Old News - 2011
News

Emulation

Electronics

Information

Miscellaneous

External Links

Other

[ 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 ]

Old News (9/18)

Odds and ends

Here's some information about the Datel Comms Link ISA card:

For convenience the schematic uses a 24-pin DIP PAL, but the real thing has a 28-pin PLCC part which is described in the pin assigments document.

Update (10/8)

I've been running a lot of tests on Free Kick to understand how various functions of the NS6201 security module work. Here's a complete description of it:

Update (10/15)

While doing a little SC-3000H research I took a closer look at the DRAM interface. Here's a diagram of the DRAM signals from the MITEC-2 chip during a RMW instruction to the $8000-$BFFF range, with the A and B markers showing the 11-cycle interval during execution of "INC (HL)", as well as the updated system documentation.

The signals work as follows:

  • RA7 is the eighth bit of the DRAM row refresh counter. The Z80 only has a 7-bit counter, so the MITEC-2 chip monitors transitions on A6 during refresh cycles to carry into RA7. However RA7 does not function as Z80 A7 outside of a refresh cycle and is assigned to a dedicated cartridge pin instead of replacing A7.

  • RCSEL# is used to control a multiplexer that outputs the row (1) or column (0) of the Z80 address bus. It follows RD# or WR# during a memory cycle to any address, and is delayed by 64ns so there is adequate time for the row address to settle and get latched by RAS0#.

  • RAS0# is the DRAM row address strobe and is asserted during refresh cycles (following RFSH#) and memory cycles to $8000-$BFFF. RAS1# is the same for $C000-$FFFF.

  • CAS0# is the same as RCSEL#, but restricted to $8000-$BFFF and delayed by a further 64ns. This allows the column address that was selected by RCSEL# to settle before being latched by CAS0#. CAS1# is the same thing for $C000-$FFFF.

Since the Z80 only runs at 3.58 MHz there is adequate time to access DRAM without inserting wait states. The MITEC-2 chip isn't clocked so it appears to use a delay line with a tap at 64ns and 128ns for the delay functionality.

These additional signals allow DRAMs with 8-bit rows to be mapped to $8000-$BFFF and $C000-$FFFF with minimal external hardware. The Basic cartridge uses two pairs of TMS4416s to add 32K of DRAM to the system for example.

Old News (9/18)

Odds and ends

Here's some information about the Datel Comms Link ISA card:

For convenience the schematic uses a 24-pin DIP PAL, but the real thing has a 28-pin PLCC part which is described in the pin assigments document.

Update (10/8)

I've been running a lot of tests on Free Kick to understand how various functions of the NS6201 security module work. Here's a complete description of it:

Update (10/15)

While doing a little SC-3000H research I took a closer look at the DRAM interface. Here's a diagram of the DRAM signals from the MITEC-2 chip during a RMW instruction to the $8000-$BFFF range, with the A and B markers showing the 11-cycle interval during execution of "INC (HL)", as well as the updated system documentation.

The signals work as follows:

  • RA7 is the eighth bit of the DRAM row refresh counter. The Z80 only has a 7-bit counter, so the MITEC-2 chip monitors transitions on A6 during refresh cycles to carry into RA7. However RA7 does not function as Z80 A7 outside of a refresh cycle and is assigned to a dedicated cartridge pin instead of replacing A7.

  • RCSEL# is used to control a multiplexer that outputs the row (1) or column (0) of the Z80 address bus. It follows RD# or WR# during a memory cycle to any address, and is delayed by 64ns so there is adequate time for the row address to settle and get latched by RAS0#.

  • RAS0# is the DRAM row address strobe and is asserted during refresh cycles (following RFSH#) and memory cycles to $8000-$BFFF. RAS1# is the same for $C000-$FFFF.

  • CAS0# is the same as RCSEL#, but restricted to $8000-$BFFF and delayed by a further 64ns. This allows the column address that was selected by RCSEL# to settle before being latched by CAS0#. CAS1# is the same thing for $C000-$FFFF.

Since the Z80 only runs at 3.58 MHz there is adequate time to access DRAM without inserting wait states. The MITEC-2 chip isn't clocked so it appears to use a delay line with a tap at 64ns and 128ns for the delay functionality.

These additional signals allow DRAMs with 8-bit rows to be mapped to $8000-$BFFF and $C000-$FFFF with minimal external hardware. The Basic cartridge uses two pairs of TMS4416s to add 32K of DRAM to the system for example.

