Either are perfectly standard EXITs. There are processors that do one faster and processors that do the other faster, and on those processors, the model will follow suit. IIRC, the 68K has a very fast four byte NEXT based on an available JMP ++(...) operation.

Many 6502 models are symmetric, and the approach is often based on parts of a model being ported from another processor's implementation.



If it only trips up when bumped up to $xx00, and not when bumped to $xx01, I'd revise what I said and say that I'd probably toss in a NOP. But that's not advice, it's just the way I'd probably tackle it.

If shifting to "PUSH ++IP->RS; ..." / "POP RS->IP" cleans it up, that has the appeal that in case there is some other application-specific word that may run into the same or similar issue, the issue has already been cleaned up.

Thank you for the validation. I had only dissected a few other Forths and they used a post-increment EXIT. My inner interpreter (ENTER, EXIT, (+LOOP), (LOOP), etc...) is rewritten now and works well with the pre-incrementing!

For my next trick, I'm revisiting SAVE-BUFFERS and LOAD-BUFFERS (also VERIFY-BUFFERS which is a minor variant). PETTIL stashes blocks of virtual memory in (what I am calling) "packets" in a structure that builds downward in upper RAM. A packet is either "data" or "screen" and is either "compressed" or "uncompressed". Those two bit flags and a "size" form the 16-bit packet header. For compression, I use run-length encoding, which works well for typical Forth source. A screen packet will have 24 bits of "linewrap" stored adjacent and below the packet header. Each bit indicates whether that physical line is the start of a logical line, or not. Only 24 bits per screen are required, because physical line 0 is always the start of a logical line.

When I started writing this, the scope was intended to be a nifty Forth for my hardware PET. Project scope has expanded to the rest of the Commodore 8-bit line, which means adding disk support. The virtual memory buffer (all those packets) will load to a different place every time. Since all navigation is relative (only sizes, no absolute addresses) this doesn't require any changes to the data after loading it in. However, loading a file to a different load address than the one stored in the first two bytes is problematic. Here's the layout.

PETTIL studio is the programmer environment, with every definition that touches the symbol table. When the compiling is done, all memory above 1A55 may be reclaimed and used for other purposes! Of course, you lose the editor, assembler, interpreter, compiler, find, the symbols, etc... but that's okay because your application code is built now and no longer needs those things. Storing the top word (e.g. STARTREK) into STARTUP will bring it up at launch, and SAVE-FORTH can store such an image on tape or disk like a turnkey application. BLKBUF will now be 7C00-7FFF and VMBUF still goes adjacent and just below that.

In no particular order, these are the design questions that I ponder today.

A VIC-20 is more useful for graphics when more of the $1000-1FFF region is available to the VIC chip. It'd be nice to move things around so `core` does not live there. What memory layouts might work better?

On the 80-column PET and the 128, a screen has 2000 characters (and no linewrap). It's workable if I make BLKBUF a 2K region and have screen packets be this size. The ewww factor is high.

Moving VMBUF at load is a pain. PETTIL has to look at the load address, subtract it from the end address, and subtract that number (packet file size) from BLKBUF. Then get the data. To make things more annoying, whenever the machine does tape or disk I/O, and the user hits the STOP key, or an I/O error occurs, the ROM drops to the BASIC `READY.`prompt. That code is chiseled into concrete, so all disk I/O for load, save and verify needs to be sandwiched between a pair of `aloha` calls to ensure that zero page is okay for running BASIC. Typing RUN resumes PETTIL with a warm start if this happens.

This (relocating loader that looks at the file load addres before calculating the effective load address) seems like it could be the sort of problem that someone else has already solved. All ideas are welcome.

Mia Magnusson came up with this in Facebook group "FORTH PROGRAMMING / RETRO COMPUTING" (https://www.facebook.com/groups/273924826349346/)

"p.s. do you really need to use standard format instead of inserting the length at the start of the file?"

INSERTING THE LENGTH AT THE START OF THE FILE! Of course! And after loading into memory, replacing the value with 00 00 to mark the tail of VMBUF again.

SAVE-BUFFERS replaces double null with the (negated) buffer size, also the PRG file size. At LOAD-BUFFERS or VERIFY-BUFFERS the first two bytes of the file are subtracted from `blkbuf` on the running system. So that takes care of the disk load.

For tape, the code is a little different, calling ROM routine READHEAD which populates the 192-byte cassette buffer at 027A with filetype, startaddr, endaddr, "filename string" (and blanks to the end of the buffer). After calculating the effective load address, a call to READDATA brings it in.

VERIFY-BUFFERS has to first store the filesize over the '00 00' at VMBUF, then call READDATA, otherwise those two bytes will not match, guaranteeing 100% "verify error". VERIFY-BUFFERS should also fail early after READHEAD, if there was not already '00 00' at this address.

Following READDATA,
( loadstartaddr ) off \ mark the tail -- both VERIFY-BUFFERS and LOAD-BUFFERS
( loadstartaddr ) vmbuf ! \ uservar, the place where new packets are added -- LOAD-BUFFERS only

I finally got the outer interpreter behaving correctly and could not be more thrilled! It does nested loading of screens and has so far withstood all the torture tests I've thrown at it. Here's the source, feedback appreciated