I've just ported Tali forth to my little Ruby 6502 SBC so thought I'd write a few words on it..

But before I do - I'd just like to say (before you get the wrong idea!) I'm not really a Forth enthusiast. I have played with it in the past (Graforth on the Apple II) and been paid to write stuff in it (Porting Suns OBP to new Sparc hardware), but it's not really for me.

However, after chatting to a Forth enthusiast yesterday I thought I'd look at some Forths. I'd already implemented something called Fast-Forth on my system - and looked at some others which were ROMs designed for the Acorn BBC Micro (My system is compatible enough to run some well-behaved software) but I thought I'd have a look at something completely different.

ScotWS's Tali looked interesting, so I got it https://github.com/scotws/TaliForth2 and gave it a go. A couple of false starts later, and with some adaptation for my system and it seems to be working well. At 24K it's 8K larger than the biggest BASIC I've run on it, so another good test.



that's a screenshot of the terminal interface to my system - I load up Tali from the SD card and start it, do the obligatory Hello World and exit. What more could you want

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

That's awesome! Thanks for giving Tali Forth 2 a spin. I'm actually interested in your false starts, if you wouldn't mind elaborating. Do you have any suggestions for making Tali2 easier to port to new hardware?

-SamCoVT

I sent Scot a few PMs, but not had anything back, however, in no particular order:

Install the "ophis" assembler which meant installing python. I also changed the Makefile to pick-up the path to the assembler as it seems to use itself and the directory it lives in for it's program segments. I use ca65 normally and can't stand Python, so if that step had not gone well, I'd have given up at that point.

I needed to get the image to 24K. I simply used 'dd' to truncate it to 24K. This didn't initially go well, so had to remove the .advance directives in the platform file. (so the suggestion here is to just generate the 24K image with notes to allow others to bolt-on their own OS bits)

(Also; Linux. Good thing that's what I use... I've no idea how MS Pc/Mac people would cope with a Makefile and Python)

End of line output is NL only, so had to make my putchar routine add a CR. (so again, notes, or an option in the system itself to do the CR+LF thing)

I had to change buffer0 start to higher in RAM for my system ($0E00) I was glad that option was there - and seems to work.

I added some "boilerplate" to the start of the image at $8000 to make it fit better in my system (Gives the application name, copyright in the *help output)

And I think that was it. My initial PM to Scott was essentially "will this break anything" and so-far it doesn't seem to have...

What I would like is some hints to read the input line before forth sees it - the way I do that in Applesoft and ehBasic is to peek at the first character of the input buffer and see if it's a star (*) and if-so, then call my OS, so typing *cat would work, slightly more forth compliant might be star ." cat" but harder to type... The main reason for this is that I then have a means to read text input from a file via the *exec command, so it would make an easy way to get files into the running forth without writing additional words into it to call the filing system.

As my Ruby system is sort-of BBC Micro-like, the binary I've made would probably work on a BBC Micro 6502 2nd processor but I've not had a chance to try it. To make it properly work the start of usable RAM (OSHWM or Page in Acorn terms) ought to be obtained from the OS rather than hard-coding in $E00 but it's not that big a deal here.

I just got some code from another Forth enthusiast to try - failed at a lack of a 'ms' word for some timing - which I understand is going to be very platform dependant anyway, however I may look at the docs to see how to implement it but when I tried to add in the star command stuff it all broke very badly, so I suspect I'm stepping on stack or something else that it didn't like and not being a Forth programmer, some of the acronyms in the source mean nothing to me.

One good point: It seems to only use ZP 0 to < $90 and my OS uses $90 upwards so there was no clash there.

A "nice to have" would be the option to call an operating system routine to get a line of text - my OS supports command-line editing and history and I've changed applesoft and ehBasic to use it (bbc basic and other Acorn languages use it by default) so there is a common-user experience, however I appreciate that the number of users using my system right now is one...

However on the whole, not much harder for me to port than ehBasic.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The idea behind generating a 32K image was to try to make it easier for folks just starting out so they can just program a 32K ROM. Adding a method to generate a 24K image is a good idea, and I'll look into that.


All of the Tali developers are definitely using Linux, and it shows, but Tali will compile on windows either by using cygwin (to get python and make) or by installing python and gnu make separately. Macs come with python and make already installed these days. Python is not a language I enjoy using, but it's what the project was using when I stumbled on it.


That's a good one I hadn't thought of. I have my terminal set up for only LFs, but I agree that you should be able to set that up or that it should be documented on exactly where to adjust it. The putchar routine is probably the best place.


