Jump to content

Photo

Trying to learn TI programming

TI-99/4A Editor/Assembler Assembly Extended BASIC Mini Memory

188 replies to this topic

#151 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Jul 9, 2017 1:44 PM

What I'm running into a problem right now is finding documentation of detecting sub-directories on the drive (the instructions only list how to find a file list.)  I'd also sort of like to find out if there is a way to get a list of the drives that are available.


Subdirectories are a non-TI extension, which is why docs are less common. I don't have any devices that can use them but my notes say they show up as file type 6 (right after PROGRAM, type 5). Others here know them far better.

The only way to get a list of devices is to scan all the DSRs. Of course, that only tells you what's available, not necessarily what's connected.

#152 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Sun Jul 9, 2017 11:32 PM

That probably takes care of finding sub-directories.  Now I just have to research how to scan the DSRs.  I can probably use a DSR sub-routine to find if there is readable media available on any given device.  That would allow me to remove them from the listing.  The plan is that the menu will default to reading the root directory of DSK1, though, if I can find a way to pull the drive it was loaded from, I'll add in that instead.  Then there will be an option to switch drives/directories once in the Menu.  I still haven't decided if I'm going to have the editor embedded in with the menu program, or have it as a separate program.

 

I've also pseudo fixed the relocation issue.  The default location will be >2600 for the loaders.  I'll compile it there & get the total size.  I'll then create my menu program with a block of RAM reserved for it.  The "relocation" code will be created & tested, but "disabled" to start (it will be sitting where I want it for testing purposes.)  I'll, later, once everything's mostly settled, create a small program to move it, byte by byte, to the reserved block.  I've worked out how to have the Menu program loaded "with" the BASIC loader program.  So the loader will just build the DEF table (>2004 & >3FF8,) and jump to the MENU.  So, load "MENU", adjust >8330 & >8332, "merge" the BASIC portion.  Load the loaders (at >2600).  Load the "patch" program & LINK to it to patch the loaders into the RAM block.  Then "save" the final program as a BASIC file.

 

Now, the only issue is if the Option 5 file is going to load something to the Lo-RAM area.  I've modified the Option 5 loader so that it detects if this is going to happen.  In this case, it copies a tiny program (10 bytes) to >8300 and uses that to copy that block to RAM and then branch to the start point.  The rather complex (needs streamlining,) code is below.  I set it up so that it will load anything it can before loading the part that will overwrite it.  I actually haven't looked into it, but can a program be compiled & loaded with multiple addresses?  I'm fairly sure an Option 5 file can be set up to load into separate blocks.  1 or more files to load to Hi-RAM, and 1 file to load to Lo-RAM.  Each file in the chain specifies its own load location & length.

 

Anyways, the code:

 
       DEF  OPT5
 
       AORG >2600
 
       COPY "DSK1.XB-EQUATES"
       COPY "DSK1.DSR-GPL;S"
 
VDPADR EQU >0D09
REVADR EQU >090D
REVADW EQU >094D
REVADL EQU >0F0D
VDPPAB EQU >0C00
REVPAB EQU >004C
FNPTR  EQU >8356
 
OPT5   LWPI OPT5WS
       LIMI 0
 
       CLR  R0          * SECTION REMOVED FOR RELOCATABLE CODE
       CLR  R1
       INC  R1
       LI   R2,PAB+9
       BLWP @STRREF     * READ FILE DESCRIPTOR FROM CALL
       MOVB *R2,R2
       SRL  R2,8
       A    R2,R11
       SWPB R11
       AI   R2,10
 
       LI   R1,REVPAB
       MOVB R1,@VDPWA
       SWPB R1
       MOVB R1,@VDPWA
       LI   R1,PAB
CPYPAB MOVB *R1+,@VDPWD
       DEC  R2
       JNE  CPYPAB      * END OF REMOVED SECTION
       DEC  R1
       MOVB *R1,R7
 
       CLR  R10         * R10 WILL BE THE START ADDRESS
       CLR  R8
LOADLP MOV  R13,@FNPTR
       BLWP *R15
       DATA 8           * FILE LOADED
 
       LI   R0,REVADR
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       STWP R0
       LI   R1,6
       MOV  R1,R2
       A    R1,R0       * CHANGE TO ADDRESS OF R3
RDHDR  MOVB @VDPRD,*R0+
       DEC  R1
       JNE  RDHDR       * COPY FIRST 3 WORDS TO R3-R5
       S    R2,R4
 
       MOV  R11,R11
       JEQ  LAUNCH
       MOV  R8,R8
       JNE  BYPASS
       MOV  R10,R10     * IS LAUNCH ADDRESS SET?
       JNE  FSTBLK
       MOV  R5,R10      * SET THE LAUNCH ADDRESS
FSTBLK CI   R5,PAB
       JHE  BYPASS
       MOV  R5,R9
       A    R4,R9
       CI   R9,GLNKWS
       JHE  OVRWRT
BYPASS MOV  R3,R3       * ARE THERE MORE FILES?
       JEQ  LAUNCH 
CPYBLK MOVB @VDPRD,*R5+
       DEC  R4
       JNE  CPYBLK      * COPY FILE BUFFER TO RAM (EXCEPT HEADER)
       MOV  R11,R11
       JEQ  LOADLP
 
UPDTFN MOV  R11,R0
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       ORI  R0,>4000
       MOVB @VDPRD,R1
       MOVB R1,R7
       SWPB R0
OLDFN  MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       AI   R1,>0100
       MOVB R1,@VDPWD   * INCREMENT THE LAST CHARACTER
       MOV  R3,R3
       JEQ  LOADLP
       MOV  R11,R11
       JNE  LOADLP
       LI   R0,REVADL
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       JMP  CPYBLK
 
OVRWRT MOV  R3,R3
       JEQ  LNCHBP
       MOVB R7,R8
       AI   R8,>FF00
       CLR  R3
       JMP  UPDTFN
 
LAUNCH MOV  R8,R8
       JEQ  LNCHBP
       MOV  R8,R1
       CLR  R8
       MOV  R11,R0
       CLR  R11
       ORI  R0,>0040
       SETO R3
       JMP  OLDFN
 
LNCHBP LI   R1,>2018
       LI   R2,>2104
       LI   R0,14
MLOOP  MOV  *R1+,*R2+
       DEC  R0
       JNE  MLOOP       * COPY XB JUMP ADDRESSES TO EA LOCATIONS
 
       MOVB *R12,@>83D4 * VDP REGISTER 1 COPIED HERE
       DEC  R12
       LI   R1,8
       CLR  R0
NXTREG MOVB *R12+,R0
       SWPB R0
       BLWP @VWTR
       SWPB R0
       INC  R0
       DEC  R1
       JNE  NXTREG      * SET THE VDP REGISTER TO EA VALUES
 
       MOV  *R12+,@FAC
       BLWP *R14
       DATA >0018       * SET UPPER CASE CHARACTER PATTERNS
 
       MOV  *R12+,@FAC
       BLWP *R14
       DATA >004A       * SET LOWER CASE PATTERNS
 
       LI   R0,>5048
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,8
CPYRT  MOVB *R12+,@VDPWD
       DEC  R0
       JNE  CPYRT       * ADD EA COPYRIGHT PATTERN
 
       LI   R0,>F048
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,16
BARBOX MOVB *R12+,@VDPWD
       DEC   R0
       JNE   BARBOX     * ADD EA BAR & BOX PATTERNS
 
       LI   R0,REVADL
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,>8300        **
       LI   R1,RELOC        **
       LI   R2,OPT5WS-RELOC **
