Jump to content
IGNORED

Information on DSRs in DX10 (990 operating system)


Recommended Posts

I started writing this in the TI-99/4A Development thread for DSRLNK.   Moved to a new thread, so I can go into even more detail.  

 

For complete information:

 

DX10 Operating System Application Programming Guide, Volume 3 (946250-9703)
DX10 Operating System Systems Programming Guide, Volume 5 (946250-9705)

 

All volumes  available on Bitsavers

 

See:

 

Volume 3, Section 3: DX10 I/O System
3.5 Logical Unit Numbers and Devices

Volume 3, Section 7:  Using Supervisor Calls (SVCs)
Volume 3, Section 9: Device I/O Supervisor Calls

Volume 3, Section 10: File I/O SVCs
 

Volume 5, Section 5: How to Write a Device Service  Routine

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

I have been reading about file access under DX10, a widely-used operating system for a 990. I wanted to know what features it offered and if our 99/4A was a subset.

 

 

Comparisons of how DSRLNK and DSR and file I/O work

 

GPL  must scan all ROMs for DSRs every time.  

DSRLNK does not but ought to: save and reuse the CRU address of the card, and DSR entry point after you first access a file. 


By GPL I mean the operating system of the 99/4A, and the conventions it established.   Documents like "GPL Interface to the Disk Controller Peripheral." cover the DSR ROM calls. Klaus Schuurman was the author of this document and the DSR ROM. (Interview by Klaus.) In GPL, you use a subroutine like DSRLNK to send an I/O request to the matching DSR ROM. 

 

DX10 has all the device information in one linked list in the operating system. Let's call it PDTTBL.
 

A PDT describes one device, and has one BLWP vector into its DSR.  PDTTBL is built into DX10--you don't just plug in new devices. (See SYSGEN below)

 

There's no ROM to turn on because the DSR code is linked into DX10. A CRU address is hard-coded in the PDT record, but it's only used by the DSR code itself.  
 

The primary interface between DSR and hardware, like a disk controller, is an 8-word register space, above  F800.  This is called TILINE. 


Hello, LUNO


The OPEN #1 we all started with in TI BASIC?  The #1 is a system-wide concept for DX10: the LUNO or logical unit number!  Before using a device or file, you gave it a LUNO, logical unit number.  The table with LUNO stored file#, name, system buffer address, etc. I bet it cached the pointer to the matching PDT with the DSR entry vector.  There were global LUNOs for printers, and each user set private LUNOs for their files. I think you could pass a LUNO as a program input. That would be convenient for reusing Assembler input and output files, for instance. Like stdin and stdout in C.

 

BASIC: 

OPEN #1:"DS01.DOCUMNT.DOC", OUTPUT     (DX10 filenames were 7.3 = familiar 10 chars total!)

 

In BASIC on DX10, I imagine it does this:

1. Set LUNO #144 to "DS01.DOCUMNT.DOC". That's done through an XOP. The DSR gets looked up and stashed in the LUNO table. 

 

2. Make a SCB starting with a 0 for DSR, the opcode 0 for OPEN, some flags, 0 for default record length, the LUNO #144 etc. (Our PAB is a subset of this. Alas, PAB has no file #.)

 

3. XOP @SCB,15

4. Check error code

The LUNO is constant through all OPEN,CLOSE,REWIND,CLOSE..

 

Other than through 99/4 BASIC, we have no LUNO table. If there were, that's where DSRLNK would cache the DSR, CRU etc. And the device name need not be a part of every PAB. 


There are many more similarities and differences in the actual DSRs.  The 99/4 interface is clearly a subset of DX10.

Edited by FarmerPotato
  • Like 3
Link to comment
Share on other sites

 

Comparison of GPL and DX10 File Interface 

 

The GPL PAB contains the parameters for a DSR (reached by DSRLNK).  Thierry explains:

 

Quote

The convention to pass parameters to a DSR is to use a peripheral access block (PAB). This is a bunch of data, generally stored in the VDP memory, that is used to pass parameters to and from the called DSR or subprogram.

 

 

