6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Apr 27, 2024 2:01 pm

All times are UTC




Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Jul 24, 2018 6:33 pm 
Offline

Joined: Wed Jul 18, 2018 12:12 pm
Posts: 96
I saw this mentioned on a YouTube video where a guy is porting CamelForth to a Vectrex game system (6809 based). It is a neat online Forth tutorial with a JavaScript Forth interpreter.

https://skilldrick.github.io/easyforth/

This is proving easier to learn on than the DurexForth I found for the C64.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jul 24, 2018 6:54 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Thanks for the link to easyforth! (Nick also did easy6502.)

(Forth on Vectrex sounds interesting. Let the dog see the rabbit, as they say:
https://www.youtube.com/watch?v=0_OprEzRG2s
via
http://vectorgaming.proboards.com/threa ... th-parts-1
)


Top
 Profile  
Reply with quote  
PostPosted: Tue Jul 24, 2018 7:37 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Jeff_Birt wrote:
I saw this mentioned on a YouTube video where a guy is porting CamelForth to a <...>

CamelForth is a creation of our own Brad Rodriguez! :D

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 25, 2018 12:48 pm 
Offline

Joined: Wed Jul 18, 2018 12:12 pm
Posts: 96
BigEd wrote:
(Forth on Vectrex sounds interesting. Let the dog see the rabbit, as they say:
https://www.youtube.com/watch?v=0_OprEzRG2s
via
http://vectorgaming.proboards.com/threa ... th-parts-1
)


Thanks I did not think of posting the link to the Vectrex project.

After playing with the Easy Forth interpreter I have to say I REALLY like the stack display at the top of the window. That makes it sooo much easier to visualize what is happening. This would probably be a great addition to any Forth environment.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 25, 2018 6:54 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Jeff_Birt wrote:
After playing with the Easy Forth interpreter I have to say I REALLY like the stack display at the top of the window. That makes it sooo much easier to visualize what is happening. This would probably be a great addition to any Forth environment.

I think that after a while you won't need it anymore, as you start thinking that way naturally. I did, anyway. I realize everyone's brains don't work the same way though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 27, 2018 9:29 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851
GARTHWILSON wrote:
Jeff_Birt wrote:
After playing with the Easy Forth interpreter I have to say I REALLY like the stack display at the top of the window. That makes it sooo much easier to visualize what is happening. This would probably be a great addition to any Forth environment.

I think that after a while you won't need it anymore, as you start thinking that way naturally. I did, anyway. I realize everyone's brains don't work the same way though.

I agree, but for the times when you really need to see what is on the stack there is .S. .S nondestructively displays the contents of the data stack. To quote the rational for including it in the 2012 standard programming tools wordset ( although, I use a Forth-83 standard system):
".S is a debugging convenience found on almost all Forth systems. It is universally mentioned in Forth texts."


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 27, 2018 11:05 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
True, and I do use .S (on rare occasion); but I have little use for it being in a constant display at the top of the window. Numbers on the stack are pretty meaningless anyway when you don't have any description of what they are. It won't say beside it for example, "This is the address of the cell in the header that holds the updated link to the next buffer." The computer doesn't know.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 28, 2018 12:55 pm 
Offline

Joined: Thu Jan 21, 2016 7:33 pm
Posts: 269
Location: Placerville, CA
GARTHWILSON wrote:
I think that after a while you won't need it anymore, as you start thinking that way naturally. I did, anyway. I realize everyone's brains don't work the same way though.

