What if V9938 never existed?

페이지 5/6
1 | 2 | 3 | 4 | | 6

By Sandy Brand

Master (153)

Sandy Brand의 아바타

26-05-2019, 23:46

Juan Luis wrote:
Quote:

The V9938 command engine can’t flip. Rather, the DIX / DIY flags negate both the source and destination increment, so the image orientation stays as it is. The flags exist to support overlapping copies without repetition (copy (0, 0)-(255,210) to (0,1)).

Fuck! Isn't there any VDP with flip X support for computers? Are all VDP with flip X support for consoles?

(Slightly off-topic: I always assumed the DIX/DIY flags do matter if you read/write data from CPU to VRAM using commands such as LMMC? That would technically be a 'flip', although not really a useful one Smile ).

By hit9918

Prophet (2866)

hit9918의 아바타

26-05-2019, 23:49

I mean these speech samples
https://www.youtube.com/watch?v=UiiNLhYHXSI

the moonsound should do this in high def.
it works by poking the frequency and volume registers in the vblank interrupt. and it needs less RAM than samples.

By Grauw

Ascended (8406)

Grauw의 아바타

27-05-2019, 01:07

Juan Luis wrote:

Fuck! Isn't there any VDP with flip X support for computers? Are all VDP with flip X support for consoles?

Mirroring isn’t that great anyway IMO for high quality artwork. Since the light source would typically be in the top left or top right, if you mirror the shading would be wrong. And mirroring up/down doesn’t apply for obvious reasons.

Also mirroring is a memory optimisation, but I think with 128K of VRAM lack of the memory itself isn’t a huge problem. I mean we can store 256x1024 worth of 4bpp bitmap data, that’s a lot.

Sandy Brand wrote:

(Slightly off-topic: I always assumed the DIX/DIY flags do matter if you read/write data from CPU to VRAM using commands such as LMMC? That would technically be a 'flip', although not really a useful one Smile ).

Ah, yes, you’re right! Smile

And I do think sourcing tiles from the CPU memory rather than from VRAM page is pretty useful. Especially for ROM based games.

Juan Luis wrote:

Do you believe that MSX2+ was able to do this at same speed and with the same music in 1988?
https://www.youtube.com/watch?v=ZwkrOy9CcYQ

Why not? Look at how fast Aleste 2 scrolls using the V9938’s vertical scroll register. Uridium is that just flipped sideways, which the V9958 has no trouble with scrolling.

By PingPong

Prophet (3439)

PingPong의 아바타

27-05-2019, 09:37

