Lee Stewart

SAVE does not require OPEN, so it should not require CLOSE. ...lee

I just do the following: CLR @83C4 clear ISR hook BLWP @0 branch to reset vector ...lee

The spoiler below has the working copy of the ALC of the DSRLNK I am editing: I have fixed the FLGPTR issue (never pointing to the PAB flag byte, PAB+1) mentioned in a previous post. I was thinking of changing the use in the routine of the term, “version”, because it has nothing to do with the version of the DSR listed in the second byte at >4001. It has, rather, to do with how many successful matches have been made of the device/subprogram name in the course of finding a routine associated with that name that actually works. That is to say, if a particular routine for, say, DSK1.FILENAME, that runs without error, has a version number of 3, it means that two previous routines with the same name (DSK1) were found, but errored out before this one succeeded. If we cannot find a better descriptor, I will just clarify it in the comments. While we are discussing “version”, I noticed that the code five instructions above NAME1, jumps to NAME2 if the device/subprogram name-length byte (at >8355) is zero. That increments the version number without there having actually been a name match in the DSR. I should think it would be better to send it to LNKERR, where a similar test, at the beginning, sends it. It is probably a moot point, because the name length should never be zero at that spot in the routine. If the byte at >8355 is zero, it will exit the routine at the beginning. It seems to me that the test is superfluous and could be removed. I’ll stop talking now... ...lee

Very nice! I think I can make only one improvement: : RLE? ( byte -- byte len) DUP 80 AND ; Because you are not using its value, you don’t need the 0> because any nonzero value tests true. I am, however, confused about why you used ALIGNED . We’re parsing bytes here, so even addresses should not be a concern, n’est-ce pas? ...lee

I just finished compressing (RLE per @Tursi) FBFONT from 1024 bytes to 700 bytes. I wrote a 58-byte decompression and PDT-loading routine, which together makes 758 bytes going into bank #3 of the fbForth 3.0 cartridge. The first 256 bytes of the font are >FFs , so I could have stored 768 bytes of the remainder of the font and written a 56-byte loading routine that would have loaded those leading >FFs and copied the remainder of the font for a total of 824 bytes—only 66 bytes more. However, I had a lot of fun porting @Tursi’s C program to TMS9900 Assembler to do the RLE compression and, after all, it did save 66 bytes! The ALC payload of the Forth word for doing the RLE compression is in the spoiler: Here is my current fbForth 3.0 TODO list, with bytes-left/bank at the end: fbForth300_TODO.txt ...lee

Yeah, the MG DSRLNK I am currently using uses the GPL version in GROM 0, but I see no way to use either of these for direct, repeat calls to a specific DSR/subprogram. My plan is to provide separate instructions for cassette tape access and to work here on a DSRLNK for ROM (>4000 – >5FFF) access to DSRs/subprograms—unless, of course, there arises a compelling reason to do otherwise. ...lee

FLGPTR is a prime example of what I intend to clarify in this commented code: FLGPTR DATA 0 Pointer to Flag in PAB (Byte 1 in PAB) * ⋮ MOV @SCNAME,R0 Fetch pointer into PAB MOV R0,R9 Save pointer MOV R0,@FLGPTR Save again pointer to PAB+1 * for DSRLNK DATA 8 AI R9,-8 Adjust pointer to flag byte * ⋮ * NOW CHECK IF ANY DSR ERROR OCCURRED LWPI DLNKWS Load back LOADER workspace MOV @FLGPTR,R0 Get back pointer to PAB+1 JMP FRMDSR - 2008.8.15 - Keep on as * - 2008.8.15 - with a Normal DSRLNK As far as I can tell, nowhere is FLGPTR updated to point to the flag byte (PAB+1). It actually, always points to the file-descriptor length byte (PAB+9). The only pointer to the flag byte is R9 in the DSRLNK workspace. In fact the last move above from FLGPTR to R0 cannot possibly work when the branch to FRMDSR is taken. I definitely have work to do! ...lee

The five parameters are SAVCRU DATA 0 CRU Address of the Peripheral SAVENT DATA 0 Entry Address of DSR or Subprogram SAVLEN DATA 0 Device or Subprogram name length SAVPAB DATA 0 Pointer to Device or Subprogram in the PAB SAVVER DATA 0 Version # of DSR from the files in this WHTech directory, which are various versions of Paolo’s DSRLNK routine. Of course, they are also present in the DSRLNK from TI Forth (pretty much identical to the E/A version), but I am not sure if they are actually reused anywhere (I will check). I need to parse one of them very carefully to make more descriptive comments as a starting point for fleshing out what I want to do. With “DSK1.FBLOCKS” as an example, SAVLEN seems to be correctly described in that “DSK1” would have a length of 4. However, SAVPAB appears to point to the position after the ‘.’ following the device name (not relevant for subprogram name), which is the actual filename of “FBLOCKS” following “DSK1.” in my example. Just before the DSR/subprogram is called >8356 also has that filename pointer. I guess that is what the DSR needs for level 3 calls. Of course, it would be irrelevant for level 1 and level 2 calls. I have work to do! ...lee

