Catalogue of Arcade Emulation Software - the Absolute Reference

Valid XHTML 1.0! Valid CSS!



Large CAESAR Logo

Master Boy (Spanish, PCB Rev A)

0.105u5 [David Haywood, ClawGrip]

< Spain >


- 0.113u3: David Haywood, Charles MacDonald and Clawgrip fixed Master Boy - Game now playable. Added internal HD647180 MCU data rom and changed Z180 CPU clock speed to 6MHz and VSync to 55.407801 Hz. Added SAA1099 (6Mhz), MSM5205 (384000 Hz) and dipswitches 'DSW1/2', 'Demo Sounds', 'Lives' and lots of 'Unknown'.

- 17th March 2007: Charles MacDonald - Good news, Master Boy has been dumped. Thanks again to ClawGrip for loaning the board out and Haze for doing a great job adding it to MAME in record time, check his website for screenshots of the game in action. It quickly became clear that dumping the Master Boy internal ROM manually was going to take forever. I designed a EPROM/SRAM emulator around the FT2232 USB chip and assembled two of them so I could have full access to the data ROM where the text pointers are stored, and the video RAM where the dumped code would be written to. The first test was to find out exactly which bytes were control codes for the text printing routine. I wrote a program to reset the board 256 times and change a string to each of 256 possible values. As it turns out there were no additional codes apart from 0x5C (newline) and 0x7F (end of string). These are the only two values that couldn't be retrieved from the internal ROM. The program was then modified to dump 16 bytes starting from each of the 16384 addresses. By overdumping, I could compare the data before and after the undumped bytes which would appear as a growing string of 0x23 bytes (the value the game initializes the name table to) which abruptly stops as soon as the start address is past the control code. This allows unreadable addresses to be positively identified. With the entire ROM dumped and a list of bad addresses made, the program was changed to test each bad address and see if data from the next adderss appeared at a different position in the name table, signifying a newline rather than the string terminator. This reduced the list further, and it was assumed that all remaining addresses were 0x7F. I went through and inspected the addresses in a disassembly to make sure these values seemed right, and they did. It was pretty cool to trace through the print string routine that made this possible, no other obvious security holes or other ways to get access to the internal ROM seemed available. And nearly all of it was filled with code, I was wrong about it being mostly empty. This ended up being one of the most rewarding and complicated projects I've worked on, since there was no information about the hardware to start with and everything had to be figured out from scratch. And now I've finally got two EPROM emulators as a result, which have been useful for playing with other hardware - I've done some experiments on the SC-3000H console and Sunsoft Shanghai / Sega Mega Play boards. Later on I'll release the project notes and files for the EPROM emulator so other people can build their own.

- 17th March 2007: David Haywood - Another 'impossible' task has almost been complete. This time Gaelco's Master Boy. It isn't playable yet (*Edit* Fully Working), and there could be more problems I've not yet encountered, but it's looking good so far. Special thanks to Clawgrip for giving us a PCB, and Charles MacDonald for working out how to get code out of the CPU.

- 11th February 2007: Charles MacDonald - It's been a while, but I finally found a way to extract the code from the MCU in Gaelco's "Master Boy". It has a string printing routine that does not do any checks on the source address, and writes data from the specified address into VRAM after adjusting the ASCII characters to match up with the tile numbers of the character set in VROM. This routine is used as soon as the game is powered up to display the diagnostic results. To make use of this, I modified the system to use NVRAM in place of the regular VRAM, and hacked up the Namco System 2 dev board so that a 27C512 EPROM could be replaced with 29F010 flash. While an EPROM emulator would have been more convenient, reprogramming the flash for each new start address is managable if tiresome. This is not without difficulties; there is only 4K VRAM present for name table storage and each entry is 4 bytes, and given the start address of the text string only about 800 bytes of internal ROM data can be saved to NVRAM on each try. Furthermore certain control codes will abort text printing immediately or skip several rows, so sometimes much less data can be recovered depending on what values are present. In time it should be possible to dump most all of the ROM, and the game's code can be examined for additional security holes if they are any. The programmer(s) have done an impressive job preventing the MCU from being affected by external tampering through modifying the stack or triggering interrupts, as well as doing range checks on lists of addresses and offsets in the ROMs.

- 19th September 2006: Charles MacDonald - I was recently sent a Gaelco "Master Boy" PCB from ClawGrip to examine. It's entirely implemented in TTL logic and a few PALs which I've desoldered, socketed, and dumped. All of the hardware functions have been mapped out except for the video timing and tilemap generation. One surprise was the inclusion of a Phillips SAA1099 stereo programmable sound generator which I haven't seen before, to go along with MSM5205 ADPCM decoder. I can't get sound out of the board, but it seems like quite a capable chip compared to other PSGs like the AY8910 or SN76489. It uses a Hitachi HD647180 MCU, a Z80 clone with a number of features added such as I/O ports, a MMU, DMA, and so on. However none of the special function pins are not brought out to the connector that joins the CPU module to the main board. In effect, it's just used as a Z80 with internal ROM. Some clever tweaking of the address lines (and assumed use of the MMU) allows the MCU to address 16K of internal ROM and 64K of external space, but the actual game board's memory map only uses 48K with a 16K gap at the beginning. Now that it's known that the ROM data is accessed in banks rather than linearly (something I was sure the MMU would have allowed for) this means some trojaning methods won't work, and others might. The game has several pointers and offset tables in the ROM which may be useful for accessing the internal ROM data. It all depends on the game doing any validity checks on the table contents before using them.

- 0.105u5: Added Master Boy (Spanish, PCB Rev A) and clone (Italian, PCB Rev A).

- 30th July 2004: Guru - Master Boy (Gaelco) arrived from ClawGrip.

Romset: 1040 kb / 9 files / zip