MOVRLC MOVB *R1+,*R0+       **
       DEC  R2              **
       JNE  MOVRLC          **
       LI   R0,GPLWS
       MOV  R10,*R0+
       MOV  R5,*R0+
       MOV  R4,*R0
       LWPI GPLWS
       B    @>8300          **
 
RELOC  MOVB @VDPRD,*R1+
       DEC  R2
       JNE  RELOC
       B    *R0
 
OPT5WS BSS  22
       DATA VDPPAB+9,EAREGS+1,VDPPAB+9,GPLLNK,DSRLNK
EAREGS DATA >00E0,>000E,>0106,>00F5
       DATA >0900,>0B00             * CHARACTER ADDRESSES
       DATA >3C42,>99A1,>A199,>423C * COPYRIGHT CHARACTER >0850
       DATA >7070,>7070,>7070,>7070 * BAR CHARACTER >08F0
       DATA >007E,>4242,>4242,>7E00 * BOX CHARACTER >08F8
PAB    DATA >0500
       DATA VDPADR
       DATA >0000
       DATA >2ACF
       DATA >00FF
       BSS  256
 
       END
 

I'm going to have to experiment with multi-block compiling & loading.  A quick way to disable the copy routine, without actually having to later change the code, would be to have a quick check of the contents of the location.  Some place where I know non-zero data could be found in the loader programs, but were I can force a zero to be in the "empty" load.  Then, when the program runs, it first checks that key location.  If it's zero, it just "JEQ" past the copy routine.  Otherwise, it runs a quick copy from a to b.  Gives me 4 to 6 extra bytes in the final program (4 if I pre-load the key address in a register.)  Example:  R0 is pre-loaded with the key location: "MOVB *R0,R1"  (2 Bytes,) rather than "MOVB @KEYLOC,R1" (4 Bytes.)  The "JEQ SKPCPY" would be the other 2 Bytes.  I've already worked out re-using buffers.  The PAB file descriptor block (not including the file descriptor length byte,) can be used to hold part of the "to be moved" program, as it won't be needed till later.  I just have to put any other temporary buffer spaces immediately following that portion of the PAB.

 

I currently plan to use 3 blocks of VDP RAM for the screens.  The main screen, of course, at >0800-0AFF, the "help" screen at >1000-12FF, and a temporary edit screen at >1400-16FF.  When time comes to start loading the program, screens 2 & 3 will be discarded.  So, they will work fine.  The only other file access I will be using up until that point will be data files, and they will be loaded 1 record at a time.  So the area from the end of the PAB to >1000 should be sufficient space.  The point I got distracted from:  One fairly important buffer will be the space I use to manipulate menu information blocks prior to being used or saved.  Could turn out to be a fairly large block.  Was planning to use simple RLE compression for the large display data (instruction/info screens & such.)  They would reside in memory & on disk in compressed format.  Then, when it comes time to edit/display them, they are decompressed into the appropriate area of VDP RAM.  After editing, they are compressed to RAM.  Still working on the details of that.  Trying to set it up so that there is only a single file for the information.

 



#153 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Mon Jul 10, 2017 12:13 AM

I can't address all the points there, you'll have to experiment with some... but so far as scanning DSRs for device names, just map each CRU base in one at a time (from >1000 to >1F00), and check for >AA at >4000. If it's present, there is a valid DSR ROM mapped in. Address >4008 has a pointer to the first entry in the DSR list, and you can walk the list to enumerate the devices. What you can't easily do is determine whether the hardware is physically present, or what type of device it is. You can try to open each device, but in the case of floppy drives that's pretty slow... especially when the drive is not present.

For loading EA#5 files, yes, absolutely the various parts can load to different, discontinuous addresses. They can also load in non-linear order (for instance, >C000 before >A000). If you're just trying to load as many possible things as you can, you can take a look at the Scratchpad Loader. A few of us on the Yahoo group put this together a few years ago, and it loads the various files from scratchpad to maximum compatibility even with EA#5 files that use all 32k. http://harmlesslion....ware/scratchpad-- this copy's for XB but all the source is in there.

#154 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Mon Jul 10, 2017 8:46 AM

I guess the thought wasn't original with me then :(

 

I have corrected it a bit.  The original code I listed would choke if a file break fell in the middle of the block I was protecting.  This new method just protects a specific range of RAM.  If data would be saved there, it is instead place in an out of the way location of the VDP (that isn't needed for other things,) and held there until the very end.  Then the small 10 byte program in the scratch pad just copies the entire chunk over to where it was supposed to go.  I also changed it so that if it isn't used, it also isn't copied.

 

The code could really use some streamlining, but I have tested it by moving it around to several locations so that my test programs will load into part of it, none of it, will have multiple files (ok, only 2,) try to load into it, etc...  Seemed t want to work just fine no matter where I put it :)

 

The new code:

 
       DEF  OPT5
 
       AORG >2600
 
       COPY "DSK1.XB-EQUATES"
       COPY "DSK1.DSR-GPL;S"
 
VDPADR EQU  >0D09
REVADR EQU  >090D
REVADW EQU  >094D
VDPPAB EQU  >0C00
REVPAB EQU  >004C
FNPTR  EQU  >8356
SBLOCK EQU  GLNKWS
EBLOCK EQU  GLNKWS+>800
VDPBUF EQU  >2E00
VBUFSZ EQU  >0800
 
OPT5   LWPI OPT5WS
       LIMI 0
 
       CLR  R0          * SECTION REMOVED FOR RELOCATABLE CODE
       CLR  R1
       INC  R1
       LI   R2,PAB+9
       BLWP @STRREF     * READ FILE DESCRIPTOR FROM CALL
       MOVB *R2,R2
       SRL  R2,8
       A    R2,R11
       SWPB R11
       AI   R2,10
 
       LI   R1,REVPAB
       MOVB R1,@VDPWA
       SWPB R1
       MOVB R1,@VDPWA
       LI   R1,PAB
CPYPAB MOVB *R1+,@VDPWD
       DEC  R2
       JNE  CPYPAB      * END OF REMOVED SECTION
       DEC  R1
 
       CLR  R10         * R10 WILL BE THE START ADDRESS
LOADLP MOV  R13,@FNPTR
       BLWP *R15
       DATA 8           * FILE LOADED
 
       LI   R0,REVADR
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       MOV  R0,R6       * TO KEEP TRACK OF WHERE VDP RAM IS POINTING
       STWP R0
       LI   R1,6
       MOV  R1,R2
       A    R1,R0       * CHANGE TO ADDRESS OF R3
       A    R1,R6       * UPDATE THE TRACKER
RDHDR  MOVB @VDPRD,*R0+
       DEC  R1
       JNE  RDHDR       * COPY FIRST 3 WORDS TO R3-R5
 
       MOV  R10,R10     * IS LAUNCH ADDRESS SET?
       JNE  FSTBLK
       MOV  R5,R10      * SET THE LAUNCH ADDRESS
