Subject: Disk DSR Error Code

From: "Stuart" <[email-masked]>
Date: Wed, 09 Feb 2011 00:38:16 -0000

Reading an error code after a BLWP @DSRLNK, DATA 8. Do you have to read it from the 1st byte of the PAB, or is it in the MSB of R0 as stated in Section 16.2.4 of the E/A manual, or is the error code stored in both these places?

Thanks.

Stuart.

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 9 Feb 2011 06:44:04 +0100

In a standard DSRLNK with DATA >8, R0 will always contain the error code, 
which just happens to be a copy of Byte 1 in the VDP Ram PAB. Note that 
this is the second byte in the VDP PAB and NOT the first because count 
starts from byte 0 of PAB, which is the true first byte of the PAB.

On the other hand, in a DSRLNK with DATA >A and unless you use a modified 
DSRLNK, the TI DSRLNK will falsely return an hypotetical byte 1 of PAB in 
your R0. The value will always be wrong, because it will be taken from the 
8th byte before the Name Device Lenght byte in PAB (the value you store in 
 >8356 before calling the DRSLNK).

Now, in a DSRLNK with DATA >A the PAB is just 2 bytes long, and there is 
no meaningful value 8 bytes before the Name Device Lenght byte in PAB.
As it turns out, the error code in a DSRLNK with DATA >A will be store by 
the DSR at byte >8350 of CPU RAM (Scratch PAD Area). There, and not 
anywhere else (VDP) will your error code, if any, be taken in case of a 
DSRLNK with DATA >A. Unless you use a modified DSRLNK, it is your duty to 
check byte >8350 in your code in such cases, ignoring whatever your R0 
will offer to you.

Hope this helps a little.

Paolo Bagnaresi

----- Original Message ----- 
From: "Stuart" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 1:38 AM
Subject: [TI994A] Disk DSR Error Code

Reading an error code after a BLWP @DSRLNK, DATA 8. Do you have to read it 
from the 1st byte of the PAB, or is it in the MSB of R0 as stated in 
Section 16.2.4 of the E/A manual, or is the error code stored in both 
these places?

Thanks.

Stuart.

---

From: "Stuart" <[email-masked]>
Date: Wed, 09 Feb 2011 13:44:18 -0000

Thanks for confirming Paolo. Now to work out why I'm sometimes getting an error code 8 instead of 7 ...

Stuart.

--- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@...> wrote:
> From: "Stuart" <ti99@...>

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 9 Feb 2011 17:49:10 +0100

According to the E/A manual page 298-299, DSR Error code 8 simply does not 
exist. Did you perform the standard SRL R0,13 before inspecting the 
content of R0? The error code is in bit 0 through 2 of R0 MSByte and 
usually people prefer to have those three bits aligned on the right of R0 
LSByte, thus the SRL R0,13.

As a side note, you have to check R0 content only if the JEQ ERROR is 
taken after the DSRLNK (which is the same as saying that an alternate JNE 
OK is not taken). If no DRS error happened, R0 of your workspace will just 
contain whatever was in it before calling the DSRLNK.

Paolo

----- Original Message ----- 
From: "Stuart"
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 2:44 PM
Subject: [TI994A] Re: Disk DSR Error Code

Thanks for confirming Paolo. Now to work out why I'm sometimes getting an 
error code 8 instead of 7 ...

Stuart.

--- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@...>

---

From: "epergrem" <[email-masked]>
Date: Wed, 09 Feb 2011 17:22:12 -0000

According to "Functional Specs for the 99/4 Disk Peripheral" the error codes are zero relative, so is it possible that the 8 is really a 7?

Ernie

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 9 Feb 2011 19:30:17 +0100

"Zero relative" ? What does it mean.

For what I know, 3 bits can count up to 7, not more.
Error code 0, with the EQ bit set in the STATUS byte "indicate a bad 
device name". This according to E/A manual, at the bottom of page 298.

Paolo Bagnaresi

----- Original Message ----- 
From: "epergrem"
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 6:22 PM
Subject: [TI994A] Re: Disk DSR Error Code

