SpritesMind.Net

Posted: **Mon Dec 14, 2015 1:27 pm**

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)

Posted: **Mon Dec 14, 2015 2:19 pm**

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)

So it would read 2 words from memory and only write 1 word into the VDP port ? otherwise that wouldn't work.
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.

Posted: **Mon Dec 14, 2015 2:44 pm**

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...

Posted: **Mon Dec 14, 2015 4:39 pm**

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.

Posted: **Mon Dec 14, 2015 5:06 pm**

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.

150 ns ? i though earlier rom were a lot slower than that (more in the 300 ns range).

Posted: **Mon Dec 14, 2015 8:12 pm**

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.

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.

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.

Posted: **Mon Dec 14, 2015 8:38 pm**

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.

Posted: **Tue Dec 15, 2015 3:40 am**

Ok, that makes sense. Mystery solved then.

Posted: **Wed Dec 16, 2015 2:57 am**

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)

Stef wrote:I almost certain that some earliest games did it from main RAM for that only reason.

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.).

Posted: **Wed Dec 16, 2015 4:53 am**

No, DMA uses nearly double speed bus timings compared to 68K.

Posted: **Wed Dec 16, 2015 9:14 pm**

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.

Posted: **Mon Jan 18, 2016 7:03 pm**

Mask 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.

Wait, 1/MCLK = ~18.624 ns
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

Posted: **Thu Mar 04, 2021 1:08 pm**

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 :

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-*

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 :

then just the lower byte of each word written to VRAM will get stored

So, I would assume that at VRAM[0000], I would read :
"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

Posted: **Sat Mar 06, 2021 10:26 pm**

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

Posted: **Wed Mar 10, 2021 1:15 am**

Stef wrote: ↑
Sat Mar 06, 2021 10:26 pm
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

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

SpritesMind.Net

VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode

Re: VDP 128Kb Extended VRAM mode