Tursi Posted July 9, 2017 Share Posted July 9, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 10, 2017 Author Share Posted July 10, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 10, 2017 Share Posted July 10, 2017 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.com/software/scratchpad-- this copy's for XB but all the source is in there. 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 10, 2017 Author Share Posted July 10, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 17, 2017 Author Share Posted July 17, 2017 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 17, 2017 Share Posted July 17, 2017 (edited) 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: // return bits for the STATUS command (saved in Screen Offset byte) #define STATUS_NOSUCHFILE 0x80 #define STATUS_PROTECTED 0x40 #define STATUS_INTERNAL 0x10 #define STATUS_PROGRAM 0x08 #define STATUS_VARIABLE 0x04 #define STATUS_DISKFULL 0x02 #define STATUS_EOF 0x01 // get file status - we get this for the most part from the header! bool BaseDisk::Status(FileInfo *pFile) { pFile->ScreenOffset = 0; // Currently we only return some of the bits (See STATUS_ enum) // Is it too hard to use ONE set of flags? if (pFile->FileType & TIFILES_VARIABLE) pFile->ScreenOffset|=STATUS_VARIABLE; if (pFile->FileType & TIFILES_INTERNAL) pFile->ScreenOffset|=STATUS_INTERNAL; if (pFile->FileType & TIFILES_PROGRAM) pFile->ScreenOffset|=STATUS_PROGRAM; if (pFile->nCurrentRecord >= pFile->NumberRecords) pFile->ScreenOffset|=STATUS_EOF; // not supported: //#define STATUS_PROTECTED 0x40 //#define STATUS_DISKFULL 0x02 // handled elsewhere: //#define STATUS_NOSUCHFILE 0x80 return true; } 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 July 17, 2017 by Tursi Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 17, 2017 Share Posted July 17, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 18, 2017 Author Share Posted July 18, 2017 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 TEST.zip Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 18, 2017 Author Share Posted July 18, 2017 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.") Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 18, 2017 Share Posted July 18, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 20, 2017 Author Share Posted July 20, 2017 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 20, 2017 Share Posted July 20, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 20, 2017 Author Share Posted July 20, 2017 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 21, 2017 Share Posted July 21, 2017 (edited) 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 July 21, 2017 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 21, 2017 Author Share Posted July 21, 2017 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 21, 2017 Share Posted July 21, 2017 ... 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 21, 2017 Share Posted July 21, 2017 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. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 22, 2017 Author Share Posted July 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 22, 2017 Share Posted July 22, 2017 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...) Quote Link to comment Share on other sites More sharing options...
RXB Posted July 22, 2017 Share Posted July 22, 2017 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? Quote Link to comment Share on other sites More sharing options...
apersson850 Posted July 23, 2017 Share Posted July 23, 2017 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. Quote Link to comment Share on other sites More sharing options...
TheTIGuy Posted July 23, 2017 Share Posted July 23, 2017 Know nothing of assembly, just wanted to post mt 1st HTML code ever, please remove if inappropriate. My First.htm Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 23, 2017 Share Posted July 23, 2017 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. 4 Quote Link to comment Share on other sites More sharing options...
Pheonix Posted July 23, 2017 Author Share Posted July 23, 2017 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. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 23, 2017 Share Posted July 23, 2017 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. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.