Pheonix Posted June 6, 2017 Author Share Posted June 6, 2017 Well, I think I have all the bugs worked out. I've relocated the WS to the beginning so that it makes it easier to relocate it on the fly. Everything that could have an address change (including the base program,) is placed in a WS register, even the address of the WS register itself (sitting in R15, with the LWPI command just before it in R14.) I never write to those, so it should be fine that way. I removed the only B (branch,) command and moved the very simple error reporting utility to the middle & changed the "test for error,) jump to test for no error then skip over it Same number of commands, it just avoids the routine if no error instead of going to the routine if there is one. Actually shrank the size a little by replacing direct address with Register referencing. It works for loading normal programs (both even LN address & odd,) and for long format programs. Even ran it multiple times. The last was fixed rather quickly by separating the PAB from the load buffer. I also don't think I can streamline it any further. At least with my current level of knowledge. If anyone else can think of ways to do things with less code, feel free to speak up Going back over my Option 5 loader to see if I can do something similar (Using the WS Registers to build in better relocation abilities.) One thing that simplifies it is the limited VDP space. The PAB & Buffer just don't have that many places they can be located at. A lot of the relocation problems can be greatly simplified if my main program builds the PAB & places it in VDP RAM. Though with the Option 5 & Normal Save BASIC loader, the need for a PAB can be eliminated, as directly accessing the files (to pull out individual blocks at a time instead of loading in 8K increments or all at once for BASIC,) doesn't seem to use it. It uses the FAC instead (from what I've read.) Still reading up on it, it looks promising. Whether I need the PAB or not, the first 2 sections will be removed. The File Descriptor will be provided by the main program & the PAB will be placed by it as well. So those routines for getting it (STRREF,) and putting it in the VDP won't be needed. Nor will the PAB block at the bottom. VDPADR & VDPPAB will also remain equates and I may be able to remove them from the Registers. They are used so often, though, that maybe I can just leave them be (smaller code by using registers instead of directly referencing (moving from register to register is 2 bytes, while immediate mode takes 4.) The latest (and hopefully final,) stand alone loader code: DEF ALOAD AORG >2600 COPY "XB-EQUATES" COPY "DSR-GPL;S" VDPADR EQU >1000 VDPPAB EQU >0EF7 ELNTBL EQU >8330 BLNTBL EQU >8332 EBASIC EQU >FFE7 RBASIC EQU >64BD FNPTR EQU >8356 LSTPRT EQU >8345 ALDWS BSS 18 DATA VDPPAB+9 * R9 DATA VDPPAB * R10 DATA VDPADR * R11 DATA DSRLNK * R12 DATA GPLLNK * R13 ALOAD LWPI ALDWS * DOUBLES AS R14 & R15 BUT NEVER ALTERED LIMI 0 CLR R0 SETO R1 MOVB R1,@PAB+9 INCT R1 LI R2,PAB+9 BLWP @STRREF * READ FILE DESCRIPTOR FROM CALL MOVB @PAB+9,R2 * GET DESCRIPTOR LENGTH SRL R2,8 AI R2,10 * ADD BASE SIZE OF PAB TO MOV R10,R0 LI R1,PAB BLWP @VMBW * COPY PAB TO VDP MOV R9,@FNPTR BLWP *R12 DATA 8 * GET FILE STATUS (FOR FILE TYPE) ANDI R0,>FF00 * PUTS ERROR IN MSB OF R0 JNE CHKERR MOV R9,R0 DEC R0 BLWP @VSBR * READ STATUS BYTE SRL R1,8 ANDI R1,>14 MOV R1,R8 * STORE FOR FUTURE USE CLR R1 MOV R8,R8 JNE LONGF1 * DATA FILE, LOAD XB LONG FILE LI R1,>0500 * SET FOR LOAD LONGF1 MOV R10,R0 BLWP @VSBW * SET ACCESS 0=OPEN, 5=LOAD MOV R9,@FNPTR BLWP *R12 DATA 8 * LOADS FILE / OPENS FILE JEQ CHKERR ANDI R0,>FF00 * DSRLNK PUTS ERROR CODE IN MSB OF R0 JNE CHKERR MOV R8,R8 JEQ NORMF1 * PROGRAM FILE, ALREADY LOADED MOV R10,R0 LI R1,>0200 BLWP @VSBW * PUTS 2 (READ) MOV R9,@FNPTR BLWP *R12 DATA 8 NORMF1 MOV R11,R0 MOV R15,R1 * R15 IS WS ADDRESS AI R1,6 * SETS R3-R7 AS DESTINATION LI R2,10 BLWP @VMBR * READS FIRST 5 WORDS MOV R8,R8 JEQ NORMF2 CI R3,>ABCD * MAKE SURE IT IS XB LONG JNE CHKERR MOV R6,R3 MOV R7,R6 MOV R4,R7 MOV R5,R4 * REGISTER ASSIGNMENTS MATCH MOV R7,R5 * (FASTER WAY??) NORMF2 MOVB @LSTPRT,R7 ANDI R7,>7F00 *TURN OFF LIST PROTECTION IF ON MOV R4,R0 XOR R5,R0 C R0,R3 * SEE IF CHECK WORD MATCHES JEQ MATCH NEG R0 C R0,R3 * SEE IF LIST PROTECTED JEQ LISTP1 CHKERR MOV R10,@>831C * MOVED HERE BECAUSE OUT OF RANGE LI R0,ERRIO * OF EVERYWHERE THAT USED IT BLWP @ERR LISTP1 ORI R7,>8000 * TURN ON LIST PROTECTION MATCH MOVB R7,@LSTPRT * SET LIST PROTECTION ON/OFF MOV R8,R8 JNE LONGF2 MOV R6,R2 S R5,R2 * CALCULATE TOTAL SIZE INC R2 * INCREASE TO INCLUDE TRAILING NULL BYTE LI R7,EBASIC S R6,R7 * CALCULATE DIFFERENTIAL IF EXISTS A R7,R4 A R7,R5 * ADJUST ADDRESSES LONGF2 MOV R5,@ELNTBL MOV R4,@BLNTBL * STORE LINE NUMBER TABLE POINTERS MOV R8,R8 JEQ NORMF3 * GO TO NORMAL MODE, JUST NEEDS TRANSFERED RDLOOP MOV R9,@FNPTR BLWP *R12 DATA 8 * READ RECORD MOV R10,R0 AI R0,5 BLWP @VSBR * GET RECORD LENGTH SRL R1,8 MOV R1,R2 MOV R5,R1 * CURRENT DESTINATION ADDRESS A R2,R5 * CHANGE TO NEXT DESTINATION MOV R11,R0 BLWP @VMBR * COPY FROM VDP TO RAM C R5,R6 JLE RDLOOP MOV R10,R0 CLR R1 INC R1 BLWP @VSBW * SET FOR CLOSE MOV R9,@FNPTR BLWP *R12 DATA 8 * CLOSE FILE JMP RUNIT NORMF3 MOV R11,R0 AI R0,8 MOV R5,R1 * DESTINATION BLWP @VMBR * COPY FROM VDP TO RAM ADLOOP MOVB *R4,R0 DEC R4 SWPB R0 MOVB *R4,R0 A R7,R0 * UPDATE TABLE VALUES MOVB R0,*R4+ SWPB R0 MOVB R0,*R4 DECT R4 DECT R4 * MOVE TO NEXT VALUE C R4,R5 JH ADLOOP RUNIT BLWP *R13 DATA RBASIC PAB DATA >091C DATA VDPADR DATA >FE00 DATA >2E40 * >2E40 SIZE W/32K EXPANSION DATA >00FF END Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 9, 2017 Author Share Posted June 9, 2017 Well... Now working on a staggered load system. This requires Direct File Access (DSRLNK subroutine 014 in the book.) Web searches and referencing the E/A manual allowed me to get snippets of instructions from multiple places. No single source seemed to include clear instructions or examples. I found one place that had an example, but didn't include the important piece. that is, it had references to "where" to place certain pieces, and even placed them, but when it came time to do "BLWP @DSRLNK" they instead did "BL @FILE" with no reference whatsoever to the label "FILE" anywhere I could find. Rather frustrating From what I worked out, my current code: COPY "DSK1.XB-EQUATES" VDPCML EQU >3800 * BYTE (>01) VDPCMD EQU VDPCML+1 * BYTE (>14) VFNAME EQU VDPCML+2 * 10 BYTES VDPADR EQU VDPCML+12 * 8 BYTES (NORMALLY INCLUDES BELOW) VDPAD1 EQU VDPCML+20 * 248 BYTES FTBLK EQU FAC+2 DEVNUM EQU FTBLK * BYTE AUREAD EQU FTBLK+1 * BYTE FNPTR EQU FTBLK+2 * WORD (IN VDP?) AIBPTR EQU FTBLK+4 * BYTE ADINFO EQU >A000 AIVADR EQU ADINFO * WORD AIFAU EQU ADINFO+2 * WORD AISTS EQU ADINFO+4 * BYTE AIRPAU EQU ADINFO+5 * BYTE AIEOF EQU ADINFO+6 * BYTE AILRS EQU ADINFO+7 * BYTE AIRCDS EQU ADINFO+8 * WORD FNBLEN EQU ADINFO+10 * FNBUFF EQU ADINFO+11 LBNWS BSS 32 SLOAD LWPI LBNWS LIMI 0 CLR R0 CLR R1 INCT R1 BLWP @NUMREF * GET DEVICE NUMBER BLWP @XMLLNK DATA CFI MOV @FAC,R5 DEC R1 LI R2,ADINFO+1 LI R3,>0A00 MOVB R3,*R2 BLWP @STRREF * GET FILE NAME MOVB *R2+,R4 SRL R4,8 A R4,R2 SWPB R3 S R4,R3 LI R4,>2000 SPCLP MOVB R4,*R2+ DEC R3 JNE SPCLP * PAD WITH >20 (SPACE) LI R0,VDPCML MOV R0,R9 LI R1,ADINFO LI R2,>0114 MOV R2,*R1 LI R2,12 BLWP @VMBW * COPY COMMAND & FILE NAME TO VPD LI R0,ADINFO LI R1,00 LI R2,5 NTEST MOV R1,*R0+ DEC R2 JNE NTEST SLA R5,8 MOV R5,@FTBLK LI R2,VFNAME MOV R2,@FNPTR LI R1,>A000 MOV R1,@AIBPTR MOV R1,@>83A0 * NOT SURE IF ADDITIONAL INFO POINTER IS 1 BYTE FOR >83?? LI R0,VDPADR MOV R0,@AIVADR * FILL FAC+2 ONWARDS MOV R9,@DSRPTR BLWP @DSRLNK DATA >A LWPI GPLWS CLR @STATUS B @RTNPTR Overly complicated, I'm sure, and it doesn't do anything yet, but I cannot get past getting anything except an error byte in >8350 (07). I've confirmed that I'm getting & setting the correct device number (still haven't worked out if there is a way to do this with sub-directories or hard drives.) The file name & it's pointer are going in the right places, and are the correct values. I've moved the file name to both CPU & VDP RAM (though what I'm reading suggests it needs to be in VDP,) without any change. I even set the Additional Info Block to >8300 as in the example I found. All to no avail Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 10, 2017 Share Posted June 10, 2017 ... Overly complicated, I'm sure, and it doesn't do anything yet, but I cannot get past getting anything except an error byte in >8350 (07). I've confirmed that I'm getting & setting the correct device number (still haven't worked out if there is a way to do this with sub-directories or hard drives.) The file name & it's pointer are going in the right places, and are the correct values. I've moved the file name to both CPU & VDP RAM (though what I'm reading suggests it needs to be in VDP,) without any change. I even set the Additional Info Block to >8300 as in the example I found. All to no avail I have not looked at every detail, but one thing wrong is that the Additional Information Block (AIB) pointer is a byte—not a word. It needs to point to an address in PAD RAM by containing the LSB of the address. The DSR supplies the MSB (>83). I use ARG (>835C) for the AIB by putting >5C in the AIB pointer byte at >8350. ...lee Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 10, 2017 Author Share Posted June 10, 2017 I think I mentioned that I thought it was, but was trying alternatives in case I was wrong. I had originally followed an example I found as closely as possible. They used >8300 for the Additional Info Block, putting >00 in >8350. So that's what I did first. It's from that example that it looked like the File Name Pointer needed to reference VDP RAM and not CPU RAM. I double used the AIB for buffering that as well, though I did try creating my own buffer when that didn't work. In VDP RAM, I put >01 >14 (the length of 1 byte followed by the subroutine I'm wanting to access >14.) That is followed by 10 bytes for the File Name padded with spaces (>20,) as instructed by the book. I put the following in FAC starting at FAC+2 (>834C,) >01 (device #, though that is an argument passed by CALL LINK, I confirmed it gets placed correctly,) >00 (# of AU's to read, or get File Specifics if = 0,) VDP RAM address of the File Name (2 Bytes,) then >00 (for >8300, though tried >A000 - and checked both >83A0 & >A000, and now >5C for >835C.) I've confirmed that the VDP RAM addresses contain what they are supposed to contain and addresses >834C - >8350 are all correct at this point. I then place the VDP Address of the >0114 subroutine length & name into >8356 as instructed and do "BLWP @DSRLNK" followed by "DATA >A" or "DATA 10" (tried both.) At this point >8350 contains (>07 - Error 7, , from what I've read,) the AIB is completely unchanged (Both with & without the VDP RAM Buffer Address in the first word.) >834C becomes >0000 instead of >0100, >834A becomes >14 (was >00, though I never touch it.) From what I've read, nothing is said about the FAC (other than the error code will be placed in >8350,) and the AIB should be >380C (placing it in the upper 2K to avoid interference with bitmap graphics,) >002C (44 AUs of the current test file,) >01 (PROGRAM, though I got this from TI Image Tool, the book said different,) >00 (again from TI Image Tool,) >8E (EOF offset of final AU,) >00 (from TI Image Tool,) >0000 (TI Image Tool.) What I get is no change (all >00 except first word of >380C which I set, or >0000 when I tried not setting it.) Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 10, 2017 Share Posted June 10, 2017 There are a few sources of information that may help: 1. the latter portion of the Myarc Hard and Floppy disk controller manual contains information about the common subprograms. Fred's site also contains information about the various subprograms. 2. the pinned development resource thread, section 3, for the DSR and disk management specifications. Specifically, review the GPL Interface specification. It is not necessary to place the filename after the "PAB" >0114; they don't need to be contiguous. They do need to be copied into VDP RAM. The additional info block will always be found in PAD ram along with the transferred parameters. You cannot place the AIB in CPU RAM (i.e., >380C); a good place for it is 8300 provided neither your program workspace nor your DSRLNK workspace overlap. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 10, 2017 Author Share Posted June 10, 2017 I know they don't need to be contiguous, it's just handier that way. I build them both as one block & transfer it all at once. I've been working on this for a week now, and I must be making a mistake somewhere. It will probably turn out to be something absurdly simple when its found, that's the way it usually turns out. When it's up and running, and streamlined, it will be converted for relocation (though not all that necessary for BASIC programs from what I understand.) When that is done, the main program will set up the PAB and such before transferring control to the loader. At that point, the main program is never accessed again (probably going to be written over in some cases.) So, all the loader needs is pointers to important bits (Device #, File Name, & Sub-Routine Bytes in this case.) As well as the BLWP links for DSRLNK & GPLLNK. Think I'm going to scrap what I currently have and start from scratch again. Maybe I can avoid whatever mistake I'm making this time around. Would feel better, though, if I could actually track down the exact issue. I actually got the GPL links from the development resource thread. It's what gave me the idea for a partial load system (loading in one block at a time, instead of the entire program at once.) I'm starting to reconsider that in favor of 2 other options. Simplest would be to just give up and make the loading screen normal mode (limited color/graphics etc...) The more complex would be to look into direct disk access instead. Track/sector/head reads instead of file blocks (AUs.) Still trying to do this using something that comes in ROM/GROM as that should be compatible between different controllers. The direct disk access may actually be more compatible with sub-directories and HDD's as well, though I cannot speak to that as yet. Would like to get this up and running, then worry about that later. In all honesty, most of my programming experience is with C++ on the PC (mostly DOS, an extremely small amount of Windows,) and.... grrr... memory fails, it was a 16 bit system from the 90's but can't remember now wasn't the Amiga, actually don't have "any" programming experience on the Amiga. I only worked in assembly on the 6502 systems (C64 & Apple II primarily.) Didn't even have an assembler for the C64 originally, long hours (after writing the code,) looking up OP codes and typing them in manually. Fun days.... Calculating branch values, without a firm grasp of signed numbers, was rather fun as well. I never looked into the Myarc manuals, mainly because I'm first focusing on what I have, a standard TI PHP???? (still packed away, had to cancel the desk I was originally going to get for it,) controller and whatever the floppy drive is. Probably just the standard SSSD drive. I'm not even 100% sure what the controller is capable of, I think it's DSSD only. Not a lot of space on either of those. But I'm planning to eventually get a better controller, and drives. Maybe even a HDD. So I'd sort of like to have the functionality available when the time comes. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 10, 2017 Author Share Posted June 10, 2017 I do have a quick side question that is sort of bugging me The manual says, to return from an assembly program back to basic: "LWPI @>83E0" (GPLWS,) "CLR @>837C" (STATUS,) & "B *R11" (alternately "RT" which is the same, according to the manual.) Here, I've been told to end with "B >006A" instead. Some of my programs work fine with the "RT" option, and some don't. I'm sort of curious what is up with that? Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 10, 2017 Author Share Posted June 10, 2017 OK, rewrote code from scratch. This is extremely close to what I originally wrote (except I'm not reusing the >8300 range as both the VDP Buffer & the AIB.) the code: DEF SLOAD AORG >2600 COPY "DSK1.XB-EQUATES" DSRCMD EQU >3800 VFNAME EQU >3802 VDPADR EQU >380C ADINBL EQU >8300 FNPTR EQU >8356 LBNWS BSS 18 DATA >0001 * R9 DATA VDPADR * R10 (BY SETTING THESE HERE, MAIN PROGRAM) DATA DSRCMD * R11 (CAN ALTER TO CORRECT VALUES EASIER) DATA DSRLNK * R12 DATA GPLLNK * R13 SLOAD LWPI LBNWS LIMI 0 * FIRST SECTION ONLY FOR TEST CODE CLR R0 MOVB @NUMARG,R1 SRL R1,8 JEQ BADARG CI R1,2 JNE BADARG BLWP @NUMREF BLWP @XMLLNK DATA CFI MOV @FAC,R9 JEQ BADARG CI R9,3 JH BADARG * READ DEVICE NUMBER WITH LIMITATIONS FROM BOOK DEC R1 LI R2,DCBUF+1 LI R3,>0A00 MOVB R3,*R2 BLWP @STRREF * READ IN FILE NAME SWPB R3 MOVB *R2+,R1 SRL R1,8 A R1,R2 S R1,R3 LI R0,>2000 PADNAM MOVB *R2+,R0 DEC R3 JNE PADNAM * PAD FILE NAME WITH SPACES (>20) LI R0,>0114 MOV R0,@DCBUF * REPLACE THE >0114 FOR DSRLNK SUBROUTINE MOV R11,R0 LI R1,DCBUF LI R2,>0C BLWP @VMBW * COPY TO VDP RAM * END OF FIRST SECTION * MAIN PROGRAM WILL DO ALL THIS BEFORE BRANCHING HERE SWPB R9 * R9 NOW SET TO >0?00 (DEVICE # & TRANSFER FILE PARAMETERS MOV R11,R8 INCT R8 LI R7,ADINBL SWPB R7 * MSB IS NOW LSB OF ADITIONAL INFO BLOCK ADDRESS LI R0,FAC+2 MOV R9,*R0+ MOV R8,*R0+ * POINTER TO FILE NAME IN VDP RAM MOVB R7,*R0 * >834C->8350 NOW SET CORRECTLY I THINGK SWPB R7 * SWAP IT BACK LI R0,VDPADR MOV R0,*R7 * SET FIRST WORD OF AIB TO VDP RAM BUFFER MOV R11,@FNPTR BLWP @DSRLNK DATA 10 LWPI GPLWS CLR @STATUS B @RTNPTR BADARG LI R0,ERRBA JMP SETERR SETERR BLWP @ERR COPY "DSK1.DSR-GPL;S" DCBUF DATA >010A * SECOND BYTE DOUBLES AS FILE NAME LENGTH FNAME DATA >2020,>2020,>2020,>2020,>2020 END Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 10, 2017 Share Posted June 10, 2017 You are using VRAM starting at >3800 for buffering. I could not find where you might have reduced the maximum number of simultaneously open files from the default of 3; but, if you have not done so, any VRAM address above >37D7 (for the TI and CorComp disk controllers) will trash the disk buffer area. You can check >8370 for the highest available VRAM address. ...lee Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 10, 2017 Share Posted June 10, 2017 I never looked into the Myarc manuals, mainly because I'm first focusing on what I have, a standard TI PHP???? (still packed away, had to cancel the desk I was originally going to get for it,) controller and whatever the floppy drive is. Probably just the standard SSSD drive. I'm not even 100% sure what the controller is capable of, I think it's DSSD only. Not a lot of space on either of those. But I'm planning to eventually get a better controller, and drives. Maybe even a HDD. So I'd sort of like to have the functionality available when the time comes. Yea, I only mentioned The Myarc manual because it is one of the few resources that contains information about the use of the subroutines. The GPL Specification contains most of what you need for you current scope. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 10, 2017 Author Share Posted June 10, 2017 You are using VRAM starting at >3800 for buffering. I could not find where you might have reduced the maximum number of simultaneously open files from the default of 3; but, if you have not done so, any VRAM address above >37D7 (for the TI and CorComp disk controllers) will trash the disk buffer area. You can check >8370 for the highest available VRAM address. ...lee Well, I would guess that that tells me where the >37D7 comes from when I was studying saved basic programs Is that where a BASIC program would normally end in a TI without the 32K RAM expansion? I don't remember seeing any mention of that address when I was looking for memory maps of VDP RAM. I'll have to look into it again. For partial loading, I could move the VDP RAM usage to >1B00 instead. Though my problem still exists with it there. Just did another search, and the closest I came to a memory map of VDP RAM is the page that detailed the different screen modes, and it mostly limited itself to the effects that VDP registers have, and a bit about where the TI puts things with the different register values. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 10, 2017 Share Posted June 10, 2017 Back in the days, TI bragged about that since every peripheral has its own DSR in ROM, accessories didn't need any of your valuable RAM. But that's not 100% true, since the disk controller does need file buffers. These are allocated in VDP RAM, as that's the only RAM all machines have. When using BASIC, you can set up the system to allow from one to nine files open simultaneously. The more you want, the more memory will be used. The CALL FILES(x) command is used for this. Default is CALL FILES(3). Thus the beginning of the buffers for three files is the most common end of available VDP RAM. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted June 10, 2017 Share Posted June 10, 2017 Yeah, and as an aside, the FILES call seems to fail with the emulated FDC on the Cf7 and NanoPEB. That breaks a lot of bitmap programs. Why TI set the default to 3 and not 1 I'll never know... Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 10, 2017 Share Posted June 10, 2017 Because they thought it was reasonable that you at least wanted to read from one file, do processing and store in another at the same time, maybe? Not too rarely do you also need to reference something else, or have a temporary file open for storage, while doing the work you are doing. I don't know, I'm just guessing. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 10, 2017 Share Posted June 10, 2017 Back in the days, TI bragged about that since every peripheral has its own DSR in ROM, accessories didn't need any of your valuable RAM. But that's not 100% true, since the disk controller does need file buffers. These are allocated in VDP RAM, as that's the only RAM all machines have. When using BASIC, you can set up the system to allow from one to nine files open simultaneously. The more you want, the more memory will be used. The CALL FILES(x) command is used for this. Default is CALL FILES(3). Thus the beginning of the buffers for three files is the most common end of available VDP RAM. To just point out how I saw this as a problem RXB allows you to do more: CALL FILES(0) ! RXB 2017 will include this feature for maximum VDP space to XB. or CALL FILES(15) As per RXB documents: Not recommended but possible now. Quote Link to comment Share on other sites More sharing options...
Casey Posted June 11, 2017 Share Posted June 11, 2017 Yeah, and as an aside, the FILES call seems to fail with the emulated FDC on the Cf7 and NanoPEB. That breaks a lot of bitmap programs. Why TI set the default to 3 and not 1 I'll never know.. It wasn't just TI that did that. Apple DOS 3.3 also defaulted to 3 files by default, as did Atari DOS (at least 2.5). It must have just been the number people thought would be enough normally. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted June 11, 2017 Share Posted June 11, 2017 Other than disk management software though, I don't know many programs that keep multiple files open. It's a dangerous thing to do. All my programming, I only use one file at a time. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 11, 2017 Author Share Posted June 11, 2017 I cannot "currently" seeing a need for my main program to keep more than 2 files open. One of which will be the catalog "file", and only in the editor section (while it's going through the catalog allowing me to select which files to add to the menu on that disk. I'm currently working on the idea of using a relative file for the menu info file. But am not sure how the final product will function. The current idea is to leave the info file open as I scroll through, so that I'm not filling up a buffer with the file, Just reading each entry as needed. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 11, 2017 Share Posted June 11, 2017 Yeah, and as an aside, the FILES call seems to fail with the emulated FDC on the Cf7 and NanoPEB. That breaks a lot of bitmap programs. Why TI set the default to 3 and not 1 I'll never know... ???? What do you mean by “seems to fail with the emulated FDC on the Cf7 and NanoPEB”? The same command works quite well in fbForth 2.0. I am pretty sure I have used it in XB, as well, but I need to check. ...lee Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 11, 2017 Share Posted June 11, 2017 Not to stray off topic, but why would having more than one open file be dangerous? I often have two or three files open at the same time. I suppose if you aren't closing files properly you could lose data, but the DSRs are all fairly hardened against trouble when used properly. Quote Link to comment Share on other sites More sharing options...
Pheonix Posted June 11, 2017 Author Share Posted June 11, 2017 Well, it looks like it might be the emulator itself (Classic99 for the debugger,) that is at fault. Can't pull up a debugger, but having the program itself supply the error code results in no error code when using Win994a. Really wish there was a good emulator that I liked. Managed to get MAME up, and it didn't produce an error code at >8350, but the numbers at >835C didn't make a lot of sense. The Results: VDP Buffer start Address: >4690 (was >1B0C) Total # of AU's for file: >3EE9 (16105???? OK, that's more than the .DSK image holds. Should be >2C) Status Flags: >83 (8 - PROGRAM file is correct, though, but ASCII? VARIABLE? & a "reserved" bit is set) Records per AU: >F6 (246) EOF offset: >83 (Should be >68) Logical Record Size: >E0 # of L3 Records Allocated: >8C02 Going to have to build it to pull all that data & display it in Win994a to see how that looks. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 11, 2017 Share Posted June 11, 2017 Well, I would guess that that tells me where the >37D7 comes from when I was studying saved basic programs Is that where a BASIC program would normally end in a TI without the 32K RAM expansion? I don't remember seeing any mention of that address when I was looking for memory maps of VDP RAM. I'll have to look into it again. For partial loading, I could move the VDP RAM usage to >1B00 instead. Though my problem still exists with it there. Just did another search, and the closest I came to a memory map of VDP RAM is the page that detailed the different screen modes, and it mostly limited itself to the effects that VDP registers have, and a bit about where the TI puts things with the different register values. You can change the top and bottom location of VDP in scratch pad that keeps track, thus make a place in VDP that will be ignore and remain unmolested by the OS. My normal location is RXB is >1000 as this is the last address in VDP that XB ever will touch as it starts at >37D7 and goes smaller til at last reaching >1000 in VDP. >0958 is the VDP VALUE STACK reaches up to >09FF at most. In XB you can also do a XML COMPCT that is a VDP garbage collection of VDP RAM. i.e. XML >70 * Is garbage collection in XB ROMs. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 11, 2017 Share Posted June 11, 2017 (edited) Well, it looks like it might be the emulator itself (Classic99 for the debugger,) that is at fault. Can't pull up a debugger, but having the program itself supply the error code results in no error code when using Win994a. Really wish there was a good emulator that I liked. Managed to get MAME up, and it didn't produce an error code at >8350, but the numbers at >835C didn't make a lot of sense. The Results: VDP Buffer start Address: >4690 (was >1B0C) Total # of AU's for file: >3EE9 (16105???? OK, that's more than the .DSK image holds. Should be >2C) Status Flags: >83 (8 - PROGRAM file is correct, though, but ASCII? VARIABLE? & a "reserved" bit is set) Records per AU: >F6 (246) EOF offset: >83 (Should be >68) Logical Record Size: >E0 # of L3 Records Allocated: >8C02 Going to have to build it to pull all that data & display it in Win994a to see how that looks. Hmm VDP RAM is from >0000 to >3FFF so how the hell could you use >4690 as a valid VDP ADDRESS for a buffer? This looks like a wrap around problem and you are actually using >0690 as a buffer address! Edited June 11, 2017 by RXB 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 11, 2017 Share Posted June 11, 2017 Well, it looks like it might be the emulator itself (Classic99 for the debugger,) that is at fault. Can't pull up a debugger, but having the program itself supply the error code results in no error code when using Win994a. Really wish there was a good emulator that I liked. Managed to get MAME up, and it didn't produce an error code at >8350, but the numbers at >835C didn't make a lot of sense. I've worked pretty hard on the disk error handling in Classic99 -- what exactly were you trying to do? The debugger is launched from the menu - Edit->Debugger... Also, any disk error is explained in the debug log, to further aid understanding why a disk error occurred. Finally, when debugging disk access routines, you can configure a disk for disk image emulation, exit the emulator, and then edit the Classic99.ini. Change the disk type from 2 to 3, and it will run the actual TI disk controller ROM. That eliminates any differences from my internal DSR. Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 11, 2017 Share Posted June 11, 2017 Yeah, and as an aside, the FILES call seems to fail with the emulated FDC on the Cf7 and NanoPEB. That breaks a lot of bitmap programs. Why TI set the default to 3 and not 1 I'll never know... It works okay on my device (the one with the parallel port, I never remember which is CF7 and which is NanoPeb). I've run and tested all of my bitmap mode applications on it, and they would bomb out horribly if it didn't work. Mind you, my code does it's own subprogram search, I don't use the E/A DSRLNK, but you could test it pretty quick from TI BASIC with the E/A cart installed -- use CALL PEEK to read out the values at >8370, issue a CALL FILES(1), then repeat and ensure they changed. When I test here in Classic99 I get this: The numbers will differ slightly on the CF device since they allocate 6 extra bytes. 1 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.