Wednesday, April 7, 2021

Zee C900 Computer Story

In 2003, a kind German fellow named Claus Schoenleber helped me get my hands on a pair of prototype Unix machines built by Commodore around 1984-85.  One was a server (the Model 1) and the other a workstation/client (the Model 2).  Because of the issues I had with them, it would take until very recently to get them working, and require the help of many, using teamwork only the internet could make possible.  That's the story for today.

The C= engineers referred to these machines internally as "Z Machine" for their Zilog Z8000 chipset, but would be marketed as the Commodore 900.

It was rough being a software guy who collected old hardware in the early 2000s.  My knowledge of basic troubleshooting was very weak, and the internet was still mostly a desert for a niche hobby like this.  As excited as I was about getting these machines, I quickly realized that their problems, and even their requirements and basic usage, were beyond my understanding.

Last year though, thanks to some encouragement from my friends at the Commodore International Historical Society and the Central Texas Commodore Users Group, I decided to apply all I'd learned in the intervening years and see what I could do with them.

The Model 1 (server) was the first one I tackled, as its power supply seemed functional.  At first, the issue was just figuring out what kind of video it generated, but experimenting got me around to this simple monochrome PC monitor, which gave me a first glimpse of the machine in action. Unfortunately, the hard drive clearly had issues, so this was as far as I got.

In 2020, I was able to chat with a fellow named Santo who had a Model 2 he had gotten working, so I decided to give that one a shot.   The power supply in that machine was non-functional, and the best efforts of my friends at the Central TX Commodore Users group to help me diagnose and repair it had progressed slowly.  

But then Dave from the Commodore International Historical Society, whose interest in these machines knew no bounds, offered to send me a near-identical power supply from a U.S. Commodore PC-10 to get it working.

That was only the beginning though.  You see, the Model 2 had a proprietary video standard to achieve its 1024x800 resolution, which means having a one-off monitor that didn't even have a known model number.  I also lacked a video cable, and its 220V requirement was certainly an inconvenience.  

Santo to the rescue though!  He had discovered a jumper in his own monitor that allowed it to accept 110V, and when my home-made video cable still failed to produce a useful signal and I discovered that one of the wires inside the monitor had become disconnected, he photographed his own board to help me figure out where it was supposed to go.

And walah!  We have video!

And this is where new problems began to surface:  the hard drive was unreadable, and the boot sequence reported memory errors.

The computer has 32 individually socketed 41256 ram chips, and the brilliant engineers at Commodore were kind enough to more or less report exactly which chip it was failing on the boot screen.  Well, sort of.  Either way, some experimental swapping with good replacement chips ended up fixing the memory issue.

The bad hard drive was a tougher problem.  But Santo to the rescue again.  He pointed me at the fine folks at who produce a remarkable board capable of both hosting a working MFM hard drive for imaging, as well as emulating one using locally stored image files.  Since my own hard drive was unreadable, I used a hard drive image he had taken of his own installation.

Of course, now there were new problems.  The X-Windows-Like GUI desktop software required a C900 mouse, which I did not have, and the floppy drive with its proprietary format appeared unable to format a new floppy or read known-good ones.  

And then even the keyboard started crapping out on me.  Luckily, the C900 can use a standard PC keyboard, which Claus had included in his shipment.  I also later discovered that the C900 keyboard was fine, and that it was a stuck key that was not visibly-stuck causing it to fail to boot. It was that ugly wide skinny stop/continue button in the upper-right.

After the keyboard, I tackled the mouse issue.  Mr Santo provided me detailed photos of his own mouse, so I went to the schematics and prepared to build one from scratch using, perhaps, an old Amiga mouse as a base.  To my great delight, however, I discovered that the pinouts for the two were identical.  The C900 mouse *IS* an Amiga mouse.  

Now I was in business.  I spent the better part of a month playing around with the demo software, using its Kermit terminal to do some wifi modeming, writing some little utilities in C, learning the cryptic keys of Emacs, and otherwise enjoying the machine.  You can see some videos of the demos here, and here

But eventually I wanted to revisit the Model 1/Server machine.  If you recall, it had a bad hard drive.  Well, I discovered the hard drive issue was merely intermittent, and I already had a good long-term solution when dealing with the Model 2, namely the MFM emulator.  And so...