I imagine you're right, but as someone who's still in the occasional-dabbling stage of acquaintance with the language (I'm finally at the point where I can do a Fibonacci sequence with only a half-dozen corrections!) learning to think that way is absolutely the most challenging part of the process. Definitely gonna take a look at this.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 28, 2018 8:46 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851
GARTHWILSON wrote:
True, and I do use .S (on rare occasion); but I have little use for it being in a constant display at the top of the window. Numbers on the stack are pretty meaningless anyway when you don't have any description of what they are. It won't say beside it for example, "This is the address of the cell in the header that holds the updated link to the next buffer." The computer doesn't know.

And it can't. That's why the few times I used .S to test something, I choose numbers that were appropriate for the test.Once was when testing ROLL for my kernel. I put something like hexadecimal 1001 2002 3003 4004 5005 and the parameter for how far to roll on the stack, execute and check with .S
Another time, I was testing (DR/W), the block buffer read write word. I put numbers like hexadecimal C000 for the address, 100 for the block number, 1 or 0 for the read/write flag ( those are the actual values used for the flag), and 400 for the size so I could keep track of the parameters easily.
I imagine a constant display at the top of the window would be distracting, or at least mildly annoying, which is why my Forth does not have, and never will have, a constant stack display. On the other hand, .S is included in the system loader, not the kernel.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 28, 2018 10:44 pm 
Offline

Joined: Wed Jul 18, 2018 12:12 pm
Posts: 96
Yeah, real men program with stone tablets and chisels they don't need any fancy programming tools. There is also no need for a fancy display of any kind, not even LEDs all a real programmer needs to do is to stick their tongue to the data bus to check the state of the system. (Said in a humorous spirit :) )

I can remember one programmer whre I used to work got incensed that he was asked to start using a text editor that color coded the syntax. Well! 'He' did not need that! The way I look at it is that I can make due with very low level tools, and hand compile code, and make do with blinking LEDs for a troubshooting aid. Just like I can use a hand plane, a hand saw and a hammer but if I'm building a house I'm going to use power tools and do a better job, faster. Modern programming accutraments are just tools that help the process along faster and give you increased insigt into what is happening.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 28, 2018 11:23 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
I like color in the editor for html since html tags are mostly not easy to pair up visually because they're not indented, vertically aligned, etc.. It makes it easier to find where you're ending the underlining, a particular font, where a commented-out section begins and ends, etc.. In 'normal' programming languages however [1], each one should be either directly across or directly above or below its mate(s). Unfortunately we see a ton of violations of this, forms like this where paired words are diagonal from each other

Code:
   condition if bla bla bla
   yada yada else bla bla then bla

instead of
Code:
   condition
   IF    bla  bla  bla
         yada yada
   ELSE  bla  bla
   THEN  bla

The first version keeps to the misguided notion that Forth definitions should be kept to two lines or less; but the second version is much easier to instantly factor visually, and I'd rather not have the color. In Forth, you can also make your own program flow control structures. A separate editor won't be aware of these, so it won't be highlighting them.

As for simple tools though, I had to work with screen files for a while around 1990, and I absolutely hated it. A good programmer's text editor is way better, and I have it set up so I can mark a block, as short or long as desired, even as little as a single character that's only part of a line, like . or @, and send it to the Forth system (as if printing the block) for execution, compilation, or assembly, as appropriate at the time, without suspending or backgrounding the editor, even though it's in a non-multitasking DOS system. No TSRs, nothing hiding under the hood. Dr Jefyll does a similar thing.

-----------------------

[1] or at least Forth, which is a 'natural language' language, meaning (as I understand it) that a BEGIN structure for example ends with UNTIL, or AGAIN, or WHILE...REPEAT instead of something like } or ; or ). When I wrote my structure macros for assembly language, I patterned them partly after Forth's. (There wasn't much choice anyway, because assemblers' macro languages don't let you use punctuation marks as macro names.) The following example, showing how things are grouped by indentation and structure-ending words, is from my page on simple multitasking. Hopefully the lines won't wrap on anyone's screen and make a disaster of it:

Code:
 ; For the RX_STATEs:
 ; When RX_STATE = 0, an $FF byte will be required to increment RX_STATE to 1.  Other bytes do nothing.  The $FF is discarded.
 ; When RX_STATE = 1, only a non-$FF byte will be put in READING_BUF and increment RX_STATE to 2.  More leading $FF's do nothing.
 ; When RX_STATE = 2, any value received will be put in READING, READING_BUF will be transferred to READING+1, and RX_STATE will
 ;                                                                                                               be returned to 0.


