Are all DSRLNK's stateless?

[+retroclouds]

This evening I was watching the blinkenlight show on my peripheral expansion box while I was loading and saving large files with my programming editor.

The way I've set the PEB up CRU wise, is that my HRD4000B is at >1700, TIPIPEB at >1400 and TI Disk Controller at >1100.

 

Then it occured to me that for each individual level 3 I/O record access, the DSRLNK scans the cards in the PAB looking for a matching device to delegate the call.

Isn't that quite an overhead? Are there DSRLNK's out there that keep track of state?

 

If the DSRLNK has detected on the first call, that DSK6 belongs to >1700, then it could keep that state internally somewhere and in consecutive calls it could skip scanning all cards again until it finds a match.

Would it be worth the effort speed wise?

 

 

[Stuart]

But would that method fail if referring to a disk by name (DSK.MYDISK.FILE) as a disk can be changed at any time?

[+retroclouds]

12 minutes ago, Stuart said:

But would that method fail if referring to a disk by name (DSK.MYDISK.FILE) as a disk can be changed at any time?

 

Probably. The question is if it even matters for slow devices like a floppy drive. Probably not worth the effort.

For mass storage devices like TIPI, HRD, nanopeb & IDE it might be another story when handling large files.

For a long time I’ve been thinking about a way to distinguish between “slow” and “fast” devices.

 

What I have in mind is that on application startup, a device scan is done (e.g. CRC check on DSR roms or other way to identify device like a HRD). Having that information you could have a standard DSRLNK and an optimized one for mass storage devices.

 

Then again, not sure if worth the effort, considering compatibility issues, etc. 

Would be interesting to see how far this can be pushed though.

[+9640News]

I think within MyWord if memory serves me correctly, I saw Peter Hoddie use two different DSNLNK calls.  One is the standard DSRLNK.  The other "remembered" where it was last called.  There was a note in the source about being very careful to make sure the proper DSRLNK was called or one could open the wrong path.

 

I would think a revised starting/ending point could be established in the call so that if it found what you were looking for at CRU >1600, >1400, >1000, etc., it would start at that point the next time it was called and circle back to >0100 less than the starting point.

Beery

 

 

 

[+InsaneMultitasker]

Record IO, particularly variable length records with more than one record per sector, can benefit from a shortcut approach.  Time saved will depend on total records read, the number of cards preceding the target device's CRU and the number of device or subroutine entries the DSRLNK needs to search through before it finds the target.  And in the case of DSRs like the Horizon ramdisk ROS, DSRLNK must search  the devices AND subroutines due to how the tables are linked for special operations. 

 

One method is to save the CRU address and the dsr device/subprogram entry point within the main DSRLNK and then leverage those values elsewhere to turn on the card, BL to the correct address, and perform usual DSRLNK error reporting steps.   If you are using a subprogram call like >14 (direct input file read) you would call the subprogram once with the  standard DSRLNK and then switch to the shortcut version until the operation is complete. 

 

You can also implement a shortcut as a separate routine or in-line with your IO routine.  To read a file you would open with BLWP @DSRLNK and then for all remaining record IO your loop would include setting the workspace to GPLWS, set any environment addresses like 8356, R12, etc. , execute the call, restore your local WS and read/report the error. 

 

[+retroclouds]

Thanks, these are all great ideas, and certainly worth investigating. I’ve taken some notes for revisiting later.

Makes some great experiments.

 

 

[+jedimatt42]

In Force Command, I scan the card ROMs once, and the crubase is a parameter to my dsrlnk. This allows me to let you copy between / load from 2 devices with the same name as distinct.

 

 

[Tursi]

Scratchpad loader remembers the CRU base (and DSR entry point) for loading EA#5 files after the first one, too. There wasn't enough memory in scratchpad to save all the search code

 

[apersson850]

The p-system does this. It defines a couple of units it presents to the user. Like disks, serial ports, the console (screen and keyboard) etc. At boot-up, it scans for the different DSRs it needs, then remembers their CRU base address and their entry address. This is "stretching" the DSR call specification from TI a bit, and (as noted above), the current DSR for the Horizon RAMdisk doesn't support it, as it makes assumptions not only about how it's called, but also about how the DSRLNK routine is written.

[+retroclouds]

For the sake of history I'm linking to the updated dsrlnk routine (V5B) written by the great late Paolo Bagnaresi. 

As a matter of fact in this version you have the possibility to save the state in memory so that following calls in your program can jump right into it, without having to do the DSR scan again.

 

http://www.whtech.com/ftp/YAHOO group backups/SWPB/FILES/Disk Access/DSRLNK DATA A - Corrected, CRU search start REV5B CPU PAB.txt

[apersson850]

That's one way. The p-system's approach is to expand the normal PAB to a PCB, Peripheral control block. It adds CRU and entry addresses to the PAB. Once these PCB data items are in place, they are used for all calls. Searching is done only once.

Edited August 21, 2020 by apersson850

[+FALCOR4]

On 8/18/2020 at 5:05 PM, InsaneMultitasker said:

Record IO, particularly variable length records with more than one record per sector, can benefit from a shortcut approach.  Time saved will depend on total records read, the number of cards preceding the target device's CRU and the number of device or subroutine entries the DSRLNK needs to search through before it finds the target.  And in the case of DSRs like the Horizon ramdisk ROS, DSRLNK must search  the devices AND subroutines due to how the tables are linked for special operations. 

 

One method is to save the CRU address and the dsr device/subprogram entry point within the main DSRLNK and then leverage those values elsewhere to turn on the card, BL to the correct address, and perform usual DSRLNK error reporting steps.   If you are using a subprogram call like >14 (direct input file read) you would call the subprogram once with the  standard DSRLNK and then switch to the shortcut version until the operation is complete. 

 

You can also implement a shortcut as a separate routine or in-line with your IO routine.  To read a file you would open with BLWP @DSRLNK and then for all remaining record IO your loop would include setting the workspace to GPLWS, set any environment addresses like 8356, R12, etc. , execute the call, restore your local WS and read/report the error. 

 

I suspect that the RAG Assembler captures the DSR address as well.  At least, watching it in action it appears to be doing so.  When I have my HRD set to an address beyond >1100, the only time I see the disk controller card LED flash is when the assembler opens a new source file.  After that, all the action in with the HRD card until another file is needed.

[+TheBF]

On 8/21/2020 at 1:29 PM, retroclouds said:

For the sake of history I'm linking to the updated dsrlnk routine (V5B) written by the great late Paolo Bagnaresi. 

As a matter of fact in this version you have the possibility to save the state in memory so that following calls in your program can jump right into it, without having to do the DSR scan again.

 

http://www.whtech.com/ftp/YAHOO group backups/SWPB/FILES/Disk Access/DSRLNK DATA A - Corrected, CRU search start REV5B CPU PAB.txt

This great stuff. Thanks!

I have wanted to do something like this from the get go. I use a PAB stack and little array that is indexed by handles. Currently the handle just returns the PAB address.

I will study this and see how I can speed things up.