Jump to content
IGNORED

About disks and formatting on the Adam


tschak909

Recommended Posts

About formatting disks on the Adam:

 

(long post, buckle up.)

 

Floppy disk access is handled via AdamNet, and AdamNet only has a few basic commands, READ, WRITE, and STATUS. 

There are character devices on AdamNet, and there are block devices. Block devices deal in terms of a block number, and some payload of a fixed size, usually 1024 bytes.

Floppy drives are block devices, so they add a request for a block for each read and write. Then there is the block payload, 1024 bytes, either sent, or received. The block number is 4 bytes long (32 bits), meaning that you can read and write to block devices that are approximately 4.3T in size.

 

BUT...

 

Since there is no FORMAT command, and Coleco didn't add a mechanism for miscellaneous commands, the WRITE command is used, with a block number of 0xFACE (64206), any writes to this block (the block payload does not matter) will cause the drive to invoke its formatting routine. What this formatting routine actually does, is dependent on the drive, and Adam has no control over it whatsoever. It sends the command (and ironically, keeps re-sending it, because the drive does not respond while formatting), and waits for either an ACK (success) or a NACK (failure).

 

At this point, the disk is formatted, it has address marks for each sector on the disk, but the disk contents are undefined.

 

Once this is done, a file system can be put on the disk. For the Adam, there really are two major filesystems, EOS, and CP/M.

 

For EOS, the INITIALIZE DIRECTORY command in the EOS ROM can prepare the target volume, you give it the number of blocks on the device. EOS only accepts a 16-bit number here, so the total number of blocks allowed on an EOS volume is 65535, or 64 megabytes. You also give it the number of blocks wanted for the directory, more blocks, more directory entries. A volume name of 12 characters is specified as well. You'll notice that this maps up exactly with various formatting tools such as Coleco Disk Manager and AJM File Manager, even the INIT command in SmartBasic. All they are doing is calling EOS to do the file system write. A caveat is that existing data in the blocks occupied by the directory can cause make directory to fail.

 

CP/M is different, and it has to do with the fact that CP/M existed long before and after the Adam. CP/M was originally developed for the Intel MDS-800, a development system that was created to aid hardware and software engineers using the Intel 8080 in their own designs. 

 

From here on out, I will use the term sector to refer to a unit of storage on the floppy disk. It does not correspond to a block, which is a unit of transfer to and from the Adam. 

The floppy disk system that it used expected 8" disks in the IBM 3740 format, which was THE standard format for 8" disks in the 1970s. The IBM 3740 system could not format its own disks, so new disks were available from IBM and other vendors preformatted for use, in that they had their address markers written for each sector, and filled with a fill byte. Because of how the disks encoded their data, IBM determined the ideal fill byte for each sector to be hex E5. This was the most complex bit pattern that could be encoded by the controller, and was a good stress test for verifying the media. 

 

Why is this fill byte important?

 

Because many early systems that used IBM 3740 format could not format their own disks, CP/M had to accept this, and build their entire filesystem around this constraint, specifically in the sectors occupied by the directory.

 

CP/M uses the e5 byte to indicate an unused directory entry. It doesn't care how the rest of the disk is filled, but it must have the sectors occupied by the directory initially filled with E5 bytes so that it knows that the disk is ready for use.

 

I will take a slight aside here, to point something out:

 

There is absolutely no mechanism to query a drive for the properties of the media it contains.

 

This means, that every formatting program must explicitly specify disk size while formatting, not for the format itself, but for the corresponding verify so that it knows the highest possible sector/block address. This is hard-coded into all of the typically available formatting programs (and in my opinion is really silly in today's context of virtual disk interfaces!)

So, when you use FORMAT.COM under CP/M? It will send the format command, regardless of capacity, but it will only verify the first 160 blocks. Same if you use a formatting tool that knows about other disk capacities. 

 

This is ultimately why it is a good idea to write new tools (and keep them free/open source!) to format and manage disks both in the context of vintage drives and the newer virtual devices that are dynamic, and the older tools need to be retired.

 

Hopefully what I have written above goes a step towards dispelling the cruft of anecdotes that have peppered this community with regards to disk storage.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...