I have decided to take this DSRLNK discussion out of my fbForth thread so that I can get more non-Forth eyes on it. One of the changes I am seriously considering for fbForth 3.0 is revamping the file management system—especially, how DSRLNK works. I will likely replace the MG DSRLNK currently in place. I am looking into an implementation of Paolo Bagnaresi’s version as modified by Bill R. Sullivan (@Bill R Sullivan & @FDOS). I do not want to include Bill’s optional use of CPU RAM PABs and buffers, but I definitely want to use the 5 saved parameters after the first call to DSRLNK so CRU and device/program searches can be minimized with subsequent DSRLNK calls. Whereas Bill suggests a stack for multiple open files, I am thinking of adding those parameters to the head of each PAB. Though others have addressed some or all of my issues, trying to follow the logic of the various DSRLNKs, especially with some (several?) misleading comments, has been unsettling, to say the least. I am also considering using a linked list of PABs, much as TI Basic does—we’ll see. ...lee

Perhaps I should move this in-depth DSRLNK discussion to its own topic, seeing as how it is almost exclusively ALC (Assembly Language Code) in nature. We would likely get more participation from ALC and DSR experts who may not be that interested in keeping up with our Forth antics. Thoughts? ...lee

FLGPTR is a prime example of what I intend to clarify in this commented code: FLGPTR DATA 0 Pointer to Flag in PAB (Byte 1 in PAB) * ⋮ MOV @SCNAME,R0 Fetch pointer into PAB MOV R0,R9 Save pointer MOV R0,@FLGPTR Save again pointer to PAB+1 * for DSRLNK DATA 8 AI R9,-8 Adjust pointer to flag byte * ⋮ * NOW CHECK IF ANY DSR ERROR OCCURRED LWPI DLNKWS Load back LOADER workspace MOV @FLGPTR,R0 Get back pointer to PAB+1 JMP FRMDSR - 2008.8.15 - Keep on as * - 2008.8.15 - with a Normal DSRLNK As far as I can tell, nowhere is FLGPTR updated to point to the flag byte (PAB+1). It actually, always points to the file-descriptor length byte (PAB+9). The only pointer to the flag byte is R9 in the DSRLNK workspace. In fact the last move above from FLGPTR to R0 cannot possibly work when the branch to FRMDSR is taken. I definitely have work to do! ...lee

The five parameters are SAVCRU DATA 0 CRU Address of the Peripheral SAVENT DATA 0 Entry Address of DSR or Subprogram SAVLEN DATA 0 Device or Subprogram name length SAVPAB DATA 0 Pointer to Device or Subprogram in the PAB SAVVER DATA 0 Version # of DSR from the files in this WHTech directory, which are various versions of Paolo’s DSRLNK routine. Of course, they are also present in the DSRLNK from TI Forth (pretty much identical to the E/A version), but I am not sure if they are actually reused anywhere (I will check). I need to parse one of them very carefully to make more descriptive comments as a starting point for fleshing out what I want to do. With “DSK1.FBLOCKS” as an example, SAVLEN seems to be correctly described in that “DSK1” would have a length of 4. However, SAVPAB appears to point to the position after the ‘.’ following the device name (not relevant for subprogram name), which is the actual filename of “FBLOCKS” following “DSK1.” in my example. Just before the DSR/subprogram is called >8356 also has that filename pointer. I guess that is what the DSR needs for level 3 calls. Of course, it would be irrelevant for level 1 and level 2 calls. I have work to do! ...lee

One of the changes I am seriously considering for fbForth 3.0 is revamping the file management system—especially, how DSRLNK works. I am looking into an implementation of Paolo Bagnaresi’s version as modified by Bill R. Sullivan. I am not sure I want to include Bill’s optional use of CPU RAM PABs and buffers, but I definitely want to use the 5 saved parameters after the first call to DSRLNK so CRU and device/program searches can be minimized with subsequent DSRLNK calls. Whereas Bill suggests a stack for multiple open files, I am thinking of adding those parameters to the head of each PAB. I am also considering using a linked list of PABs, much as TI Basic does—we’ll see. ...lee

You, of course, are welcome to whatever you can use from the VFILL ASL in fbForth101_LowLevelSupport.a99. ...lee

Generally, you want the termination resistor pack on the drive at the physical end of the cable, regardless of its number. ...lee