Jump to content
IGNORED

DSRLINK Code Tutorial


TheBF

Recommended Posts

I do not know that it is the problem, but I think that your reliance on the persistence of GPLWS’s R9 is flawed. I think you should stash it in a safe PAD-RAM location (>83xx) and either copy it to R9 within DSKLNK prior to “BL *R9or use “BL @>83xx” instead. [Edit: Crossed-out stuff will not work!]

 

...lee

Link to comment
Share on other sites

I do not know that it is the problem, but I think that your reliance on the persistence of GPLWS’s R9 is flawed. I think you should stash it in a safe PAD-RAM location (>83xx) and either copy it to R9 within DSKLNK prior to “BL *R9or use “BL @>83xx” instead. [Edit: Crossed-out stuff will not work!]

 

...lee

 

Ahhhh.

 

Very cool.

 

I just tried running with a disk image and some source code on the disk image, Disk1 = TYPE3.

 

No problem. !

 

I will implement your idea after lunch.

 

B

Link to comment
Share on other sites

I made 3 major changes changes: Everthing still works fine in Classic99 with a TYPE 3 DISK1 and disk image.

  1. Use a variable to transport the ROM code entry to GPL R9
  2. Turned off the disk card after calling OPENDEV, which searches for the device in ROM and gets all the relevant numbers
  3. re-wrote ENABLE and DISABLE in ALC and they now disable and enable interrupts respectively.
VARIABLE: ROM  \ holds ROM entry address found by OPENDEV

\ Create the VECTOR that we call with BLWP.
\               workspace    compile program address
\               ---------    -----------------------
 CREATE: DSKLNK  DSRWKSP T,  [cc] THERE TCELL + T, [tc]
            83E0 LWPI,      \ change to GPL workspace
            837C @@ CLR,    \ clear GPL status
            ROM @@ R9 MOV,
           *R9 BL,          \ GPL R9 already has the entry address
            NOP,            \ in case the DSR returns here
            DSRWKSP LWPI,   \ DSR returns here.
            RTWP,           \ Return to Forth Workspace
            NEXT,           \ Return to Forth interpreter
: OPENDEV ( $addr len card -- )  \ turn card on, set DSR
         DUP >R ENABLE
         ?CARDID                     \ abort if card is not 'AA'
         'DSRLIST
         DSRFIND ( -- link)
         DUP ?DEVERR                 \ abort if link=0
         DUP 83D2 !                  \ store link in O/S variable
         DUP 4 +        ( -- link $) \ link+4=DSR$ ie: Name of the DSR in CARD ROM
             C@ 8355 C! ( -- link)   \ length byte of DSRNAM -> 8355
           2+ @ ROM !                \ link+2 contains DSR CODE entry ADDR -> ROM variable
         R> DISABLE
;
CODE: Enable ( CRU -- )
              0 LIMI,
              TOS R12 CMP,
              NE IF,
                   0 SBZ,
              ENDIF,
              TOS R12 MOV,
              TOS 83D0 @@ MOV,
              0 SBO,
              TOS POP,
              NEXT,
              END-CODE

CODE: Disable  ( CRU -- )
               TOS R12 MOV,
               0 SBZ,
               TOS POP,
               2 LIMI,
               NEXT,
               END-CODE

Did some interactive sleuthing at the Forth console and found that I could call OPENDEV with no problem.

When I do an OPEN operation ( 0 FILEOP )

  • The DSKCARD comes on, : That's good
  • The drive motor does not start : somehow the card is not getting the correct drive info?
  • After a second the ok prompt comes back to Forth but the system is locked up. : The BLWP operation is working as expected
  • The disk controller light does not go out fully but is dim, like it's being flashed very rapidly. : Some code is running that should not be?

However when I run the word INCLUDED to try and load a file, the screen goes white.

 

My next steps will be to get all my variables out scratch-pad.

After that take all my code out of scratch-pad as well.

I can't be sure what the ROM code is using in that memory area.

Link to comment
Share on other sites

Please let me know when you find out what it is so I can add a check to the Classic99 DSR.

 

I'm pretty surprised it's that far off when using the type 3 disk though -- are you sure the Classic99 debug log confirms that is doing the right thing? That runs the real TI DSR all the way down to the sector access itself. Maybe you have a misconfiguration? I've used it to actually step through the disk controller ROM before.

Link to comment
Share on other sites

Please let me know when you find out what it is so I can add a check to the Classic99 DSR.

 

