Hi All,
Just FYI, I'm working on a project as follows:

The hardware is a small WW board with 6502, 6522, 6550, EEPROM, 2K of RAM, LCD display (16 X 4), and a 22-key keypad. The keypad gives me hex chars, space, Enter, backspace, and a few extras.

The software is planned to be a "teeny-tiny Forth", which will support only a hex character set, and the little LCD display. It will parse an input line by looking at how many hex chars are in the 'word'.

For example, if the length of a symbol is 1 or 3, then it's an 'operation'. If the length is 2, then it's a byte data value (to be pushed onto the Forth stack). If the length is 4, then it's an address (also pushed onto the Forth stack).
So, an input line might look like this:
1234 AA D // deposit data AA into address 1234 (D = 'deposit')
1234 AB 5678 CD 100 // do oper '100' on the 4 params
To compile a new word to do the above, it might look like this:
101 1234 AB 5678 CD 100 // '101' = 'compile'

Any comments are welcome!

It's coming along slowly, as I have time to work on it. When I have the SW far enough along to do the basics shown above, I'll ask Mike to post it to the archive. At the moment, it talks to the keyboard and LCD correctly, and I'm working on the parsing of input lines.

Pete

> The software is planned to be a "teeny-tiny Forth",
> which will support only a hex character set

Does this mean only characters 0-9 and A-F? Is that just to go with the 22-key keypad? I'm sure you're talking about a common intelligent LCD module, which takes care of how to make all the ASCII set and then some. I would suggest making it so the keypad could be used to enter the ASCII codes of all the characters. If you do it much at all, you'll learn them so it's much quicker than you might think to write out command lines, sentences, etc..

> It will parse an input line by looking at how many
> hex chars are in the 'word'.

Teeny Forths in the past have used a name field in a word's header with only 4 bytes. The first byte held the name length (up to 31), plus precedence and smudge bits. The next three bytes held the first three characters of the word's name. As you can see, you had to be careful not to have two different names with equal length and the same first three characters; but it makes FIND a little simpler. I think Commodore 64 BASIC did a similar thing.

>For example, if the length of a symbol is 1 or 3,
>then it's an 'operation'. If the length is 2, then
>it's a byte data value (to be pushed onto the Forth
>stack). If the length is 4, then it's an address
>(also pushed onto the Forth stack).

Is this to simplify Forth words like NUMBER? One of the nice things about Forth is that everything (except numbers) is a word, whether it's an operation, a constant, a variable reference, a structure-control or -defining word, etc.. (Forth gave the tools for object-oriented programming even before it was called OOP).

> So, an input line might look like this:

> 1234 AA D // deposit data AA into address 1234 (D = 'deposit')
> 1234 AB 5678 CD 100 // do oper '100' on the 4 params
> To compile a new word to do the above, it might look like this:

> 101 1234 AB 5678 CD 100 // '101' = 'compile'

The compiling words like : ] , and C, would be well worth holding onto. Never stop dreaming about what might suit your needs better than what's out there; but as an experienced Forth user, I might encourage you to not go so tiny that you leave out some of the really basic parts of Forth that make it so quick to get applications going. Regardless, I'll be interested in what you come up with. I have toyed with the idea of streamlining assembly-language programming by using a set of Forth-like subroutines, but in the end decided the penalties outweighed the small benefits.

Without abandoning the basics, I believe Rockwell got their Forth kernel in the 65FK3 ROM for the R6501Q microcontroller in only 4KB. Most Forths are 8K or more, but some are even less than 4K, including the editor, without throwing out the things that really make Forth what it is. (Talk about efficient!) If you can't get any answer out of FIG these days, let me know and I can photocopy some public-domain 6502 Forth kernels for you if you don't have them. These are not fancy, but have the Forth-79 and FIG-Forth word sets. Even if you don't use them directly, they may save you a lot of re-inventing time in writing your own.

Garth

_________________
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?

Hi Garth,
Thanks very much for your comments!
First, let me mention a couple of general things:
- For me, the 'fun' is in writing the code from scratch. I have source for a 6502 FigForth, but I don't plan to use it in this project.
- I am not really trying to follow any Forth standards, just make something that works, by borrowing some Forth concepts. Perhaps I should call it "Forth-like"... or call it a souped-up RPN calculator, like my old HP-25C...