Old News (9/9)

Atari GX2 protection

Atari GX2 games consist of three boards:

  • Game board (JAMMA compatible)
  • JSA board (Sound and some I/O)
  • CLARN board (Security and linking)

The CLARN board has a fast board-to-board parallel link and a slower cabinet-to-cabinet serial link. Surprisingly an entire ADSP-2105 DSP is used just to manage serial communications. The parallel link consists of two identical subsystems shared across two board sets, each containing one port of a 2Kx8 dual port RAM and a 8Kx8 RAM (only 4K usable) accessed through a TPC1020 FPGA.

Here's some preliminary documentation (pinouts, memory map, etc.): The FPGA can't access the dual port RAM, DSP, and I/O on the board, though it may be able to snoop CPU access to them. It has the right connections to provide a 16-bit interface to the 8-bit RAM transparently. Moto Frenzy writes data into RAM and tests it frequently, doing dummy reads and other seemingly pointless operations. The FPGA keeps track of these accesses and uses it to influence data that is read back later as it can manipulate the RAM address and data bus as needed. The game depends on correct results when creating sprite lists and road data, without the CLARN board present the sprite positions and road display are corrupt making the game unplayable.

The next step is to add a USB interface to the GX2 board and write 68K code to communicate with a PC. Then I can send test programs to the system and start experimenting with FPGA RAM access. Since the RAM is external, it can be monitored with a logic analyzer or even replaced with a RAM emulator (same one used in Master Boy) to capture the actual data the FPGA is working with. I'm hoping the protection has more to do with the RAM content rather than the internal state, as the FPGA has 48 bits that can be isolated from the I/O pins.

The Atari GT games (T-Mek/Primal Rage) use a similar security system. The main board has an Actel A1020B FPGA connected to 8K RAM. With the RAM removed, the game runs much like it does in MAME now. The A1020B is a significantly more complex chip so it's likely the security has improved considerably. Definitely something to look at later.

Old News (9/5)

Free Kick dumped

Well, that was fast. Works great in MAME.



Does anyone have an original (non-bootleg) version of Counter Run they could lend for attempted dumping?

I ran Free Kick in single-step mode up until a point where the stack pointer was initialized to a known value, than triggered repeated NMIs to push the stack pointer down past zero, wrapping around the address space into the external memory area. This is the only place where activity on the Z80 bus can be monitored.

The NMI routine was allowed to finish instead of being interrupted again. At a point where it calls a leaf function, the return address was modified to point to a fragment of the IRQ handler which pops several registers off the stack before returning. This let BC, DE, and HL to be set to user-specified values, followed by another modified return address that pointed to a single LDIR instruction. A block transfer was performed that copied the internal RAM data to the external memory area in 4K chunks, and the process was automated to dump the entire content of security module correctly.

It's satisfying to have this game dumped after working on it for quite some time, and this outcome certainly justified the time spent developing the Z80 analysis board. Here's hoping Counter Run can be dumped in a similar way.

Old News (8/23)

Z80 Analysis Board

One of the coolest things created to assist emulation was Dave Widel's application of using a I/O card to control a custom Z80 to identify instructions and find the correlation between encrypted opcode/data bytes and their decrypted value. I've been continuing research on the Z80-based Free Kick / Counter Run security module and I wanted to add similar functionality into a new board designed to facilitate analysis of these modules.

This board connects the expansion port of the Rev. 4 PAL dumper and has sockets for regular 40-pin Z80s and the 52-pin security modules. It has three operating modes:

  • Static clock: The user controls the clock input and can assert any inputs and monitor outputs.
  • Single step: Like above, but the CPU runs at full speed and automatically enters a wait state for all bus cycles.
  • Bus request: CPU gives up ownership of the bus and the internal memory and I/O spaces can be probed.
The two dead Free Kick modules work as expected despite having corrupted program code in the internal RAM, I can observe what they do for each clock cycle or bus cycle, though they don't do much. For some reason the one working module doesn't seem to operate reliably in the analysis board, but works fine on the real thing. I guess more testing is necessary. Using the bus request feature didn't allow access to the internal RAMs, but it was highly likely they'd disable the read/write strobes to prevent that kind of attack. Regular Z80s and custom 40-pin ones (Top Roller, MC8123, Kabuki) all work fine, though there isn't a pressing need to work on those parts.