WATCH_ACIA:
        LDA  RX_STATE
        CASE  ACCUM

            CASE_OF  0                             ; In the case of RX_STATE being 0, an $FF is required to increment it to 1.
                IF_BIT   ACIA_STAT_REG, 3, IS_SET  ; If a byte came in (indicated by bit 3 of the status register),
                    LDA  ACIA_DATA_REG             ; get it (this clears the flag in the status register too),
                    INA                            ; and see if it's $FF.  (INA is 1 byte less than CMP #$FF, and I don't need A again.)
                    IF_EQ                          ; If it was $FF,
                        INC  RX_STATE              ; move on to watch for a valid (non-$FF) first byte.
                    END_IF                         ; The accumulator value gets discarded.
                END_IF                             ; If no byte came in, just exit.
            END_OF


            CASE_OF  1                             ; To get here, we've received the $FF marker and we're looking for a valid 1st byte.
                IF_BIT   ACIA_STAT_REG, 3, IS_SET  ; If a byte came in,
                    LDA  ACIA_DATA_REG             ; get it,
                    IF_PLUS                        ; see if it's valid as a high byte, ie, that the high bit is clear, and if so,
                        STA  READING_BUF           ; store it as valid in the buffer area meant to prevent wrong readings between bytes,
                        INC  RX_STATE              ; and move on to watch for the 2nd byte which could be anything.
                    END_IF                         ; If it's not a valid high byte, just discard it, and leave RX_STATE as is.
                END_IF                             ; If no byte came in, just exit.
            END_OF

                                                        ; In the case of RX_STATE being 2, we've gotten the high byte of READING,
            CASE_OF  2                                  ; and we're waiting for the second byte which could be anything.
                IF_BIT  ACIA_STAT_REG, 3, IS_SET        ; See if a byte came in.  If one did,
                    COPY  VIA_SR, TO, READING           ; just transfer it
                    COPY  READING_BUF, TO, READING+1    ; (including the high byte now, which we had saved to prevent glitches
                    STZ   RX_STATE                      ; in the two-byte READING value), and go back to state 0.
                END_IF                                  ; If no byte came in, just exit.
            END_OF


            STZ   RX_STATE                         ; If there's any chance for state to go invalid, just reset it and start over.
        END_CASE
        RTS
 ;---------------------------------------

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 29, 2018 4:11 pm 
Offline

Joined: Wed Jul 18, 2018 12:12 pm
Posts: 96
GARTHWILSON wrote:
I like color in the editor for html since html tags are mostly not easy to pair up visually because they're not indented, vertically aligned, etc.. It makes it easier to find where you're ending the underlining, a particular font, where a commented-out section begins and ends, etc.. In 'normal' programming languages however [1], each one should be either directly across or directly above or below its mate(s). Unfortunately we see a ton of violations of this, forms like this where paired words are diagonal from each other

Code:
   condition if bla bla bla
   yada yada else bla bla then bla

instead of
Code:
   condition
   IF    bla  bla  bla
         yada yada
   ELSE  bla  bla
   THEN  bla

The first version keeps to the misguided notion that Forth definitions should be kept to two lines or less; but the second version is much easier to instantly factor visually, and I'd rather not have the color. In Forth, you can also make your own program flow control structures. A separate editor won't be aware of these, so it won't be highlighting them.


I very much like a nice easy to read program layout as well. It lets you focus on the program not trying to decipher the jumbled structure. It is rather like someone who writes without the proper use of proper sentence structure or punctuation makes their document very hard to read. I have struggled with this in Forth to find out what makes the code more clear to read and what (if any) conventions are commonly used.

I also very much like comments, I first learned to comment well when I learned 6502 assembly as a way of trying to convey to myself what I was trying to accomplish or why I did something a certain way, not just restating what I actually wrote in English. The notion of 'self documenting code' is absurd in my view as the code itself only shows what you did, not what you were trying to do nor why you chose to do it that way.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 29, 2018 8:16 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851
GARTHWILSON wrote:
As for simple tools though, I had to work with screen files for a while around 1990, and I absolutely hated it.

