Jump to content

Photo

DSRLINK Code Tutorial


88 replies to this topic

#76 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Mar 17, 2018 12:29 PM

Code has been Compiled!

 

So the basic concepts are in place.  I actually made a Forth program file  for testing with BASIC. :-)

100 CALL CLEAR
110 PRINT "Create a Forth"
120 PRINT "Program with BASIC"
130 OPEN #1:"DSK1.HELLO",OUTPUT,VARIABLE 128
140 PRINT "  :-) "
150 PRINT
160 PRINT "Writing file..."
170 PRINT #1:"\ generated with TI BASIC"
180 PRINT #1:" "
190 PRINT #1:": HELLO"
200 PRINT #1:"  CR ";CHR$(46);CHR$(34);" Hello CAMEL99 Forth!";CHR$(34)
210 PRINT #1:";"
220 PRINT "Closing file..."
230 CLOSE #1
240 END

Then after killing a few bugs... ok a lot of bugs I was able do what's on the screen capture.

 

The next challenge is to see if I can shoe-horn enough file support into the kernel to allow the 8K image to load up stuff when it boots.

 

 

 

Attached Files



#77 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Mar 17, 2018 3:21 PM

Extendable Kernel in 8168 bytes.

 

How does one convert Text files to TI-FILES?

 

 

Attached Files



#78 mizapf ONLINE  

mizapf

    River Patroller

  • 3,069 posts
  • Location:Germany

Posted Sat Mar 17, 2018 4:49 PM

TIImageTool: Edit->Import files (filter: all files), import mode: DIS/VAR 80, then right-click on the new file, Save as TIFILES, or drag it out, drop into a file explorer.



#79 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sun Mar 18, 2018 7:35 PM

TIImageTool: Edit->Import files (filter: all files), import mode: DIS/VAR 80, then right-click on the new file, Save as TIFILES, or drag it out, drop into a file explorer.

 

Thanks Mizapf.  That's a very nice tool.  



#80 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Tue Mar 20, 2018 8:25 PM

What I learned about calling a DSR.

 

For the uber-gurus (German/Sanskrit... interesting)  :) all of this will be old news but I am happy I went through the process.

So for all those crazy people who might want to write a DSR interface system in some other language here goes.

 

First of all here is all the assembly language that I use to call the system ROMS. I use a DSR workspace but all it does is allow to me to get back to my Forth workspace. So it wastes 13 of the registers but it's a very convenient way to switch out the Forth workspace and get back.

( I could move the top of the workspace into Console ROM space and keep the bottom 3 registers in RAM I think, but I have not tried it yet)

\ This is the only code used to CALL the DSR ROM code
CODE: CALLDSR ( -- )     \ *called with Forth word BLWP
             83E0 LWPI,             \ change to GPL workspace
            *R9 BL,                 \ GPL R9 already has the entry address
             0BF0 DATA,             \ This normally has DATA 8 in it. :-)
             DSRWKSP LWPI,          \ back to the dummy workspace
             RTWP,                  \ Return to Forth
             NEXT,
END-CODE

I made decisions that others might frown upon but I did it anyway.

 

1. I know where there disk card is in CRU space and I don't want to access any other system calls with this code so I use the address >1100 as a constant.

2. I know that card has an ID byte at the beginning >4000 so that is a constant called 'ID (Forth speak: the address of ID)

3. I know the link list of DSR names & routines is starts at address 4800  >4008  so that is a constant called 'DSRLIST. ( ​* Master Lee found my typo.  I am gonna get a 'C' on this paper I bet)

 

You need a way to create a TMS9900 vector.

