Suggestions for making Tali easier to port to new hardware

[SamCoVT]

Gordon (drogon on the 6502 forums) recently ported Tali to his hardware and had a few suggestions:

Have the ability to make a 24K image (it looks like he is loading Tali from an SD card). This should be as easy as a new "platform" file.

Discuss in the porting instructions how to set line endings for the output. Tali defaults to LF only, while his terminal is set up for needing LF and CR. He ended up putting it in his putchar function, which is probably the best place for it.

The good news is that he rated Tali2 as "not much harder for me to port than ehBasic", which I think was pretty much our target for ease of installation.

[scotws]

Sorry to all, I've been caught up in Real Life Stuff for weeks and weeks now and have not been on pretty much any forum; I'll try to catch up to the discussion next week, when I should have some time. -- So there are two issues here: Moving line ending definitions to putchar (which we should probably have done immediately) with docs, and second, add a way to make 24k images?

[SamCoVT]

I've helped Druzyek from the 6502 forums shrink Tali down to under 16K. It actually wasn't that hard. I removed (commented out) block support, both editors, the assembler, and a few other choice words to get it around 14K. I'd like to propose having some method in the platform file that could be used to select pieces of Tali2 to either include or not include.
One difficulty I can see is that Ophis doesn't seem to support conditional assembling (something like #ifdef). You had mentioned possibly changing to a different assembler - if you really want to do that, I recommend finding one that supports conditional compilation/assembling.

It looks like you anticipated this in taliforth.asm with some .require statements that are commented out - I think that method can work, but we will need to move the matching headers into separate files as well. Making the separate wordlist headers "link" together will likely be the most difficult part.

[SamCoVT]

I think it makes sense to organize the ANS words around the ANS wordsets. If you don't need block support, you can remove all of the block words. If you don't need double support, you can remove all of the double words (there will still be doubles, eg. NUMBER will still be able to make them, but words like D+ and D< will be removed).

I'd also like to be able to remove the wordlist support (which would be the ANS search wordlist). When I did this for Druzyek, I left the general structures in places, but removed all of the words to access them. In that mode, only the Forth dictionary is used for compiling and for word lookups, which works great. Fortunately Tali's lookup mechanism isn't actually using the ANS search words - I had considered rewriting it to make things a bit smaller (at the expense of speed), but this is an argument for leaving it as it is - it allows the removing the the ANS search words.

I did have to "relink" things in the headers manually to stitch the wordlist back together when removing words - that's where conditional compilation would be very handy. It would also be handy to reorder some of the words in the wordlist so it's easier to remove an entire section instead of having to remove individual words.

For non-ANS words, like the assembler and editors, I think there are obvious groupings that make sense.

[scotws]

I think #252 - conversion to 64tass will be a bit step towards this. Once we are working with 64tass, we should revisit this.

[SamCoVT]

generate_wordlist.py may need to be made smarter if we have optional words. If it can't find the xt_ and z_ labels it currently gacks. It should gracefully report that the word does not exist.

The other option is to leave the labels and just remove the code. While that would have the nice side effect of reporting "0" for the size, I don't like it very much as I'd like to use conditional compilation on a bunch of words at once (eg. the block editor or wordlist words) with a single .if and .endif.

[SamCoVT]

#260 appears to be working nicely and is a good step towards closing this. The ability to make 24K images (well, images that were the exact right size, really) was added into the Makefile for ophis (you just ask it to make taliforth-platformname**.prg**), but that will need to be updated to work with 64tass. I think that will just be a deep dive into the command line options for both programs to see what Ophis was being told to do and what 64tass needs for command line options. I'll create a separate ticket for that (#261)

[SamCoVT]

Just a note for me: If the BLOCK support is removed, the 1K buffer can also be removed. See the constants in cold_zp_table: in native_words.asm - the first one could use some conditional compilation to remove 1K block buffer (but leave the 256 bytes for user vars) if block support is removed.