Jump to content

Photo

DSRLINK Code Tutorial


155 replies to this topic

#76 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 821 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
  • 821 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 OFFLINE  

mizapf

    River Patroller

  • 3,421 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
  • 821 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
  • 821 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,836 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
  • 821 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,836 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
  • 821 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
  • 821 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,836 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 OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,298 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
  • 821 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,663 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.


#90 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Fri Sep 7, 2018 2:40 PM

I made a change to my PAB structure in order to make a "file handle" based file system faster.

 

I will be posting in the CAMEL99 Forth thread for consistency since it's more on topic there.



#91 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Tue Oct 2, 2018 11:10 AM

FYI to any who cares to know, my DSR Link which works fine under Classic99 does not work on a real TI-99.

I been making some changes to try and find out why, but it is very slow going from the PC to the 99.  I use Forth as a debugger, meaning I can call each routine from the console and even type them in command by command and then examine CPU and VDP ram, but I have not found the problem yet.  I notice that everything in the PAB looks correct and I even put data in 83D0 again, in case that was the problem.

 

My next test will involve saving R11 in the GPL workspace before calling the ROM code and then restoring R11 when the rom code returns.  That could be a problem since Forth is calling the keyboard routine in GPL space all the time and I can see a relevant Forth address in R11 when I look at Classic99's debugger.

 

More tests to come.



#92 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Tue Oct 2, 2018 5:57 PM

Are interrupts disabled during disk access?  TI Forth and fbForth do that.

 

Also, what is your latest code?  I would like to dig into it.

 

...lee



#93 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Tue Oct 2, 2018 7:32 PM

Are interrupts disabled during disk access?  TI Forth and fbForth do that.

 

Also, what is your latest code?  I would like to dig into it.

 

...lee

 

OK I will try that as well. Thanks.

 

I am working with an interim version here that cobbles together a kernel with tools but I remove if/else/then and loops to keep it under 8K.

 

Here are the relevant files. in spoilers.

( I will put the 0 limi, instruction in the version I put here)

 

DSKDSR6.HSF

Spoiler

 

FILESYSF.HSF   is a very small system to allow Forth to bootstrap itself with more source code. 

Spoiler


#94 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Tue Oct 2, 2018 7:42 PM

Here is the source code for CAMEL3.HSF which creates the Forth system hi-level words.

I uses the newly arranged USER variable area but that did not seem to be the problem.

 

The biggest difference with this dbug verison is:

  • the COLD word does not try to include DSK1.START

It's important to note that cross-compiler is not standard Forth exactly.  There are some special words to make it work.

They are documented at the top of this file.

That was by design so my feeble mind could know what was ti-99 code and was cross-compiler code. ;-)

 

EDIT: Here a source code file for version of the hi-level system.

With the changes I made to the user variable and the DSKLNK word, it now enables the disk card on the 99 and stops.

It does not blow up the VDP screen like it used to, so a little closer.

 

Spoiler

Edited by TheBF, Tue Oct 2, 2018 8:09 PM.


#95 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Wed Oct 3, 2018 12:10 AM

Regarding DSKLNK , I cannot see that it is necessary to save/restore R11 around “ *R9 BL, ” unless you know something I do not (entirely possible).
 
NOP, is not at the place where the DSR expects an 8.  The DSR does not expect an 8.  It is the traditional DSRLNK that expects an 8 (or >A) after the BLWP that calls it.  Rather, the location of the NOP, may be used by the DSR as an error return.  It is the following address where the DSR normally returns, so you do at least need the place-holder you have provided.
 
I know you are trying to keep all of the ALC to just DSKLNK , but I am thinking you will need interrupts disabled before the card is turned on and not re-enabled until the card is turned off because both ISR workspace (>83C0 – >83DF) and GPL workspace (>83E0 – >83FF) are subject to change while interrupts are enabled.
 
...lee


#96 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Oct 3, 2018 7:24 AM

 

Regarding DSKLNK , I cannot see that it is necessary to save/restore R11 around “ *R9 BL, ” unless you know something I do not (entirely possible).
 
