Titan's Mega Drive tech docs including Debug Register

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

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

Post by Eke » Tue Apr 25, 2017 8:28 am

Kabuto wrote: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.
Yes, this was indeed the case: as mentioned in my previous post, transparent sprite pixels were never rendered into sprite buffer (since they have zero effect in "normal" mode, no matter the value of priority and palette bits). Modifying the pixel priority lookup table calculation and the sprite pixel rendering macro fixed this effect and a few others at the end of the demo.

Remaining issues so far:

1) a few vertical jittering during the zooming and twisting of overdrive 2 logo (not sure what causes this, maybe mid-line vscroll modifications in 2-cell vscrolling mode ?)

2) missing broken border tricks during the arcade scene + some rolling black lines over this screen likely caused by the missing HINT occurences during vblank (this one will need some work since it's not so easy to dynamically increase the height of the rendered frame in emulation loop)

3) rotating textured cubes scene is completely broken (this one needs some investigation but probably relies on precisely timed VDP writes among other things)

4) graphical issue during transition between the "incoming" scene and the moving white spotlights (not sure how you call this effect) at around 5:20 in youtube official video (needs investigation as well)

5) some graphical issues during the transition between the 'ninja robot' scene and the plasma effect with locked Titan logo (again not 100% sure but some might be related to mid-line vscroll modifications)

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

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

Post by Kabuto » Tue Apr 25, 2017 7:52 pm

1) no per column vscroll changes here, just per rasterline vscroll changes in the zoomer, no vscroll changes at all when it twists

3) yeah, this part requires halfway precise timing (but it's actually kinda relaxed since this routine also has to account for cycles stolen by the Z80)

4) we call them voronoi circles. If you show me a screenshot I can maybe figure out what's wrong

5) yeah, those plasma twisters require exact timing and do 40 vscroll updates per line; you can tell that timing is off by black horizontal lines crossing the image

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Wed Apr 26, 2017 6:48 pm

Kabuto wrote:3) yeah, this part requires halfway precise timing (but it's actually kinda relaxed since this routine also has to account for cycles stolen by the Z80)
The per-line update code doesn't seem so bad. I imagine writing it was a pain, since it seems to have strategic nops inserted to avoid having the 68K frozen via DTACK due to a full FIFO (which would presumably be bad for the code running on the Z80), but it seems like timing in an emulator could be pretty far off and it would still generally work. In BlastEm at least, the problem with this scene seems to be that a link field is getting messed up somewhere, probably on sprite 0 (sprite list jumps from 0 to 56 or something like that). I haven't had a chance to investigate why that's happening though. Could be some interaction between timing of writes making their way through the FIFO and changes to the SAT address, but that's just a wild guess.

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

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

Post by Kabuto » Wed Apr 26, 2017 11:05 pm

Yes, this code does indeed try to avoid FIFO stalls so the Z80 would not be halted when trying to prefetch.

Actually, getting the timing right was not that difficult, I just adjusted NOPs until I got no more FIFO stalls (measured indirectly because FIFO stalls stabilise the timing on screen as measured by generating a column by changing background colour). What was more difficult was taming the sprite logic; both phase 1 (visibility check) and phase 2 (which row to render) had to give correct results. The code assumes all sprite Y writes to occur between phase 1 and 2. Only 8 sprites are visible on a row and as I noted in the doc for phase 2 "If there are less than 20 ones visible then they're checked late" there is plenty of time before the VDP re-evaluates sprite Y in phase 2. If you don't re-evaluate sprite Y then every 28th line will be glitched.

But "completely broken" sounds like there might be a timing problem of some kind...

The link field of sprite 0 is set to 56 initially on purpose right at the start of the frame, and decremented by 8 after every 28 raster lines (but on the last step only decremented by 7 instead of 8 so it becomes 1 in the end).

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Thu Apr 27, 2017 1:10 am

Kabuto wrote:The code assumes all sprite Y writes to occur between phase 1 and 2. Only 8 sprites are visible on a row and as I noted in the doc for phase 2 "If there are less than 20 ones visible then they're checked late" there is plenty of time before the VDP re-evaluates sprite Y in phase 2. If you don't re-evaluate sprite Y then every 28th line will be glitched.
Ah, I see what you mean. I may need to make some minor tweaks to my phase 2 implementation, but what I'm seeing presently is much worse than a glitched line every 28 lines.
Kabuto wrote:But "completely broken" sounds like there might be a timing problem of some kind...

The link field of sprite 0 is set to 56 initially on purpose right at the start of the frame, and decremented by 8 after every 28 raster lines (but on the last step only decremented by 7 instead of 8 so it becomes 1 in the end).
From your description and what I've seen in my initial investigation, it sounds like my main problem is that the mid screen link field update is not working for some reason. Probably some bad interaction with the mid-screen SAT base address updates. Knowing that it's supposed to start at 56 will be very helpful in narrowing down the problem.

EDIT: Yep, first write after the vcounter change misses the first external slot that occurs shortly after HSYNC. This results in the second half of the word updating the size/link word of sprite 0 to occur after the change to the SAT address that occurs after the next vcounter change. So either 1) The first write should be making that early slot 2) SAT cache updates are done as a whole word when the first byte is written 3) Both.