FSTBLK MOV  R5,R9
       A    R4,R9       * CALCULATE END ADDRESS OF LOAD
       CI   R5,EBLOCK
       JHE  CPYBLK      * GO ON IF IT STARTS PAST OPT5 CODE
       CI   R9,SBLOCK
       JL   CPYBLK      * GO ON IF IT ENDS BEFORE OPT5 CODE
 
       CI   R9,EBLOCK
       JLE  EBLKLW
       LI   R9,EBLOCK
EBLKLW CI   R5,SBLOCK
       JHE  NOTLOW      * DOES IT START INSIDE THE CODE?
       MOV  R4,R0
       LI   R4,SBLOCK
       S    R5,R4       * HOW MANY UNTIL CODE STARTS
       S    R4,R0       * REDUCE TOTAL AMOUNT BY BLOCK SIZE
 
       A    R4,R6       * UPDATE THE VDP ADDRESS TRACKER
PRECPY MOVB @VDPRD,*R5+
       DEC  R4
       JNE  PRECPY      * COPY TO SAFE RAM
       MOV  R0,R4
 
NOTLOW MOV  R4,R8
       MOV  R9,R4
       S    R5,R4
       S    R4,R8
       CLR  R0
       CI   R4,EBLOCK-EMARK
       JLE  NOTFUL      * BUFFER IS LARGE ENOUGH
       MOV  R4,R0
       LI   R4,EBLOCK-EMARK
       S    R4,R0       * MAXIMUM BUFFER SIZE
 
NOTFUL A    R8,R0
       A    R4,R6       * TRACKER
       LI   R7,GLNKWS
       NEG  R7
       AI   R7,VDPBUF
       A    R5,R7       * SAVE OLD START ADJUSTED FOR VDPBUF
       A    R4,R5
       LI   R1,EMARK    * START OF BUFFER
FILBUF MOVB @VDPRD,*R1+
       DEC  R4
       JNE  FILBUF      * BUFFER FILLED
 
       LI   R4,EMARK
       NEG  R4
       A    R1,R4       * HOW MANY WAS MOVED AGAIN?
       ORI  R7,>4000
       SWPB R7
       MOVB R7,@VDPWA
       SWPB R7
       MOVB R7,@VDPWA
       LI   R1,EMARK
SAVBUF MOVB *R1+,@VDPWD
       DEC  R4
       JNE  SAVBUF
       MOV  R0,R4
       JEQ  CPYDN
       SWPB R6
       MOVB R6,@VDPWA
       SWPB R6
       MOVB R6,@VDPWA
       JMP  FSTBLK
 
CPYBLK MOVB @VDPRD,*R5+
       DEC  R4
       JNE  CPYBLK      * COPY FILE BUFFER TO RAM (EXCEPT HEADER)
 
CPYDN  MOV  R3,R3       * ARE THERE MORE FILES?
       JEQ  LAUNCH 
 
       MOV  R11,R0
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       ORI  R0,>4000
       MOVB @VDPRD,R1
       SWPB R0
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       AI   R1,>0100
       MOVB R1,@VDPWD   * INCREMENT THE LAST CHARACTER
       B    @LOADLP
 
LAUNCH LI   R1,>2018
       LI   R2,>2104
       LI   R0,14
MLOOP  MOV  *R1+,*R2+
       DEC  R0
       JNE  MLOOP       * COPY XB JUMP ADDRESSES TO EA LOCATIONS
 
       LI R0,>0040
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,>2020
       LI   R1,>300
CLRSCR MOVB R0,@VDPWD
       DEC  R1
       JNE  CLRSCR
 
       MOVB *R12,@>83D4 * VDP REGISTER 1 COPIED HERE
       DEC  R12
       LI   R1,8
       CLR  R0
NXTREG MOVB *R12+,R0
       SWPB R0
       BLWP @VWTR
       SWPB R0
       INC  R0
       DEC  R1
       JNE  NXTREG      * SET THE VDP REGISTER TO EA VALUES
 
       MOV  *R12+,@FAC
       BLWP *R14
       DATA >0018       * SET UPPER CASE CHARACTER PATTERNS
 
       MOV  *R12+,@FAC
       BLWP *R14
       DATA >004A       * SET LOWER CASE PATTERNS
 
       LI   R0,>5048
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,8
CPYRT  MOVB *R12+,@VDPWD
       DEC  R0
       JNE  CPYRT       * ADD EA COPYRIGHT PATTERN
 
       LI   R0,>F048
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,16
BARBOX MOVB *R12+,@VDPWD
       DEC   R0
       JNE   BARBOX     * ADD EA BAR & BOX PATTERNS
 
       LI   R0,GPLWS
       MOV  R10,*R0
       MOV  R7,R7
       JEQ  NOBUF
 
       LI   R1,RELOC
       LI   R2,>8300
       STWP R3
       S    R1,R3
CPYRLC MOVB *R1+,*R2+
       DEC  R3
       JNE  CPYRLC
 
       LI   R6,>8300
       LI   R5,SBLOCK
       LI   R7,VDPBUF
       SWPB R7
       MOVB R7,@VDPWA
       SWPB R7
       MOVB R7,@VDPWA
       LI   R4,VBUFSZ
       MOV  R6,*R0+
       MOV  R5,*R0+
       MOV  R4,*R0+
       MOV  R10,*R0
NOBUF  LWPI GPLWS
       B    *R0
 
RELOC  MOVB @VDPRD,*R1+
       DEC  R2
       JNE  RELOC
       B    *R3
 
OPT5WS BSS  22
       DATA VDPPAB+9,EAREGS+1,VDPPAB+9,GPLLNK,DSRLNK
EAREGS DATA >00E0,>000E,>0106,>00F5
       DATA >0900,>0B00             * CHARACTER ADDRESSES
       DATA >3C42,>99A1,>A199,>423C * COPYRIGHT CHARACTER >0850
       DATA >7070,>7070,>7070,>7070 * BAR CHARACTER >08F0
       DATA >007E,>4242,>4242,>7E00 * BOX CHARACTER >08F8
PAB    DATA >0500
       DATA VDPADR
       DATA >0000
       DATA >2ACF
       DATA >00FF
       BSS  256
 
EMARK  END


#155 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Mon Jul 17, 2017 2:36 AM

OK, that is frustrating.  What I've written is around 1K in size (including DSRLNK & GPLLNK.)  Those are only around 200 bytes though.  Starting to look at what others have written (this is mostly a learning exercise for me,) and am a little frustrated at how small everyone else's seem to be :(  Yes, I put in a lot of error prevention & such.  I also have been putting in a 255 byte buffer for the file descriptor.  Mainly because one HDD card I read on allows a path depth of over 100 (that could easily require a descriptor length of over 1000 bytes.)  So, I set it at 255 which is the largest string that can be passed through the CALL LINK (from everything I can find that is.)  But it's still discouraging.  I've also discovered an Option 5 program that literally uses every bit of available RAM (which was what made my >8300 patch necessary.)

 

Because of this, I've taken a bit of a break from the Option 5 loader.  From my project in general for that matter (been putting my Amiga's back together for the couple of days.)  Seriously considering not trying to write my own Option 5 loader, and go back to using those already provided.  Just altering them to be relocatable & stretching the File Descriptor when necessary.  Really, Building the PAB is actually handled by my main program anyway.  Also trying to see if there is any way to combine the different loaders to share as much code as possible.

 

