Variant Detection Test
This test is a by-product of my work on a "universal-binary" game, that detects and uses the capabilities of the platform it is loaded into.
Download: Variant Detection Test v1.4 (Source, needs Chiplet to build)
It currently tries to detect the following variants:
- CHIP-8
- CHIP-8 TPD *
- CHIP-8 FPD *
- CHIP-8E
- CHIP-8x *
- CHIP-8x TPD *
- CHIP-8x FPD *
- CHIP-10
- CHIP-48
- SUPER-CHIP 1.0 BETA
- SUPER-CHIP 1.0
- SUPER-CHIP 1.1
- SCHIP-MODERN
- RS-M8001 MC8
- MC8-MODERN
- XO-CHIP
*) These variants will only be shown by name but no quirks test is done.
For variants that use the start address of 0x200, the variant detection test also runs a set of quirks tests, similar to the tests in the CHIP-8 test suite quirks test, this test gives results on the most relevant quirks:
All quirks test outputs consist of the short name of the quirk in three letters, a detection result, and optional a conformance rating.
- The three letters are
VFR,MEM,SHF,JMP,DWTandWRP. See below for each quirk and the meaning. - The detection result varies from quirk to quirk, in its easiest form it is
+for an enabled quirk and-for a disabled one. A?shows an error in the implementation, but for some quirks the detection result or error can be one or two letters/digits to further help debugging. - The conformance rating gives either a checkmark if the detected behavior is correct for the detected variant, or an
xif not. In case of two letter/digit error reports no conformance rating is given and anxis implied to fit the screen space.
-
VFR+This implementation resets VF on AND/OR/XOR operations. -
VFR-This implementation keeps VF intact on AND/OR/XOR operations. -
VFR?This implementation behaves inconsistent over the operations, some reset VF, some don't.
On original CHIP-8 and a number of derived variants for the COSMAC VIP, the AND/OR/XOR operations reset VF to 0. This is a side effect from the way they are implemented together with the other math operations in group 8, apart from 8xy0. They are all based on generating a small subroutine on the stack (just two 1802 instructions) and executing it, then setting VF to the state of the 1802 flag register DF.
Most non-CDP1802 based variants do not implement this behavior for the AND/OR(XOR operations, and thus this became a quirk.
-
MEM0This implementation keeps the index registerIunchanged. -
MEMXThis implementation increments the index registerIbyx. -
MEM1This implementation increments the index registerIbyx+1. -
MEM?This implementation behaves either inconsistent or the increment could not be detected, so it's none of the above.
The original implementation CHIP-8 on the COSMAC VIP, and most on that platform, increment the index register on load/save operations by x+1, so the index register points to the first byte after the read/written bytes. When CHIP-48 on the HP-48SX was published, it
just incremented by x so the index register would point to the last byte read/written. This was kept in SuperCHIP v1.0, but changed in SuperCHIP v1.1 where no change of the index register happens at all. XO-CHIP went "back to the roots" and reimplemented the original behavior.
-
SHF+This implementation ignoresyand simply shiftsVxby one bit. -
SHF-This implementation setsVxtoVyand shifts that by one bit. -
SHF?This implementation inconsistently uses either method or shift is broken.
The original implementation CHIP-8 on the COSMAC VIP, and most on that platform, use the value from Vy to shift it and set the result to Vx and VF. The implementations on the HP-48SX stopped using Vy and just shifted Vx. Programmers that want to write portable
code that supports those variants and the original behavior use the shift opcodes always with the same register for Vx and Vy so it behaves the same on all of them.
-
JMP-This implementation jumps tonnn + V0. -
JMP+This implementation jumps toxnn + Vx. -
JMPRThis implementation implements CHIP-8E relative jumping, and is probably CHIP-8E. -
JMP?This implementation jumps tonnn + V0 + 0x200(that is RS-M8001 MegaChip behavior, any other wrong behavior will crash the test and can not be detected)
The original implementation CHIP-8 on the COSMAC VIP jumps to nnn + V0 making this a usable indexed jump feature, albeit its still rare use. When CHIP-48 on the HP-48SX was published, it
(probably, due to an error) jumped to nnn plus the register with the number of the most significant nibble of that address, so it was much harder to use as the register was depending on the base address. People basically stopped using it on CHIP-48/SuperCHIP. XO-CHIP brought
back the more useful original behavior.
-
DWT-This implementation doesn't wait at all. -
DWTLThis implementation limits drawing to one draw per frame in lores mode (64x32). -
DWTHThis implementation limits drawing to one draw per frame in hires mode (128x64). -
DWTBThis implementation limits drawing to one draw per frame in lores and hires mode (probably a bug). -
DWT?The behavior fits none of the above, surely a bug.
The original implementation CHIP-8 on the COSMAC VIP, and most on that platform, start a draw by waiting for the end of the frame interrupt, at the end of the visible pixel area. This is done to minimize tearing effects in animations. As the actual drawing of a bitmap could take longer than a screen, this technique was not perfect. CHIP-48 didn't have such an issue but as the CPU of the HP-48SX calculator was faster, it still limited the drawing to one operation per frame, to better mimic the original speed. With SuperCHIP, this behavior was only kept for the lores mode, and the extended or hires mode ran as fast as the calculator could. XO-CHIP doesn't wait by default, as modern games often pace by use of the delay timer, not by drawing limits.
-
WRP-This implementation doesn't wrap (apart from the initial coordinates). -
WRP+This implementation wraps initial coordinates and subsequent pixels of draws. -
WRPLThis implementation only wraps draws in lores (64x32), probably a bug. -
WRPHThis implementation only wraps draws in hires (128x64), probably a bug. -
WRPPThis is a HP-48SX SuperCHIP v1.1 behavior that doesn't wrap but has collision behavior counts rows collided and clipped on the bottom inVFinstead of just collisions leading toVF=1. -
WRPOLThis implementation doesn't wrap the origin on lores. -
WRPOHThis implementation doesn't wrap the origin on hires. -
WRPWLThis implementation has broken or inconsistent wrapping/clipping on lores. -
WRPWHThis implementation has broken or inconsistent wrapping/clipping on hires. -
WRP?The exact behavior could not be recognized or is none of the above.
NOTE: There is the special case of CHIP-10, which doesn't wrap or clip subsequent pixels but just draws them in the next line, ignoring boundaries. This gets a WRP? with a checkmark as it is the expected CHIP-10 behavior.
In CHIP-8 the main rule that is set is, that the origin of the Dxyn draw is wrapped. Besides that, the subsequent pixels drawn are clipped on most variants. Mainly XO-CHIP introduced wrapping as default, so sprite pixels wrap around the screen to the other side, same position on the non-wrapped axis. A bunch of new implementations get this wrong, so the test tries to help in detecting inconsistencies in regards to wrapping/clipping.
The following diagram tries to visualize the decision tree used to detect the various variants. It can help if the test doesn't detect the expected and configured variant in an emulator.
Sadly no results from real hardware yet, only an emulated VIP (in this case Cadmium).
The classic original interpreter developed for the COSMAC VIP by Joseph Weisbecker, 1977
128x64 CHIP-8 from #VIPER-V1-I7 and #IpsoFacto-I10, by Ben H. Hutchinson, Jr., 1979
CHIP-8 with two page display (64x64), from #VIPER-V1-I3, by Andy Modla and Jef Winsor, 1979
Note: As with all variants not loading to 0x200, this sadly doesn't have quirks checks active.
CHIP-8 with four page display (64x128), from #VIPER-V2-I6, by Tom Swan, 1980
Note: As with all variants not loading to 0x200, this sadly doesn't have quirks checks active.
CHIP-8 rewritten and extended by Gilles Detillieux, from #VIPER-V2-8+9, 1980
An official update to CHIP-8 by RCA, requiring the hardware extensions VP-590 and VP-595, 1980
Note: As with all variants not loading to 0x200, this sadly doesn't have quirks checks active.
A modified version of CHIP-8X to use two page display (64x64), from #VIPER-V4-I3, by by Andy Modle and Jef Winsor
Note: As with all variants not loading to 0x200, this sadly doesn't have quirks checks active.
A modified version of CHIP-8X for the four page display mode (64x128), from #VIPER-V4-I3, by Tom Swan, sadly not actually working as described due to an implementation bug
Note: As with all variants not loading to 0x200, this sadly doesn't have quirks checks active.
The accidental release of an early version of SuperCHIP-1.0 with Fx29 giving small and big font sprites.
The actual finished version v1.0 of SuperCHIP-1.0 about an hour later.
The updated version from a couple of days later, the most relevant SuperCHIP variant out there.
The original, first released MegaChip emulator by Revival Studios.
The (to my knowledge) second implementation of MegaChip by Ready4Next, closer to what the test names MC8-MODERN.
This is MC8-MODERN as implemented by Cadmium. Due to the lack of some details in the original specs and implementations, there is some leverage on how to fill the gaps, and it is my take on staying close to the originals but filling the gaps, ymmv.
Modern SUPER-CHIP interpretation as done in Octo by John Earnest, 2014
Note: While this is Octos behavior for SCHIP, setting Octo to SCHIP and running the variant detection program will still detect XO-CHIP, as Octo doesn't deactivate the XO-CHIP extensions, so still does long-skips over F000 nnnn. The test therefore correctly
concludes it is actually an XO-CHIP and just complains about the quirks being all wrong.
A modern extension to SUPER-CHIP supporting colors and actual sound first implemented in Octo by John Earnest, 2014