EDIT 2: Counting cycles, it looks like it has to be 2). Even ignoring refresh and Z80 cycle stealing, the worst case timing between the vcounter change and the first write is something like 62 M68K cycles (434 master clock cycles). This is a bit over 27 slots and there's only 21 slots (maybe 22 if I've got my accounting off, hv counter updates at sort of a weird point in the memory access cycle) between the line change and that early access slot. On top of that, there is a minimum latency between when a word is written to the FIFO and when it's written to VRAM (I believe this to be 3 slots based on the pixel doubling pattern in direct color DMA demos).

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

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

Post by Kabuto » Thu Apr 27, 2017 12:26 pm

Another possible issue: subsequent link field writes are done shortly before the sprite table address is changed. If this word is emulated to be written out too late then your emulated VDP might see it as not being written to the current sprite table as its address will have changed by then. As a result there will be parts of the cube missing (big black bars across the image).

EDIT: judging from your twitter screenshots it looks like you might not be emulating invalid plane size 0x22 correctly, it's supposed to result in a 32x1 tile plane which I use a lot to get rid of planes when I don't need them

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Thu Apr 27, 2017 6:06 pm

Kabuto wrote:EDIT: judging from your twitter screenshots it looks like you might not be emulating invalid plane size 0x22 correctly, it's supposed to result in a 32x1 tile plane which I use a lot to get rid of planes when I don't need them
You are indeed correct. Specifically my handling of an invalid horizontal size was wrong. I think I screwed it up when I was fixing The Incredible Hulk which uses an invalid vertical size. I made a reasonable guess as to what was actually happening (using the size bits as the upper two bits of a mask) that seems to have been incorrect, at least for the horizontal size. I've been meaning to do some proper tests (though I'm sure someone else already has at some point), but it's good to have another data point.

On an unrelated note, I was looking back at some of my old logic analyzer captures and I can answer at least one minor unknown you mentioned in your doc. In Phase 2, unneeded slots seem to read data for sprite 0. Can't say for sure that happens in all cases as it seems the only captures I had available were ones that had no visible sprites.

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

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

Post by Kabuto » Thu Apr 27, 2017 8:31 pm

Mask of Destiny wrote:I've been meaning to do some proper tests (though I'm sure someone else already has at some point), but it's good to have another data point.
IIRC invalid horizontal size always gives you 32x1, invalid vertical size with valid horizontal size will behave as if vertical size was set to 32.
Mask of Destiny wrote:On an unrelated note, I was looking back at some of my old logic analyzer captures and I can answer at least one minor unknown you mentioned in your doc. In Phase 2, unneeded slots seem to read data for sprite 0. Can't say for sure that happens in all cases as it seems the only captures I had available were ones that had no visible sprites.
Thanks, will add this

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Thu Apr 27, 2017 8:54 pm

