+Lee Stewart Posted October 28, 2020 Share Posted October 28, 2020 1 hour ago, GDMike said: I expect, that "EXPECT" is a pretty powerful player. Well—in the Forth 2012 standard mentioned by @TheBF, ACCEPT goes EXPECT one better by returning on the stack the actual number of characters entered. ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 3 minutes ago, Lee Stewart said: Well—in the Forth 2012 standard mentioned by @TheBF, ACCEPT goes EXPECT one better by returning on the stack the actual number of characters entered. ...lee True but has much less in the SPAN department. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 For GDMike's benefit he should see what it takes to replicate TI BASIC's INPUT word in Forth. I chose to use two words, one for strings and then use the string version for numbers. You can see how ACCEPT was used to capture a string by making $ACCEPT that sets up the input parameters for you and stores the length as the first byte of the string address on the stack. You can also see how much more goes into doing #INPUT like TI BASIC But it works pretty much as expected for a BASIC progammer, just in reverse. \ $INPUT #INPUT for CAMEL99 Forth V2.6 \ *Difference* there is a separate input for numbers and strings DECIMAL : $ACCEPT ( $addr -- ) CR ." ? " DUP 1+ 80 ACCEPT SWAP C! ; : $INPUT ( $addr -- ) BEEP $ACCEPT ; \ BEEP like TI-BASIC : #INPUT ( variable -- ) \ made to look/work like TI-BASIC BEEP BEGIN PAD $ACCEPT \ $ACCEPT text into temp buffer PAD PAD COUNT NUMBER? \ convert the number in PAD WHILE \ while the conversion is bad we do this CR HONK ." input error " CR DROP REPEAT SWAP ! ; \ store number in the variable on the stack CAMEL99 INPUT WORDS.mp4 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 I built an "accept at" routine last year. It took awhile but I did it with beep and location. It expected the col,row the text and it worked well. I just can't remember the code off top of my head. It's somewhere buried in my TF stuff. Lol 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 I didn't have error correction, like yours, "I don't know what you call it, boundary protect", but it was supposed to be just a tool for me.. I also made a screen copy routine, and paste. So simple. But when I started I thought it'd be hard. Love forth 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 When I got my X BASIC cartridge I thought ACCEPT at was the most amazing thing I had ever seen with all the variations. VALIDATE() with a string or UALPHA and all that stuff. I am now not happy with that way of bundling everything together into a command. I much prefer Chuck Moore's vision of making those pieces separate but easily combinable as you need to. You are right. It makes it easy. Instead of wishing you had this or that you just put some words together. Here is VALIDATE in Camel99 Forth. It uses an assembly language routine called SCAN. Add some strings of validation chars of your choice and voila! : VALIDATE ( char string -- ?) ROT SCAN NIP 0> ; : PUNCTUATION S" !@#$%^&*()_+" ; CHAR Q PUNCTUATION VALIDATE 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 Yeah I think I've seen something similar with CASE somewhere?? Somewhere!! I know Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 Btw, I'm trying to finish up in SNP, just need the DSR written and I'm getting closer, then i, hopefully will be back in FORTH. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 1 minute ago, GDMike said: Btw, I'm trying to finish up in SNP, just need the DSR written and I'm getting closer, then i, hopefully will be back in FORTH. I used a version published by @insanemultitasker which I seemed to be able to understand better. It works well. I have found some ways to make it smaller but I am actually testing right now to see if I can trust it on real iron. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 I had asked lee, ooops this is off track, about my tipi clock sometimes working and not, regarding maybe Sam's was causing it, but yesterday I went to change the"lowercase y" Because I didn't like the shape, then I found out my inverse char routine would invert the colors on all my characters except u,v,w I thought wow, Why!? So I dug and found that my DSR I had from a copy from somewhere, had an address of >F80 ..shazam.. I changed it to somewhere in low RAM, and it fixed both my clock and my character wipe outs that were going on. Which is why I'm almost done and just one last thing then back to forth. Probably ? since I haven't had the pleasure 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 4 hours ago, GDMike said: Which is why I'm almost done and just one last thing then back to forth. Probably ? since I haven't had the pleasure When you do it will be different because it doesn't use blocks normally. Just text files. (blocks are a loadable extension) It is mostly compatible with Starting Forth (https://www.forth.com/starting-forth/0-starting-forth/) You use any text editor that you like. EDIT1 from E/A works fine. And the kernel is just the CORE words. Everything else you INCLUDE into the system as needed. I have just finished a new version that is not released yet. I want to get it working for super cart as well which gives you lots of memory. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 (edited) Very interesting, so what does the text file consist of, as in, do I keep just one text file that's 15 lines or just one big file and forth handles the seperate screens on its own, or does that screen boundary just not exist anymore? Edited October 28, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2020 Share Posted October 28, 2020 11 hours ago, GDMike said: Btw, I'm trying to finish up in SNP, just need the DSR written and I'm getting closer, then i, hopefully will be back in FORTH. Folks reading this thread are not likely to know what you mean by SNP (Super Notes Pro). It is always a good idea to say too much than not enough IMHO. 11 hours ago, GDMike said: So I dug and found that my DSR I had from a copy from somewhere, had an address of >F80 ..shazam.. I changed it to somewhere in low RAM, and it fixed both my clock and my character wipe outs that were going on. It is unclear to me what you mean by “DSR” (Device Service Routine) because that moniker usually applies to programs in DSR space (>4000 – >5FFF) or GROM/GRAM, which directly service devices like disk drives and cassette recorders. I think you mean DSRLNK (DSR LiNK), but, again, I am not sure because you say it “had an address of >F80”, which is in the console ROM. But, since you cannot write there, I thought maybe you mean PAB (Peripheral Access Block), which a DSRLNK routine hands to a DSR and is usually located in free VRAM (VDP RAM). A VRAM address of >0F80 would, indeed, interfere with the character table for character codes 240 and up. However, you really lost me when you said you “changed it to somewhere in low RAM”, which we normally think of as >2000 – >3FFF in low expansion RAM, which is not where most DSRs expect to find a PAB. ...lee 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 (edited) 1 hour ago, Lee Stewart said: you “changed it to somewhere in low RAM”, which we normally think of as >2000 – >3FFF in low expansion RAM, Corrected in next post Yes, I changed the PAB address from>0F80 to >2000(I believe that's the address I used, I'll DBL check). And so far the program works, whereas it didn't, or it barely did prior to the change. So I'm happy. Edited October 28, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 (edited) 15 minutes ago, GDMike said: Yes, I changed the PAB address from>0F80 to >2000(I believe that's the address I used, I'll DBL check). And so far the program works, whereas it didn't, or it barely did prior to the change. So I'm happy. Oh, I apologize it's >7D0 not >2000!! Oh my.well when I'm in the system working so much goes on and I can't remember when I walk away and the attempt at using>2000 didn't work, but stuck in my head. So sorry ? Edited October 28, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2020 Share Posted October 28, 2020 1 hour ago, GDMike said: Oh, I apologize it's >7D0 not >2000!! Oh my.well when I'm in the system working so much goes on and I can't remember when I walk away and the attempt at using>2000 didn't work, but stuck in my head. So sorry ? No prob. Interestingly, 7D016 = 200010! You need to be careful with that area of VRAM. >07D0 is perilously close to the beginning of the character tables (>0800) you are trying to avoid. In Text mode (which is what you are using, I think) you should be safe using VRAM from >460 to >7FF and from >1000 to the value in >8370 in scratchpad RAM (for FILES = 3: >37D7 for TI Disk Controller, >37CF for nanoPEB). And now, back to your regularly scheduled program.... ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 4 hours ago, GDMike said: Very interesting, so what does the text file consist of, as in, do I keep just one text file that's 15 lines or just one big file and forth handles the seperate screens on its own, or does that screen boundary just not exist anymore? There are no screens or blocks. Just normal DV80 files. It's almost like we are in the 21st century! It's like an Asm or C program source code file. And all the libraries are the same. DV80 files. Text files... with names... imagine that! The disadvantage of using native files is that editors are bigger and so keeping the editor in memory is hard to do. With SAMS it can be done. BLOCKS are actually a virtually memory system so they are pretty clever for small footprint machines. See the video below for a quick demonstration. We don't have WORDS in the dictionary, so we INCLUDE the tools file. The tools file knows it needs FORGET, CASE and DEFER so it gets those files first and compiles them. Afterwords tools are available to use. INCLUDE TOOLS DEMO.mp4 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 (edited) I see. Sorta kinda. I mean, I read a book years ago and one of them, of course I can't pull it outta my hat, but it went out of the way and described forth as having 15-16 lines per screens?? 1000 characters deliberately, and screens were the essential part of what makes forth forth, and was a proud moment for the editor as he/she explained. You just shot an arrow through that editors opinion. So back then, years ago, I picked up a forth for x86 and it indeed had 15 or 16 lines for editing screens. And you're blowing it away. So you're basically pushing code that won't crash through to the command line interpreter? Or can I troubleshoot and save my fixes back to my saved disk of code. Ahh. Nope cause no editor.. So it's gotta be troubleshot at the command line and then I go back to my editor and file and fix it. Hmmm but do you, probably do, have an editor that can be loaded that would allow fixing the code at command line and quickly fixing the file and reload for testing.. It's an interest concept, well, working concept I guess. Edited October 28, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 2 hours ago, GDMike said: I see. Sorta kinda. I mean, I read a book years ago and one of them, of course I can't pull it outta my hat, but it went out of the way and described forth as having 15-16 lines per screens?? 1000 characters deliberately, and screens were the essential part of what makes forth forth, and was a proud moment for the editor as he/she explained. You just shot an arrow through that editors opinion. So back then, years ago, I picked up a forth for x86 and it indeed had 15 or 16 lines for editing screens. And you're blowing it away. So you're basically pushing code that won't crash through to the command line interpreter? Or can I troubleshoot and save my fixes back to my saved disk of code. Ahh. Nope cause no editor.. So it's gotta be troubleshot at the command line and then I go back to my editor and file and fix it. Hmmm but do you, probably do, have an editor that can be loaded that would allow fixing the code at command line and quickly fixing the file and reload for testing.. It's an interest concept, well, working concept I guess. Yes I have ED99. With stock 32k card and ED99 loaded there is about 7K to load pieces of code, test them and then forget them. I will get ED99 into a separate vocabulary eventually that lives in the 8K pages at D000..EFFF . The Forth vocabulary will use the default pages up there. I almost have everything in place to make that work. So with SAMS it can be a pretty big integrated develop environment. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2020 Author Share Posted October 28, 2020 2 hours ago, GDMike said: I see. Sorta kinda. I mean, I read a book years ago and one of them, of course I can't pull it outta my hat, but it went out of the way and described forth as having 15-16 lines per screens?? 1000 characters deliberately, and screens were the essential part of what makes forth forth, and was a proud moment for the editor as he/she explained. You just shot an arrow through that editors opinion. Yes. All modern and commercial Forth systems use files now. MPEForth, SwiftForth, iForth, MeCrisp Forth. Quote So back then, years ago, I picked up a forth for x86 and it indeed had 15 or 16 lines for editing screens. And you're blowing it away. Yes again. Quote So you're basically pushing code that won't crash through to the command line interpreter? Forth is designed to test everything at the command line before you commit it to final code. If it crashes restart the system. That'll teach ya! Quote Or can I troubleshoot and save my fixes back to my saved disk of code. Ahh. Nope cause no editor.. Well yes there is an editor, in fact if you wanted to make a block file and edit code pieces that you could and then save them later as a DV80. Quote So it's gotta be troubleshot at the command line and then I go back to my editor and file and fix it. Well I actually have a little editor that lives in VDP RAM. Only 40 columns wide an 9K of code. You could load that and use it too. Quote Hmmm but do you, probably do, have an editor that can be loaded that would allow fixing the code at command line and quickly fixing the file and reload for testing.. It's an interest concept, well, working concept I guess. Yes ED99 can do that and it's not a concept really it's how all other compilers work. There is just no linking loading step. Forth does it all at once. And when you are finished you save the while thing as an EA5 program. Just got that working. 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 28, 2020 Share Posted October 28, 2020 Oh, save as a standalone program, well ain't you the clever one. Lol Actually, all you leaders of forth are! Always something new. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 30, 2020 Author Share Posted October 30, 2020 So... in the course of working on my next revision of Camel99 Forth , I finally found the bug in these new ISO FORTH style loops has eluded me for 2 years. I found it because I was trying to squeak in the code to handle HASHed searches and VOCABULARY variables and a search order array. I ran out of room in 8K and so tried using these new style loops. I had given up on integrating them into Camel Forth because they were flakey, but I needed the space. They are smaller the FIG Forth style I have been using because they do less error checking and have some other neat trick that I will show in my next post. It turned out the bug was probably in the original Camel Forth kernel. At least that is way it worked out using these simpler loops. Since the Forth83 standard, getting out of a DO/LOOP has been a bit more difficult but the details elude me at the moment as to exactly why. Camel Forth's solution uses something called a leave stack to manage the problem. This boils down to the compiler knowing how to branch from where LEAVE is in the code to just past the LOOP word. It's is a lot like compiling an IF/ENDIF into the code to do the jump. It also must clean up any stuff that DO left on the return stack with UNLOOP. The word that resolves where all this jumping is to go is called ENDLOOP in Camel Forth but I called it RAKE because it RAKES the LEAVES! Get it! Damn that's a bad joke. And I think I stole it from eForth source code ... What I found after a million or so crashes (ok not a million) was that RAKE was underflowing when it unwound the LEAVE stack. EDIT: Late night mistake. The array is called L0. LP is the pointer into that array, organizing it like a stack with >L and L> . LP L0 Is 4 CELL array variable and so this was over-writing the Code field address of LP L0 the next time LEAVE was called... Yikes! The fix was to reset the LP stack pointer at the end of RAKE. It all worked reliably after that! Hobbies just don't get better than this! I must be crazy, ok I am. \ ANS/ISO Looping and Branching : >MARK ( -- addr) HERE 0 , ; : <RESOLVE ( addr --) HERE - , ; : THEN ( addr -- ) HERE OVER - SWAP ! ; IMMEDIATE : BEGIN HERE ; IMMEDIATE : IF POSTPONE ?BRANCH >MARK ; IMMEDIATE : AHEAD POSTPONE BRANCH >MARK ; IMMEDIATE : ELSE POSTPONE AHEAD SWAP POSTPONE THEN ; IMMEDIATE : UNTIL POSTPONE ?BRANCH <RESOLVE ; IMMEDIATE : AGAIN POSTPONE BRANCH <RESOLVE ; IMMEDIATE : WHILE POSTPONE IF SWAP ; IMMEDIATE : REPEAT POSTPONE AGAIN POSTPONE THEN ; IMMEDIATE \ CAMEL Forth LEAVE stack pointer is initialized by QUIT : >L ( x -- ) ( L: -- x ) 2 LP +! LP @ ! ; : L> ( -- x ) ( L: x -- ) LP @ @ -2 LP +! ; \ -compile this- - run this now- : DO ( -- ) ?COMP POSTPONE <DO> HERE 0 >L ; IMMEDIATE : ?DO ( -- ) ?COMP POSTPONE <?DO> HERE 0 >L ; IMMEDIATE : LEAVE ( -- ) ( L: -- addr ) POSTPONE UNLOOP POSTPONE BRANCH >MARK >L ; IMMEDIATE : RAKE ( -- ) ( L: 0 a1 a2 .. aN -- ) BEGIN L> ?DUP \ read leave stack, dup if <>0 WHILE POSTPONE THEN \ resolves branch in LEAVE REPEAT L0 LP ! ; IMMEDIATE \ reset the leave stack. *BUG KILLED* : LOOP ( -- ) COMPILE <LOOP> <RESOLVE RAKE ; IMMEDIATE : +LOOP ( -- ) COMPILE <+LOOP> <RESOLVE RAKE ; IMMEDIATE 1 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 30, 2020 Share Posted October 30, 2020 5 minutes ago, TheBF said: Since the Forth83 standard, getting out of a DO/LOOP has been a bit more difficult but the details elude me at the moment as to exactly why. Does this mean that where the loop exits is different from figForth (and, consequently, TI Forth and fbForth) and Forth 79, in which the loop is left only upon reaching LOOP or +LOOP because LEAVE merely sets the loop limit equal to the current index? ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 30, 2020 Author Share Posted October 30, 2020 6 hours ago, Lee Stewart said: Does this mean that where the loop exits is different from figForth (and, consequently, TI Forth and fbForth) and Forth 79, in which the loop is left only upon reaching LOOP or +LOOP because LEAVE merely sets the loop limit equal to the current index? ...lee Yes that's the issue. Thank you for the reminder. The Forth83 committee wanted to leave the loop right away versus the older method where you make limit=index and run the code until LOOP is encountered again. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 30, 2020 Share Posted October 30, 2020 2 hours ago, TheBF said: Yes that's the issue. Thank you for the reminder. The Forth83 committee wanted to leave the loop right away versus the older method where you make limit=index and run the code until LOOP is encountered again. That usually causes me to force the test that issues LEAVE to the end of the loop, sometimes resulting in unnaturally contrived code. I can usually make it work, but needing to remember that can be a PITA. ...lee 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.