Generously given to me by Michael from the ARC Group.
The Model I was originally released in 1977, but this one was made in about 1980. It has 16k of memory and has been highly modified.
It also came with an expansion unit with RS232 interface and 32k of additional memory. There was no disk drive, but that was only a minor obstacle.
It also came with an original monitor (probably not the ideal one to use with the expansion box), buffered cable to connect the computer to the expansion unit, a box which turned out to be a high resolution graphics mod, a joystick, and dust covers.
The Commodore PET (branded CBM in some markets) computer is an icon of early microcomputer history. There are very few in Australia and the only ones I have seen in South Australia was the one in the Adelaide Uni Physics labs back in 1983 and one imported from the UK. I am aware of one other that was for sale on gumtree about 5 years ago.
It was some surprise then that I spotted this image on facebook marketplace. I was further surprised when I contacted the seller and he said he had a second machine covered in pigeon poo.
Presentation is everything, so i was interested of course. We came to an arrangement for the first machine and i drove (with my wife for company) up to Snowtown (a town with a story) where it was located.
The site was an ex Telstra maintenance site, long since abandoned to the pigeons and probably a myriad of other undesirables. Just walking into the building was a health risk and the smell was unbelievable.
I paid a smaller sum for the filthiest computer ever, and another small donation got me a very disreputable 2031 disk drive. The other drive is not related to these machines.
I pondered my sanity as I put them on a drop sheet in the back of the car.
I do have some standards about what comes into my “clean” shed and both machines were well below the threshold, so they went into the “dirty” shed first.
Opening the covers proved confronting. The first was not too bad but very dirty and corroded. The second machine and the drive almost made me gag. They were full of some combination of pigeon fluff and pigeon manure, which I suspect just blew in over a long period. I donned rubber gloves and a face mask and began the ugly task of removing the debris, first in handfuls and then with the vacuum cleaner.
It was clear that I needed to disassemble the second machine and the drive unit if I was to get all of the offending material out – and that was a necessary first step to just being able to stomach and store the machines.
Having got most of the innards clear of crap, I started washing down the cases. This was an unpleasant task, but was not difficult. Pigeon mature seems to wash off fairly easily, and the largely plastic construction seems to have been unaffected by its coating. Some stains remained, and the metal parts had some corrosion, but I was happy with the improvement.
The second keyboard was set aside for the moment.
At this point the machines were allowed into the clean shed, although they were far from clean. Remarkably, though, they both seemed to be complete – not even a missing keycap. The condition of the mainboards was poor, though.
These machines are both model 4016-N which means that originally they would have had 16k of RAM and 40 column text.
They both seem to have been upgraded to 32k of RAM and 80 column text.
I thought initially that they must have been used by Telstra, and perhaps they were, but they clearly once belonged to TAFE.
These machines were produced late in the PET’s product life. They were obviously under cost pressure, eg there are a lot of places where rivets were used instead of screws.
80 columns is handy for things like word processing, but a lot of the games were produced for the 40 column models. It is possible to put the machines into a 40 column mode, but the characters are still narrow and the proportions changed.
These machines use universal boards so they can be reconfigured to 40 columns – this would require several links to be changed and a new edit ROM.
There was a lot to be done before any reconfiguration would be on the agenda.
Initially i built the 68000 Cromix system using high density 5.25″ disk drives for the system drives. Having been able to install Cromix it was time to take the next step and add genuine 8″ drives.
The selected drives were Mitsubishi M2896-63 half height drives.
The 16FDC disk controller was designed primarily for Cromemco Persci drives. I don’t have of these drives and am unlikely to ever find any.
The 50 pin interface is quite different. I stumbled on this document by Martin Eberhard that examined in detail how to adapt the 16FDC to use Shugart SA800/850 drives.
I shamelessly used this very handy information to make an adapter cable for the Mitsubishi drives.
16FDC Pin
16FDC Signal
Drive Pin
Drive Signal
2
Side_Select
14
Side_Select
4
DS4_L
32
DS4_L
6
N/C
6
Alternate I/O
8
N/C
8
Alternate I/O
10
Seek_Complete_L
12
Restore_L
14
Eject_L
16
N/C
16
Alternate I/O
18
DS3_L
30
DS3_L
20
Index_L
20
Index_L
22
Ready_L
22
Ready_L
24
Motor_On_L
18
Alternate I/O /Head_Load_L / Motor_Start_L
26
DS1_L
26
DS1_L
28
DS2_L
28
DS2_L
30
N/C
32
N/C
34
DirC
34
Select (Direction)
36
Step_L
36
Step_L
38
Write_Data_L
38
Write_Data_L
40
Write_Gate_L
40
Write_Gate_L
42
Track_0_L
42
Track_0_L
44
Write_Prot_L
44
Write_Prot_L
46
Read_Data_L
46
Read_Data_L
48
N/C
48
Not Used
50
N/C
50
Not Used
2
Alternate I/O / Write Current Switch
4
Alternate I/O
10
Alternate I/O
12
Alternate I/O
24
Not Used
[Next time a drive is out, get the jumper settings.]
I reinstalled Cromix 20.09 on the 8″ disks using the same instructions as i had used previously.
I had a badly deteriorated industrial computer chassis with accommodation for 2x 8” drives. It also had a cutout for two 5.25” floppy drives. I could have used it on an STD project, but I have another rack that I can use for that which is more compact and has an integrated power supply.
I figured that if i reduced the length of the chassis to get rid of some bulk, then it might make a good drive unit for the Cromix system above.
It took a lot of mechanical work, but the result worked pretty well. I put a window in the top cover just so that the operations of the 8″ drives could be seen and enjoyed – not something i would have done with a vintage unit.
I added one more high density drive (Mitsubishi 4854) which is on the 5.25” cable but appears to the cromix to be another 8” drive. I had to make a small mod to the 16FDC board to route the pin 34 of the 5.25” interface (RDY) to pin 22 of the 8” drive interface. This is because the high density 5.25” inch is treated as an 8” drive and Cromix expects a ready signal for those drives.
This particular Mitsubishi 4854 drive has a curious property whereby the reduced write current pin 2 has been disconnected – possibly because it was in a system which used pin 34 for a drive or side select. The line is pulled up, but only when the terminator is in place. That means this drive must carry the terminator because the line does have to be high.
Along the way I checked the alignment of the drive (which was good) but noticed that imagedisk could only make sense of the very first track on side 0. Apparently this track is FM rather than MFM – probably for compatibility with the 16FDC ROM.
The Mitsubishi M4854 drive has a head solenoid. The solenoid is probably unnecessary because the system seems to be ok with the drive spinning up on each access (this didn’t work with other high density drives or the 8″ drives).
Currently, i use a gotek/flashfloppy in place of the 40 track 5.25″ boot drive. I start with an image of a 40 track boot disk and can then switch to any of the myriad of 8″ disk images from the GIT repository.
Drives/devices are arranged as follows:
Drive
Mount Point
Small
Large
Uniform Small
Uniform Large
0
Gotek
da
sfda
fda
usfda
ufda
1
8”
db
sfdb
fdb
usfdb
ufdb
2
8”
dc
sfdc
fdc
usfdc
ufdc
3
5.25 80 Track
dd
sfdd
fdd
usfdd
ufdd
I also expect to be able to use this unit with the Compupro/Jade CP/M machine.
This machine is a reconstruction of a hobbyist built machine from the early eighties. It came to me in pieces in amongst a lot of other gear, so it wasn’t obvious to me that there was a complete computer there at all.
I had already rediscovered a Cromemco based computer which used half a dozen of the 29 S-100 cards that i’d received. I also had a rack, some 8″ drives, and a lot of 8″ disks which i had previously imaged.
Many of the disks were labelled as being Jade, and there was indeed a JADE DD Floppy Disk Controller amongst the cards. There were many more disks that used the JADE format.
There was also a Versafloppy II Floppy Disk Controller card, for which there were also a number of disks.
These were all CP/M disks so i was looking for a 8080, 8085 or Z80 processor board. The candidates were a Cromemco SBC which wasn’t a great fit with CP/M or a CompuPro 8085/88 CPU card which would work.
I also expected there to be some I/O and a card for a boot ROM. And RAM of course. There weren’t a lot of clues from the cards themselves.
Fortunately there was a disk labelled “Jade System BIOS Development which contained some assembler files for the CP/M bios and the boot ROM. At this point, i ruled the Versafloppy II out.
The boot ROM code had some comments identifying key components (8251, 8255 and 8253) on a W/W card. Once i found the card with that combination of components, i realised that W/W stood for wire-wrap. It was a hand-crafted board. It also has a speech synthesiser chip!
Looking at the chassis, i could see that the wires dangling from the back panel married up with empty sockets on the board.
A little while later i realised that there a couple more ports which may belong to this unidentified card:
It has a real-time clock on it.
I had several memory cards that could potentially be used, but given that the CPU card is capable of addressing more than 64k, i started with an Intersystems 256KDR.
This card is probably overkill, and i may swap it out in the future.
I do have an EPROM card, but it is made for 2708 EPROMs which i can’t program at present – i would need a new programmer.
Instead, i built a new card using a modern S-100 prototype card.
The Jade Double D is notable for being an intelligent floppy disk controller. The onboard Western Digital FD1791 FDC chip is controlled by a Z80 processor. The CPU communicates with the DD through a 1kB window.
Although the card includes a processor and 2k of RAM it has no ROM. Instead, code must be injected by the CPU card. The code is embedded in the CPU boot ROM.
The boot code assumes that the window address must be set to F400. The jumpers were already correctly set.
This card supports 5.25″ drives on a 34 pin interface or 8″ drives on the 50 pin interface. Eventually i will use 8″ drives with this machine, but in the short term i just wanted to use a couple of goteks (with Flashfloppy).
The images that i wanted to use are from 8″ disks. These work fine in the gotek but because the gotek uses the 34 pin interface there were a couple of residual issues. There are a some signals expected by the boot ROM and the CP/M BIOS for the 8″ drives that are not on the 34 pin interface.
The first is the RDY signal which is supported by Flashfloppy on pin 34. This requires a link on the DD from pin 34 of the 34 pin interface to pin 22 of the 50 pin interface.
The second is that an 8″ drive can detect whether a disk is single or double-sided – the index hole is in a different location. For this, i added a switch to assert or negate the SIDES signal depending on which image i had loaded. I later copied all of the single sided disk images to double-sided disk images to make things a little simpler.
This card had a couple of hardware issues. The first was two shorted tantalums. The second was that, for whatever reason, two sockets had been butchered, and the chips soldered to the socket pins.
The cards were popped into the rack, including a partially tested EPROM card with a boot ROM programmed using a file from one of the 8″ floppy disks.
The source showed that on start-up the first serial port to receive a space character would become the console and offer to boot from the Jade DD.
The boot ROM source indicated a serial port speed of 9600. I used an IBM terminal setup accordingly.
I started with a CPU, EPROM, and I/O cards and proceeded to discover the various mistakes i had made with the EPROM card!
Once i could see that code was being read from the EPROM i added the RAM board and the Jade Double FDC. I could see data coming out of the UART, but it wasn’t making it to the terminal and that was because a shorted tantalum on the Jade board had blown the -12V fuse.
Once repaired, i got the boot screen.
I hooked up a couple of goteks and on the second image it booted.
In principle the files on the CP/M disks can be extracted using cpmtools. This, however, requires knowing the disk definitions.
I was able to work out the skew table by looking at the directory sectors on track 2. I guessed the directory size for the 2.2 format.
There were actually two different CP/M formats for the two different CP/M implementations on the disks: Exidy CP/M 1.4 and Software Source CP/M 2.2.
I was able to make some guesses based on the sector arrangement, and when i looked at the images i could see the order of the directory sectors. They both use a skew of 5 but start with different sectors – which explains why each CP/M only works with their own disks.
The directory size was a guess.
I thought i had nailed the format, but later i realised that there were some issues.
The two CP/Ms that I have use 2kB blocks. Each directory extent can accommodate 16 block pointers, but they are not all used. I think there was a rule that an extent could only represent a maximum of 16kB (multiple extents can be used for bigger files) so the CP/Ms that I have only used 8 pointers and just waste off the other 8.
With the original diskdefs cpmtools would read fine but when writing it would use up to 16 of the pointers. This befuddled CP/M.
The fix was not obvious but I found a comment on one of the other diskdefs suggesting that
logicalextents 1
wasted half of the entries (which is what I want) so I gave that a try and it worked.
My Sorcerer uses a Micropolis hard sectored floppy drive system. It uses 16 sectors, each of which includes a 256 byte data section and 19 bytes of bonus “metadata” used by Micropolis DOS (MDOS). This metadata is ignored by the CP/M implementations (Exidy & Software Source) that i have encountered.
The drives have an unusual track spacing of 100TPI. This is unusual so imaging has to be done using the actual drive units.
FluxEngine is a very low cost imaging solution that support Micropolis hard sector disks as used on my Sorcerer. At the time, Greaseweazle did not support hard sectors. It has since been added. I’ll do a separate post on that.
I connected to the drive using a straight through cable and using drive:0. This selects the second drive in the dual drive unit (drive 1). For the single drive unit, DS1 (the second drive select) must be selected.
I used FluxEngine on a new PC, so there would be no USB bandwidth issues. My older machine does seem to work reliably, but if it gets busy then FluxEngine will sometimes throw a bandwidth error.
Initially i used my single drive unit (which I call Drive 2) mainly because it was compact. Once I started working my way through the disks, I found I was getting lots of errors. I thought that I might do better with the dual drive unit (I call the top drive “Drive 0” and the bottom drive, “Drive 1”). I found that Drive 0 was a little better than Drive 2 and that Drive 1 was the best drive to use.
The results were a little disappointing but some further reading of the FluxEngine doco:
hinted that I could fiddle with decoder.bit_error_threshold to perhaps get better results. 0.2 is the default. 0.4 improved things a lot. 0.5 was the best. With the wrong setting, a lot of empty (?) sectors were read. I also increased the retry limit.
Drive 1 remained the best performing drive. I tried messing with the alignment on Drive 2, but I could not noticeably improve its performance. I did some poking around with the scope but no obvious differences between the dual and single units leapt out at me.
Out of 87 disks, I was able to read 19 without any errors being reported. I was able to read another 18 with only a small number of errors. A further 38 disks didn’t yield anything usable. Some were shedding oxide, but most 24 were successfully reformatted. Many were unlabelled, so perhaps no great loss.
Disks that were formatted with MDOS were read using the 275byte sector size. CP/M disks were read with 256 byte sector size. My understanding is that CP/M doesn’t use the “metadata”, and the 256 byte size is much easier to view.
There were some examples of where I was able to copy a disk on the real machine, but FluxEngine was unable to read the disk without error, eg Disk 24. The copy read fine. This meant that there was potential to improve the yield by making fresh copies on the real machine. Ie The real disk controller is still doing a better job in real time than the flux engine does in slow time. That’s the advantage of inside knowledge, perhaps.
I attempted to copy all the errant disks to intermediate disks, which I subsequently imaged. I did this for the CP/M disks using COPYDISK. This yielded another 13 good images! I think this confirms that FluxEngine is way less tolerant of problems than the sorcerer system. Even many disks that had a lot of issues came good.
I repeated the exercise for the MDOS disks, which gave another 8 good images.
I was able to write back both CP/M and MDOS images:
The write process verifies each track by reading back so even the writes need the bit_error_threshold parameter.
Writing also work through the virtual sector generator to a soft sector disk. The disk can be read by the system if the virtual sector generator is used.
I was very impressed with FluxEngine. David Given has done an amazing job.
The Micropolis disk system uses hard sectored disks. This is particularly challenging for disk imaging systems.
Release 1.20 of Greaseweazle included hard sector support, so i gave it a try. I was able to read and write disk images with moderate success. Without a codec for the disk formats the software could not check each track and retry if necessary.
The Greaseweazle developer, Keir Fraser offered to add the fluxengine codec into the code which he did very rapidly.
I tried it out and found it worked very well.
I did find that some of the default parameters didn’t work well with my drives, but these were changed with the delays option.
The relevant commands are:
Get help
gw -h
Speed test
gw rpm –-drive=0
Head clean
gw clean –-drive=0
Set some safe drive parameters
gw delays –-step=30000 –-settle=10
Reads a micropolis disk into an scp file. The raw option keeps the sector pulses and allows reprocessing. Without the raw option the files are more easily viewed with the HxC tools.
CP/M files are read with the 256 byte option format=micropolis.100tpi.ss
When creating the image files, the sector integrity is checked and if the sector is bad it is retried. It was common for multiple retries to be required.
I did try to adjust some parameters (i had to with fluxengine) but i could not get much improvement. Nevertheless, it was quite satisfactory.
The actual system does better, so it often helps to make a fresh copy of a disk on the Sorcerer before trying to image with either FluxEngine or Greaseweazle.
I also tried using Greaseweazle to write micropolis images to soft sectored disks with a Virtual Sector Generator. It also works fine.
What i have not been able to do, so far, is to trick the Sorcerer into using a Gotek/Flashfloppy either with or without the Virtual Sector Generator.
As at V1.22 Greaseweazle includes the micropolis codec.
I use Greaseweazle a lot so i really appreciate the effort that Keir and others have put into its development.
