Kchula-Rrit Posted February 13, 2021 Share Posted February 13, 2021 Are there any gotchas involved in using CALL FILES (>16) subprogram? I think an obvious one would having no files open at the time, lest the table or the files get corrupted. In 1985 I wrote a text editor in Extended BASiC and used CALL FILES (1) to free some memory. I seem to recall seeing something somewhere, back then, that CALL FILES had to be the very first statement (at least in X-BASIC), but cannot find the reference. How about in assembly? I search the forum but did not find anything. K-R. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 13, 2021 Share Posted February 13, 2021 I think CALL FILES (and the subprogram) needs a NEW in BASIC because the pointers have to be reset. This does not work with a program in memory because the tables grow from higher memory locations downward and would need to be moved away. Quote Link to comment Share on other sites More sharing options...
RXB Posted February 13, 2021 Share Posted February 13, 2021 1 hour ago, mizapf said: I think CALL FILES (and the subprogram) needs a NEW in BASIC because the pointers have to be reset. This does not work with a program in memory because the tables grow from higher memory locations downward and would need to be moved away. Yes if you do a BASIC or XB CALL FILES(#) you have to do a NEW after it... unless you use RXB RXB 2020 automatically does a NEW for you after using CALL FILES routine. Also RXB 2020 can do CALL FILES(0) or up to CALL FILES(15) Both not possible in any other Basic or XB, as I wrote a over ride version that takes place before any Disk Controller can do it. See GPL is processed first then ROM/DSR are accessed. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 13, 2021 Share Posted February 13, 2021 2 hours ago, Kchula-Rrit said: Are there any gotchas involved in using CALL FILES (>16) subprogram? . . . How about in assembly? I search the forum but did not find anything. You need to be sure all open files are closed—especially, if you are reducing the number of DSR file buffers. I would be sure all files are closed, anyway. You probably know the rest of this: You also need to ensure that none of the VRAM space your program is using will get trashed if you are increasing the number of file buffers. Each file buffer takes 518 bytes. Subtracting that value from the contents of >8370 for each additional file will reveal the new top-of-VRAM so you can decide the impact on your program before actually running the DSR’s FILES subprogram >016. ...lee 1 Quote Link to comment Share on other sites More sharing options...
Kchula-Rrit Posted February 13, 2021 Author Share Posted February 13, 2021 Thanks for verifying that my memory isn't totally gone, as far as the BASIC/Ex-BASIC is concerned. Didn't know about how Ex-BASIC used the VDP RAM at the time; I just remembered having to do it right away. What about doing >16 Subprogram from an assembly program. Is there anything to watch for, aside from making sure all files are closed before doing the call? K-R. Quote Link to comment Share on other sites More sharing options...
Kchula-Rrit Posted February 13, 2021 Author Share Posted February 13, 2021 2 minutes ago, Lee Stewart said: You need to be sure all open files are closed—especially, if you are reducing the number of DSR file buffers. I would be sure all files are closed, anyway. You probably know the rest of this: You also need to ensure that none of the VRAM space your program is using will get trashed if you are increasing the number of file buffers. Each file buffer takes 518 bytes. Subtracting that value from the contents of >8370 for each additional file will reveal the new top-of-VRAM so you can decide the impact on your program before actually running the DSR’s FILES subprogram >016. ...lee Thanks for answering; your answer showed up as I was "re-asking". I try to use VDP RAM based on the value in >8370, rather than just using, say, >2000->2400 and hoping nothing else walks on it. When I did my batch-loader, I subtracted appropriate amounts from >8370 to allocate VDP RAM for my PABs and buffers, then updated >8370. When the loader finished, I "freed" the VDP RAM by writing the value I saved from >8370 at loader startup. I figured I could: 1. Save the value at >8370 as the "original" top-of-free-space. 2. Do the >16 subprogram. The DSR would allocate VDP RAM and update >8370. 3. This would be my "new" top-of-free-space. 4. At exit, after closing all files, I could do another >16 to re-set FILES back to the default value of 3. This leads to another question. After an assembly program is loaded into RAM, does it start-up with all files closed? Or, does the file from which the program itself loaded remain open, maybe as a link to ...? I think I just answered it; it would make sense to close the program file after loading it. K-R. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted February 13, 2021 Share Posted February 13, 2021 Editor Assembly won't have any open files at the time that it branches into your program. EA5 loaders don't OPEN your file. When the LOAD operation is complete, the controller will not be actively using any VDP sector buffer that was used to facilitate the LOAD. If exit involves resetting the console, then the powerup routines in the console ROM and on the controller cards will reset the VDP stack. I believe they set it to 1 on powerup. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 13, 2021 Share Posted February 13, 2021 (edited) 3 hours ago, Kchula-Rrit said: When I did my batch-loader, I subtracted appropriate amounts from >8370 to allocate VDP RAM for my PABs and buffers, then updated >8370. When the loader finished, I "freed" the VDP RAM by writing the value I saved from >8370 at loader startup. Just as long as any changes to >8370 you make are restored before issuing another call to SP >016. 3 hours ago, Kchula-Rrit said: Save the value at >8370 as the "original" top-of-free-space. Not sure of the need for this. (4) will reset >8370 to that value without help. In fact, the TI floppy DSR will ignore >8370 except to put its new value there upon a call to SP >016. I believe the only time the DSR checks to see what is in >8370 is at power up before it has any file buffer space. As far as the DSR is concerned, >8370 is for the programmer’s benefit. There may be other system checks on that location, but the DSR “knows” what it should be. [EDIT: The TI DSR does, in fact start with the value in >8370 and expects it is immediately prior to the file buffer area. It checks for its CRU there. If it does not find it, it goes to the next top-of-available-VRAM address, which it expects to find stored 2 bytes above the address in >8370. It keeps going, expecting to walk a chain of buffer stacks. I would expect it to go off into the weeds if a wrong address got stuffed in >8370. My test on Classic99 did not and was the reason for my crossed-out explanation. Classic99 must be doing something else. Perhaps, with DSK1 set to “TI controller”, it would be like real iron—I will have to check and also test on real iron.] ...lee Edited February 14, 2021 by Lee Stewart CORRECTION 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 13, 2021 Share Posted February 13, 2021 22 minutes ago, jedimatt42 said: If exit involves resetting the console, then the powerup routines in the console ROM and on the controller cards will reset the VDP stack. I believe they set it to 1 on powerup. If you are talking about the VRAM file buffer stack, the TI DSR powers up with 3 file buffers. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted February 14, 2021 Share Posted February 14, 2021 48 minutes ago, Lee Stewart said: If you are talking about the VRAM file buffer stack, the TI DSR powers up with 3 file buffers. ...lee Thanks for the correction! Made me go re-read my TIPI DSR Panic subsided. I set it to 3 there. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 14, 2021 Share Posted February 14, 2021 @Kchula-Rrit, please note my corrected post #8. Sorry about that! ...lee Quote Link to comment Share on other sites More sharing options...
Kchula-Rrit Posted February 14, 2021 Author Share Posted February 14, 2021 1 hour ago, Lee Stewart said: @Kchula-Rrit, please note my corrected post #8. Sorry about that! ...lee Thanks, I saw that. When I wrote the batch-loader, I made two PABs, one to read the file-list (I called it a "makefile") and one for the TI LOADER routine in low RAM. I took the value at >8370, subtracted >100 and made that the data buffer for the LOADER routine, subtracted another >100 and made that the data buffer for the "makefile". I subtracted >28 (4010) and put the LOADER PAB there. Then I subtracted another >28 and put the "makefile" PAB there. I subtracted 1 and put that value into >8370 to run the batch loader. Here's the VDP memory map: It worked okay in TI994w, haven't tried on my TI yet. Hope it won't go off to the Twilight Zone. Still waiting for some parts to fix my power supply. K-R. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 15, 2021 Share Posted February 15, 2021 On 2/13/2021 at 4:51 PM, Lee Stewart said: Just as long as any changes to >8370 you make are restored before issuing another call to SP >016. Not sure of the need for this. (4) will reset >8370 to that value without help. In fact, the TI floppy DSR will ignore >8370 except to put its new value there upon a call to SP >016. I believe the only time the DSR checks to see what is in >8370 is at power up before it has any file buffer space. As far as the DSR is concerned, >8370 is for the programmer’s benefit. There may be other system checks on that location, but the DSR “knows” what it should be. [EDIT: The TI DSR does, in fact start with the value in >8370 and expects it is immediately prior to the file buffer area. It checks for its CRU there. If it does not find it, it goes to the next top-of-available-VRAM address, which it expects to find stored 2 bytes above the address in >8370. It keeps going, expecting to walk a chain of buffer stacks. I would expect it to go off into the weeds if a wrong address got stuffed in >8370. My test on Classic99 did not and was the reason for my crossed-out explanation. Classic99 must be doing something else. Perhaps, with DSK1 set to “TI controller”, it would be like real iron—I will have to check and also test on real iron.] ...lee Classic99 has its own simulated disk DSR, since the TI disk controller doesn't know how to interact with Windows and the Windows file system. It drops some bits and pieces in memory to be compatible with software that relies on side effects from the TI disk DSR, but no, you can not use the Classic99 DSR to describe the functionality of the TI disk controller. "TI Controller" loads the TI Disk Controller DSR and will use it for the disks you have specified (assuming they are DSK1 through DSK3) - CALL FILES will also be routed to the TI DSR. So THERE you can step into the TI DSR code and it will function the same until it reaches the sector read or write function, which is then trapped and simulated in Classic99. 1 1 Quote Link to comment Share on other sites More sharing options...
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.