Subject: DSR-ish questions

From: "Marc H" <[email-masked]>
Date: Wed, 03 Oct 2012 00:11:57 -0000

Hey Folks.

I have been tinkering with file handling on the TI and have a pretty good understanding of how to save/load, PAB's etc (Thanks to Timbo.) it's not nearly as complicated as my earlier fear indicated.  Pretty easy actually (at least at the level I am operating on.)  

I am at the point of trying to understand and perhaps write a DSRLNK program.  I think I have a good understanding as to the function of DSRLNK but am not entirely sure.  If I am missing something would someone please chime in.

The steps the DSRLNK subroutine does (for DSRs anyway) is.

1)  Scan the cards via CRU from >1000 to >1F00 looking for byte >AA @ ROM location >4000.

2)  If >AA is found @>4000 then look at >6008.  If >4000<>AA then go to step 4

3)  Search the linked list pointed to by >4008 for a device name that matches the device you are looking for.  If you find it then BL to the address of that list element.  

4)  Add >100 to the CRU.  If CRU<2000 then go to step 1)  Otherwise return with an error condition

Questions......(provided I got that somewhat correct.)

I assume that DSRLNK does the searching and matching of device names in other words there are no provisions in DSR's to search and execute the linked list ??? 

I would guess that DSRLNK is responsible for reporting errors of a "device not found" nature  while the DSR's return operation errors (reported in the PAB.)

I also am led to believe that although the operations may be nearly identical,  items such as DSK1 and DSK2 both have a unique identity in the linked list.  The DSR doesn't do any cutting and pasting ?  IE if I am looking for DSK2 I need to find an entry that is "DSK2"

Lastly....  as an example.  Is DSK1 listed as "DSK1" or "DSK1."

Is this even close ?

Thanks.

Hull

PS...  If anyone feels up to it could the splain the differences in TI vs Geneve DSRLNK's?  Just an overview please ;-).

---

From: Jeff White <[email-masked]>
Date: Tue, 2 Oct 2012 23:29:37 -0400

My answers entwined.

> I assume that DSRLNK does the searching and matching of device names in other words there are no provisions in DSR's to search and execute the linked list ??? 
Correct.

> I would guess that DSRLNK is responsible for reporting errors of a "device not found" nature while the DSR's return operation errors (reported in the PAB.)

Yes.  But be wary of DSK-controllers.  Multiple cards may have DSK-devices (or other, but less likely).

> Lastly.... as an example. Is DSK1 listed as "DSK1" or "DSK1."

Device names do not include the full stop (period).  DSR's may have DSK, DSK1, etc. as devices. 
> 
> Thanks.
> 
> Hull
> 
> PS... If anyone feels up to it could the splain the differences in TI vs Geneve DSRLNK's? Just an overview please ;-).___
> 

GPL or native mode?

Jeff White

---

From: Tony Knerr <[email-masked]>
Date: Wed, 03 Oct 2012 05:17:11 -0400

It may be helpful to look at (maybe use?) an already written DSRLNK.
The one by Miller/Warren is quite good.

Other than that I would suggest starting the CRU scan at >1100,
incrementing by >100 until >1F00, and then checking >1000.
A ramdisk set to >1000 may cause you to miss the intended floppy
disk you are looking for.

Tony

On 10/2/2012 8:11 PM, Marc H wrote:
>
> Hey Folks.
>
> I have been tinkering with file handling on the TI and have a pretty 
> good understanding of how to save/load, PAB's etc (Thanks to Timbo.) 
> it's not nearly as complicated as my earlier fear indicated. Pretty 
> easy actually (at least at the level I am operating on.)
>
> I am at the point of trying to understand and perhaps write a DSRLNK 
> program. I think I have a good understanding as to the function of 
> DSRLNK but am not entirely sure. If I am missing something would 
> someone please chime in.
>
> 3) Search the linked list pointed to by >4008 for a device name that 
> matches the device you are looking for. If you find it then BL to the 
> address of that list element.
>
> I assume that DSRLNK does the searching and matching of device names 
> in other words there are no provisions in DSR's to search and execute 
> the linked list ???
>
> I would guess that DSRLNK is responsible for reporting errors of a 
> "device not found" nature while the DSR's return operation errors 
> (reported in the PAB.)
>
> I also am led to believe that although the operations may be nearly 
> identical, items such as DSK1 and DSK2 both have a unique identity in 
> the linked list. The DSR doesn't do any cutting and pasting ? IE if I 
> am looking for DSK2 I need to find an entry that is "DSK2"
>
> PS... If anyone feels up to it could the splain the differences in TI 
> vs Geneve DSRLNK's? Just an overview please ;-).
>
> _

