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: 26
Joined: Sun Aug 25, 2013 6:56 pm

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

Postby 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: 512
Joined: Thu Nov 30, 2006 6:30 am

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

Postby 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: 803
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

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

Postby 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 277 times
overdrive-6-1-new.jpg
overdrive-6-1-new.jpg (19.44 KiB) Viewed 277 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: 512
Joined: Thu Nov 30, 2006 6:30 am

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

Postby 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: 803
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

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

Postby 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 151 times


Return to “Video Display Processor”

Who is online

Users browsing this forum: No registered users and 1 guest