Charles MacDonald's Home Page | |
|
News (4/6/13) I've been working on a System 24 project and decided to update the old hardware documentation. Almost everything has been tested that I can think of, including some unused features that games don't utilize. There's still a bit more work to do regarding wait states and rendering timings.
News (10/20/12) Here's the current version of the fdtool program which is used to work with and manipulate FD1089 tables and key data:
The dumping hardware design files and control program will get released next. I'm using it to get a better idea of how the 68000 runs on a cycle by cycle basis, but the hardware needs some slight modifications to fully enable this type of clock control. Once that's done and tested it will be ready for the public. Old News (10/13) I recently acquired some PCBs from Sega's "Caribbean Boule" (1991), a roulette game for eight players with electromechanical components. It's an interesting mix of old and new technology spread out over thirteen boards:
The satellite boards are labeled "System M1" (1990) but have no relation to Model 1 in terms of having 3D capabilities:
The design reminds me of Model 1 which came out a year later; the serial-to-memory I/O chip that I thought was introduced with Model 1 showed up here first and the old System 24 parts are re-used in a similar way. I always find these intermediate steps beteween hardware platforms intriguing and this board fills in some blanks for me. The new I/O chip (315-5338A) has a pretty cool mode where it can be operated remotely over a serial connection. In Model 1 this was used on the main board, the chip communicated with the comms board and stuffed data into dual port RAM for the V60 to read, all without any CPU intervention. Here it is used in a similar way, controlling the 7-segment LED drivers and inputs on the operator's control panel PCB without needing a Z80 or other CPU/MCU to handle those tasks. The game board is from 1989 and has no system designation. It looks a lot more like older Sega board designs compared to the satellite board:
The video board seems to not do much; hardly any of the sprite ROMs are populated. It uses the same communication board as other X-Board games. The sound hardware isn't used and no sample or Z80 ROMs are specified in the ROM list. Going by the diagrams it connects to a RGB to S-Video converter, as the projection monitor only has S-Video input. Throwing in an entire X-Board just to drive a standard resolution display seems like overkill, but it's the only thing with a fiber-optic comms board Sega made at the time. Can we emulate this game? Well we still need the video board ROMs dumped, but perhaps communication can be faked so that the rest of the system works. Peformance should be an issue with 9 displays, 11 68Ks, and 17 Z80s. I can't even begin to imagine how incredibly costly this thing must have been when it was new. I guess there is good money in gambling games because it must have cost a small fortune. The FD1089 work discussed earlier is nearly done. I finished a program that can search for LCG seeds and used it to generate a complete key for sjryuko, to replace the partial key we had in MAME. Together with the dumping circuit any FD1089 can be preserved now. There's a lot of partial dumps in MAME so if you can help out and loan a FD1089 to be read out, please get in touch. Old News (8/17)Last Survivor Thanks to ShouTime we finally got Last Survivor dumped and emulated. It's a good reminder that there are still working FD1094 CPUs out there, and we do need to get them dumped as soon as possible. Between this and Bullet we have had good fortune finding rare games, so who knows, maybe we'll find Charon next. FD1089While FD1094 dumping has been a plug-and-play affair, we've never had a good solution for the FD1089. We recently acquired a FD1089-based game to be redumped to complete the partial table set that's already in MAME. This was a good opportunity to approach the FD1089 again from a new perspective, given the last work I had done on it was back in 2005. Here's the dumping circuit I developed: ![]() This is a variation of the custom Z80 dumping board I made for the Free Kick-type CPU modules. There's a lot more chips underneath the top PCB, and the empty sockets were for some alternate ideas that I ended up not needing to use. The new automated dumping process works like this:
Being able to control the 68000 at the bus-cycle level makes a lot of interesting behavior readily apparent. You can see the prefetch mechanism, including dummy fetches that result in unused data, and the out-of-order stack writes during exceptions. Plus a lot of invalid instruction encodings don't cause exceptions at all, which isn't what I expected. Rather than being useful undocumented instructions I think they are just aliases for other valid ones. Anyway it would be worthwhile to look into this further. News (7/7) DECO Games Quite a lot of progress has been made with the Data East cassette system dumping efforts. Many different dongle types have been examined and supported, and currently all known dongle types can be dumped. Software has been developed to extract the PROM data out of dongle dumps and to perform detailed analysis of the decryption features of various dongles, and to determine internal jumper settings to see how a dongle is configured without even opening it up. A few games have been added to MAME recently and it's likely there will be more additions in the future, as we keep finding tapes and dongles to dump from generous donors. Bubble SystemThanks to Guru I have a Bubble System board to work with, and I made an expansion card to run software other than the BIOS and provide USB communication to a PC. It also has a pass-through connector so the RAM cards that fit in the expansion port can still be used.
The Bubble System MCU controls the bubble memory, watchdog, and system reset functions. It seems to reset the system very aggressively and it has been hard to write software that keeps the MCU happy long enough to start reading sectors of bubble memory data. The board I have has some faults, so there could be a number of problems contributing to this behavior. Regardless, I've been able to run test programs on the Bubble System and probe the various memories, registers, and the bubble memory interface to learn more about how it works. I think it will definitely be possible to extract all the game data in time. More WING CPUs dumpedI've dumped an alternate version of Free Kick and Exciting Black Jack. Free Kick was an older version (1987.9) which the two bootlegs were derived from, so all known version of the game are now dumped. Exciting Black Jack utilized the custom CPU module in new ways that lead to the discovery of more memory mode quirks and an external memory mode select. I've updated my notes about it here: All that's left to dump are Counter Run and Lucky 74, both of which are already in the possession of other MAME developers.Old News (2/5) The Data East cassette system uses a security dongle that is unique to each game. This prevents operators from duplicating a game simply by copying the audio data from a game cassette to a blank tape. There are several types of basic dongle designs, and each one has data that is specific to a particular game. A 6502 CPU runs the BIOS and software loaded off the tape. It can exchange command and data bytes from a 8041 MCU that controls the tape drive over a serial interface. The dongle sits between the 6502 and 8041 and can modify, replace, or pass data through unaltered during communication. A loaded program can also interrogate the dongle for additional data unrelated to the 8041 or tape contents. I've made a circuit that mimics both the 6502 and 8041 interface so all aspects of the dongle can be observed. Because some dongles also have a reset generator inside them that intializes the internal state, the dongle reader has a software-controlled power supply to force a reset condition as needed.
It has been tested successfully with a so-called Type 3 dongle. This dongle has a normal operating mode and a "PROM mode" where a 4Kx8 PROM can be read out sequentially. After a reset, values written to the data and command registers and data read from the command register are not modified. Values read from the data register have bits 6 and 7 exchanged, and bit 0 is the latched value from the previous byte that was read. The 8041 normally uses commands in the 00-7F range and ignores higher values. This allows 80-FF to be used to send commands to the dongle that will not trigger any action on the tape drive. For the Type 3 dongle, writing Cx (where bits 3-0 don't matter) enables PROM mode. Now, writing any value to the command register loads bits 12-8 of a 12-bit counter and bits 3-0 are reset to zero. Reading the command register returns a byte from the PROM at the current address, then the counter is incremented by one. The counters wrap from offset FFF to zero. In this way the loaded program can read out the entire PROM content. Oddly enough the 8041 interface seems to be disabled in this mode. Writing to the data register or command register will tristate the data bus, causing the 8041 to latch an open-bus value. Likewise, reading the data register returns an open-bus value as well. There are no resistors on the BIO-8 board or in the Type 3 dongle to pull the data lines into a known state, so the actual value that is present will fluctuate. Perhaps after receiving the Cx command the 8041 knows to ignore all future communciation with the 6502. Once the power has been cycled the system and dongle will reset and normal operation resumes, with the tape drive being accessible again. Once I get some other types of dongles to experiment with I'll post an update about how they work. Old News (1/6) I recently dumped the internal ROM for Wing's "7 Smash". The ROM was trojaned in a similar way to Pinkiri 8 and other Wing games that are now emulated in MAME.
This board uses a HD647180 MCU (in a huge 90-pin SDIP package) with 16K of internal ROM and up to 128K of external ROM. The external ROM contains program code so it isn't particularly hard to get control of the system by inserting your own software into the ROM once you've made a NOP sled or identified the entry points. To get the internal ROM data out I used my 8-bit EPROM emulator which can also emulate RAMs. The two red wires in the picture are used to tap into the system reset signal from the MB3771 and part of the glue logic which generates a write strobe for memory locations. This allows the trojan program to write back into emulator memory to store data. Once it had copied the internal ROM to RAM (and generated a checksum) I just had to download the emulator RAM and that was it. If any more of these games come up in the future it should be fairly easy to get them dumped. Old News (1/1) Here's some Saturn and PSX info:
The ROM replacement is designed to be used with an EPROM emulator connected to the flash memory socket of a PSX Action Replay or similar device. It functions as a loader for a small (~32K) program appended to the ROM, which is copied to work RAM at $80010000 and executed as a subroutine. The appended program can return to the caller to continue with the BIOS boot process if necessary. The AR and most clones use a 78L05 regulator which is not sufficient to power an EPROM emulator, I had to replace mine with a full-sized 7805. The cheaper variants just use a zener diode to knock down 7.5V to 5V and have no real regulator, so more changes will be necessary. I've been having a lot of fun playing the fan-translated version of Persona 2: Innocent Sin. The people responsible did an incredible job hacking up the original game for the rest of us to enjoy, and it's thrilling to think they are working on Soul Hackers next: Incidentally Atlus localized the PSP version of Innocent Sin, but purists will probably want to play it on the PSX like it was intended. | |
|
|