The Counter Run bootlegs seem to come from the same source. One set is extensively modified to work with the bootleg hardware, the others have a protection check disabled (a 3-bit latch mapped to an I/O port inside the security module) and a checksum test that is bypassed. I guess they were too lazy to calculate a correct checksum.

What's really interesting is that the bootleg ROM is a dump of the entire internal Z80 address space and includes the work RAM which isn't necessary or even utilized. The work RAM has a factory default high score list (no initials from the bootleggers), a sprite list and other variables, the Z80 stack contents (likely ruling out a HD647180), and even the original correct checksum result. This means the bootleggers were able to take control of the module at some point during normal operation, perhaps during the attract sequence. I want to say there should be an easy way in, but I don't know what it is yet.

Sega Genesis Development Cartridge

During the winter I made a development cartridge for the Sega Genesis. My goal was to make it SRAM-based to facilitate rapid testing of software which can't be done with flash cartridges. Features include:

  • 4MB SRAM
  • 32K battery backed RAM (CR2032)
  • 1MB boot ROM (Flash)
  • IDE interface (8-bit mode)
  • USB interface
Games can be loaded over USB at about 260K/sec so even the largest games load in just 16 seconds. I didn't get around to writing a menu system to load games from external storage, but I did some video streaming tests using an IDE hard drive and later a Compact Flash card over a CF<->IDE adapter. I wanted to see how good FMV could look when VDP DMA is the only limiting factor rather than the source device, such as the Sega CD's two-speed drive. Here's an example of 256x192 4-bit FMV playback at 20 FPS, though YouTube makes it a bit choppier:

To handle different types of cartridges there are four different memory modes the devcart can run in. BIOS mode gives the boot program full access to all memory and peripherals. Game mode 0 supports cartridges up to 4MB, mode 1 supports 2MB and backup RAM, and mode 2 supports 4MB with banked backup RAM for games like Phantasy Star IV. Virtually all games work with the exception of the few cartridges that have special hardware (SVP, J-Cart, SSF2) or EEPROM instead of save RAM.

I also tried some 32X games, but the SH-2s in the 32X adapter can access ROM much faster than the 68K ever could. There are long enough propagation delays from the time the cartridge signals are asserted to the time the 22V10 enables the data bus buffers that the memory cycle is nearly over. I could have gotten faster GALs (using 25ns, they go down to 5ns) but the lack of good 32X games doesn't justify the cost of these parts.

Overall this project was a lot of fun. Developing software and running games is a snap, being able to transfer data to the PC while a program runs makes debugging easy, and the IDE performance was better than expected for non-DMA transfers. Once I finish up the client software and documentation I'll release the project files.

Fake 22V10s

I recently bought a set of used Lattice GAL22V10D devices from China-based distributor that turned out to be counterfeit. They all have identical top-side labeling, including the speed grade and date code. The molded plastic body differs from chip to chip; some have an indendation for a pin 1 indicator, others have a notch, some have both. The ejector pin marks are frequently missing, and the body color is inconsistent and ranges from dark black to gray. All have a beveled edge around the top instead of a sharp edge like the real chips, likely due to sanding to remove the old markings. The pins were clean and bent out -- clearly not pulls as advertised.

Out of the set of 50 there were two good chips, which physically matched regular 22V10s and were pulls with pencil markings indicating their original board position ("U10" and "U11"). I guess throwing in a few good PALs in the tube makes the transaction more legit. Now that Lattice discontinued the 16V8 and 22V10, these chips are rising in price and the pirates seem to have positioned themselves to benefit as people scramble to purchase the last batches available. I wonder what these chips really are, probably just junk that fits the 24-pin DIP form factor.

Old News (7/17)

Bubble System information

Back in 2007 Guru and I did some experiments with a Konami Bubble System board. I wanted to discuss the results before I forget how it all worked.

The system has a 68000 with 128K of work RAM implemented as DRAM, and the first 4K is replaced with two 2Kx8 SRAM chips. The SRAM is shared with a unknown MCU (64-pin SDIP) that can halt the 68000 and read/write SRAM as needed. The MCU directly interfaces with the bubble memory. There are dedicated hardware registers at $40000 for the 68K to make sector read/write requests, and the MCU uses $F00-$F7F in shared RAM as a sector buffer for these requests.

