LAST ARCHIVE

ARCHIVES INDEX

NEXT ARCHIVE

SEVEN-AND-A-HALF BITS (What no comment?)

Joe Griffin

A Black Mark for Commodore

I sent a copy of my article on 128D/1571DCR bugs to Commodore at both Maidenhead (to the MD, Steve Franklin ) and to West Chester (to Fred Bowen ). Neither party has bothered to respond, not even a letter to acknowledge receipt or say they will look into it. I am extremely sorry that Commodore choose to turn their back on the user like this.

A Gold Star for Creative Micro Designs

Having been informed by Tim Harris of Financial Systems Software that the 1571DCR bug also existed in the JiffyDOS ROM, I sent a copy of my article and a disk containing the test program to Creative Micro Designs, the authors of JiffyDOS. In mid-July, I received a letter from Mark Fellows, President of CMD.

In his letter, Mark comments that "The exact cause of the problem is surprising (but not that surprising if you are familiar with the way Commodore does things ! ). A comparison with the upgraded (V5) ROM revealed that Commodore fully intended for the C128D drive ROM to be bug-free. All the required changes made in the 1571 V5 ' fix ' ROM are present in the C128D ROM ... EXCEPT THREE !! "

In order, to fix the C128D ROM, the only thing required was to put the missing three patches into place. The C128D DOS now functions flawlessly.

Mark has commented on some points in my original article and has given me permission to repeat those comments.

• The 1571-CR drive in the 128D does include custom circuitry and this is why the V5 ROM was not 100% compatible.
  
  
• The stand alone 1571, and that in the 128D Portable machines, does have a WD 1770 controller but its only function is to read/write MFM encoded data. It is NEVER used with a standard Commodore formatted disk, even in burst mode.

• The 318047-01 ROM (fitted in the 128D) is not a Version 8 ROM, but is a V5 ROM, adapted to the new circuitry, but with the problem of the "missing patches" mentioned above. To Mark's knowledge, Commodore has no plans for developing or releasing a Version 8 1571 ROM.

• The 318047-01 ROM is not a "stop-gap" version. It is a ROM that one of Commodore's programmers messed up. The reason that a corrected ROM has not been released is that Commodore had produced a very large quantity of defective ROMs before the problem was discovered. Naturally, Commodore are not interested in scrapping a million-dollar inventory of 318047-01 ROMs, so they continue to install them in 128D's. It should be noted that the 318047-01's are "mask" ROMs and are NOT re-programmable. If Commodore ever use up their stock of these, then maybe a fixed version will be released.

The good news for owners of 128D Desktop machines is that the V5.10 JiffyDOS ROM is now available either as a fix-it ROM or as part of JiffyDOS from Financial Systems Software limited (0385-553153).

1541 ROMs

Since publishing drive identification information in this column, I have been contacted by a number of owners of very early 1541s. On these machines, location $ff15 in the drive ROM contains the value 170 ($aa). This area of the chip was unused, so a fill byte was put in there. Later versions of the 1541 incorporated a patch which was put into the free space and hence the value has changed.

1581 Bugs

True to form, Commodore have managed to introduce a smattering of bugs into the 3.5 inch drive. On the hardware side, very early models are reputed to have a WD 1770 controller. This could give corrupted directories during disk copying. A public domain program is available (1 have a copy) which checks whether the 1770 or 1772 chip is fitted. Anyone who finds that their 1581 contains a 1770 should consider getting it replaced with a 1772. FSSL have more details on the upgrade.

On the software / firmware side, the 1581 is not blameless either! Problems can occur in creating sub-sub directories (though I have not experienced this problem) but of major concern is that because of a bug associated with the. track cache buffer, block allocate commands do not work, if a block write is carried out at the same time.

The problem can be demonstrated by using the program on page 75/76 of the 1581 User's Guide. Type in the program and run it a few times on a blank, formatted disk. Then display the directory of the disk, the 'blocks free' should be a few less than the 3160 of an empty disk. Now remove the disk from the drive and re-insert it, then again list the directory. The number of blocks free has mysteriously gone back up to 3160 ! If you look at the sectors which should have been written, you will indeed find that the data in them has been altered but they have not been allocated.

During the production of Superbase 3 for the 1581 a number of problems were encountered. Data written to the disk mysteriously disappeared. Eventually it was found that, because of this bug, the 1581 DOS was only updating the data sectors and not the BAM on the disk. Simon eventually got details of an address in the 1581 ROM which could be used to force a BAM update. I will publish details if I can get them.

For interest, it is worth noting that if a block allocate command is carried out without writing data to the sector, then the BAM is correctly altered. I suspect that the problem comes about because the track buffer does not rewrite the barn if a sector other than on the directory track is to be rewritten.

Files, Directories and Direct Access

Unlike most other floppy disk systems, Commodore 8-bit disk drives (with one notable exception, the 1581) do not use the Modified Frequency Modulation (MFM) recording method. In the early days of the PET, Chuck Peddle's team devised the Group Code Recording (GCR) method of encoding the data onto the media. This allowed a higher storage capacity and a greater reliability than contemporary units.