As for the menu system itself, I was trying to eliminate the need to load multiple files (using the load assembly with XB program method.)  But, I'm starting to reconsider that.  The Font data by itself is 2K.  Then you add in the pre-programmed  text (help screen, labels, borders, etc...) I'm starting to think it might be best to just put anything that is a large chunk into a file.  The font is easy, just set the character pattern address as the buffer and "load" it :)  can do the same for the help screen & loading screens.

 

I've brought the loading screens back.  It finally dawned on me that the high loading speed was due to the emulator I was using.  I was having an issue with the incorrect manner in which Classic99 (the one I'm using for the debugger access) handles file status reads, so tried my code in another emulator.  Was actually surprised a bit at how long it took to load.  I realized my mistake almost immediately and decided to bring them back.  They'll still be the basic screens, as I've already decided to move away from bitmap mode.  I can still do it in bitmap mode if I wanted, but with the design changes I've made, it became unnecessary to use it.

 

FYI - in case you are curious.  In Classic99, if you read a files status (DSRLNK OP-Code >09) you get inaccurate results.  In Mode-2 - bit 0 is used to mark both a program file & a non-existent file, bit 7 is used to mark protected files, bits 1 & 4 aren't used.  In Mode 3 the bits are all accurate except bit 5, which is only accurate if bit 2 (protected) is set.  Caused me no end of hair pulling until I figured that out.  I have to be careful while debugging, though, as I can't reliably tell the difference between fixed & variable files.



#156 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Mon Jul 17, 2017 3:11 PM

FYI - in case you are curious.  In Classic99, if you read a files status (DSRLNK OP-Code >09) you get inaccurate results.  In Mode-2 - bit 0 is used to mark both a program file & a non-existent file, bit 7 is used to mark protected files, bits 1 & 4 aren't used.  In Mode 3 the bits are all accurate except bit 5, which is only accurate if bit 2 (protected) is set.  Caused me no end of hair pulling until I figured that out.  I have to be careful while debugging, though, as I can't reliably tell the difference between fixed & variable files.

 

I'd be happy to fix that. ;)

 

(edit) I was able to figure some of it out -- "mode 2" and "mode 3" -- are you hacking the Classic99.ini and changing the disk mode? Don't do that without knowing what you're doing. It's not necessary for anything except testing with a TI Disk Controller ROM anymore.

 

That said, if that's what you meant, "mode 3" is the TI Disk Controller ROM running, completely untranslated by Classic99. So the behaviour you see there is the behaviour you're going to get out of the hardware too. You can say it's wrong, but that won't change it. ;)

 

That answers my other questions too - you're using disk images, so I know where in the source to look. What you're describing sounds wrong, so I went looking for that.

 

That said, I'm pretty sure you're seeing other bugs. The code that handles status calls is shared between images and files, and I double-checked things like PROGRAM versus FILE NOT FOUND. (Not found is 0x80, PROGRAM is 0x08). PROTECTED and DISK FULL are unsupported and never set (TI controller does not run this code so follows its own rules).

 

You're claiming that 0x80 indicates both file not found and program files, 0x40 indicates protected, and 0x08 and 0x02 are not used. That doesn't line up with my observations. (It's correct that 0x02 - memory full - is not used.) The code is pretty straight forward:

 

Spoiler

 

I don't have much that /uses/ status. I did a few tests from BASIC (EOF() uses it), but I couldn't test much of what you observed with that. Do you have a simple test app?


Edited by Tursi, Mon Jul 17, 2017 3:54 PM.


#157 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Mon Jul 17, 2017 3:48 PM

I guess the other question is, are you running an old version? Old versions used to have a lot of trouble with status inquiries. :) Should be on 395.



#158 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Mon Jul 17, 2017 9:50 PM