According to "Functional Specs for the 99/4 Disk Peripheral" the error 
codes are zero relative, so is it possible that the 8 is really a 7?

Ernie

---

From: ti99_forever <[email-masked]>
Date: Wed, 9 Feb 2011 10:53:46 -0800 (PST)

The problem is the very bad documentation of DSRLNK in the EA manual...

Paolo, you should write something up that puts all the material in one place... 

I don't remember that DSRLNK put the error code in R0, I remember reading that damn byte myself when I did it...

And I didn't realize that bad calls to a non-existent DSR are recorded elsewhere...
 
--- On Wed, 2/9/11, Paolo Bagnaresi <[email-masked]> wrote:

> From: Paolo Bagnaresi <[email-masked]>
> Subject: Re: [TI994A] Re: Disk DSR Error Code
> To: [email-masked]
> Date: Wednesday, February 9, 2011, 1:30 PM
> > According to the E/A manual page 298-299, DSR Error
> code 8 simply does 
> > not
> > usually people prefer to have those three bits aligned
> on the right of 
> > R0
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>     [email-masked]
> 
> 
> 

____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

---

From: "epergrem" <[email-masked]>
Date: Wed, 09 Feb 2011 19:18:35 -0000

Paolo,
"Zero relative" simply means that the error codes begin at 0 and not 1.  Because there are 8 codes, I was just asking if he was starting at 0 or 1.

Ernie

--- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@...> wrote:
> --- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@> 
> wrote:
> >

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 9 Feb 2011 22:08:35 +0100

Hi Ben!

Yes, TI could have written a better E/A manual, but when it comes to 
DSRLNK error codes the documentation is quite straightforward. See page 
262 of the E/A manual:

"If an I/O error occurs, the equal bit is set, and the error code is 
stored in the most significant byte of Register R0 of the calling 
program's worskspace." Which happens to be true.

Now, you may not use the TI DSRLNK and of course the code in your personal 
DSRLNK might differ, but a standard DSRLNK behaves as described. Then 
again, you can ignore what is in R0 of your calling workspace, and 
directly access byte PAB+1 in VDP Ram (FLAG/STATUS). It's just the same, 
you will find the same error code, if any, that is already in your R0.

As for "Paolo, you should write something up that puts all the material in 
one place...". I don't have a site where to put my material. There are, 
indeed, source codes I would like to share. But even on whtech I always 
have to ask somebody who has access to the uploading area.

But maybe you mean I should write one big document where to put ... ??? 
What, all I know about DSRLNK? It's not much more than what I have already 
written on the various yahoo groups about TI about it, really.

Thanks for your interest and encouraging.

Paolo Bagnaresi

----- Original Message ----- 
From: "ti99_forever"
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 7:53 PM
Subject: Re: [TI994A] Re: Disk DSR Error Code

Paolo, you should write something up that puts all the material in one 
place...

I don't remember that DSRLNK put the error code in R0, I remember reading 
that damn byte myself when I did it...

And I didn't realize that bad calls to a non-existent DSR are recorded 
elsewhere...

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 9 Feb 2011 22:18:39 +0100

Hi Ernie,

understood, thanks. DSRLNK reports values from 0 to 7 as error codes. The 
reported values should not be changed, so that the error codes will match 
those listed by the E/A manual.
And this just for the sake of simplicity.

Of course you may change all that, and develop a program that lists 
different numbers for errors known with a different value in other more 
standard programs. Granted, TI E/A manual is not a Bible. And, after all, 
it's a free world the one we live in ;-)

Paolo

----- Original Message ----- 
From: "epergrem" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 8:18 PM
Subject: [TI994A] Re: Disk DSR Error Code

Paolo,
"Zero relative" simply means that the error codes begin at 0 and not 1. 
Because there are 8 codes, I was just asking if he was starting at 0 or 1.

Ernie

---

From: ti99_forever <[email-masked]>
Date: Wed, 9 Feb 2011 13:49:12 -0800 (PST)

There was the "undocumented" DSRLNK routines (the >A ones). I remember first learning how to call them when I called Myarc about a typo in the back of their HFDC manual and the person told me the format of the 2-byte PAB. I couldn't believe him, but he was right, it worked...