My Forth is for a Commodore 64 so I'm stuck with blocks. Actually, blocks are not that bad, for virtual memory, not so much for source code. My programming style does not seem suited to blocks.
Code:
SCR# 82
// INTERPRET
HEX
: INTERPRET  ( -- )
   BEGIN
      BEGIN
         BEGIN
            BEGIN
               BEGIN
                  BEGIN
                     NAME
                     FIND ?DUP
                  WHILE
                     0< STATE @ AND
                  WHILE
                     ,
                  REPEAT CS-SWAP

SCR# 83
// INTERPRET
                  EXECUTE ?STACK
               REPEAT
               NUMBER ?STACK
               DPL @ 0<
            WHILE
               DROP STATE @
            UNTIL CS-SWAP
            [COMPILE] LITERAL
         REPEAT
         STATE @
      UNTIL
      SWAP
      [COMPILE] LITERAL
      [COMPILE] LITERAL
   AGAIN ; -2 ALLOT

SCR# 84
// QUIT (ABORT)
HEX
: QUIT  ( -- )
   BLK OFF [COMPILE] [
   BEGIN
      BEGIN
         RP! CR QUERY INTERPRET
         STATE @ 0=
      UNTIL
      ."  OK"
   AGAIN ; -2 ALLOT
: (ABORT)  ( -- )
   SP! QUIT ; -2 ALLOT
' (ABORT) IS ABORT

This was copied from a print dump file. I left everything in this section exactly as it was printed so you can see how annoying it is with INTERPRET split across two screens. As for the lack of comments, the Commodore 64 has a 40 column video screen.
The next thing I'm going to do is write a version of INCLUDE for this Forth that reads Commodore sequential files ( each line delimited by a carrage return) and interprets the file one line at a time. That will be the easy part! I only need enough memory to hold one line at a time. Writing an editor to edit Commodore sequential files from Forth? That'll be a challenge!


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 29, 2018 9:35 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Jeff_Birt wrote:
I also very much like comments. I first learned to comment well when I learned 6502 assembly as a way of trying to convey to myself what I was trying to accomplish or why I did something a certain way, not just restating what I actually wrote in English. The notion of 'self documenting code' is absurd in my view as the code itself only shows what you did, not what you were trying to do nor why you chose to do it that way.

Here's a little bit from the "Debugging" page of my 6502 primer:
Quote:
I sometimes catch bugs when further commenting code that's already working but not exhaustively tested yet. I comment as if trying to explain it to someone else who hasn't been following my train of thought on it. (If I come back to change it a year later, I'll need the comments anyway.) As a result of this madness, no user has ever found a software bug in any product or automated test equipment I programmed. The projects have had from 700 to 10,500 lines of code.


Quote:
My Forth is for a Commodore 64 so I'm stuck with blocks.

Ah— makes sense. Blocks definitely had their place in early, simple machines.

Here's my INTERPRET:
Code:
: INTERPRET             ( -- )          \                              SF283-286
   BEGIN   BL WORD                      \ ^ addr
      DUP C@ 0<>                        \ ^ addr f
   WHILE   STATE @                      \ ^ addr f
      IF COMPILER ELSE INTERPRETER THEN \ ^ empty
   REPEAT  DROP         ;


I don't like the over-factoring some people do, particularly if a factor is used only once and it's hard to come up with a concise name for the factor that adequately describes what it does. In other situations, the factoring might be imperative to break a programming problem down into manageable-sized chunks. The factored-out words can, in many systems, be compiled without headers to save space, but there's still the CFA and nest and unnest, and executing nest and unnest takes time too, and more return-stack space.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 29, 2018 11:06 pm 
Offline

Joined: Wed Jul 18, 2018 12:12 pm
Posts: 96
JimBoyd wrote:
My Forth is for a Commodore 64 so I'm stuck with blocks. Actually, blocks are not that bad, for virtual memory, not so much for source code. My programming style does not seem suited to blocks.


No, your not stuck with blocks. Durex Forth is for the C64 and uses files.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: