Jump to content

Photo

DSRLINK Code Tutorial


137 replies to this topic

#126 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Oct 10, 2018 6:38 AM

I replicated your video to double check if it was the repository code's problem.

It failed just like your video on the new Classic99 but ran on the older version.

 

I recompiled the same code and commented out 1 line that compiles the "start" file.  Sent it over to TI-99 and voila!.

It cleared the screen, put up the title  and yes it Beeps on startup 

 

You may be more rigorous with something on Classic99 now than the original hardware.

Something that my home made cross-compiler doesn't respect. (?)

 

I know Speccery loaded and ran an early version on his FPGA version as well. Don't know the particulars there.


Edited by TheBF, Wed Oct 10, 2018 7:27 AM.


#127 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Oct 13, 2018 9:52 AM

Still no luck -- maybe you are squeaking by on your older version of Classic99, or maybe I'm doing something wrong, but I can't even get it to start, it doesn't make it to the first disk access. Have a look here and tell me what to try differently:

 

 

 

Hi Tursi,  I found one piece of the puzzle.

 

So the reason that my Forth won't run on the new CLASSIC99 is because of the following code.

It puts the timer in continuous running mode with TMR! which seems to run fine.

BUT I grab a number with TMR@  and then grab another number later to test the run time of short Assembler and machine code routines.

 

I also use it to create JIFF delay used for MS delays and that is the word that doesn't work.

\ this code works fine
CODE: TMR!   (  -- )         \ load TMS9901 timer to max value 3FFF
             W 3FFF LI,      \ load scratch register W with MAXIMUM timer value
             R12 CLR,        \ CRU addr of TMS9901 = 0
             0 LIMI,
             0   SBO,        \ SET bit 0 to 1, Enter timer mode
             R12 INCT,       \ CRU Address of bit 1 = 2 , I'm not kidding
             W 0E LDCR,      \ Load 14 BITs from R1 into timer
             R12  DECT,      \ go back to address 0
             0    SBZ,       \ reset bit 0, Exits clock mode, starts decrementer
             2 LIMI,
             NEXT,           \ 16 bytes
             END-CODE

\ this code does not work on new CLassic99, but works on real hardware.
CODE: TMR@   ( -- n)         \ read the TMS9901 timer
             TOS PUSH,
             R12 CLR,
             0 LIMI,
             0 SBO,          \ SET bit 0 TO 1, ie: Enter timer mode
             TOS 0F STCR,    \ READ TIMER (14 bits plus mode bit) into W
             TOS  1 SRL,     \ Get rid of mode bit
             0 SBZ,          \ SET bit 1 to zero
             2 LIMI,
             NEXT,
             END-CODE
 
 
 CODE: |-| ( x y -- x n )    \ : |-|   OVER - ABS ;
            *SP TOS SUB,
             TOS    ABS,    \ get ABS of subtraction
             NEXT,
             END-CODE
 
\ JIFFS give finest resolution for delays
: JIFFS    ( n -- )
           0 ?DO
                 TMR@
                 BEGIN
                   PAUSE TMR@ |-| 650 >
                 UNTIL
                 DROP
           LOOP ;
 
\ MS resolution limited to 1/60 second and minimum is 1/60 sec.
: MS  ( n -- )  4 RSHIFT  PAUSE JIFFS ;  \ MS/16 = JIFFS

Edited by TheBF, Sat Oct 13, 2018 10:52 AM.


#128 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,289 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Oct 13, 2018 3:41 PM

That's helpful. I've found the version that broke it, and with the above description I can assume it's related to the fixes for CS1. I can't translate your forth code into assembly though, but I'll try just studying the diff...



#129 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,289 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Oct 13, 2018 3:43 PM

Can you detail what "does not work" means? I mean, SOMETHING happens. To fix a problem it needs to be clear what the code is doing that is incorrect, and what it should do. I don't see any reason in the function you called out that the code would /hang/.



#130 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,289 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Oct 13, 2018 4:28 PM

Got it.. thanks for the description. The problem was upon exiting 9901 timer mode, I would reset the timer. But your code was polling the timer, continuously entering and exitting timer mode, so it never counted down. I added the 9901 timer to the debug window and it was immediately clear. Fixed that, and it came up.

 

Going to spend a few minutes on your disk issue now... no promises. Either way I'll do a new release shortly to address this bus.



#131 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Oct 13, 2018 6:03 PM

Sorry, Just saw this. 

The symptom was as you described when you first tried it.

 

On boot, the Beep started , the MS delay word calls the TMR@ code word and it never ended. 

 

I am pretty frustrated with the disk problem. I tried cutting my own path, but clearly there is something I am missing as the DSR in ROM does some pretty strange things once it is entered, writing to VDP registers and such and never exits. 

 

I am looking at a wholesale re-write using other peoples Assembler code. :?



#132 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,289 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Oct 13, 2018 7:06 PM

By symptoms, I meant you said "this code does not work" and showed me code to read the 9901 timer. My question was "how does it not work?" (I do not need the answer any longer - that function DOES work, just the timer was not counting down).

 

I'll note though, that I was not successful with writing my own DSRLNK either, and my own code just uses a ported version of the E/A one. ;)

 

I did get some progress, but I did not get all the way there. I found two absolute things and one maybe - fixing the two absolute things in the debugger let the 'open' call succeed, at least.

 

-interrupts must be off
 
Classic99's DSR does not suffer from this issue because Classic99's DSR takes zero time from the 9900's point of view - imagine the 9900 is halted while the DSR executes. Thus, an interrupt can't interrupt it.
 
-CRU Of the disk controller must be stored at >83F8 (ie: >1100)
 
There is no "not found" handling in the disk DSR - if the CRU can't be matched, it just searches VDP until it's happy. Since R12 was 0, it was not too hard to find a match and then make all kinds of bad assumptions about the memory space it found.
 
-DSR is not turned off after the call
 
... I think. It seems to jump back into the interpreter which is a bit hard to trace with just the disassembly. This can cause problems with the next DSRLNK which will try to enable cards without turning the previous one off.
 
-Code ends up jumping to >8300 where it hits invalid instructions - comes from >B8B2 (BL *R9, R9 is >8300)
 
So I was not sure what was going on at this point...


#133 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Oct 13, 2018 7:16 PM

 

By symptoms, I meant you said "this code does not work" and showed me code to read the 9901 timer. My question was "how does it not work?" (I do not need the answer any longer - that function DOES work, just the timer was not counting down).

 

I'll note though, that I was not successful with writing my own DSRLNK either, and my own code just uses a ported version of the E/A one. ;)

 

I did get some progress, but I did not get all the way there. I found two absolute things and one maybe - fixing the two absolute things in the debugger let the 'open' call succeed, at least.

 

-interrupts must be off
 
Classic99's DSR does not suffer from this issue because Classic99's DSR takes zero time from the 9900's point of view - imagine the 9900 is halted while the DSR executes. Thus, an interrupt can't interrupt it.
 
-CRU Of the disk controller must be stored at >83F8 (ie: >1100)
 
There is no "not found" handling in the disk DSR - if the CRU can't be matched, it just searches VDP until it's happy. Since R12 was 0, it was not too hard to find a match and then make all kinds of bad assumptions about the memory space it found.
 
-DSR is not turned off after the call
 
... I think. It seems to jump back into the interpreter which is a bit hard to trace with just the disassembly. This can cause problems with the next DSRLNK which will try to enable cards without turning the previous one off.
 
-Code ends up jumping to >8300 where it hits invalid instructions - comes from >B8B2 (BL *R9, R9 is >8300)
 
So I was not sure what was going on at this point...

 

 

Cool!  That's great sleuthing.  I will implement those changes and try and feel my way along from there.

 

This has got to be the most convoluted Disk "API" ever invented. :-)

 

Thanks!!!



#134 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,289 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Oct 13, 2018 7:48 PM

I'm not a fan of the TI Disk DSR, but people keep insisting we use it as a standard. There's no error checking, it makes assumptions about how it was called and expects random variables in scattered RAM locations. It's a pure classic case of "everything is perfect" programming. The only assumption it SHOULD make is that the PAB has a pointer to it. ;)

 

I'm thankful that we aren't expected to be similarly compatible with the RS232 or PIO DSRs... people got lazy and went straight to hardware there.



#135 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Oct 13, 2018 8:18 PM

 

Cool!  That's great sleuthing.  I will implement those changes and try and feel my way along from there.

 

This has got to be the most convoluted Disk "API" ever invented. :-)

 

Thanks!!!

 

I think it works!  :-D   I have a type 3 file, disk image with my boot files on it and it compiled them all on start up!

 

 

I spoke too soon of course.  I have the new Classic99 version INI file set to type 3. :-)

But I have a direction now so it's all much better. 

 

Your ideas were the same as Lee suggested with the exception that I was turning the card on in the Forth workspace, so I never set GPL R12 to the disk card address.

And I didn't turn the card off inside the GPL workspace either so it kept running.

 

So my method removes all the messy stuff of creating and manipulating the PAB data to Forth. I also scan the link list of devices in Forth and record the relevant data.

