|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
Listing common inaccuracies in SMS/GG emulators
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:
Examples of harder tests:
|
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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:
Now why do I want to structure this as a game?
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. |
|
|
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. | |
|
Posted: Sat Nov 14, 2020 7:17 am |
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. |
|
|
Posted: Sat Nov 14, 2020 2:53 pm |
On a semi-related topic, I'd be curious to know why anything made with psglib doesn't sound right in Dega. |
|
|
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. | |
|
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. | |
|
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. | |
|
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. | |
|
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. |
|
|
Posted: Sun Nov 15, 2020 2:01 pm |
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 |
|
|
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. | |
|
Posted: Sun Nov 15, 2020 4:50 pm |
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?) |
|
|
Posted: Mon Nov 16, 2020 10:26 am |
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. |
|
|
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. | |