Scorpio News |
April–June 1987 – Volume 1. Issue 2. |
Page 44 of 51 |
---|
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 extent 512.
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.
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 the next issue.
The user of 80-BUS compatible products has been quite well served for floppy controllers – initially by the Gemini GM809 , then the GM829 with SASI support for a Winchester, closely followed by the even more supportive GM849 – 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?
The MPI 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.
Page 44 of 51 |
---|