Jump to content

Photo

DSRLINK Code Tutorial


155 replies to this topic

#151 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,804 posts
  • Location:Silver Run, Maryland

Posted Sun Oct 28, 2018 3:24 PM

I might have found a bug in CLASSIC99 when using TYPE 3 disks or I still don't understand things.

 

I was working over my DSRLNK and it worked perfectly when reading the file status field in the PAB while using TYPE 1 and TYPE 2 disks.

But with a type three disk I never got a change in status when I hit the EOF.

 

I spent a long time cursing my inability to find the problem in the Asm code.  :)

 

In desperation I wanted to see what I was missing so I ran the equivalent program in BASIC and...  it doesn't seem to find the EOF bits in the status flag either.

 

Here is the BASIC program:

100 REM   CATALOG DISK PROGRAM    
110 PRINT "Input DSKx. :";
120 INPUT DSK$
130 OPEN #1:DSK$,INPUT ,INTERNAL,RELATIVE
140 INPUT #1:N$,X,Y,Z
150 PRINT N$,X;Y;Z
160 GOTO 140
170 CLOSE #1
180 END

Run it and INPUT a type 1 or 2 disk and it will error out on 140.

But on a type 3 disk it runs forever, just like my Forth programs.

 

Is my analysis correct?

 

I am not sure you have chosen the best example file for this topic.  DSKx.CATALOG is not a real file.  The DSR provides the user with exactly 128 “records” with null strings for nonexistent file names.  These are always presented alphabetically with the null records at the end.  This allows you to abort reading records at the first record with a null filename string, which is how I do it in fbForth 2.0 (ported from TurboForth).  Having not yet analyzed the DSR routine that generates the “file”, I cannot say how it may differ from normal file access.

 

The above notwithstanding, I did try to dig through the DSR’s READ routine to see if it handled VARIABLE files differently from FIXED files regarding incrementing the PAB to the next record to be read.  I think it does, but I was having a little trouble following the ALC.  I do know that, for RELATIVE files in TI Basic, TI recommended to use a method different from EOF to check for the last record read.  I would also say that the fault for the failure of your code to error out when it passed the end of file may lie more with TI Basic’s INPUT than with the DSR’s READ routine.  I say this partly because the DSR’s READ routine only seems to distinguish between VARIABLE and FIXED files, not whether they were opened in SEQUENTIAL or RELATIVE mode.  Of course, I may have missed something.  I would certainly try your code on a file of your own making before concluding there is a problem with Classic99.

 

...lee



#152 TheBF ONLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 786 posts
  • Location:The Great White North

Posted Sun Oct 28, 2018 5:30 PM

OK that makes sense. I thought that all files would report EOF the same way.  I see now that the directory is a fixed length file with empty records.

 

So I can change my disk directory utilities to test for a null file name.  Simple.

 

Thanks Lee

 

But for the record, Classic99 reports an EOF with type 1 and type 2 files.


Edited by TheBF, Sun Oct 28, 2018 5:31 PM.


#153 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,322 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Oct 28, 2018 7:46 PM

"Type 1" and "Type 2", being FIAD and DOAD, are DSRs that I wrote, that (originally, at least) behave like I believe a DSR should. All input is through the PAB, and all behaviors run through standard interfaces. "Type 3" runs the TI disk controller ROM, which everyone else considers perfection. ;) Directories are handled very differently from files there.

 

Your code is just hoping that a file error will stop it. With a quick look at the disk DSR, it appears it will report EOF after 128 records are read, without regard to how many files are on the disk. It DOES check whether it's out of files, and if it is, then yeah, it /explicitly/ returns the zero size record instead of EOF.

 

I suppose I could make my DSR work that way too, but it seems kind of dumb. Still, I'll take a note. ;)



#154 TheBF ONLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 786 posts
  • Location:The Great White North

Posted Sun Oct 28, 2018 9:27 PM

As long as we know it's not a big deal to be sure. 

 

While I am here, I notice that the DSR code I took from here clears R1 and then does INC R1 before it does the BL *R9.

 

Is that something that other programs use to count the entries into the DSR?  It doesn't seem to make a difference if I comment those 2 lines out.



#155 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,804 posts
  • Location:Silver Run, Maryland

Posted Mon Oct 29, 2018 12:23 AM

As long as we know it's not a big deal to be sure. 

 

While I am here, I notice that the DSR code I took from here clears R1 and then does INC R1 before it does the BL *R9.

 

Is that something that other programs use to count the entries into the DSR?  It doesn't seem to make a difference if I comment those 2 lines out.

 

R1 is only important if the caller of DSRLNK cares which instance of a device/program routine was run.  R1 will only ever contain 1 if the first hit on the name search runs successfully and takes the normal return by performing  “INCT R11” before returning.  A DSR may actually contain the device/program name sought, but refuse to run it or otherwise take the error return immediately following “BL *R9”, i.e., not do the normal “INCT R11” before returning.  If the error return is taken, the same DSR search continues until the device/program is either found again (a duplicate name[?]) or the list is exhausted.  If the list is exhausted, the next DSR ROM is searched.  If the name is found in any of these subsequent searches, R1 is incremented and saved as are the new entry point and CRU.  Once a device/program routine is run to completion with the normal return, R1 is likely trashed, but the caller of DSRLNK can use the saved value of R1 to discover which instance of the device/program routine was run as well as its entry point and which card (by its CRU) did the deed from the other saved values.

 

The saved values that appear unimportant because they are not actually used in the E/A-type DSRLNK may have been put there for debugging purposes or future use.  I agree with your conclusions that they are not critical to your current programming, but, with the exception of the saved R1,  they certainly could be used to shorten file access for already open files.  Saving R1 appears only useful as a debugging tool.

 

...lee



#156 TheBF ONLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 786 posts
  • Location:The Great White North

Posted Mon Oct 29, 2018 7:28 AM

Your knowledge of this machine is always amazing Lee.

 

I tried a version without GPL R1 being incremented before each call and it messed up sometimes so It stays.

 

For anyone who's interested here is the current DSR Link I am using, re-written for the XFC99 cross-assembler.

It seems to work pretty well now. I replaced some jumps with structured loops and  if/endif  which helps me see the shape of the code.

There are conditions where the code jumps out of the structured loops. I left these alone because a complete re-write is needed if I wanted it "pretty".

(make it work, then make it better)

 

EDIT: The original posted version was un-reliable due to me trying to keep interrupts on in part of DSRLNK code. 

          I have re-posted the reliable version. Interrupts are disabled while the code runs.

 

Spoiler

Edited by TheBF, Thu Nov 15, 2018 7:54 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users