Actually running 393 right now (I'll update in a bit.)  Yes, I meant disk mode 2 & 3.  Was having a problem during direct sector reads and was instructed to switch to mode 3. I've since moved away from that, and went back to mode 2 because it's easier than switching the disk, exiting out, editing the ini, then loading back up again.  I just switched to mode 3 in this case to complete testing.

 

Took me a bit to dig the testing code out - I had deleted it :(  It's included below.  But I got the following results (After updating to 395.)

Expected       File Type            Mode 2  Mode 3   OTHER*
============================================================
   >08     Program                   >80     >08      >08
   >48     Prot. Program             >80     >48      >48
   >10     Internal Fixed            >10     >10      >10
   >50     Prot. Internal Fixed      >10     >50      >50
   >14     Internal Variable         >14     >14      >14
   >54     Prot. Internal Variable   >14     >54      >54
   >00     Display Fixed             >00     >04      >00
   >40     Prot. Display Fixed       >00     >40      >40
   >04     Display Variable          >04     >04      >04
   >44     Prot. Display Variable    >05     >44      >44
   >80     Non-Existing              >80     >80      >80

*OTHER = Win994a Simulator & MAME

The results have improved in Mode 3 with only one error (which doesn't effect what I'm trying to do right now.)  But Mode 2 is still failing to differentiate between a file that doesn't exist and a program file.  Though I did notice eventually that the non existing file is actually being created during the status read (in mode 2.)

 

As promised the testing code.  I'm also attaching a disk image I used for testing.

 
       DEF  GETST
 
       AORG >A000
 
       COPY "DSK1.XB-EQUATES"
       COPY "DSK1.DSR-GPL;S"
 
VDPPAB EQU >0C00
VDPADR EQU >0D09
ELNTBL EQU >8330
BLNTBL EQU >8332
EBASIC EQU >FFE7
RBASIC EQU >64BD
FNPTR  EQU >8356
LSTPRT EQU >8345
 
GTSTWS BSS  30
       DATA VDPPAB+9
GETST  LWPI GTSTWS
       LIMI 0
 
       LI   R1,>8080
       LI   R0,>0040
       MOVB R0,@VDPWA
       SWPB R0
       MOVB R0,@VDPWA
       LI   R0,>0300
CLRSCR MOVB R1,@VDPWD
       DEC  R0
       JNE  CLRSCR
 
       SETO R1
       LI   R2,PAB+9
       MOVB R1,*R2
       INCT R1
       BLWP @STRREF     * READ FILE DESCRIPTOR FROM CALL
 
       MOVB *R2,R2      * GET DESCRIPTOR LENGTH
       SRL  R2,8
       AI   R2,10       * ADD BASE SIZE OF PAB
       LI   R0,VDPPAB
       LI   R1,PAB
       BLWP @VMBW       * PAB NOW IN VDP
 
       MOV  R15,@FNPTR
       BLWP @DSRLNK
       DATA 8           * READ FILE STATUS
 
       MOV  R15,R0
       DEC  R0
       BLWP @VSBR
       MOV  R1,R14
       SRL  R14,8
 
       LI   R0,>0020
       LI   R2,TXTHDR
       MOV  *R2+,R3
SHWHDR MOVB *R2+,R1
       AI   R1,>6000
       BLWP @VSBW
       INC  R0
       DEC  R3
       JNE  SHWHDR
       MOV  R14,R4
       ANDI R4,>000F
       SLA  R14,4
       MOVB R14,R4
       SRL  R14,4
       LI   R3,2
SHWSTS MOVB R4,R5
       SRL  R5,8
       MOVB @HEXDEC(R5),R1
       AI   R1,>6000
       BLWP @VSBW
       INC  R0
       SWPB R4
       DEC  R3
       JNE  SHWSTS
 
       LI   R3,>0082
       LI   R4,>0040
       LI   R5,>80
       LI   R6,8
SHBTS  MOV  R3,R0
       A    R4,R3
       MOV  *R2+,R7
SHWSTR MOVB *R2+,R1
       AI   R1,>6000
       BLWP @VSBW
       INC  R0
       DEC  R7
       JNE  SHWSTR
       MOV  *R2+,R7
       COC  R5,R14
       JNE  BITCLR
       A    R7,R2
       MOV  *R2+,R7
BITCLR MOVB *R2+,R1
       AI    R1,>6000
       BLWP  @VSBW
       INC   R0
       DEC   R7
       JNE   BITCLR
       COC   R5,R14
       JEQ   BITSET
       MOV   *R2+,R7
       A     R7,R2
BITSET SRL   R5,1
       JNE   SHBTS
 
       LWPI GPLWS
       CLR  @STATUS
       LIMI 2
       B    @RTNPTR
 
HEXDEC TEXT '0123456789ABCDEF'
TXTHDR DATA 14
       TEXT 'STATUS BYTE: >'
BIT0   DATA 8
       TEXT 'BIT 0 - '
       DATA 12
       TEXT 'FILE EXISTS '
       DATA 20
       TEXT 'FILE DOES NOT EXIST '
BIT1   DATA 8
       TEXT 'BIT 1 - '
       DATA 18
       TEXT 'FILE NOT PROTECTED'
       DATA 18
       TEXT 'FILE IS PROTECTED '
BIT2   DATA 8
       TEXT 'BIT 2 - '
       DATA 12
       TEXT '  *RESERVED*'
       DATA 12
       TEXT '  *RESERVED*'
BIT3   DATA 8
       TEXT 'BIT 3 - '
       DATA 8
       TEXT 'DISPLAY '
       DATA 8
       TEXT 'INTERNAL'
BIT4   DATA 8
       TEXT 'BIT 4 - '
       DATA 10
       TEXT 'DATA FILE '
       DATA 12
       TEXT 'PROGRAM FILE'
BIT5   DATA 8
       TEXT 'BIT 5 - '
       DATA 6
       TEXT 'FIXED '
       DATA 8
       TEXT 'VARIABLE'
BIT6   DATA 8
       TEXT 'BIT 6 - '
       DATA 10
       TEXT '  *UNUSED*'
       DATA 10
       TEXT '  *UNUSED*'
BIT7   DATA 8
       TEXT 'BIT 7 - '
       DATA 10
       TEXT '  *UNUSED*'
       DATA 10
       TEXT '  *UNUSED*'

PAB    DATA >0900
       DATA VDPADR
       DATA >0000
       DATA >0008
       DATA >00FF
PAB2   BSS 256
 
       END

Attached File  TEST.zip   8.01KB   3 downloads



#159 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Mon Jul 17, 2017 10:09 PM

Reason for pulling the status at this time.  During the creation of my Menu program, instead of loading an info file, I'm just using a static list for now.  I was going to just read the status of each file and set it up as opt5, basic, long basic based on the status results.  This was going to be all done in the module that would normally load and interpret the info file.  That's when I ran into the issue, and decided to take a small break.  Right now, I'm trying to get my Amiga 2000 finished.  Having problems install the HDD :(

 

Eventually deciding the file types will be done by the editor, and will be handled by reading the catalog (file descriptor "DSK1.")



#160 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jul 18, 2017 12:12 PM

Thanks! It took a bit to figure out how to run your test... but once I realized it was for XB it was easy to put together a quick test harness!

 

The protected file bit is not supported by the Classic99 file system, so there's no need to test that. I have reproduced your issue with the PROGRAM file type reporting as non-existent, and that's a surprise! It looks like it's because the status handler attempts to buffer the file records (it basically just calls open to get the data) -- but PROGRAM files don't do that. Since the open fails, the status handler assumes it's because the file's not available. Will fix that up!

 

The bad return code from the TI controller ROM on Display/Fixed is interesting... it seems to be reading the correct sectors. Since the others get it right I guess I'll have to step through the DSR ROM to see what's going wrong there - might be a symptom of something more insidious.



#161 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Wed Jul 19, 2017 9:46 PM

My A2000 is all put together and pretty much finalized :)  Got the A4000 up on the test/build bench now.  Was working on my menu again for a bit (back hurts,) and came across an interesting issue (to me at least.)  Is there any way to find out where a program was loaded from once it starts running?  So, for example, if I was to load my menu program manually from DSK2, is there a way to find that that is where I loaded it from after it's running?  I can't seem to find it in a quick search.  I'll keep looking, but I figured it never hurts to ask. :)

 

Tursi:  Don't get me wrong, I love the debugger in Classic99.  It just has this minor little issue that keeps kicking me at just the wrong moment :(  If you are up for a request on the debugger... Would love the ability to view a dissasembly at a given address instead of just where my program happens to be at the moment :)  In paused mode, just being able to type in an address and have the dissasembly screen show dissasembled code beginning at that address would be great.



#162 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Jul 20, 2017 1:39 AM

Unfortunately I'm buried under many other projects, and Classic99 isn't at the top of the list for major work. However, when I need to do that, I just breakpoint, write down the current PC, and type "PC=xxxx". The PC will jump and the disassembly will update. You can then "PC=yyyy" back to the original location, and nothing is harmed. It's hacky, but it does the job. ;)

Load tracking is covered on the forum here a few times, you may have to search but I think that's the term you want. I don't think there was a 100% certain way but there were a couple of pretty-close approaches that people finally settled on. ;)

#163 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Thu Jul 20, 2017 2:37 AM

One of these days I'll actually remember to RTFM :(  Of course, I hadn't noticed that there actually was a manual until you mentioned the PC= option.  That's when I actually went looking for it.  With that information, what I asked for is not needed.  the PC= does what I need it to do.  About the only thing left would be a GPL dissassembler, I'll read through the manual first though :)

 

I'll add "load tracking" to my search term.  I'm still looking.  Maybe that will lead me to something.  If I can just get a "device" I can use that as a start point, and if that device doesn't have the support file I need, I'll then scan through the rest.  I'm moving a lot of the "data" out of the main program and putting them into a separate file that I'll just load.  For example, the font will just be a >0800 byte file that I will load with a VDP RAM buffer of >0000 (location of the character pattern data.)  I can do the same thing with the main menu screen & the help screen.  Since most of the data files will be read in 1 record at a time, I'm planning to set up 2 screens.  When it come time to actually load the target program, I'll just shut down screen 2 and use screen 1 to display the loading screen.  I'm only trying to decide if it's worth it to compress any of the data.  Font file will be 768 bytes, screen 1 (help/loading screen) will be 800 bytes (768 screen & 32 color.) Screen 2 will be 768 bytes.  Simple RLE can reduce that tremendously.  The basic display, for example, will be reduced from 768 bytes to 108 bytes.  The main drawback being that it can no longer be loaded directly into the display space.  It would have to be loaded, moved to CPU RAM then decompressed back into VDP RAM.  Not sure if it's worth it or not. 



