Old News - 2007 | |
|
Old News (5/12) I had the Sega System 16B hardware out again to check some issues with the display area size. While the the display isn't blanked by the latches which feed the video DAC for 321 pixels, the tilemap chip (which manages priority between itself and the sprite chip) somehow gets the latches to be loaded with zero during pixel column 0, reducing the display range to a more sensible 320 pixels. A little odd, but there you have it. I guess you can't trust video timings just based on the blanking and sync signals, but I have a hunch that is usually not the case. I decided to give the 171-5797 ROM board a quick review as long as everything was hooked up. This one has two custom chips, in particular the 315-5250 which implements a Z80 sound latch, programmable timer, two hardware comparators, and a main and sub CPU interface where the main CPU can knock the sub CPU offline and access anything on it's bus. As there's only one CPU in System 16, the pins used for the sub CPU aren't used. However the region #2 /CS signal is configured to allow sub CPU memory access. What's the point of doing that when there is nothing present on the sub CPU side? Having examined the After Burner schematics and completing a pinout of the chip's connections as it's used on the ROM board, I figured out how the sub CPU shares memory with the main CPU. It uses these signals which normally go to a second 68000:
/SASI - /AS input from sub CPU
SR//W - R//W input from sub CPU
/SLDSI - /LDS input from sub CPU
/SUDSI - /UDS input from sub CPU
/SASO - /AS output from main CPU
/SLDSO - /LDS output from main CPU
/SUDSO - /UDS output from main CPU
/SCCS - /CS for sub CPU comparator registers
/MSCS - /CS for main CPU to access sub CPU memory area (1MB)
In the X-Board hardware where this chip made it's debut, the sub CPU
/AS signal fed both /SASI and /SASO, and extra logic formed /SLWR and
/SUWR from a combination of either /SLDSI, /SLDSO and /SUDSI, /SUDSO
being active. During an access to sub CPU memory, the 'O' signals
output what the main CPU provides and the 'I' signals feed those
back into the custom chip.
Internally, the 315-5250 routes signals around from the main
to the sub CPU side like so:
Main Sub
MA19-MA1 -> SA19-SA1
MD15-MD0 <> SD15-SD0
MR//W -> SR//W
? -> /SASO
/LDS -> /SLDSO
/UDS -> /SUDSO
When the chip does a bus request and kicks the sub CPU offline, these
signals are driven by the main CPU. On this ROM board you could tell the sub
CPU memory area was supposed to be used as the chip has /BR and /BG shorted together, so that
the bus arbitration logic gets a bus grant the instant it issues
a bus request. In addition /SASO is connected to /SCCS.
So what does this arrangement actually do?
While the 68K accesses region #2, /MSCS is asserted enabling the sub CPU memory space. Bus access is granted and /SASO is asserted which in turn pulls /SCCS low, subsequently enabling the sub CPU comparator registers. Because the other signals are routed internally, it's OK that the sub CPU address and data pins on the chip are unused. With the read/write strobes also internally connected, the CPU now has full access to the second comparator. No games use these registers that I know of, but the idea that a game under-utilizes the protection measures available is certainly not unknown to Sega. The ROM board also has some cool stuff like logic that regenerates the /LDS and /UDS signals used by the two custom chips based on the already combined /RD, /LWR, and /UWR strobes that the 315-5195 chip outputs, as well as it's own reset circuit and clock source for the comparator. A shame that the timer isn't hooked up, but due to the lack of expansion signals on the ROM board connector not much can be done. There's even a small prototyping area and spare /CS signal for expansion. Maybe adding an EEPROM for long term high score saving is possible, could be fun for the shoot-em-ups like Cotton if moving it to the the 171-5797 ROM board can be done. Old News (4/6) Here are the project files for my EPROM/SRAM emulator. Full source code, PCB layout, and GAL equations are included. I've also added support for 16-bit (tested) and 32-bit (experimental) ROM loading. There are some things I forgot to add to the PCB layout, I will probably update it in the near future. I also optimized the data throughput for Host Bus Emulation Mode (mainly for all the data that had to be dumped from Master Boy), so I've got to update the SMS Cartridge Reader/Writer utility with the new USB code at some point. Earlier I repaired my Virtua Fighter PCB set which had been dead for quite some time and have been using two of the EPROM emulators in parallel to run test programs. I also finished mapping out all of the video board circuitry except for the customs/TGPs (no idea how to proceed on that one ;), and have been able to piece together a mostly complete memory map on the V60 side including timings for each memory region. I was running some timing tests on the 8751 MCUs used in several Sega games, and noticed they seemd to respond to the internal ROM / external program memory select pin (/EA) even when it was changed after a reset. I thought this meant it may have been possible to force the MCU to run a user specified program and dynamically enable/disable the internal ROM while running. This ended up not being the case, the opcodes are fetched but not acted upon. Maybe the MCU internally drives NOPs onto the data bus. I wonder if the program counter continually increments so that you could force the PC to get into the external program memory range, but in the limited testing environment I had set up this didn't seem to happen. Probably the PC is never incremented. This behavior seems to be standard across the Intel C8751 and D8751 chips. If /EA is pulled high or left unconnected, the internal ROM program runs. If /EA is tied to ground it stops execution and starts fetching opcodes by strobing /PSEN repeatedly. You can change /EA as many times as you want and reset the MCU with it in different states, you'll get the same behavior every time. It's unfortunate, but at least this confirms that a trick used to dump some protected 8051s will not work on these MCUs in particular. I compared their operation to a unprotected AT89C52 which responded correctly, so this is definitely a function of the MCU security bit(s). Old News (3/17) 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 address 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. Old News (2/11) 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. A new version of SMS Plus is available, the big addition being legacy video mode (TMS9918) emulation for both the SMS and GameGear displays. This was written while I did extensive testing on a SMS 2 and GameGear, so I feel it's fairly accurate. I have included a very preliminary Windows port that I used during development, but it's not the kind of thing you'd use for any serious gaming.
Support for the SG-1000/SC-3000H hardware will be added next. Most of the games seem to play well with just the TMS9918 emulation added, but the PPI and keyboard need to be implemented. Maybe I'll take it a step further and support the SF-7000. A few months ago I designed a SMS cartridge reader based around FTDI's FT2232 USB chip. It's Host Bus Emulation Mode turned out to be the perfect solution for USB connectivity to a memory mapped device like a cartridge. The current files including the design instructions, PCB layout, GAL equations, and PC client source code are available here:
It also supports dumping battery backed RAM, writing to SRAM cartridges, erasing/reprogramming Flash-based cartridges using the AM29F040 chip, and performing tests on the memory mapper hardware to determine which features are provided. I even used it to track down some errors in my reworked SMS development cartridge. ;) | |
| Return | |