Much later I finally discovered the TI documents with the hidden info.

But I don't remember the part about a non-existent DSR being called...

and there were some books put out that didn't do the proper error checking, if at all...

--- On Wed, 2/9/11, Paolo Bagnaresi <[email-masked]> wrote:

> Date: Wednesday, February 9, 2011, 4:08 PM
> Hi Ben!
>

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 10 Feb 2011 00:12:49 +0100

Hi Ben,

"But I don't remember the part about a non-existent DSR being called..."

Mmmh, I didn't explain myself well enough. Sorry about that.
I never meant there was a non-existant DSR. I said "the TI DSRLNK will 
falsely return an hypotetical byte 1 of PAB in your R0."

This does not mean you called a non-existant DSR. This simply means that a 
standard DSRLNK, like the one that gets loaded in Low Memory by E/A module 
option 3 (Load and Run) will return to your calling R0 the byte found 8 
bytes before the byte that contains the Name Lenght in the VDP PAB in Ram 
(which is the address in VDP that you put in >8356 before calling the 
DSRLNK).

Now, DSRLNK will return to you the content of Byte 1 in the VDP PAB (count 
starts from byte 0) in case of a DSRLNK with DATA 8, but the content of a 
byte that is placed 8 bytes before Byte 1 in the VDP PAB (count starts 
always from byte 0) in case of a DSRLNK with DATA >A.

This is because with DSRLNK DATA >A the PAB is just 2 bytes long, and you 
put in >8356 the address of Byte 1 in PAB. 8 bytes before that address in 
VDP there could be anything. That anything will be returned to you as 
error code with DSRLNK DATA >A.

This is the portion of a standard DSRLNK that generates a false error 
code:
      MOV  @>8356,R0
      MOV  R0,R9
      AI   R9,-8

Later on, that address stored in R9 will be used to read byte 1 in PAB 
(FLAG/STATUS),

       MOV  R9,R0
       BLWP @VSBR

This is just fine with a DSRLNK with DATA 8, but deadly wrong with a 
DSRLNK with DATA >A.
The code should check the value of the DATA following the DSRLNK before 
checking for errors.
And, in case of DATA >A, the error code has to be taken from byte >8350 in 
CPU Ram, and not from the VDP PAB.

So, there is not a non-existant DSR. It's just that the DSRLNK TI gave to 
the users in the E/A module was structured to not take into account the 
possibility of calling a DSRLNK with a DATA different from 8. I think TI 
just wanted to keep secret all the calls to directly access the disk by 
sector, and wanted us to access the disk just by filename. Users did not 
have to know anything about direct sector access.

In my opinion, TI goofed there anyway. If they wanted to keep secret the 
DATA >A call, the did not have to add any DATA after the DSRLNK. The 
DSRLNK code itself would have used 8 as a fixed offset from the beginning 
of >4000 CPU RAM (the address where all the DSR start from).

At the beinning of their DSRLNK, instead of a
        MOV *R14+,R5

they could have used a
        LI R5,8

and we could not have used their DSRLNK for any secret call any more. But 
all this is just retro-speculation that doesn't lead us anywhere...

What matters is: "Have fun with your code!"

Paolo Bagnaresi

----- Original Message ----- 
From: "ti99_forever"
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 10:49 PM
Subject: Re: [TI994A] Re: Disk DSR Error Code

> There was the "undocumented" DSRLNK routines (the >A ones). I remember 
> first learning how to call them when I called Myarc about a typo in the 
> back of their HFDC manual and the person told me the format of the 
> 2-byte PAB. I couldn't believe him, but he was right, it worked...
>

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 10 Feb 2011 00:22:36 +0100

----- Original Message ----- 
From: "ti99_forever"
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 10:49 PM
Subject: Re: [TI994A] Re: Disk DSR Error Code

> 2-byte PAB. I couldn't believe him, but he was right, it worked...

Yes, I got to know the DATA >A calls through an italian roman TI user, who 
bought the Myarc WDS-100 Whinchester hard disk system (Myarc Personality 
Card, I belive it was).

