Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Listing common inaccuracies in SMS/GG emulators

Reply to topic
Author Message
  • Joined: 05 Dec 2019
  • Posts: 24
Reply with quote
Listing common inaccuracies in SMS/GG emulators
Post Posted: Fri Nov 13, 2020 3:00 pm
I'm considering making a multi-aspect test ROM with a list of several dozen common problems in SMS emulation. I'd like them to range from common errors in 1990s-era or "college project"-grade emulators up through some cycle accuracy things that MEKA, BlastEm, and Emulicious only recently got right (or have yet to get right). I'd prefer where some notable emulator version gets it wrong and some other free or freeware emulator gets it right. If we could come up with 100 tests from easy through hard, that'd be perfect.

Now the gimmick of this test ROM is that it can also run as a "game", a (simple) platformer where a character runs around and collects coins. Every time you touch a coin, it runs one of the tests. If it passes, you collect the coin, and if it fails, the coin just stops spinning and you can press Up to view technical details about what failed.

I asked about this on Discord, and Maxim reminded me that many inaccuracies are not visible to the CPU, instead "requiring visual checks to determine the result." These would need to be put in a separate visual test ROM. The Game Boy emulation scene solves this by specifying on which frames to screenshot and compare to a PNG of the expected results. There's a GB test analogous to the HTML/CSS Acid2 test, for instance.

Examples of what I'd consider easy tests:
  • Reading the VDP status register twice in a row clears or doesn't clear certain flags
  • Correct number of cycles per scanline and scanlines per frame
  • daa (BCD adjustment) works/doesn't work for valid inputs


Examples of harder tests:
  • daa works/doesn't work for invalid starting conditions (A-F nibbles in particular)
  • Cycle-accurate interaction between writing to SAT and VDP reading SAT
  • Open bus behavior
  • Writing too fast to the VDP
  • Behaviors that differ among SMS, GG, and MD: all need to be SMS-like, all need to be GG-like, or all need to be MD-like
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8249
  • Location: Paris, France
Reply with quote
Post Posted: Fri Nov 13, 2020 4:03 pm
This is a good idea, but out of curiosity, have you seen the existing SMS VDP Test ?
https://www.smspower.org/Homebrew/SMSVDPTest-SMS
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Fri Nov 13, 2020 6:35 pm
Testing sound is similarly difficult. Here’s some common inaccuracies...

* Noise bit pattern is correct
* Power on state is not correct (some variants default to making sound)
* Behaviour on register writes, eg writing a “latched” volume, repeated latched updates
* Aliasing caused by bad resampling to the emulated sampling rate
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Fri Nov 13, 2020 6:38 pm
I think one common inaccuracy is the emulation of whole opcodes instead of cycle-timed within opcodes, and also even emulating a line at a time (a common speed up technique in older emulators).

Some emulators also have incorrect cycle counts for some instructions, especially the undocumented ones.

Similarly the emulation of the undocumented flags and hidden registers of the Z80. Many older emulators won’t pass ZEXALL.

Many old emulators don’t emulate port $3E.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 138
Reply with quote
Post Posted: Fri Nov 13, 2020 8:45 pm
I have full datasets of many z80 opcodes as executed on a real console, DAA included if I remember correctly. I can send them your way.

Edit:
Dataset here. No DAA, but I may make one just for completion sake.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Dec 2019
  • Posts: 24
Reply with quote
Post Posted: Fri Nov 13, 2020 9:54 pm
SMS VDP Test could be useful as a reference. Some of its tests rely on visual inspection, and those would fit into a screenshot-based framework rather than this one.

Per VDPTest-ReadMe.txt, it depends on a CPU that passes ZEXDOC and has correct cycles per instruction. ZEXDOC, a variant of ZEXALL that ignores flags with officially unspecified values, takes four hours according to "Using Z80 Instruction Exerciser (Zexall/ /Zexdoc)" by Jeff Avery. It takes this long because it exhaustively steps through certain states of the registers. I had planned to assume that instructions needed to run the easier games just work because practically all emulators get them right. Then for each semi-problematic instruction, I'd choose a few representative corner cases that would predict whether it's likely to behave well on the cases in between, with each test ideally taking no more than a frame or two.

