Creating an Arcade ColecoVision Clone
This is my second time trying to post this.. the first time a browser glitch discarded my post, and I couldn't be bothered to type it up again. But now I feel like it.
With Super Space Acer nearing some form of completion after almost 25 years, my thoughts have turned to its final destination, which I'd always hoped was an arcade cabinet. I came close years ago with "SSA:DX", which was a emulation hack that replaced graphics, music, and some of the gameplay, but I lost interest in that approach. This version is much more likely to happen.
I decided that since the ColecoVision version is the farthest along, and because I have relatively mature tools for it now, that I would base it on that. But I needed a JAMMA-based ColecoVision. So I started sketching, and after a few nights of running through scenarios, I came up with a compromise system that I'm pretty pleased with.
The starting point, of course, is the ColecoVision. That defined the memory map and the hardware base. Z80 CPU, SN76489 sound generator, and a TMS9918A VDP.
The first thing to go was the VDP. Since I need RGB out for JAMMA, the 9918A is right out. It can be generated from the 9928 (as Baby Pac Man proved), but a simpler solution was to go straight to Matt Hagerty's F18A (codehackcreate.com), which is a plugin solution that doesn't require the external RAM. Even better, it has zero wait-state access, a built-in GPU, and extended graphics modes, while offering nearly 100% compatibility. As a finished, ready-to-go product, it was the ideal choice that offers a free upgrade to boot (and it can be installed in real ColecoVisions too). It outputs VGA, so will require a small amount of work to output 15Khz RGB for JAMMA - I'm working with Matt on what that will take. But that's just an FPGA stream change, the hardware is good.
The F18A has an additional benefit - like the 9918A it generates two clocks. One is suitable for driving the Z80, and the other is suitable for driving the sound chips. That saves on clock generation circuitry. I also planned for a VHDL change to allow software to double the CPU clock, allowing for a faster Z80 to be in place.
Next I looked at memory expansion. The ColecoVision memory map has 24k of space between the BIOS and the cartridge, so filling that was obvious. At that point, I wondered about the OpCode Games Super Game Module. I thought it would be nice to have the support of a developer like that, so maybe I could adopt his memory map.
It made things a little more complicated. My original memory map broke things into 16k chunks, but this requires that the first 8k also be pagable. The BIOS needs to go in and go out. After some research, I also found there were some bad feelings over people using the Megacart cartridge scheme (which I also wanted to adopt), and wondered if that would extend here.
After much consideration and several designs, I finally compromised. I went back to my 16k pages, but I made paging the BIOS out and replacing it with RAM compatible with the SGM method (which itself is based on the Adam paging). This has two benefits - for one, my system will fail Opcode SGM system detection, meaning unauthorized titles won't "just work", but the actual code to make them work remains familiar to SGM developers, on the off chance anyone else is interested in this. To me, that's the right answer.
The upper half of the memory map contains the cartridge ROM. Since I am familiar with the Megacart and have a toolchain for it, that's what I wanted to use. The first 16k of cartridge space is fixed, and the second is pagable. I preserved this scheme, but in order to both reduce the hardware and eliminate potential bad feelings, I leave the banks non-inverted compared to the Megacart scheme (that is, bank 0 selects the first bank on the EPROM, not the last one). This also means that ROMs don't need to be built for the exact right sized EPROM like Megacart ROMs do - they will mirror properly. At the same time, the techniques and actual code paths for Megacart software does not need to change, so it remains familiar to developers and my existing tools will continue to work for me. Unlike Megacart, I also opted to go with 256 pages instead of 64, giving a maximum space of 4MB (this might break some existing megacart titles if they don't have enough space at the end of a page, but again, it's not hard for the developer to work around).
So this produced a system that was largely compatible with the ColecoVision, but expanded, with a 16k BIOS, 16k RAM, and 32k cartridge space. In addition, the BIOS can be swapped with another 16k RAM giving 32k total, and the cartridge space can be paged up to 4MB.
The Adam paging scheme for the BIOS range uses two bits, so I decided to fill in the unused two settings with two halves of a 32k NVRAM, for high score saving. This is a stretch goal that I'm not 100% certain of yet, but it's not hard to add.
With the memory map and video defined, I still had one more thing to look at before closing the book on the SGM. The SGM added the MSX sound chip, an AY-3-8910 (presumably to make MSX ports easier). The port that it lives on is unused in my design, so again as a stretch goal, I added it to the system. I'm not entirely sure how I feel about this one, we'll see how it plays out.
An important part of hardware developing is debug, so I wanted to add a serial UART for printing debug messages to a console. After a little research, I settled on the FT2232 - this is a very nice USB serial interface chip with a parallel output suitable for CPU interface. I can basically drop it on a port and have bi-directional serial communication over USB - very nice option for modern systems.
Finally, the controllers. Settling on the wiring for the controllers was probably the hardest part of the design - and the least compatible with the ColecoVision.
The hardware interface itself I left identical. This only made sense, to be compatible with existing libraries and even existing software. (However, it's a bit of a mess, requiring three port ranges, and overlapping the sound chip! Yikes.) But since JAMMA systems don't have keypads, I completely discarded the keypad concept and replaced its bits with discrete buttons.
Using spare pins on the JAMMA harness it's simple to get 5 buttons per player, and there were enough inputs for this, so I did. (I had a game that did so back in the day, the spares are right there beside the mapped buttons). There are also enough bits for separate start buttons and coin inputs. So far as service switches, I mapped test, tilt and service. There's technically one bit spare.
One unknown I need to test is whether monitoring the coin inputs via software will work -- I may need an external latch to ensure the coins are never missed. I don't want to rely on maskable interrupts and the NMI is already owned by the VDP - but an external latch is easy to add if needed.
Since there were a good number of available bits for inputs (16 bits per player), I also mirrored the buttons on the two reads. Reading the joystick side, you get the four directions plus B1 and B2, like normal. Reading the keypad side, you get all 5 buttons plus Start (including B1 and B2). This may help reduce load on systems that only care about one or the other, or not. It didn't really hurt. Note that since I don't encode patterns like the keypad does, ColecoVision's B3 and B4 is not the same as mine.
Finally, there was the input. I really wanted to just be able to drop in a big EPROM, and I chose 4MB because that was the biggest DIP EPROM I know of. I'm still wavering on this - and the ROM source may end up being a flash on the PCB instead, updated via software. The USB port makes that easier, at least! The memory mapper takes the BIOS from this space as well, meaning that every update can replace the BIOS too - the BIOS can then contain the ColecoVision BIOS if it needs that to run, or can simply contain more game code.
So far I have most of the circuitry worked out on paper, except I haven't selected latches for the controllers or designed the amp (I might just use an external amp anyway). I'm starting the schematic capture. I'm hoping by mid next year to have a prototype running (maybe sooner if I just hack a ColecoVision, but I want to test my circuitry). My biggest uncertainty is whether to build the final units with discrete logic, or use an FPGA for all the glue (and probably the sound chips, too). The FPGA approach will certainly go faster, and it'll still have a real Z80 on board. It will also simplify the board a lot - the current discrete design is 21 chips, and that doesn't include off-board interfaces. With an FPGA I can take it down to 7. That's really the strongest argument in favor, but it feels like cheating.