On 12/23/2011 01:47 PM, Enrico Lazzerini wrote:
Hi all,
after i finally resurrected my BIGBOARD and I made ??the boot of the operating system
CP/M, are struggling with reading old diskettes. Before i comes out completely my mind in
the counting of all parameters to pass to the program 22disk, someone knows a
comprehensive guide on how to decode the disc formats? I am very close to the
identification of parameters, but frankly it is extremely stressful. I'll try to list
where I am keeping in mind that the format Bigboard 1 has 77 tracks x 26 sectors / track
each with 128byte single-density single-sided.
1) almost every disk CP/M in the first 2 tracks the format is 77 tracks x 26 sectors /
track each from 128byte.
Only if 8" single density, which was a standard for
CP/m If you had 8
inch. It's referred to as 8" SSSD.
Most of my systems the disk is 5.25 and either 16 sectors of 256 or 9
sectors of 512 (both DD) or the oddball
18 sector single density. Once the users left 8" single density single
sided there were very few standards
but a few were frequently used.
2) then starts the data portion that would be
double-sided and i need to remove from this portion the sectors used for the FAT whose
number is to be calculated as a function of the total number of sectors to be managed;
FAT?? CP/M never used FAT as the allocation scheme was considerably
different.
More completely the FAT does not exist in the CP/M file structures.
A peek inside the CP/M file system:
CPM uses the directory as a block of data the first 16 bytes are the
file data like name and extension. The
second 16 bytes are the allocation block numbers (as byte values for
small disks or word values for large
disks) allocated to the file. If the file has more allocation blocks
than fit in a directory extent there will mean
additional directory entries (called extents) for that file and
additional block allocations. Directory areas are
reserved in the current allocation block size for that media
(1/2/4/8/16k) and remain fixed in size. From a
programmers view the extents (each entry) carried additional information
about the file in first 16 bytes
11 of which were for the file name and extension (8.3) and the remaining
bytes told if it was erased or in
use (relative byte 0),and the last 4 bytes (relative bytes 12,13,14,15)
had data on the file and the actual
extent number if there was more than one.
File directory was a list of file names with a linkage for files of more
than one extent.
What this means is CP/M has to read the entire directory to "log in" a
disk and establish the used and available
file space and those values are stored temporarily as bit strings in
variables called ALLOC0 and ALLOC1.
This is where FAT and CP/M are different the FAT scheme has a reserved
block on disk saying whats used
and unused, where CP/M the file extents contain the block number of the
used areas to get a FAT like table
you read the directory and using the block numbers (and BIOS specific
data) you create a list of used
and available allocation areas. There are other differences ut that one
is where the two diverge the most.
Its important to note that CP/M V2 and up was deigned to allow an
experienced programmer to build their own
BIOS for a new machine or extend/improve it to allow for new storage
media and other I/O. All of the format
on the media decisions were variables available to the programmer.
This allowed great flexibility in media
used with only one restrictions that being the media must be block
addressable and that CP/M could only
address large devices in logical blocks of 8mb maximum though a large
disk could be sliced up into
multiple logical disks. This allowed it to be used with block
addressable tape, floppies
of all sizes, hard disks, Ram disks, ROMdisks, Bubble memory, even
modern IDE, CF and SD.
Note the concept of a partition table is also not par of CP/M though the
BIOS could accommodate that
using an offset into the media.
With all that said.. THE 8"SSSD CP/M standard.
First sector number are 1,,26 there is no 0. Tracks are numbered 0 to 76.
CP/M used a logical sector of 128 bytes and SSSD was also a physical
sector of 128 bytes. Larger sectors can
be used but then deblocking is the responsibility of the BIOS to manage
and the OS has the cues to help. For
the 8" SSSD case we do not have to worry about deblocking.
The first two tracks of 26 x 128 were reserved for system with first
sector having a boot file and the remaining ones used
to store the image of CPM (complete CCP, BDOS and BIOS). These do not
exist in the file system and the BIOS has these
as an offset into the media. There is an actual BIOS pararmeter called
offset and it is used by the OS to calculate the
file position on the disk.
The actual file system starts at track 2 sector 1 (first sector of track
2) and continues to track 76 sector 26. It is for all
intents the logical 0 point of the disk.
Space on the disk is allocated in 1K block (groups of 8 128 byte
sectors) per 8"SSSD standard. There are 1950
128 byte sectors available but they are used as 1K blocks so there are
243kbytes (1K=1024 bytes) of
allocatable space. Yes, there are six unused sectors at the end of the
disk because the smallest block
the OS can allocate is 1K (8 sectors) it's unusable.
The first two blocks of 1K is preallocated as directory and can hold 64
directory entries of 32bytes each.
thsi reduces the available space by 2K so there are 241K bytes of space
on an empty disk. The ALV0 and ALV1
parameters in the BIOS preallocate these. ALV1=11000000b and
ALV1=00000000b (again for SSSD 8").
The ALV parameter is a bit map of used allocation blocks and for the
8"SSSD case is typically a reserved
area in ram of 31 bytes total (one bit for every Allocation block of the
media). This is stored in the BIOS
and reflected in the medias file system organization and format.
A file can be a be 1 byte ( but one 1K allocation block will be
consumed) or can be as large as 16Kbytes
for a file extent, and using multiple extents the file can be as large
as 241K (again for the SSSD 8" case).
A file can be scattered across the disk as the OS allocates blocks on an
available basis with a bias to
sequential blocks they exist. So file fragmentation is expected after
multiple create and delete cycles.
The sectors used to create a allocation block may not be sequential.
There is a parameter to allow
skewing sectors to allow for rotation of media for better access time.
The 8" SSSD was a skew of 6
was used based on the 8080 CPU speed and current floppy controllers.
This is also both optional
and the skew value is up to the system programmer writing the BIOS. For
example for most hard
disks th rotation rate was so high that skew is never used.
3) i'm able to reconstruct the sequence of sectors
on the disk for the first 2 tracks with the CP/M and for the remain data area;
The first two tracks of a cpm disk are the system tracks and are for
loading the OS itself. They are prior to the directory
block and the general storage (called data) area after that. They are
reserved by the BIOS but there is no on disk table
of that allocation.
4) then takes over a parameter which is the allocation
unit size that means how fields are grouped together to determine the parameters DRM
5) the allocation unit size determines all the other parameters BSH, BLM, DSM
Correct this establish the disk size in storage units or allocation
blocks in the range of 1k,2k,4k, rarely larger for floppies but can be
larger
for hard disks.
This establishes things like skew and other file system geometry. They
are programmable and the BIOS designer can
as they wish select them values that suit their system.
6) Finally, AL0 and AL0 that the 22disk's
document did not clarify well to me.
AL0 and AL1 are storage areas to accounting information in the BIOS area
(in ram) for tracking what allocation blocks
are in use. Important to the BIOS programmer but not part of the on
disk structure.
This is meaningless to 22disk which read disks as foreign but requires
knowledge of the foreign disks organization.
Do not confuse this with ALV which 22disk needs to know so it used the
directory correctly and of the correct size.
SO: that it is a bit hard for me...
S0?? I need context for that to mean any thing.
Is out there anyone who can help me?
I hope this is a help. I've written many a BIOS for CP/M systems and
even rewrote portions of the internal code
for my own entertainment. If your used to DOS or Windoes based OS then
this will look very foreign as they
are different in how they used disks.
Excuse for my poor english.
Seems good to me. But I only speak one language and I admire those that
can speak many.
Allison
Enrico -Pisa - Italy