18 years was a long time to wait to finally see these machines happy and functioning again, but definitely worth it.   2020 may have been the worst year ever, but for a shut-in Commodore collector: not so bad!  And definitely a team effort that only good hearts and the power of the internet could provide.

I hope you enjoyed my little journey.  Until next time...

Thursday, February 4, 2021

Best Week Ever!

Way back in 2002, I was lucky enough to lay my hands on a beautiful Commodore 256-80 computer, the top dog of the CBM-II line of business machines.  

It had issues almost from the beginning though.  

First off, it would only power up occasionally, and when it did, the power supply made a horrible screeching sound for as long as I used it.  

Second, it had been equipped with the 128K BASIC roms instead of the 256k roms, which means BASIC was using less than half of the available memory.

Lastly, my 8088 card, which I acquired from the same owner, absolutely refused to work inside this computer.  

I despaired, but remained thankful for what I had.

You might think the first thing I would concern myself with was fixing that screeching noise from the power supply.  However, I didn't.  I had been told it was probably due to slightly loose wiring in one of the transformers vibrating during normal usage, and that replacing the irreplaceable transformer was the only real fix.

I focused instead on the booting problem of the power supply.  For nearly 20 years, perhaps twice a year, the computer would stop booting.  I would then take it apart, remove the board shown above, and then try to figure out what was wrong.  Typically, after a few days of poking around, the computer would start booting again, and so I'd button it back up and move on to something else.

Along the way, I tried restoring the BASIC 256 roms by burning the images to some 68764 EPROMS I had, but the computer would only boot into the monitor, indicating a failure.  Did I have bad memory in the upper two banks?  Is that why the 128K roms had been put in there? <sigh>

I also made repeated attempts to get the 8088 board working, but the boot disks would never do more than hang the computer during load, indicating to me that the board was still failing or incompatible.

Recently, however, Dave McMurtrie acquired an identical 256-80 machine with a bad power supply, and managed to fix his by replacing basically every source-able component on the board.  This was inspiring to me.  Why couldn't I do that? If he can fix a dead power supply, surely I can fix an intermittently bad one.  

Why did I have to live with any of these problems?  

And so I got to work.

My first step was to replace every capacitor on the board except the two largest, which measured fine.  If I had any doubts about the need to replace the others, they were dispelled when I tried measuring one of the old capacitors on the left side of the board and it was reported as a diode.  I also found myself cleaning off tons of electrolytic fluid that had been leaking.  You hear all the time about how bad capacitors will bulge on top when they go bad, but these were all bulging out at the *bottom*. 

Dave had sent me some of his leftovers, so I also swapped in some fresh voltage regulators and transistors, and even replaced the choke, though I doubt they were bad.

When I was done, I tried it out, and to my delight, the computer was booting again.  But that wasn't the best part:  the screeching noise was GONE! It wasn't just loose wires in the transformer after all!  Something I wish I'd known 15 years ago, but better late than never and all that.

Flush with optimism from the power supply repair, I went back to looking at those BASIC 256 roms.  The 68764 burns I had made still verified as correct in my eprom programmer, but also still refused to boot in the computer.  So, for no reason, I made new ones, this time in some 68766 eproms, and guess what?  BAM!

I was on a roll now.  Nothing could stop me.  I pulled the 8088 daughterboard off the shelf and once again carefully installed it inside the computer.

I had two boot disks, which I'd tried interchangeably over the years:  an MS-DOS 1.25 boot disk, and a CP/M 86 boot disk.  I hooked up a drive and tried MS-DOS 1.25...

I almost fell over with joy, right then and there.  After 20 years: a stable quiet power supply, the correct version of BASIC, and the 8088 card working perfectly.  Perhaps the 8088 card had been too much for the power supply in the past?  Either way, it was all good now.

So, of course I tried the CP/M-86 boot disk and now it, too, came right up.  Looking at the directory on the disk, my eyes went straight to that first program. 

WordStar on my C128 had gotten me through college, so how could I resist another trip around the keyboard with it?

And with some finagling and some help from Steve Gray with the PET Emulator, I even managed to play some PETSCII robots:

This had been the best week ever!  

... of course, all of the above triumphs consumed perhaps 2-3 days.  You'll have to wait to find out how the week actually started.  If this didn't convince you I'd had a good week, the next installment will.

