Forth Tutorials

[+TheBF]

I actually have 4* in the Camel99 kernel.

I tried it and dropped to 150 mS.

 

[+TheBF]

21 hours ago, FarmerPotato said:

How long if you replace 4 * with 2 lshift?

 

Since this is a tutorial Topic, I will address GDMike's  googly eyed reaction.

 

The good Farmer is making reference to the definition:

: []     ( x y addr -- addr' ) + SWAP 4 * + ;

He is asking  if using 2 LSHIFT ( shift the number 2 bits to the left)  would be faster than using 4 * (multiply by four)

You might asking how are they the same thing?

 

This is a function of binary numbers.

Consider the number 1.

Let's print it as the 9900 CPU would see it:  0000 0000 0000 0001   (spaces inserted for human CPUs)

 

If we multiply 1 x 4   We would get         :  0000 0000 0000 0100

 

In Forth if we do "1  2 LSHIFT"  we get    :  0000 0000 0000 0100

 

The same result!  

So shifting 2 bits to the left will multiply by 4.  Therefore shifting 1 bit left is a 2* multiplication, 3 bits -> 8* and so on.

 

This is done in Assembler with the 9900  shift instructions and if you look up the speed of the shift instructions compared to the multiply instruction, shifts are faster.

 

Standard Forth has the words 2*  (shift left 1 bit)  and 2/  (shift right one bit)  for this very reason. On most CPUs they are faster than multiply and divide.

 

So in Camel99 Forth I added the words  4*  and 8* in Assembler because these are useful in processing graphics data structures like sprites and characters on the TI-99.

 

ANS/ISO Forth 94  added the words LSHIFT and RSHIFT so you can do this to any number of bits as you can do in the instruction set of most CPUs, the 9900 included.

 

Of course the 9900 has more shifts than this in the instruction set and in TI-Forth and FbForth you can see SRC for example. Shift right circular which lets you slide bits to the right and have them wrap around to the other side. Pretty fancy.  

 

Hope that removes the confusion emoji.  

And apologies if you already knew this.

 

 

 

[+Lee Stewart]

2 hours ago, TheBF said:

ANS/ISO Forth 94  added the words LSHIFT and RSHIFT so you can do this to any number of bits as you can do in the instruction set of most CPUs, the 9900 included.

 

Of course the 9900 has more shifts than this in the instruction set and in TI-Forth and FbForth you can see SRC for example. Shift right circular which lets you slide bits to the right and have them wrap around to the other side. Pretty fancy

 

Here are the details for TI Forth and fbForth, which, by the way, have the same names as their ALC counterparts and, in fact, use those same TMS9900 instructions:

fbForth ANS-Forth Description             Notes
------- --------- ---------------------  -----------------------------------
SLA     LSHIFT    Shift Left Arithmetic
SRL     RSHIFT    Shift Right Logical     Does not maintain sign bit
SRA               Shift Right Arithmetic  Sign bit is copied to vacated bits
SRC               Shift Right Circular    LSb shifts into MSb

 

...lee

[GDMike]

I knew shifts were faster but never knew by how much.

I'd definitely do a shift if possible. Great lesson here. 

[apersson850]

Just remember that the longer the shift, the more clock cycles it consumes on the TMS 9900.

But it doesn't match MPY anyway.

[+TheBF]

Since I now have the tools to test on "real iron" I put this to the test.

 

The video shows that using LSHIFT with 2 parameters doesn't give us any benefit this partially because the Forth interpreter is 3 extra instructions so we loose time with each parameter.

Also LSHIFT on the 9900 needed some support code to make it compliant with the standard for LSHIFT.  

I could optimize this a little but it would still be slower than a single shift instruction like 8*.

CODE: LSHIFT  ( n bits -- n') \ shift left arithmetic
              TOS R0  MOV,    \ the shift bits MUST be in R0 to do this
              TOS POP,
              R0 R0 MOV,
              NE IF,
                 TOS R0 SLA,
              ENDIF,
              NEXT,
              END-CODE

CODE: 8*      ( n -- nx8)   \ use in graphics & sprite calculations
              TOS 3 SLA,
              NEXT,
              END-CODE

 8* gives a 33% speed up.

 

 

Edited May 20, 2020 by TheBF
added code for 8*

[+TheBF]

The Simplest Compiler

 

In the spirit of the tutorial topic, I thought I would share something that I actually missed in its importance back when I was trying to learn Forth. That thing is what Forth calls a compiler.

To most other people a compiler is a complicated piece of software and to be fair the Forth compiler "program" is also a little daunting to swallow in one bite. However at the bottom of the pyramid is something very simple.  We will build up this simple thing from its roots and later explain how to use the same concept to make stand-alone programs in Forth.

For review let's start with a block of memory. The memory is a bunch of "locations"  for numbers and each location has an address a bit like the homes we live in. The Forth "compiler" when given a number, puts the number in an empty memory location and informs the system that the memory location is used. That's it.

Here is how it works:

Forth's memory is called the dictionary.  There is a variable that keeps track of what memory is used and what memory is free. The variable is called the "dictionary pointer" customarily called DP for short. 

VARIABLE DP

When you start a Forth system DP contains the address of the next available memory location in the dictionary. Any memory lower than the value in DP is considered in use.

If we wanted to move DP we need to increase its value by some amount. 
How about this?

: ALLOT     ( n --)    DP +!  ;  ( this will add n to the value in DP)

When you need to know where the free memory starts Forth says it's right HERE.   

: HERE  ( -- addr)     DP @ ;   ( fetch the memory location in DP )

With this little tool kit we can make an integer compiler just this easy.

: ,         ( n --)    HERE !   2 ALLOT ;

Notice that the name of the Forth integer compiler is called "comma".

Let's review how it works:

• 1234          consider a number on the data stack
• HERE !       stores the number from the stack at the address "HERE" (ie: the address in variable DP)
• 2               goes on the data stack
• ALLOT       moves the value in DP ahead by 2 (the number of the stack)
• DP            now contains the address of a free memory location. 

 

What good could that possibly be you might ask?
Well computer programs are just numbers stored in memory. 
With our little compiler we could make a TMS9900 program like this:

HERE  0580 ,  10FE ,

We used HERE to put the DP memory location on the DATA stack so we remember where our program begins. 
We then compiled the numeric instruction:  INC R0
Last we compile the instruction JMP $-1 (ie: jump back 1 memory cell)

If we had a way to "branch" to that address on the Forth stack our little program would take off and never come back, looping forever.

 

I hear you asking what if we had to compile a single byte into memory?
Simple.

: C,        ( c --)    HERE C!  1 ALLOT ; ( Forth's "char" compiler)

It works the same as "comma" but only stores 1 byte with "c store" (C!) and bumps the value of DP by 1.

Its now easy to see these simple operators, comma and c-comma, are the basis of making a Forth Assembler.

Some CPUs make it difficult but it is possible to understand the Forth Assembler for the 9900 without much trouble.

We look at that in the next installment and then make an assembler to make stand alone E/A 5 programs.  

 

 

 

 

 

  

 

Edited May 22, 2020 by TheBF

[+TheBF]

Let's Make an Assembler
 

Now that we have a simple number compiler what would it take to make an Assembler for Forth?  For simple instructions that take no arguments (registers or addresses) not very much at all.  The colon compiler in Forth let's us glue things together very easily and gives each routine a name that can be run by giving the name to the Forth interpreter.

Let's define the 9900 instructions that stand alone.

: IDLE, ( -- )  0340 , ;  
: RSET, ( -- )  0360 , ;
: CKOF, ( -- )  03C0 , ;  
: CKON, ( -- )  03A0 , ;
: LREX, ( -- )  03E0 , ;  
: RTWP, ( -- )  0380 , ;

Notice that we name each instruction with a comma on the end. This is just to remind us of what these Forth words really do.  They "comma compile" numbers into memory.

Some 9900 instructions need a single register included in the instruction. For the easy instructions we can simply add the Register number to the instruction!

: STST, ( Rx --)  02C0 +  , ;  
: STWP, ( Rx --)  02A0 +  , ;

Notice we use the Forth data stack to hold the input parameter (the register) and the instruction takes the register value and simply adds it to the instruction and then it compiles the sum with our comma compiler.

 

Speaking of Registers how would we create "named" registers like using the R option in the TI Assembler.  They are just names for specific numbers so this works.

DECIMAL 
 0 CONSTANT  R0    
 1 CONSTANT  R1 
 2 CONSTANT  R2    
 3 CONSTANT  R3 
 4 CONSTANT  R4    
 5 CONSTANT  R5 
 6 CONSTANT  R6    
 7 CONSTANT  R7
 8 CONSTANT  R8    
 9 CONSTANT  R9
10 CONSTANT R10   
11 CONSTANT R11
12 CONSTANT R12   
13 CONSTANT R13
14 CONSTANT R14   
15 CONSTANT R15

You can also find 9900 instructions that take a number or address as a parameter. Since the parameter is a 16 bit value it is not part of the instruction but rather is compiled in memory directly after the instruction. That's easy. Use two commas. One for the instruction and another to compile the parameter from the Forth data stack into the next memory location.  (corrected)

: LWPI,  ( addr --) 02E0 T,  T, ;
: LIMI,  ( n --)    0300 T,  T, ;

 

We can see the convenience of using the reverse notation because we don't have to make a special parser for an assembler syntax. We just use Forth's existing systems.

* About this time the mystique of what an Assembler program does begins to melt away. (but the big programs do more than just this)

 

There are some 9900 instructions that can take an address or a register as a parameter. That means we need to add some decision making to our assembler.  

Here is a routine that can decide if the parameter is a address or not.

: ADDRESS? ( n -- ?) DUP 1F > SWAP 30 < AND ;

Given a number n it returns a true flag if n is an address or a false flag if n is a register.

 

Here is a Forth word that uses the address detector and compiles the correct code for either type of input.

It's not important to understand all the details of this code. This is more about seeing how it's done.

: REG|ADDR,  ( arg -- )  \ register or address compiler           
	OVER ADDRESS?        \ address or register?           
	IF   +  ,  ,         \ compile instruction & address           
	ELSE +  ,            \ compile register           
	THEN ;

Using REG|ADDR, we can define a bunch more instructions

: B,      0440 REG|ADDR, ;    
: BL,     0680 REG|ADDR, ;
: BLWP,   0400 REG|ADDR, ;    
: CLR,    04C0 REG|ADDR, ;
: SETO,   0700 REG|ADDR, ;    
: INV,    0540 REG|ADDR, ;
: NEG,    0500 REG|ADDR, ;    
: ABS,    0740 REG|ADDR, ;
: SWPB,   06C0 REG|ADDR, ;    
: INC,    0580 REG|ADDR, ;
: INCT,   05C0 REG|ADDR, ;    
: DEC,    0600 REG|ADDR, ;
: DECT,   0640 REG|ADDR, ;    
: X,      0480 REG|ADDR, ;

This exercise continues for the rest of the instructions but we won't show them all here. Some require more complicated logic and computation to embed the correct bits into the instructions but the process is the same. It takes a bit of fiddling but normal humans can build their own assembler this way. I have read that some CPUs do make it much more difficult than others to make nice syntax without a lot of nasty extra "add-ons" in the Forth Assembler syntax. The 9900 is not one of those CPUs.

 

The full source code for a Forth assembler is available in all the TI-99 Forth systems. Many are based on the original TI-FORTH Assembler.  

If you dare to study them be aware that they use some "black magic" Forth stuff (CREATE DOES>)  to save space and reduce typing as well as some fancy compiler extensions to create structured branching and looping. (which is pretty cool) All questions are welcome. Don't hesitate to ask.

 

Next Up

In a Forth system, when we use an Assembler of this style, the code and the names of the routines, constants and variables all exist in the Forth dictionary together.  

This is fine if we don't mind the entire Forth system travelling along with our application. In the next writeup we will look at what it takes to turn this assembler into a cross-assembler that keeps the names of routines and variables inside Forth but writes the code and text into a different part of memory so we can save it as an executable program.

 

 

 

 

 

Edited May 24, 2020 by TheBF

[+TheBF]

A Cross Assembler in Forth

 

We have seen how Forth manages it's dictionary memory and how that mixes all the names of routines and the code into one memory space. This is not how a conventional Assembler or compiler works. The regular way this is done is you use the Assembler program which is located in one place in memory. The Assembler reads your program source code and "emits" code into a second memory space.

When everything is finished processing the Assembler saves the different memory data as a finished program file. For the TI it can be save as a binary image (E/A 5) or as an object file but it is a form of that second data space.

 

To demonstrate how Forth normally works we load the Assembler and write this in Camel99 Forth:

CODE ADD2 ( n n -- n')       
	*SP+ R4 ADD,    
    NEXT,    
    ENDCODE

<warn> I am going to go into a bit of internal Camel Forth detail to show regular Forth. 
  This is so we can show the difference with a Cross-assembler. 
  It's not critical to know this to use Forth. 
</warn> 

In memory we see this: 

CB0A: CAF5 0004 4144 4432 ....ADD2      
CB12: CB14 A136 045A      ......

The data dump is described like this: 

• - CAF5 is the address of the previous word in the dictionary (ie: a link)
• - byte 00 the "immediate field" 
• - byte 04 the length byte of the name ADD2
• - 4 bytes that are the string "ADD2"
• - CB14  the address where the actual code starts (ie:the next memory word)
• - A136  the actual TMS9900 ADD *SP+,R4 instruction
• - 045A  the B @R10 instruction. This returns to Forth

All this happens because as we learned before the Forth Assembler uses the comma operator to put the data into the Forth dictionary.

What would happen if we made a different "comma" operator?  Like this:

VARIABLE TDP   \ "target dictionary point"
\ set where the Cross-assembler puts its code
: ORG   ( addr -- ) TDP ! ;

\ Target versions of HERE and ALLOT
: THERE  ( -- addr) TDP @ ;
: TALLOT ( n -- )   TDP +! ;
\ integer and byte "Target" compilers
: T,     ( n -- )   THERE !  2 TALLOT ;
: TC,    ( c -- )   THERE C! 1 TALLOT ;

You can see that things look very much like before but we added a 'T' in front of each word. There is also one new word ORG, to allow us to set the value of the "target dictionary pointer" (TDP) to any place in memory. That's it!  If we replace all the places where comma is used in our assembler to compile actual machine code we automagically get a "cross-assembler". 

For example these instructions become:  (corrected)

: LWPI,  ( n --) 02E0 T,  T, ;
: LIMI,  ( n --) 0300 T,  T, ;

 

I took the liberty of *modifying ASM9900, the Camel99 Assembler program. I loaded the new version into Camel99 Forth and made this little program. 

HEX 3000 ORG
TCODE ADD2 ( n n -- n')       
	*SP+ R4 ADD,        
	NEXT,        
	ENDCODE

Notice I had to make a new word TCODE. This is because the word CODE records the address of the code with HERE.  I needed a new version that records the address of the code over THERE.

A dump of the TCODE definition:
CFBA: CFA7 0004 4144 4432 ....ADD2      
CFC2: 3000                ..      

And here is the break down: (corrected)

• - CFA7 is the address of the previous word in the dictionary (ie: a link)
• - byte 00 the "immediate field" 
• - byte 04 the length byte of the name ADD2
• - 4 bytes that are the string "ADD2"
• - 3000 is where the actual code starts (We set ORG to 3000)

That's the end of the data in the dictionary but if we dump the memory at >3000 we see:
                                        

3000: A136 045A 0000 0000 .6.Z....   

• - A136 is the actual TMS9900 ADD instruction 
• - 045A is B @R10 instruction. This returns to Forth as before

So now we are assembling code into a specified memory space more like a conventional Assembler while the Forth dictionary fufills the role of remembering the names of the routine. This is analogous to Assembler equates, labels, REF and DEF statements.

It is not difficult now to make a routine to copy the code at >3000 to VDP RAM and ask the TI-99 file system to save the data as a program file.

 

An interesting difference between this Cross-Assembler and a conventional Assembler is that we can test TCODE definitions at the Forth console, before we commit them to a file. Nice feature.

 

 

After adding some syntax sugar (ok a lot of sugar like nest-able sub-routines and relocatable images   ) I was able to write this program and the little video shows what it did.

 

\  Cross compiling program demo

NEEDS NEW. FROM DSK1.CROSS99

MARKER REMOVE
HEX
         NEW.
         A000 ORIGIN.

SUB: WMODE
       R0 4000  ORI,
       R0 SWPB,
       0 LIMI,
       R0 8C02 @@ MOVB,
       R0 SWPB,
       R0 8C02 @@ MOVB,
       RET,
;SUB

SUB: VWRITE  ( CPU-addr VDP-addr cnt -- )
       WMODE @@ BL,
       BEGIN, TOS DEC,
       OC WHILE,
            R1 *+  8C00 @@ MOVB,
       REPEAT,
       2 LIMI,
       TOS POP,
       RET,
;SUB

L: A$  S" Hello World!" TEXT, \ compiles a byte counted string

\ main program.........
PROG: XASMTEST
     8300 LWPI,   \ Forth workspace
     SP FF00 LI,  \ set data stack
     RP FE00 LI,  \ set return stack

\ set up to write string
     A$ @@ TOS MOVB,    \ get count byte to TOS
     TOS SWPB,          \ swap byte to other side
     R1  A$ 1+ LI,      \ start of text to R1
     R0 CLR,            \ VDP screen address to R0
     VWRITE @@ BL,

\ delay
     TOS FFFF LI,
     BEGIN,
       TOS DEC,
     EQ UNTIL,

\ return to main menu
     83E0 LWPI,
     R0 CLR,
     R0 837C @@ MOV,
     RT,
END.

S" DSK3.HELLO" SAVE-EA5

CR .( Program size = ) BYTESUSED DECIMAL . .( bytes)

 

                                        
*Footnote:
 When replacing comma in the assembler it's important to know where the comma is compiling CODE versus where it is compiling dictionary DATA.

Edited May 24, 2020 by TheBF

[+Lee Stewart]

A couple of nits...

23 hours ago, TheBF said:

: LIMI, ( addr --) 0300 , , ;

and

3 hours ago, TheBF said:

: LIMI, ( addr --) 0300 T, T, ;

Because I must be a little OCD, this confused me at first. LIMI takes an interrupt mask rather than an address, so it might be less confusing to use ‘n’ or ‘mask’ in the stack effects comments:

: LIMI, ( mask --) 0300 , , ;
   \ ...and...
: LIMI, ( mask --) 0300 T, T, ;

 

And, an oversight:

3 hours ago, TheBF said:

 

A dump of the TCODE definition:
CFBA: CFA7 0004 4144 4432 ....ADD2      
CFC2: 3000                ..      

And here is the break down:

• - CFBA is the address of the previous word in the dictionary (ie: a link)

The link is CFA7

 

...lee

[+TheBF]

Thanks. You caught me moving too fast again.  

I will edit when I get back at my desk.

 

Shift:

I spent some time this afternoon reviewing the early days of this topic on Atariage. When I saw the level of confusion in the discussions I have come to the conclusion that Forth requires a very different teaching approach.

It might literally make more sense to start at the Assembler level and work your way upwards exposing Forth words as just Assembler macros with a return stack and data stack built into the framework.

This is the closest thing I can think of to conventional programming that would allow people to latch onto Forth without triggering their algebraic sensibilities.

Moving carefully that way I think people would have a better chance of getting the fundamentals under their belt so the rest is less confusing.

 

My thesis I guess is that Forth presents a veil of a normal language but it is not and this leads to many assumptions about what "should" work but they don't work as expected.

This leads to frustration and retreat when a threshold of patience is exceeded.

 

It almost makes me want to write a book.  

[+Lee Stewart]

1 hour ago, TheBF said:

It almost makes me want to write a book.  

 

You may be onto something there!

 

...lee

[DavidC]

On 5/23/2020 at 7:25 PM, TheBF said:

 

This leads to frustration and retreat 

 

It almost makes me want to write a book.  

Please.  Keep it simple.   Simple is a relative term, and very difficult to do in the grand scheme of things.  What may be common knowledge to some is a absolute mystery to others.   It took me a few days, and more than one book, reading thru threads and whatnot just to figure out how to save simple WORDS on to a disk drive.   I still refer to my notes to retrieve said WORDS and believe me when I say they aint that fancy.   That is the hardest part,  finding the line between a complete newb that wants to learn and someone who already knows the basics and will get bored with the first few chapters.    Start out with.."This is how you turn the computer on..." skip this if you already know.    Ya know?  

Edited May 26, 2020 by DavidC

[+TheBF]

7 hours ago, DavidC said:

Please.  Keep it simple.   Simple is a relative term, and very difficult to do in the grand scheme of things.  What may be common knowledge to some is a absolute mystery to others.   It took me a few days, and more than one book, reading thru threads and whatnot just to figure out how to save simple WORDS on to a disk drive.   I still refer to my notes to retrieve said WORDS and believe me when I say they aint that fancy.   That is the hardest part,  finding the line between a complete newb that wants to learn and someone who already knows the basics and will get bored with the first few chapters.    Start out with.."This is how you turn the computer on..." skip this if you already know.    Ya know?  

Good advice.  I remember trying to grok Forth.  I had no experience beyond BASIC and I thought because I was pretty good at BASIC and had written a couple of Assembler language routines called by BASIC,  that everything else would be easy. :-)   I booted Forth, started the ediitor and promptly changed the first sector of the disk so Forth wouldn't boot from that disk again. ?

 

I must say that "saving words" to a disk drive is not part of standard Forth so I would expect a lot of trouble finding that functionality. (If I understand you correctly)

On TI-Forth and FbForth it is called BSAVE.  Saving the dictionary to disk can be very platform dependant.  Or maybe you mean how to use an editor to save source code. (?)

 

My thinking on this specific tutorial is that it begins with an understanding of Assembly language. So it's not a beginner level tutorial. It is rather an explanation of a "Macro Assembler for a virtual machine" that is a bit more like the source code to Jones Forth.  The difference is that where Jones Forth is explaining how to make Forth, a language, my tutorial is building a macro assembler for the VM. By not framing Forth as a high level language we remove the expectation of high level functionality but demonstrate how we can add high-level functionality to the VM and it's development system.  I have not decided if there really is a need for this approach.

 

Just spitballing here after a bit of thought; here is an outline:

1. Architecture of the Two Stack Virtual Machine
2. Features of the VM
   1. Separate data and return stacks
   2. Single interface to sub-routines
   3. Implicit parameters use the data stack
3. The Instruction set:
   1. Data Stack Instructions
      1. fetch
      2. store
      3. dup
      4. swap
      5. drop
      6. rot
      7. tuck
      8. nip
   2. Return Stack Instructions
      1. to"R"
      2. from"R"
      3. R fetch
   3. Branching
      1. Branch
      2. Zero Branch
   4. Arithmetic Instructions
      1. add
      2. subtract
      3. divide
      4. multiply
      5. modulus divide
      6. divide with modulus
   5. Logic Instructions
      1. AND
      2. OR
      3. XOR
      4. INVERT
      5. NEGATE
      6. shift left
      7. shift right
4.  An Assembler
5. A Compiler
6. An Interpreter
7. Examples

Etc...

 

[GDMike]

My experience with forth, Turboforth in this case, was not the language so much but actually understanding everything around it, how the screens and editor worked, why flush buffers, the difference between my work and the boot disk of screens that were part of the boot process. As I always kept messing up those words on the boot disk by deleting them to write my own words then finding out I just overwrote words I needed.lol

There didn't seem to be a division between the os and screens that were blank, available for my new words and how much space you have for your own program. I finally figured it out and can fly between disks now, but more documentation needed to illustrate words used to set disk 1 and disk 2 as boot default and workspace, well that was all my problem for awhile until learning s."dsk2.work" use or something like that... sorry if this syntax isn't right, forth requires either a book in front of you with word description or a great memory for remembering the syntax.

I have a good book but bad memory, yes, it's definitely as good as your memory. People like either easy to remember words or good docs or a program that can show you the words and it's definition easily. 

No one wants to work for a program, they want the program to work for them.

[+TheBF]

13 hours ago, DavidC said:

Please.  Keep it simple.   Simple is a relative term, and very difficult to do in the grand scheme of things.  What may be common knowledge to some is a absolute mystery to others.   It took me a few days, and more than one book, reading thru threads and whatnot just to figure out how to save simple WORDS on to a disk drive.   I still refer to my notes to retrieve said WORDS and believe me when I say they aint that fancy.   That is the hardest part,  finding the line between a complete newb that wants to learn and someone who already knows the basics and will get bored with the first few chapters.    Start out with.."This is how you turn the computer on..." skip this if you already know.    Ya know?  

On the other hand this is one of the reasons that modern Forth systems mostly have started using the file systems of what they are running on. So for example in Camel99 Forth there are no blocks unless you want them loaded into the system.

I intended people to use the Editor Assembler Editor.  Save a file and then INCLUDE it into the system.

It's not nearly as convenient or efficient as blocks on a small machine but it is workable.  Being able to load the file and test your code in the interpreter before going back to editing it is the redeeming feature of Forth. So the individual files are are all parts of the project like blocks are and when you want to build the entire project you just included everything in the correct order.

 

It's not a bad way to work.

 

I tried to show that in my manual but I can see where more step by step on a tiny project might be better. I did that with a hello world example I think.

 

[+TheBF]

4 hours ago, GDMike said:

My experience with forth, Turboforth in this case, was not the language so much but actually understanding everything around it, how the screens and editor worked, why flush buffers, the difference between my work and the boot disk of screens that were part of the boot process. As I always kept messing up those words on the boot disk by deleting them to write my own words then finding out I just overwrote words I needed.lol

There didn't seem to be a division between the os and screens that were blank, available for my new words and how much space you have for your own program. I finally figured it out and can fly between disks now, but more documentation needed to illustrate words used to set disk 1 and disk 2 as boot default and workspace, well that was all my problem for awhile until learning s."dsk2.work" use or something like that... sorry if this syntax isn't right, forth requires either a book in front of you with word description or a great memory for remembering the syntax.

I have a good book but bad memory, yes, it's definitely as good as your memory. People like either easy to remember words or good docs or a program that can show you the words and it's definition easily. 

No one wants to work for a program, they want the program to work for them.

I get it. Forth was designed by a guy who lived and breathed computers from university right up to now.  He took a few years to decide what Forth was and when he was done he just kept changing it for himself as the needs arose.

So small wonder it is difficult for somebody wanting to try it for a hobby.  The writing on it seems to indicate it needs to be used long enough for the "penny to drop" in ones head and then it makes sense. This assumes you have the patience to get there.

 

[GDMike]

But after learning and recognizing those things I mentioned, I was writing my ass off! I, for a test, recreated the TI splash screen with sounds (beeps and honks) so easily, especially with the word V! In turboforth.

V@ and V! It's so much easier than hchar and gchar.  But I really can't wait to get back into it, but I've got to finish this assembly program at the moment. But I'll be back...

hey, I can only do one thing at a time!!!

But I do it well. Sorry Lee, explaining my issues isn't one of those things I do well. 

But I've learned a lot by listening to you. 

And the BF is a great writer too

[DavidC]

7 hours ago, TheBF said:

Good advice.  I remember trying to grok Forth.  I had no experience beyond BASIC and I thought because I was pretty good at BASIC and had written a couple of Assembler language routines called by BASIC,  that everything else would be easy. ?  I booted Forth, started the ediitor and promptly changed the first sector of the disk so Forth wouldn't boot from that disk again. ?

 

I must say that "saving words" to a disk drive is not part of standard Forth so I would expect a lot of trouble finding that functionality. (If I understand you correctly)

On TI-Forth and FbForth it is called BSAVE.  Saving the dictionary to disk can be very platform dependant.  Or maybe you mean how to use an editor to save source code. (?)

 

 

 

 Yes, I meant using the editor, putting my words or code or whatever you call it, into blocks and flushing to save them to a disk.    That took me forever to figure out.  I read thru this entire thread until it dawned on me what to do and how to do it.  This thread and other internet resources.  

[+TheBF]

Just now, DavidC said:

 Yes, I meant using the editor, putting my words or code or whatever you call it, into blocks and flushing to save them to a disk.    That took me forever to figure out.  I read thru this entire thread until it dawned on me what to do and how to do it.  This thread and other internet resources.  

So you needed an example, step by step, how to make a program.  Block based systems are so outside conventional practice now it is not obvious what is going on. 

(I watched a video recently of how to start and drive a Model T and it is NOT like today's cars)

 

I needed one too when I started Forth and there was no Internet!

I had to resort to reading the manual. Imagine...

 

There is always a difficulty when experts explain things to beginners on a topic because it is hard to remember the beginners requirements after you know the subject.

[GDMike]

Exactly, these forth OS' take for granted that the user has some familiarity with the useage as does the ti editor assembler book. But finding documentation step by step for the beginner on a particular forth is Missing, but I think if more guidance on the basics were available I think more people would start to like forth. Forth is so flexible and so powerful and I'll always try to code in forth I even have the x86 forth on my PC. Well, that is until my PC died lately. But anyway, I've tackled quite a bit in forth but I haven't dabbled in serial communications or DSR.

[+Lee Stewart]

4 hours ago, GDMike said:

... these forth OS' take for granted that the user has some familiarity with the usage as does the ti editor assembler book.

 

To be fair, they do not really take this for granted. They state explicitly that the user needs to go elsewhere to learn rudimentary Assembly Language or Forth before attempting these manuals.

 

The Editor/Assembler Manual states at its beginning:

This manual assumes that you already know a programming language, preferably an
assembly language.

 

 and in the TI Forth and fbForth 2.0 manuals in Chapter 2 “Getting Started”:

The purpose [of this manual] is to permit those users that have at least an elementary knowledge
of some Forth dialect to easily begin to use TI Forth [or fbForth 2.0]. Those with no Forth
experience should begin by reading a book such as Starting FORTH, (1st Ed.) by Leo Brodie.

 

And, Starting FORTH is. indeed, a very good place to learn Forth. Where the Forth of Starting FORTH differs from TI Forth and fbForth 2.0, Appendix C of the respective manuals has a page-by-page reference of the differences and, where possible, how to implement Starting FORTH’s conflicting definition or solution. The second edition of Starting FORTH is more helpful with TurboForth and, perhaps, CAMEL99 Forth, though there is no similar annotation of differences.

 

...lee

[+TheBF]

14 hours ago, Lee Stewart said:

 

To be fair, they do not really take this for granted. They state explicitly that the user needs to go elsewhere to learn rudimentary Assembly Language or Forth before attempting these manuals.

 

The Editor/Assembler Manual states at its beginning:

This manual assumes that you already know a programming language, preferably an
assembly language.

 

 and in the TI Forth and fbForth 2.0 manuals in Chapter 2 “Getting Started”:

The purpose [of this manual] is to permit those users that have at least an elementary knowledge
of some Forth dialect to easily begin to use TI Forth [or fbForth 2.0]. Those with no Forth
experience should begin by reading a book such as Starting FORTH, (1st Ed.) by Leo Brodie.

 

And, Starting FORTH is. indeed, a very good place to learn Forth. Where the Forth of Starting FORTH differs from TI Forth and fbForth 2.0, Appendix C of the respective manuals has a page-by-page reference of the differences and, where possible, how to implement Starting FORTH’s conflicting definition or solution. The second edition of Starting FORTH is more helpful with TurboForth and, perhaps, CAMEL99 Forth, though there is no similar annotation of differences.

 

...lee

 

Perhaps for the absolute Neo-phyte to programming a set of "Starting Forth" addenda would be the best doc and most expedient for me to produce as you have done.

I think I need to put the addenda on the todo list. Thanks for reminding me of your Appendix C.

 

I have just converted to Libre Office since my machine crashed so I am going over the documents again. As I re-read I have some good introductory stuff in there but probably the world today wants a video tutorial. That's a lot of work...  

[+Lee Stewart]

5 hours ago, TheBF said:

I think I need to put the addenda on the todo list. Thanks for reminding me of your Appendix C.

 

I must hasten to add that I cannot take credit for the bulk of Appendix C. It was present in the original TI Forth manual, though I certainly have edited it---extensively, in the case of fbForth 2.0---but still, mostly someone else's work. 

 

...lee

[DavidC]

6 hours ago, TheBF said:

but probably the world today wants a video tutorial.

No, not necessarily a video.  Just a good explanation of the basics for newbs.  A walkthrough, I guess I would call it.  I don't know.  Video killed the radio star...a basic understanding of what is what.  To put it into regular terms, COMPUTE! magazine had a ton of books published to help people learn just about anything.  With screen shots and 300 pages that kept the reader involved with the learning process. Step by Step.   I don't know how to say what I mean.. The first few chapters were extra simple, the meat and potatoes were inside once the reader got past the unknown, and the deeper you went, the richer the knowledge.  I understand that writing a 300 page book is a huge undertaking and way more complicated and time consuming than it is worth for maybe 20 people that will read the book.   So I guess I should shut up now.   My train derailed...