Jump to content

Photo

Checking for disk error in assembly


11 replies to this topic

#1 senior_falcon ONLINE  

senior_falcon

    Dragonstomper

  • 861 posts
  • Location:Lansing, NY, USA

Posted Sun May 7, 2017 7:26 PM

I need some information on how to check for disk errors from an assembly program. Here's the PAB set up to open an IV254 file.  (The improper file name is intentional.)

>001A,>0800,>FE00,>0000,>600B,DS3.PROGRAM

After DSRLNK the PAB is exactly the same.  Byte 1, the Flag/Status byte is unmodified and none of the first 3 bits have been set to indicate an error.

After DSRLNK the STATUS byte at >837C is >C4.  The COND bit (bit 2) has not been set to indicate an error.

This is in a program running in TI BASIC using the EA cartridge and using the built in DSRLNK.  

Something must be missing from the E/A manual.  How do I detect the above error?


Edited by senior_falcon, Sun May 7, 2017 9:32 PM.


#2 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,156 posts
  • Location:Beaverton, OR

Posted Sun May 7, 2017 9:10 PM

To my understanding, assuming no DSR will service "DS3."    The File Management Specification says  the Flag bits error code of '0' means BAD Device Name, device is not in the system.

 

The FMS also agrees with you, in this case, saying the 'COND' bit in the cpu status should be set.

 

Are you using the console ROM's DSRLNK?

 

Another document I have says that at the end of the namematch, if no match is found, we go to >006A in rom, and that code clears the COND bit...     So success would be flag:0, and cond/equal:1  no match, flag:0, and cond/equal:0    maybe...

 

Maybe a quick test of a success to compare against, would illuminate.  Is this one of those EA manual errors we always hear about? 

 

 

006A  :     SZCB @>011B,@>837C

 

I don't see any other way to interpret the EA manual, than the way you are reading it.  So unless the EA DSRLNK routine differs from GPLDSR... ?  ?  

 

-M@  



#3 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Sun May 7, 2017 9:26 PM

Presuming the string of hex values ahead of “DS3.PROGRAM” are the first 10 bytes of the PAB, byte 9 has the wrong length for the filename.  It should be >0B, not >0F.  I don't know what effect that would have on error tracking, however.

 

...lee



#4 senior_falcon ONLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 861 posts
  • Location:Lansing, NY, USA

Posted Sun May 7, 2017 9:30 PM

 

Are you using the console ROM's DSRLNK?

 

 

The BASIC program does CALL INIT and then the assembly subroutine has REF DSRLNK



#5 senior_falcon ONLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 861 posts
  • Location:Lansing, NY, USA

Posted Sun May 7, 2017 9:32 PM

Presuming the string of hex values ahead of “DS3.PROGRAM” are the first 10 bytes of the PAB, byte 9 has the wrong length for the filename.  It should be >0B, not >0F.  I don't know what effect that would have on error tracking, however.

 

...lee

You are right, I made an error in copying.  It was >0B.  I have edited the post.


  • RXB likes this

#6 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,659 posts

Posted Sun May 7, 2017 9:44 PM

Directly after your call to DSRLNK, try testing the EQ bit and see if that gets you anywhere. 

 

BLWP @DSRLNK

DATA 8

JEQ  ERROR

 

A few other things to check:

Does the routine work properly with a 'good' device and name?  Did you copy the PAB into VDP?  Is >8356 pointing to your length byte in VDP (i.e., if you copy the PAB to v>1000 does 8356 contain >1009?)   And you are using your own WS, not GPLWS?



#7 senior_falcon ONLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 861 posts
  • Location:Lansing, NY, USA

Posted Mon May 8, 2017 5:26 AM

Directly after your call to DSRLNK, try testing the EQ bit and see if that gets you anywhere. 

 

BLWP @DSRLNK

DATA 8

JEQ  ERROR

 

A few other things to check:

Does the routine work properly with a 'good' device and name?  Did you copy the PAB into VDP?  Is >8356 pointing to your length byte in VDP (i.e., if you copy the PAB to v>1000 does 8356 contain >1009?)   And you are using your own WS, not GPLWS?

With the bad device name EQ is set after the DSRLNK.   With a good device name it is not set.  So that seems to be the problem.  A big thank you to the folks at TI for omitting that from the manual.  GRRR.

To answer your other questions, yes,yes,yes, and yes.  (it never hurts to ask)



#8 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,659 posts

Posted Mon May 8, 2017 10:36 AM

The E/A manual does mention the EQ bit in the DSRLNK utility section though I don't recall it saying much, if anything, about setting EQ for incorrect devices.  The reason I mentioned it is because the DSRLNK routines I've used reset or set that bit via R15 using SZCB or SOCB.

 

I wonder if the original DSRLNK was written as documented and the direction changed at some point.   



#9 senior_falcon ONLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 861 posts
  • Location:Lansing, NY, USA

Posted Mon May 8, 2017 10:59 AM

  A big thank you to the folks at TI for omitting that from the manual.

I take it back.  It actually is in there on page 262.  Anyway, thanks for the help!



#10 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,351 posts
  • Location:Denmark

Posted Mon May 8, 2017 12:47 PM

Does that mean that if the error code is 0 it is not enough to check the COND bit, you always need to check the EQ flag?



#11 senior_falcon ONLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 861 posts
  • Location:Lansing, NY, USA

Posted Mon May 8, 2017 12:57 PM

It looks that way.  The error code and condition bit did not pick up the bad disk name error, but the EQ flag does.



#12 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Mon May 8, 2017 6:45 PM

It looks that way.  The error code and condition bit did not pick up the bad disk name error, but the EQ flag does.

 

The ALC for the E/A utilities (from Thierry's site) is in the spoiler below.  Labels are actual low RAM addresses preceded by ‘A’.
 
Spoiler
 
DSRLNK is from >22B2 – >2397. When it runs through all of the cards in DSR ROM space without finding a device name for type 8 or a subprogram name for type >10 calls, the test at >231E will cause the “JEQ  A2388” to be taken. This changes back to the DSRLNK workspace, clears R1 (normally has the contents of PAB+1 = flag/status byte), stashes it in the caller's R0, sets the EQ bit in the caller's status register and returns to caller.
 
fbForth 2.0 uses the MG DSRLNK, which calls the console GROM 0's DSRLNK routine.  When that returns, it does pretty much the same as the E/A DSRLNK error return, except that it relies on the console's GPL DSRLNK to have set the CND (EQ) bit if the device or subprogram was not found. The return, therefore, happens the same way except that the GPL status byte should actually have the CND bit set and testable upon return—something not possible with the E/A DSRLNK and the reason it did not work for you.
 
...lee





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users