N64

Because I am a very stupid person, I have decided to utilize the week I have off for the holidays to look at the N64 driver in MESS.  My plan is as follows:

1. Iron out the regressions from the past ~10 versions of MESS, as I know they are great in number.
2. Get the Serial Interface into shape, as it's what's preventing several games from booting due to Controller Pak issues.
3. If #2 doesn't take care of it, get Hey You, Pikachu! to work.
4. Drink heavily and curse the emulation scene.

Minecraft Mod API Brain Dump

Quick brain dump from IRC on what I, as an engineer, would want out of a proper modding API for Minecraft:

<@Harmony> First suggestion: Study the plugin structure of N64 emulators.  Some folks hate 'em, but I've always been a fan of a-la-carte services.
<@Harmony> Have an input abstraction layer for input plugins, for example; define a standard set of messages that the input plugin will send to the application, and the input plugin can be written to accept input from whatever HID it wants.  Person's playing on a keyboard, with no force-feedback?  Fine, EVENT_DAMAGE_* (hypothetical name) will be ignored.  Person's playing with an X360 controller?  The input plugin can key off those events and send the motors a-spinning.
<@Harmony> Some sort of abstraction layer to allow assets to be easily dropped-in; not just textures, but block models, mob models, player models.
<Nightmare> block types, and block-block interactions (so we can make a brick which floods the map with molten cheese, etc)
<@Harmony> That should actually be considered separately, let's not get ahead of ourselves.
<@Harmony> The blocks themselves aren't so much data-driven, I imagine, as code-driven.
<@Harmony> It would be nice to have them data-driven, perhaps by the same asset replacement system as renderable assets, but depending on where the core gameplay portion of the engine goes in the future, it might be easier to have blocks conceptually be part of the core gameplay engine, and simply have each block have an associated render asset
<@Harmony> Perhaps that plugin or subsystem could communicate with a render abstraction layer, which could allow people (like me) to write custom materials
<@Harmony> Imagine, dirt that's lit and has low specular like dirt
<@Harmony> Genuinely bumpy stone
<@Harmony> Environment-mapped water, with a soft UV wobble applied depending on the water current
<@Harmony> A modified fur shader for lush-looking grass
<@Harmony> Bright, bloomy snow
<@Harmony> Man, if I could get my hands on the original source code and not some decompiled bullshit, that's the first thing I'd do, is change that "OpenGL 1.1!" yellow text line to "OpenGL 3.0!"
<@Harmony> And think even further down the rabbit hole - nice, polished-looking mob, animal and player models, with plenty of bones, nicely skinned
<@Harmony> None of this requires any modifications to the physics side of the engine, so that could remain the same :D

74LS47, 74LS390, and 7-segment Decoder Complete!

Full tour video here: http://www.youtube.com/watch?v=RJIbZ-NzniQ

Not really much more needs to be said.  Check it out.

7400-Series Emulation Library for Minecraft: SELF-MC

One thing I've noticed with growing amazement is the circuitry that people have been laying down in this one game, Minecraft.  It turns out that due to the fairly simple rules that are followed by Redstone Dust in the game, you can build all of the necessary logic gates to re-create the inner workings of simple CPUs, ALUs, and other circuits that use binary logic.

However, one thing that has consistently bothered me is the lack of any sort of off-the-shelf solution for certain circuits - for example, the initial 16-bit ALU demonstration in Minecraft required the user to read binary, whereas I'm shooting for something a bit more visual.  It's with this in mind that I've implemented a working framework for the 7447 BCD-to-7-Segment Decoder IC, which takes four bits as an input and outputs seven lines that can be used to drive seven LEDs (or, in our case, torches) in the standard configuration to form digits.

More screenshots and videos will be posted after I get home from work, but in the meantime, here are the results of my test suite of all 10 single-digit decimal numbers being fed into the circuit:

0: Segments A, B, C, D, E, F

1: Segments B, C

2: Segments A, B, D, E, G

3: Segments A, B, C, D, G

4: Segments B, C, F, G

5: Segments A, C, D, F, G

6: Segments C, D, E, F, G

7: Segments A, B, C

8: Segments A, B, C, D, E, F, G

9: Segments A, B, C, F, G

The primary goal with this circuit was to be compact in two ways: First, the ability for the 7447 circuitry to be located entirely underground, and second, and using a minimum of X/Z real estate by building upward rather than outward.  In both ways, it was a rousing success.

Below is the logic diagram of the 74LS47 chip.  It consists of four primary inputs and seven primary outputs, with some glue logic - omitted thus far in the Minecraft implementation due to irrelevance - to control things like output blanking, lamp testing, and so on.

Source: 74LS47 Datasheet from Motorola

As mentioned, the areas highlighted in red were omitted or modified:
- The four red NAND gates were converted to NOT gates.
- RBI, RBO, BI and LT are not hooked up due to being relatively irrelevant to the functionality of the chip in Minecraft, though they could be trivially added back in.

At any rate, the sky's the limit for what I want to do next.  The only real downside is finding datasheets that actually contain a comprehensive logic diagram.  The end goal, however, is to begin converting the core functionality from other complex 74-series chips in order to begin building up a library of chips.

Stay tuned for a full schematic at some point.

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.