We'll see that the GPL PAB inherited the names and order of fields from DX10.  GPL uses just 10 bytes (not counting the name string).  Whereas DX10 has 16, and some extended varieties.


DX10 calls it the I/O Service Call Block (SCB).  Most I/O calls use the General I/O Service Call Block; some use an extended block. 

 

 

 

																		   
    GPL PAB                              DX10 General I/O Service Call Block

                                       +--------------------+----------------+
                                       |  0  00 for I/O SVC |   Error Code   |
+----------------+                     +--------------------+----------------+
| 0  Opcode      |                     |  2  I/O Opcode     |   LUNO         |
+----------------+------------------+  +--------------------+----------------+
       x         | 1 File Type/Err  |  |  4  System Flags   |  User Flags    |
+----------------+------------------+  +--------------------+----------------+
| 2       VDP Buffer Address        |  |  6        Data Buffer Address       |
+----------------+------------------+  +-------------------------------------+
| 4 Record Length|          x          |  8           Record Length          |
+----------------+------------------+  + ------------------------------------+
       x         | 5 Character Count|  | 10          Character Count         |
+----------------+------------------+  +-------------------------------------+
| 6 Record #/Program File Size      |  | 12  2-word RELATIVE Record Number   |
+-----------------------------------+  |                                     |
         x                             | 14  ..                              |
+----------------+------------------+  +-------------------------------------+
| 8 Bias/Status  | 9 Name Length    |                                       
+----------------+------------------+                                        
|10+ DSR name                       |                                        
+-----------------------------------+                                        

 

 

GPL is for a much smaller computer.  It makes do with a byte, where DX10 has a word.  Look there, you could have more than 64K records in a file!

 

The SVC Call Block or SCB is used with SVC ("Supervisor call", or I like to say "service call").  SVC is an XOP.  It's how you access the operating system services.   The first two bytes of the SCB are the SVC number and a byte for return error code.  Here, the first byte is 00 to ask for I/O service. That's your DSRLNK equivalent.

 

I'm to use the term "Opcode" to refer to the GPL opcode, for example OPEN, CLOSE, etc.  DX10 calls this the "I/O Subcommand" and reserves "Opcode" for what I call the "SVC number".

 

LUNOs

 

Notice that the SCB has no DSR name (the pathname).  Instead, you assign the pathname to a LUNO or Logical Unit Number

 

Just like TI BASIC  OPEN #1:"DSK1.MYFILE".   You need a LUNO to do any file operations.  The order is:

 

  1. Assign LUNO to file or DSR name 
  2. Open
  3. Read/Write
  4. Close
  5. Release LUNO

 

DX10 uses names like CS01 for cassette, DS01 for hard disk, DK01 for floppy disk.  So a disk pathname might look like DK01.KMG.PHONEME.SRC 

 

DX10 filenames are 7 chars plus 3 char extension.   See where GPL got its 10 char filename?

 

I wish that GPL had used LUNOs everywhere, not just TI BASIC. Allocating a little table in VDP RAM above the Disk Controller buffers.  Then DSRLNK would have a place to cache details, like the CRU address and DSR entry point of every open file. It would be more efficient.  Our intrepid programmers will work around that!

 

 

File Opcodes in GPL and DX10

 

In both GPL and DX10, the opcodes are "device independent".  Each has a similar meaning on any device.  Compare these tables of the opcodes on GPL and DX10. 

 

From Thierry again at TI Tech Pages

 

Byte 0: Opcode

This byte is used to define the type of operation to be performed by the DSR. The standard opcodes for file operations are the following:

>00 Open. Opens the file, reserves room in VDP memory to store data in.
>01 Close. Closes the file, frees the dedicated VDP memory area.
>02 Read. Input data from the file/peripheral.
>03 Write. Writes data to the file/peripheral.
>04 Rewind. Points at a given record (or at top of file).
>05 Load. Loads a memory image ("program") file.
>06 Save. Saves a memory image file.
>07 Delete. Removes a file from the storage unit.
>08 Scratch. Removes a given record from a file.
>09 Status. Returns informations about a file.

