Shadow of the Beast on Amstrad CPC+!! | MSX Resource Center (Página 2/10)

Enlighted (6212)

24-02-2018, 09:18

Any programmer can do much more impressive things with the V9990.
Wait until the game is released before concluding. The video just shows a demo that is feasible on MSX2+ without much difficulty for a good programmer.

Por maxis

Champion (512)

24-02-2018, 11:04

True, the full game will reveal the limits. But the GX4000 demo simply looks very promising. Sometimes we have to wait for a very long time for the game release.

I remember the "making PoP on C64" blog, where getting from demo to the working game took Mr.SID 2 years.
BTW, I'm still waiting for the PoP on MSX2 ;)

Por hit9918

Prophet (2932)

24-02-2018, 14:19

Quote:

Also one interesting feature is the fully embedded sprite memory into the ASIC. It helps the CPU to have more throughput when accessing the video area in the shared RAM.

Quote:

As GFX9000 is connected via the I/O space and not sharing the RAM with Z80, the bottleneck is the Z80 to V9990 interconnect.

so when the CPC has separate vram. then is genious thing.
while when the MSX has separate vram. then is bad thing.

Por erpirao

Paragon (1315)

24-02-2018, 14:38

maxis wrote:

True, the full game will reveal the limits. But the GX4000 demo simply looks very promising. Sometimes we have to wait for a very long time for the game release.

I remember the "making PoP on C64" blog, where getting from demo to the working game took Mr.SID 2 years.
BTW, I'm still waiting for the PoP on MSX2 ;)

PoP? best the sword of ianna.

and the demos always look promising, (well, almost always)

and that shadow to low res .. (160x200 vs 256x212) .. is 40% less graphic load, and already compare with the Amiga video at 320x200 is a nonsense.

and here is another video with many scrolls on the screen for msx2 + (shadow of the beast).

Por maxis

Champion (512)

24-02-2018, 20:47

hit9918 wrote:

Quote:

Also one interesting feature is the fully embedded sprite memory into the ASIC. It helps the CPU to have more throughput when accessing the video area in the shared RAM.

Quote:

As GFX9000 is connected via the I/O space and not sharing the RAM with Z80, the bottleneck is the Z80 to V9990 interconnect.

so when the CPC has separate vram. then is genious thing.
while when the MSX has separate vram. then is bad thing.

Well neither Amstrad CPC nor Amstrad CPC PLUS/GX4000 has the "vram". Either the main RAM is shared between the CPU and the display area, or the built-in into the ASIC (Arnold) dual-port sprite RAM is appearing in the CPU address space. And obviously there are no bottlenecks in the CPU RAM random access.

BTW, SMS solves the extra bandwidth requirement for the colorful sprites differently - SMS uses the unique and very elegant architecture - 16 bit pseudo static XRAM providing no penalty at random accesses and great throughput (like on the professional video equipment).

Also, I do believe that with V9990 Shadow of the Beast is possible, since on a good old 6502 running at the heart of TurboGrafx16 it is

Por PingPong

Enlighted (4136)

24-02-2018, 22:08

maxis wrote:

Well neither Amstrad CPC nor Amstrad CPC PLUS/GX4000 has the "vram". Either the main RAM is shared between the CPU and the display area, or the built-in into the ASIC (Arnold) dual-port sprite RAM is appearing in the CPU address space. And obviously there are no bottlenecks in the CPU RAM random access.

I think bottleneck are. the CPU instruction cycles are extended in length to sync to video hw.
A mind of bottleneck that apply always. Even when not doing vram access.
By the way, to be more precise how the video hw steal cpu?
On the C64 for example, video hw, does issue a kind of DMA.
does, on CPC BUSRQ/BUSACK used ?
Otherwise how they solve the sharing of D0-7 and A0-15 lines under an electrical point of view?
(i mean: short circuit)

Por maxis

Champion (512)

24-02-2018, 22:55

PingPong wrote:

maxis wrote:

Well neither Amstrad CPC nor Amstrad CPC PLUS/GX4000 has the "vram". Either the main RAM is shared between the CPU and the display area, or the built-in into the ASIC (Arnold) dual-port sprite RAM is appearing in the CPU address space. And obviously there are no bottlenecks in the CPU RAM random access.

I think bottleneck are. the CPU instruction cycles are extended in length to sync to video hw.
A mind of bottleneck that apply always. Even when not doing vram access.
By the way, to be more precise how the video hw steal cpu?
On the C64 for example, video hw, does issue a kind of DMA.
does, on CPC BUSRQ/BUSACK used ?
Otherwise how they solve the sharing of D0-7 and A0-15 lines under an electrical point of view?
(i mean: short circuit)

On CPC PLUS whenever the CPU shares access to the same RAM area where the video DMA is directed, the slowdown will occur, but still you can do pretty much everything by the CPU in the video DMA area. Otherwise the double buffering is possible too by alternating the working video buffer and displayed video buffer.

Z80 has a very sluggish BUSRQ/BUSACK mechanism, hence it's not used for any kind of synchronization. I.e. Z80 WAIT and the hardware bus multiplexing is in use on CPC in order to preempt the current CPU access and have a video DMA access in place.
Hence, when CPC was upgraded to CPC PLUS with sprites, the great choice was made to create the transparent independent (not physically situating in the the same RAM) area for 16 sprite bitmaps and the sprite attributes. All these sprite datas are actually the hardware registers inside Arnold ASIC. Any of those 16 sprites can be overloaded in real time without any time penalty (Arnold is memory mapped into the Z80 memory space). Putting the sprite data into the main RAM and enabling the sprite DMA would slow down CPU in the video memory down even further. It's great that the Amstrad designers opted for the dedicated hardware sprite memory.

Por TomH

Champion (361)

24-02-2018, 23:02

The CPC has a fixed four-cycle pattern, in which two contiguous cycles are used for video collection, and two are left available for the CPU. To box the CPU into its window, WAIT is asserted for three out of four cycles.

So the net effect is pretty much that machine cycles that check WAIT are extended to the next multiple of four cycles.

So instruction fetch is not affected. It's still a cycle faster than on an MSX. Accesses within instructions are generally extended from three to four cycles. So they take a cycle longer than on an MSX.

Por PingPong

Enlighted (4136)

24-02-2018, 23:02

maxis wrote:

Z80 has a very sluggish BUSRQ/BUSACK mechanism, hence it's not used for any kind of synchronization. I.e. Z80 WAIT and the hardware bus multiplexing is in use on CPC in order to preempt the current CPU access and have a video DMA access in place. .

Do you have any reference to schematic about the BUS mux? i cannot find this online. (I'm interested in more detail)

Por maxis

Champion (512)

25-02-2018, 11:51

PingPong wrote:

maxis wrote:

Z80 has a very sluggish BUSRQ/BUSACK mechanism, hence it's not used for any kind of synchronization. I.e. Z80 WAIT and the hardware bus multiplexing is in use on CPC in order to preempt the current CPU access and have a video DMA access in place. .

Do you have any reference to schematic about the BUS mux? i cannot find this online. (I'm interested in more detail)

Check out this (the basic CPC464):

IC114 and IC114 are the buffers isolating the microprocessor from the RAM. The multiplexing goes via controlling the tri-state of 74ls244 from the gate array.