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

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

Your interrupt task could easily be in assembly (just put it in your platform file). You already have an ISR that handles serial, so it would have to handle both that as well as a timer, but Garth's primer does a good job showing how to handle multiple interrupt sources. It should be possible to write ISRs in Forth, but it's more complicated and would be a bit of an adventure. Tali is an STC (Subroutine Threaded Code) type Forth, so it compiles runnable 65C02 op-codes into the dictionary. Tali also has an assembler, so you can write assembly directly from Forth and even mix Forth and assembly when compiling. You would need a way for your firmware ISR to be able to run a RAM routine (if it exists) - Tali leaves half of zero page free for you to use so you might put a RAM vector there.

Tali can compile a LOT of words before you run out of space. On a 32K RAM system, there should be about 29K free at startup. The Tali test suite is the only software I know that actually would use all of that RAM, but it has a lot of extreme test cases, like a 4K RAM drive and strings longer than 256 characters. The test suite uses MARKER to set a point to return to at the top of each test file and runs that word at the end of the tests to restore the dictionary.

It is very possible to compile words that crash Tali. In particular, Tali does not have "compiler security" so it is possible to write an IF and forget the THEN or write a DO and forget LOOP. These kinds of words, with mismatched or missing flow control words inside, are likely to crash Tali. Many flow control words compile a jump to address 0000 that is replaced by the ending word once the address to jump to is known (eg. only when we reach THEN do we have the address to jump to if an IF-THEN is false, so THEN goes back and "patches" the IF). There is no code at address 0000, but the 65C02 will read the data there as if it is opcodes and try to run it.

The standard way I test to see if I've made a mistake is to do a .S after defining a word. If there is extra stuff on the stack (these are the addresses of opcodes that need patching) then I've definitely made a mistake. Here's a silly example to show that:

Code:

: test if 8 . ;  ok \ Make a word test that prints 8 if true (but I forgot the THEN).
.s <1> 2063  ok \ Check the stack afterwards - oops, there is an address there and the stack should be empty.

Breaking code into small pieces held in separate words helps to narrow down these kinds of errors.

On a separate topic, some folks are discussing FORGET, however Tali does not have this word. It uses the word MARKER instead. It's true that you have to know ahead of time that you'd like to come back to a particular spot and create the MARKER word ahead of time. When you run the marker word, Tali removes all words (defined after the marker word) in all wordlists (Tali uses wordlists, which operate a little differently than the older VOCABULARY based Forths) and resets the search order (which controls the order that wordlists are searched in - first one that has a word of that name wins). If a new wordlist has been created after the MARKER word, it is also removed. Here is an example of using MARKER, and you can look at the test files (in /tests) to see them in actual use at the top and bottom of test files.[size=115]I rarely use MARKER in daily use. I prefer "reproducible state" where I keep all of the definitions and all of the words to run in a file (on my computer) so I can get to a particular state from a cold start. That way, I can reset my board, paste that file in, and be in a known state. I can try to some code, and if it works then I add it to the file and now that is my reproducible state. Also, if I need to go to bed and pick things back up tomorrow, I only have to boot up my board and paste in my code to be right back where I was the day before.

Well, this is getting a little esoteric. I rather like the idea of FORGET I have to say. MARKER also seems to have its place.
However:
On a simple machine such as my SBC SamCoVT's way of working is the way I ended up working. Blocks with code in them got tedious very quickly and either a punch of the reset button followed by a file upload is as quick a way as any - for me at least. On a more capable machine, working that way would be less conveniant and MARKERing and/or FORGETting probably a nicer way to work.

Anyway, SamCoVT, on the interrupt routine, I am already done. My other obsession in real life is clocks so I just had to get one working on the SBC - its a background routine to update a RTC and a foreground Forth word to display it.
Thanks also for the info on the ways to crash Tali!

When I use SEE to look at a word, often it seems the disassembly goes wrong and gets confused. If I hand dissassemble it there is nothing wrong (and the words work). Is the disassembler still a "work in progress"? I can post examples.

Please post a few examples of disassembly attempts failing. It should be able to be fixed or explained.

if I use SEE to look at this word I get:

I guess, looking at it, the problem is the inline numbers.

...and thinking about it more, perhaps I am making assumptions again. I assumed it would be a sort of hybrid disassembler that, since it knew about the words it is disassembling it would skip non-assembler bits like inline numbers.