Some DSR accept other custom opcodes. For instance, the RS232 DSR accepts: >80... 
The Horizon Ramdisk supports several additional opcodes...

 

They are fully documented in the TI Tech Pages  The TI disk controller card

 

 

DX10 General I/O Opcodes

 

From DX10 Volume 3, Table 9-1

 

00 Open         - SEQUENTIAL or RELATIVE
01 Close
02 Close with EOF
03 Open Rewind
04 Close Unload
05 Read Status or File Characteristics
06 Seek Forward
07 Seek Backward
08 Not Used
09 Read ASCII   - DISPLAY  format
0A Read Direct  - INTERNAL format
0B Write ASCII  - DISPLAY  format
0C Write Direct - INTERNAL format
0D Write EOF
0E Rewind
0F Unload

 

The GPL opcodes are a subset of these, with the exception of that weird SCRATCH opcode.  In DX10, that is >49  and it applies only to KEY-INDEXED files (databases).  (more later)

 


Also essential, DX10 opcodes for File Utilities:


 

90 Create File
91 Assign LUNO
93 Release LUNO
95 Rename
96 Unprotect
97 Write Protect
98 Delete Protect File
99 Verify Path Name
9A Add Alias
9B Delete Alias
9C Define Forced Write Mode

 

In GPL, Rename is not an opcode, instead it can be found in the subprograms list of the disk DSR ROM.  Refer to "GPL Interface to the Disk Peripheral" or TI Tech Pages.   To tell DSRLNK to call a subprogram, you change the number, this makes it search the desired list of names:

 

BLWP @DSRLNK
DATA >A            this was 8 to lookup DSR for a PAB

 

 

 

A few more DX10 opcodes:

 

10 Rewrite
11 Modify Access Privileges
12 Open Extend
4A Unlock

 

 

And even more, supporting KEY-INDEXED files (not SEQUENTIAL or RELATIVE)

 

40 Open Random  KEY-INDEXED
41 Read Greater 
42 Read by Key/Read Current
44 Read Greater or Equal
45 Read Next
46 Insert
47 Rewrite
48 Read Previous
49 Scratch!
4A Unlock
50 Set Currency Equal
51 Set Currency Greater or Equal
52 Set Currency Greater


 

 

 

More of File Operation SVC Block

 

For opcodes 00-4A

 


10.2.1 Sequential and Relative Record File I/O Call Block
Figure 10-1. Sequential and Relative Record File I/O Call Block


Byte 
-2	00 for I/O SVC
-1	SVC Status Code
 0	I/O Opcode
 1	LUNO
 2	System Flags
 3	User Flags
 4	Data Buffer Address
 6	Logical Record Length
 8	Character Count
10	2-word RELATIVE Record Number

User Flags for OPEN calls:
	Bits 
	0  Initiate I/O.  When set, DX10 queues up the operation and returns control.
	1-2	Reserved (or KIF)
	3-4	Access Privileges.
		00	Exclusive WRITE
		01	Exclusive ALL
		10	Shared: for RELATIVE: Multiple LUNO can read/write. SEQUENTIAL: read, no write.
		11	Read Only
		
	5	Open: Do Not Replace File Flag.   
	    Read/Write:  1=Lock on Read, Unlock After Write
	6	Comm Timeout Unused.
	7 	Blank Suppression.  Write VARIABLE: truncate blanks. Read: Pad buffer with blanks.
	
User Flags for SEQUENTIAL or RELATIVE file operations:
	Bits
	0  Initiate I/O
	1	Unused
	2	Ignored
	3-4	Access Privileges
	5	Lock/Unlock
	6	Comm Timeout Flag
	7	Blank Adjustment Flag

System Flags (set and reset by DX10)
	Bits
	0	Busy flag: 1=Busy 0=done. Do not modify data buffer or call block when Busy.
	1	Error flag: 1=error 0=no error. Error code returned in byte 1 as status code.
	2	EOF flag: 1=end of file record encountered.
	3-7	Reserved

 

Here is the structure of a File Utility SVC Call Block

 

