Color Forth Quick Start

Quick Start Guide http://colorforthray.info

From an actual users point of view...

The colorForth machine/os/language/application/interface ( these words seem to be interchangeable at this level with maybe the exception of OS which really could be defined as YOU) is a rapid program development environment using a clever set of tools to exercise Forths ability to reduce problems to factors of the most minimal level with respect to the machine and operational codes that the colorForth is implimented in.

colorForth as it appears on the disk image is in two sections, a boot-kernel with editor and some services, followed by the section coded in colorForth bytecode. The boot-kernel section will boot colorForth, set up the display and keyboard and floppy drivers, set up the editor and then load one of the blocks ( normally block 18 ) in the bytecoded section.

A colorForth developer is either editing code or running previously edited code. In fact, the source becomes a part of the interface, similar to configuration files in other languages. Variables are stored at the very place in the source that you declare them, change before your eyes in real time when you are viewing a block of running code in the editor where the variable is active, and therefore you can create blocks of interface to your program that you can keep tabs on, even while editing them. Compile time is negligible in this system, and when you are ready to re-load the block you are editing, you empty the dictionaries and re-load the relevent blocks. This happens fast enough in most cases to be imperceptable.

Chuck Moore writes at his site about three defined times in the life of a program as:

Edit time- creating the program using the editor
Compile time - the machine converts edited source into runable code
Run time- application is running

His point being that the earlier a concept can be resolved or even eliminated the better. This is where the colorforth editor is unique in helping the developer.

Roger Levy, fan of these concepts ( and the writer of the Glypher programing language where the original idea was use a colorforth like environment written in Charles R. Childers RetroForth 7 and 8 series, that glyphs could represent entire words, even if the glyph was just a spelled out word, but imagine symbols of any kind... ) explains that there is another time to consider...

Design time - keeping the 3 other times in mind, during Design time, one factors ones problem starting with the first thing that works and then work back to the most efficient usage of all of the necessary resources and time. This Design time uses the other three times to design a simple solution to what she understands is the problem at hand. One solves only the problem at hand, reduces the program to a point where if one more thing were removed from it... it would fail. During Design time one edits, compiles, tests/runs code until the problem is solved to a bullet proof level. The best programs allow the system to run if the program has an error because the only errors we are interested in are ones that are part of the actual problem. During the rapid edit/compile/testRun cycle one crashes often as they try ideas. Instant feedback is a large part of the rapid development capabilities. Run. Crash. Fix.

The usage of colorForth as a problem solver is very simple. The editor is a token creator and can scoop up tokens and move them anywhere. "copy" can copy entire blocks of code to new blocks, where you can strip out code and start from a working program during the entire process. Newer versions of colorForth can change the color of the word on the fly while editing. This is convenient as optional words can be white when not needed and then change to another color when actually needed.

The combination of so many of colorForth's "talents" makes it a bondage environment that is suitable for creating simple macros, or shortcuts where the source is a part of the program's interface. Keyboards are displayed on the screen and one can easily change the functions of the 27 keys that colorForth uses to compose concepts.

All of the control flow is handled by very few in number of simple loops, simple jump statements, simple binary logic, simple concepts. Though many may claim that the source can look as though it were unreadable, this is simply not true. When one knows the "way of the way", the "Forthing" way, this very restrictive, yet very extensible system flows from answer to answer, one may find that the current system as it comes is more then understandable. It's Brilliant!

As an example:

Checkmate in 3... To learn to use the system I decided to recreate a chess game I had then recently finished for ANS forths. In doing so, the differences in using colorForth vs. ANS Forths in respect to my own ability to creatively solve the "problems" involved were perceptively dramatic. The ANS Forth work took nearly a year. And while one can say that during that year I learned enough from ANS Forth to make the colorForth easier to use, the differences in the finished programs and approaches to the problems plainly show that the colorforth solutions are different enough that the ANS Forth example has little bearing on the colorForth versions. AND the colorForths are just more "beautiful".

The first version of the chess uses the "quirks" of the colorForth keyboard interface to it's advantage.

Typeing a piece name, ( composed of color and position, for pawns a color and a column number 1-8: w1=whitePawnColumnA b8=blackPawnColumnH, for all other pieces a color and a side, king or queen, and the piece if necessary: wk=whiteKing bqr=blackQueenRook) ... a piece name, which is defined as the variable that carries a packed xy screen position of that piece, followed by the spacebar puts the address of that pieces variable on the data stack. Hit the spacebar again and you now have the keyboard for entering the number of squares to move. Now when you hit the space bar the number is entered onto the data stack and the keyboard returns to entering words. Now you can pick a direction, u=up ul or lu = upLeft and so on. ( for those that are interested the knights are handled slightly differently where the name of the knight is followed by the word "kn" which adds a 1 after the knights variable address and then duplicates both the address and the one ( a 1 a 1 -- ) allowing you to type a diagnal and a column/or/row direction or vice versa like: bqk kn dr d = black queen knight one block down-right one block down)

