Having the program code underneath the extended banking window is proving such a headache that I've turned my attention - for now - to updating the "Shadow RAM" version of LW with some of the new features intended for the "Pro" version. Such are the changes being made to the standard version, that the Sparta 3.x compatible version will probably have to be started again from scratch (since it's built on the codebase of the current development version). In any case, I'd rather make progress with something that works for now, and the testbed version is working well.Before applying the more ambitious features, I'd already implemented (for the 3.11 update):

• New, Windows-compatible shortcuts for some commands
• "International Lock" mode: a new state for the keyboard which allows single-keystroke entry of alpha control characters
• A couple of cosmetic bug fixes
• A faster screen refresh routine, made possible by "upsampling" the 512 byte, two-characters-per-cell 80 column fonts so that they occupy 1K in memory, with two copies of the same character side-by-side in memory. This completely eliminates bit-shifting when rendering the characters on the screen.

I'd dearly love to add a built-in menu to version 3.11, but I think that will have to wait for the next version (or be implemented as an extension).So, with version 3.11 just about ready to roll, I set about trying to implement the 32K buffers to the same code base. Result: it works well. There's very little noticeable slow-down, even though there's quite a lot of convoluted code employed when reading and writing bytes from and to the virtual 32K text buffer. Theoretically, the method could be extended to connect maybe three or four 16K banks, but it's at that point that travelling from one end of the file to ther other would become unacceptably slow. I think 32K is about the limit. Of course, you can still include external files, and although the segmented file reading feature will be dropped, the "/A" "append to file" switch will remain, so there's nothing to stop you writing compound files if you have a reason to do so.One of the biggest headaches with the two-bank text buffer system was the screen redraw. The redraw routine checks to see if START (which points to the first character to be displayed) is >= $8000. If it is, then the upper bank is switched in; otherwise the lower bank is left in place. EOL characters are used as markers in two special locations:

• At the insertion point, signalling the refresh routine to load the text pointer with the value at link, which points to the upper segment of text (ahead of the empty space always in front of the cursor)
• At the "end of text", i.e. $8000.

In both instances, it's necessary to establish whether a switch to the "upper" bank is required. Of course, if $8000 is reached and we're already in the upper bank, then the end of the buffer has been reached. The biggest problem came with word-wrap. Previously, when jumping across the empty space ahead of the insertion point, it was simply a case of saving the original pointer values just in case word-wrap stepped back to a point before the cursor position. In that case, the jump across the empty space (to the link position) would be accomplished early on the next line down. However, with bank switching happening both when skipping empty space and when reaching $8000, this system became virtually impossible to implement.What I decided was to abolish "back tracking" altogether. When a line is word-wrapped, any discarded characters are placed in a temporary buffer, the contents of which are loaded into the line buffer when the next line is displayed, before any more characters are pulled from the 32K buffer. This allows for a "no turning back" approach once the second bank has been swapped in. It also broke a lot of things which had to be fixed up. For example, the pointer to the text in the buffer is no longer necessarily a pointer to the start of the displayed line. I think I just about have it cracked, though.Loading and saving a 32K text file will be as simple as swapping in the first bank, performing I/O, then doing the same with the second bank switched in (if the file is big enough). When loading a file, the text will naturally fill up the buffer from the bottom. The only time LW holds all the text at the bottom of the buffer is when the cursor is at the end of the file, so it will be necessary to first perform a "cursor home" operation on any freshly loaded file. This will introduce a short delay before the file can be edited (up to a few seconds with a 30+K file), but is preferable to writing a complicated block move routine to copy parts of the text between two extended banks. It's also more elegant.Other desirable features for this developmental version include:

• A built-in menu system
• Expanding tabs on the screen
• Decimal, centre and flush-right tabs
• Multi-level undo/redo

The multi-level undo/redo facility should be interesting. Probably consuming yet another two banks of extended RAM, this feature will work by recording all insertions and deletions in linked list based stacks (one for undo, another for redo). Since 90% of LW's editor operations usefully call an insert/delete routine at the lowest level, that's the obvious place to intercept and record edits. I'm not aware of any other Atari 8-bit editor with undo/redo (certainly not of more than one level), but it seems to me an obvious application for the RAM on expanded machines.The tabs may prove a step too far in a program which already has to do a lot of work to get 80 column text on the screen in real-time. However, the menu system is a given, and coupled with 10 x 32K text buffers and mutli-level undo/redo, it should make The Last Word the most powerful word processor for upgraded 8-bit computers.