Sonic and Sega Retro Message Board: Need testers for Gens and Gens/GS ROM compatibility - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

Need testers for Gens and Gens/GS ROM compatibility

#16 User is offline GerbilSoft 

Posted 05 September 2015 - 03:22 PM

  • RickRotate'd.
  • Posts: 2806
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin
Today's update: I've done a ton of changes in the past month or so, though most of them have been low-level and not directly related to the main blockers. (Mostly due to boredom.) Among other things, the Paused Effect is now MMX and SSE2-optimized, and the Fast Blur effect is SSE2-optimized for 32-bit color. gens-sdl also has an ARB fragment program version of the Fast Blur effect, ported from gens-qt4. Both of these effects also have test suites to ensure they work correctly.

There's also MMX- and SSE2-optimized byteswapping code, which is used quite a bit when loading ROMs and loading/saving savestates.

Other changes include some Win32 compatibility improvements (use of "\\?\" for long filenames on NT-based systems) and the use of popt for command line parsing.

The major blockers right now other than packaging:
  • Sega Pico pen support.
  • Fix a DMA regression caused by attempting to fix test failures in VDPFIFOTesting. The DMA subsystem needs a complete rewrite, which isn't doable at this point, so I just want to get it working back to how it was in Gens/GS r7.

I'm planning on releasing Gens/GS II Technical Preview 1 sometime this month. Hopefully I can get it all done.
This post has been edited by GerbilSoft: 05 September 2015 - 03:25 PM
Reason for edit: +popt

#17 User is offline GerbilSoft 

Posted 21 September 2015 - 09:55 AM

  • RickRotate'd.
  • Posts: 2806
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin
zomg, an update.

A minor shadow/highlight bug was pointed out to me by flamewing and Jorge. In a nutshell: the shadow/highlight sprite operators (palette colors $3E and $3F) don't just mask the sprite they're in; they mask all lower-priority sprites on the same pixel. (Not 100% positive about higher-priority sprites, but I assume those take precedence.)

Left = before, right = after. (Confirmed on Kega, Regen, and hardware.)

Posted Image Posted Image

Posted Image Posted Image

I'll probably add an automated test case for this later to ensure that it doesn't accidentally get reverted.

#18 User is offline flamewing 

Posted 21 September 2015 - 10:28 AM

  • Emerald Hunter
  • Posts: 1115
  • Joined: 11-October 10
  • Gender:Male
  • Location:🇫🇷 France
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12

View PostGerbilSoft, on 21 September 2015 - 09:55 AM, said:

A minor shadow/highlight bug was pointed out to me by flamewing and Jorge. In a nutshell: the shadow/highlight sprite operators (palette colors $3E and $3F) don't just mask the sprite they're in; they mask all lower-priority sprites on the same pixel. (Not 100% positive about higher-priority sprites, but I assume those take precedence.)

High priority actually makes no difference; the only thing that actually matters is which sprite gets drawn first. If the sprite with the operator is drawn before, it masks sprites that come latter; if a sprite gets drawn before the operator, it masks the operator instead.

The ROMs I sent you actually tests this too; so matching the image from Kega/Regen/Real hardware means it is correctly implemented.

#19 User is offline GerbilSoft 

Posted 21 September 2015 - 11:15 AM

  • RickRotate'd.
  • Posts: 2806
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin

View Postflamewing, on 21 September 2015 - 10:28 AM, said:

High priority actually makes no difference; the only thing that actually matters is which sprite gets drawn first. If the sprite with the operator is drawn before, it masks sprites that come latter; if a sprite gets drawn before the operator, it masks the operator instead.

The ROMs I sent you actually tests this too; so matching the image from Kega/Regen/Real hardware means it is correctly implemented.

That's what I meant by high priority. Link priority, not plane priority. (It's a bit confusing because the same term refers to different things. :v:)

I was wondering whether or not the test ROM handled that, so that's a good thing. (I compared it to Kega Fusion 3.63x and the "after" images matched.)
This post has been edited by GerbilSoft: 21 September 2015 - 11:21 AM

#20 User is offline flamewing 