I'm glad that worked out for you. Tali is quite tolerant of what ends up where in memory as long as it knows.



If you want to peek in the input as it is read, you can check out ACCEPT (search for xt_accept:) in native_words.asm and the spot where the entire line has been read in is the _done: label. This is just before it has been placed in the history. The number of characters is located at "0,x" and the address where the string starts is in "2,x" and "3,x", but it is also more conveniently in the two-byte variable "tmp1" in ZP.
If you want just after it has been saved in the history instead, then the z_accept: label (just before the rts) is the spot and the values are in the same locations.

The "recommended" way would be to create a new forth word to accept any string and hand it to your OS routine. If you know the address of a routine, you can run it directly in Tali Forth 2 by using the execute command like so:

The hex and decimal switch the number encoding for input and output in Forth. The F123 is the address in hex, and the execute word will run it. To make this a word, like "os" (the word * is already taken, and while you can redefine it, you might miss multiplication later) you might say:

Your routine just needs to know that the character count is at "0,x" and the address is in "2,x" and "3,x" and it should probably save and restore the X and Y registers. It should remove the string address and the number of characters in the string from the data stack by running inx 4 times (or adding 4 to x). I'm assuming you'll need to shuffle things around to the locations your OS is expecting to process the line. If you get this working, you can add the forth code to "forth_code/user_words.fs" and it will be run at startup of Tali Forth so that the "os" word is available for any Forth session.

The "better" way would be to just write your "os" routine using the built-in assembler, but if you're just starting to play with Forth, that might not be a good place to start. Forth assemblers are often considered "extra weird" if you haven't gotten used to Forth yet.


Tali Forth 2 requires a 65C02 processor. It won't run on an older 6502.


A quick and dirty ms word (assuming it takes how many milliseconds on the stack) might look like:

ms isn't a standard word, but it should be easy to implement. The code above loops the correct number of times, but doesn't actually do the delay as that would be hardware specific, as you correctly stated. If you want to post the code you are interested in, I can probably help you get it running. If you tell me your CPU clock speed, I can help you get the timing close as well.


xt_accept in native_words.asm is the code to replace. If you want to leave the existing code there for reference, you can replace it with your own routine, which might have the structure:

Your code will need to take a count (0-255) at "0,x" and the address of where to put the string at "2,x" and "3,x". When it's done, you need to remove one of the arguments on the data stack, which is kept using the X register ("inx" twice to remove one 16-bit value) and then fill "0,x" with the number of characters read and "1,x" with zero. You can use any of the ZP temporary variables (eg. tmp1, tmp2, tmp3 (16-bits each)) that are used in the existing version of ACCEPT.

If your code can meet those demands, you should totally be able to replace the existing version of ACCEPT.

Then you can go into headers.asm and locate the header for the accept word.

This will now use your version for all calls to accept. You can check out the "Internals" chapter in the manual for more detailed information.
One note about doing this is that it will break the ability to redirect the input (I/O is vectored in Tali2), but I don't believe that breaks anything in Tali itself - you'll just lose that ability. It's probably not a big loss if you just want to play around with Forth.


I'm glad to hear that. That was the goal of the project. Thank you for taking the time to outline the sticky points in the porting path. I think you've shown some places where porting can be made easier for new folks.

-SamCoVT

I can't speak to Tali, but in a "normal" Forth, if you wanted to add in command line history, then you would want to essentially replace the EXPECT word, as that's the "enter a line" routine for Forth.

One caveat is that normal EXPECT tracks how many characters have been typed (as the number to, well, expect, is a parameter to the word). So, in theory, as you cycle through the lines, you would have to maintain that value. You may not. It's mostly used for two things. 1) to tell the word when to stop (if you passed 80 as an argument, on the 81st character, it's returning -- newline or no), and when to stop backing up with BS. When it's 0 and you hit BS you get a BELL.

For older Forths, I would agree with you. EXPECT has been marked obsolete and replaced with ACCEPT in ANS Forth since the ANS94 standard. Some ANS Forths still have EXPECT implemented, but Tali (following the ANS2012 standard, which was the first to officially remove EXPECT) does not.

The two words aren't quite equivalent, as EXPECT stores the length it actually read in the variable SPAN (also obsoleted by ANS) and ACCEPT returns it on the stack instead. Besides that difference, they are essentially the same word.