Friday, March 13, 2020

Here's What You Missed

The last decade or so has seen a bit of a revival in the Commodore 8-bit branch of the retro-gaming and retro-computing realm.  Prices have been rising, new hardware and software has exploded, and the chatter in all kinds of social media has multiplied.  For me, it's been fantastic.

However, I've observed a kind of awareness gap in the prodigal sons who've been returning to the fold.  I decided, therefore, to write a little essay to get everyone who was absent from the 8-bit community during the 1990s and 2000s caught up. 

For fellow die-hards: if I neglected anything, please comment below.   This will understandably be written with a U.S. bias, though I did my best to overcome it.

And with that, let's get started.

Part 1: Hardware

For the Commodore 8-bit scene, the 1990s cannot be understood at all without talking about a little company founded by Doug Cotton and Mark Fellows in Massachusetts called Creative Micro Designs.  From 1987 - 2001, CMD made us feel like our machines were more a lifestyle choice than clinging to obsolescence.  Their products included the Kernal upgrade JiffyDOS, the SuperCPU 20mhz accelerator, HD-Series hard drives, FD-Series high density and enhanced density 3.5" floppy drives, the RAMlink ram drive, Smart-series mice and trackball controllers, gamepads, 1750 ram expansion clones (with 2MB!), and don't forget the SIDSymphony sound expander, and the SwiftLink and Turbo232 high speed serial/UART cartridges they licensed from Dr. Evil Labs.

While CMD towered over the 90s, they weren't entirely alone in their efforts to give Commodore power users new capacity.   Tomas Pribyl and Jan Vorlicek developed the IDE-64 in 1994, a cartridge-based IDE controller that bragged better performance and a lower price, at the expense of compatibility, for mass storage.

Another option that emerged in the 90s was 64NET from Paul Gardner-Stephen, which allowed a PC to be used as a storage device for a C64.   Around 2000, a similar solution called 64HDD, was devised by Nick Coplin.

As the internet began to take off in the mid-90s, new products began to emerge to solve the most pressing and important problem of the day:  how to get software from the internet onto floppy disks.  This led to various cables and solutions for connecting Commodore floppy drives to internet-enabled PCs in order to transfer software, primarily using Joe Forster's Star Commander software.  These cables began with Leopoldo Ghielmetti's X1541 cable in 1992, which eventually expanded to include the XM1541, XE1541, and so forth.

Not to be left out, however, these dark ages also saw the first devices for getting 8-bits onto the internet directly.  Initially this was through dial-up modems, often involving the aforementioned SwiftLink cartridge.  Eventually, the wired-ethernet solution RR-Net was introduced by Jens Schönfeld as an add-on for the Retro-Reply cartridge, although software support has always been somewhat slim for this device.    An even stranger solution was the Palm Pilot ethernet cradle, which, when combined with the SwiftLink cartridge, also allowed wired ethernet capability.

At the beginning of the new millennium, though, the scene's attention was turned to a young self-taught engineer named Jeri Ellsworth, who promised to bring us something previously un-imagined: a new hardware reproduction of the Commodore 64.  By re-implementing each of the computer's custom chips in FPGA technology, this culminated in the CommodoreOne (C-One) computer.   Not many years later, this same technology was scaled back in the form of the C64 DTV game.  The DTV was famously designed to be hacked in such a way as to include ports for a keyboard and second joystick, and a serial port for disk drives, allowing it to be turned into a useful computer.

Part II: Software

Above is a screen shot of the Weekend World demo by Outcast.  The interregnum Commodore demo scene saw a decline in the number of releases, though not in their quality.  By the year 2000, the scene was producing 10% of what it had in 1990, but all of it building on the technological achievements of their predecessors.  Output remained steady through 2009 before finally dying off in the last 10 years.  The demo scene, especially in Europe, was the social center of Commodore 8-bit fandom.  "The Scene" as it was called, was organizing itself into yearly and bi-annual "Parties" all over the continent.

Meanwhile, the same period saw intense interest among die-hard 8-bitters in new operating systems and platforms to take advantage of new hardware, new innovations in user interfaces, and, of course to access the internet.  Chief amongst these was the graphical user interface GEOS and its Trinity of Successors.  

