"Look up in the sky!"

 Although it was a classroom full of PET 4032s that got me interested in Commodore back in the early 80s, the first PET I would ever own myself was the Commodore SuperPET.

I was not yet collecting at this point, so I thought this would be the only PET I would ever own.  For that reason, I was very careful in which model I picked.  I wanted the best.

Over the years, the numerous exotic programming languages, such as Waterloo BASIC, APL, Pascal, COBOL, etc have provided me countless hours of education and entertainment.  Lately, however, my appreciation of this machine has leapt into the stratosphere.  

It began with a purchase of Retro Innovations Super OS/9 MMU. OS/9 is a 6809-based business operating system not normally associated with Commodore computers, and this hardware upgrade would allow my SuperPET to run it.   The Super MMU, originally designed by TPUG, provides a new optional method by which the 6809 can address its extra 64K.  Normally, this memory is only available in chunks at a particular address window.  The SuperMMU allows the ram to dominate the entire address space, making it friendlier to OS/9.

The Super MMU sits between the 6809 processor and the SuperPET cpu daughterboard.  It also replaces the functionality of a 74LS273 on the board through that cable you see in the picture.  The position of the cable depends on which kind of SuperPET you have.  Two-Board SuperPETs, like mine, use the upper position, while Three-Board SuperPETs use the lower one.  It also took me forever to figure this out, but the jumper JP2 pictured here also needs to be changed to reflect your board type.  Again, the upper position is 2-board, and the lower 3-board.  You can see I have it wrong in this picture, thus the "taking a long time to figure out" part. :)

The OS/9 disks themselves came from Mike Naberezny, who also had a hand in helping bring the MMU project back to life.  The disk format for PET OS/9 is extremely strange.  OS/9 "disks" exist as 640 block RELative files on an 8050 disk.  Thus, for best results, you also kinda need a CBM 8050 drive to use with it, since other PET drives, such as 2040, 4040, etc can only fit one image per floppy, the SD2PET doesn't support REL files well enough, and the CBM 8250 requires special commands to support the 8050 REL file format.

Once the MMU was installed and the disks prepared, I was ready to boot.  This involved typing Disk8/0.os9 at the SuperPET 6809 menu screen.

After mentioning my adventures on facebook, a wonderful human being named Andy shared his SuperPET software collection with me.   Even more important, he shared his *knowledge* regarding the enigmatic loading procedures required to boot and use the several new programs.  For example, take a look at some of the commands required to boot Collossal Cave:

I have not yet made this software available on my FTP site, but it will be soon.

Not long after this, I discovered the web site of a Mr. Robert Ferguson.  He not only assembled a fantastic timeline of the SuperPET, but actually *reverse engineered* the RS232C-based "HOSTCM" filesystem protocol used by the SuperPET to transfer files to and from mainframes back in the day.  He even provides his C source.

This provided me an amazing opportunity.  You see, my user's group designed an RS232C modem, the "Gurumodem", that actually has an SD-card interface on it.  How perfect is that?! 

So, I immediately got to work porting Mr. Ferguson's code to work with the Zimodem firmware used by our modem.  While I probably could have just cut and pasted 90% of it, I instead decided to re-type and refactor while reading, so that I could actually learn how the protocol worked as I went along.  This is a bit like copying your friends homework in your own words, I guess. :)

Of course, the first step was to configure the Gurumodem for the SuperPET's default RS232 settings with the command: ATB"2400,7E1"  followed by ATS54=2S46=2&W.  Obviously, I did this on another computer at first.

I then used a very dumb and simple SuperPET terminal program called "NEWTERM" to upgrade my firmware to a special version containing the HOSTCM protocol using the command AT&U=9000.

Once the firmware upgrade completed, and I had reset the modem, I was ready to activate HOSTCM mode by entering AT+HOSTCM while inside NEWTERM.

From here on, I was able to access the SD card on my Gurumodem using the built-in syntax that involves prefixing filenames with "host./".   Above is an example from inside the SuperPET text editor, using the DIrectory command to list the contents of my SD card.

Well, that's all I've got for today.  I'd like to find a way to exercise some of the features of the HOSTCM protocol not used by the Editor, but I'll have to think about that one.   Until then, if you have a SuperPET, I encourage you to get the most from your computer by taking a look at both the Super OS/9 MMU and the Gurumodem.

Welcome Back to Planet Zelch

 Around 1983, I got my first modem: the Commodore VICMODEM.  It allowed me to discover a world that would enthrall me for the next decade: the world of Bulletin Board Systems (BBS).  For those who don't know, a BBS was a computer-to-computer service, run by ordinary people on their public phone lines.  To the users who called in, BBSs provided message forums, email, file downloads, chat, online games, and often an art gallery.  

By 1986 I was writing my own BBS software for the C64, and by 1987, running a board named after it: 

In 1990, I put aside Zelch BBS for the C64, and helped write Zelch 128 with  my friend Bill in Tucson, Arizona.

Unfortunately, in 1993 my years of BBS-ing came to an end. I went off to college and discovered the internet, which replaced the venerable BBS, both for me as well as everyone else.  

In 1996, however, it all came back for a brief encore.  I was a grad. student working for the Computer Science dept. at SWT University, where we had a room full of  Slackware Linux machines, all online.  With lots of help from some friends back in Tucson, we managed to put Zelch 128 back online, but in a new way. Instead of a modem and phone line, the C128 user port was wired directly to the serial port on the Linux machine.  When a user logged into to the Linux machine from the internet via Telnet, they would automatically be put into a serial terminal program (minicom), which would communicate with the C128 as if it were a modem connection.   A Commodore Telnet BBS!  [ Read the C= Hacking article about that here, and the article in Driven here. ]  

However, even this ended when I graduated at the end of 1996.

Now, fast forward to 2021, and a lot has changed.  Instead of floppy drives, the best high-speed storage peripherals are sd-card based, such as the SD2IEC.  And instead of Linux boxes, wireless internet "WiFi" modems that hook directly to the Commodore 128 user port solve the same problem.  My interest in the later spawned my WiFi Modem firmware "Zimodem", as well as the plethora of 8-bit internet software, including new terminal programs for GEOS.

When I received a nicely working C128 as a donation a few weeks ago, I decided it was time to revive, once again, that old telnet BBS from 1996.

So, if you'd like to give it a try, you can connect to it at coffeemud.net, port 6502.  The best way is from a real Commodore 8-bit computer, such as the C64, C128, or Plus/4, using your own WiFi Modem.  For Windows users, there is also CGTerm or SyncTerm.  

Stop by when you can, and behold this microscopic internet-before-the-Internet that consumed my attention and interest for so many years.

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 pdp8online.com/mfm 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...

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.