Willsy Posted September 9, 2013 Share Posted September 9, 2013 Ah! Yes! I see what you're saying now - der!!!! I'm so dumb!! I'll fix that tonight! Good spot, Lee! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 9, 2013 Author Share Posted September 9, 2013 Ah! Yes! I see what you're saying now - der!!!! I'm so dumb!! I'll fix that tonight! Good spot, Lee! Nah—just blind to your own code. Don't be so hard on yourself. The most elusive mistakes for me to find are the ones I know I didn't make! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2013 Author Share Posted September 12, 2013 Almost there with fbForth v 0.92! I have the ALC for level 3 block I/O fleshed out. I have a few high-level bits of Forth code to clean up. Then, it's on to testing and debugging. There will be bugs—I just hope there aren't an intractable number of them! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2013 Author Share Posted September 12, 2013 I'm working on COLD —it's a little more involved, now that I'm using a movable system area in VRAM. If COLD finds the system in bitmap mode, it must move the system area before resetting to text mode and then reload both true lowercase from the moved system area and uppercase from console GROM. Or—I could just assume that the user knows to run COLD from text mode with the default blocks file in use and simply do the minimal resets. I think that's how TI Forth does it. If I do the former, the code is gonna bloat. I could warn the user that the system needs to be in text mode with the default blocks file before executing COLD . As usual, I'm torn!—and, once again, likely talking to myself... ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2013 Author Share Posted September 12, 2013 Yup—just checked TI Forth—it really doesn't do a COLD start very well in any mode but text. The manual doesn't tell you this, either—not even my expanded 2nd edition! I think I will do the same with fbForth, except that I will warn the user in the manual. After all, I'm not writing a new Forth. My intention all along was to improve TI Forth only to the extent of changing Forth screen/block I/O to file I/O instead of director sector I/O, only changing what I absolutely was forced to change to make it work. I did add a few improvements; but, I don't want to get carried away! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2013 Author Share Posted September 12, 2013 What do you think about simply exiting fbForth if COLD is executed in a mode other than text? I can have fbForth discover whether it is in text mode by checking the fbForth user variable VDPMDE (1 = text mode) or the RAM-scratchpad byte at location 83D4h (value that gets copied to VDP write-only register 1 after every keystroke; bit 3 [from left] = 1 for text mode). Barring objections, I think I have a plan! ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 12, 2013 Share Posted September 12, 2013 Do you not have a word like GMODE which sets up the appropriate graphics mode? I don't understand why COLD can't just call a word that selects 40 column mode? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2013 Author Share Posted September 12, 2013 Nope—I think the user caveat in the manual should be enough! I shouldn't make COLD too intelligent. It's also the first thing that fbForth executes after it gets control. VDPMDE is initialized by COLD to 1 (text mode) at that point, so I would need to check the bit in 83D4h that was set before fbForth gained control to avoid subverting the startup code. I think I'll leave it alone. If the system goes south, the user will reset the system. I'm glad we had this little talk. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2013 Author Share Posted September 12, 2013 Do you not have a word like GMODE which sets up the appropriate graphics mode? I don't understand why COLD can't just call a word that selects 40 column mode? It's complicated. Changing modes is in the optional system blocks and takes a fair amount of code. I will likely put it into the cartridge when I get to that point—but, here it's simpler not to bloat the code any more than necessary, I think. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 14, 2013 Author Share Posted September 14, 2013 As you all know, debugging is usually painful—especially if a lot of code is changed all at once. A lot of what I changed required modifying a lot of code before I could actually try it; but, now it's very painful! I have most of the low-level block I/O working. The really painful task, now, is tracking back through the high-level Forth code I needed to change to find the bugs. Of course, I made it harder on myself because I didn't resist the urge to revise code that could have waited! Oh, well... I'm having the most difficulty with two things: High-level Forth code in the ALC is not nearly as intuitive as it is in Forth source. Tracking Forth execution in the Classic99 debugger is a bit painful, especially if it's not all pure Forth. I can track the words executing by setting a breakpoint whenever the IP (interpretive pointer) register changes; but, when it drops into ALC, I have another ball or two to keep in the air. I'll get it done—well before Faire time, I hope—we'll see. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 17, 2013 Author Share Posted September 17, 2013 Wow! I finally found one insidious bug by using the "Compare" plugin of Notepad++. It turns out that I had forgotten to move a label when I was mucking around with the user variable table. I feel like an idiot! Now, at least, the system loads and gives me a console prompt. Now, on to the rest of the bugs.... ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 18, 2013 Author Share Posted September 18, 2013 Two more bugs down—both in the dramatically changed MESSAGE . I changed it from using a special blocks file for messages to loading them into VRAM in space that was vacated by the fbForth record buffer, which is now 128 bytes instead of 1024 bytes. One bug was introduced by entering '-DDUP' in the ALC of MESSAGE 's definition for the code field address (CFA) of -DUP , when I should have entered 'DDUP'. DDUP is a label in the ALC and, of course, -DDUP negated it. It's value is AAA6h and negating it to 555Ah sent it off into the weeds! The second bug was due to the fact that my clever message index uses byte offsets to retrieve messages and—you guessed it—I retrieved the index with @ (fetches the contents of a word, i.e., 2 bytes, of memory) instead of C@ (fetches the contents of a byte of memory). The error became obvious when I saw the message offset in the left half of the word on the stack instead of the right half, where it belonged! I must finish testing my changes and also clean up the blocks file, FBLOCKS, to accommodate the changes. I am optimistic that I will be able to post v0.92 by week's end. As things stand, the return stack (in low CPU RAM) has 36 bytes more memory and there are 68 bytes more high CPU RAM available in v0.92 than in v0.91a. I've even added a few words to the resident dictionary. These savings may not seem like much; but, I thought I would lose memory to my changes. Of course, final testing and debugging could change that. ...lee 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 18, 2013 Share Posted September 18, 2013 Woah! Great job Lee! Keep at it! With regard to tracking bugs, I can assure you that I have had *plenty* of face-palm moments. The most insidious bugs tend to be the most stupid ones, generally! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 21, 2013 Author Share Posted September 21, 2013 Sorry about this—but, posting fbForth v0.92 will have to wait for the Maryland Wine Festival. I probably won't be able to do much until Monday. I have to finish modifying graphics words in FBLOCKS and rewriting CPYBLK and do a little testing. I will try to get it up by Tuesday's end—that's the only window I have for awhile, I'm afraid. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 25, 2013 Author Share Posted September 25, 2013 MWF was fun! I am mostly done with changes. I have not tested CPYBLK yet—I may post it in a day or two in case anyone might want to do a paper run-through. @Willsy? That will require also posting a couple of ancillary words that no one will be familiar with. My time will be limited over the next week or so—going to the Jersey shore for a change of scenery and partying with some friends! ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 25, 2013 Share Posted September 25, 2013 Ha! Partying with some friends! You way you write one would think you're 25 - not (what is it?) 70?? Still, you're as young as the woman you feel, as we say in Blighty Yeah, I'll have a look. My version of CPYBLK cheats somewhat. It reads in a block, changes the active file, and sets the buffer in which the (just read) block resides to "dirty" (I.e. needs to be flushed) then does a FLUSH. Need to make a small change to mine as we were talking about a couple of weeks ago. Haven't done it yet but it's a one-liner. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 1, 2013 Author Share Posted October 1, 2013 I'm having a little trouble with writing blocks to files. Reading works fine; but, I had not checked writing except for MKBFL, which writes blank records sequentially from beginning to last record before it closes the file. CPYBLK is the first use of write-to-file I have tested since MKBFL . I am obviously doing something wrong because the output file gets truncated and has only the last block when I check it. I've tried the writes in both 'ouput' and 'update' modes to no avail. They each fail in different ways, but the file truncation occurs in both. I have not had time to check whether I have done something wrong in setting the PAB header; but, that must be where the problem lies. I am using a late (but not the latest) version of Classic99. I'm rambling a bit here as I think of how to lay out the problem to get the response I need. Any ideas as to what might cause the file truncation? @Tursi? @Willsy? @InsaneMultitasker? @matthew180? ...lee Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 1, 2013 Share Posted October 1, 2013 For Classic99 issues, my first question will always be "What does the debug log say?" Only has the last block.. but.. in the first position? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 1, 2013 Share Posted October 1, 2013 I'm having a little trouble with writing blocks to files. Reading works fine; but, I had not checked writing except for MKBFL, which writes blank records sequentially from beginning to last record before it closes the file. CPYBLK is the first use of write-to-file I have tested since MKBFL . I am obviously doing something wrong because the output file gets truncated and has only the last block when I check it. I've tried the writes in both 'ouput' and 'update' modes to no avail. They each fail in different ways, but the file truncation occurs in both. I have not had time to check whether I have done something wrong in setting the PAB header; but, that must be where the problem lies. I am using a late (but not the latest) version of Classic99. I'm rambling a bit here as I think of how to lay out the problem to get the response I need. Any ideas as to what might cause the file truncation? @Tursi? @Willsy? @InsaneMultitasker? @matthew180? ...lee Hard to tell as your description is a bit cryptic Are you using relative files? Are you inadvertantly resetting the record counter to 0 each time you copy the PAB from CPU to VDP RAM? Is it a full moon tonight? Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 2, 2013 Share Posted October 2, 2013 Yes, they'll be relative files (or, they should be). Almost certainly a problem with the PAB definition. Lee, check the source to FILE in TurboForth. It builds a PAB based on a file-spec passed into it. You could use it in TF to compare PABs. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 3, 2013 Author Share Posted October 3, 2013 Thanks for all the information! I will get back with details later after I do a little more debugging. What I do not understand is how any operation would result in truncation of a file. What would do that? There's no information in the E/A Manual to that effect. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 3, 2013 Share Posted October 3, 2013 The only think I can think of is that you're not opening in UPDATE mode. It would be useful if the debug view in the Classic99 debugger EXPLICITLY told you EXACTLY what is in the PAB. At the moment it's kind of halfway there. Opening DSK1.BLOCKS on drive type FIADPAB requested file type is DF128 It would be nice if it said Opening DSK1.BLOCKS in APPEND mode as a DF128 ...or something like that Anything you can do, Tursi? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 3, 2013 Author Share Posted October 3, 2013 I think I got it. I was probably doing several things wrong, but the biggest error was not insuring that the 'record#' word in the PAB was 0 before opening a file, especially when I was trying to use 'output' mode for writing random records. My trial run was * MKBFL DSK1.JUNK1 80 CPYBLK 4 5 DSK1.FBMSGS 10 DSK1.JUNK1 * Because I'm opening only one blocks file at a time, I'm using the same RAM space for modifying the first 8 bytes of the PAB before copying it to the PAB in VRAM. MKBFL works in either 'output' or 'update' mode to create an 80-block file, DSK1.JUNK1. What I think was happening in CPYBLK was that DSK1.JUNK1 was opened with whatever record# was last used for DSK1.MSGS—first 4, then 5. CPYBLK actually opens each blocks file twice—once to make it the current blocks file (after which it closes it); a second time for the actual reading/writing. I think the truncation happened during the first opening of the output file and the writing of blocks 10 and 11 to the output file extended its length to 10 blocks for the first access and 11 blocks for the last. It seems to be working now, so I think I'll move on and leave nailing it down for a time when I've nothing better to do. You guys (@Tursi, @InsaneMultitasker, @Willsy) probably already know the definitive answer based on what I reported above. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 3, 2013 Author Share Posted October 3, 2013 I am thinking of using only 'update' and 'input' modes. The only problem with this is that, if you use MKBFL to create a file that just happens to already exist (user error! ) and you passed a fewer number of blocks (say, 40) than the existing file (say, 60), it will blank 40 blocks but leave the file at 60 blocks; whereas, it would truncate it to 40 blocks for 'output' mode. This also narrows the truncation problem in the last post to the fact that I actually opened files in 'output' mode when I was writing to them and closing them wrote an EOF record after the last written record. The E/A Manual says this on page 295: The CLOSE operation closes the file. If the file was opened in OUTPUT or APPEND mode, an End of File (EOF) record is written to the device or file before closing the file. which more or less confirms what I found. Regarding MKBFL , I could attempt opening in 'input' mode to see whether the file exists before actually creating the file in 'update' mode. I'm inclined to leave it at "user beware!" with a notation to that effect in the manual. If they "create" an existing file, it gets overwritten (read, "trashed") in either 'output' or 'update' mode. 'Output' mode would yield the actual number of blocks requested (more or less than existing), but adds to my already bloated code; whereas, 'update' mode would do it only when the requested number of blocks is greater. ...lee Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 3, 2013 Share Posted October 3, 2013 the log information I want to see is this: Writing 0xA bytes drive 1 file x (Variable record 0) from >1080 Classic99 will tell you EXACTLY what record is being written to... so no need to guess or test theories, just read! That said, if you open a file for output mode, any existing file with the same name is always blown away. As for reporting the open mode... it looks like the information is available. 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.