not is by whether there is a zero in the block position of the directory entry.
What CP/M doesn’t know is which records have been written to the block; this is
left for the programmer to determine.
One way of doing this is to use the write random with zero fill function when
writing to a previously unallocated block. To establish, from within a program,
wheather or not a block has bean allocated to a file is to read the desired
record using the read random function. If an error code is returned, you are
trying to read a block that has not been allocated, i.e. CP/M found a zero
in the relevant position in the directory entry. If this happens, you can write
the record with zero fill. If no error code is returned, a block has already
bee allocated which could contain the wanted record. If you previously used
the zero fill function when writing a record to this block, examination of the
contents of the required record will reveal zeros if nothing has been written to
it or data if something has been written.
A point worth noting is that the CP/M DIR command will only show a file if a
directory entry exists for extent 0. For this reason, writing one record to
record position 63535, for example, will result in two directory entries being
created; an empty one covering extent 0 and one covering the 128th record of
Another observation about random files is the way that PIP.COM handles them (or
more accurately, it doesn’t). PIP,COM reads and writes files sequentially and
will therefore get an end of file code from the BDOS when it encounters an
unallocated block in a file. Normally, this would be adequate as most files
indeed end this way. If faced with the example of a file that contains only
record 65535, PIP.COM will only copy the empty directory entry for extent 0.
BIOS date structures
Some questions that still need to be answered are: how does CP/M know how many
block the disk contains, what size are they, how many of them are reserved for
the directory and how does it keep track of which ones are free for use? The
short answer is that the BIOS contains this information but to amswer these
questions in detail, some information about BIOS data structures is required.
The disk routines in the BIOS contain data areas and buffer space that will be
used by the BDOS when it needs to have information that is system dependent.
These areas are known as the Disk Parameter Headers (DPH’s), Disk Parameter
Blocks (DPB’s}, Checksum Vectors and Allocation Vectors. We’ll look at these in
MAP 80 Multi-Purpose Interface (MPI) Review
by P.D. Coker
The user of 80-BUS compatible products has been quite well served for floppy
controllers – initially by the Gemini
support for a Winchester, closely followed by the even more supportive
Map 80’s VFC
was also capable of
controlling 5.25″ drives and Nascom/Lucas also
produced an FDC card. So why have Map produced yet another card?
is more than just an FDC, catering for the usual range of disk size
with support for a Winchester drive or two. By changing a few links and the
FDC chip one can convert to Nascom FDC compatibility rather then the more usual
Gemini/Map “standard”. It also has a CTC and two channels of SIO, one of which
is a standard RS232 and the other conforms to the proposed standard for RS485
(high speed multi-drop interface). The CTC can be used to generate software
selectable baud rates or, if the user wishes, on-board crystals can be used to
generate two frequencies on the MPI board which are independent of the system
clock. It uses 16 ports and, in my experience, can substitute for either of the
two earlier Gemini FDC’s – I have no experience of the most recent Gemini FDC.