VisiCalc on a PET 8032

My exhibit for VCFE 10.0 was to include a bunch of old computers running early spreadsheet programs.  I planned to include the closest representations possible for me of the Vintage Computer “Holy Trinity”- The Apple ][, TRS-80, and Commodore PET – all running the original VisiCalc. The PET would prove the toughest.

Like the other computers I needed to get a working copy of the software onto the native disk media of the 8032. In my case this would be a floppy in a Commodore 8050 disk drive.  This proved more difficult than I anticipated and much harder than the other computer brands.  But the PET had an extra challenge- it needed not just disk software but also a VisiCalc specific “copy protection” ROM installed inside the computer.  A very early DONGLE implementation indeed.

The plan was to make this ROM from .bin files available around the internet.  One challenge is that the type of 2532 type ROM of the PET is uncommon today.  I decided to adapt a modern EEPROM to the 2532 socket.

A few months prior I thought I might be doing this kind of ROM work so I bought some  Atmel 28C256 EEPROMs for the purpose.  I figured the 32K byte capacity should be useful in many projects.

I set out to define an adapter to allow the lower 4K of the 28C256 to be used in place of a 2532 ROM.  Here are the pinouts of the two ICs:

 

The idea with a socket adapter is to try to minimize the wiring.  You want as many pins to connect directly down from the top socket to the lower socket.  Fortunately the pinouts of many PROMs follow a similar scheme.

The chart below was my design for the adapter.  The center box represents the 28C256 pinout.  Flanking it are the left and right pins of the 2532.  The pins marked in green are straight down direct connects.  All of the other pins are connected TOGETHER based on their color.  The yellow pins are all connected to ground via pin 12 of the 2532 socket.  Grounding the unused address pins A12-A14 isolates lower 4K of memory of the EEPROM.  Grounding ~CE makes the part always enabled.  Vcc is routed with a wire from the 2532 Vcc pin to the 28C256 Vcc, and also to ~WE so that write is disabled. A11 is in a different spot on the two ICs so that is routed by wire. Note the Vpp 2532 pin is not needed at all so it is not connected to anything.

With the socket made, I set myself to loading up the 28C256 from a TL866 programmer that I bought a while back to program a Heathkit ET-3400 EEPROM.  So I loaded the visicalc .bin file into the programmer software, set the IC in place and hit PROGRAM.  It went through the programming cycle but indicated FAIL. Tried several other parts with the same result.  After considering possible faults, including programmer software versions, etc, I concluded it was the parts.  Either they were faulty or incompatible with the programmer.  I read of some similar experience with Atmel versions 28C256 so I’m leaning towards a bad batch.  So I bought some Microchip 28C64 parts from another Ebay vendor, which were billed as tested parts.  The pinout of this part is fortunately compatible with my socket adapter.  A smaller capacity EEPROM with less wasted bits!

When I received the parts I tested them right away and programming was a success.  Now to see if the data is accessible in circuit.  First we need a reference of what’s in the EEPROM.  Here’s the beginning of the .bin data as shown programmer:

I installed the EEPROM and socket adapter and powered up the computer looking for any signs of distress. It seemed fine.  Then I entered the built in machine language monitor with a SYS 8 command (sys to any address that contains 0 does the job.  address 0008 contains a 0)  Then I dumped some memory in the ROM address area via M 9000 908F:
… SUCCESS!

Next I had to consider running the VisiCalc software.  There were .D64 image files available around the web.  Downloading this is simple enough.  In fact, the system of firmware and software were able to be tested in VICE. Here is the process:

Install VICE, launch vice.
Set drive 8 to the .D64 file:

Set the ROM area 9 to the VisiCalc ROM inage file:

 

Load the loader program, first one on the disk:

And run it!

Now for the real thing.  For this I needed the .prg files available on the PET.  I have a PETDisk, but this won’t work for VisiCalc because PETDisk only implements enough DOS to load a program from the command line.  A full DOS implementation is required for VisiCalc since it has a loader/initializer program that needs to chain to the main program.   I presume VisiCalc won’t work right if you skip the loader and manually load the “main” VisiCalcXX .prg file.  Fortunately I have an 8050 drive that would be ideal if I could get the files to it.  There are options for doing that.  I choose the method of using a Zoom Floppy “USB to Commodore interface” from RETRO Innovations, with the related OpenCBM tools running on a laptop.

When received the Zoom Floppy board, I hooked it up and installed the software as directed.  I chose to use CMBXfer  to write the files to the drive.  CBMXfer is a great GUI shell that runs on top of a set of DOS tools called OpenCBM. OpenCBM has supported communications from PCs to Commodore drives for a long time, over various hardware interfaces.  I struggled with a problem that CBMXfer would not copy files directly out of the .D64 file that I had used in the emulator.  Later I learned this was a configuration error on my part.  But as a work-around,  I extracted the files from the .D64 file with a tool called 64Pro, and then transferred the individual files to the drive with CBMXfer.  The disk seemed fine to the PET, ie: the directory listed fine and the initial file loaded. But when I ran the VisiCalc loader, I got this:

Something about the process I used made a disk with which VisiCalc was not happy.  I didn’t know what.

Unfortunately, I failed to solve this for the VCFE show.  At the show, myself and esteemed colleagues theorized that it might be data corruption from using 48TPI media (Double Density) in a 96TPI (quad density) drive.  Word was, using a 96TPI drive, that if you make enough copies using DD diskettes, one should eventually work.  I made a bunch.  None worked.  So after the show,  (April 28th 2015) I tried a different tactic- I used DirMaster to create a .D80 image and copy the .D64 contents into it, followed by writing  out the .D80 image to the drive with D82Copy from the OpenCBM tools. Here’s what that looked like:

Making the .D80 image: This shot shows using DirMaster to open the .D64 image window, open new,D80 image window, and drag and drop from .D64 window into the .D80 window, and then save the .D80 image.

Writing the .D80 image out to the 8050 drive:

load, run, SUCCESS!  F I N A L L Y !

So it was too late for the show, but better late than never.
And really cool to see it run.