I don't search the entire list of devices because I know I only want disk card access at this time.

 

Here is what the code looks like now with your changes in CROSS-COMPILED Forth Assembler

There is a stub for and PANIC error handler but I will make that something meaningful.

 

Now I need to change it so I  use the DSRWKSP to hold the parameters that I find in forth and then the GPL workspace can grab them from there.

\               workspace    compile program address
\               ---------    -----------------------
CREATE: DSKLNK  DSRWKSP T,  [cc] THERE TCELL + T, [tc]
             0 LIMI,
             837C @@ CLR,     \ clr GPL status flag
             83E0 LWPI,       \ change to GPL workspace
             R12 DSKCARD LI,  \ card address -> GPL R12
             RCODE @@ R9 MOV, \ RCODE has the ROM entry address
             0 SBO,           \ turn on the card
            *R9 BL,           \ branch to ROM code
             @@1 JMP,         \ on error DSR returns here

             0 SBZ,           \ on success turn off card
             DSRWKSP LWPI,    \ return to DSRWKSP
             2 LIMI,
             RTWP,            \ Return to Forth Workspace
             NEXT,            \ run the Forth interpreter

@@1:         0 SBZ,           \ TROUBLE! turn off card
             DSRWKSP LWPI,    \ to DSRWKSPACE
             BEGIN,
                 R0 INC,      \ shows in the debugger
             AGAIN,   \ loop forever halts program


Edited by TheBF, Sat Oct 13, 2018 8:50 PM.


#136 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Yesterday, 8:50 PM

I was not making much progress with my own DSRLNK on a type 3 drive so I took some time to Code the same version that Vorticon is using in my RPN Forth Assembler. 

That seems to be working somewhat in preliminary testing.

 

Got it to open a file but then it reports that the file is corrupt, but I know it's not because the Editor opens it just fine.

 

Here is what Classic99 is reporting on this one:

DSR opcode >0 on PAB >36C7, filename DSK1.START                                                      
Releasing file buffer 60                                                                            
Recycling unclosed file buffer 60
Opening DSK1.START on drive type FIAD                                                              
PAB requested file type is DV80                                                                    
Allocating file buffer 0                                                                           
Detected C:\Users\Public\Dev\Forth\HSF2000\cc9900\classic99\DSK1\START as a V9T9 file              
Warning: Number Records doesn't match sector length on variable file.                              
Corrupt file - truncating read.
C:\Users\Public\Dev\Forth\HSF2000\cc9900\classic99\DSK1\START read 13 records                        
Restore set record number to 0         

Does anybody want to take a guess as to where I should look for this kind of error.

Have I initialized the PAB wrong?



#137 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,289 posts
  • HarmlessLion
  • Location:BUR

Posted Yesterday, 10:06 PM

The thing you need to remember when you are reading the debug is that there are two sides to the disk emulation.

 

First, the PC side needs to read and parse the file that you have on your PC.

Then, the TI side needs to read and parse the interpreted version of the file that the PC has parsed.

 

What this means is you need to pay attention to the errors. If it says "Corrupt file - truncating read.", it's the /PC/ side that thinks the file is corrupt, not the TI side. The TI side won't see the corruption because the parser simply truncated the corrupt part of the file ("truncating reads") and did not present it to the TI side (so, of course the Editor reads it without error). It's /also/ warning you that the header is invalid - the number of records and the sector length on a variable length file is expected to match, and your file doesn't. It's still doing its best to do something useful with the file, but you can't just say "it's not corrupt". It is. (if you post it, we can tell you why it's corrupt and even repair it). (I should also note that using V9T9 format files on Classic99 is deprecated, and you should switch to TIFILES headers for active development.)

 

However, all this happens on the PC side, which means that it doesn't have anything to do with your DSRLNK implementation. That happens entirely on the TI side.



#138 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Today, 6:51 AM

I will take all that under advisement. It great to have more background on how Classic99 operates.

I did convert the file to TIFILES format on a lark but that didn't help.

 

It's important to note that I had to re-type most of the original DRSLNK file to translate it to my assembler so it's still very probable that I have done something wrong there, but I am still grokking how it does some of the magic to see what is wrong  :-)

 

( i might want to visit a shrink to understand why I have insisted on doing this with homemade tools) :-)

 

I will double check the data file corruption, because I am using a copy of the data file in a different directory, however I am pretty certain I can read this file with other TI programs without that error showing in Classic99.  It was created with the E/A editor. 

 

All that to say, I suspect ME more than my PC,  but your expertise affects my path to the  future.

 

Thanks for weighing in and I can't really thank you enough for making Classic99.  Outstanding hack.






1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users