+Lee Stewart Posted October 15, 2014 Author Share Posted October 15, 2014 (edited) @Willsy has ported his TurboForth String Library to fbForth. I added one word and will add the library to the next FBLOCKS release. I am now puzzling over how to handle the additional 34 words in the glossary of the manual (see post #1). I will, probably, simply add them to the current glossary, as always. {EDIT: See posts #914 – #917} I will definitely add a descriptive chapter (Chapter 14) and include the code in Appendix J—maybe not by Faire time, however. ...lee Edited November 9, 2014 by Lee Stewart 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 17, 2014 Author Share Posted October 17, 2014 I just posted the latest FBLOCKS file in post#1. It has the following additional options: Disk Catalog Utility (ported from TurboForth code with @Willsy's permission Portable String Library (ported by @Willsy and slightly modified by Yours Truly) In addition to the above, there are much-faster-loading binary images of the 64-Column Editor TMS9900 Assembler Portable String Library As always let me know of any bugs you find or other issues you may have with the software. In particular, note that, whereas the menu selection may say “64-Column Editor BLOAD [clears RAM]..32”, it is still loaded with 32 LOAD , not 32 BLOAD . ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 18, 2014 Author Share Posted October 18, 2014 Please, note that the current FBLOCKS file in post#1 is at the bottom of that post. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 25, 2014 Author Share Posted October 25, 2014 I found a bug in the 40/80-column editor for the insert-blank-line function ( CTRL+8 ). I will post ZIP files in post#1 sometime today or tomorrow. I have changed the first line of the boot screen to read: to indicate a revision number with a colon. The ZIP files will still be dated in their filenames. FYI, the bug was that the inserted line would not blank the entire new line if the cursor were not located in the first column. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 25, 2014 Share Posted October 25, 2014 Great minds... I'm doing the same in the latest release of TF! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 26, 2014 Author Share Posted October 26, 2014 Great minds... I'm doing the same in the latest release of TF! Well—considering that I lifted it from you ... ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 27, 2014 Author Share Posted October 27, 2014 OK...I just posted fbForth 2.0.1 in post#1. It has the bug fix mentioned 3 posts back. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2014 Author Share Posted October 28, 2014 Will it never end?!? I found a problem with the BSAVEd MENU options in FBLOCKS. I am not really sure what is wrong; but, when more than one vocabulary is involved with the RAM part of the dictionary that is being BSAVEd, I need to first change the context vocabulary to the last-defined vocabulary before issuing the BSAVE command. Obviously, I need to troubleshoot that; but, right now, I am desperately trying to finish preparations for Chicago. It also may have had to do with the kernel fix a few posts back. Anyway. the latest FBLOCKS file along with a couple of font files is at the end of post#1. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2014 Author Share Posted October 28, 2014 I just noticed that the catalog routine of my nanoPEB's (v1) DSR does not include the VIB or FDIR in its sector count for a disk, but adds(!) the FDR to the sector count for each file. That messes up the reporting of both fbForth's DIR (and TurboForth's DIR because I ported it to fbForth). I don't have enough time to put FBLOCKS on diskette to check it out by Faire time; so, could someone check whether DIR reports the same information for a diskette as it does for the same set of files on a nanoPEB disk image? ...lee Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted November 3, 2014 Share Posted November 3, 2014 At first glance, I couldn't find the code to use FB 2.0 as a "User Cart" entry in the .ini file in Classic99. Could you point me in the right direction? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 3, 2014 Author Share Posted November 3, 2014 (edited) At first glance, I couldn't find the code to use FB 2.0 as a "User Cart" entry in the .ini file in Classic99. Could you point me in the right direction? It's about halfway down in post #1. Here is what the full entry should be: [UserCart0] name="fbForth 2.0" rom0=3|0000|8000|MODS\fbForth200_3.bin ...lee Edited November 3, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 5, 2014 Author Share Posted November 5, 2014 (edited) I think the only problem with BSAVE (mentioned in post #908) involves the two resident vocabularies, FORTH and ASSEMBLER . The only way the vocabulary pointers for those two vocabularies get updated upon BLOADing is through the BSAVEd values for CONTEXT and CURRENT . At least one of those must point to FORTH . The other must point to ASSEMBLER if the TMS9900 Assembler is part of what is to be BSAVEd. The reason for this is that the NFA of the last defined word in any vocabulary is stored in that vocabulary's vocabulary pointer. In fbForth 2.0, both FORTH and ASSEMBLER vocabulary words are stored in low RAM so they can be modified. They are not updated by BLOAD except through CONTEXT and CURRENT . BSAVEing the 64-column editor should not pose a problem with its EDITOR2 vocabulary, as long as one of CONTEXT and CURRENT points to FORTH , because EDITOR2 is part of the upper-RAM portion of the dictionary, which is properly BSAVEd without further machinations. ...lee Edited November 6, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 6, 2014 Share Posted November 6, 2014 Sounds like a clarification on the manual (under BSAVE) might be on order as there's potential for a confusing gotcha! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 6, 2014 Author Share Posted November 6, 2014 Yeah—I plan to do just that along with some other corrections and clarifications, the need for some of which are the result of using the fbForth 1.0 version of the manual as my starting point for the 2.0 version. Before posting the next revision of the manual, I plan to do the following: Correct errors found Clarify information discovered to be inadequate Add a utility to allow editing the 64-column editor’s font of tiny characters Explain in §13.4 how to edit the tiny-character font with the utility in (3) and FONTED Add Chapter 14 for the String Library Add the String Library words to the glossary Incorporate selected information suggested by users (hint, hint ) ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 7, 2014 Author Share Posted November 7, 2014 I need some advice about whether I should bother with the tiny character font editing utility I mentioned in my last post because the process is a little clunky and maybe not worth the effort. The really clunky part is that the user would be editing 2 characters side by side in the font editor because each tiny character is the same height but exactly half the width of each character in a normal font. What do you think? ...lee Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted November 7, 2014 Share Posted November 7, 2014 I would leave that out, Lee. The tiny font used in the 64-column editor is probably as good as such a tiny font is going to get. . .no need to modify it until no good (mung). 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 7, 2014 Author Share Posted November 7, 2014 Unless there are objections, I think I will also omit adding the string library words to the glossary, relying on the new Chapter 14 for everything to do with the string library. That will make my tasks the following: Correct errors found Clarify information discovered to be inadequate Add Chapter 14 for the String Library Incorporate selected information suggested by users (hint, hint ) ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 10, 2014 Author Share Posted November 10, 2014 A little more on the DIR problem I mentioned above in post #909: Total sectors on disk: The nanoPEB and CorComp DSRs both report the number of sectors on the disk less the VIB and FDIR sectors. Classic99 adds the VIB and FDIR sectors to the total. Each file's sector size: The nanoPEB and CorComp DSRs both add each file's FDR. (This is what Thierry's website says the DSR should do.) Classic99 does not include FDR MESS (v155) won't open the catalog "file" with the HFDC driver (I cannot get either the TIFDC or the BWG drivers to work at all) ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 10, 2014 Author Share Posted November 10, 2014 Re MESS in my last post—apparently, the HFDC DSR on MESS does not like my specifying the record length of the catalog “file”, which should be 38. I can get it to work in TI Basic; but, so far, I cannot get past the filename in the first record in fbForth without a system hang. Specifying the record length works just fine on the real iron with the nanoPEB as well as the CorComp diskette controller. Given how differently DIR works on Classic99, MESS and the real iron, I suppose I could dispense with relying on the DSRs’ catalog routines and write my own low-level routine to directly read the VIB, FDIR and FDRs—but that will definitely be painful! ...lee Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted November 10, 2014 Share Posted November 10, 2014 Or just note the current limitations and keep this one in hand as a future enhancement. . . Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 10, 2014 Share Posted November 10, 2014 I cannot get either the TIFDC or the BWG drivers to work at all How exactly do they fail? Both have been reimplemented but I did not notice any problem in my tests. Error message from MESS? Can you read BASIC files? Michael Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 10, 2014 Author Share Posted November 10, 2014 How exactly do they fail? Both have been reimplemented but I did not notice any problem in my tests. Error message from MESS? Can you read BASIC files? Michael I could not get past the reset after changing the 8th slot to either TIFDC or BWG. The message is Since then I've found the problem: The TIFDC and BWG controllers apparently cannot handle the 1600-sector CF7+/nanoPEB images that have 20 sectors/track and a full allocation bitmap. Furthermore, the TIFDC will only handle single density. The BWG controller seems to be fine with 18 sectors/track and my original DIR that sets the record length at 38 before opening the catalog "file". The HFDC controller is problematic with DIR . If I remove the record length from the PAB prior to opening the catalog "file", it will open, but it goes off into the weeds after I read and process the first record. This is puzzling because my TI Basic program succeeds after removing the opening record length from the PAB (same as with the 1600-sector image). ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 10, 2014 Share Posted November 10, 2014 Since then I've found the problem: The TIFDC and BWG controllers apparently cannot handle the 1600-sector CF7+/nanoPEB images that have 20 sectors/track and a full allocation bitmap. Furthermore, the TIFDC will only handle single density. The BWG controller seems to be fine with 18 sectors/track and my original DIR that sets the record length at 38 before opening the catalog "file". That is right. I heard of some requests and attempts to use CF7+ images with MESS, but this is unlikely to work until I actually create a CF7+ emulation. You always have to consider that there is the original DSR which must process the image. Also, with 0.155 the dsk/dtk file is used to create the disk track flux sequences, and I really depend on the file size to determine track count, sides, and density, especially when the disk is not yet formatted. The HFDC can load the catalog in BASIC (CALL DIR(x) or in a program using OPEN). Maybe there are difference because the DSR has to cope with hard disks and floppy disks. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 11, 2014 Share Posted November 11, 2014 A little more on the DIR problem I mentioned above in post #909: Total sectors on disk: The nanoPEB and CorComp DSRs both report the number of sectors on the disk less the VIB and FDIR sectors. Classic99 adds the VIB and FDIR sectors to the total. Each file's sector size: The nanoPEB and CorComp DSRs both add each file's FDR. (This is what Thierry's website says the DSR should do.) Classic99 does not include FDR ...lee Classic99 SHOULD be matching what the TI disk controller did, that is the intent at least. I would ask people NOT to code for Classic99 idiosyncrasies but instead report them as bugs, because that's what they are. (I don't promise to "fix" them all, but they should at least all be inspected!) Classic99 supports the /actual/ TI disk controller, you can check the documentation for how to enable it. You're fairly restricted right now, which is why it's not a public option, but it's good for checking what the original code actually returned. I would personally discourage writing low level catalog functions anymore, since there is such a variety of devices out there (and my personal vendetta to eventually get away from the TICC disk layout standard ). Does it matter that much to your catalog program that the reported size of the file differs on different controllers? I seem to remember that was true back in the day anyway? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 11, 2014 Author Share Posted November 11, 2014 Classic99 SHOULD be matching what the TI disk controller did, that is the intent at least. I would ask people NOT to code for Classic99 idiosyncrasies but instead report them as bugs, because that's what they are. (I don't promise to "fix" them all, but they should at least all be inspected!) Classic99 supports the /actual/ TI disk controller, you can check the documentation for how to enable it. You're fairly restricted right now, which is why it's not a public option, but it's good for checking what the original code actually returned. I would personally discourage writing low level catalog functions anymore, since there is such a variety of devices out there (and my personal vendetta to eventually get away from the TICC disk layout standard ). Does it matter that much to your catalog program that the reported size of the file differs on different controllers? I seem to remember that was true back in the day anyway? According to Thierry’s site, the filesize reported should include the FDR. This is what is reported by Jaime’s DSR (nanoPEB/CF7+). the BWG DSR (MESS), TIFDC(MESS), HFDC(MESS) and my CorComp (real iron) DSR. I have not yet fired up one of my PEBs to check the real-iron TIFDC, but I would bet it's the same. So, yeah, I would say that is a bug in Classic99’s disk DSR emulation. The “Total” and “Free” sectors reported by the respective DSRs is quite another matter, however. Most (all?) of the DSRs report a number for “Total” that does not include the VIB and the FDIR, even though the actual number of sectors on the disk (including the VIB and the FDIR) is sitting right there in the VIB! According to Thierry’s site, the total number of sectors is read from the VIB and the number of free sectors in the allocation bitmap is counted (all 1600 bits are included!?!). I have no idea how the reported numbers are actually calculated without reading the ALC of the DSR (my eventual plan). So—I guess I really should not care about how a given DSR reports them. I presume that “Free” would be the same regardless of what is reported for “Total” and that “Total” will be either what is in the VIB or 2 less. ...lee 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.