---

From: Marc Hull <[email-masked]>
Date: Wed, 3 Oct 2012 12:01:39 -0700 (PDT)

Well I got where I am at via a routine Tim sent me.  It's pretty slick.  In fact too slick for me to wrap my head around.  It "appears" to do a little parameter passing through the various WS's it uses and it has proven difficult to trace at certain junctions.  

I am attempting to dumb it down a bit (losing flexibility I understand but aiding in understanding.)  The dumbing down is for my benefit.  I seem to be behind the curve here ;-).

Your RAM Disk suggestion puzzles me.  Unless you had more than one DSK1 (or 2 or 3 or 4 etc.)  What could happen ?

--- On Wed, 10/3/12, Tony Knerr <[email-masked]> wrote:

From: Tony Knerr <[email-masked]>
Subject: Re: [TI994A] DSR-ish questions
To: [email-masked]
Date: Wednesday, October 3, 2012, 4:17 AM

  

      

    It may be helpful to look at (maybe
      use?) an already written DSRLNK.

      incrementing by >100 until >1F00, and then checking
      >1000.

      A ramdisk set to >1000 may cause you to miss the intended
      floppy

      Tony

    

            Hey Folks.

              I have been tinkering with file handling on the TI and
              have a pretty good understanding of how to save/load,
              PAB's etc (Thanks to Timbo.) it's not nearly as
              complicated as my earlier fear indicated. Pretty easy
              actually (at least at the level I am operating on.) 

              I am at the point of trying to understand and perhaps
              write a DSRLNK program. I think I have a good
              understanding as to the function of DSRLNK but am not
              entirely sure. If I am missing something would someone
              please chime in.

              1) Scan the cards via CRU from >1000 to >1F00
              looking for byte >AA @ ROM location >4000.

              2) If >AA is found @>4000 then look at >6008. If
              >4000<>AA then go to step 4

              3) Search the linked list pointed to by >4008 for a
              device name that matches the device you are looking for.
              If you find it then BL to the address of that list
              element. 

              4) Add >100 to the CRU. If CRU<2000 then go to step
              1) Otherwise return with an error condition

              I assume that DSRLNK does the searching and matching of
              device names in other words there are no provisions in
              DSR's to search and execute the linked list ??? 

              I would guess that DSRLNK is responsible for reporting
              errors of a "device not found" nature while the DSR's
              return operation errors (reported in the PAB.)

              I also am led to believe that although the operations may
              be nearly identical, items such as DSK1 and DSK2 both have
              a unique identity in the linked list. The DSR doesn't do
              any cutting and pasting ? IE if I am looking for DSK2 I
              need to find an entry that is "DSK2"

              Lastly.... as an example. Is DSK1 listed as "DSK1" or
              "DSK1."

              Is this even close ?

              Thanks.

              Hull

              PS... If anyone feels up to it could the splain the
              differences in TI vs Geneve DSRLNK's? Just an overview
              please ;-).

          _

---

From: Marc Hull <[email-masked]>
Date: Wed, 3 Oct 2012 12:02:37 -0700 (PDT)

Native as I imagine GPL mode is more or less like TI mode.  Thanks for the clarifications.

--- On Tue, 10/2/12, Jeff White <[email-masked]> wrote:

From: Jeff White <[email-masked]>
Subject: Re: [TI994A] DSR-ish questions
To: "[email-masked]" <[email-masked]>
Date: Tuesday, October 2, 2012, 10:29 PM

  

      My answers entwined.

 

      Hey Folks.

