Quizard 2.2, Patch-Free

I futzed around a bit with the function that sends the initial 20 bytes to the protection device last night.  I discovered that if I killed the random number that it used as a seed and made it 1, the game would simply dump out the key bytes.  Heartened, I wrote some functionality to take those bytes and fashion an appropriate 8-byte return value from them, and with only a 4-byte patch to always return 1 rather than a nuclear NOP-out of nearly an entire function, all the games started firing up.

Even better, I had a hunch that since the main CPU never sends any kind of key to the MCU, perhaps the values themselves are symmetric.  It turns out that they are, and so any seed - not just 1 - will work with the same algorithm.  So the patch could go, but the functionality stayed.  Hooray - all the games will run with no RAM patching!

Now for the bad part: Quizard 3.2, 4.1 and 4.2 all still refuse to go in-game for reasons unknown.  They don't try to chat up the microcontroller in any way, so it must just be what the MCU is returning that they *eventually* don't like.

Quizard 2.2, however, is fully playable.  Pictures:

Quizard 1.2, 3.2, and 4.1

With some additional finagling, I've managed to get both Quizard 1.2 and Quizard 1.7 to be fully playable by either one or two players, along with service mode.  Additionally, the protection check patches were able to be made partially generic, enabling Quizard 3.2 and Quizard Rainbow 4.1 to boot, go into attract mode, and coin up without much hassle:

Unfortunately, both of them have some sort of additional checks before they'll go in-game.  I can patch them with an additional poke, but that ventures into even more hacky territory than I'd like.

Quizard 1.7 Attract Mode

Using a targeted hack, I was able to get the 1.7 revision of Quizard to boot in MAME:

Unfortunately, this looks like it's going to be pretty gnarly, as the MCU controls all inputs and DIP switches to the game.  Yikes!

Quizard

Astute readers of the MAME release notes may have noticed multiple revisions of a game added to MAME 0.139 called "Quizard".  Quizard is noteworthy for being one of the few arcade games to be based on the Philips CD-i game console, and benefits from my ongoing CD-i work in MESS.


Quizard consists of a standard CD-i console with a separate I/O board hooked up to both the front and rear serial ports, with a protected i8571 microcontroller in tow for copy protection.  For anyone interested in seeing what the machine actually looks like, pop on over to Interactive Dreams and read the (short) article on the game: http://cdii.blogspot.com/2007/06/cd-i-arcade-conversions.html


The game currently fails to boot in MAME for unknown reasons which I am in the process of trying to track down.  While it also fails to boot in CD-i Emulator, it does so for different reasons than it does in MESS - MESS seems to get stuck in an OS call shortly after the OS launches the cdi_quizard executable module, whereas CD-i Emulator loads it, tries to send data to the (non-existent) I/O board, then hangs while waiting for a response.


The first order of business is going to be to get MESS into a state where it will run as far as CD-i Emulator does.  This shouldn't be overly difficult, as I've almost narrowed down specifically where it's crashing.  After that, I'll need to verify that the UART handling in MESS's SCC68070 implementation is okay.  Lastly, a lot of guesswork to try to figure out just what the heck it is that it's trying to send to the microcontroller will be necessary, but that should be reasonable considering that much more nefarious protection is broken in MAME with some regularity.  After that, everything should be peachy.