#164 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Jul 20, 2017 11:51 PM

There's no GPL debugger. I've thought about it, but it's a big job. ;)
 
Uploaded v396 to fix the file status reporting, /BUT/...
 
The TI disk controller ROM ("mode 3") is broken in this respect. It can not tell DV from DF apart on a status call - it will always report DV unless the file is also protected.
 
The bug is here:
A588A  BL   @A4B70            get 2 bytes from FDR into R0
       DATA >000C             file status byte
       ANDI 0,>8F00           mask irrelevant bits
       JGT  A589A             <------------ right here - BUG! DV files are 0, which is not greater than!
       ORI  0,>0080           var: put var bit in PAB status style
A589A  SLA  0,3               get rid of var bit in FDR style
       SOCB 2,0               add "eof" and "mem full" bits
... and the editor threw away my explanation. So here it is again, shorter this time.

The problem is in the code that remaps the variable bit from >8000 to >0080, so that the shift that follows can put it into the right place. The status byte in the FDR for a display/fixed (unprotected) file is >00. Zero is not arithmetically greater than zero, so the JGT is not taken, and the variable flag is dropped into the word.

I had to dig out my console and PEB to prove this, and yes, a real TI disk controller fails in the same way.

Anyway, the Classic99 controller is fixed to properly report the status of a PROGRAM image file now. ;)

Edited by Tursi, Thu Jul 20, 2017 11:54 PM.

  • RXB likes this

#165 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Fri Jul 21, 2017 12:49 AM

OK, just went back and checked.  MAME (with TI FDC as the device,) does report D/F files as same as D/V unless they are protected.  And failing because the code wasn't designed to properly handle a >00 value actually makes sense.  Don't know why I was getting the correct value there on my original test run.  I can only think it was because I ran through them quickly, and didn't pay close enough attention and messed up :(  Or I had accidentally put in a different controller card. 

 

Glad to hear I was able to help you track down an issue and fix it in your code :)  I always get a warm/fuzzy feeling when I'm able to help out another programmer.  I may be an amateur, but I like to think I understand the difficulties in tracking down problems with complex code.  From what you've said, I am assuming that you are the creator/writer of Classic99.  It's a very fine emulator.  Generally, I prefer real HW over emulation, but for testing & programming purposes, an emulator is nice.  The new version works great, btw.  Just out of curiosity, and feel free not to answer, but.... Any particular reason file protection is disabled in mode 2?  It isn't going to impact what I'm writing (so far,) but I am a little curious.

 

I don't really need a GPL language debugger.  Was looking for a disassembler at one point, when I was trying to track down a way to "RUN" a BASIC program from assembly.  The only disassembled code I had access too, at the time, was for console ROM BASIC, not Extended BASIC.  Was able to get it working, but it was a little frustrating.  I kept running into an issue with the jump table getting corrupted.  Not that it "should" have made a difference, but it didn't sit well with me.  Fixed it by not using GPLLNK to run it, but to take the portion of the code in GPLLNK that I needed and running it directly.

 

I have been looking into other drive & device options as well.  I would really like to put a small HDD and a 3.5" floppy into system along with the 5.25" drive.  Reading up on the options, 80 track access and such, I came across some interesting information.  My TI FDC (PHP1240, right?) can be modified for 80 track, there is also a mod for DD.  Reading comments, many people asking, but not finding any responses, about 80 track and DD together, I decided to do a little quick math.  An 80 track DD (18 sectors/track,) disk would have a total of 2880 sectors.  That would require an Allocation Map of 360 Bytes (2880 / 8.)  The Volume Information Block only has 200 Bytes available for the Allocation MAP.  So for it to work, the VIB would need to be altered or extended.  Adding in a second AU would become necessary.  Also, to do HD would require twice that number.  Though, expanding the AU size to 512 would accomplish the same without creating more sectors.  Would this be handled in the DSR ROM or is it something that is pretty much locked by the TI-99/4A's console ROMs?

 

Finally, searching for "Load Tracking" isn't helping much in my search either :(  I'm on the verge of just creating a list of available devices, and using a default search order.  DSK1 would be the first (since it is being designed to run as an auto-run menu system,) and then just working through the devices until it finds itself.  The File Buffers (>37d7 - >3e??) don't seem to be consistent.  I'll keep searching, but it seems a consistent method just doesn't exist, so working with the DSK1 assumption seems to be the best option.

 

 



#166 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Fri Jul 21, 2017 7:55 AM

...

Finally, searching for "Load Tracking" isn't helping much in my search either :(  I'm on the verge of just creating a list of available devices, and using a default search order.  DSK1 would be the first (since it is being designed to run as an auto-run menu system,) and then just working through the devices until it finds itself.  The File Buffers (>37d7 - >3e??) don't seem to be consistent.  I'll keep searching, but it seems a consistent method just doesn't exist, so working with the DSK1 assumption seems to be the best option.

 

Search for “boot tracking” in the development sub-forum.  I think most discussion of this issue is there.

 

...lee



#167 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Jul 21, 2017 10:24 AM

Any particular reason file protection is disabled in mode 2?  It isn't going to impact what I'm writing (so far,) but I am a little curious.


It's unimplemented rather than disabled. The Classic99 disk controller implements everything in native code so that I can verify operation and compatibility to eventually move the code back to a hardware device. Or at least, that was the plan twenty years ago. ;)

It doesn't support the file protection bit because I think it's a dumb feature that serves no useful purpose and I didn't want to propagate it. ;)

Would this be handled in the DSR ROM or is it something that is pretty much locked by the TI-99/4A's console ROMs?


The console ROMs have no concept of "disk". TI implemented a generic file access system based on searching for a DSR ROM and passing the PAB to it -- all details of what to do with that PAB are handled by the DSR.

Most of the limitations we have on the file system are because the only controller that had time to become popular was the Disk Controller card and all the disk controllers based on it - so they (nearly) have all the same limitations and warts. And every time one of them changed something, it caused incompatibilities in the software that assumed they could rely on the side effects. ;)

But there's technically no limits at all. OPEN, READ, CLOSE. Nothing in that infers the limitations of the underlying system, except that the device name can't be more than 7 characters and the full path name is limited to 255. ;) So, yes, you can totally change the layout of the storage medium. Classic99 (and V9T9) does this for FIADs by serving up PC files to the system. Hard drive controllers do it too. Someone once mentioned (I thought) a device that did have two sectors for the allocation units... but other people know more about the various options that were available than I do, I never had more than the base TI controller card.

Sorry for steering you wrong on the boot tracking - thanks Lee for speaking up there.

#168 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Fri Jul 21, 2017 6:21 PM

There's actually nothing, then, stopping someone to write a DSR to read just about any format?  Maybe I should say layout.  I imagine that it would depend on the HW as well.  The WD1773 (is that the right number?) is probably limited to FM and/or MFM format.  But is there anything stopping a designer from using a different chip and reading, GCR (Apple, Commodore, etc..) disks?  I can just see it now, Kryoflux on a TI PEB card :)  OK, maybe not.  But taking the controller card out of the equation, the only HW limitation is 7 bytes for device name and 255 bytes for file descriptor?  So, even the 10 bytes for file name is a limitation of the DSR and not the console itself?

 

