Page 1 of 3

Titan's Mega Drive tech docs including Debug Register

Posted: Wed Apr 19, 2017 6:20 pm
by Kabuto
This is our first item in a series of follow-ups about the making of Overdrive 2: everything we figured out about the Mega Drive hardware.

I hope this will clear many things up and inspire more people to play with this platform!

Just ask right here on the boards if there are any questions, or join us on IRC (#titandemo on EFNet)

https://docs.google.com/document/d/1ST9 ... V8saY8/pub

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Thu Apr 20, 2017 9:29 am
by Stef
Thanks a tons for sharing your findings ! Guess i will have a very pleasant moment reading the document :)

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Thu Apr 20, 2017 2:04 pm
by Eke
Thanks a lot indeed. I only had a quick look at it but I noted the following topics holding new infos to me, mostly VDP processing edge case tricks:

- V28/V30 bit trick: it was my initial assumption that this bit could be used to increase the display size by switching it in appropriated line intervals but I would never have thought this could lead to disable completely the border area. I didn't initially noticed it but that trick is indeed used in Overdrive 2 demo to render fullscreen picture on a PAL TV :shock:

- Sprites processing: Some of the provided infos are mostly stuff already documented in the forum but it contains some interesting bits of information about the effects of using invalid sprites link value (initial tests seemed to indicate sprite parsing during "phase 1" would simply stop if the link value was > 79 as if a value of 0 was encountered but that does not seems the case from your tests) or when VDP actually reads the SAT cache (I would not have thought ypos and size were read a second time during "phase 2" for example). This could indeed be abused to produce tricky sprite behavior but more as a way to stress emulators than improving sprites capacity so I don't know if this was used in the demo ?

- Sprites masking mode description seems to be a little bit different from what was described by Nemesis (see viewtopic.php?f=2&t=541&start=34) but I'm not sure. Again, I wonder if this was used in the demo ?

- 128k extended mode: that fast 8-bit DMA trick is really clever and I can see this is being used for various scenes in the demo as implementing 64k/128k addressing mode switching in Genesis Plux GX fixed some graphical bugs (the first scene with the rain effect especially). It also fixed the z80 sound driver crash which was caused by DMA halting 68k twice longer than it should in this mode. It did not fix the scene in the arcade though which still display corrupted tiles all over the screen so I guess this one relies on something else?

- Debug register: I don't have read the description in detail yet but it seems some stuff would be a pain to emulate, especially the bits that let you display normally hidden "garbage". It would be interesting to know what 'usable' effects are actually used in Overdrive 2 demo (besides the plane 'blending' effect obviously). Those PSG channel selection bits are also new to me, funny we still discover stuff like that after all this time.

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Thu Apr 20, 2017 5:08 pm
by Kabuto
- Sprites processing: ... ypos and size were read a second time during "phase 2" ... This could indeed be abused to produce tricky sprite behavior but more as a way to stress emulators than improving sprites capacity so I don't know if this was used in the demo ?
--> yes, that behaviour is utilised... or rather, worked around.

- Sprites masking mode description seems to be a little bit different from what was described by Nemesis (see viewtopic.php?f=2&t=541&start=34) but I'm not sure. Again, I wonder if this was used in the demo ?
--> no, x=0 is never used iirc. Nemesis' description reads mostly identical to mine but he did not notice the differences when the 40th tile slot is in use and used by a sprite with x!=0.

- 128k extended mode: that fast 8-bit DMA trick is really clever ... also fixed the z80 sound driver crash ...
--> nice progress! never thought emu developers would try to fix their emulators so quickly, after it took a while after overdrive 1.

- It did not fix the scene in the arcade though which still display corrupted tiles all over the screen so I guess this one relies on something else?
--> yeah, debug flags, and HIRQ behaviour with opened vborders

- Debug register: I don't have read the description in detail yet but it seems some stuff would be a pain to emulate, especially the bits that let you display normally hidden "garbage".
--> actually everything on screen should be rather easy to emulate, but yeah, the garbage might need full emulation of the VRAM bus. Lots of work was spent on getting rid of all the unwanted garbage, but 2 effect makes explicit use of what one would normally consider garbage ;)