Is this even close ?

Thanks.

Hull

---

From: Tony Knerr <[email-masked]>
Date: Wed, 03 Oct 2012 17:41:57 -0400

I don't remember the issue exactly. I'm not even sure of what type of 
ramdisk presented the problem, might be Myarc?
It's something like the ramdisk throws an error if scanned before the 
floppy. I think the discussion was in the dash group
some years back, you may want to look there if it's still possible to 
read the old messages. Perhaps someone else can
shed some light on the exact nature of the problem.

Anyway, I've always used that method of CRU scanning to avoid any issues 
others may have. And it doesn't seem to
hurt anything. :-)

Tony

On 10/3/2012 3:01 PM, Marc Hull wrote:
>
> Well I got where I am at via a routine Tim sent me.  It's pretty 
> slick.  In fact too slick for me to wrap my head around.  It "appears" 
> to do a little parameter passing through the various WS's it uses and 
> it has proven difficult to trace at certain junctions.
>
> I am attempting to dumb it down a bit (losing flexibility I understand 
> but aiding in understanding.)  The dumbing down is for my benefit.  I 
> seem to be behind the curve here ;-).
>
>
> Your RAM Disk suggestion puzzles me.  Unless you had more than one 
> DSK1 (or 2 or 3 or 4 etc.)  What could happen ?
>
> --- On *Wed, 10/3/12, Tony Knerr /<[email-masked]>/* wrote:
>
>

---

From: Jeff White <[email-masked]>
Date: Thu, 4 Oct 2012 09:22:25 -0400

Thierry's site explains some bugs in the TI FDC, normally located at CRU>1100.  DSK.diskname, >10, and >11 routines will stop the DSR scan with an error unless the device is found on the FDC.  This means, it must find something on one of up to 3 attached drives.  DSK.TIMP or DSK5 on a RAMdisk must be found before CRU>1100.

To work around these issues, putting >1100 at the end of a DSRLNK scan works, as long as all the other cards behave.

Whether similar bugs are in the DSR's of Corcomp, Myarc, etc. disk controllers, I do not know.

Jeff White

On 03 Oct 2012, at 17:41, Tony Knerr <[email-masked]> wrote:

> I don't remember the issue exactly. I'm not even sure of what type of ramdisk presented the problem, might be Myarc? 
> It's something like the ramdisk throws an error if scanned before the floppy. I think the discussion was in the dash group
> some years back, you may want to look there if it's still possible to read the old messages. Perhaps someone else can
> Anyway, I've always used that method of CRU scanning to avoid any issues others may have. And it doesn't seem to 
> hurt anything. :-) 
> 
> Tony
> 
> 

<snip>

---

From: Tony Knerr <[email-masked]>
Date: Thu, 04 Oct 2012 17:16:18 -0400

I'd have to test the other conditions, but the TI FDC will pass the 
"DSK5" search without an error.  Only drives 1 through 3 and the
DSK.diskname error out.

Tony

On 10/4/2012 9:22 AM, Jeff White wrote:
> Thierry's site explains some bugs in the TI FDC, normally located at 
> CRU>1100.  DSK.diskname, >10, and >11 routines will stop the DSR scan 
> with an error unless the device is found on the FDC.  This means, it 
> must find something on one of up to 3 attached drives.  DSK.TIMP or 
> DSK5 on a RAMdisk must be found before CRU>1100.
>
> To work around these issues, putting >1100 at the end of a DSRLNK scan 
> works, as long as all the other cards behave.
>

---

From: "Tursi" <[email-masked]>
Date: Thu, 4 Oct 2012 14:34:57 -0700

Yeah, the TI DSR will throw an error if the DSR name matches one of its 
entries but the rest of the operation fails.

The main time that's an issue is when you use the "DSK.DISKNAME.FILENAME" 
syntax, since if the disk controller doesn't find the disk, it returns an 
error instead of letting the DSRLNK pass through to the next card.

I had thought that was fixed in the RAMdisk DSR, which means that it was 
only an issue if your RAMdisk (or alternate disk controller) came /after/ 
the disk controller. That is, a RAMdisk at >1000 was okay, but to deal with 
RAMdisks at CRU bases greater than >1100 the recommendation I saw was to 
start your search at >1200 and do the Disk controller at >1100 last.

-----Original Message----- 
From: Tony Knerr
Sent: Thursday, October 04, 2012 2:16 PM
To: [email-masked]
Subject: Re: [TI994A] DSR-ish questions

I'd have to test the other conditions, but the TI FDC will pass the "DSK5" 
search without an error.  Only drives 1 through 3 and the DSK.diskname error 
out.

Tony

Thierry's site explains some bugs in the TI FDC, normally located at 
CRU>1100.  DSK.diskname, >10, and >11 routines will stop the DSR scan with 
an error unless the device is found on the FDC.  This means, it must find 
something on one of up to 3 attached drives.  DSK.TIMP or DSK5 on a RAMdisk 
must be found before CRU>1100.

Whether similar bugs are in the DSR's of Corcomp, Myarc, etc. disk 
controllers, I do not know.

Jeff White

---

From: Tony Knerr <[email-masked]>
Date: Thu, 04 Oct 2012 18:22:25 -0400

Yes, that makes more sense than what I originally posted (so I was >100 
off, what's a few bytes among friends ;-) ).

So Marc, start the CRU search at >1200, after you get to >1900 check 
 >1000 and then finally >1100.
Make sense now?

Tony

---

From: Jeff White <[email-masked]>
Date: Thu, 4 Oct 2012 20:19:47 -0400

I meant to say that using routines >10 and >11 for devices other than 1-3 will error out at the TI FDC.  Never hit this wall myself -- knowledge is gleaned from others.

Jeff White

On 04 Oct 2012, at 17:16, Tony Knerr <[email-masked]> wrote:

> I'd have to test the other conditions, but the TI FDC will pass the "DSK5" search without an error.  Only drives 1 through 3 and the
> DSK.diskname error out.
> 
> Tony
>

---

From: Insane Multitasker <[email-masked]>
Date: Thu, 4 Oct 2012 23:37:15 -0500

I seem to recall that the dsrlnk paolo and others updated was well-documented.  It or another similarly documented routine may be what you are looking for?

To: [email-masked]
From: [email-masked]
Date: Wed, 3 Oct 2012 12:02:37 -0700
Subject: Re: [TI994A] DSR-ish questions

 

      
My answers entwined.

 

      Hey Folks.

Correct.

Is this even close ?

Thanks.

Hull

GPL or native mode?
Jeff White

---

From: Marc Hull <[email-masked]>
Date: Sun, 7 Oct 2012 13:23:40 -0700 (PDT)

Your right.  But expecting me to take the enlightened more logical way ?  Tim....  have you ever even met me ? ;-)....  Back to pounding my head against the wall.  I think somethings starting to crack.  Not sure what but definitely something ;-)...

--- On Thu, 10/4/12, Insane Multitasker <[email-masked]> wrote:

From: Insane Multitasker <[email-masked]>
Subject: RE: [TI994A] DSR-ish questions
To: [email-masked]
Date: Thursday, October 4, 2012, 11:37 PM

  

      

        

 

      
My answers entwined.

 

      Hey Folks.

Correct.

Is this even close ?

Thanks.

Hull

GPL or native mode?
Jeff White

---

From: Insane Multitasker <[email-masked]>
Date: Mon, 8 Oct 2012 13:44:09 -0500

I've got some big rocks in the yard that need to be pulverized. Drive on down for a spell!  I'll print out some DSR code on each rock that needs to be cracked...
 
;)

To: [email-masked]
From: [email-masked]
Date: Sun, 7 Oct 2012 13:23:40 -0700
Subject: RE: [TI994A] DSR-ish questions

  

  

My answers entwined.

  
Hey Folks.

Correct.

Is this even close ?

Thanks.

Hull

GPL or native mode?

Jeff White