NOP, is not at the place where the DSR expects an 8.  The DSR does not expect an 8.  It is the traditional DSRLNK that expects an 8 (or >A) after the BLWP that calls it.  Rather, the location of the NOP, may be used by the DSR as an error return.  It is the following address where the DSR normally returns, so you do at least need the place-holder you have provided.
 
I know you are trying to keep all of the ALC to just DSKLNK , but I am thinking you will need interrupts disabled before the card is turned on and not re-enabled until the card is turned off because both ISR workspace (>83C0 – >83DF) and GPL workspace (>83E0 – >83FF) are subject to change while interrupts are enabled.
 
...lee

 

 

Wow, you stayed up late. ;-)

 

No I have no extra information. I was guessing that there might be a problem with changing R11 in the GPL workspace.

 

Thanks for the insights, I will make those changes and see if results change.  I will replace the NOP with a  data cell.

 

"I am thinking you will need interrupts disabled before the card is turned on and not re-enabled until the card is turned off because both ISR workspace (>83C0 – >83DF) and GPL workspace (>83E0 – >83FF) are subject to change while interrupts are enabled."

 

This sounds like a big one.  I never thought of this being a problem.  For all it's good features, the little 99 O/S is pretty weird in some ways.

 

I have yet to get Classic99 working the way Tursi suggested using TYPE 2 or TYPE 3 disk drives, which should cause the emulator to run real ROM code.  That would be the ideal way to find this by single stepping the code in the debug window.

 

I think I should make that happen as a first priority. It would definitely improve the [edit, compile, load, crash] cycle time.  :)

 

Thanks for your help Lee.



#97 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Wed Oct 3, 2018 8:34 AM

Wow, you stayed up late. ;-)

 

Yeah...When I get focused on something like this, I will often run it down no matter the TOD—probably, not the most efficient process late at night.  :sleep:

 

I will replace the NOP with a  data cell.

 

The NOP is probably better—just in case the DSR actually returns there.  The E/A cartridge’s and Paolo Bagneresi’s DSRLNKs actually install a jump back to search for another match in the linked list of device/subprogram names.  If you really wanted to handle that (in my opinion, unlikely) event, you should probably error out with the “bad device name” error or some such since, with your setup, it would be inconvenient to revert back to searching the DSR’s device list.

 

I have yet to get Classic99 working the way Tursi suggested using TYPE 2 or TYPE 3 disk drives, which should cause the emulator to run real ROM code.  That would be the ideal way to find this by single stepping the code in the debug window.

 

You definitely need TYPE 3 to insure actual use of the TI DSR code (TYPE 2 is simulated).  Because you cannot set up TYPE 3 within Classic99 (though Tursi implements it, he discourages its use and does not support it), I would first set up (in Classic99) whichever disk you are using as a DSK image, close Classic99, edit classic99.ini to change “Type=2” to “Type=3” in the proper “[Diskn]” section, close classic99.ini and restart Classic99.

 

...lee



#98 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Oct 3, 2018 8:43 AM

Ok thanks.  Just as a final test I re-wrote Enable and Disable in code to turn off interrupts and turn on interrupts respectively.

This did not change the operation on the real TI-99 but stills works perfectly on the emulator.  :(

 

So I will setup classic99 for real ROM operation and see where that leads.

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


#99 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Oct 3, 2018 9:06 AM

Here is a dumb question.

 

What's the best way to make a TI disk image?

 

I have been playing with Windows for this entire process. 

 

EDIT:  Found a menu option in TIDIR.  I might be able to figure this out.


Edited by TheBF, Wed Oct 3, 2018 9:13 AM.


#100 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Wed Oct 3, 2018 9:17 AM

Here is a dumb question.

 

What's the best way to make a TI disk image?

 

I have been playing with Windows for this entire process. 

 

EDIT:  Found a menu option in TIDIR.  I might be able to figure this out.

 

TIDir and TIImageTool both work well.

 

...lee






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users