Good Grief, Commodore, NOT AGAIN!
(an article to be published in the ICPUG Newsletter March/April 1989, copies also passed to 'CBUG' and 'Twin Cities 128')

by Joe Griffin

The opinions and comments contained in this article are my own and do not constitute an official statement in my capacity as Vice-Chairman of ICPUG.  The findings are based on my experiences with my own 128-DCR (metal cased machine) and a friend's 'Portable' (plastic cased model).  The latter machine has been used with both the 'as-fitted' (Version 3) rom and a 'Fix-it' (Version 5) rom.

I would welcome feedback from other owners of the metal cased machine,
particularly from any American users.

Back in the summer I bought a C-128, to take over from the PET as my main workhorse.  After some consideration, I decided to buy a new 'Desktop' model for four main reasons.

- Better shielding (less radio interference)
- No fan  (quieter)
- 64k video RAM    (allowing more intricate screen usage)
- latest disk ROM  (fixing the dreaded 1571 bugs)

At least that's what I thought.  After an initial period of teething trouble during which a Video RAM fault appeared, I sent the machine back for repair twice.  The first time it was returned to me, there was no change in the fault.  The second time it came back, the fault was fixed but after half an hour an i/o chip blew and it got very fussy about accepting anything from the keyboard.  At that point I was given a new machine!  Touch wood, it's still working.

At last, I was able to compare the results obtained with my requirements.  Unlike my PET which made any radio within 50 feet howl, the C-128 gave only minimal interference.  It does exhibit a slight hum from the power supply, but compared with earlier 128D's, it's virtually silent.  I'm just starting to get into Video, but the extra ram does appear to be useful for things like a 48 kbyte ram-disk.  Finally the 1571 seemed to be a good fast drive and as it would happily compile a large program with PetSpeed, I assumed it was bug-fixed (an earlier 1571 fell over in a fairly spectacular fashion until a 'fix-rom' was fitted).  I transferred a large, important database from the 8250 to the 1571 and was pleased by the general behaviour.  Time passed and I used and altered the data, taking regular backups.

Then I heard that Superbase 3 was nearing the beta-test stage.  I rang Peter Maclaurin of Precision to offer my services, explaining that I had a new 128D, so I would be able to check it's behaviour with the fixed rom.  My complacency was somewhat rudely shattered when Pete asked "Why do you say it's got the fixed rom, have you put a new rom in?"  I explained that it was a new machine and therefore...  Pete interrupted me and explained the simple fact that just because Commodore have fixed the rom doesn't mean that they actually put it into their computers!  He advised that I use the Greg Perry program to check it (see ICPUG National Magazine Vol9 No3, p239).

That evening, I typed in the few lines of Greg's program and set it to work.  It chundered away, creating a large relative file and writing a few records.  Then it continued, apparently reading from the relative file and writing into a sequential file.  This was fine, obviously there were no bugs in this drive! Then came the point at which the write file was closed and re-opened for reading.  Up came the message 'write file open error'.  Well at least it wasn't the original bug!  After some time experimenting, I found that it left the sequential file as a 'splat' file, rather than a correctly closed one.  So much for a bug-free drive.

At that point I started to look at my database and found widespread corruption.  Fortunately my earliest backup (of 4) was only suffering from major damage, not total disaster.  Using the Superbase Utility program I was able to get back all but 5 records and I was able to copy those across from the 8250 version.

After talking to both Precision and Commodore at the PC Show, I opened the 128D and checked the rom number - it is 318047-01 (DOS $62A0).  I was told that it is actually version 4a, a partially fixed, stop gap version.  The theory I was given for it's existence is that if Commodore actually released the rom, it would be seen as an acknowledgement that earlier versions were wrong and the door would be open for all sorts of law suits.

After some delay, I obtained a version 5 rom (Part No 310654-05).  This was fitted and checked.  The test program behaved correctly and soon everything seemed OK...

A little time later, I tried to back up one of my work disks, using 'Gulp Copy' a utility (from Transactor) which uses the 1750 RAM Pack to buffer an entire disk.  It hung!  Well, I thought, some of the routines have moved around a bit and there isn't a lot I can do about it until I have time to look at the code.

Some considerable time later I bought 'Big Blue Reader'.  It worked well on the 1581 but hung on the 1571.  The manual did advise upgrading to Version 5 roms, so it couldn't be that.  I quickly checked this by running it on a friend's 128 (with Version 5 rom).  It worked happily.  A copy of the rom code was taken from each machine and compared - they were identical!

What I had overlooked is that the latest 128D's (referred to as 128-DCR) are the 'cost reduced' version.  I believe that there is also a 1571-CR.  In my 'D' there is no separate disk controller board, just a single motherboard.  Most importantly, the drive does not include the Western Digital 1770 controller, which handles the burst mode activity.  I suspect that my problem was that the rom was trying to use burst mode with a controller which was not there.  Discussions with one source have suggested that the 318047-01 rom is essentially version 8 of the 1571 rom and that this will be offered in future, in place of version 5 as an upgrade.

From my findings, it appears that we are right back to stage one with the 1571 bug.  Until such time as Commodore can offer us a working fix, any 1571 drive using the 318047-01 rom should be regarded as suspect and not used as a double sided drive when important data is at stake.  If in doubt, use the Greg Perry program to check out your drive.

As I stated at the start of this article, I would welcome feedback from other users, just in case I have a 'rogue' machine.  In the meantime I am contacting Commodore for their comments.  I will report progress through this journal. 
Post script
 (not published in the above article but will appear as an update)

The statement above, about the 1770 WD controller was inaccurate.  It was based on a comment in an article in Twin Cities 128 (Issue 17).  I now understand from John Collins (Ex-CBM Electronics) that the 1571's have never had the WD controller, but use custom circuitry.  So why the problem again? 

It is also worth noting that in Version 3 (original) and Version 5 (Fix-it) ROMs, the reset error message declares the dos to be V3.0 but the ROM in the 128DCR gives it as V3.1 - an easy check.