Tali stores the history in an array of counted strings (the kind where the first byte is the length). Only 128 bytes are reserved for each counted string, so only the first 127 characters are actually saved in the history if ACCEPT was called with a larger number and read a larger string. It also will truncate on recall if the history string is larger than what is currently being requested.

Thanks for the update. Too much to reply in-line, so will just answer a few bits -

The BBC Micro 6502 2nd processor is only that by name - they are all 65C02.

However, I'm somewhat surprised with Tali - if it's a new, state of the art Forth, it seems to me somewhat old-fashioned with blocks, no screen editor, no easy interface to a modern filesystem (or even a 40 year old one)

So maybe I should not be looking for a "bare metal" Forth, as Tali describes itself. Or maybe I'm just not cut-out for Forth! So I may just leave it at that, for now.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I'm here! I'm here! Sorry for the late answer, and thanks for all the suggestions, and thanks for Sam for already answering. I hope to be able to get back to actual coding soon, and your points are very good ones.

You'll be happy to hear (or maybe not, grin) that Microsoft is making it easier to work with Python (https://www.onmsft.com/news/learning-to ... uch-easier). The decision to use Ophis with it's Python base might have been, ah, curious, but it was what I knew when I started, and I sort of got carried away with the project, and so here we are now ...

(To anybody reading this, is this big enough of a problem that we should switch to ca65? What would the advantages be? I know the Steckschwein people use it.)

If you look at https://github.com/scotws/TaliForth2/issues/232 , there is a discussion about raising Tali's size to beyond 24k, which I take it would not work at all for your machine? Space is getting to be a problem, especially because we're thinking of adding multitasking.

Don't let this turn you off Forth, though, for the full, kitchen-sink-class experience you might want to try Gforth. You'll never be the same after a few weeks with the language .

You'll be happy to hear (or maybe not, grin) that I do not use MS products unless I have no choice. I also do not program in python - ever. I simply have no need or desire for it.



I'm using ca65 - for not reason other than it works for me on my chosen platform and I can make it work in my somewhat old-fashioned Makefile + editor environment. It lets me modularise my software onto many small, manageable files and link it all together. I'm sticking to that until I get my own assembler finished - with the intention of that running under the OS on my SBC.



For me, code size isn't a real issue. The reason I wanted it under 24K was the nature of my operating system. In my system, "applications" start at $8000 and extend upwards. My OS currently starts at $E000 and extends to $FFFF, so that leaves 24K for the application starting at $8000. Application data being from $0E00 upwards with a few private pages below that. However I'm about to "take" the next 4K down for my operating system as it's outgrown the 8K it has (really 7.5K due to IO space, vectors, etc.) so I'd have to move Tali down anyway. The reason for the $8000 start is historical - it's where language ROMs or other applications started in the BBC Micro. I can load & run code anywhere from $0E00 upwards, but a special sequence of bytes at $8000 will be identified in the 'help' output.



I'm not a fan or active user of Forth. I made that clear at the start of this thread. I'll never use Forth in the same way I'll never use Python. I have in the past, but I have no use, need nor desire to use them now or in the future and no-one is going to offer me money to write code in them (mostly because I'd turn them down). It was just a curiosity because I was speaking to someone locally recently about it, and sadly, because of it's bare-metal nature, then I lose the principle of least surprise when running applications on my OS (e.g. they all use the same getline code which automatically gives them editing, history, easy use of a local filing system, etc.) then it does not fit well with my system, so my enthusiasm to do any more with it simply isn't there.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

A wee bit off topic, but is there a "better" open source, cross platform assembler out there for 65xx? CA65 and it's suite of tools is pretty sophisticated.

I think that the fact that the community does not standardize on an assembler for shared code is a hinderance, and I'd wish we'd pick one.

I'd almost suggest a new thread, but I think it very likely that we've already had at least one on that question.

See this: https://xkcd.com/927/

Everyone has their favourite and some just like to write their own. I've not found it too difficult to convert (mostly historical) stuff to ca65 format - the "worst" (or hardest to convert) is probably anything down in BBC Basic assembler where the assembler is built into the BASIC interpreter and you assemble code by wrapping the code in a FOR loop for the 2-pass assembly...

Using macros is the biggest issue though.

And to add to the growing list, I'm in the middle of writing one myself, however this is because I want it to run directly on my SBC rather than be a cross assembler. "Back in the day" I used the TED II+ assembler on the Apple II (as well as the BBC BASIC one). Mine is ending up looking more or less like ca65 though (by intention as I want it to be compatible)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/