Apparently, Myarc used to give away TI secrets (if we admit that was 
indeed a secret) to their best customers ;-)

Paolo Bagnaresi

---

From: mark wills <[email-masked]>
Date: Thu, 10 Feb 2011 00:04:42 +0000 (GMT)

It's only put in R0 *if* there was an error.

So you need something like:

BLWP @DSRLNK
DATA 8
JEQ ERROR

( code for no error)

...
...
...

ERROR
SLA R0,12 ; move error code to LSW
...
...

If my memory serves me correctly... That's how it's done in TurboForth.

Mark

________________________________
From: ti99_forever <[email-masked]>
To: [email-masked]
Sent: Wed, 9 February, 2011 18:53:46
Subject: Re: [TI994A] Re: Disk DSR Error Code

I don't remember that DSRLNK put the error code in R0, I remember reading that 
damn byte myself when I did it...

Yahoo! Groups Links

    http://docs.yahoo.com/info/terms/

---

From: mark wills <[email-masked]>
Date: Thu, 10 Feb 2011 00:06:24 +0000 (GMT)

Paolo

Planet-99.net has an articles section tailor made for this kind of stuff!

Mark

Sent: Wed, 9 February, 2011 21:08:35

Hi Ben!

Paolo Bagnaresi

----- Original Message ----- 
From: "ti99_forever"
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 7:53 PM
Subject: Re: [TI994A] Re: Disk DSR Error Code

Yahoo! Groups Links

---

From: mark wills <[email-masked]>
Date: Thu, 10 Feb 2011 00:11:44 +0000 (GMT)

There's a nice write up of level 2 sub-programs and their 'mini PABs' (as I call 
them) on Fred Kaal's web site:

http://members.ziggo.nl/fgkaal/level2subprograms.html

Regards

Mark

---

From: "Stuart" <[email-masked]>
Date: Thu, 10 Feb 2011 00:30:06 -0000

Turns out the error code returned was always correct, but I had a bug in the code that prints it ...

Stuart.

--- In [email-masked], "epergrem" <epergrem@...> wrote:
> --- In [email-masked], "Paolo Bagnaresi" <paul.bagnaresi@> wrote:
> >

---

From: Insane Multitasker <[email-masked]>
Date: Wed, 9 Feb 2011 20:22:58 -0600

The "File Management Specification for TI_994 Personal Computer" document specifies the condition bit is set when a device is not found.  The condition bit was not intended to be used for error codes 1-7.  Error 0 is only used in conjunction with the condition bit; otherwise, condition 0 indicates no error. 
 
If held to this standard, a DSRLNK written in this fashion expects the user to test the condition bit.  If set, and error byte=0, the device was not found.  On the other hand, if not set, and error byte not equal to zero, an error occured. The only time the calling routine should assume no error occured is if and only if the condition by is reset and the error byte=0.  
 
Finally, the document does specify the user should clear the error byte prior to each call.  This can be especially important when using CPU versus VDP RAM as your PAB location.
 
Regardless, I have encountered programs that operate in the manner described by the document.  As has been discussed, subprogram DSRLNK access (DATA 10) is handled differently. 
 
Tim

---

From: Jeffrey White <[email-masked]>
Date: Wed, 9 Feb 2011 20:29:58 -0800 (PST)

You know, Paolo, if I ever get to Italy, I need to shake your hand.  Your are 
truly one of  the best 99ers.  The closest I have gotten to Italy is 
Brannenburg, Germany.  However, my company has as its mission world domination, 
so I may get to Italy, yet.
 
Jeff White
 
p.s.: What is better than fried chicken and beer?

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 10 Feb 2011 06:51:39 +0100

Hi Tim,

you wrote:

"The condition bit was not intended to be used for error codes 1-7."
Well, that of course is true for what the DSR inside the Eprom does, but 
TI DSRLNK is a different beast and goes a step further. I am talking about 
the DSRLNK that TI added to the utilities of the E/A Module.

There, you can find that for *any* error code (0 through 7) the Condition 
bit of STATUS will always be set. Which is kind of handy, after all. Why 
double checking the STATUS condition bit if On or Off and the PAB+1 byte 
in VDP as well? Just one check does it all!