[quote=Grauw wrote:
Juan Luis wrote:

Do you believe that MSX2+ was able to do this at same speed and with the same music in 1988?
https://www.youtube.com/watch?v=ZwkrOy9CcYQ

Why not? Look at how fast Aleste 2 scrolls using the V9938’s vertical scroll register. Uridium is that just flipped sideways, which the V9958 has no trouble with scrolling.

in some point it does appear that aleste is doing a very fast scroll, but it is a trick. look at the background, when the scrolling goes fast it is mainly because only vdp(24) is updated, but there is no data feed from cpu. You can see this at the beginning of the stage and looking at it you will notice that it is a simple screen cycling without updates.
similar to what you can achieve with:
for T%=0TO255
vdp(24)=T%
nextT%

anyway i think msx2+ can scroll at decent speed in all directions even with the need to feed new pixel data when adjusting the scroll registers.

By Grauw

Ascended (8406)

Grauw의 아바타

27-05-2019, 11:43

PingPong wrote:

in some point it does appear that aleste is doing a very fast scroll, but it is a trick. look at the background, when the scrolling goes fast it is mainly because only vdp(24) is updated, but there is no data feed from cpu. You can see this at the beginning of the stage and looking at it you will notice that it is a simple screen cycling without updates.

It does that too in some very fast sections, but e.g. here @ 16:58 it scrolls at 4 px / frame without repetition. And that’s still relatively slow, the VDP is fast enough to supply 16x212 worth of new pixels for a 16 px per 60 Hz frame scroll.

At max speed Uridium 2 seems to scroll 8 px per 50 Hz frame (pause and use , and . to frame-step in Youtube). That’s no problem for the V9958 to keep up with, even in 8bpp screen modes.

Sonyc scrolls at 4 px / 60 Hz frame bidirectionally, effectively 8 px / frame, as fast as Uridium 2.

By DarkSchneider

Paladin (867)

DarkSchneider의 아바타

27-05-2019, 12:32

Grauw wrote:

The V9938 command engine can’t flip. Rather, the DIX / DIY flags negate both the source and destination increment, so the image orientation stays as it is. The flags exist to support overlapping copies without repetition (copy (0, 0)-(255,210) to (0,1)).

Mirroring isn’t that great anyway IMO for high quality artwork. Since the light source would typically be in the top left or top right, if you mirror the shading would be wrong. And mirroring up/down doesn’t apply for obvious reasons.

Also mirroring is a memory optimisation, but I think with 128K of VRAM lack of the memory itself isn’t a huge problem. I mean we can store 256x1024 worth of 4bpp bitmap data, that’s a lot.

Disappointing, mirror is always useful, and for SC7/8 it could helps a lot for saving memory.

Grauw wrote:

And I do think sourcing tiles from the CPU memory rather than from VRAM page is pretty useful. Especially for ROM based games.

I also like much to work from RAM and think is the way to follow, but again we are limited. It is nice with a proper WAIT signal connected and compatible with commands, so the CPU (at any speed) and VDP (the same) could auto-negotiate (being the CPU halted by the VDP at hardware level) for full throughput. Again we have something promising not achieved.
Take a Zemmix on Turbo mode, it simulates the WAIT signal correctly connected and working, and an about 10MHz Z80. Then try to do some operations from CPU to VRAM, is so...nice.

By tvalenca

Paladin (728)

tvalenca의 아바타

27-05-2019, 18:57

Juan Luis wrote:

From the point of view of memory, there were two types of video processor architectures. VDP that didn't share video memory like MSX VDPs, and video processors that share video memory with CPU and other chips like C64, Amiga custom chips, NES, etc.

The reason for choosing shared memory in consoles was to reduce the price. When a videogame is executing, most of information is constant (code, graphics patterns definition, sounds). The only variable informations are program variables in CPU and pattern names table in VDP. NES had only 2KBytes for Pattern Name Table and 2KBytes for program variables. All constant information was in the cartridge. This allowed to reduce the price of the console. This kind of architectures were very common in consoles world.

Well, that wasn't my point. (oh, wait: Video memory CANNOT be directly accessed on the NES! You have to use PPU ports - which were memory mapped, but this doesn't mean that you can LD anything into VRAM without asking PPU to do it for you)
Also, altough putting most of video memory inside cartridge did reduced the need of a bigger memory bank, it was a one-off feature in the market (as in: no one else -besides SNK on NEOGEO MVS and AES- did anything alike)

By Juan Luis

Resident (46)

Juan Luis의 아바타

27-05-2019, 23:58

Quote:

Take a Zemmix on Turbo mode, it simulates the WAIT signal correctly connected and working, and an about 10MHz Z80. Then try to do some operations from CPU to VRAM, is so...nice.
Reply

The ideal way of accessing to CPU memory from VDP is by DMA, using BUSRQ, BUSACK y WAIT when VDP doesn't have the information ready to transfer. Transfers would be quicker disturbing less to the CPU, but as I said at beginning of this post, MSX does't have BUSRQ and BUSCACK signals on the bus. Memory transfers could be done more efficiently

By Grauw

Ascended (8406)

Grauw의 아바타

28-05-2019, 00:29

DarkSchneider wrote:

I also like much to work from RAM and think is the way to follow, but again we are limited. It is nice with a proper WAIT signal connected and compatible with commands, so the CPU (at any speed) and VDP (the same) could auto-negotiate (being the CPU halted by the VDP at hardware level) for full throughput. Again we have something promising not achieved.

You can send data to the HMMC VDP command at pretty much full throttle, no need to poll the TR flag which slows it down by a lot. All real turbo hardware has automatic waits inserted on VDP access (exactly what you wish for), and FPGA emulations don’t have access speed restrictions.

That the waits are not fed by the VDP but through another mechanism (V9958’s /WAIT may seem ideal on paper but there must be a reason they didn’t use it) doesn’t change the fact that you can assume them to be present and rely on it to prevent you from accessing the VDP too fast on a turbo CPU.

Alternatively, you could poll TR if you detect a turbo CPU, and skip it if it’s a regular 3.58 MHz Z80.

(p.s. The OCM / Zemmix Neo turbo mode completely messes up the cartridge bus timing, very nonstandard, causing signal level incompatibilities with a lot of hardware especially > 8 MHz. Would be nice if that was fixed, similar to the turboR.)

By PingPong

Prophet (3439)

PingPong의 아바타

28-05-2019, 00:19

tvalenca wrote:

Well, that wasn't my point. (oh, wait: Video memory CANNOT be directly accessed on the NES! You have to use PPU ports - which were memory mapped, but this doesn't mean that you can LD anything into VRAM without asking PPU to do it for you)

this does not surprise me at all. it is well known that ppu is basically a copy of tms

페이지 5/6
1 | 2 | 3 | 4 | | 6