File Utilities (such as Create File, or Rename) need more fields, in addition to the ones mentioned so far.

 

From: DX10 Volume 3 : Section 10, Figure 10-3.

 

00	00             |  Status Code
02	Subopcode      |  LUNO
04	System flags   |  User Flags
06	Pointer to Data Buffer
08	Logical Record Length
0A	Character Count
0C	Pointer to Key Index Definition Block
0E	Reserved
10	Utility Flags
12	Defined Logical Record Length
14	Defined Physical Record Length
16	Pointer to Pathname
18	Reserved for Pointer to Passcode
1A	Reserved
1C	Initial File Allocation (CREATE FILE only)
1E	...
20	Secondary File Allocation (CREATE FILE only)
22	...

 

There's a lot of interesting things in there.  Most of them are used with Create File.

 

Initial File Allocation refers to how much disk space to reserve immediately. When a file grows out of that, there is a hint for the Second File Allocation.   This scheme doesn't fragment the disk so much.  In GPL allocation is essentially 1 sector at a time.  DX10 files can grow to 16 ever-bigger allocations; GPL disk files have many more slots.

 

Logical Record Length is what you expect, like in VARIABLE 80 or FIXED 80.  But in GPL the limit is 254.  DX10 allows 256, or the exact disk sector size which is often 288.   Just like in GPL, records are "blocked" in memory up to as many as can fit into one sector, before it gets written to disk. Some remainder is wasted.

 

Physical Record Length lets you get around that.  It defaults to one sector size.  But if you specify Physical Record Length as a sector size multiple, then that is the size of the "blocking" buffer. Records fill up that buffer, and only then is the remainder wasted.  You can use bigger Logical Record Length, up to the Physical Record Length.  

 

Other weirdness:  

  • Logical Record Length is merely a suggestion for VARIABLE records. GPL strictly enforces the limit.  DX10 just uses it to estimate the file allocation.
  • Blank Suppression in VARIABLE records: on Write ASCII, the DSR removes trailing spaces. Read ASCII puts them back (up to the buffer size).
  • Physical Record Length must be a multiple of 3 sector sizes.  (Extensive discussion in DX10 Volume 3.)
  • Passcode is not implemented in DX10.  I think it is in DNOS?

 

 

Some Code Conventions

 

Calling convention:

 

  1. Set up the SCB
  2. XOP

 

Use the assembler directive to define SVC:

DXOP SVC,15
SVC @MYSCB

* equivalent to:
XOP @MYSCB,15

 

In the 9900, XOP takes a BLWP vector from the table at >0040.  On entry, R11 in the new workspace is MYSCB. 

 

 

 

 

Create New File

 

There's a lot of example code in DX10 Volume 3.  Here's a short one:

 

10.3.1.1 Create Sequential File Example. The following example creates a call block with these specifications:

  • 80-byte logical records 288-byte physical records
  • 1000-record initial allocation 
  • 500-record secondary allocation
  • blank suppression
  • pathname of PACK.USER.TEXT.FILE01

 

*EXAMPLE

CRSEQ 	DATA O
	BYTE >90,0,0,0 	CREATE FILE
	DATA 0,0,0,0,0 
	BYTE 0   	LRL
	BYTE >8D	BLANK SUPPRESSED, EXPANDABLE, FILE TYPE
	DATA 40   	RECORD LENGTH LESS AVERAGE NO. BLANKS 
	DATA 288  	PHYSICAL RECORD LENGTH 
	DATA PATH  	PATHNAME ADDRESS
	DATA 0,0
	DATA 0,1000	INITIAL ALLOCATION 
	DATA 0,500	SECONDARY ALLOCATION 

PATH	BYTE NAME-$-1  PATHNAME LENGTH
	TEXT 'PACK.USER.TEXT.FILE01'	PATHNAME
NAME	EQU $

* Note that the logical record length has been specified as 40 on the assumption the average record contains 40 trailing blanks.

* Code:
	DXOP SVC,15
START  SVC @CRSEQ         * does XOP @CRSEQ,15

	

 

 