This can be used to create a simple peice-movement language. Should one want to define his move as in the format e2e4 or even just e4 as some pawns can do, you can...

: e4

: e2e4 [ w5 ] 2 u ;

... which means the interface leaves you with something you can use to program a game as if you were using standard notation to document what happens on the screen during the game.

Okay, so far pretty typical Forth... The drawing routine for the game picks up each variable and unpacks it's XY co-ord and draws the peice there, a bit map created with the included colorForth ICONS editor. The direction routines obviously take a variable address and a number and move each peice that number by adjusting the portion of the stored variable responsible for the direction the piece is moving in.

Big deal, any forth... Okay, okay, now the point of all this begins to emerge.

A chess board is okay but it's not a game until you can document the moves. Again, the editor is a block editor and co-incidently came with enough color options to make createing a representation of the chessboard written in text easy to create. The kernel section has a word "copy" that can copy a block to another block. Using the editor for chess documentation becomes convenient.

looking like:

c 4 t h c h e s 2 g a b c d e f 9 0 8 r n b q k b n r 7 p p p p p p p p 6 w m w m w m w m 5 m w m w m w m w 4 w m w m w m w m 3 m w m w m w m w 2 p p p p p p p p 1 r n b q k b n r y a b c d e f 9 0

Each line starts with a red letter as the red words include the carriage return, the extent of colorforth formating with the exception that words rap at the right margin. The name of the game "c4thches2" is written in multiple colors. The picture link provided shows the line up. The lines starting g and y are created using the green and yellow hex-keyboards and being that there is no G and H in hexidecimal the 9 and the 0 are used in their place. Lines 7 and 8 are green characters for the green side and 1 and 2 are yellow for the other. the W's and M's represent W=white and M=notWhite empty squares.

Incidently, the white dot characters to the right of the board make each line end in a multiple of 8 so that the cursor control on the keyboard will make the u == up key and the d == down key cause the cursor to go straight up and down a column of ranks. This multiple of 8 offset starts from the begining of the block. So to re-align to the file between the kings and queens, reasonably a center column, that is to center the cursor you hold the up button and the cursor goes to the start of the block at top, and you are re-aligned. Now navigate down to your next piece.

Using the colorforth editor to make a peice move by scooping up the letter that represents the peice, putting it in the new place, keeping aware of blank squares and typing them in when necessary ( could put some extras to the side of the board I suppose ) and then copying that block to a new block sorta trumps all of the previous work I had done. Why? Because it is the simpler solution, which is what colorForth is interested in.

BUT!!! Inspiration. What if we combine ideas. What if we use the editor as our application interface, along with a few words to help us display when the move is done, and to auto copy the move to the very next documentation block, and set up the editor for the next move.

These links connect to screen shots of c4thChes3. The idea here is that the block 172 starts out as the first block of the game. It will be the interface for the game and code on block 21 will copy this block to 174 when called to do so, after the first move, to document the move. Using the editor block navigation it is possible to watch each move as if it were animated to display each move one after another. Blocks 170 and 168 support the game. 170 has individual componants of the display that had to be defined before the interface block(s) could be defined. It was written as appears as I tested self documenting ideas. It is obviously not the most efficient version of the code, but it's easily corrected for production code with out any real loss.

Block 168 displays the name of the game, the board and it's peices, row numbers, column letters, and a MM on the screen that can be changed to indicate whose turn it is. Changing the color means that you finished your move. A two system - two player game might use the change color - your move signal to exectute block 21, documenting the move, then also copy that block to the network code, tranfering the block to be copied in the proper place on the other players machine, arriving to signal his display to display just like yours the updated move.

You may now notice that it is not very far from this program to turning it into an inventory system where you can actually represent where the object is currently being stored in the warehouse. The PartNames? used in such a system could be very descriptive and executing one could report on the things like quantity and cost, next arrival time and how many on current order and how many allocated. Making a change to a block incorporating this copy-load method, its a simple versioning system.

Most every colorforth program of this type can be seen as an extention of the editor. The editor as program, as interface, as extensible op codes, as machine... lines are blurring.

--Raymond A St. Marie, colorCoder. Http://colorforthray.info