That actually leads me to another, non-programming related, question.  I keep reading that the HD drive support (MyArc HFDC card) causes the TI-99/4A to have minor fits.  Is it the DSR that needs adjusting, or is this something else?

 

Back to drive limitations,  Is the DSR written in GPL or CPU code?  Programming the DSR to double-step an 80 track drive's motor for 40 track disks seems like it would be simple enough (to maintain compatibility,) it would just boil down to how the DSR handles disks with more than 1600 sectors (the most a 200 byte allocation map can handle.)  That's 80 tracks, 2 sides, 10 sectors/track (400 K.)  There are really only 2 ways to handle that, I would think.  One is to increase the size of the sectors (to 512 bytes instead of 256,) which would probably beak a lot of software.  The other is to add extra sectors to the VIB, a safer method as it would only apply to newer disks, as long as support for a single sector VIB is included.  For DD, that would require only 1 extra, for HD it would require 3 (with the last one only using 8 bytes.)  In all honesty, at this point, I think I would set it up to use 2 sectors by default, with the reserved sectors being applied to each side.  So, each side would have it's own VIB, where the Map only applies to the side in question.  That could make things a bit simple, but there would have to be something in the VIB to let the DSR know if a legacy floppy was in the drive.  Changing the identifier (Bytes 13-15, "DSK") could work for doing that.  The sector numbering could remain the same, just how the Map is referenced.



#169 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,746 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Jul 21, 2017 8:34 PM

There's actually nothing, then, stopping someone to write a DSR to read just about any format?  Maybe I should say layout.  I imagine that it would depend on the HW as well.  The WD1773 (is that the right number?) is probably limited to FM and/or MFM format.  But is there anything stopping a designer from using a different chip and reading, GCR (Apple, Commodore, etc..) disks?  I can just see it now, Kryoflux on a TI PEB card :)  OK, maybe not.  But taking the controller card out of the equation, the only HW limitation is 7 bytes for device name and 255 bytes for file descriptor?  So, even the 10 bytes for file name is a limitation of the DSR and not the console itself?


Yes. ;)

Switch Classic99 back to FIAD mode and you'll see the TI "DSR" handling your entire PC filesystem. The console doesn't care. :)

Back to drive limitations,  Is the DSR written in GPL or CPU code?


CPU code. DSRs are banked into CPU space at >4000 and have 8k of address space reserved.

I can't help much with your other questions. I don't like diskettes (anymore) and I've never used a TI hard drive, so I don't delve too deep into them. But I thought someone mentioned a couple of years ago about HD diskettes with an extra allocation sector (maybe on the Geneve...)

#170 RXB OFFLINE  

RXB

    River Patroller

  • 2,724 posts
  • Location:Vancouver, Washington, USA

Posted Fri Jul 21, 2017 11:48 PM

Subdirectories are a non-TI extension, which is why docs are less common. I don't have any devices that can use them but my notes say they show up as file type 6 (right after PROGRAM, type 5). Others here know them far better.

The only way to get a list of devices is to scan all the DSRs. Of course, that only tells you what's available, not necessarily what's connected.

Is there a DSR without a CRU address we can scan?



#171 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 418 posts

Posted Sun Jul 23, 2017 3:09 AM

The cassette DSR is in the console, and different, as it's not among those that are scanned in the PEB expansion card scan sequence. It's partially in GPL, so it's different from all aspects.

 

But when it comes to disks, you can do just anything. Look at the p-system, for example, which uses the original TI disk controller, or a CorComp double density or whatever, but doesn't read the normal TI files at all. It doesn't have any allocation  map limiting the number of sectors, but instead have the p-systems limit of max 77 files per volume. It also allows 15 character file names.

Look at the programs Advanced Diagnostics and Explorer, which use non-contiguous sector numbers or unformatted storage, by bypassing the DSR and doing their disk access in their own way. The same method could be included inside a DSR.

Or look at my very own DSR, which converts a Maximem module and 64 K internal memory expansion into a RAMdisk.



#172 TheTIGuy OFFLINE  

TheTIGuy

    Chopper Commander

  • 158 posts
  • Location:Military City, USA.

Posted Sun Jul 23, 2017 3:47 AM

Know nothing of assembly, just wanted to post mt 1st HTML code ever, please remove if inappropriate.

Attached Files



#173 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,691 posts

Posted Sun Jul 23, 2017 11:41 AM

 

 

That actually leads me to another, non-programming related, question.  I keep reading that the HD drive support (MyArc HFDC card) causes the TI-99/4A to have minor fits.  Is it the DSR that needs adjusting, or is this something else?

 

Back to drive limitations,  Is the DSR written in GPL or CPU code?  Programming the DSR to double-step an 80 track drive's motor for 40 track disks seems like it would be simple enough (to maintain compatibility,) it would just boil down to how the DSR handles disks with more than 1600 sectors (the most a 200 byte allocation map can handle.)  That's 80 tracks, 2 sides, 10 sectors/track (400 K.)  There are really only 2 ways to handle that, I would think.  One is to increase the size of the sectors (to 512 bytes instead of 256,) which would probably beak a lot of software.  The other is to add extra sectors to the VIB, a safer method as it would only apply to newer disks, as long as support for a single sector VIB is included.  For DD, that would require only 1 extra, for HD it would require 3 (with the last one only using 8 bytes.)  In all honesty, at this point, I think I would set it up to use 2 sectors by default, with the reserved sectors being applied to each side.  So, each side would have it's own VIB, where the Map only applies to the side in question.  That could make things a bit simple, but there would have to be something in the VIB to let the DSR know if a legacy floppy was in the drive.  Changing the identifier (Bytes 13-15, "DSK") could work for doing that.  The sector numbering could remain the same, just how the Map is referenced.

I'm not sure what you mean by 'causes the TI-99/4A to have minor fits".  The HFCD (and SCSI, IDE, and HDX) added extensions to the disk-based DSR subroutines which unfortunately made writing support for those devices more complicated than it needed to be. As has been described in the forums in other threads, the complications only apply to certain routines used by a small numbers of programs such as disk managers and terminal emulators.

 

As for disk drive limitations, there is a third option and it is the option currently used by the Myarc controllers, Horizon RAMdisk ROS (8.32 or higher), and the Geneve.  The 200 byte bitmap is -not- extended in any way.  Instead, each allocation unit(AU) represents 1,2,4, or 8 sectors based on the capacity.  For a 2880 sector diskette, each AU represents 2 sectors.  The File Descriptor Record cluster bytes do not need to be manipulated for this AU/sector ratio.

 

Disk sizes greater than 3200 sectors require manipulation of both the AU/sector ratio and the FDR cluster bytes.  The Geneve can manage disk images of up to 12,800 sectors in size, either by using the HFDC disk emulation feature or by specially formatting a Horizon RAMdisk.  The only changes to the VIB are in the density/track bytes and total sectors word, the latter is often used to determine the proper calculations.



#174 Pheonix ONLINE  

Pheonix

    Star Raider

  • Topic Starter
  • 81 posts