(Assembler equivalent:   DISKLINK    DATA DSRWKSP,CALLDSR 

And you need to be able to BLWP to that vector.  I created a new Forth word in ALC for this. It was just 2 instructions so no biggy. 

 

You need a way to cut a string like: "DSK1.MYFILE"  into  "DSK1" which is the device name.

 

You need a way to search the linked list of Device names in the ROM, searching for the string you cut above.

My code called DSRFIND takes the full filename and extracts the device name into a temp string variable.

It searches via the links until it finds the device or hits the zero at the end of the list.

I found it easier to just return the link address (in the ROM) at the end of the search.  I convert that link to the code address later.

If the device is not found DSRFIND returns zero.

 

Card Control

You need to have basic CRU control.  CAMEL99 Forth has CRU! that puts a value into R12 and CRU@ which reads R12.

And 0SBO  and 0SBZ which do one ALC instruction each. ( SBO 0  and SBZ 0 )

 

With CRU control you need smart Card control word that checks if R12 has and address in it and if so turn if off, then change the address and turn on the new address. I called that ENABLE.  DISABLE simply loads R12 and turns off that address.  

 

*MAGIC*

When you enable the Disk controller card you need to store that CRU address in >83D0 also. I don't know why.

Edit: Not needed. This is seems to be a variable used by the console DSR. Your DSR can use it as such, but does not need to.

 

*MORE MAGIC*

I will use some Forth code to help me remember/ explain what happens next.

: NEWFILE ( $addr len -- ) 
         2DUP MAKEPAB   ( -- $addr len realpab)
         -ROT            ( -- realpab $addr len )
         DiskON ?CARDID                           
         DSRFIND         ( -- realpab link)
         DUP ?DEVERR     \ ABORT if link=0
         DUP 4 +         ( -- link $)   \ link+4=DSR$ ie: the name of the DSR
             C@ 8355 C!                 \ len(DSR$) -> hex8355
                         ( -- link)
         >ENTRY  83E0 9 REG# !          \  DSR code entry into GPL.R9
        ( -- realpab ) 8356 !           \ the "REAL" PAB file name stored here
;

1. MAKEPAB creates a PAB in VDP memory with the full string (DSK1.MYFILE), the file mode byte, the buffer address, and the record size

BUT... it also does something *magic*.

 

You must get the address in your newly created VDP PAB at the dot character in the full filename.

So remember this is the VDP address of the dot character in the filename field of the PAB.

Put that somewhere safe in your chosen language you will need it shortly. I call it the "realpab"

 

2. Turn on the Disk card at  CRU >1100 .  Check the Card ID >AA  is now present at address >4000

 

3. Run DSRFIND to find your DEV string that you extracted

 

4. Test your result: If it's zero error out. (my code just aborts to Forth console with a message)

   If you found a good link,  add 4 to it, that's the address of the string in the ROM.

   Read a byte at that address and store the byte in >8355.  ( It's length of the device string in ROM).

 

 5. Take the LINK you found and increment by 2 to get to the code-address field. 

     Read the contents of that field and you have code-entry-address (runnable code)

     Stuff that code-entry-address into R9 of the GPL workspace. (you can only do that in the 9900 family)  :-D

    

6.  Remember that "realpab"?  Put that address into memory at >8356.

 

Wasn't that fun?  Not my idea of a nice API to a file system.  :_(

 

The FINAL CALL

 

I call this FILEOP and it does the following:

  1. Put the file operation byte into PAB[0]
  2. Fetch the flag at PAB[1], mask off the upper 3 bits and put it back to clear err bits.
  3. Clear the GPL status byte 
  4. Turn the disk (which must copy the CRU address to >83DO (REMEMBER?)
  5. BLWP to the VECTOR
  6. Read the error byte at PAB[1] , (shift 5 bits to the right to see them correctly)
  7. Read the GPL byte and check for errors
  8. Turn the disk card off
: FILEOP  ( c -- n)
          PAB VC!                  \ write opcode byte to VDP PAB
          PAB_FLG@ 1F AND PAB_FLG! \ clear err code bits
          0 GPLSTAT C!             \ clear GPL status register
          DiskON
          DSKLNK BLWP ERR@
          DiskOFF  ;

What a weird OS. But we love it   Is that a problem...?  :twisted:


Edited by TheBF, Sun Apr 1, 2018 7:32 AM.


#81 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Wed Mar 21, 2018 7:21 AM

Very nice!  :)  See my comments in this color interspersed in your post below:

 

What I learned about calling a DSR.

 

For the uber-gurus (German/Sanskit... interesting)  :) all of this will be old news but I am happy I went through the process.

So for all those crazy people who might want to write a DSR interface system in some other language here goes.

 

First of all here is all the assembly language that I use to call the system ROMS. I use a DSR workspace but all it does is allow to me to get back to my Forth workspace. So it wastes 13 of the registers but it's a very convenient way to switch out the Forth workspace and get back.

( I could move the top of the workspace into Console ROM space and keep the bottom 3 registers in RAM I think, but I have not tried it yet)  [LES note:  Well, that would mean the 6 bytes for R13 – R15 would be in slow RAM at >2000.  If truly no other register but the last 3 is used, you could use a faster, 6-byte block of available space in scratchpad RAM, offset at least 26 bytes from >8300]

       <snip>

3. I know the link list of DSR names & routines is starts at address 4800 so that is a constant called 'DSRLIST.  [LES note:  The linked list of DSRs starts at >4008.]

        <snip>

*MAGIC*

When you enable the Disk controller card you need to store that CRU address in >83D0 also. I don't know why.  [LES note:  The E/A Manual, on p. 406, says of >83D0, “Search pointers for GROM and ROM search. Four bytes.”]

        <snip>

What a weird OS. But we love it   Is that a problem...?  :twisted:

 

...lee



#82 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Mar 21, 2018 7:39 AM

Thanks for the review Lee. I will correct the >4800 typo in my post.

That E/A manual is full of good stuff. I will have to pay more attention. (not my strong suit) 

 

I might look around the scratchpad for a place to put those 6 bytes, but it's kind of crowed in there and my DSRWKSP is really a flow through to GPL workspace.

Compared to the hit we take running the thread interpreter it probably would not speed things up very much.

 

I tested calling the OPEN opcode and dropping the error message and it takes about 14mS in this current iteration. So not too bad.

And if you are waiting for the FLOPPY drives to wake up it's going to be a lot more. :-)

 

Thanks again for checking over the details.  

 

B


Edited by TheBF, Wed Mar 21, 2018 7:45 AM.


#83 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Wed Mar 21, 2018 10:27 AM

Thanks for the review Lee. I will correct the >4800 typo in my post.

That E/A manual is full of good stuff. I will have to pay more attention. (not my strong suit) 

 

I might look around the scratchpad for a place to put those 6 bytes, but it's kind of crowed in there and my DSRWKSP is really a flow through to GPL workspace.

Compared to the hit we take running the thread interpreter it probably would not speed things up very much.

 

I tested calling the OPEN opcode and dropping the error message and it takes about 14mS in this current iteration. So not too bad.

And if you are waiting for the FLOPPY drives to wake up it's going to be a lot more. :-)

 

Thanks again for checking over the details.  

 

B

 

No prob.  :)

 