Kabuto wrote:invalid vertical size with valid horizontal size will behave as if vertical size was set to 32.
I have a hunch that it actually gives you a weird setup that looks like it's 32 high, but actually has 64 distinct rows with some duplication. Specifically I think you'll get: 0-31, 0-31, 64-95, 64-95. The reason I think this is that unlike horizontal size which is a bit more complicated, vertical size is effectively just a mask. Using the size bits as an AND mask gives the correct values for the valid sizes and gives the above values for the invalid size. I could very well be wrong, but it's the kind of thing that's easy enough to miss when testing if you're not looking for it and it seems like the most logical hardware implementation.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

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

Post by TmEE co.(TM) » Fri Apr 28, 2017 11:22 am

There is no mirroring effect going on when the width is 64 tiles, only the first 32 rows get used, when the width is 32 tiles it does produce the mirroring effect, 0...31, 0...31, 64...95, 64...95.

EDIT : I tested out all combinations :

Code: Select all

H  V
00 00 - 32x32
00 01 - 32x64
00 10 - See above
00 11 - 32x128
01 00 - 64x32
01 01 - 64x64
01 10 - 64x32
01 11 - 64x64
10 00 - 32x1
10 01 - 32x1
10 10 - 32x1
10 11 - 32x1
11 00 - 128x32
11 01 - 128x32
11 10 - 128x32
11 11 - 128x32
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

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Fri Apr 28, 2017 5:44 pm

TmEE co.(TM) wrote:There is no mirroring effect going on when the width is 64 tiles, only the first 32 rows get used
Well that makes sense. The top 3 address bits are always fixed to the value from the appropriate register. 128x64 will give you 128x32 and 64x128 will give you 64x64 for the same reason.

Thanks for doing all that testing!

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Fri Apr 28, 2017 5:53 pm

Yeah tilemaps get limited to 8KB.

Also d'oh, just realized that horizontal size is more complicated than vertical size because bit shifting is involved (to get the correct address for each row). So horizontal size is likely AND mask in addition to some bit shift going wrong (which is probably how it just ends up as 32x1).
Sik is pronounced as "seek", not as "sick".

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

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

Post by Eke » Sat Apr 29, 2017 8:03 am

Kabuto wrote:1) no per column vscroll changes here, just per rasterline vscroll changes in the zoomer, no vscroll changes at all when it twists
Strange. This is what I got, not sure where this comes from .
overdrive-1.jpg
overdrive-1.jpg (24.33 KiB) Viewed 17608 times
Also got similar weird vertical jitter on those voronoi circles
overdrive-8.jpg
overdrive-8.jpg (21.62 KiB) Viewed 17608 times
Kabuto wrote: 4) we call them voronoi circles. If you show me a screenshot I can maybe figure out what's wrong
Vertical lines across the screen at the end of transition (disappear before the end of effect)
overdrive-7.jpg
overdrive-7.jpg (28.7 KiB) Viewed 17608 times
Again, I still haven't tried to figure what cause this exactly.

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

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

Post by Kabuto » Sat Apr 29, 2017 8:47 am

Eke wrote:Strange. This is what I got, not sure where this comes from...
This looks like you still need to invert address bit 0 after converting the target address for 128k mode emulation.

No idea what causes the vertical stripes in the 3rd pic, though, incorrectly emulated illegal plane modes maybe?

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

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

Post by Eke » Sat Apr 29, 2017 12:07 pm

Kabuto wrote: This looks like you still need to invert address bit 0 after converting the target address for 128k mode emulation.
Off course you are right, totally forgot about that. The textured cubes scene also look much less broken now...
overdrive-6-1.jpg
overdrive-6-1.jpg (20.26 KiB) Viewed 17592 times
overdrive-6-2.jpg
overdrive-6-2.jpg (19.68 KiB) Viewed 17592 times
overdrive-6-3.jpg
overdrive-6-3.jpg (19.07 KiB) Viewed 17592 times

Post Reply