After a power-up reset the MCU writes the vector table and a boot program into shared RAM for the 68000 to execute. Guru replaced the SRAM with NVRAM so we could get the boot program before it was overwritten by the game program. It does the following:

  • Wait for a fixed period of time.
  • Kick the watchdog.
  • Copy MCU-supplied data from 14C to D00. I think this is the bad sector bitmap and is 304 bytes. That's 2432 bits for each 128-byte sector, or 304K total. Sectors are actually 132 bytes each, with 128 bytes of usable data. The BIOS strips the excess data out after the MCU has read a raw sector into RAM.
  • If offset $78000 contains $5555, jump to $78002. This corresponds to external EPROM attached to the daughterboard connector, presumably for development.
  • Read bubble memory sectors $001, $001, $801. This data isn't used, so these are probably dummy reads to prepare the bubble memory for later access. Bit 11 of the sector number may have a special purpose here (e.g. sectors $001 and $801 are the same)
  • Read eight sectors from sector $181 onwards to RAM at $10000, converting each raw 132-byte sector to a 128-byte sector.
  • Jump to $10000 where the first 1K of the game program loaded from bubble memory resides. This is the higher area of work RAM that isn't shared with the MCU.
From this point the game is running, and it will continue to load more sectors into memory and perform game specific operations. It has a simple BIOS in the low 4K of work RAM where trap #0 reads a sector and trap #1 writes a sector. I don't know if games commonly write data such as high scores back to the bubble memory however, or if the sector buffer for a sector write operation has to be in the raw format or not.

Now for the sake of preservation and emulation our goal is to read all of the bubble memory data for each game. In order to do this a trojan has to be executed by the 68000 to talk to the MCU and request sectors to read. As the 68000 program code is either loaded from bubble memory or copied from the MCU internal ROM, there is no easy way to run our own code. Replacing the SRAM with ROM (in our case, write-disabled NVRAM) prevented the MCU from starting up correctly as it expects to read and write data when booting, so the only remaining option is to use the daughterboard connector. We had tried replacing the RAM daughterboard with two NVRAMs filled with $55 and the BIOS still didn't jump into that region, but it's possible the RAMs on that board occupy a different memory range.

A custom PCB could be attached to it with the identifying signature and 68000 code that would get executed directly. Some additional hardware like more NVRAM or a USB interface could be added to the board for saving sectors as they are read. Or, another option would be to replace the 68000 with a Fluke module and break execution once the startup program passes control to the program loaded from bubble memory, then overwrite RAM at that address with a trojan.

At some point we probably want to get the MCU decapped, identified, and read for the sake of accuracy. The bubble memory games are quite rare and expensive so it has been hard to find people with access to working boards who want to risk doing something like this. In the meantime it's probably sufficient to just dump the bubble memory and simulate the MCU for emulation.

Old News (7/3)

Emulator updates

I've decided to switch licenses for SMS Plus, Genesis Plus and TGEmu to the MAME license, in an effort to curb people from selling them for profit. The newest releases are here:

I strongly recommend port maintainers to remove older source distributions of the software, and to include "license.txt" from these new source packages with your port specific binary and source distributions. Please contact me if you have any questions or concerns.

Old News (6/27)

YMO Live

I had a great opportunity to see Yellow Magic Orchestra perform at the Warfield in SF. Its been thirty years since they last visited the USA, and this was quite a limited tour with only one other stop at the Hollywood Bowl in LA. The crowd had a lot of energy and we made enough noise at the end to get two more songs as an encore.

They played more material from their middle period which happens to be my favorite, such as Seoul Music, Taiso, Gradated Grey, and Ongaku. The new songs were fantastic, and of course they covered all the classics the fans were expecting, including an especially rousing performance of Firecracker. Definitely a once in a lifetime chance and a lot of fun!

News (6/26)

Super Magic Drive Schematics

Here are schematics for the floppy disk drive PSU that comes with the Super Magic Drive. What's interesting is that the parts for the +12V rail are missing but could be added. I guess modern 3.5" drives only need +5V to operate? The disk drive itself is identical to a standard PC floppy drive, mine is a TEAC FD-235HF in particular.

PAL device reader, rev. 4

Here are the current project files for revision 4 of the PAL device reader. Please take note that the archive is incomplete and I need to find a few files to add as well as completing the documentation. I cannot provide any support for it, so don't ask!

Atmel ATDH1150USB JTAG cable

Atmel sells a USB JTAG cable for use with the ATF1508 CPLD. There is very little documentation about it available online. For $50 USD, you get a FT2232D, 93C56A EEPROM, and 74LVC244A in the kind of enclosure a hobbyist project would come in:

