For RC2015/07, I’m going to hook up an old vector display (the retro part) to a modern microcontroller and either write a new game for it or port an old one. Vector displays were used on computers from the 1950s through the 1980s, and are perhaps most known to the public as the type of display used in Atari’s Asteroids arcade game. In the 20th century, vector displays offered sharper images for line art than did the raster displays which became more common starting in the 1970s.
I’ll use one of two different HP vector display systems, a 1338A tri-color beam penetration display with analog inputs, or a 1345A monochrome display with a built-in display controller with a parallel digital interface.
The 1338A is particularly interesting because the beam penetration tube allows for green, yellow, and red to be displayed (but unfortunately not blue), but with the same sharpness found in monochrome vector displays. More typical color vector displays, such as those used in later Atari games including Tempest, use a normal color CRT with a shadow mask, so the vectors wind up being fuzzy and composed of discrete dots.
For the 1338A, I could build my own interface, or use an HP 1350A or 1351A Graphics Translator, which provide a vector generator with an IEEE-488 (aka GPIB or HP-IB) interface.
I’ve nearly finished tracing the Pacer control panel interface card schematic. I haven’t yet traced the connections of one NOR gate of the 7425 at position 6A, and one inverter of the 7404 at position 5C. It’s possible that they’re unused.
As with the other Pacer schematics I’ve reverse-engineered, there are probably errors and omissions. The purpose of reverse-engineering this wasn’t necessarily to produce perfect schematics, but to develop enough understanding of the Pacer to diagnose and repair faults, and to design new memory and I/O cards. Considered in that light, the reverse-engineering process has mostly been successful. Continue reading
I finished tracing the Pacer user memory card schematic. Most of it seems fairly obvious, except bus pin 25 and the E1/E2/E3 jumper. There are also some functional problems with this particular card. Continue reading
The PACER memory board has sockets for four MM5204 512×8 EPROMs. The MM5204 is somewhat hard to come by, so I’ve designed a small adapter board to plug into an MM5204 socket and accept a common 2716 EPROM. Only the lowest 1/4 of the 2716 is used. Continue reading
At present the RAM on the user memory board in the PACER isn’t working correctly; the four most significant bits (D15..D12) are always reading as ones. Since this is true for all four banks of RAM (0000-00FF, 0100-01FF, 0200-02FF, and 0300-03FF), this probably isn’t a failure of one of the RAM chips, but rather of one of the DS8833N bus buffers. Those are fairly uncommon and I don’t think there are any pin- and function-compatible substitutes, so I’ll have to buy some from a broker or an eBay seller.
I’d like to dump the contents of the PACER monitor ROMs and disassemble the code, but at the moment that’s more of a challenge than one might expect. Continue reading
I’ve created a Github repository for my PACE assembler and simulator, which together with some very incomplete support for National’s IMP-16 multi-chip processor, I call ns16. It is released under the GPLv3. This was all work done back in 2009 and 2010, except for a small amount of cleanup I just did. There’s still more cleanup and documentation needed.
I finally got around to renewing my ARRL membership, after it had been lapsed for far too long.
After quite a few hours with a continuity tester and magnifier, I have the PACER CPU card mostly figured out, and have drawn a schematic . I haven’t identified all of the passive component values, and there are probably other errors and omissions, because I’m not trying for perfection, but rather to understand enough of the machine to repair problems and design a memory upgrade.
The PACE data bus is not fully TTL-compatible, though for read cycles a TTL buffer can drive it, and the PACER uses 74367 hex tristate buffers for that. For address and data output from the PACE, it has PMOS open-drain outputs, so pulldowns are required, but the PACER doesn’t have any. National Semiconductor recommended to use the DS3608N hex MOS sense amplifier without pulldowns, but since the DS3608N data sheet does not indicate that it has internal pulldowns, I don’t really understand how that can work reliably (or at all), though it obviously does.
One of the things I’d like to accomplish in RC2015/01 is to get some non-trivial software running on the PACER. In addition to hardware restoration work, this will require building a memory expansion, because as supplied it only has 1Kx16 of RAM (2K bytes). There isn’t much PACE software left in existence, not that there was ever a whole lot, but one thing that is available is FIG-Forth. PACE FIG-Forth requires a little over 3Kx16 of RAM, plus more for user words and variables, so my memory expansion should be to at least 4Kx16 (8K bytes). Continue reading
I’ve written about what I did with the PACER before the RetroChallenge, so henceforth I’ll describe what I’m doing for the RC. I’m starting with tracing out a schematic of the motherboard/backplane, including the power supply, the eleven edge connector positions, which are easy because they’re all wired in parallel, and the three IDC headers positions and one DIP socket footprint.
As supplied, only one of the IDC headers was present, and was cabled to the front panel board. The DIP socket footprint does not have a socket installed either. There are no markings that provide any clue as to any intended use of these extra connectors, but perhaps as I trace the wiring I might gain some insight as to their purpose.