Although Creative Micro Designs often released patches and utilities to help users of Berkeley Softwork's GEOS 2.0 enjoy their new hardware, it became quickly apparent, even to CMD themselves, that a more integrated solution was required.  First out of the gate with such a solution was CMD themselves, with gateWay.  Written by Jim Collette, gateWay featured integral support for CMD hardware, a task switcher, and a highly customizable (albeit unattractive) deskTop.

The next leg of the trinity to arrive was Maurice Randall's "Wheels" (GEOS 4.0) OS.  Wheels sported movable and re-sizable windows, and support for CMD native partitions and sub directories in its beautiful "Dashboard" replacement for deskTop.  This was quickly followed by GEOS MegaPatch3 by Markus Kanet in Germany, which included TopDesk 64, and, like gateWay, included integrated task switching.

While the GEOS patches remained a popular platform, UN*X clones for the 8-bits began arriving as well.  First up was LUNIX in 1993 by Daniel Dallmann, which featured pre-emptive multitasking, pipes, and support for SLIP, PPP, and featured several network clients.   The same year, Craig Bruce released his own ACE r9 for the C64 and C128, along with ZED-128 text editor, capable of handling enormous text files.  Greg Reidel's UNIX-128 for the Commodore 128 rounds out our list.

As the year 2000 rolled around, Jolse Maginnis brought us an OS for the CMD SuperCPU, called WiNGs.  It's object was to give the c64 support for the latest audio and video encodings, as well as extensive support for internet connectivity. 

Our final entry in the OS bundle came in 2003, when Adam Dunkels released Contiki OS for all manner of Commodore 8-bits, as well as other platforms.  Another GUI OS, Contiki was significant as a vehicle for RR-Net cartridges, by including a native tcp/ip stack as well as several internet servers and clients.  Every 8-bitter wanted to run a web server on their C64 that year.

Software which ran on the standard Commodore kernal was also plentiful during this period, and helped us stay tentatively connected with advances in the PC-world.  This included Pasi Ojala's "gunzip" in 2002 and "puzip" in 2004, Errol Smith's "UnZip64 v2" for handling pkzipped archives in 1998, and David DeSimone's "uuxfer" for decoding programs off of USENET.  

New graphic formats popularized in the 90s also got support on our little 8-bits, include JPEG with JPX viewer by Stephen Judd in 1999,  GIF files with VGIF viewer by David Jansen in 1990, and geoGIF by Randy Weems for GEOS the same year.  Photos became a particular fascination with C64 users with the invention/discovery of dozens of new video modes one could achieve with the VIC-II chip, such as FLI, IFLI, and all the derivatives that emerged between 1990 and 2010.

There were also advances in image creating and editing software for the 8-bits as well.  This includes the amazing GoDot system for the C64 released in 1996 by Arndt Dettke, as well as IPaint for the Commodore 128 in 1993 by Rick Kane.  And of course, there is no way GEOS would be outdone on image editing, which made the release of geoCanvas by Nate Fiedler in 1993 quite an event.

And lastly, as the BBS scene gave way to the internet, serial terminal programs capable of 80 column display and ANSI grew in importance for 8-bit computer users using dial-up shell accounts.  This made the release of Novaterm 9.6 by Nick Rossi in 1997 an extremely welcome development for C64 users.  On the Commodore 128, we all swore by DesTerm by Mathew Desmond in 1998.

Part III: Magazines

Magazines and other bundles of periodical content continued to play an important role in the interregnum, especially during the early 1990s when it was still our only way to find out what was going on in the Commodore world.

At first, the Glossy magazines, especially those hanging in from the 1980s, continued to keep us in the loop.  

In the U.S., these would include RUN Magazine which continued until 1993, and COMPUTE! magazine, which included an internal "Gazette" section for 8-bitters until 1994.   In their waning years, the content shifted a bit towards GEOS and the new CMD hardware, but otherwise kept their original focus.

Believe it or not, new glossy magazines also appeared after the old 1980s magazines vanished.  Although many of them didn't last very long.  

Creative Micro Design's own Commodore World, which ran from 1994-1999, picked up where RUN magazine left off and focused almost entirely on GEOS and their other products.  Meanwhile, GO64!, a German language Magazine, was published  by CSW Verlag from 1997-2000.  GO64! also began publishing an English edition in 1999, and picked up the remainder of Commodore World's subscribers.