Posted 21 September 2015 - 11:47 AM

  • Emerald Hunter
  • Posts: 1115
  • Joined: 11-October 10
  • Gender:Male
  • Location:🇫🇷 France
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12
For future reference, the images generated by the ROMs go like this:
Row 1: no operator sprites, alternating low and high priority, each pair of sprites come from a different palette line. The purpose of this is to test abnormal rendering of colors in sprites on Shadow/Highlight mode. Basically, confirmation that only color 14 is abnormal. The last two sprites use palette line 3, hence they have 2 operator blocks each.

Rows 2 and 3: as above, but all non-operator sprites are covered by low priority shadow operators that come before them in link order. Split in two lines due to sprite pixels per line limit.

Rows 4 and 5: as above, but shadow operators are high priority.

Rows 6-9: as rows 2-5, but with highlight operator instead.

Row 10: Alternating priority on both highlight operators and sprites, sprites come before operators in link order. Only 4 of them because of 80 sprites total limit.

Now that I think of it, the last row is actually bugged and the alternating high and low priorities should behave differently for sprites and operators. Oh, well...

#21 User is offline GerbilSoft 

Posted 07 October 2015 - 09:35 AM

  • RickRotate'd.
  • Posts: 2806
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin
I haven't posted here in a few weeks, so here's a short update.

Major blockers for Tech Preview 1:
  • Fix DMA regression in "The Adventures of Batman and Robin".
  • Implement Pico tablet emulation.
  • Implement onscreen FPS counter.
  • Add unit tests for shadow/highlight implementation.

Planned features for Tech Preview 2: (SMS/GG only build)
  • Switch to libarchive for compressed file handling.
  • Switch to CZ80, a much better Z80 emulator (and it's written in C so it's portable).
  • Start implementing support for Sega Master System and Game Gear. (VDP Mode 4, Z80 memory and I/O map.)
  • Rewrite the PSG to be cycle-accurate, and use Blip_Buffer for anti-aliasing.
  • Rewrite the VDP to be more accurate. (Fetch tile data based on the current cycle number using VRAM timing diagrams available on SMS Power.) SMS mode doesn't have DMA, so this is why I'm going to rewrite it for SMS instead of starting the rewrite for MD. It'll eventually be extended to MD, at which point the old MD code will be removed.

Other planned features for later:
  • New MDP host services library, libmdphost. This will handle a bunch of the repetitive MDP host services, e.g. 8-bit/16-bit/32-bit block read/write, so I can write them once and anyone can use them in any emulator.
  • Port the new emulation loop to the Qt UI.
  • Reimplement MDP, and add some features necessary for a few plugins in MDP 1.1. (Among other things, HBlank and VBlank handlers in addition to "frame finished".)
  • Switch the 68000 emulator to Musashi. Musashi is used by Regen and Genesis Plus GX, among others. Some features supported by Musashi not supported by the current emulator include Address Error and proper prefetch emulation.

EDIT: I can't seem to find the Mode 4 timing diagram on SMS Power. I'm pretty sure there was one somewhere. Does anyone know where it is? SMS Power does have a TMS9918 diagram, though some parts seem inconsistent (compare the individual sprite accesses to the combined sprite accesses): http://www.smspower....erTimingDiagram
This post has been edited by GerbilSoft: 07 October 2015 - 10:48 AM
Reason for edit: +timing diagram...

#22 User is offline GerbilSoft 

Posted 08 November 2015 - 09:19 PM

  • RickRotate'd.
  • Posts: 2806
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin
So I was reading through the old genvdp.txt document, and found a note that "The Adventures of Batman & Robin" writes past CRAM address 0x80 (using DMA), and the emulator needs to ignore this in order for the game to work. This contradicts VDPFIFOTesting, but interestingly enough, ignoring those writes fixes the game. I suspect the real problem is DMA timing in general, so the whole thing needs to be reworked in order to really fix it. For now, I simply applied a hack to ignore CRAM writes over 0x80.

Now, wouldn't it be nice if I finished up the rest of the stuff and had Tech Preview 1 out for Sonic 2sday? :)/>
This post has been edited by GerbilSoft: 08 November 2015 - 09:40 PM
Reason for edit: +DMA

  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users