While the 64 became the best-selling single computer model of all time largely due to a comprehensive game library, Commodore International‘s follow-up a few years later in the form of the Plus/4 was widely considered a flop.  Within a year, resellers had stopped carrying the new machine and Commodore was unloading them through closeout channels as varied as eastern-European public schools and mail-order/TV commercials in the U.S.  Not much more commercial software had been written for the new platform by the time of its demise than at its 1984 introduction (Micro Illustrator, Jack Attack…almost everything by Commodore’s own software group except my favorites Blazin’ Forth and Questprobe: Spider-Man.)

What the Plus/4’s detractors fail to grasp is that it completely resolved a major downer of the previous home machines: the 64 had shipped as soon as possible on the CEO’s orders and although its low-cost graphics and sound hardware shone in the hands of a software publisher, few of its features were unlocked for the beginning programmer.  All special hardware could be accessed only by PEEK and POKE into the register space. The box remained near useless to most users before they invested in boxed software, whereas even a Plus/4 ignored by the software industry represented a much more useful blank slate to the budding programmer.  This pretty much describes myself when I picked up a gently used, if at all, Plus/4 from the local Computer Corner for $40 in 1987.

Sure, the earlier Commodore BASIC was a good vehicle for many of us kids learning how to program in between gaming sessions.  But once one reached the advanced sections of the manual and was trying to conjure up sophisticated user interactions with the same poor code structures it introduced at the outset (GOTO and GOSUB, nothing more) or even started running out of memory for variables, it quickly became clear that only a change of programming environment could result in the completion of a project worthy of the platform.

Contrast this with the Plus/4, a true programmer’s computer that wasn’t even intended to become one.  Commodore had been able to ship the 64 at a handsome profit due to its plethora of support chips–not to mention the CPU–being fabricated inside Commodore itself, and its gobs of DRAM plummeting in cost in accordance with Jack Tramiel‘s calculated gamble.  This mass-market value proposition in turn did drive a burgeoning game, desktop publishing and home dialup market.  On the other hand, the 264–as the Plus/4 was originally called–was never intended to replace the 64 but rather stave off low-end threats from Sinclair in Europe and what would later become MSX in Japan.

While the VIC-20 and 64 had been rushed out the door with a barely adequate Microsoft BASIC 2.0 from the PET/CBM platform, for its next try Commodore had the time to really optimize the hardware and software design.  Dave Diorio embarked on the design of the MOS 7360 Text Editing Device (TED), a single-chip graphics, sound, I/O and memory management chip that would lend its abbreviation as a codename for the entire follow-up cost-down effort.  With TED and the MOS 7510 CPU as the centerpieces, Bil Herd reduced the vast count of packages on the motherboard to the bare minimum to achieve a real, usable computer while solving issues along the way that the thrifty design mindset had produced.  Fred Bowen and Terry Ryan squeezed in the improvements in the system software, left the door open for quick-boot ROM productivity applications intended for frequent use (since the system bus expansion port was intended to be taken up by the 1551 disk drive) and the end result was a family of computers that could span multiple segments of the market.

The 264 and its big-brother 364 were more nuanced machines than the unfocused Commodore marketing departments could appreciate, appreciated even today by those willing to give up SID voices and VIC-II sprites in favor of:

  • A palette of 121 colors (up from 16 in the VIC duo) that made the output of paint programs actually attractive
  • A real RS-232 transceiver chip for serial communications that didn’t hamstring the main processor
  • TEDMON, a built-in machine language monitor (typically sold for the 64 only as a ROM cartridge such as HESMON)
  • BASIC 3.5 with renumbering, loop structures, readable graphics and sound commands
  • A disk drive that accessed the same media at almost 10x the speed of the 1541
  • The ability to boot a ROMed application, called “3-plus-1” in the shipping version (but for everyone’s sake let’s pretend it was one of the originally intended single-function apps such as CALC/PLUS)

All these 264 features of course came at the expense of extra ROM capacity relative to the 64.  Yet the amount of available BASIC memory displayed at power-on actually increased, from 38kB to 59kB!

This trick was accomplished by the help of the new TED chip that could switch the upper half of the 264’s memory address space between ROM and RAM very easily. Besides allowing all system RAM to become graphics RAM, TED would take care of DRAM refresh also. The various ROMs normally were mapped to the top 32K, but instead of obliterating the underlying RAM a write operation always went straight through.  Read operations were possible by interacting with TED through a short assembly language routine kept in the lower 32K (always RAM), at address $0494, that could switch back and forth between modes one byte at a time.  Not lightning fast, but enough to allow BASIC to store its variables up underneath ROM and open up more space for program storage. And if the access were just writes, for example log entries for debugging, there was no penalty at all!

I was recently reminded of this scheme (upper 32K RAM-under-ROM, lower 32K always hardware registors or SRAM) when I began working with 2011’s “EP” series refresh of Microchip’s 16-bit PIC24 and dsPIC33 families: it is not uncommon to run out of a convenient way to output debug information in real time when programming microcontrollers with limited peripheral pins.  And so, just like on the 264 series, it is possible to build up a log or trace of moderate size in the upper bank of RAM, underneath read-only entries in the flash program space akin to ROM in the old days.

I’ll go into more detail of this deja-vu capability in part two.

Advertisements