99/4A DISK PERIPHERAL SOFTWARE AND THE VDP

The following was published in TILines in the 1980s, and is a combination of data from various manuals and my own inputs. -[Colin Hinson]

Apologies for the layout and tables, one day I will find the time to fix the layout in html and fix the tables in html instead of relying on Courier font.


T.I. 99/4A DISK PERIPHERAL OVERVIEW (Continued)
So far in the previous parts of this article, we have dealt with
the floppy disc layout and the methods of accessing the disc itself.
When accessing the disc from a high level (i.e. using file access as
opposed to sector access), current information about the disc and
file(s) etc are held in VDP ram so as to avoid having to re-access the
relevant sectors on the disc each time a sector is read from a file. In
addition to this data space is also required to buffer the data being
read from the disc. The memory used for this is at the high end of VDP
ram and is permanently allocated by the power up routine within the DSR
ROM of the disc controller, and as a consequence cannot be used by
application programs, although its size can be changed by a (GPL)
utility routine.
The allocated VDP memory is roughly sub-divided into three
categories:
1. Drive Control information
2. File allocation information
3. Data buffering.
Each of these is discussed below.
DRIVE CONTROL INFORMATION
In order to control the Disc hardware, the software needs to know
the current status of each drive before it can access it. All this
information is readily available (some through checking the actual
current status of the drive directly).
The power up routines take care of the FD1771 register intialisation.
FILE ALLOCATION INFORMATION
File allocation information is held in the File Control Blocks
(FCBs), each open file having an FCB associated with it.
The information contained in the FCB is identical to the File
Descriptor Record (FDR) data held on the disc for each file, with the
addition of 6 bytes of dynamic information about each file. These six
bytes are stored in front of the FDR information (i.e. the FDR starts at
FDB byte 6). As the length of the FDR is 256bytes and there is a data
buffer for each file of 256 bytes, the total length of an FDB is
therefore 256+256+6 = 518 bytes.
The format of the 6 byte extension of the FDR is:
Bytes -6 and -5 = Current logical Record offset on Level 2
Bytes -4 and -3 = Physical Record location of the FDR
Byte -2 = Logical Record offset
Byte -1 = Drive ID
The meanings of these entries are as follows:
Drive ID - Contains the Drive number on which the associated file
resides. If the highest bit of this byte is set, then
the current data block has been modified and it will
have to be written back to the drive before the file
is closed or a new data block is accessed.
Logical Record offset - Contains the offset of the next logical
record in the current physical record. If during a
READ operation this points to a byte entry of >FF
then this indicates an end of record for the current
physical record.
Note that this entry is used only for variable
length records. For fixed length records, the actual
AU and the position within that AU is computed before
each I/O operation, and therefore the logical record
offset byte is irrelevant.
During WRITE operations, this offset points to
the first free byte in the physical record. If the
next logical record would leave less than one byte
in the current record, a byte count of >FF will be
written, and the logical record will be located in
the next physical record. The first logical record
in a physical record can never cause the physical
record to overflow as the maximum logical record
length is 254 and the physical record length is 256.
Physical location of the FDR - Points to the physical sector on
the disc where the FDR resides for the associated
file, and is used when it is necessary to re-write
the FDR to the disc. It is maintained on read only
accesses even though it is not required.
Current Logical Record Offset on Level 2 - Contains the physical
record offset of the most recently processed physical
record and is independant of READ or WRITE operations.
Always contains the logical offset for Level 2 of the
datablock which is currently in memory.
It should be noted that this system causes fixed length sequential
files to be accessed as relative access files on Level 2.
DATA BUFFERING
In order to buffer the data to and from the disc, a 256 byte buffer
is maintained for each OPEN file. The buffer is located immediately
above the FCB memory area.
One of the VDP RAM buffers is permanently assigned for processing
VIBs (Volume Information Blocks - see previous parts of this series).
If more than one drive is used in WRITE mode, then the bit maps are
moved in and out of this area as required. This buffer is accessed for
each access to the disc VIB.
Every Level 3 WRITE operation to a file will eventually be passed
on to Level 2 as a physical sector WRITE. To keep the number of disc
accesses to a minimum, a flag (the MS bit of the Drive ID) to indicate
that the current data buffer has been modified. The data buffer is only
written to the disc if the next physical record access involves another
physical record. If the file is closed then the last data buffer is
written onto the disc if required (this is the reason why the ends of
files go missing if you forget to close them!).
VDP MEMORY LAYOUT
The memory layout is outlined in the diagram (such as it is!)
below. This block of memory is reserved by the power up routine in the
Disc DSR ROM. The size of the area from then on depends upon the number
of files which are allowed to be open at the same time, and is initially
set to 3. This number can be varied between one and 16 by calling a
subprogram (through CALL FILES from BASIC). Each extra file will of
course take up 518 bytes.
As for each peripheral, the disc peripheral identifies its reserved
area through its CRU address (unique for each peripheral). The area is
'validated' by an >AA byte, followed by the address of the previous top
of memory. As the disc peripheral has the highest priority on power up,
this entry will always point to the actual top of memory. The disc
system does not use this however, and so will work equally well on other
CRU locations.
The first entry after the CRU ID contains the number of files for
which the area is reserved, and directly determines the length of the
reserved area. After this entry come the areas reserved for the FCBs
and the associated buffers for each file. In order to simplify(?) the
buffer allocation, buffers are not allocated on demand, but as soon as a
file is opened. The FCB and buffer are associated with the file for its
entire 'open' life.
+------------------------+
3FFF |                        |
|  Name Compare Buffer   |        +----------------+
3FF5 |                        |       /| Current track 3|
+------------------------+      / +----------------+
3FF4 |                        |     /  | Current track 2|
|  Volume                |    /   +----------------+
~    Information         ~   |    | Current track 1|
|        Block           |   |    +----------------+
3EF5 |                        |   |    | Current Disc No|
+------------------------+   /   /+----------------+
3EF4 |                        |  /   /
|  Additional Info.      | /   /
3EEF |                        |/   /   +----------------+
+------------------------+   /   /|                |
3EEE |                        |  /   / | Data Buffer N  |
|   Disk Status Info.    | /   /  |                |
3EEB |                        |/   /   +----------------+
+------------------------+   /    |                |
3EEA |                        |  /     |  File          |
|  VDP Stack space       | /      |    Control     |
3DEB |                        |/       |     Block N    |
+------------------------+        |                |
3DEA |                        |        +----------------+
|   Data and             |        |                |
~     File buffer        ~        ~                ~
|       Space            |        |                |
3DEB-N*518 |                        |        +----------------+
+------------------------+        |                |
3DEA-N*518 | Maximum No. of files(N)|\       |  Data Buffer   |
+------------------------+ \      |    number 1    |
3DE9-N*518 |      CRU ID            |  \     +----------------+
+------------------------+   \    |                |
3DE8-N*518 | Next Buffer  (>3FFF)   |    \   |  File          |
+------------------------+     \  |    Control     |
3DE6-N*518 | Validity code ( >AA)   |      \ |      Block #1  |
+------------------------+       \|                |
3DE5-N*518 |                        |        +----------------+

The VDP Stack area is used to simulate a stack based machine with
the TMS 9900, giving the programmer the advantage of being able to use
the multilevel stack oriented CALL/RETURN system, rather than the single
level BL system used by the 9900 series processors. The stack can of
course also be used to PUSH and POP registers and data to and from it.
The disc status information area is used to save the current track
numbers of the (3) drives, and the most recently accessed drive number.
The additional information area is no longer used (by the 99/4A).
The VIB buffer is described above.
At the top of memory, an 11-byte buffer is reserved which is used
for name comparison. Every high level entry point automatically saves
the drive number and the 10 character file name in this entry. If less
than 10 characters are available, the buffer is padded with spaces.
Next time: DSR subprograms
Colin Hinson.

Donations for the upkeep of these pages :


If you have any comments, complaints, suggestions, requests, links that don't work etc, please drop me a line via my Genuki email page.

If you want to know when the page changes, try a change tracker such as PageCrawl.io


web counter