Camel99 Forth Information goes here

[+Lee Stewart]

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

[+TheBF]

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. 

[+TheBF]

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

 

[GDMike]

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

 

[GDMike]

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

[+TheBF]

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 

 

 

[GDMike]

Yeah I think I've seen something similar with CASE somewhere?? Somewhere!! I know

[GDMike]

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.

[+TheBF]

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. 

 

[GDMike]

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 

[+TheBF]

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.

 

[GDMike]

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

[+Lee Stewart]

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

[GDMike]

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

[GDMike]

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

[+Lee Stewart]

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, 7D0₁₆ = 2000₁₀!

 

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

[+TheBF]

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.

 

 

 

 

[GDMike]

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

[+TheBF]

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.

[+TheBF]

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.

 

[GDMike]

Oh, save as a standalone program, well ain't you the clever one. Lol

Actually, all you leaders of forth are! Always something new.

[+TheBF]

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

 

 

 

 

[+Lee Stewart]

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

[+TheBF]

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.

[+Lee Stewart]

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