The distinguishing features of these GCR drives include a variable number of sectors per track. The outermost (longer) tracks have more sectors than the innermost (shorter) ones.

On all drives, including the 1581, a directory of the files (including pointers to the actual file data) established by the disk operating system (DOS) is maintained on its own track, about haft way across the disk surface. A record of the used and unused disk sectors, known as the Block Availability Map (BAM), is maintained by the DOS and uses one or more disk sectors on, or adjacent to, the directory track. Even though unused sectors of the directory track are not allocated in the BAM, DOS considers this track to be inviolate and will not use it for storing data.

Each sector in the directory, or in a file established by the DOS, contains as its first two bytes a pointer, comprising the track number and sector number of the location of the next block of the file. These pointers are maintained by the DOS, as is the BAM, and are of no importance to the user, provided that all disk accesses are via files of a type supported by the DOS.

Commodore have however provided routines which allow the user to access disk sectors directly (direct access programming). When this is done, as with machine code programming of the CPU, the user is given great freedom but carries a heavy responsibility. No housekeeping is done: track and sector links are not provided and the BAM is not updated, unless the user specifically carries out these tasks. Also the direct access routines know nothing of and care little for the sanctity of the directory track. It is by use of direct access routines that a directory can be modified, or even linked back into itself, to become endless.

When a direct access 'Block-Allocate' command is given, one of two things will happen; if the sector addresses is unused, it will be marked as used in the BAM. However, if it is already used, then an error message will be generated with the location of the next available sector contained within the error string. The 'next' sector will always be later on the same track, or on a higher numbered one.

To create a direct access file with linked sectors requires something like the following procedure:

• Allocate the sector.

• Allocate it a second time.
• Read error string to obtain address of next free sector.
• Place pointers to next sector in data buffer.
• Place remainder of data in buffer.
• Write buffer to the original sector.
• Repeat for next sector.

When less than a full buffer of data is left, the track link is replaced by a zero byte and the sector byte by the number of bytes of data to be written.

This is obviously quite a tricky method of working and requires quite a lot of disk accessing. For Superbase, Simon & Tom devised a simpler method of working, which is quite ingenious - they write the file backwards!

The directory entry points, not to the first sector, but to the last and each sector points back, not forward. To add a further sector requires that the program finds the first free sector after that pointed to by the database file header block. The pointers required are already known from the header, so this block can be written and allocated. The header block is then updated with the address of this new current sector and a consistent file chain has been established.

Problems do however occur, as mentioned above, with the directory track. On a 4040 / 1541 format disk the directory is on track 18. Imagine the situation as direct access fills up track 17 - sectors are allocated in the order 0,1,2,...,18,19,20 but then the end of the track has been reached. The next available sector is the first free one on track 18 (the directory track). A smart programmer would include code to check the track number and if it is 18, increment it before writing any data (this is what S&T do in S'base ). A very thorough programmer would also reset the sector counter to 0, so that it continues from 19,0 ( often 18,0 [header] and 18,1 [directory start] will be the only blocks used on track 18, so S'base frequently continues from 19,2).

Obviously when different drives are used, the program needs to distinguish the type of drive in use and avoid the appropriate directory track(s). For example, the following disk systems are the common ones:

Disk Drive	Directory Track
4040,1541,1570	Track 18
1571	Track 18 AND Track 53
8050,8250	Track 39
1581	Track 40

Commodore hard drives use Track 1 or thereabouts, but may be more complicated (I don't know much about them).

8 bit switches

In the last issue, Dal Hale wrote about adding device change switches to the 128D. Like him I wanted the option to switch the built-in drive out on occasions. From the Twin-Cities 128 Compendium, I obtained the same information as he got by looking inside the case. However, I used a pair of sub-miniature toggle switches, as they are a lot easier to set and only need a round hole drilled for fitting, not a cut-out.

Spurred on by the success of this venture I carried out what appears to be the ultimate unnecessary modification. I fitted toggle switches to my 1581 which already has DIP switches fitted. The toggles nicely fit one each side at the bottom corners of the back and are wired in parallel with the DIP switches, which need to be left open for the toggles to take effect. The reason for this modification was that I can now change the device number of the '81 by feel, instead of having to disconnect it, take it from its shelf and poke around inside the back with a fine screwdriver.

If you are thinking of fitting switches to a 128D, it is worth considering using toggles as they make switching a lot easier.

Basic 8 Printer drivers

One of our members contacted me some time ago about using his MPS1000 with the Basic 8 package. Although the MPS is said to be Epson compatible, it does not work with the Basic 8 Epson driver and he could only use it in 801 emulation mode. After borrowing an MPS manual from our illustrious Chairman, I found that the MPS does not share the Epson's ability to set all graphics modes from one command using a different index number for each but need separate but similarly structured commands. A fairly trivial change to the source code allowed the driver to modify the printer command string, according to the mode required. This has been tested on my Epson and I assume it will work with the MPS1000 set into IBM mode on the serial bus. If anyone would like a copy, I will happily supply it.

TOP