Posted Sun Jul 23, 2017 3:17 PM

I decided on "minor fits" after trying to find a way to sum up my results into a single word (settled on 2.)  My reading of HD floppy access on the TI-99/4A was rather disconcerting with widely variable results.  One source says it works fine on a TI-99/4A as long as you are running it on the Geneve (which to me, doesn't count as a TI-99/4A.)  Another source says, it works, but you get data corruption on the disk.  A third source says that when you try to load/save the TI reports errors & fails.  Didn't find a single source that said it worked, so gave up.  P.S.  To me, calling a Geneve a TI-99/4A is like calling a C128 a C64.  Yes, it is compatible, but it still isn't the same.  That being said, I might, some day, look into getting one.  After a lot more research into it, that is.  From what I understand, it's a PEB card that takes the place of the TI-99/4A console itself.

 

I didn't exactly leave it out, I counted it as a more complicated way of increasing the sector size.  You're basically following in the footsteps of the PC's FAT system, and creating clusters to handle drives that have more sectors than the Allocation Map has bits for.  So, you now have 2 values to track, sectors & clusters.  You also have to have a set method for grouping sectors into clusters:  Is an interleave going to be incorporated?  Are you going to cross sides?  Are you going to cross tracks?  Those are the 3 main questions that come to mind.  Less likely to break compatibility than increased sector sizes, though, so I guess I shouldn't have glossed over it.  All that being said, since TI (in their FDC,) seems to have a modified FAT system anyway, that actually follows.

 

Personally, I prefer extending the Map over building clusters.  Reserve the extra Map sectors as used during format, and then all you need is for the DSR to be aware of them & use them.  Everything else would work like normal.  You end up losing space right at the beginning, but you make for it from less wasted space per file.  In the cluster method, you can end up losing 1 sector for every file on the disk.  Though, on average, you only lose 1 sector every other file.  So, put 2 files on the disk, and you break even with the 2 methods.  Put more and you actually start netting less sectors lost.  This hold true for when you use 3 extra sectors for the Map as well.  3 extra sectors are needed for HD 80 Track, or a cluster size of 4 sectors.  So the wasted sectors / cluster will range from 0 to 4 for an average of 2.  So, 2 files will (on average,) result in a net gain of 1 sector.  That's just my personal view on it, though.

 

On the same note:  On the PC, 5.25" HD floppies are actually 16 (512 byte,) sectors instead of the 18 that 3.5" HD floppies have.  If this is a limit of the media, and not some random rule created by DOS, then it might be safer to set HD floppies to 32 sectors/track instead of 36.  I'm assuming that there isn't already something that detects 3.5" & 5.25" drives in place.  You lose a bit of space (1.2 M instead of 1.44 M,) but it won't cause problems for someone wanting to use an HD 5.25" drive.  In this case, then only 2 extra sectors are needed, which would be aesthetically better (IMHO.)  Side 0, Track 0, Sectors 0 & 1 are reserved for the VIB & FDIR.  Add in a reservation (on HD disks,) of Side1, Track 0, Sectors 0 & 1 for extended Map and you have a balanced floppy :)  Sorry, but I think it makes for a nice aesthetic.

 

All of this is moot, however.  As MyArc's HDFC (from what I understand - the only one with HD floppy support,) has already set their standard.  My main reason for bringing this up was for those writing new DSRs for home brew controllers.  As an amateur programmer, I'm not up to writing something that involved or complicated.  My simple menu program is pressing me past my normal limits as it is.  With a mod to make the TIFDC 80 track combined with a MOD to make it DD, the need for a method to handle 2880 sectors is needed.  I'm also thinking that making a double step for a new 40 track format (with the 80 track MOD,) would be better.  Right now, it just formats half the disk.  I'm also wondering if the MOD could be extended to HD disks as well.  But that's a discussion meant for when I track down the development site (if it still exists,) and doesn't really belong here.  Makes for interesting reading, though, as I take a brief break from the project.

 

Back to the project.... I've stepped away from including everything as a single file.  I'm going to either put the font (as well as the basic screens,) in a file on disk to be loaded, or just use the TI's basic font (with my special characters in DATA statements to be copied.)  I still haven't made up my mind.  For now, I'm creating a font/screen file and going to use that.  I may drop it later, though.

 

I'm also trying to design the "help" screen, & still trying to decide if I want to incorporate RLE compression anywhere.  It could, theoretically reduce a 768 byte loading screen data to as low as 12 bytes.  Though it could also double the size - still working on that.  I may also read up on code for more complex lossless compression as well.  My current code is basic simple RLE.  Basically (when decompressing,) if the MSb of the byte read is set, it takes the least significant 7 bits as a count (-1) of how many times the next byte is to be used.  So, 120 spaces would result in >F720.  Where a single space would just be >20.  The problem (with me adding in reverse text,) is that half the characters that could be used would also set the MSb.  So a single reverse space would be >80A0 (>80 for a single run of the following character - >A0.)  Basic, simple, and easy to program, but can end up wasting space as well as saving it.  There are ways of fixing that, though, I just haven't researched them much yet.

 



#175 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,126 posts

Posted Sun Jul 23, 2017 3:53 PM

I haven't ever seen a mod out there to upgrade the TI Disk Controller to DD. The 80-track modification is pretty widespread, but that is pretty much it when it comes to modifications for the TI controllers. I imagine it would be possible to do like the old TRS-80 machines did and couple a WD1773 with the WD1771 that's normally there and then write a DSR that supports the change, but I don't believe anyone has ever taken that step. I have one of the TRS-80 daughter boards in one of my boxes of parts, though it may not be functional, as I've never tried to test it.

 

Note that TI did make a DD controller (prototypes only for the PEB and another for the Hex-Bus, I have one of each), but it used an NEC765, so it is definitely not a way forward for modifying the regular single density card. It used 16 sectors per track, not 18, though that was a DSR-imposed limitation, not a hardware one. Note that early PCs also supported the 16-sector per track format (320K/Disk). TI disk systems also have always treated the entire drive space as a single disk (formatting both sides, when available), and didn't divide them into isolated units.

 

All other DD controllers were third party: CorComp (18 sectors/track in DD, 40 tracks/side), Myarc (16 or 18 sectors/track in DD, 40 or 80 tracks/side), Atronic (18 sectors/track, 40 tracks/side), BwG (by the System99 UG) (18 sectors/strack, 40 tracks/side). There was also one third party single density controller from Percom Data (single-sided, 40 tracks, 9 sectors/track).

 

The Myarc HFDC worked quite well on both the TI-99/4A and on the Geneve (I've used it with both). It would only let you connect two hard disks with R/W capability, with the potential of a Read-only third hard disk. On the floppy drives, it supported single or double density, 16 or 18 sectors/track, and 40 or 80 tracks/side. On the Geneve (and with the right data separator chip), it would also support HD disks. Most cards required replacement of the original data separator to work in HD mode. Note also that this card is different from the regular Myarc floppy controller identified in the third paragraph.

 

Newer options include the CF7+/NanoPEB, which use 1600 sector disk images on a CF card or the HDX that uses the serial port to access disk images on a PC hard drive.







Also tagged with one or more of these keywords: TI-99/4A, Editor/Assembler, Assembly, Extended BASIC, Mini Memory

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users