Re where you place your workspace.  Again, if it truly does not use any of the first 26 bytes of the workspace and you do not care about using RAM on the 8-bit bus, why not do something like the following:

VARIABLE MYWS_R13R15 4 ALLOT
MYWS_R13R15 26 - CONSTANT MYWS 

or, however you would do that in CAMEL99 Forth.

 

Or—even better:

HERE 6 ALLOT
26 - CONSTANT MYWS

...lee



#84 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Mar 21, 2018 12:47 PM

HERE 6 ALLOT
26 - CONSTANT MYWS

I like this idea. Very clever. 

I am working on getting a file handle system right now so this is an optimization I can come back to.

On another note I discovered I have been running my return stack on non-aligned address boundaries. 

Not sure if it made a difference but it feels better to know it's on even boundaries now.



#85 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sun Apr 1, 2018 7:27 AM

Very nice!  :)  See my comments in this color interspersed in your post below:

*MAGIC*

When you enable the Disk controller card you need to store that CRU address in >83D0 also. I don't know why.  

[LES note:  The E/A Manual, on p. 406, says of >83D0, “Search pointers for GROM and ROM search. Four bytes.”]

        <snip>

 

 

...lee

 

So being the crazy man I am I wondered, "Do I really need to put the CRU address into >83D0 or is that what the TI-99 DSR code needs?"

 