Below are some specific comments on your comments:

>> which will support only a hex character set

>Does this mean only characters 0-9 and A-F? Is that just to go with the 22-key keypad?

Yes, only those chars, plus space, backspace, return, etc. And yes, it is because of the small keypad. My thought was: "Given that I want to use a small keypad and display, how can I make it significantly more functional than the KIM-1 interface?".

>I would suggest making it so the keypad could be used to enter the ASCII codes of all the characters.

That's a good idea - I could use the 1 or 2 extra keys as 'control' or 'shift' keys, etc. Another option (for the future, not right away) is I could use the serial port to support a complete character set. I would use some front-end code in the serial port handler that would translate words like 'foobar' into their 3-char teeny-tiny equivalent.

>> It will parse an input line by looking at how many

>> hex chars are in the 'word'.

>Teeny Forths in the past have used a name field in a word's header with only 4 bytes...

I will do something similar, but keep it simpler by enforcing the length requirement for all identifiers.

>> To compile a new word to do the above, it might look like this:

>> 101 1234 AB 5678 CD 100 // '101' = 'compile'

I just noticed that this example is wrong - it should be:
101 ABC 1234 AB 5678 CD 100
where 'ABC' is the name of the new word.

BTW, regarding the 'compiling' of new words: I intend to keep this simple by not really compiling anything; rather, just store the word as an ASCII string (high performance is not a goal). So, the example above would be stored as:
'ABC' // name of word, in ASCII. Always 3 bytes.
19. // length of word definition, up to 255.
'1234 AB 5678 CD 100' // word definition, in ASCII

>Without abandoning the basics, I believe Rockwell got their Forth kernel in the 65FK3 ROM for the R6501Q microcontroller in only 4KB. Most Forths are 8K or more, but some are even less than 4K...

I expect to have all the basics, including many of the 'primitive' words, in a 2K EEPROM. I'm going to wire in a second EEPROM (8K) for 'compiled' words. To an experienced Forth user like yourself (I am NOT one), I will no doubt be missing a bunch of features. If I later develop a thirst to be more like "real Forth", then I'll expand things through the serial port interface.

My 65c02 workbench computer that I've used so much in my work relies primarily on one of the serial ports for input. This way I can use the nice text editor (MultiEdit) on the PC for writing Forth source code, and "print" it over to the workbench computer to try it. I say "print" because that's all the PC thinks it's doing-- just sending a block to a serial printer, whether that block is just a word or several pages at once. The workbench computer takes it in, but intead of printing it, compiles, interprets, or executes the incoming source code on the fly as required. Since the serial line only handles text and not comipiled code of any kind, the host computer can be anything with a text editor. It does not have to be IBM-compatible or need any special software besides the text editor.

The idea with typing ASCII codes into the 22-key keypad was that if you want to type "Get", for example, you'd type 47 65 74. You could do this without Shift, Ctrl, Alt, and other such keys, although they can sure add flexibility for for certain things.

Garth

_________________
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?

BTW, one other thing about this project that I didn't explain before:
The reason for the small keyboard and display is that I plan to mount the hardware in a briefcase, and I need to leave room for the following:
- A 6V gel-cel battery.
- An AC supply and battery charger.
- A 'proto-board' for fooling around with interfaces.
- Some Dallas '1-wire' hardware.
- Perhaps a small PIC board (?).
- Other hardware that I haven't thought of yet.

Pete

I recently got things working on this project:
- It implements 18 'words' so far, including a do-while loop.
- It's mounted in a briefcase, with a battery, etc., so I can sit it on my lap while I implement more 'words'.
- One thing I changed related to earlier discussion: I'm not storing a length with each word; rather I carved up the EEPROM into 32-byte 'blocks'. Each word therefore uses a multiple of 32 bytes (all are 1 block so far). This approach simplifies the 'find', and I figure I have plenty of space to work with.

The top of the source code listing describes how things work, and lists the current 18 'word' definitions.

The source code is on my web site at:
www.geocities.com/saipan59/robots/lcd.as
Other 6502 and PDP-11 related stuff can be found by using this instead:
www.geocities.com/saipan59/robots

Any comments are welcome.

Pete