I think it's well made, but there are many DIY and commercial JTAG cables with identical parts for much less. The connectors are:
  • JTAG-A - Connects to a JTAG header to program ATF1508 CPLDs.
  • JTAG-X - Same as "A", but as a fine pitch connector.
  • TWI (AT17) - Connects to a TWI header to program the AT17xxx FPGA configuration EEPROMs.
It has a status LED that is not powered by the target device so it can function even if the target device is turned off or not connected. The LED states are as follows:
  • Unlit - Default state when cable is plugged in to a PC.
  • Green - Only after the Atmel ISP software has detected the cable and is idle.
  • Orange - When communicating with a device (e.g. during programming, erasing, verify)
  • Red - When an error has occurred.

You can access the EEPROM data using FTDI's FT Prog v2.2 utility program. Start it and hit F5 (or select "Scan and Parse") to read the device settings. According to the program, the FT2232 is set up like so: 

    Chip type:  FT2232D/C
    Vendor ID:  0x0403
    Product ID: 0x6010
    Product Description: 'ATDH1150USB'
    Serial Number: FTS8GSG1 Auto-Generate
My board has a FT2232D. The EEPROM contents include the string "FTS8GSG1" so it's not clear what the "auto-generate" part refers to.

The software used is Atmel ISP v6.7, and it's quite well written. Once you set up a chain file to program the device, you can just click on the "Jedec file" chain item and click "OK" on the Device Property dialog box that comes up to automatically reload a new JED file. This makes development very easy and rapid. So overall it's a good product, but I'm sure cheaper options exist.

CPLD development board

I recently made a development board for the Atmel ATF1508AS(L) CPLD:
It has the following features:
  • 6-bit (2:2:2 RGB) video DAC (can directly drive a RGB monitor)
  • 7-bit audio DAC (can drive a line-in input of an amplifier)
  • JTAG header
  • Socket for Flash/NVRAM (512K max)
  • SD card interface
  • Pushbutton and LED (for user I/O)
  • Two 2x32 headers to access CPLD pins
  • 5V and 3.3V power supply (with power switch and PTC resettable fuse)
  • 28.636 MHz clock
In particular the video output has been a lot of fun, I've tried implementing different kinds of video designs to generate 15 and 31 KHz displays, displaying bitmaps, byte and bit-mapped graphics, playing video clips stored in NVRAM, compositing multiple layers, scrolling, etc. Time permitting I'd like to put my designs online and maybe write a tutorial about working with CPLDs. Coming from a PAL/GAL background this kind of chip certainly seems to have unlimited potential.

SMS Region Mod + YM2413 sound

I've developed a safe region modification for the SMS. The previous method that somebody developed was to short an I/O pin to ground when it was being driven as an output which is potentially damaging. The new method uses a feature of the I/O chip to disable it during the region detection routine and can be added with a 74LS125 and 74LS138.

I also implemented this modification in a 16V8 PAL along with the support functions to add YM2413 sound output:

Here are the relevant files:

This isn't necessarily the best method to for adding FM sound in regards to the analog section and the missing PSG/FM enable and mixing functions, but it's what I could build with the spare parts I had and it sounds decent.

News (6/11)

System 16 odds and ends

I've updated the Sega USB Link project files with a USB BIOS for the System 16B 171-5797 ROM board, and a sample program (memory map viewer) that can be used as a basis for developing System 16B software.

DRAM interface

I was doing some research on the 315-5195 chip and found out it has a DRAM interface, presumably to support DRAM in place of the 68000 program ROMs. This would facilitate uploading new ROM images and being able to immediately test updated software without having to erase and program EPROMs. The related signals are:
  • AEX# (CN4 A20) - Lags 68K AS# by 10 ns. Can be used by an external multiplexer to switch from the row address to the column address.
  • CAS# (CN4 A21) - Lags 68K AS# by 90 ns. Can be used as the column address strobe by DRAMs mapped to the program ROM space. Note: AS# functions as RAS#.

Video ROM access

There are also two additional signals that decouple sprite and tile ROM address bus from the video chips:

  • XGAO# (CN2 A20) - When high, disables output of the '374 at J16 that normally connects VR0-7 to GA3-10. This pin is input by the 315-5192 chip and may direct it to tristate the GA0-2 and GA11-15 outputs as well. GA0-15 can then be freely driven.
  • OBAC# (CN2 B20) - When high, disables both '244s at J6,J7 that normally connect RD0-15 to RDB0-15. RDB0-15 can then be freely driven. CGB0-3 would still need to be isolated from the sprite ROM banking circuit on the ROM board.