As for sound, none of that is CPU-measurable, so the only sound would be game sounds. Incidentally, I've been working with 240p Test Suite developer Artemio Urbina on a multi-platform sound test called MDFourier. In addition to resampling quality, it tests a bunch of behavior edge cases, such as "latched" volume and "latched" noise type, as well as Game Gear volume crossfades. The Game Boy version of MDFourier is particularly brutal to mGBA's resampler.

So the process for designing this test would look like this:

  1. Find Z80 instructions that notable emulators get subtly or completely wrong, even if they can run some of the "easier" games, and write tests for them. Probably split daa into two to four tests, for example. Is there a list of tricky instructions?
  2. An early test will be 228 CPU cycles per scanline, as most of the VDP stuff relies on it. I guess use instructions with different inherent cycle counts.
  3. Choose some bits and pieces of SMS VDP Test to rewrite.
  4. Order them by difficulty compared to how many games rely on each quirk or how many homebrew games end up broken because they incorrectly rely on the system not having each quirk. This would be a big subjective part.


Now why do I want to structure this as a game?

  1. A chance to learn SMS game programming, particularly to see if registers IX and IY are as necessary as I'd thought.
  2. While some emulator developers endeavor to get every test ROM right, others prefer to prioritize their time on getting "actual games" working. If we can turn emulator testing into a game, we can file bugs against emulators on that game.
  3. I like puns, and the mechanic of collecting coins feeds into a pun on one well-known brand name of heavily speed-optimized emulators written in i386 assembly language and intended for use on severely underpowered (e.g. 486DX2/66) PCs. This doesn't include an SMS emulator quite yet, though it does include an MSX emulator, and I imagine at least some of the tests would carry over.
  4. All of the above.


I guess one thing I could do is make the game framework first, with a bunch of trivial tests (always pass, always fail, etc.) that can be replaced once we decide on a set of things to test.
testgamecoin.gif (13.54 KB)
I've been coming up with graphics for the game part. Click to view spinning coin
testgamecoin.gif

  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Fri Nov 13, 2020 10:56 pm
ZEXALL for SMS is something I have spent a bunch of time on over the years. It tries (semi-successfully) to iterate over the entire state of many opcodes and CRCs the state after each one, which means a very large problem state some of the time. However practically for an emulator, it is indeed the edge cases that are likely to be more tricky.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 561
Reply with quote
Post Posted: Sat Nov 14, 2020 7:17 am
PinoBatch wrote
A chance to learn SMS game programming, particularly to see if registers IX and IY are as necessary as I'd thought.


While I can't contribute to the emulator test topic, I can comment on this one. My first homebrew game (probably the second one too, I don't know offhand) actually never used IX and IY, so obviously you can get away fine without them. I wouldn't necessarily recommend it, though.

I love the sprites in your mockup. The tree might need some more work still.
  View user's profile Send private message
  • Joined: 16 May 2002
  • Posts: 1183
  • Location: italy
Reply with quote
Post Posted: Sat Nov 14, 2020 2:53 pm
Maxim wrote
Testing sound is similarly difficult.
On a semi-related topic, I'd be curious to know why anything made with psglib doesn't sound right in Dega.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Sat Nov 14, 2020 2:58 pm
Dega just has the worst PSG emulation possible, equivalent to nearest-neighbour resampling causing tone aliasing. This is more noticeable at higher frequencies, eg Aztec Adventure music. It shouldn’t be related to PSGLib though, it should sound the same regardless of the playback engine.
  View user's profile Send private message Visit poster's website
  • Joined: 16 May 2002
  • Posts: 1183
  • Location: italy
Reply with quote
Post Posted: Sat Nov 14, 2020 6:31 pm
Indeed, it should, but it doesn't, that's precisely what made me curious, and that's why I mentioned it. Everything else (e.g. official games) sounds "acceptable", even if it's inaccurate, but whenever I try something based on psglib, it just sounds wrong, and you know I like to work with music, I can tell inaccurate from plain wrong. Dega must be doing something else wrong, but I apologise if I went outside of the scope of this topic. It's just something I've been wondering for a while now and I thought to take this chance to bring it up.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Sat Nov 14, 2020 7:20 pm
It would be interesting to see some examples (we can split the thread). One possibility is that Dega relies on some redundancy in sound engine behaviour that is absent in the minimised PSGlib stream. For example, vibrato might use a single-byte tone update for space saving, which Dega might effectively ignore.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Nov 2020
  • Posts: 3
  • Location: Gensokyo