CRSEQ is the Service Call Block (SCB).  For the File Utilities, the structure is reused, all fields having the same meaning. This SCB is 36 bytes for CREATE FILE, but 28 bytes is all the others use.

 

 

Assign LUNO

 

After the file is created, you need to assign it to a LUNO.   Compare to TI BASIC:  

 

OPEN #1,"DSK1.MYFILE",OUTPUT,DISPLAY,VARIABLE 80

 

SCB for >91 Assign LUNO 
 

 

Byte          Meaning
0 	 	Contains SVC opcode. Must be > 00.
1    	Initialize to 0. System returns any error.
2       Contains the SVC subopcode. Must be >91. 
3       Contains the LUNO number or 0.
16      Utility flags: 
Bit 0   Created by Assign
        0= file not created
        1= file created
Bits 1,2 File Usage
        00 = no special usage
        01 = directory file (CATALOG)
        10 = PROGRAM file
        11 = image file
Bits 3,4 Scope of LUNO
        00 = task local
        01 = station local (the user's login terminal)
        10 = global
Bit 5  Generate LUNO
        1 = system generates LUNO
        0 = indicates LUNO is specified in byte 3
Bit 6  Autocreate
        1 = system creates file if it does not already exist
        0 = file must already exist

Bytes
22,23   Pathname address


 

>93 Release LUNO

 

When you are done using the file, you must:

 

Release LUNO

Byte          Meaning
0 	 Contains SVC opcode. Must be >00 for I/O.
1    	Initialize to 0. System returns any error.
2       Contains the SVC subopcode. Must be >93. 
3       Contains the LUNO number (not 0!)
16      Utility flags: 
        Bits 3,4 Scope of LUNO
        00 = task local
        01 = station local (the user's login terminal)
        10 = global

 

 

Just for fun, here is an impossible TI BASIC statement.  LUNO is the #1:

 

OPEN #1:"DSK1.MYFILE",PROGRAM,TEMPORARY,INTERNAL 11840

 

 

 

 

Edited by FarmerPotato
Totally Rewritten
  • Like 4
Link to comment
Share on other sites

I was interested to compare GPL's DSR opcodes with the set in DX10.

 

DX10 Opcodes for Device Dependent I/O!

 

I am calling them Opcodes, because that's what we would call them here. But DX10 calls them Sub-opcodes of Opcode 0 (the I/O 
service)


First, for comparison, in GPL these Opcodes are defined:

 

Reference: Thierry Nouspikel's TI Tech Pages

https://www.unige.ch/medecine/nouspikel/ti99/headers.htm#DSR%20call

 

From that page:

 


Byte 0: Opcode
This byte is used to define the type of operation to be performed by the DSR. The standard opcodes for file operations are the following:

>00 Open. Opens the file, reserves room in VDP memory to store data in.
>01 Close. Closes the file, frees the dedicated VDP memory area.
>02 Read. Input data from the file/peripheral.
>03 Write. Writes data to the file/peripheral.
>04 Rewind. Points at a given record (or at top of file).
>05 Load. Loads a memory image ("program") file.
>06 Save. Saves a memory image file.
>07 Delete. Removes a file from the storage unit.
>08 Scratch. Removes a given record from a file.
>09 Status. Returns informations about a file.

Some DSR accept other custom opcodes. For instance, the RS232 DSR accepts:

>80 Interrupts. A variant of Open that allows for interrupts upon reception of a char on a serial port.

The Horizon Ramdisk supports several additional opcodes:

>0A Assembly. Loads and runs a memory-image assembly file.
>0B Basic. Loads and runs an extended basic file.
>0C Cartridge. Loads a memory image GPL file.
>B0 Rambo. Selects a memory bank to be mapped at >6000-7FFF.
>80 to >8C: same as >00 to >0C, but uses a buffer in CPU memory rather than in VDP memory.


DX10 Device Opcodes

00 Open  SEQUENTIAL or RELATIVE
01 Close
02 Close with EOF
03 Open Rewind
04 Close Unload
05 Read Status or File Characteristics
06 Seek Forward
07 Seek Backward
09 Read ASCII   - DISPLAY format
0A Read Direct  - INTERNAL format
0B Write ASCII  - DISPLAY format
0C Write Direct - INTERNAL format
0D Write EOF
0E Rewind
0F Unload
10 Rewrite
11 Modify Access Privileges
12 Open Extend
4A Unlock


only KEY-INDEXED files (not SEQUENTIAL or RELATIVE)

40 Open Random  KEY-INDEXED
41 Read Greater 
42 Read by Key/Read Current
44 Read Greater or Equal
45 Read Next
46 Insert
47 Rewrite
48 Read Previous
49 Scratch!
4A Unlock
50 Set Currency Equal
51 Set Currency Greater or Equal
52 Set Currency Greater

 

File Utilities

90 Create File
91 Assign LUNO
93 Release LUNO
95 Rename
96 Unprotect
97 Write Protect
98 Delete Protect File
99 Verify Path Name
9A Add Alias
9B Delete Alias
9C Define Write Mode

 

Curiosities

GPL and BASIC had this vestigial file attribute PERMANENT.

DX10 offers the alternative TEMPORARY.

Close with EOF - adds an EOF mark (character?)  to the file. Can have multiple EOF on a tape!

Scratch is the GPL name.  Can only delete a record from KEY-INDEXED.

KEY-INDEXED is my syntax; TI abbreviates it KIF.  It is a B-tree with some overhead on each file, sector, and record. 

A primary key is defined as a range of characters in the record.  You can define up to 15 more search keys.

 

Reference:

 

DX10 Operating System Application Programming Guide, Volume 3 (946250-9703)
Volume 3, Section 10: File I/O SVCs

in http://www.bitsavers.org/pdf/ti/990/dx10/

 

TI Tech Pages

https://www.unige.ch/medecine/nouspikel/ti99/headers.htm#DSR


 

 

  • Like 3
Link to comment
Share on other sites

 

Operating System Code

 

 

Matching a device name to a DSR routine is much simpler than DSRLNK! 

 

In DX10, inside Service Call 0, I imagine there is some code to match the device name, 2 characters like 'DS' for disk. (CS is cassette!)

It has to walk the global linked list, PDTTBL.  Remember that PDTTBL is permanent and has all the known devices.   Each entry of PDTTBL is analogous to the DSR list under one of our ROM headers. (Thierry calls this list the true DSRs, as opposed to the other linked lists in our ROM.)

 

If the PDTNAM field matches, it calls that DSR with a BLWP.  The DSR gets its own workspace, which is always set up with useful values.  


So I imagine code like this to match the 2 character device name:

 

	LI   R0,'DS'         let R0 be the device we're looking for
	LI   R1,PDTTBL       pointer to the global table
DSR010
	MOV  *R1,R1          go to first or next entry
 	JEQ  DSR030          ?end of list, device not found
	C    PDTNAM(R1),R0   is this a match for our device?
	JNE	 DSR010
DSR020
	AI   PDT$,R1         point to the BLWP vector
	BLWP *R1             enter the DSR
DSR030
* error, device not found
	ORI  R15,>2000       set the EQ bit (i made this up)
	RTWP
        	

 

See how nice it is to have 2-char device names?  Just one Compare instruction!

 

The PDTTBL is a linked list of this data structure:


Reference:  5.3.1 WS for PDT - physical device table

 

* Layout of a PDT entry (pretend these are all DATA statements)
       DORG 0
PDTLNK        Link to next PDT
PDTMAP         Pointer to DSR map file
PDTR0     R0    Scratch
PDTPRB    R1    Pointer to PRB
PDTSDF    R2    Device status flags
PDTDTF    R3    Device type flags
PDTIB     R4    Pointer to device info block
          R5    Available for the DSR to use
          ...
          R11 
          R12    CRU base
          R13 Saved WS registers for RTWP
          ... 
          R15    
PDT$          PDT workspace address
PDTDSR        DSR entry point
PDTERR, PDTFLG, error code and flags
PDTNAM        Device name (2 characters like 'DS')    
PDTSL1        system log 1
PDTSL2        system log 2
PDTBUF        not used    
PDTBLN        Buffer length
PDTINT        Pointer to DSR interrupt routine
PDTDVQ        Device queue anchor
PDTTM1        Time out count 1
PDTTM2        Time out count 2
PDTSRB        Saved PRB address
PDTFQL        Priority DSR schedule queue word


DX10 enters the DSR with a BLWP. The code above sets up R1 to point to PDT$. After BLWP, the new WP points to the PDTR0 in the record.
The DSR will use RTWP to return.

 

GeneveOS

 

GeneveOS has one 'Master DSR' list like this.  Unfortunately, that ignores our GPL convention. Fortunately, ROMPAGE and the GeneveOS maintainers opened that up to scan PBox cards' DSR ROMs.

 

GEN990 or SYSGEN

 

DX10 is custom assembled and linked on every system when it is installed.  This is neat, because it doesn't bloat up with code for devices or features you don't use.

 

A program called GEN990 asks you about all the peripherals you have connected, the CRU address, the interrupt level, and the filename of each DSR.  From that, it is able to write the source code for the PDTTBL.  After it generates code, the assembler is invoked.  Then the linker connects all the DX10 object code with the custom object. (actually my knowledge is extrapolated from the SYSGEN of its baby operating system, TXDS. TXDS fits on floppy disk.)

 

(Caveat: I'm still just a beginner. Read the DX10 books.)

  • Like 3
Link to comment
Share on other sites

  • 4 months later...
On 2/10/2024 at 1:08 AM, retroclouds said:

You went quite deep to compare the differences between DX10 and the TI-99-4a file handling.

Was wondering, did you come on any details how the catalog of files on DX10 storage devices looks like, compared to what we have on the TI-99/4a ?

The disk organization is covered in DX10 System Design Document, section 4, which starts with the Volume Information Block.

 

Page 4-34 begins the Directory Overhead records and File Descriptor Records. This is a VCATALOG file.  When it is created, one overhead and N general records are allocated.  GPL uses a sorted list of FDRs, but VCATALOG is a hash table.  

 

When FDRs are created, the filename is hashed modulo N, and the FDR is placed in that record, or linearly after.

 

VCATALOG records might contain:

FDR - regular file descriptor

ADR - named alias to an FDR in this VCATALOG

KDR - key descriptor record, companion to the FDR of a key-indexed file. The KDR defines offset and length for up to 14 keys.

 

 

FDR flags identify it as one of these types:

regular file

directory

program file

image file

 

 

 http://www.bitsavers.org/pdf/ti/990/dx10/

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

On the TI 99/4A, the other operating system, the p-system, changes somewhat the behavior of the DSR call.

 

First, the p-system has a list of IO devices. The are called units and are either character or block units. A character unit is the keyboard or a serial port, a blocked unit is a disk device.

These units are mapped to BIOS sections handling the different operations that can be performed on a unit. Read, write, clear and so on each have their entry. For a unit like the REMOUT:, a (usually) serial output port, there is no read operation. REMIN: has no output operation.

 

The BIOS sections then map the logical task for the unit to a physical device. Unit #1 sends output to the screen, #4 to a disk, #6 to a communication port and so on. Units that behave in the same way, like the blocked units #4, #5 and #9, all map to the same physical device, the disk controller. This is where that device's DSR is called. This is done via a PCB, Peripheral Control Block, which is an extension of the PAB. When the system is booting, it populates PCB entries for all units that are in use. The CRU and entry address for the DSR for the desired function (for the disk controller it's sector read/write) are stored in the top of the PCB, followed by the PAB with its normal structure. This means that at runtime, the system simply indexes into a unit table to find the pointers for the different operations available for that unit, indexes to the right operation, finds the CRU and entry addresses through the PCB, enables the card and jumps to the proper part of the DSR without any further searching.

 

It does something similar with interrupt service. It scans all valid DSR entries and creates a list of those with an interrupt service routine, so that it on an interrupt only checks cards known to have any interrupt service at all if they did trigger the interrupt.

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...