Advice on CP/M CBIOS handling of double sided disks

[SteveH]

Hi All,

I’m looking for some advice or best practice on how to handle double sided disks within a CP/M 2.2 CBIOS. My CBIOS deblocking routines are currently working on just side 0. I’m using 8” DD disks formatted as 77 tracks, 8 x 1024 byte sectors per track and 2 sides – well, to be honest, I’m testing this using a HxC floppy emulator, but once working will switch to real diskettes.

My thoughts so far are

• Double up the number of tracks and treat even numbered tracks as side 0 and odd numbered as side 1.
• Double up the number sectors per track and treat the first 8 sectors as side 0 and the last 8 sectors as side 1.
• Double up the number of tracks and treat the first 77 as side 0 and the remainder as side 1.

I think my last idea may result in more head movement, so am inclined to discard that one, but has anyone got any other/better suggestions or gotchas? Or even, what was common practice back in the day when CP/M was prevalent.

Cheers
Steve

 

[Chuck(G)]

In CP/M, there's no "right" way. Let me elaborate.

1. You can treat one side at a time, so all sectors on side 0, then reverse direction and do all sectors on side, starting from the highest track moving down toward 0. This has the advantage that single- and double-sided floppies will treat sectors and tracks in the same sequence. If you have a multi-track boot record, you don't need to know if the disk is single-or double-sided until after you've booted.

2. You can proceed the same as (1), but instead of treating the side 1 tracks in reverse, keep the order from low-cylinder to high-cylinder. Not such a good idea, as a file that overflows the last track on side 0 will have to seek all the way back to the first track on side 1.

3. You can do things DOS-wise and simply go from side-to-side and increment the track number, but you have to be able to tell whether a floppy is single- or double-sided at first access. In order to do this, some systems alter the address mark values, so that a single-sided drive may have sector addresses of 1-26, but a double-side drive will have addresses of 129-154.

4. You can interleave the sectors from side to side.

Your choice--they've all been done.

 

[SteveH]

Thanks Chuck,

Pretty much what I thought - it was a free for all. I'm not currently concerned with single sided disks so I'll go with what's the simplest to code in my CBIOS - shift the track number right 1 bit (half it) and use the carry to determine side 0 or 1.

Cheers

 

[Chuck(G)]

I didn't even mention some of the more outré schemes, such as putting the directory in the middle of the disk, then allocating clusters in reverse (down to track 0) then upwards from the directory.

All in all, the fastest I've seen if you have the equipment is to allocate such that the cluster size is an integer factor of the track size; use both sides, with the second size being "skewed" to allow for the head switch time and read both sides at 1:1 interleave in one operation and cache them in memory. Writes can be handled on a sector-by-sector basis, since they generally comprise only 10% of disk accesses. But whole-track caching really makes a huge difference.

The downside is that the code's more complex and more memory is required. But on a floppy-only system, the system can really fly.

 

[krebizfan]

If you have any existing CP/M disks, implement that format. If you can read an existing disk, you know the code works correctly. I doubt the speed benefits to getting the optimal layout are as useful now as they used to be.

 

[SteveH]

... But whole-track caching really makes a huge difference.
The downside is that the code's more complex and more memory is required. But on a floppy-only system, the system can really fly.

Unfortunately, it's not a luxury I want to afford on the beast I restored. It's already got 4KB tied up in BIOS and monitor proms, plus more memory used by the 6845 CRT controller. For now, it's a trade off between size and speed.

If you have any existing CP/M disks, implement that format.

I've only got the hardware and thus far all attempts at finding any original software have fallen flat. So for now, it's just roll my own and see how it goes (both fun and a learning experience). The beast in question can be seen in this thread - 1982 British built LSI M-THREE computer restoration project

 

[Chuck(G)]

Whatever, you should always implement a common organization as a "bailout". In 8", it's the DRI "A1" (sssd 8", 26 128-byte sectors/track). After that, you're on your own.

Sometimes, the situation arises where you have more RAM than you need.

I've got an old Amstrad "Joyce" word processor sitting here with a Z80 and 512KB of memory, but floppies only. To date, all I've done with the excess memory is use it as a RAMdisk. Unfortunately, the architecture doesn't lend itself to expansion; otherwise it might be fun.

 

[SteveH]

Whatever, you should always implement a common organization as a "bailout". In 8", it's the DRI "A1" (sssd 8", 26 128-byte sectors/track). After that, you're on your own.

IIRC from some 30 years or so ago when I first used an LSI M-THREE, the manufacturers version of CP/M supported a "patchable" drive P that allowed different disk formats to be configured. I could probably do the same, defaulting to DRIs A1 format.