Reply with quote
Post Posted: Sun Nov 15, 2020 12:17 am
I haven't played many SMS/GG Emulators outside of the designated core on RetroArch and Kega Fusion... and a SMS Emulator for GBA for the hell of it so I can't tell many differences.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Sun Nov 15, 2020 10:08 am
On with the inaccuracies. Many emulators do not support mid-frame changes of certain things:

* Disable/enable hiding left 8 pixels - used only by Game de Check!
* Switch video mode - only done by some unreleased homebrew
* Change sprite table address (not sure if any games do this for status bars?)

The rendering of the leftmost 8 pixels when not hidden and with non-zero fine scrolling (i.e. scrollx % 8 != 0) is never seen in a game.

I suspect many emulators don't bother putting the collided sprite index into the status register's low bits.

Some emulators may not correctly handle mirroring of ROM, e.g. a 32KB ROM will have its low 16KB appear in the 32-48KB range.

Some emulators do not handle non-power-of-two ROM sizes, or non-multiple-of-16KB ROM sizes. Arguably the latter is somewhat undefined anyway. I remember at least one crashing when given certain ROM sizes.

Some of the VDP register bits act as masks to table addresses, and as such it's important to set them to 1, mostly. Some emulators don't emulate this.

Some bugs/differences in variants of the VDP are not emulated, or are enabled only by checksum matches. For example, the name table mirroring needed for Ys (JP), the incorrect 2x scaled sprites on older VDP variants, the availability of the extra-height modes in later VDPs. As these differences are genuine, you may not want to rely on any of them; or you could call it a bug to have an inconsistent set of them.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 640
  • Location: Spain
Reply with quote
Post Posted: Sun Nov 15, 2020 2:01 pm
Maxim wrote

* Change sprite table address (not sure if any games do this for status bars?)



We're just discussing that couple of days ago, and seems Alien 3 uses two different SATs:
https://www.elotrolado.net/hilo_hilo-oficial-dossier-completo-de-sega-master-system_2197710_s200#p1750408404
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13435
  • Location: London
Reply with quote
Post Posted: Sun Nov 15, 2020 3:35 pm
Interesting, it seems like they could have managed with one if they redefined the status sprites mid-screen. I guess the goal is to get slightly more sprites on screen. It looks like it does the status sprites, the Ripley, then assigns the remaining slots based on the y position of each entity. On a busier screen both tables will be fuller.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Oct 2008
  • Posts: 357
Reply with quote
Post Posted: Sun Nov 15, 2020 4:50 pm
Maxim wrote

Some bugs/differences in variants of the VDP are not emulated, or are enabled only by checksum matches. For example, the name table mirroring needed for Ys (JP), the incorrect 2x scaled sprites on older VDP variants, the availability of the extra-height modes in later VDPs. As these differences are genuine, you may not want to rely on any of them; or you could call it a bug to have an inconsistent set of them.


Would it then be a fix to have an option to choose the hardware model to emulate?
I do remember other consoles having similar inconsistencies in hardware, such as SNES hardware bugs in earlier consoles, or it sounds like Genesis sound emulation (different chip variants used in different hardware revisions, so I hear developers shifted focus to the newer one in later games?)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2790
Reply with quote
Post Posted: Mon Nov 16, 2020 10:26 am
Maxim wrote
One possibility is that Dega relies on some redundancy in sound engine behaviour that is absent in the minimised PSGlib stream. For example, vibrato might use a single-byte tone update for space saving, which Dega might effectively ignore.


I confirm PSGlib does that (updates only one part of the F-register for a channel, if the other half stays the same) and this is likely to sound totally wrong on emulators that doesn't emulate the PSG chip correctly.
  View user's profile Send private message Visit poster's website
  • Joined: 16 May 2002
  • Posts: 1183
  • Location: italy
Reply with quote
Post Posted: Wed Nov 25, 2020 2:43 am
Another Dega quirk is that the diving event in Olympic Gold is broken. It might be broken in other emulators too, since there is at least another video on Youtube in which you can see that behaviour, but they didn't specify the emulator they used. For what it's worth, it does work in Fusion, though.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!