DISCS, DOS and CP/M on the EINSTEIN

This guide's original content was six unlabelled screenshots of a typed article with no accompanying text. The screenshots have been read closely and transcribed below, page by page, immediately followed by the original image of that page so readers can verify any specific number or byte value against the source. A handful of characters in the original recreation are genuinely ambiguous at any zoom level (for example "OESH" where "0E5H" may have been intended, or "ES" where "E5" may have been intended) — these are transcribed exactly as printed rather than silently corrected, since the original document itself cannot be verified against the underlying 1980s magazine source.

Introduction

Whilst reading through some of my collection of old Einstein magazines I came across a series of articles originally written by Vin Davies (a professional software author), which goes through in great detail, everything anyone could ever wish to know about DISCS, DOS and CP/M on the original EINSTEIN computer.

As the quality of these old magazines is quite poor, I decided to take it upon myself to recreate those articles and where possible add to them, the following is my attempt to do Vin's articles justice.

The Article

The standard 3" disc drive as fitted to the Einstein is a single sided 40 track drive with 10 sectors per track. A single sided disc drive can only access one side of the disc media due to having only one read/write head, although the media may be used on both sides.

A sector is 512 bytes and this is the unit of transfer to/from the disc. It is not possible to transfer smaller units, larger units are transferred as an integral multiple of 1 sector.

A DOS or CP/M record is 128 bytes. DOS (or CP/M) function 20 (see the DOS/MOS reference manual, pages 52 onwards) is provided to 'read sequential' one record, and function 21 is to 'write sequential' one record. Having just read the above paragraph which states 1 sector (512 bytes) is the unit of transfer, this sounds like an anomaly. However, when DOS receives the first instruction to read 1 record it actually reads 1 sector (4 records) into its own buffer (which is at FE00 - FFFF Hex). A buffer is just an area of memory which is used to accept the incoming data. It then provides the 128 byte record from this buffer. The next three requests to read 1 record (sequentially) result in DOS providing the required record from the buffer. The next disc read is made only when a read is requested and the buffer has been emptied. A similar process takes place when writing sequentially. DOS builds the first four records to be written into the buffer and only when the buffer is full, is the buffer, (4 records), written to disc. This is why it is essential to close a file when writing to disc has finished, because it is very likely that there are 1, 2 or 3 records in the buffer which have not been written to disc.

The diagram in the page above labels the Einstein's 3" disc: Index Access Hole, Drive Hub, Access Window, Location Holes and Write Protect Indicators.

Disc Organisation

The first two tracks are said to be reserved for the DOS (CP/M) operating system. This is not strictly true. Track 0 sector 0 and in some versions Track 0 sector 1 are for the BOOT program. This program is not part of DOS (CP/M), its purpose is to read in the operating system and pass control to the CCP, (Console Command Processor). This is the part of the operating system that analyses the user commands as typed and process them. Once a user program is executing, the CCP has no work to do and can therefore be overwritten by the user program and its data.

This explains why some programs will terminate quietly whereas others cause the default drive to activate. When the drive activates it is re-loading the operating system because the CCP may have been overwritten. DOS occupies 4 or 5 sectors in track 0 (usually sectors 5,6,7,8 and 9 depending on the version of the operating system) and all sectors in track 1. Thus there are a few sectors in track 0 that are not used by the operating system.

Part of a copy protection scheme is to place some data into one or more of these unused sectors. The 'protected program' reads the sector(s) and if the expected data is not found then it assumes that the program is an illegal copy. This part of the protection scheme will cause a copy of a program, produced by COPY.COMN (or... PIEP.sCOM), to fail because only the file has been copied and not the sectors in which the data has been planted. This scheme will not work when a disc is copied using a sector copier such as BACKUP.COM so an additional feature is required to prevent sector copiers from working. More details on this later.

The Directory

This is an area of the disc that contains information relating to specific details of files or programs on the disc. This data is on track 2, remember we number from track 0, and uses the first 4 sectors (2k bytes).