If it was smarter, it would do those things. The issue is the literal values (41, 42, 43) in your code. Those are saved as a jsr (at address $9388) to routine that grabs the literal value from RIGHT AFTER the jsr. It then fudges the return stack so that when the routine returns, it returns to JUST AFTER the constant value. The routine is named literal_runtime in Tali's assembly (native_words.asm), but has no name in Forth.

Looking at the hex dump near the top might help see what is going on. The 20 88 93 has a JSR to address $9388. The two bytes that follow that are 41 00 and that's your 41 as a 16-bit number (eg. $0041, stored little end first). Tali's disassembler isn't smart enough to know that the literal value is not opcodes, which is why you see the 0 eor.zxi there. For the next literal constant, that one is not even a valid opcode so you get the ?. Sometimes the data value will match up to a single-byte or 3-byte op-code and then Tali is off by a byte and messes up the next valid opcode as well.

Tali also doesn't look in the dictionary to see if a JSR jumps to a word with a name, like many other Forths do, but it also inlines assembly code for short words (rather than compiling a JSR to them it copies their assemble over into the new word) so that may be of limited use.

The short answer is that Tali's disassembler is not the best and could be better. It does not properly handle literals or other data mixed in with opcodes. If you'd like it to be better, you are welcome to open a ticket on Github. There is room for improvement with even just a small amount of work.

Thanks Sam. I had worked out what was going wrong with the disassembly. It would be a "nice to have" improvement so maybe I will open that ticket.

I have done the ISR and now have an internal clock (as per Garth's code). I have done ROM based subroutines to write to the LCD and IO to i2c and they are working great.

I was looking at Garth's "Zero-overhead interrupt service in Forth" pages and contemplating implementing that within Tali - just as an exercise. Garth says his technique would work in most indirect-threaded systems. Tali is subroutine threaded so the first step is understanding those systems and deciding whether it is actually possible to apply Garth's technique to Tali. All good fun.

I may have spoken too hastily...
... actually handshaking isn't working properly, at least it doesn't appear to be. I had put a line delay of 50ms in to my terminal program and forgotten, so it looked like it was working. I just removed it and comms locks up after a few hundred bytes.
The code in the platform file (relating to serial IO) is as in the original taliforth-sbc.asm file and I can see that the RTS line goes high simultaneously with the lockup - so it seems Tali is saying "whoa-hang fire". I have set my console program TeraTerm to RTS/CTS handshaking so I just can't see why it hangs. I note in your SBC [SamCoVT] that you use a Rockwell 65C51 as do I.

I am using a Win10 laptop (sorry, all you Linuxers out there) - does anyone know if I have to do anything else on the Win10 machine?

Edit. I am going to post this somewhere else as it is a) off topic really and b) driving me NUTS!

I've updated the master-64tass branch to include proper handling of literals when disassembling. This helps the situation drastically, although it still gets confused by things like strings that jump over the data. I thought I was going to have to do special handling for variables as well, however I found that variables are always compiled "Never Native" (they have to be in order to work properly) and so they will always be a JSR and the regular name lookup works fine for that. Here's the new output from your example.

Code:

: lcdchrout ( do nothing for testing ) ;  ok
: abc 41 lcdchrout 42 lcdchrout 43 lcdchrout ;  ok
see abc
nt: 812  xt: 81D
flags (CO AN IM NN UF HC): 0 0 0 1 0 1
size (decimal): 24

081D  20 88 93 29 00 20 11 08  20 88 93 2A 00 20 11 08   ..). ..  ..*. ..
082D  20 88 93 2B 00 20 11 08    ..+. ..

81D   9388 jsr     LITERAL 29
822    811 jsr     lcdchrout
825   9388 jsr     LITERAL 2A
82A    811 jsr     lcdchrout
82D   9388 jsr     LITERAL 2B
832    811 jsr     lcdchrout
 ok

Note that SEE changes the base to hex, so all the literal values are in hex. If you use DISASM (which takes ( addr n ) to define a range to disassemble) it will use the current BASE. For the above, SEE says that "abc" starts at $81D (looking at XT field) and is 24 bytes long (size field), so in decimal mode I might say "$81D 24 disasm" to see the results in decimal. The $ in front of a number allows you to enter hex values regardless of the current base.

Note for the above note: using disasm in decimal mode shows the addresses in decimal as well.

Edit: I just realized the original example was in hex, in which case everything will work out and you can ignore the above notes!