When I did the blocks code for my own Forth, I put together a basic screen editor with emacs-ish keybindings. It just presumes that it's talking to an ANSI-compatible terminal or terminal emulator, but these days, that's pretty much everything. It also presumes 16 lines of 64 characters for 1K blocks. Happy to share if it would be useful.

--p.

_________________
Mite 6502: http://www.dourish.com/projects/mite.html

My own (rampantly non-standard standalone x86 PC) Forth uses 16/64 block organization as well. It presumes something on the order of an 80x25 display and a PC-type keyboard for the editor, but a certain amount of that is hidden behind some fairly factorable interfaces (CLRSCR, GOTOXY, SKEY (could be EKEY?), a TEXTCOLOR variable, stuff like that). It's a "visual" type of editor, but I didn't go so far as emacs-ish keybindings.

One of the fun features of the third major revision of the editor is that you can ^Z to get to an interpreter prompt that appears below the editor area, and ^Z between the two without losing your place in either.

Looks like 11 blocks of source for versions 2 and 3 of the editor, plus 3 more for the interpreter prompt integration. Because why would your block editor not be distributed in source blocks?

If anyone is interested, I'd be happy to share the source. And at some point I may rebuild it for a more standard-compliant system and possibly for an ANSI-type terminal interface.

I'd love to see how you guys handled the editor, there doesn't seem to be much code out about how they worked. Thank you! We have AT-XY working, and Sam says he knows how to do GET-XY, so that's the basis we have here as well.

So here is some interesting information on 65c02 code in Tali: I wrote a small, throwaway program in Python 3 to find out which mnemonics are being used most, and some other information (see code_statistics in the tools folder). It goes through the program files (main python words, disassembler, ed editor, and main program) and counts stuff. This gives us: So yes, there is roughly one comment every 1.5 mnemonics, which I think qualifies as "rampantly over-commented". But more interesting is the frequency of mnemonics used. The top ten: You can really tell this is a SBC based Forth: The enormous number of JSRs, and all the INX/DEX stack manipulations. The BMI is from the code for underflow checking, which after seing this I'm wondering if should go into a subroutine after all, I hadn't really realized how many times we call that.

It's not really worth the trouble at the moment to try to break down the various mnemonics in their actual opcode variants (it would be trivial with my assembler notation, alas, this is Ophis). The rest of the list:

BMI? I'm curious, how did you implement underflow checking? My Forth also uses the lower part of zero page for the data stack. It's for a Commodore 64 so the stack can't grow as far down as locations 0 and 1 ( 6510 data direction register and data register built into the cpu ). It is also an ITC Forth.
I only implemented underflow checking in addition to INTERPRET's stack checking where I could get it with zero overhead. The x-register = hex 7E when the stack is empty.
The code for 2DROP and DROP checks for underflow just before jumping to NEXT

The line with BRAN, compiles a BPL to NEXT
If there is an underflow, set it to underflow by one cell ( 2 bytes ) to protect the Forth virtual machine registers ( XSAVE, UP, N scratchpad area etc ) while keeping an underflow condition that will be caught and delt with by INTERPRET.
(DO) does something similar ( it doesn't jump to NEXT ).
If you were wondering, SUB compiles a constant in the host dictionary which points to the target's current free memory location, its version of HERE in virtual memory ( the C64 REU ), and sets up the metacompiler assembler.

By comparing the minimally required depth of the Data Stack with the actual depth. DSP0 is the Data Stack Pointer when the stack is empty, and -3 means four bytes (because of the zero etc), so we expect two entries. If there are less than two, the comparison turns negative and we jump to the underflow error routine. There is a longer explanation of this and how to strip off those checks for your own words at https://github.com/scotws/TaliForth2/bl ... rnals.adoc .

This is a classic speed/size trade off at the moment (see https://github.com/scotws/TaliForth2/issues/165): We could move this code to someplace as a subroutine, and then save 224 bytes, but at the cost of 12 cycles per underflow check for the subroutine jump. In a loop, that really ads up quick. At them moment, we have ROM to burn from the 24 KByte reserved for Tali, so we leave it like this. It would, however, be nicer to have something like this in hardware with an interrupt.

Which is why I only add underflow checking ( other than that done in the interpreter loop ) if I can get it with zero overhead, although it's more like underflow limiting rather than checking since it limits the extent of the underflow and lets the interpreter handle it.

How can you get underflow checking with zero overhead?

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

Yes, that's how Tali 1 did it. My problem was that my programs kept not working (cough) and it was hard to figure out why. The compromise here is to have it enabled by default for the core words and allow "underflow stripping" for new words where that code can be automatically removed once you sure it works.

Was Tali originally indirect threaded code?

Did your underflow checking correct the underflow?

What my underflow checking does is leave the stack in a state of underflow but only one cell deep so INTERPRET will abort with an error showing the line with the offending word when it checks the stack. There are six bytes between address hex 7E ( the stack empty position ) and address hex 84 ( N-1 ) so a one cell ( 2 byte ) underflow is harmless. As for the phantom values dredged up from an empty stack, just be careful with CMOVE and friends.

Oh no, always subroutine threaded (SBC). I'm very happy with it because of the massive amount of inlining you can do. No, error routine with reset -- if it blew up, I want to know why quickly. It's sort of an Erlang-Forth that way

Did the underflow checking interfere with figuring out why your programs kept not working? When you say reset, it reset the processor? Maybe it would be better to abort in the outer interpreter.

No, sorry, I wasn't being clear there (I need to stop writing these things too late at night) - Tali 1 didn't have underflow checking, there was just a floodplain. I'm sure somebody who is better at Forth would have been fine, but I just kept having things going wrong and didn't know why. When I have achieved Forth enlightenment (or at least the Third Jhana) I'll rewrite a version without the checks .

Understood.

The third what?