I'm pretty surprised it's that far off when using the type 3 disk though -- are you sure the Classic99 debug log confirms that is doing the right thing? That runs the real TI DSR all the way down to the sector access itself. Maybe you have a misconfiguration? I've used it to actually step through the disk controller ROM before.

 

I did not see any errors fly by on the Classic99 debug window. But I will double check every thing as time permits.

Thanks for your interest.

 

I did notice when I single stepped that there was a never time that the code was running in the ROM range. The BLWP occurred and then suddenly it had returned to the expansion memory. I went on to other things, but I will review that again.

 

I don't have the latest version of Classic99. Maybe that's a problem?

Link to comment
Share on other sites

I am probably picking at nits, but it does not seem that you zero >8354 when you store the DSR name-length in >8355. I do not know whether this could be a problem, but all of the DSRLNKs clear the word at >8354 before storing the DSR name-length byte at >8355.

 

...lee

 

At this point I will try anything you suggest.

 

Thanks Lee.

Link to comment
Share on other sites

 

I did not see any errors fly by on the Classic99 debug window. But I will double check every thing as time permits.

Thanks for your interest.

 

I did notice when I single stepped that there was a never time that the code was running in the ROM range. The BLWP occurred and then suddenly it had returned to the expansion memory. I went on to other things, but I will review that again.

 

I don't have the latest version of Classic99. Maybe that's a problem?

 

I'm not talking about errors -- if it doesn't explicitly say that it is using the "TICC" to handle the call, then it's not using the TI Disk Controller ROM. If you change the config from the GUI, it will undo the manual change, since the GUI doesn't know about this (not so) secret hack. You also can only edit Classic99.ini while the emulator is closed. Your description says it's still using the Classic99 DSR (which doesn't have any 9900 code), so for one of those reasons it doesn't seem to have taken. Double check your config and the debug - it will save you some trouble debugging.

Link to comment
Share on other sites

 

I'm not talking about errors -- if it doesn't explicitly say that it is using the "TICC" to handle the call, then it's not using the TI Disk Controller ROM. If you change the config from the GUI, it will undo the manual change, since the GUI doesn't know about this (not so) secret hack. You also can only edit Classic99.ini while the emulator is closed. Your description says it's still using the Classic99 DSR (which doesn't have any 9900 code), so for one of those reasons it doesn't seem to have taken. Double check your config and the debug - it will save you some trouble debugging.

 

Cool. Thanks for that.

 

And indeed the TYPE was set to 2! Ok now I have a better debug platform than rs232 to floppy

 

:)

Edited by TheBF
Link to comment
Share on other sites

I can give you something. Today however I am on the highway (in 10 mins) and up here in the great white north we have Thanksgiving early because when we used to do it on the USA date, years ago, everything here was a frozen wasteland. ;)

So that's this weekend.

 

However if you go to github you can get the current flawed version by taking this folder:

 

https://github.com/bfox9900/CAMEL99-V2/tree/master/DSK1

 

The only files you actually need are listed in the file called START. Just read it with TIDIR and you will see what is "included" on boot.

( I am not on my dev. machine at the moment so I can't read it myself at the moment)

 

As mentioned, it works as a FIAD drive, but failed on my old 99. I have not tested this exact version on a disk image, but it is the one I send over to try on real metal.

 

Gobble gobble.

 

(And we don't pardon any turkeys. I guess we are not as polite as legends suggest) :skull:

 

EDIT:

And I of course discovered that you cannot use .F extensions on TI-99 files. Too many years away from the old beast to remember that.

Edited by TheBF
Link to comment
Share on other sites

I assume you are using a disk image?

 

That's the actual problem if so. With a type 1 drive it should load and then try to compile DSK1.START.

With the disk image it should do what happened to you.

 

In re-reading the DSR doc I see that the system assumes it has 36 bytes at 834E.

I am using some of that so I re-built a version that keeps that area clear, however that did not seem to fix the problem at my end.

 

If you want to try it under better control, I could give you a version of the kernel that doesn't try and load a file at boot time.

If it's too much trouble then I will just continue searching for myself and report back to you.

 

Happy Thanksgiving.

 

(I did suspect there would be many Canadians on here)

Link to comment
Share on other sites

No, I'm using the files you instructed me to download, copied into a folder and mounted as a folder. I need to see it working before I try to troubleshoot the stuff that doesn't. :)

 

That's for sure.

 

Ok let me find out what the heck is up there. I have always just pushed it up but never downloaded back to re-tested.

Link to comment
Share on other sites

No, I'm using the files you instructed me to download, copied into a folder and mounted as a folder. I need to see it working before I try to troubleshoot the stuff that doesn't. :)

 