- It would be interesting to know what 'usable' effects are actually used in Overdrive 2 demo (besides the plane 'blending' effect obviously)
--> just bits 6 to 8 (blending and plane exclusive modes)

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Thu Apr 20, 2017 10:16 pm
by Sik
Eke wrote:- Debug register: I don't have read the description in detail yet but it seems some stuff would be a pain to emulate, especially the bits that let you display normally hidden "garbage". It would be interesting to know what 'usable' effects are actually used in Overdrive 2 demo (besides the plane 'blending' effect obviously).
The biggest issue with Genesis Plus GX from what I remember is that it merges planes A and B too early (and only later merges with S), but to emulate this feature properly you need to keep them all separate until the moment they're going to be displayed (since it involves masking against the selected plane). Emulators that don't do this will have an easier time emulating the blending part (there's still border and garbage, but they aren't anywhere as critical aside from the border breaking effect).
Eke wrote:Those PSG channel selection bits are also new to me, funny we still discover stuff like that after all this time.
They aren't really new, it's just that everybody kept hearing clicks and didn't bother to look further into it. It could be exploited to make some loud sounds I suppose (with horrible sampling quality, although at least a good sample rate is feasible).

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Fri Apr 21, 2017 7:11 am
by Eke
Kabuto wrote: Nice progress! never thought emu developers would try to fix their emulators so quickly, after it took a while after overdrive 1.
To be fair, first demo only required a few adjustment to FIFO timings emulation, which was done quickly after the demo release to get stable 512k screen, and the limitation of "phase 1" sprites parsing when display is disabled during hblank, which was fixed quickly after Oerg ended up explaining this "your emulator suxx" trick :wink:

I would say it's quite motivating to have such brillant and challenging demos as a goal to run in your emulator, pretty much as fun as trying to defeaticopy protections in unlicensed games :)
Sik wrote: The biggest issue with Genesis Plus GX from what I remember is that it merges planes A and B too early (and only later merges with S), but to emulate this feature properly you need to keep them all separate until the moment they're going to be displayed (since it involves masking against the selected plane).
Yes, that's pretty much it, this is mainly done for optimization (it avoids reading/writing layer buffers multiple time). A simple workaround is to use specific bg and sprite rendering functions when those debug bits are activated.

EDIT: got it to work without changing much of existing implementation and keeping optimized prioritizer for 'normal' Mode 5 rendering, really nice to see those blending effects on screen (many scenes are now properly emulated so it seems you indeed abused of this trick all over the demo)
Sik wrote: They aren't really new, it's just that everybody kept hearing clicks and didn't bother to look further into it. It could be exploited to make some loud sounds I suppose (with horrible sampling quality, although at least a good sample rate is feasible).
I might have misunderstood that bits description then. You mean it's not really PSG channel output selection but rather the output of selected PSG channel as if the flip-flop was fixed in high state?

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Fri Apr 21, 2017 8:54 am
by Mask of Destiny
Kabuto wrote:Lots of work was spent on getting rid of all the unwanted garbage, but 2 effect makes explicit use of what one would normally consider garbage ;)
So based on a comment/question from alk on IRC, I'm guessing one of those is the dissolve of the white border in the post-Titancade screen. What's the other?

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Sat Apr 22, 2017 12:31 am
by Sik
Eke wrote:
Sik wrote: They aren't really new, it's just that everybody kept hearing clicks and didn't bother to look further into it. It could be exploited to make some loud sounds I suppose (with horrible sampling quality, although at least a good sample rate is feasible).
I might have misunderstood that bits description then. You mean it's not really PSG channel output selection but rather the output of selected PSG channel as if the flip-flop was fixed in high state?
When bit 9 is set:
1) Make all four PSG channels always high (like when we use them for PCM)
2) Make their attenuation the same as for the channel selected by bits 11-10

That's all there's to it, really. You could do the PCM trick on them but 4x as loud (at the expense of no normal PSG output).

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Sat Apr 22, 2017 1:20 am
by Kabuto
Mask of Destiny wrote:
Kabuto wrote:Lots of work was spent on getting rid of all the unwanted garbage, but 2 effect makes explicit use of what one would normally consider garbage ;)
So based on a comment/question from alk on IRC, I'm guessing one of those is the dissolve of the white border in the post-Titancade screen. What's the other?
Yes, that screen and the arcades screen, for the horizontal sideborder. The only 2 parts that actually want to have something in the borders.

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Sat Apr 22, 2017 8:14 am
by Eke
Sik wrote: When bit 9 is set:
1) Make all four PSG channels always high (like when we use them for PCM)
2) Make their attenuation the same as for the channel selected by bits 11-10