If the object and tile ROMs were replaced with SRAMs, these functions greatly simplify the hardware needed for the 68000 to share the SRAMs with the video hardware, allowing it to write new graphics data as needed. Hang-On supports SRAM in place of sprite ROM, so it seems likely they wanted to support a similar feature for System 16B.

ADPCM mute control

One bit of the Z80 sound bank latch drives the mode input of the uPD7759. This always seemed unusual as the stand-alone mode can't possibly work; the chip's message select inputs (I0-7) are grounded and the message start strobe (ST#) is permanently inactive. Not to mention the lack of external ROMs and support hardware needed to address sample data.

But the designers did this intentionally. In stand-alone mode the chip drives the Z80 data and write pins which would cause a conflict, so they added buffers to isolate these signals. Now the chip can operate in either mode, but uPD7759 manual says the mode pin should never be changed during speech synthesis or when idle; as these are the only two states it has, this seems to imply it shouldn't be changed at all and should be fixed to a desired level at power-up. So why toggle the operating mode during gameplay?

A quirk of ADPCM encoding is that you cannot immediately transition from one volume level to another, it takes several samples to accomplish that. This is problematic when you want to cancel playback of an existing sample and start up another. It would be too hard to calculate the sample data needed to transition from the current state to a new one (if interrupting a sample) or to zero (if muting an existing sample early) and there might be some unusual sounds during the transition period.

So the result of cycling in and out of stand-alone mode seems to mute the chip instantly and reset the internal ADPCM decoding state such that new sample data can be sent. Games pulse the pin high after sample playback ends, transitioning it into stand-alone mode for a few microseconds. In some cases they leave it high until the next sample is requested. For whatever reason the RESET# pin isn't used for this purpose; perhaps asserting it during playback causes an audible pop or other undesired noise. Or maybe it was too complex to add a circuit to assert the pin for the required time (18.7us), and this solution used less parts at the expense of operating the chip in an undefined way.

News (5/8)

TMS9929A experiments

The TMS9918A VDP has composite video output, and the TMS9928A and TMS9929A have component video output in the form of luma (Y) and color difference (R-Y, B-Y) signals. As the luma output includes sync information, it can be used for composite video too, if you don't mind being limited to a grayscale display. The VDP can generate about eight unique shades.

I tried using the composite video output circuit from the Elf Color Board which was intended for TMS9918A/TMS9118A chips, and it worked perfectly on the TMS9929A. Here's a slightly modified schematic of the circuit, along with a test pattern display for the SC-3000 personal computer which has an integrated VDP register editor.

I'm currently working on a project to add RGB output to the TMS9929A and adapting it to use standard SRAM instead of several 16Kx1 DRAMs. I'll post more information if the experiments are successful.

Old News (4/10)

DECO cassette drive overview

Data East made an arcade system that loaded game data from a miniature cassette, that was played back from a custom digital tape drive. The drive chipset was develped by Mag-Tek who are still in business and make magnetic strip based products. I was asked to look into how the cassette system works so that games could be dumped and preserved. I'll present an overview of the hardware and an (untested) dumping circuit.

The cassette drive connects to the "BIO-8" circuit board by means of a 2x10 pin connector: 

                    +----------+
     TAPE_SENSE     |A1 <   B1 |    (N.C.)
     (N.C.)         |A2     B2 |    (N.C.)
     RCLOCK         |A3     B3 |    RDATA
     GND            |A4     B4 |    (N.C.)
     REV            |A5     B5 |    FWD
     FAST           |A6     B6 |    (N.C.)
     (N.C.)         |A7     B7 |    (N.C.)
     EOT/BOT        |A8     B8 |    (N.C.)
     +12V           |A9     B9 |    +12V
     GND            |A10    B10|    GND
                    +----------+

Cable "E" has a 2x10 header that plugs into this connector, and it has a black plastic arrow molded on it which points to pin A1 as shown above. The other end of the cable is a green edge connector with gold contacts that plugs into the cassette drive PCB.

TAPE_SENSE is a switch output that is 5V when a cassette is inserted and the lid is closed, and 0V when no cassette is inserted or the lid isn't closed. The switch is a spring-loaded metal pin near to the motor.

EOT/BOT is the output of a photodiode that can see light emitted from a LED that is mounted at a 90-degree angle from it. The cassette contains a reflective metal strip behind the tape, such that an opaque section of tape blocks light, and the transparent leader permits light through. This output is 5V when the leader portion of the tape is visible (meaning you are at the end or beginning of the tape) and 0.40V for any other condition: opaque tape present (you are in the middle of data), no cassette inserted, or lid open regardless of cassette being present or not.

FWD, REV, and FAST are inputs that control the cassette spindle motor when driven at +5V and are inactive at 0V. FWD and REV cannot be asserted at the same time, and the BIO-8 board has logic to prevent this condition. Normally the cassette speed is appropriate for playback when only FWD or REV are driven, and asserting FAST along with either one of those signals is used for a fast-forward or fast-reverse.

RCLOCK and RDATA are the digital data that is encoded on the tape. The clock signal is used to determine when the data signal can be sampled. These outputs are 5V for a '1' bit and 0.40V for a '0' bit. Because the tape passes by the pickup head faster as one spindle gathers tape, the clock and data rate increase during playback. It seems that the MCU on the BIO-8 board is fast enough to handle the steadily increasing data rate.

DECO cassette drive dumping

I have developed a circuit that is connected to the cassette drive cable "E" by splicing the RCLOCK and RDATA wires so that the signal can be tapped. RCLOCK is a white wire at the ends with a gray sleeve and RDATA is a red wire at the ends with a black sleeve. You can also splice the black wire with the foil "E" label on it (corresponding to position A10 on the above diagram) for ground. The circuit should allow normal operation of the board in addition to providing audio outputs for dumping.

It converts the output levels to 1.25V, low-impedance outputs that should be suitable for driving the line-in input of a PC sound card. To prevent damage, I would recommend connecting the outputs to a cheap amplifier first, which you can use to adjust the volume. For this reason the schematic only shows RCA jacks.

Note that cable "E" has no +5V line, so you'll need to tap that from the PSU that powers your DECO boardset.

Please record the audio at 44100 Hz or higher and check the volume levels to avoid clipping. The right channel (clock) will look like a square wave, and the left channel will look like a rectangular wave. I haven't been able to test the circuit myself as I need to transplant parts from two different drives to make one working one, so please use this circuit at your own risk. That said, I'm looking forward to seeing some new tape dumps!

PAL TurboGrafx information

NEC released a PAL variant of the TurboGrafx-16 (model HES-TGX-11), which is fairly amusing as the video chipset only supports NTSC. To accomodate PAL displays, a chip (PCZ80 by NHE) clocks the VCE slowly during several scanlines such that a 264-line NTSC frame fits within a 313-line PAL frame. While it can control the CPU speed, it does not slow it down. This means NTSC software has more time to execute code during the "slow" lines, but in practice this does not seem to cause any problems. During the slow lines, the PCZ80 chip continues to generate regular horizontal sync pulses on its composite sync output, such that all 313 lines are present for a PAL monitor.

The video output is fairly interesting. Analog RGB from the VCE is fed into a CXA1145 encoder that is hardwired to PAL mode. It generates S-Video and composite video, the latter of which goes to a 5-pin DIN jack with an unusual 270-degree pin spacing. The S-Video is not accessible but appears to be fully implemented. The composite video output of the VCE is completely bypassed. To provide PAL compatible display timing, the PCZ80 chip generates a 4.48 MHz color subcarrier for the CXA1145 chip.

This arrangement introduces a few subtle differences. The color subcarrier strip bit in the VCE control register does nothing as now the CXA1145 controls the color burst. The frame size bit (262 or 263 lines) does nothing either as the PCZ80 forces a NTSC frame to always be 264 lines. Games that use the vertical blanking interrupt have slow music, those that use the timer do not. No games were reprogrammed to handle PAL differences, and regular North American TurboChips run on the PAL system, albeit letterboxed and slower.

A/V DIN connector modification

The A/V connector has the following pinout (with the system's connector facing you, pins are 5 to 1 from the 270 degree position going clockwise to the -90 degree position): 

    1. Composite video
    2. Right audio
    3. Ground
    4. +5V DC
    5. Left audio
I removed the 270-degree DIN connector and replaced it with a more standard 180-degree one, then cut the traces to isolate the solder pads and rewired the connections to match the CoreGrafx II / SuperGrafx A/V cable pinout:
  • Solder a wire from the side of R155 facing the backplane connector to DIN pin 1.
  • Solder a wire from the side of R150 facing the backplane connector to DIN pin 2.
  • Solder a wire from DIN pin 3 to the shield ground tab nearest to it on the board perimeter.
  • While it isn't necessary to connect +5V, you can solder a wire from the pin of L109 nearest to the board perimeter to pin 4 for compatibility.
  • Solder a wire from the side of R149 facing away from the backplane connector to DIN pin 5.

PAL timing and NTSC modification

There isn't much information about the PCZ80, though sources seem to indicate it is a Z80-based microcontroller. However it generates complex high-frequency signals, so either it has a very capable timer peripheral or it isn't a MCU at all, and is some kind of small-scale gate array. Relevant pins are: 

Pin 2 - Reset input.
Pin 4 - Unused (active-high horizontal sync output)
Pin 5 - Unused (active-low horizontal sync output)
Pin 6 - 21.32825 MHz clock input (X201 via 74HCU04)
Pin 10 - 17.73448 MHz clock input (X202 via 74HCU04)
Pin 11 - 4.48 MHz clock output to CXA1145 "XO IN" (X202/4)
Pin 15 - 21/17 MHz clock output to HuC6260A
Pin 16 - Composite sync output to CXA1145 "C-SYNC IN"
Pin 17 - Vertical sync input from HuC6270
Pin 22 - 21.32825 MHz clock output to HuC6280A

While not fully implemented, to modify a PAL system to NTSC make the following changes:

  • Replace X201 with a 21.477270 MHz crystal.
  • Replace X202 with a 3.579545 MHz crystal.
  • Remove IC115 and socket it.
  • Jumper IC115 socket pin 6 to pins 15 and 22.
  • Jumper IC115 socket pin 10 to pin 11.
  • Cut and lift pin 7 of IC117, tie to +5V.

    This clocks the Hudson chipset at NTSC speeds, and provides a 3.58 MHz color subcarrier for the CXA1145 as well as putting it in NTSC mode. What's untested is recreating composite sync for the CXA1145. I think you can do it by XORing the V-Sync and inverted H-Sync outputs of the VCE together, but the real VCE composite sync leads/lags from these two sync outputs. So the picture may not be centered and the equalization pulses will be missing; though in practice most modren monitors don't need them. While the VCE provides a composite sync output on the luma (Y) pin, it isn't clear if a LM1881 sync splitter could be used without the rest of the composite video circuit being implemented, which is otherwise missing on this system. And lifting the VCE pins to make the necessary connections could be quite difficult.

    Old News (1/12)

    Spring cleaning

    I recently had a chance (after many years) to dump a FD1094, and after digging up all the utility programs and information from back then I realized I should have put all this stuff online so it would be easier to find. Doing this work also got me curious about documenting the ROM board used by several System 24 games too. Here are a few files:

    I couldn't find the source to the USB link utility and can't be bothered to rewrite it at the moment, but Windows executables for it are provided in the various archives. I'll provide source for a rewritten version eventually if people have a need for it.

    The disk dumping tool is a little crude, you have to specify the disk type and reassemble the program before running it. But it works, and that's all that matters. Speaking of which, these tools use SNASM68K (not included) which has an interesting quirk: your PATH environment variable must be 250 characters or less or it will crash outright. Keep that in mind if it fails unexpectedly.

    To the best of my knowledge I believe we can brute-force FD1089 keys now, so there is no need to dump those CPUs. The only missing information that can't be determined is the bitmap that specifies encrypted areas, but that's easy enough to infer from program behavior. As a result the FD1094 dumping tool does not support the FD1089. The ones I worked on previously were done manually and the process was never fully automated unlike the FD1094.

    With the help of Mark McDougall I've made schematics for the Super Magic Drive copier. These units tend to get damage from a leaking battery, so I hope the schematics help owners with repair efforts. I'm also providing a link to the last update of the SMD utility software I wrote, which has a DRAM test for those of you who want to check if your SMD is functioning properly.

    If you are having trouble dumping games on your SMD, take a look at the schematics -- there are a lot of signals from the Genesis that aren't connected to the pass-through cartridge slot. You could easily solder wires to restore these connections. If anyone tries this I'd love to know which games benefit. I'm sure Virtua Racing is one of them.

    Work on the PAL reader is still underway, it's just taking longer than I expected. To answer some very common questions it isn't ready, it isn't for sale, and I won't build you one. This website is a hobby of mine, not a business. :)

    • www.digits.com www.digits.com