Titan's Mega Drive tech docs including Debug Register

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

Moderators: BigEvilCorporation, Mask of Destiny

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 12:52 pm

Cool :)

Regarding those remaining glitches, please check what I wrote here about re-fetching of sprite Y coord and size:
viewtopic.php?f=22&t=2604&start=15#p31287

Looks like it affects your emulator as well

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 » Sat Apr 29, 2017 7:25 pm

Kabuto wrote:No idea what causes the vertical stripes in the 3rd pic, though, incorrectly emulated illegal plane modes maybe?
BlastEm had these too and I believe fixing that is what got rid of them.
Kabuto wrote:Regarding those remaining glitches, please check what I wrote here about re-fetching of sprite Y coord and size:
The bit about masking the calculated tile row is also important here, though only after re-fetching the Y coordinate works of course. Threw me off a bit at first because the artifacts look somewhat similar in that there are periodic glitched lines, but the re-fetching issue has glitched lines in a fixed position on the screen whereas the latter has them mapped to the surface of the cube/prisms.

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 » Sun Apr 30, 2017 7:55 am

Mask of Destiny wrote:
Kabuto wrote:No idea what causes the vertical stripes in the 3rd pic, though, incorrectly emulated illegal plane modes maybe?
BlastEm had these too and I believe fixing that is what got rid of them.
Yes,that was it. Genesis Plus correctly emulated all illegal plane sizes except two ("10 10" and "10 11" in above list) where the row index was not completely masked as it should (which indeed results in 32x1 plane size). Using a different row index shift value for computing VRAM base address (14 instead of 0 in current implementation) indeed fixed that issue.

Mask of Destiny wrote:
Kabuto wrote:Regarding those remaining glitches, please check what I wrote here about re-fetching of sprite Y coord and size:
The bit about masking the calculated tile row is also important here, though only after re-fetching the Y coordinate works of course. Threw me off a bit at first because the artifacts look somewhat similar in that there are periodic glitched lines, but the re-fetching issue has glitched lines in a fixed position on the screen whereas the latter has them mapped to the surface of the cube/prisms.
Re-fetching next line active sprite attributes when SAT is written mid-line improved this a bit but I still have some (but different) errors, although the 5-bit row masking should be correct: (line-ypos) & 0x1F
overdrive-6-4.jpg
overdrive-6-4.jpg (23.11 KiB) Viewed 11784 times
overdrive-6-1-new.jpg
overdrive-6-1-new.jpg (19.44 KiB) Viewed 11784 times
I am doing it in a naive way though (re-fetch all found sprites attributes if writes happen after phase 1 and before the start of phase 2, based on the number of active sprites found during phase 1)

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 » Mon May 01, 2017 7:39 pm

Eke wrote:I am doing it in a naive way though (re-fetch all found sprites attributes if writes happen after phase 1 and before the start of phase 2, based on the number of active sprites found during phase 1)
Are you preserving the list of sprites determined to be on the current line when you do the re-fetch (sounds like maybe that's what you are doing, but it's not 100% clear)? Correct rendering relies on sprites showing on a line based on the old Y value even though the new Y value would cause them to not be displayed on the current line.

Also, this is probably overly pedantic and perhaps already obvious, but the writes technically happen during phase 2 not between the phases. They just manage to stay ahead of when an individual sprite is evaluated through a combination of the unused slots being pushed to the front and the used slots being evaluated in sprite list order. For that reason, you'll probably want to do that re-evaluation fairly late in the line if that is not already the case.

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 May 02, 2017 12:50 pm

Mask of Destiny wrote: Are you preserving the list of sprites determined to be on the current line when you do the re-fetch (sounds like maybe that's what you are doing, but it's not 100% clear)? Correct rendering relies on sprites showing on a line based on the old Y value even though the new Y value would cause them to not be displayed on the current line.
Yes, the link value of active sprites is now saved during the sprite "parsing" phase (which, in Genesis Plus - and most line-based emulators - does visible sprite detection and all attributes fetch in a single phase) then, if SAT is modified by VRAM write before the end of the line (or more correctly before active sprite attributes have been evaluated), all attributes are simply fetched again (from internal cache and VRAM).
Mask of Destiny wrote:Also, this is probably overly pedantic and perhaps already obvious, but the writes technically happen during phase 2 not between the phases. They just manage to stay ahead of when an individual sprite is evaluated through a combination of the unused slots being pushed to the front and the used slots being evaluated in sprite list order. For that reason, you'll probably want to do that re-evaluation fairly late in the line if that is not already the case.
Yes, by "start of phase 2" I meant the time when the first active sprite for the upcoming line is being evaluated (which would indeed correspond to the end of phase 1 if there were 20 active sprites), this was in reference to Kabuto's post indicating the writes should occur "between " phase 1 and phase 2.

My problem is probably a timing issue since that part not only seem to modify Y values mid-line but also update link values mid-frame.

EDIT: It was actually a stupid code mistake, i was only refetching the first sprite, whole scene is ok now
overdrive-6-2-new.jpg
overdrive-6-2-new.jpg (19.73 KiB) Viewed 11658 times

Morden
Interested
Posts: 33
Joined: Wed Aug 31, 2011 11:30 am

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

Post by Morden » Mon May 29, 2017 7:52 pm

For years my go to emulator for Sega's stuff has been Fusion 3.64, but since the homebrew scene seems to be about breaking all emulation in an and all ways possible, what's the best alternative right now? I'm looking for something simple so I can grab an occasional screenshot every now and then, and if it can run Overdrive II, that's even better. Sorry for posting in this topic, but I figured maybe Eke could point me towards a Win build of Genesis Plus GX? All I found was the plugin, unless that's all there is to find.

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 May 31, 2017 12:27 am

The easiest way to run Genesis Plus GX on Windows is probably to use the Genesis Plus GX core in Retroarch. There is code in the repo for making a basic SDL build. I've had audio sync issues with that build when run under Linux (not sure how it does on Windows), but it might be sufficient if you just want to take some screenshots. That said, I don't think Eke has pushed any of his changes to support Overdrive 2 to the public repo yet.

If you're looking for something that can run Overdrive II now, the recent nightly builds of my emulator, BlastEm, can run it near perfectly. The only known issues at this point are that there are some CRAM dots in the horizontal border that shouldn't be there during the tunnel scene and line -1 is rendered incorrectly in the "fractal rotozoomer" and "disco floor" scenes.

Post Reply