Also in Europe, the gaming magazine Commodore Format held strong from 1990 all the way through Commodore's bankruptcy in 1995.   It remained intensely focused on cheat codes and strategies and tons of colorful screenshots all the way.

And of course, the magazine Die Hard ran for 20 issues, from 1992 to 1994, and started out as a monochrome newsletter to quickly build into a nice glossy magazine.  It was published by LynnCarthy Industries in Idaho.

Magazines based entirely on disk have been around since the 1980s, and chief among those was the mighty LoadStar by Fender Tucker of SoftDisk Publishing, and later Dave Moorman.   Known for publishing digital articles and original Commodore 64 programs, pictures, and music from independent contributors, LoadStar managed to hang on far longer than most.  In 1990, LoadStar 128 joined its older brother as a Commodore 128 only publication, and they ran until 2007.  The disk magazine was also accompanied by a paper magazine called the LoadStar Letter, which spawned another paper publication called The Underground by S. Eggleston of California.

Launched in 2001 by Joerg "Nafcom" Droege, Scene World has been publishing their interviews,  articles, and software for both NTSC and PAL users ever since.

Another important disk magazines from this period is Commodore Gazette published by Christopher Ryan of Michigan, which ran from 1995 - 2004.  It focused primarily on articles and public domain software.    

Of course, its impossible to discuss periodicals from this period without discussing the several online newsletters published during this time.  First and foremost among these was the mighty C= Hacking Magazine published by Craig Taylor, Jim Brian, and Steve Judd between 1992 and 2002.  It focused on community innovations, programming techniques, and the hidden capabilities of our little 8-bits.

And lastly, although you've probably already heard of it, the online magazine Commodore Free was started back in 2006 by Nigel Parker, and didn't cease publishing new issues until 2017.  

Part IV: Early Internet

The early days of the internet for Commodore 8-bit users could be summed up by USENET and FTP.  Web sites did exist, but tended to be more like picture galleries and references than social media.

USENET was the early internet's standard Forums protocol, and allowed for networked computers to share plain-ascii text under group categories.  It was THE social media of the 1990s for Commodore users.  

The popular USENET groups for C= 8-bitters were called "comp.sys.cbm" and "comp.binaries.cbm".

The former was for announcements, conversation, trolling, and the occasional Speccy vs C64 flame war.  It would be pretty familiar to any modern user browsing the old discussions, which you can absolutely do right now through google groups.  Common refrains there include the FAQ postings by Cameron Kaiser, and few old timers will forget the ramblings of WildStar.

"comp.binaries.cbm" is a odd medium for sharing software, but that's what it was.  Although on casual inspection it appeared to be another discussion forum, instead you'd find most of the messages were UUencoded ascii of various commodore related binaries, often broken up into several parts spanning several messages.  An early unix shell account user would download the parts of the message, combine them, and translate them back from ascii -> binary before moving it over to a floppy for execution.

FTP sites constituted a more straight-forward method for sharing binary files on the internet, and several FTP sites sprang up during the 90s to serve the 8-bit community.

One early important site was the FUNET archives at  Maintained by Marko Mäkelä until 2005, funet was invaluable as a source of firmware for computers with dead roms, schematics for troubleshooting, as well as all the latest utilities and project documents to keep any 8-bit user busy.  Since 2005, the archive has been at, run by the Australians Rod and Gaelyne Gasson, was another popular general purpose file area that seemed to have a little bit of everything. 

When it comes to games, however, nothing beat and  So popular were these enormous collections of disk images that they were known simply as "The Arnold Archives".  

Web sites, while not as important early on, were still seen as artistic monuments on a hill -- discussed when they changed, and little more.  Many of these monuments remain to this day, while some have faded into memory.  The Secret Weapons of Commodore has always been one of my personal favorites, as was the Commodore 8-Bit Server, the Commodore Knowledge Base, VIC-20 Digital Archaeology, Snakeman's page, Project 64,, and the CBM-II Page -- but these are just a  sample.

Part V: Sunset, or Sunrise?

The last decade has seen impressive leaps of renewed interest in Commodore 8-bit computing.  New storage devices, new networking solutions, new display options, new computers, and piles of new games and software that seems to have come out of nowhere.  It's almost like the 1980s are completely back again.

