VDP 128Kb Extended VRAM mode
Moderators: BigEvilCorporation, Mask of Destiny
Re: VDP 128Kb Extended VRAM mode
I think that what Tiido said is that the VDP is being dumb and reading the same word twice for no real reason (maybe it was a last minute hack when they were wiring the VDP back to using 64KB? the whole thing is a really ugly mess, 64KB mode 5 uses a different address bus wiring while 128KB mode 5 uses the same arrangement as mode 4)
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: VDP 128Kb Extended VRAM mode
So it would read 2 words from memory and only write 1 word into the VDP port ? otherwise that wouldn't work.Sik wrote:I think that what Tiido said is that the VDP is being dumb and reading the same word twice for no real reason (maybe it was a last minute hack when they were wiring the VDP back to using 64KB? the whole thing is a really ugly mess, 64KB mode 5 uses a different address bus wiring while 128KB mode 5 uses the same arrangement as mode 4)
Honestly that does not make any sense for me O_o...
I think the VDP is always reading memory as word to fed up the VDP data port as it does for CRAM or VSRAM DMA writes.
The only difference is that word data from FIFO is wrote to VRAM through 2 internals 8 bit writes operation where CRAM or VSRAM are wrote in single 16 bit operation.
I understand the hacky solution idea where you would simply read the data twice from memory, but that means you also copy it twice to FIFO, read low byte on first word and high byte on second word. But then it requires to completely hack the auto increment logic / destination address update stuff as well, i really don't believe they did that.
Re: VDP 128Kb Extended VRAM mode
It doesn't make much sense to me either but if it was such a rushed change as I'm saying then maybe it was the easiest way to get it working.
EDIT: argh you edited while I replied =P Remember that the way a DMA transfer works seems to be like simply simulating writes to $C00000 (well, not exactly but you get the same effect), for all we know the second word gets dropped by the DMA portion of the hardware before it reaches the FIFO.
Incidentally, I suppose that DMA fill bug I mentioned is probably gone in 128KB mode.
Let's just wait for Tiido to clarify what he meant I guess...
EDIT: argh you edited while I replied =P Remember that the way a DMA transfer works seems to be like simply simulating writes to $C00000 (well, not exactly but you get the same effect), for all we know the second word gets dropped by the DMA portion of the hardware before it reaches the FIFO.
Incidentally, I suppose that DMA fill bug I mentioned is probably gone in 128KB mode.
Let's just wait for Tiido to clarify what he meant I guess...
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: VDP 128Kb Extended VRAM mode
Actually I haven't considered FIFO at all... but it is verified that FIFO is always there.
It is measured that ROM reads during DMA happen every other pixel, and due to way bus cycles work single access will always see two bytes out the ROM, if the VDP was using both bytes you'd have DMA cycle every 4 pixels (so it can write one byte on one cycle and other on the other) rather than every 2 that is observed. The VDP does not refetch data from same address either, address increments on every access.
That only leaves VDP using only one byte out the two that each access reads and perhaps the FIFO entries actually have 8/16 info to them. If access speed doubled you'd need like 70ns ROMs and such didn't even exist at that time. DMA cycles are at 150ns speed, the edge of most ROMs.
It is measured that ROM reads during DMA happen every other pixel, and due to way bus cycles work single access will always see two bytes out the ROM, if the VDP was using both bytes you'd have DMA cycle every 4 pixels (so it can write one byte on one cycle and other on the other) rather than every 2 that is observed. The VDP does not refetch data from same address either, address increments on every access.
That only leaves VDP using only one byte out the two that each access reads and perhaps the FIFO entries actually have 8/16 info to them. If access speed doubled you'd need like 70ns ROMs and such didn't even exist at that time. DMA cycles are at 150ns speed, the edge of most ROMs.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: VDP 128Kb Extended VRAM mode
150 ns ? i though earlier rom were a lot slower than that (more in the 300 ns range).TmEE co.(TM) wrote:Actually I haven't considered FIFO at all... but it is verified that FIFO is always there.
It is measured that ROM reads during DMA happen every other pixel, and due to way bus cycles work single access will always see two bytes out the ROM, if the VDP was using both bytes you'd have DMA cycle every 4 pixels (so it can write one byte on one cycle and other on the other) rather than every 2 that is observed. The VDP does not refetch data from same address either, address increments on every access.
That only leaves VDP using only one byte out the two that each access reads and perhaps the FIFO entries actually have 8/16 info to them. If access speed doubled you'd need like 70ns ROMs and such didn't even exist at that time. DMA cycles are at 150ns speed, the edge of most ROMs.
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: VDP 128Kb Extended VRAM mode
The DMA engine only reads every 2 pixels until the FIFO is full. For word-wide targets, the FIFO drains as fast as it fills so this never happens. For byte wide targets the FIFO drains half as fast as it fills and since there's some minimum latency (at least 2 slots IIRC) before any data written to the FIFO can be written to the target, the FIFO fills up almost immediately. Once the FIFO is full you'll see one access every 4 pixels, though I believe the individual accesses are still only 2 pixels long. It's been a little while, but I'm pretty sure I have a logic analyzer capture of that specific case.TmEE co.(TM) wrote:It is measured that ROM reads during DMA happen every other pixel, and due to way bus cycles work single access will always see two bytes out the ROM, if the VDP was using both bytes you'd have DMA cycle every 4 pixels (so it can write one byte on one cycle and other on the other) rather than every 2 that is observed.
But yeah, I don't see how DMA could work properly on a 300ns ROM unless you're not talking about the address valid -> output valid time.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: VDP 128Kb Extended VRAM mode
Ok so that seems logic then, full speed until FIFO is full
About the Rom speed, to be honest i'm not really sure about which timing it was.. But finally my question is the following, does that mean that even earlier ROM were capable of ROM to CRAM DMA ? I almost certain that some earliest games did it from main RAM for that only reason.
About the Rom speed, to be honest i'm not really sure about which timing it was.. But finally my question is the following, does that mean that even earlier ROM were capable of ROM to CRAM DMA ? I almost certain that some earliest games did it from main RAM for that only reason.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: VDP 128Kb Extended VRAM mode
Ok, that makes sense. Mystery solved then.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Re: VDP 128Kb Extended VRAM mode
You know, doesn't DMA use the same bus timings as the 68000? (remember that the 68000 may take four cycles to access memory but only a portion of that is actually used externally, the rest is internal workings - which is also why DMA is faster, not having to cope with those wasted cycles)
To be fair, that may have more to do with making it easier to manage palettes by grouping them together on the fly (most games will take separate palettes together, e.g. the player palette + the palettes specific to a level), as well as making it easier to do palette effects (fading, rotation, etc.).Stef wrote:I almost certain that some earliest games did it from main RAM for that only reason.
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: VDP 128Kb Extended VRAM mode
No, DMA uses nearly double speed bus timings compared to 68K.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: VDP 128Kb Extended VRAM mode
Yeah, a DMA memory operation takes the same number of cycles (4), but the clock is much faster as it's the VDP's current clock which is either MCLK/4 or MCLK/5 whereas the 68K's clock is MCLK/7.
Re: VDP 128Kb Extended VRAM mode
Wait, 1/MCLK = ~18.624 nsMask of Destiny wrote:Yeah, a DMA memory operation takes the same number of cycles (4), but the clock is much faster as it's the VDP's current clock which is either MCLK/4 or MCLK/5 whereas the 68K's clock is MCLK/7.
So, if DMA does read at speed MCLK/4 during 4 cycles, it means that it shoud response during 4/CLK seconds.
so, 4*7/MCLK = ~521.481 ns
and 4*5/MCLK = ~372.487 ns
and 4*4/MCLK = ~297.99 ns
But, taking into account that reading actually made during 8 half-cycles, and response is taking not all of them... it should be even a bit faster.
So far as I remember, 200 ns is recomended cart response, so it looks ok
Re: VDP 128Kb Extended VRAM mode
I'm sorry ot resurrect - again - such an old topic, but I've been toying with this mode, and I have problem putting it in use.
Let the code :
This code is simple :
- first, it clears 128k, and writes the CART header in VRAM[0000]
- then, it sets 128k, and writes the CART header in VRAM[0080]
In its Overdrive notes (mirrored on the excellent @Sik site), Kabuto notes :
"SEGA MEGADRIVE ..."
and at VRAM[0080], I would read :
"S_G_ _E_A_R_V_ ..." (of course, "_" isn't "_" but points to the lack of character).
The lower bytes would be written to the actual VRAM chips, and the upper bytes would be written to the non-existent chips (ie, dismissed).
But, running this code in Exodus 2.1, GensKMod 212a - 073, and Regen 097D, I got the same text at VRAM[0000] and VRAM[0080].
So, I think there must be something I'm doing wrong, but I can't find what.
Could you guys please give me the hand on this stuff ?
Edit: typo
Let the code :
Code: Select all
ROM_SIZE equ $10000
GFX_CTRL equ $C00004
GFX_DATA equ $C00000
_dmaSrcDestLen: macro
move.w #$9300+((\3)&$FF),GFX_CTRL
move.w #$9400+((\3>>8)&$FF),GFX_CTRL
move.w #$9500+((\1>>1)&$FF),GFX_CTRL
move.w #$9600+(((\1>>1)&$FF00)>>8),GFX_CTRL
move.w #$9700+((((\1>>1)&$FF0000)>>16)&$7F),GFX_CTRL
move.l #$40000080|((\2&$3FFF)<<16)|((\2&$C000)>>14),-(a7)
move.w (a7)+,GFX_CTRL
move.w (a7)+,GFX_CTRL
endm
DC.L $FFFFF0
DC.L $200
DC.L INT, INT, INT, INT, INT, INT
dc.l INT, INT, INT, INT, INT, INT, INT, INT
dc.l INT, INT, INT, INT, INT, INT, INT, INT
dc.l INT, INT, INT, INT, INT, INT, V_INT, INT
dc.l INT, INT, INT, INT, INT, INT, INT, INT
dc.l INT, INT, INT, INT, INT, INT, INT, INT
dc.l 0,0,0,0,0,0,0,0
dc.l 0,0,0,0,0,0,0,0
DC.B 'SEGA MEGA DRIVE ' ; Console name (16B)
DC.B '(C)OB1 2021.MAR' ; Copyright notice (16B)
DC.B 'DMA 128K '
DC.B ' '
DC.B ' ' ; Domestic game name (48B)
DC.B 'DMA 128K '
DC.B ' '
DC.B ' ' ; Overseas game name (48B)
DC.B 'GM' ; Type of product (2B)
DC.B ' 00000000-00' ; Product code, version nbr (12B)
DC.W 0 ; Checksum (2B)
DC.B 'J ' ; I/O support (16B)
DC.L 0, ROM_SIZE-1 ; ROM start/end (4B each)
DC.L $FF0000,$FFFFFF ; RAM start/end (4B each)
DC.B ' ' ; Padder (12B)
DC.B ' ' ; Modem (12B)
DC.B ' '
DC.B ' '
DC.B ' ' ; Memo (40B)
DC.B 'JUE ' ; Country game (16B)
move.b $a10000,d0 ; Read Version Number
andi.b #$f,d0
beq.s japan
move.l #'SEGA',$a14000
japan:
move.w #$8104,GFX_CTRL ; Set M5
move.w #$8F02,GFX_CTRL ; Auto Increment 2
move.w #$8114,GFX_CTRL ; Set DMA
_dmaSrcDestLen $100,0,$80
move.w #$8194,GFX_CTRL ; Set 128k | DMA
_dmaSrcDestLen $100,$80,$80
move.w #$8124,GFX_CTRL ; Clear DMA, issue V INT
movea.l #$FFFF00,a0
move.l a0,usp
move.w #$0500,SR ; Acknowledge V INT
main:
bra main
INT:
rte
V_INT:
addq.w #1,$FF0000
rte
DS.B ROM_SIZE-*
- first, it clears 128k, and writes the CART header in VRAM[0000]
- then, it sets 128k, and writes the CART header in VRAM[0080]
In its Overdrive notes (mirrored on the excellent @Sik site), Kabuto notes :
So, I would assume that at VRAM[0000], I would read :then just the lower byte of each word written to VRAM will get stored
"SEGA MEGADRIVE ..."
and at VRAM[0080], I would read :
"S_G_ _E_A_R_V_ ..." (of course, "_" isn't "_" but points to the lack of character).
The lower bytes would be written to the actual VRAM chips, and the upper bytes would be written to the non-existent chips (ie, dismissed).
But, running this code in Exodus 2.1, GensKMod 212a - 073, and Regen 097D, I got the same text at VRAM[0000] and VRAM[0080].
So, I think there must be something I'm doing wrong, but I can't find what.
Could you guys please give me the hand on this stuff ?
Edit: typo
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: VDP 128Kb Extended VRAM mode
None of these emulators (even Exodus as far i know) actually emulates that 128K mode so don't be surprised to not see behavior of the 128K mode here.
BlastEm is the only emulator to (partially ?) emulate it so be sure to use this emulator which is the most accurate by far when you are testing obscures things like that
BlastEm is the only emulator to (partially ?) emulate it so be sure to use this emulator which is the most accurate by far when you are testing obscures things like that
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: VDP 128Kb Extended VRAM mode
Yeah, my support is fairly minimal at the moment. I emulate 128KB mode's impact on the FIFO, but I don't support actually having 128KB of VRAM and rendering currently takes place as if 64KB mode is selected regardless of what the relevant bit in the mode registers is set to. I think Picodrive also emulates this now, but my impression is that it's not especially accurate in other ways