Besides, E/A manual clearly states (page 262, concerning DSRLNK) that if 
no error occurred, the EQ bit in STATUS will be reset (JNE OK).

Let's say that with DSRLNK TI changed a bit what the had decided 
previously ;-)

Paolo Bagnaresi

----- Original Message ----- 
From: "Insane Multitasker" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 10, 2011 3:22 AM
Subject: RE: [TI994A] Re: Disk DSR Error Code

The "File Management Specification for TI_994 Personal Computer" document 
specifies the condition bit is set when a device is not found.  The 
condition bit was not intended to be used for error codes 1-7.  Error 0 is 
only used in conjunction with the condition bit; otherwise, condition 0 
indicates no error.

If held to this standard, a DSRLNK written in this fashion expects the 
user to test the condition bit.  If set, and error byte=0, the device was 
not found.  On the other hand, if not set, and error byte not equal to 
zero, an error occured. The only time the calling routine should assume no 
error occured is if and only if the condition by is reset and the error 
byte=0.

Finally, the document does specify the user should clear the error byte 
prior to each call.  This can be especially important when using CPU 
versus VDP RAM as your PAB location.

Regardless, I have encountered programs that operate in the manner 
described by the document.  As has been discussed, subprogram DSRLNK 
access (DATA 10) is handled differently.

Tim

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 10 Feb 2011 07:13:43 +0100

Hey Jeff,

you gotta be careful, you made me blush!  ;-)

Thanks for the appreciation, Jeff. Said by you it has an immense value to 
me.

> "What is better than fried chicken and beer? "

Italy has a good reputation when it comes to food. As a mtter of fact, we 
had more than 2700 years to practise on that field.

What about "Bucatini all'amatriciana"? It's hollow spaghetti with a sauce 
of unsmoked bacon, tomatoes and sheep cheese. If well done, it's just 
delicious!

Paolo Bagnaresi

----- Original Message ----- 
From: "Jeffrey White" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 10, 2011 5:29 AM
Subject: Re: [TI994A] Re: Disk DSR Error Code

You know, Paolo, if I ever get to Italy, I need to shake your hand. Your 
are
truly one of the best 99ers. The closest I have gotten to Italy is
Brannenburg, Germany. However, my company has as its mission world 
domination,
so I may get to Italy, yet.

Jeff White

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 10 Feb 2011 10:26:16 +0100

Wrong tip on my side.

The value returned by DRSLNK in R0 MSByte of your calling workspace is
*already* shifted by 13 positions. In other words, the value returned in
your R0 MSByte is already in the range 0-7.
No need to shift it again.

But if you read it yourself from the VDP PAB+1 (FLAG/STATUS), then you
have to shift it by 13 positions (SRL R0,13) if you want it on the 0-7
range.

Sorry about the mess!

Paolo Bagnaresi

----- Original Message ----- 
From: "Paolo Bagnaresi" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 09, 2011 5:49 PM
Subject: Re: [TI994A] Re: Disk DSR Error Code

> According to the E/A manual page 298-299, DSR Error code 8 simply does
> not exist. Did you perform the standard SRL R0,13 before inspecting the
> usually people prefer to have those three bits aligned on the right of
> R0 LSByte, thus the SRL R0,13.
>
> taken after the DSRLNK (which is the same as saying that an alternate
> JNE OK is not taken). If no DRS error happened, R0 of your workspace
> will just contain whatever was in it before calling the DSRLNK.
>
> Paolo
>

---

From: Insane Multitasker <[email-masked]>
Date: Thu, 10 Feb 2011 11:29:57 -0600

TI changed 'their' mind?   :)  
 
My point, if there is one to be made, is that not every DSRLNK is created
equally.  I have encountered some that follow the convention defined
in the file management specs, which requires one to test both the
status bit and error byte.  Otherwise, I agree you are correct within the
confines of the EA manual and its DSRLNK specs.  ;)-

> From: [email-masked]
> Date: Thu, 10 Feb 2011 06:51:39 +0100