So I commented out the place where I do the deed and guess what?  It still works!  

So one more magic incantation has been removed.

: DiskON  ( -- ) DSKCARD ( DUP 83D0 !) Enable ;  \ 99-4A needs CRU copied to 83D0 (magic)


#86 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Sun Apr 1, 2018 1:22 PM

 

 

So being the crazy man I am I wondered, "Do I really need to put the CRU address into >83D0 or is that what the TI-99 DSR code needs?"

 

So I commented out the place where I do the deed and guess what?  It still works!  

So one more magic incantation has been removed.

: DiskON  ( -- ) DSKCARD ( DUP 83D0 !) Enable ;  \ 99-4A needs CRU copied to 83D0 (magic)

 

I would be willing to bet that the GPL DSRLNK needs them, which would mean fbForth needs them because I am using the GPL DSRLNK.



#87 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,959 posts

Posted Sun Apr 1, 2018 6:24 PM

For more information re: 83D0 and 83D2, see "Interface Standard & Design Guide" by Tony Lewis, section J: DSR Access.

 

I recall scanning and uploading a copy to AtariAge once upon a time, though it doesn't seem to be attached to the pinned development resources thread. There were a few pages missing so there should be a second and/or corrected upload.  I was not able to locate the file,  maybe someone else will have better luck.  (edit: attached a copy for reference)

 

Anyway, the entire guide is a "must read" for DSR and peripheral design.  It explains and ties together many of the earlier written TI specifications.

Attached Files


Edited by InsaneMultitasker, Sun Apr 1, 2018 6:34 PM.


#88 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sun Apr 1, 2018 8:02 PM

For more information re: 83D0 and 83D2, see "Interface Standard & Design Guide" by Tony Lewis, section J: DSR Access.

 

I recall scanning and uploading a copy to AtariAge once upon a time, though it doesn't seem to be attached to the pinned development resources thread. There were a few pages missing so there should be a second and/or corrected upload.  I was not able to locate the file,  maybe someone else will have better luck.  (edit: attached a copy for reference)

 

Anyway, the entire guide is a "must read" for DSR and peripheral design.  It explains and ties together many of the earlier written TI specifications.

 

 

Ah... yes from this it is quite clear that these addresses are for the internal DSRLNK.  Therefore I don't need them in my code because I don't use the console ROM.



#89 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,591 posts
  • Location:Germany

Posted Mon Apr 2, 2018 12:30 PM

For more information re: 83D0 and 83D2, see "Interface Standard & Design Guide" by Tony Lewis, section J: DSR Access.

 

I recall scanning and uploading a copy to AtariAge once upon a time, though it doesn't seem to be attached to the pinned development resources thread. There were a few pages missing so there should be a second and/or corrected upload.  I was not able to locate the file,  maybe someone else will have better luck.  (edit: attached a copy for reference)

 

Anyway, the entire guide is a "must read" for DSR and peripheral design.  It explains and ties together many of the earlier written TI specifications.

 

 

Thank you for uploading! Fascinating stuff. Anyone know if the accompanied disk is available somewhere?
 

The document says "a 5-14' single sided, single density diskette containing utility programs is provided with the manual to assist the peripheral developer in creating DSRs and application programs. The purpose of including these programs with the manual is to provide in (the author's opinion) the "best" utility programs available to the developer such that DSRs may be quickly written, debugged and released."


Edited by retroclouds, Mon Apr 2, 2018 12:31 PM.





1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users