Hee hee. I think structured comments can work, so long as you keep exercising the code flow which reads them.

Well, after sleeping on it, I rewrote the code to look at the label map listing from Ophis and calculate the sizes automatically. Amazing what laziness will motivate you to do ... also got rid of the cycle count, that's unrealistic at this point unless I can figure out how to automate that as well.

Now that would be pure procrastination, as in, not wanting to do those 100+ boring tests.

Lazy programmers are the best programmers!

So I finally did what I should have done long ago to make debugging easier, there is now a primitive disassembler included, accessed with DISASM ( addr u -- ). There is good and bad news here: Bad, because by default, it's in that weird assembler notation I use -- -- though the good news is that it's really easy to replace that with whatever version you want to use, because the disassembler is kept in a separate file named, well, disassembler.asm. As long as the Forth word parameters are followed, you can use what you want. Size is about 2K, and it's as ALPHA as the rest. I've had one or two cases where long words will not stop until it crashes, but can't get it to reproduce as of yet. SEE now outputs both a hexdump and the disassembled code.

Also, Raymond Wiker has added better support for multiple platforms and a real Makefile, so porting should be easier now. Thanks!

FYI, I have Tali Forth running on real hardware (homebrew 65C02 SBC running at 1MHz with 32K RAM and 32K ROM) I just had to add the initialization for my ACIA to the init code, add my routines for getting and putting characters, and adjust the memory map slightly (my IO window is at 7F00-7FFF). Here is a sample run from real hardware:



I suppose I should modify the startup message as this isn't for an emulator anymore. This was much easier to get running on my board than FIG Forth, and the documentation so far is very good.

Tali Forth also seems to run much faster than FIG Forth on my system. I used to need to set up TeraTerm with intercharacter delays and a half-second line delay when pasting forth into my terminal at 9600bps. With Tali, I don't need any intercharacter delay and 200ms at the end of lines seems to work fine so far.

Do you need help testing words?

I'd seen SamCoVT's reply on GitHub first and so initially answered there. In the meantime, he's posted a bunch of bugs there (which I'm working through), and has started adapting John Hayes' Forth test suite (http://www.forth200x.org/documents/html/testsuite.html) to Tali, which would be really cool. It tests Forth with Forth, and the great advantage would be that it enforces ANSI like the big kids. Also, Tali desperately need some sort of automatic testing, I've been having regression issues.

The low-level discussion about adding this to Tali ended up here: https://github.com/scotws/TaliForth2/issues/29

Before, I had been considering a system based on Python's subprocess module to redirect input and output, and have a program that starts py65mon with the Tali binary, gets the "ok" string, and then starts automatic testing by sending a string ("challenge"). It would then wait for the result via redirected stdin ("response"), and compare that with a pre-defined string ("want"). The advantage would be that it could potentially be used for anything running on py65mon (or any emulator, for that matter), not just Forth, as long as you can redirect input and output.

Which leads me to the question if anybody has already done something like this? I've found in my increasing age that I'm rarely the first person to think of something .

Expect perhaps? Possibly in combination with something that generates expect scripts from a higher-level description.

Ah, cool, exactly what I was thinking of. And there is even a Python version. Thanks!

Thanks to Sam Colwell, Tali Forth 2 now runs the Forth test suite originally written by John Hayes, which should really help with regression testing (see https://github.com/scotws/TaliForth2/tree/master/tests). It's not quite all there yet -- Tali is still missing 2! and u< for one thing -- but this should make a big difference in the quality of the code.

Tali Forth 2 has just been released as BETA. Yippie!

"BETA" in this case means "Everything that's there should work, but probably doesn't." Actually, though, a lot should really work because of the ANS test suite, which was ported by Sam and has been invaluable for development. (He also found the infamous "X bug", which shall not be spoken of.) To him and all the other people who helped, thank you so very much.

There is a bunch of stuff still to be added before Version 1.0 can even be considered, such as an assembler and an editor (for a full list, see https://github.com/scotws/TaliForth2/issues). I'm going to have scale down for the next couple of weeks, as Real World is finally catching up to me, but of course welcome any suggestions, corrections, or comments.

Thanks again!

It seems Tali has been mentioned on Hacker News: https://news.ycombinator.com/item?id=17479151

Which make sense in a certain way, because it looks like I'm not going to get a single line of code in the next three weeks ...

That odd-looking clc that should probably be replaced with something like lda 0,x in COMPILE, has migrated to line 1560, where it's hiding as of tonight.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Thank you for mentioning that, Mike B. This is currently listed as a bug and it causes large words to be natively compiled. I got as far as locating it, but ran out of time before fixing it. It looks like you posted a fixed/shrunk version some time back - I had briefly seen it when scanning through Tali-related posts, but didn't realize the changes had not been incorporated into TaliForth2 yet. I'll be sure to check out your code when I attempt to fix this one, if Scot doesn't beat me to it (we are both temporarily low on free time).

Well, Sam won this one. Thanks for that, I just pushed the fixes. Mike, sorry I missed those, that should have gone in a lot sooner ...

Some very, very nice progress the last couple of weeks:

First, Sam has added the building (wait for it) blocks for the BLOCKS word set. Because having blocks but no storage to test them with sucks, he also included a RAM disk (see https://github.com/scotws/TaliForth2/bl ... h_words.fs). It's all high-level stuff at the moment, but the way this works out is 1) Forth version first, 2) make sure the test suite works, 3) move words to "subroutine Forth" (jumps to the words), and finally 4) "assemblerize" the code for space and speed. At some point, there will be a block editor. I've actually become something of a BLOCK covert, once you figure it out, it's pretty nice, and amazingly simple.

Second, I've added a first ALPHA version of the ed line-based editor of Unix fame. There are only a few commands installed yet (ainpdqQw= to be exact) and not all prefixes, but you can write a text, store it, and there it will be, in memory. Under the hood, it's something of a mess, especially the prefix part, and since there is not test suite yet, it's going to be flaky. Still, once it is done it shouldn't be that hard to adapt for the people here who have Forth systems. Current size is 1.5 KByte assembled, including some test routines that will get removed; aiming to stay under 2K. See https://github.com/scotws/TaliForth2/blob/master/ed.asm