But between 1990 and 2010, the 8-bit community marched onward, even as we watched former comrades fall away.  I think it's useful to remember that period, both to reflect on the problems we faced, and on all that was built as a foundation for what we would all enjoy today in our little 8-bit hobby.

Thursday, February 6, 2020

Return of the geoJunky

Despite having had copies of the software forever, it wasn't until the early 1990s that I became a true convert to the cult of GEOS.

I picked up every accessory, every productivity package, every Thing I could get my hands on that was related to this Mac-like GUI for the Commodore 64 and 128.  And this included geoProgrammer, the official symbolic macro assembler, linker, and debugging package from BSW.

Code is written for geoProgrammer using the stock GEOS word processor, called geoWrite.  This has the fun side-effect of not only allowing image assets to be integrated into the source code document, but also allows you to use all the fonts and styles and margins to make your code as beautiful as possible.

So armed, I spent the 90s and early 2000s writing numerous applications for GEOS.  You can find information about most of them on my geoProjects page.  However, my geoCoding spree pretty much came to an end in 2002 ..... until very recently.

The C64Net WiFi modem, which I've blogged about to the point of exhaustion at this point, inspired not only my 8-bit programming in general, but got me back into GEOS programming in particular.

In 2017 I wrote an 80 column ansi terminal program called geoTelnet, which I've also mentioned in previous posts before, but you can find more information about it here.

In early 2018, not long after its release, I got asked to do a color PETSCII terminal program for enjoying online BBSes from GEOS.  I figured this would be a pretty easy slam dunk, since the hardest problem, rs232 communication in GEOS, was already solved.

However, as engineers are wont to do, I decided I needed to re-architect things.  You see, geoTelnet was a VLIR application, so it theoretically could grow naturally with new swapped-in code modules.  However, it was only designed for two modules:  a GEOS 64 module with all features, and a GEOS 128 module with all features.  This left things rather squeezed, with no room for, for example, more transfer protocols or a settings screen.

This created a slew of linking issues, since the code sections for the features were already pretty integrated with each other, and weren't expecting to be separated from each other.  However, that was a straight-forward problem.  What really frustrated me for several days as I started migrating to the new architecture was hard system crashes whenever text was printed on the screen.  My interest soon waned, and a year went by when I gave no thought to it.

Then, in early 2020, on a whim, I decided to pick it back up and see if I couldn't find that bug.  And find it I did, almost immediately (it was pretty stupid).  I was so excited that I spent the entire rest of the day hacking away on my PETSCII renderer. 

To test it, the next feature I tackled was getting the Buffering system working again.  This would allow me to load PETSCII files from disk for testing.  I then generated the above test pattern in Commodore BASIC, saved it, loaded it into my program, and eventually got it to what you see above.

The first time I saw true online PETSCII art rendered correctly on the screen, I was ecstatic.  I was able to borrow from the code written for ANSI and Telnet codes to implement the cursor and other special PETSCII codes.

The last unique feature to put in place is the ability to actually input PETSCII codes from the keyboard.  Things like color codes, special graphics characters, and the ability to toggle between the two font modes (lower/upper and upper/graphics).  Surprisingly, this turned out to be trickier than I thought.

You see, the GEOS kernel doesn't care about many of the keys on the keyboard, so they simply don't scan them.  And since they don't scan them, they aren't available as keystroke events for my terminal program to act upon.  This led to me having to learn how the standard Commodore KERNAL actually accomplishes the feat, so that it can be replicated in my application.  Turns out it's not too bad -- you consult an 8x8 matrix of all possible keys, tell the 6526 CIA to pull one of the rows, and then read back an 8-bit bitmap, which tells you which, if any, keys on that row are being pressed.

Once that was done, fixing the remaining features was pretty much a down-hill process.  The phonebook, terminal options, desk accessories, and x-modem worked pretty much the same as they did in geoTelnet.   X-Modem uploads did give me a little trouble, due to the fact that serial communication must be de-activated to swap modules, causing it to "miss" the handshake character from the remote side.  This was quickly figured out though.

I'm not sure what's next at this point.  I'd considered fulfilling the promise of the re-architecteing by not only adding new transfer protocols, but by actually integrating the ascii and ansi features of geoTelnet back into this program, to create one large full-featured terminal.  Though, I might also venture into other areas -- geoFTP, geoIRC, geoETC...

We'll see.