To read the directory from a disc in drive 0, enter MOS and type;

R 4000 4800 0002<E>

To view the data use the tabulate command T;

T 4000 4080<E>

Each directory entry occupies 32 bytes which are as follows:

• Byte 00 – User number, or ES if the file has been erased. On the Einstein, user areas are not implemented.
• Bytes 01-08 – The file name.
• Bytes 09-0B – The file extension (e.g. .XBS)
• Byte 0C – The extent number. An extent is 16k bytes. A file of 40k will have 3 directory entries. The first will have the extent no. 0; the second will have extent no. 1 etc.
• Byte 0D – Not Used.
• Byte 0E – Used in CP/M to record the number of extents in the file.
• Byte 0F – The number of 128 byte records in this extent. If the file is less than 16k this is the number of records in the file.
• Bytes 10-1F – Contains a list of the block numbers allocated to this extent. The Einstein blocks are 2k bytes (1k is more common) and 2 bytes specify the block number (1 is more common).

So a block number 1 appears as 01 00 (note reverse order); block number 2 appears as 02 00 etc.

Since there are 16 bytes available for the block numbers there can be a maximum of 8 two-byte block numbers. This represents 8 * 2k = 16k.

This is why one directory entry represents a maximum of 16k, i.e. one extent. The directory is a directory of extents and not files.

Block 0 is used by the directory (2k bytes) and refers to Track 2 starting at sector 1.

Block 1 is the start of the user data area and refers to track 2 starting at sector 4.

To calculate the track/sector number which corresponds to the start of a block:

1. Multiply the block number by 4 (4 sectors in 1 block).
2. Divide by 10 (10 sectors in 1 track).
3. Add 2 to the quotient to get the track no. (Block 0 starts at trk 2)
4. The remainder is the sector number corresponding to the start of the block.

Conversely to find the block no. corresponding to any track/sector no.:

1. Subtract 2 from the track number (block 0 starts at track 2).
2. Multiply the result of 1 above by 10 (10 sectors per track).
3. Add sector number.
4. Divide by 4 (4 sectors per block).
5. The quotient is the block number.

The program SCTED.COM (part of EMSOFT DSCLONE disc) displays all the features described so far and includes a calculator for converting track/sector to block number and vice versa.

The Sector Numbering System and Copy Protection

Early versions of DOS numbered the logical sectors in sequence. One track of 10 sectors was numbered:

05 06 07 08 00 01 02 03 04

The disadvantage of this is that when several sectors are to be read one after another, by the time sector 90 has been read and saved in the buffer sector 01 has passed the read/write heads of the disc drive and so a long wait occurred before sector 01 was available.

The "speed up disc" programs and later versions of DOS numbered the sectors:

00 05 01 06 02 07 03 08 04 09

So when sector 00 was written the minimum delay occurred before sector 01 was available. This sector numbering scheme is often referred to as sector interleaving or sector skew.

DOS expects sector numbers to be in the range 0 through 9.

BUT THE FLOPPY DISC CONTROLLER DOES NOT CARE WHAT NUMBERS ARE USED.

So the second part of a copy protection scheme is to format a disc so that periodically a sector number greater than 9 is used. Standard sector copying routines such as BACKUP.COM will fail to copy a disc once they encounter a non standard sector number. Thus by using some planted data in the 'unused' sectors in track 0 and incorporating some sectors greater than 9 in the formatting process we produce a copy protection mechanism that will cause any standard CP/M type copying programs to fail.

Cloning programs such as DSCLONE.COM analyse the sector numbers in the tracks of a disc to be copied and then format the receiving disc in exactly the same way. Only when the track of the receiving disc has been given an identical format to the source disc is the sector data copied.

However there are some more sophisticated methods available to 'copy protect' programs and these can be more difficult to detect. There are two approaches:

1. To make use of an undocumented feature of the disc controller.
2. To make a small change to the 'standard' pattern of bytes that exists between the data sectors.

