Apple /// PROM logic decode

3 posts / 0 new
Last post
Offline
Last seen: 3 years 2 months ago
Joined: Mar 16 2018 - 01:55
Posts: 26
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.

Verault's picture
Offline
Last seen: 5 months 2 weeks ago
Joined: Dec 21 2017 - 14:19
Posts: 372
Fantastic info. The Apple ///

Fantastic info. The Apple /// needs as much love and support as it can get. Thankfully it seems to be getting it this year. I have a III and III plus, let me know if you need help testing down the road. My III has a 128KB 12v ram board. My III plus has a 256KB 5v RAM board.

 

By the way, I was looking at an Apple III selling on ebay recnetly and was amazed it has a sticker showing the Apple III was sold in 64KB and 96KB RAM configurations! I wonder how many of those were out there?

https://www.ebay.com/itm/164968232973?nma=true&si=BrffUAdkVXvc%252BLDJ2VTrE5yqdr8%253D&orig_cvip=true&nordt=true&rt=nc&_trksid=p2047675.l2557

Offline
Last seen: 3 years 2 months ago
Joined: Mar 16 2018 - 01:55
Posts: 26
Apple /// memory configurations

I'm moderately certain that NO 64K machines were sold, and only a very few 96K. The stickers must have been designed before they were aware of just how much RAM would be needed to run SOS, Business BASIC, load a reasonable BASIC program, and use graphics. 64K wouldn't do it; I'm not sure that SOS would even boot. Even 96K was marginal, and that configuration was quickly discontinued.

Shortly after the Apple /// was introduced, my boss had a 96K Apple /// system on loan from a dealer for a few days, and asked me to evaluate it. We did not experience any of the hardware problems that were common on early machines. I recommended against purchase, because what he needed was more advanced hardware capabilities (such as 80 column text) when running Apple II software. We could modify the Apple II software, but rewriting it entirely for the Apple /// was out of the question. The Apple //e was what we needed, but unfortunately it wasn't aannounced until nearly three years later.

Thanks for the testing offer. I have a pretty good assortment of /// and ///+ hardware on hand, but at some point will need testing on more machines.

Log in or register to post comments