Gameboy "DUCK" DMG Universal CheKer DEV?

Few new pictures.

 

OK, so it is a DMG-CPU - which implies that it's basically a GameBoy with a whole bunch of extra circuitry.

I can't see any ROM on the board, just a pair of 64k bit (8k byte) SRAM chips - which strongly suggests that it needs external ROM to boot (presumably in that top "main socket"). The design seems to deliberately low-tech - apart from the RAM and the DMG-CPU, all the other chips are SSI and MSI. This makes a lot of sense in a piece of production test gear - simple designs are a lot more transparent and less likely to cause strange problems that are hard to track down.

From the look of it, that vertical IDC header should connect to the 7-seg LEDs on the front panel. and the horizontal one (next to the '541 octal buffers) goes to the keypad.

Presumably the LCD is driven directly from the DMG-CPU, since there doesn't appear to be enough logic on the board to drive it any other way. I would also guess that if you could somehow connect a GB cart up to the top connector then it should boot - although the lack of the regular GB controls might be a problem.

It's possible that it's wired the same as the lower socket, and you could swap the adapter over - but I wouldn't want to try it without doing some circuit checks first...

Edit:

Actually, thinking about it I just realized that the original GB also had 2 8K byte SRAM chips in it - one for the video and the other for the scratchpad RAM - so it has exactly the same RAM complement as a regular console. It just has a lot of additional I/O.

 

Where would the BIOS fall into all this? That's not what's supposed to be on the upper slot, is it?

 

It's very hard to tell what's going on - normally the easiest way to figure out how something like this works is to disassemble the code that controls it, but in this case that's the bit that's missing. I also just noticed that one of the SRAM chips has a coin cell next to it, so presumably is non-volatile - I guess it's also possible that the code was downloaded into that RAM from the upper cart and only updated when you wanted to check a different cart.

In fact, that would make a lot of sense - since this appears to be a production test system it's likely that they had a whole row of them - and having to burn multiple EPROM carts (one for each system) every time you changed the firmware would be a pain. If you put the code into battery backed up RAM, then you would only need a single update cartridge to set up all the test systems.