+mizapf Posted June 27, 2014 Share Posted June 27, 2014 :thumbsup: Looks good. :thumbsup: 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 28, 2014 Author Share Posted June 28, 2014 :thumbsup: Looks good. :thumbsup: Woot, woot! You are a gentleman and a scholar! Thank you, so much! ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 29, 2014 Share Posted June 29, 2014 Game on boys! How's that for collaboration! I love my TI friends. Best crowd by far! 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2014 Author Share Posted June 30, 2014 Game on boys! How's that for collaboration! I love my TI friends. Best crowd by far! It has certainly worked very well for this last bit of testing! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2014 Author Share Posted June 30, 2014 I have coded BSAVE so I can hoist it into ROM. BSAVE saves a reloadable (with BLOAD ) binary image of a segment of the user-loaded part of the dictionary It had to be loaded from FBLOCKS before this change and took 170 bytes. I thought coding it in ALC would bloat it, but it's actually a few bytes shorter (including the split header) and not taking up precious bank 0 real estate. After I test and debug it, I think I'll release another beta. After that, I will hoist the 40/80 column editor into ROM, followed by the file I/O library. If I can manage to avoid encroaching on ROM bank 3 with those, I will load the floating point math library into ROM bank 3. The only thing I am a little worried about is the number of words I will have in the resident dictionary by the time i am through with all of this. It will raise the time the outer interpreter takes to find words that are at the beginning of the dictionary because of its threaded nature. I'm up to about 370 words before I start on words in this paragraph. One way I have figured I could alleviate this situation (if, indeed, it seems to be a problem) is to link certain sections of the dictionary into linkable/unlinkable segments by storing those links in low RAM. I can certainly test it first before I attempt this variable linking scenario. Any thoughts? ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 30, 2014 Share Posted June 30, 2014 Depends on how your FIND is coded. I've had >1000 words loaded (specifically to see if I could notice a slow-down). I couldn't. TF FIND is in assembler and is super fast - but TF dictionary format is really simple, it just walks the list looking for matching lengths. No real work to do. IIRC your dictionary format is more complex, is there some shifting and ORing required to read your dictionary? I can't remember the specifics now. It will probably be fine. Load up the dictionary with words and give it a try. I think I just loaded the same application over and over until I had > 1000 words defined. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2014 Author Share Posted June 30, 2014 (edited) Depends on how your FIND is coded. I've had >1000 words loaded (specifically to see if I could notice a slow-down). I couldn't. TF FIND is in assembler and is super fast - but TF dictionary format is really simple, it just walks the list looking for matching lengths. No real work to do. IIRC your dictionary format is more complex, is there some shifting and ORing required to read your dictionary? I can't remember the specifics now. It will probably be fine. Load up the dictionary with words and give it a try. I think I just loaded the same application over and over until I had > 1000 words defined. The actual work of searching the dictionary in fbForth is done by (FIND) , which is also in ALC; but, I suspect it does take a little longer than your FIND because it needs to mask off non-count bits in the length byte and the terminator bit in the last character of the name field. I'll take a peek at TurboForth's code for comparison. Here's the code for (FIND) if you care to have a look: ;[*** (FIND) *** ( addr nfa --- false | pfa b true ) * String at addr should be padded with at least 1 blank at the end!! * DATA DIGI_N * PFIN_N DATA 6+TERMBT*LSHFT8+'(','FI','ND',') '+TERMBT * PFIND DATA $+2 * PFINDP BL @BLF2A * DATA _PFIND->6000+BANK2 * DATA _PFIND *++ Above code from PFIND label is in bank 0 * This part is in bank 2 with headers to accommodate searching without bank-switching _PFIND MOV *SP,R1 ; nfa to R1 JEQ PFIND4 ; top of dictionary? PFIND1 MOV R1,R0 ; no; copy nfa to R0 MOV @2(SP),R3 ; str addr ptr to R3 MOVB *R0+,W ; copy nfa count byte to W; inc R0 to 1st char ANDI W,>3F00 ; mask out non-count bits CB W,*R3+ ; compare char counts; inc R3 to 1st str char JNE PFIND3 ; counts the same? PFIND2 MOVB *R0+,W ; yes; next nfa char to W, incrementing nfa JLT PFIND5 ; char with terminator bit? CB W,*R3+ ; no; compare chars, incrementing str JEQ PFIND2 ; if =, compare next chars PFIND3 MOV @-2(R1),R1 ; not =; counts different; get prev word's nfa JNE PFIND1 ; if not top of dictionary, try again PFIND4 INCT SP ; no match; top of dictionary; pop top of stack CLR *SP ; return false on top of stack JMP PFINDX ; return to inner interpreter PFIND5 ANDI W,>7F00 ; mask out terminator bit from nfa char CB W,*R3 ; last nfa char same as last str char? * ...should match space at end of word with even count JNE PFIND3 ; no; head out INCT R0 ; yes; increment R0 to pfa or pfa ptr * Change to accommodate headers not in bank 0 (pfa ptr in R0) BL @GTCORP ; check for ptr in ROM PFIND6 MOV R0,@2(SP) ; leave pfa on stack at same position as addr CLR *SP ; clear top stack position MOVB *R1,@1(SP) ; copy length byte to right byte of top of stack DECT SP ; make room on stack for 3rd cell SETO *SP ; put -1 on stack NEG *SP ; make it 1 (true) PFINDX B @RTNEXT ; return to inner interpreter ;]* ;[*==== GTCORP =============================================================== * Checks whether header is in ROM for cfa|pfa or cfa|pfa ptr. * * Input: R0 = putative cfa|pfa [may need to change this expectation] * * Output: R0 = actual cfa|pfa * GTCORP CI R0,DCTTOP ; compare to top of headers in ROM JH GCPXIT ; >? [possibly in ROM if <=] CI R0,DCTBOT ; no, compare to bottom of headers in ROM JL GCPXIT ; <? [in low RAM if <] MOV *R0,R0 ; no, get actual cfa|pfa from pointer GCPXIT RT ; return to caller ;]* ...lee Edited June 30, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 30, 2014 Share Posted June 30, 2014 Looks very similar. Here's TF's FIND loop (the part that walks the list looking for a matching length). Note that it also has some masking to do. vfind data $+2 ; vectored find mov *stack+,r6 ; pop length to r6 mov @latest,r7 ; get address of last dictionary entryfndnxt mov @2(r7),r8 ; length of dictionary entry andi r8,>400f ; mask out immediate bit and block numbers c r8,r6 ; are they the same length? jeq lmatch ; jump if yesfind1 mov *r7,r7 ; point to next dictionary entry jeq nomatch ; if 0 then no match. end of dictionary. jmp fndnxt ; else check the next entry It's very fast. I'll think you'll be fine in fbForth :-) Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2014 Author Share Posted June 30, 2014 OK, BSAVE is working! I will post beta 5 later on today. Right now I have other work calling me. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 1, 2014 Author Share Posted July 1, 2014 (edited) I am now posting the latest updates to Post #1 of this thread. The beta-5 ZIPs are posted there. Let me know if there are any problems. ...lee Edited July 1, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 1, 2014 Author Share Posted July 1, 2014 And, now on to hoisting the 40/80 column editor into ROM space! After that, however, I need to work out how to allow folks to load the 64-column editor. At the moment, they are mutually exclusive. I guess I could change the CLOAD condition to look for a word unique to the 64-column editor rather than one shared by both. Actually, there are only 3 words that would invoke the irritating "isn't unique" messages, because each editor is currently loaded into a different editor vocabulary (EDITOR1 and EDITOR2). This may be the perfect place to work out the linking/unlinking scenario I contemplated somewhere above. H-m-m-m—I have work to do. ...lee Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted July 1, 2014 Share Posted July 1, 2014 I have been quietly following the development of FbForth (since I have absolutely nothing to contribute here unfortunately), and I have to say that I am thoroughly impressed by the quality of the work being done. This is going to be a killer package. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 1, 2014 Author Share Posted July 1, 2014 (edited) I have been quietly following the development of FbForth (since I have absolutely nothing to contribute here unfortunately), and I have to say that I am thoroughly impressed by the quality of the work being done. This is going to be a killer package. Thanks for your encouragement, Walid! Actually, you have contributed in the past and I would like you (and anyone else, for that matter) to offer your opinion on what I did with the 64-column editor (64ED) because you are one of the few I know who has actually used it. A few posts back, I mentioned changing the exit from the 64ED to pop you into the mode you left when invoking it rather than simply exiting to the text window of SPLIT mode. At that point, you were usually screwed unless you had had the foresight to load other graphic modes before entering the 64ED. With fbForth 2.0 it is now easy enough to simply invoke whatever mode you want at that point; but, with my change, you don't have to. Though it tells you what block # you were just editing, you now can no longer see it. I want to know what you think is the better exit procedure—or, suggest a different one! ...lee EDIT: I was wrong about the crossed-out section. Edited July 1, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted July 1, 2014 Share Posted July 1, 2014 SInce we now have the ability to invoke any mode we want, we can leave that to the user. My personal preference when using SPLIT mode would be to return to that mode because it allows me to test high res routines on the fly (one of the things I love about that mode) for debugging purposes. As long as I can invoke any other mode from there I should be fine. It's no secret that I love working with the bitmap mode on the TI, so I am a little skewed here Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 1, 2014 Author Share Posted July 1, 2014 SInce we now have the ability to invoke any mode we want, we can leave that to the user. My personal preference when using SPLIT mode would be to return to that mode because it allows me to test high res routines on the fly (one of the things I love about that mode) for debugging purposes. As long as I can invoke any other mode from there I should be fine. It's no secret that I love working with the bitmap mode on the TI, so I am a little skewed here I'm inclined to agree. It is easy enough to clear the screen for bitmap testing after exiting the 64ED by simply re-invoking SPLIT or, for even more bitmap real estate, SPLIT2 . I think I will change it back for the next go-round. In the meantime, you could delete or comment-out " SVMD @ VMODE " from line 9 of block 12. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 11, 2014 Author Share Posted July 11, 2014 Sorry it's taking me so long with the 40/80-column editor conversion. Other stuff is getting in the way; but, the editor is written in Forth and is pretty convoluted (very un-Forth-like ). I am trying to deconvolve it some, but it's pretty rough translating/converting most of it to ALC! I am also incorporating a few bits of code from @Willsy's TurboForth editor (he did give me permission ), especially the editing box graphics. I may add keystroke help at the bottom of the screen in much the same way @Willsy did in TF. It's getting there—but, still some days away. ...lee 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted July 15, 2014 Share Posted July 15, 2014 This auction MIGHT be of interest to some of your Forth Gurus... 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 15, 2014 Share Posted July 15, 2014 Dang! Never seen that one before! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 15, 2014 Author Share Posted July 15, 2014 This auction MIGHT be of interest to some of your Forth Gurus... It would really be nice if the TI Forth Notes newsletter were on some of those diskettes. Perhaps it's worth a bid to find out. ...lee Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 16, 2014 Share Posted July 16, 2014 I'm working on it. . .I put in the first bid. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 16, 2014 Author Share Posted July 16, 2014 I'm working on it. . .I put in the first bid. Well, then—I'll not fight you on it. If you get it, we can talk at The Faire. OMG, that's not even 4 months away! I'd better get cracking on finishing up the fbForth 2.0 cartridge for a possible demo!! ...lee Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted July 19, 2014 Share Posted July 19, 2014 Now... THIS looks interesting in a Forth kind of way! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 19, 2014 Author Share Posted July 19, 2014 Now... THIS looks interesting in a Forth kind of way! Or—you could get them all here: http://www.forth.org/fd/contents.html ...lee 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted July 19, 2014 Share Posted July 19, 2014 Or—you could get them all here: http://www.forth.org/fd/contents.html Even better. The link has been saved in my Forth File for future reference. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 19, 2014 Share Posted July 19, 2014 Howie nabbed it at the last second. . .he's built quite a TI collection over the last couple of years. 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.