Apple /// PROM logic decode

The Apple /// uses PROMs and masked ROMs for much of its logic functions, in order to fit everything (but the DRAM) onto the motherboard. Many of the PROMs are bipolar 1024 x 4, which means they have 10 address inputs and 4 outputs, so they can implement any four logic functions of ten variables. Later machines, like the Apple IIe and original Macintosh, used PAL chips for this, but the PAL chips didn't exist, or at least weren't readily available, when the Apple /// was being designed. PROMs can potentially implement more complex functions (having more minterms) than PALs, but they are more prone to output glitches, so they usually are only suitable when the output doesn't need to be continuously valid, i.e., when it's loaded into a register by a clock pulse that occurs at least the PROM access time after the inputs have stabilized. MMI later took to calling bipolar PROMs "PLE" (Programmable Logic Element) and offered a PLEASM assembler (by analogy to PALASM), but the idea never became very popular. I suspect that Apple developed their own program to turn logic equations into PROM images, as the Apple /// service manual gives equation files for some of the Apple /// PROMs.

Unfortunately the Apple /// service manual does not give the equations for ALL of the PROMs; in particular, one of the PROMs needed for the 5V memory board has an incomplete listing, and another is missing. Because of that, and also because I want to decode the PROMs used for the third-party 512KiB memory board, I wrote a Python program to decode PROM imags into logic equations. I haven't yet written up documentation or examples, but the program is on github: https://github.com/brouhaha/rom2eqn/

Currently the program can output equations in either VHDL or a subset of CUPL. The logic equations are minimized using Quine McCluskey tabular minization, using a Python library by Thomas Pircher. This results in equations in strict sum-of-products form, whcih is not necessarily the most desirable form, but it is not at all obvious what heuristics could be used to convert it into a more desirable form. If you look at the equations in the Apple /// service manual, they are definitely NOT given in flattened sum-of-products form, but rather in whatever form the engineer found most convenient in which to write them.

I plan to try using ATF22V10 or ATF750 CPLDs to replace the memory control PROMs (C11, C12, and C13), though they are not pin compatible, as the original PROMs are 18-pin and the CPLDs are 24-pin. I've just designed an adapter board and ordered a few PCBs.

My intention is to eventually make a new 512KiB memory board using SRAM chips. The existing 512 KiB DRAM memory board not only replaces the C11 through C13 PROMs, but also runs wires and cables from those and the 6522 to the memory board. I will have to do the same. Although I will look at the design of the orignal board, my design will not be a clone of it. I also plan to make the memory board capable of supporting some other enhancements to the Apple ///, so it will actualy use an FPGA rather than the CPLDs which I'm only using for a proof of concept.