That's all there's to it, really. You could do the PCM trick on them but 4x as loud (at the expense of no normal PSG output).
Thanks for the precisions.
Kabuto wrote: - It did not fix the scene in the arcade though which still display corrupted tiles all over the screen so I guess this one relies on something else?
--> yeah, debug flags, and HIRQ behaviour with opened vborders
Some questions about V28/V30 bit trick':
- it makes HINT still occurring during vborders but also whole vblank i.e all 313 lines possibly ?
- VDP skips vborder activation but does it also forget to set vblank flag ?
- what about VINT ? Is it still ocurring or is it also skipped ?

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Sat Apr 22, 2017 11:17 am
by Kabuto
Eke wrote: Some questions about V28/V30 bit trick':
- it makes HINT still occurring during vborders but also whole vblank i.e all 313 lines possibly ?
yes. HINT runs continuously. Set register $F to 0 and you get a HIRQ on each of the 313 rasterlines. Set it to 156 and you get a HIRQ before raster line 156 the frame on which you open vborder the first time, then before raster lines 0 and 157 the next frame, then before raster lines 1 and 158 the following frame, and so on.. it runs constantly and is not reset at the start of the frame.
Eke wrote: - VDP skips vborder activation but does it also forget to set vblank flag ?
- what about VINT ? Is it still ocurring or is it also skipped ?
I did not test those, but I am pretty sure that both of them are skipped too.

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Mon Apr 24, 2017 9:24 am
by Eke
Thanks again,

I have another question regarding the debug mode when sprite plane is forced active (bits 8,7 = 0,1) : what happens for pixels where there hasn't been any sprite pixel (transparent or not) rendered in the line buffer ? The sprite buffer pixel color value is normally 0 in this case (same as a low-priority transparent pixel) since it was cleared during previous line rendering but using zero as AND mask here gives wrong result in the demo.

Outputting the normally expected pixel value in this specific case (instead of blending or forcing sprite color) produces correct result for the various scenes that use the debug bits - except for the very first one (moving circles effects "behind" overdrive sprite) where it is missing the blue circles around the sprite (but I can however see them "behind" the sprite as part of the transparency effect). So what is the trick here?

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Mon Apr 24, 2017 10:14 am
by MetalliC
if I get it right - forcibly enabled plane ANDed with normally final result color number. there is always color number, in your case it is border color ?

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Mon Apr 24, 2017 12:06 pm
by Eke
From what I could tell, background color was set to color 0 so result would be the same.

I think the background is never displayed anyway if bit 7 or bit 8 is set (or maybe only during x/y borders in case sprite layer is the one being forced active, I don't know, the doc is not 100% clear about that, it just says that sprite layer is not rendered during borders and sprite buffer might not even be read out so I'm not sure what should be the forced color value in this case).

But after having looked back at the code, it might be possible that anding with 0 is the way to go and the graphical error I got was simply due to inter-sprite priority lookup table in Genesis Plus GX simply ignoring transparent sprite pixels, thus not writing priority and palette bits in sprite buffer for such pixels (since they have no effect in normal display mode). I will need to modify this and test again later to see if effects get fixed.

Re: Titan's Mega Drive tech docs including Debug Register

Posted: Mon Apr 24, 2017 6:14 pm
by Kabuto
Eke wrote:I have another question regarding the debug mode when sprite plane is forced active (bits 8,7 = 0,1) : what happens for pixels where there hasn't been any sprite pixel (transparent or not) rendered in the line buffer ? The sprite buffer pixel color value is normally 0 in this case (same as a low-priority transparent pixel) since it was cleared during previous line rendering but using zero as AND mask here gives wrong result in the demo.
You should get a 0 as output too.
Eke wrote:Outputting the normally expected pixel value in this specific case (instead of blending or forcing sprite color) produces correct result for the various scenes that use the debug bits - except for the very first one (moving circles effects "behind" overdrive sprite) where it is missing the blue circles around the sprite (but I can however see them "behind" the sprite as part of the transparency effect). So what is the trick here?
This sounds like you're not treating transparent sprite pixels correctly, this effect uses sprites with palette 3, so their transparent pixels will be written to the linebuffer as 0x30.
Eke wrote:I think the background is never displayed anyway if bit 7 or bit 8 is set (or maybe only during x/y borders in case sprite layer is the one being forced active, I don't know, the doc is not 100% clear about that, it just says that sprite layer is not rendered during borders and sprite buffer might not even be read out so I'm not sure what should be the forced color value in this case).
You're right, background is never displayed, and I clarified the doc a bit. You can assume sprites to be 0 in all borders (except for the special case of raster line -1 but not in sideborders either). The linebuffer is not touched during vertical blank (since the 4 tiles rendered after raster line 223 are still in there in raster line -1).