Titan's Mega Drive tech docs including Debug Register

[Kabuto]

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]

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.

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]

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.

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 (23.11 KiB) Viewed 21053 times

overdrive-6-1-new.jpg (19.44 KiB) Viewed 21053 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]

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]

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

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 (19.73 KiB) Viewed 20927 times

[Morden]

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]

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.