Retrochallenge wrap up
Retrochallenge 2018/9 is officially over, and judging was completed a few days ago. I'm proud of the amount of progre- Wait I won? I won! I won!!
Ok, I'm a little excited, I went in not expecting to end up in a top spot, being a rookie and all. Big thanks to John Linville and Michai Ramakers for hosting and judging the competition. Also huge thanks to all of the other contenders. As I said before, following along their diverse set of projects while my own progressed was the best part of the whole thing.
The sheer variety of projects really surprised me, with submissions that ranged from dealing with 1960s era "portable" computers, to 1990s era obscure gambling on the Super Famicom. Some mostly dealt with hardware, while others were entirely software (like Forth-ception) and some involved both. A few dealt with RE-engineering antiquated tech, some involved building new-old software and hardware. A few had a history lesson mixed in (mine included.)
So what's next for the projects I've been working on? I started this blog to document reverse-engineering of the AY-3-8500, and most of it's circuits have been explained so far. Because of this, I'm moving REing it to a back burner in favor of a longer-term project. The chip simulation is very accurate emulation except for one major flaw, it runs at less than 1% of the actual hardware's speed. I considered making a simulation of it based on the datasheets, however this isn't true historically-accurate emulation, and the process wouldn't be easily repeatable with similar chips that are less thoroughly documented in datasheets.
The only way to accurately re-create some of these dedicated game chips is digitize the logic/schematic from die photos. Transistor level simulation unfortunately, is way too slow to be playable. One way to increase speed would be to implement the simulation in a faster language such as C++, the visual6502 team apparently tried this but didn't reach real-time speeds.
Last month I realized that the circuitry could be greatly simplified and still function the same way. Why say, simulate the dozens of transistors which make up a counter when you could emulate a counter with a few lines of code? Since the beginning of October, I've been working on a program called DLAET or Digital Logic Abstraction and Emulation Tool (pronounced "delete" or "dah-leet"). It works like a logic synthesizer in reverse, once done it will automatically convert low-level transistor netlists into more abstract logic, such as gates, counters, PLA, signal dividers, etc...
|A debug image from DLAET. The green, red, and yellow wires are redundant,|
and have been logically combined with the blue ones
The high level netlists will be converted in to high speed C code, which will emulate the logic in software. DLAET is not an emulator, it's a tool to create emulators from schematics/netlists. The chip I'm using for the initial testing is a >2000 transistor, 2Mhz chip (aka the AY-3-8500). I did some back-of-the-napkin speed calculations, which suggest that a modern CPU should be able to run the test chip at or above real time speed. I also put some thought into what emulation back-end the output code should be tailored for, and decided on MAME. I'll make a fork of it as soon as DLAET spits out some working C code.
The idea of an automatic logic abstracter has some other possibilities. Along with these discrete game chips, many ASICs in home computers and arcade machines. With moderate additions to the code, the digital portions of discrete game boards could be optimized to run much faster, or be emulated in the first place. The output code could also be modified to produce VHDL/Verilog descriptions of the chips put into them instead of C, allowing a physical emulation of the hardware.
Speaking of processing programs, I wrote a program to proces could be emulated if the necessary decapping, photographing, digitizing and processing work went into them. With moderate additions to the code, the digital portions of discrete game boards could be optimized to run much faster, or be emulated in the first place. The output code could also be modified to produce VHDL/Verilog descriptions of the chips put into them instead of C, allowing a physical emulation of the hardware.
Speaking of processing programs, I wrote a program to process image files into netlists back in spring. A cleaned up version of it will be put online, along with the source images for these various projects, to help anyone crazy enough to aid in digitizing these old chips. I stumbled across some similar programs online recently such as Oliver Gailbert's dietools. If only I found that back in February, I may have not created my own program from scratch, or at the very least; not name it "ChipTools" which sounds like a cheap knock-off.
Along with that project, I've worked a little on the SP0256 simulation since the end of September. Unfortunately its slow going, with no schematics, correcting errors involves finding something that isn't working as it should, then tracing the signals to suspicious looking areas. Whenever I make decent progress, I'll update it and post about improvements.
Looks like I've got no shortage of things to work on! I plan on posting updates every few weeks, so stay tuned. Along with these projects, there are one or two side projects that are unrelated to 1970s microchips I might end up posting about as well In the meantime, if you have questions or suggestions, hit that "comment" button below.