So I re-worked the kernel so that it now does NOT touch anything in the area of >834E. (Version is 2.1.i) (interim version)

I changed the names in the folder DSK1 so they no longer have a .F extension.

 

Most importantly. so I stop wasting your precious time, I mounted the DSK1 folder that is on GitHub onto Classic99 and booted the kernel which compiled DSK1.START file and the other files it includes.

That part should now be solid for you to see now (apologies for the previous experience)

 

The new START file is this so you need these files in the folder. ( or you can leave some out and see the file error 7 occur)

\ V2.1 START file loads NEEDS/FROM and then loads ANS Forth extensions
 
S" DSK1.NEEDFROM" INCLUDED
 
NEEDS INCLUDE FROM DSK1.INCLUDE
NEEDS CODE    FROM DSK1.CODE
NEEDS ALIAS   FROM DSK1.CELLS
NEEDS CHAR    FROM DSK1.CHAR
CR .(   ok)
 
 
HEX 17 7 VWTR
 

I have incorporated one of LEE's changes which is clearing >8354 when I put the length byte into >8355.

I have reverted back to passing the ROM entry address by directly writing it to GPL R9, and interrupts are running so that is back to the way I started.

 

And I can confirm now that when I run this version as a disk image I get a bunch of this:

Illegal opcode (0000) at address >98A0, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98A4, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98B8, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98BC, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98C0, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98C4, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98C8, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98CC, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98D0, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98D4, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98D8, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98DC, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98E0, Bank >0000, DSR >0001                                      
Illegal opcode (0000) at address >98E4, Bank >0000, DSR >0001                                     
Illegal opcode (0000) at address >98F8, Bank >0000, DSR >0001                                                          
Link to comment
Share on other sites

> ( or you can leave some out and see the file error 7 occur)

 

Do I want to see the file error 7 occur?

 

I know it sounds petty, but what I'd really like is a step by step instruction from nothing to seeing the error I need to troubleshoot.

 

>Illegal opcode (0000) at address >98A0, Bank >0000, DSR >0001

 

I can guarantee you shouldn't be executing code at that address, that's the Speech Synthesizer (IIRC). I'd put a breakpoint there and see how it jumped there.

 

I can try to take a peek tonight after work.

Link to comment
Share on other sites

> ( or you can leave some out and see the file error 7 occur)

 

Do I want to see the file error 7 occur?

 

I know it sounds petty, but what I'd really like is a step by step instruction from nothing to seeing the error I need to troubleshoot.

 

>Illegal opcode (0000) at address >98A0, Bank >0000, DSR >0001

 

I can guarantee you shouldn't be executing code at that address, that's the Speech Synthesizer (IIRC). I'd put a breakpoint there and see how it jumped there.

 

I can try to take a peek tonight after work.

 

Yes that is a glaring problem.

 

Step by step,

1. put the files named in the START file listing in the folder with the CAMEL99 program

2. E/A5 option DSK1.CAMEL99

 

Works in a folder. Fails miserably in a disk image.

I appreciate you even considering it.

 

Thanks

Edited by TheBF
Link to comment
Share on other sites

I don't see anything wrong with what you are doing.

The 2 variables that I can think of are:

1. I have an older Classic99

2. I have not done exactly what you just did.

 

Ball is in my court. Thanks very much for being my Alpha tester.

The cheque is in the mail (CDN $ only) :-)

Link to comment
Share on other sites

And the results are in:

 

My code runs on Q1394 but NOT on Q1399.003

 

It was hours of fun while the illusion lasted! :)

 

I will be looking much closer at working examples of DSRLNK to find the error of my evil Forth ways.

 

Thanks again Tursi and Lee for weighing in.

 

Edit:

...But this begs the question.

I can convert programs from my cross compiler, from V9T9 to TIFILES, then send them over RS232 to my real TI-99 and run them.

Different versions that I built of CAMEL99 Forth worked perfectly as long as I did not try to access files.

Are there differences in Classic99 Q1399.003 and my old TI-99?

Edited by TheBF
Link to comment
Share on other sites

The assumption is that the newer version is closer... but the fact it runs on your real hardware is interesting. Are the files on Github the same files as you are running? (ie: have you tried re-downloading them?) Classic99 is not even getting as far as the DSR call, which makes me wonder if it's crashing on something else. I can see it executing scratchpad code and jumping out, so it seems the interpreter started. It's also beeping, and something must have turned on the sound chip -- is it supposed to start with a beep?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...