The D128

Views of the 128 Prototype (.jpg). These pictures were taken by yours truly of Bil Herd's prototype 128 at Vintage Computer Festival East 4.0.
Board Overview (187K) | "Prototype Only" (30K) | ROMs (48K) | VIC Daughterboards: Daughterboard 1 (121K), Daughterboard 2 (116K) | MMU Daughterboard: Board (103K), Chip Notations (81K) | PLA Daughterboard (153K)

Introduced Development model only.
Hardware 6509, 128K RAM.
Graphics and Sound VIC-II; 6845 CRTC; SID.
Eventual Fate Became the 128.

Comments
While this computer is extremely, extremely, similar to the 500 series, the D128 comes from a different development track -- the 500 was part of the 6509 evolution, while this unit is truly the direct ancestor of the modern 128. The development history of the 128 is particularly fascinating -- this story comes very courtesy of the original engineer, Bil Herd (read his original post in the Commodore Knowledge Base).

Originally, the D128 was a 6509 system with a 6845, very similar to the 600/700 series, under design by fellow engineer Bob Russell; 64 compatibility was not considered part of the original design, which Herd, having just come off the notoriously incompatible 7501 line, argued with. His first battle was over the 8563, essentially a colour 6845 in those days, which had been in development with the CBM 900 for approximately a year and a half at that time. Since the 8563 had not been designed specifically for the 128, problems were inevitable, obvious and prolific. For one, the chip did not behave identically to the 6845, contrary to what Bil had been led to believe, and the timings were quite different; worse, the 8563 ran off a 16MHz oscillator (the VIC-II runs off a 14.31818MHz crystal; since it generates the clocks for everything else, so does the rest of the system), so memory access timing became hit and miss. Early VDC chips failed memory access every third of a second. This wasn't fixed until December of that year. Another ludicrous problem was that the 8563 didn't generate any IRQs to signal it had finished a video task; VDC designer Kim Eckert brightly explained to Herd that this was not required because the entire system could simply wait and poll the VDC's registers (never mind other IRQs or the fact you might have to bank in I/O specially to do this) to see when it was done. This became a popular joke at Commodore's RandD labs: after all, ringers on phones aren't necessary either. You can simply pick up the phone over and over and see if someone's there. Herd notes pucklishly that the local bar owners wondered why Commodore engineers were always messing with the pay telephone. And yet another gag was the 8563's memory transfer feature. While it was supposed to be useful for screen scrolling, it only took 256 characters at a time, less than a sixth of the screen, and the register had to be written to twice or the VDC would invariably forget a character.

Worst of all was a final reengineering of the 8563 to incorporate a back-bias generator: the chip could no longer display the first couple of characters on each line completely (and when it heated up, it would not display them at all); each chip got finicky about its power demands (so the power supply had to be adjusted individually for each unit); and because of the memory transfer quirk it took close to 10 seconds to load the font into the chip when the computer started up (and then it would only fritz occasionally). And these were the good ones, which were rare: of a US$40-$120,000 run of chips, only three or four in the batch would work. Naturally, the VDC designers (Eckert and wife Anne) were on vacation by now. As CES loomed that December, the only fully working 128-custom chip was the CPU. While the double memory store trick worked, no one had bothered to tell CP/M developer Von Ertwine about it as he wrote CP/M Plus at home as a consultant. Wisely, he had not kept with the evolution (devolution?) of the VDC, but was using a partially working early version instead. To keep the 8563 cool and thereby evade much of the silicon's bugs, he took the tiny metal butter cup out from his popcorn popper, placed an icecube in it, and put the cup on the 8563. Herd estimates he got about half an hour's work per icecube. Von didn't find out about the VDC's checkered past until the day before the convention (he repaired CP/M the same day he found out, to the designers' amazement), and even then the VDC was still not working. To fix it, Herd connected its indicator notch to the nearest ground pin (the indicator notch has a gold pin connecting to the substrate, so Bil was basically grounding the entire chip), added pullup resistors to the outputs and jacked up the power supply to 5.3v (diminishing the effective lifespan of the chip to a few days, enough to get them through the convention). For the frequency mismatch, the VIC chip's 8.18MHz dotclock was doubled and fed to the VDC in lieu of its normal 16MHz input. This tweak was very successful (and very hasty; the original PCB for it was produced in a blindlingly quick 12 hours). Naturally, these fixes started wreaking havoc with 64 mode. Units were surreptitously marked as to which mode they could do correctly. At the show, the adjustable power supplies were a big hit (probably because, unlike the infamous 64 bricks, they worked); engineers simply espoused the benefits of adjustable voltage and turned the control as they switched modes in front of an unassuming populace.

64 mode compatibility became another issue (here's Herd's post on that topic); paradoxically, the Z-80, which was not in the original specs for the D128 either, became the solution and saving grace. In the opinions of much of the 128's designers, Commodore marketing had once again looked before they leaped by announcing the 128 as "100% compatible" (even now owners of 128s can attest they are extremely compatible but not wholly compatible). At that point in design the Z-80 was not part of the specification, and Herd et al. were noticing that the 64's Z-80 cartridge would barely work 20% of the time in prototype 128s. (It didn't even work fully reliably in 64s.) When it did work, it drew an extra 0.5A that was just not workable into the power supply requirements, so Herd "accidentally" designed the Z-80 into the system board instead. This strange solution turned out to be the fix to another host of problems. In between the intricacies of the 64's memory mapping and video architecture (Bil muses about 'colour character mode with I/O swapped out under UltiMax mode'), and under the onus of achieving full compatibility, the designers started investigating three of Commodore's own cartridges that would not work in the 128. Two of the cartridges turned out to be a bad batch of ROMs. The third was the Commodore Magic Voice Cartridge, which behaved rather rudely with the expansion port lines (as soon as it saw the processor going for reset vectors, it would pull GAME low and hopefully swap out the 64's ROMs for the cartridge's). Since these signals were never meant to be altered in real time, the 128 would behave erratically (i.e. crash) because the CPU would never get to initialize the MMU to 64 mode before the cartridge had snatched its ROMs (and therefore its bootstrap code) away from it. So the Z-80 was recruited, since it boots from a different memory location, and given the job of polling for cartridges and making the command decision for which mode to start up in. Specifically, it would do an equivalent of the POLL routine and initialize the MMU to 64 mode if it saw activity on the expansion port (or if the C= key is held down). Not everyone liked this idea: Commodore Australia called the RandD labs to complain that they would rip the Z-80s off the board if the 128 arrived down under with the chip still there. Nevertheless, whenever you turn on your 128, the Z-80 chip is the master processor on startup to this day.

The reason 64 compatibility is still incomplete on the 128 is because the altered VIC chip still holds registers for 128 mode features, including 2MHz mode and the 128's extra keys. Most of the programs that misbehave on a 128 running in 64 mode write to more VIC registers than are really present. On a real 64, the rest is unmapped I/O and the writes are ignored. On a 128, you've just written to these extra registers (most of them hit location 53296 and kick the processor to 2MHz, which fouls the screen). Also, much of the I/O area, which mapped to dead space on the 64, now maps to the MMU ($D500) and the VDC ($D600). Writes to these locations could cause interesting and probably undesirable behaviour.

The pictures above are of Bil's later prototype, after the 6509 had been scrapped. On this unit, the VIC-IIe, MMU and PLA "chips" under development are on separate daughterboards for easier testing and alteration. Other than the chip population, the VIC-IIe daughterboards look identical. Overall, however, the sum gestalt of the prototype is very much like the final 128 design.