SCTED.COM has a feature which is rarely found on other sector editors. It will give a display of the bytes which exist between the data sectors. There are 2 problems found when viewing this display and both are unavoidable due to the characteristics of the disc controller.

1. The actual data bytes, which are displayed, are corrupted.
2. Many of the bytes which exist between sectors are corrupted.

These 2 problems are of no great significance because the IMPORTANT bytes between the data sectors ARE CORRECTLY DISPLAYED and it is in these bytes that it is possible to make very small changes. The 'protected' program will analyse these bytes and if it fails to detect the small changes then it is assumed that it is an illegally copied program.

Disk Format Information

The Floppy Disk Controller (FDC) on the Einstein is the WD 1770 series chip. When a disk is formatted the data sectors are filled with a marker byte, usually OESH. But what concerns us here is the information which goes between the data sectors. These areas are referred to as the inter-block gaps (IBG's). Here is the set of bytes which, it is recommended, should be written in the IBG.

• 12 bytes – 00
• 3 bytes – F5 (FDC writes 3 * A1)
• 1 byte – FE (ID address marker)
• 1 byte – Track No
• 1 byte – Side No
• 1 byte – Sector No (0-9 is standard)
• 1 byte – Sector length (02 is standard = 2*256)
• 1 byte – FC (FDC writes 2 CRC chars)
• 22 bytes – 4E
• 12 bytes – 00
• 3 bytes – F5 (FDC writes 3 * A1)
• 1 byte – FB (Data address mark)
• 512 bytes – DATA
• 1 byte – F7 (FDC writes 2 CRC chars)
• 24 bytes – 4E

The CRC above is the Cyclic Redundancy Checksum. When data is written to disk a type of checksum is calculated AND written to disc. Subsequently, when the disk is read, the checksum is again calculated and compared with the checksum value read. If they match then all is well. If not then the message 'BAD DATA' will be seen.

The 2 items marked in bold above are:

1. SECTOR NUMBER as previously stated, the standard sector numbers are 0 through 9. However any single byte value can be used, but if this is done then any standard DOS (CP/M) program that attempts to read the file which contains the non standard sector numbers will fail with the "NO SECTOR" message (see the previous article on 'copy protection' schemes).
2. SECTOR LENGTH the standard value is 2, which means 2 units of 256 byte (giving a sector length of 512 bytes). But it is possible to include some non standard sector lengths in the formatting of a track. Once again any attempt to access a file containing a non standard sector length, when using normal DOS or CP/M programs will fail.

It must be said that a purpose built program can be written to read files which contain such irregularities.

Incidentally, it is stated that when a block of 3 * F5 is sent to the FDC then 3 * A1 will be written. This is not my experience, I have found that 2 * A1 are written with another value to make up the 3 bytes.

Another area for experiment is the 12 * 00's. It is certainly possible to alter this number slightly and this might be another candidate for using in copy protection schemes.

The format information can be examined using the SCTEDP program (select the T option). (see EMSOFT range for SCTEDP).

The Einstein Can Read Alien Disks

The Amstrad 6128 uses 2 different sector numbering systems:

For DATA format disks the sector numbers are C1 through C9 (a data format disk has no tracks for the operating system, thus it has a greater capacity). For SYSTEM format disks the sector numbers are 41 through 49. As you can see there are only 9 sectors per track on the Amstrad disks.

To read a sector from an Amstrad DATA format disk which is in drive 0 Enter MOS and type

R 1000 liFF C100

this will read 1 sector (number C1 from track 0) into location 1000. If you have a 5 1/4" drive you can also read sectors from an IBM disc (40 track).

Double Sided Disks On The Einstein

Effectively track 1 is regarded as

side 0, sectors 0 through 9 and

side 1, sectors 0A through 13

and, of course MOS can be used to read any of these sectors.

How does the operating system know which drives are single sided, double sided or 40 track or 80 track? This information is kept at FBB1. The information is loaded in when a cold start is made. The 8 bits must be regarded as two quartets. The least significant 4 bits identify which drives are single or double sided:-

• 0000 all 4 drives are single sided
• 0010 drive 1 is double sided, the rest are single sided
• 0100 drive 2 is double sided, the rest are single sided

etc.

The four most significant bits are used to determine which drives are 40 or 80 track.

• 0000 all drives are 40 track
• 0010 drive 1 is 80 track, the rest are 40 track
• 0100 drive 2 is 80 track, the rest are 40 track
• 1100 1000 drive 3 is 80 track, double sided and drive 2 is 40 track but double sided. Drives 0 and 1 are 40 track, single sided.

The Disk Parameter Block (DPB) or how does DOS (CP/M) know how the disks are organised?

The DPB contains all the information relevant to the discs which can be used on the machine. The CP/M (DOS) function call number 31 can be used to find the start address of the DPB. E.g

LD C,1
CALL 5

when these two instructions have been executed the HL register pair will contain the start address of the DPB. In DOS80 this address is at F8C0, where you will find 4 definitions for the 4 possible (different) drives which can be fitted. The details for each entry are:

Address F8C0

• Offset 0 – SPT (2 bytes) – The no. of 128 byte units in 1 track {for single sided 10 sectors = 10*4 (128 byte units) = 40 = 24 00 HEX}
• Offset 2 – BSH (1 byte) – Log (base 2) of no of 128 byte units in an allocation block. The block is 2k so there are 16 sets of 128 bytes in 1 block and log(base 2) of 16 = 4 (2*2*2*2 = 16)
• Offset 3 – ASM (1 byte) – (No of 128 byte units in one block) - 1. 16 units in 1 block, 16 - 1 = 15 = 0F
• Offset 4 – EXM (1 byte) – (No of extents which can be described in one FCB, i.e. one dir entry) - 1. As described in the first article only 1 extent can be described for each dir entry so 1 - 1 = 0 for EXM
• Offset 5 – DSM (2 bytes) – The largest block number. [s.s discs have 94 blocks = 5E 00, n.b. LO - HI order. d.s 40 track 194 blocks = C2 00. d.s 80 track 394 blocks = 8A 01]
• Offset 7 – DRM (2 bytes) – (Max no. of dir entries) - 1 [dir entry is 32 bytes, 2k for ss discs so 2048/32 = 127 = HEX 3F 00. 4K for ds discs so 4096/32 = 127 = HEX 7F 00]
• Offset 9 – ALO,1 (2 bytes) – Bitmap of dir block allocation. ALO / AL1: ss disks 1000 000 / 0000 0000 = HEX 80 00. ds disks 1100 000 / 0000 0000 = HEX C0 00
• Offset 11 – CKS (2 bytes) – No of dir entries per sector (512 bytes per sector, 32 bytes per dir entry, so 512/32 = 16 = HEX 10 00)
• Offset 13 – OFF (2 bytes) – No. of reserved tracks (for Op. Sys.). s.s disks: 2 tracks are reserved so the value is 02 00. d.s disks: 1 track (2 sides) is 01 00

Well I know some of this has been heavy going but I have received a number of requests for this information. Furthermore, if you found it heavy going try casting your mind back. Have you not had several experiences when something looked impossibly difficult which you now find easy?

Finally I must pay tribute to the originators of CP/M. It is a very simple yet powerful operating system suitable for any Micro with a 6080 or Z80 processor. Perhaps the most important aspect (which we now realise is obvious) is that the machine dependent parts of the operating system are isolated in the one program unit called the BIOS. Actually this is not quite the case for DOS 1.3 or DOS80 which do not hold their DPB's in the BIOS. In this respect these versions are more akin to the earlier versions of CP/M before 2.2. Fortunately other aspects of these versions of the operating system are superior to CP/M 2.2. The greater freedom to change disks makes things much easier.