Gnome's Computers - Onwards To CBM

The Molecular was a very happy machine to use, and I still have my own operating manual. But eventually our work tailed off as clients announced they were no longer needing us as they were buying their own micro-computers. And in 1980 we bought our first micro. We looked around at available hardware and discussed the matter with a local dealer selling the Commodore PET - 3032 I think it was. He desperately needed business software to sell with the machines. So we set about writing a Sales, Purchase and Nominal Ledger integrated package for the CBM.

The first thing was to learn how to drive the beast (we started with just one machine and a twin disk drive). I soon discovered how to corrupt a disk beyond recovery, for DOS 2.1 had a nasty bug which left the write head switched on if the disk had a write-protection tab fitted. When you put another, unprotected disk in the drive, it immediately wrote to that disk! There was also the "Save with Replace" (@) bug, which is still going strong on the 1541 DOS. It's all very well to say "this command may corrupt a nearly full disk". It's worse than that: this command can leave sectors still allocated but not chained to a file. A "Validate" after its use often shows more sectors freed. But later DOS versions (DOS 2.5c onwards) seemed to have cured these problems.

I went on a 3-day disk course run by a very good instructor, Mike Gross-Niklaus. He seemed a little put out when I queried his statement that the block allocation map was not accessible to a user: and even more so when I then displayed one on his screen! Much of my early learning was from a magazine called "Printout", to which a certain Ron Geere, and a Mike Todd frequently contributed! They're still around, and I wonder if they're reading this. Thanks chaps, for a lot of help.

Commodore PET 3032It took about a year to develop a saleable system, which we called MICROFACTS. There was a chief designer who was our MD, and two programmers one of whom was myself. We merged our own company with the dealership; and an offshoot, FACTS SOFTWARE is still going strong today, though no longer on CBM kit. When I retired in 1985 I was the last remaining Commodore specialist in a company now of about 20 people. For a year or two I continued to service customer problems - mainly corrupted disks - on a part-time basis. Now this sort of work is farmed out to a small consultancy who have my original documentation and master disks. This firm is run by my old managing director.

Microfacts was programmed for CBM 3032, 8032, 8096 and the disastrous 700 series which Commodore made a hash of. I think we were the only firm to do any successful software on the 700. Once we had to take our machine and the ledgers package to demonstrate to Commodore at Slough, because they hadn't got a working machine available! The 700 could make a story on its own, but I might risk a libel action from Commodore. We programmed round the many bugs, but by the time our package was ready for sale the model disappeared from the market.

Our early packages were entirely in Basic. At first we used four levels of protection against tampering - though we didn't attempt to prevent copying. Protection included measuring the length of the coding, at each run: and using dummy coding, and camouflaged commands. We achieved overlays, and these would not work if coding was moved. Also, we wrote the user's name on the disk in two places, sumchecked and camouflaged. This was displayed prominently on the screen at start-up. If the name was altered, the disk was marked with a flag that prevented further use. Later we perfected our own "dongle", an Eprom which plugged into the cassette port and was clocked into memory. Each user had a different ID number.

The CBM 8096 was rather a disappointment to us. Like the C64 now, there was only a part of this memory available to Basic - which we used for development programming. The model we had came with some bank-switching software: but the instructions were in German, which none of us understood. By the time we had figured it out, we had obtained a compiler and development utilities which allowed us to write program modules in separate banks and link them together. We then discovered that the 8096 was disastrously slow with its bank-switch. It seemed OK until we compiled: and then the switching was no faster than in slow old Basic. Our customers, to whom we had promised great things, were rather dissatisfied since the overall ledger package was in fact rather slower than on the 8032. I think the compiler, also, was not as efficient.

By the end of 1984 sales of Commodore software were falling off. Our company was writing the same ledger packages for DEC, Apricot and IBM PC. I was the last remaining CBM specialist. To keep me busy, they made me "Quality Controller": a thankless task which involved testing other people's work. I was told to "nit-pick", so I did and became very unpopular. The work became repetitive with little challenge, so when the school where I used to teach invited me to come back and "computerise" all their pupil records (and later, other records) on databases, I retired from full-time work and took a 20-hours/wk job there. It's heaven!

For 2 or 3 years, between programming, I had been doing customer support. We would receive agonised phone-calls from customers who had corrupted their disks and had no recent backups. Some had already backed up a corrupted disk and had no valid backup to use. I got quite crafty at "re-knitting" damaged records on relative files; and usually managed to rescue the bulk of their data. One user sent in a disk which was unreadable due to fine scratches all over its surface. I asked him if he worked in a builder's yard. "How did you know?" he asked. "Because there's brick-dust in the disk sleeves" I said. Another was surprised when I suggested he ate sandwiches at the computer. "There's a greasy fingerprint on the disk surface" I said. I was right: it was butter!

There was one disk we could not recover. The user's premises had been burgled: and the thieves took away the complete CBM kit and the disks. It seems they abandoned them in a pasture not far away: and that night it snowed. Three weeks later it thawed, and the cows were let out and they investigated their field. By the time the kit was found they had smothered it in cow-pats! The user sent us his data disk and asked if we could recover the data! We had to say no.

It seemed that some users ignored our advice not to put disks near the phone. I received a disk which was "spattered" with rubbish, and I suspected magnetic influence. Asked if he kept disks near a phone or electric motor, the user said "Well - how near is near?" I said, "Oh about 6 ins. to 8 ins. is too near. He only rested his disks against the phone! When it rings, the field is quite strong. I had to send in an 'official' report for his insurance co. that "In my professional opinion, his disk was corrupted by external magnetic influence." This was apparently accepted.

At one time I thought I'd learned almost all there was to know about user problems, bugs, and so forth. Fool! Along came the Vic, the C64, the C128, Amiga, PC etc. etc.? There's always something new to learn, and I don't know the half of my C64. Scrolling, graphics, music, sampling are different worlds from mine. But what fun! I've almost mastered bank-switching.