The funny thing about the VBXE blitter is that it is much faster than the 6502, even when you ask it to do really crazy stuff like tons of one-pixel blits. At 21 bytes per blit and 8 VBXE cycles per machine cycle, the blitter can setup blits at the rate of about every 1-2 instructions. That means that in order to really utilize the blitter, you need to either do large blits, reuse blit lists, or just find a way to set up blit lists very rapidly.
For some reason, I love abusing blitters. I think it'd be possible to both layout and draw proportional text entirely on the blitter -- use a bunch of one-byte blits in add mode to generate the x coordinates for each character, another one to copy text characters into a blit list, execute that as a third pass to copy bitmap pointers for each character into another blit list, and then execute that to finally blast them onto the screen. Pad the passes with degenerate blits and you can run the whole thing in one big list. The annoying problem is that the blitter doesn't have a numeric compare mode, 16-bit addition, or addition with carry, so it's hard to do this for cases where a byte quantity doesn't suffice.
Another fun use for the blitter might be to generate 6502 code....
The fun part about the blitter will surely be finding abstract uses for it. I still haven't gotten my head around your suggestion for mapping out proportional text using the blitter: I'll have to read that again half a dozen times! If I can use the blitter in the manner I described, though, it will cut out the whole second-pass loop which "standard" versions of LW required lots of fancy optimisation code to avoid. Because of the layout of the VBXE attribute bytes, I'm hoping I can program the blitter to copy the visible portion of the 256 byte "plain" line buffer to the display RAM, skipping every other character to avoid the attribute byte. Keeping lots of buffers in VRAM like this in order to use the blitter is a good argument for using the MEMAC_A buffer and keeping it permanently switched in for the CPU (as things are at the moment). It's more RAM hungry, but since LW's text buffer occupies $4000-$7FFF, it's a little more flexible to use an 8K VRAM window at $A000. I think blitting the screen RAM up and down for scrolling will be more or less redundant when the refresh routine uses the blitter: it will be so blisteringly fast at redrawing the screen that hopefully no further optimisation will be needed. It will certainly keep up with the fastest useable key repeat rates.
From being a little sceptical in the early days about the "ethics" of a hardware upgrade like VBXE, I must say it's a real thrill to write my first program using the device. It's great for Atari-8 only programmers like me who wouldn't otherwise get access to blitter lists and other such delights. As for comparisons with MS Word, I have absolutely no doubt whatsoever that a virtually full version of MS Word for DOS would be possible using VBXE. I'm already looking into possible ways of running LW's code from an extended bank or banks, so we could be well on the way to having the most powerful WP on any 8-bit computer, period!
Other ideas - such as having the text buffer itself held in VRAM, might be possible in future but as ever the logistics of creating virtual buffers using a pool of extended banks is very expensive, particularly given LW's text buffer model. I think it's a case of one step at a time here.
Anyway - because it will take a long
time to complete this app in a way which fully exploits VBXE's capabilities and because I know a text editor which uses the device will be useful to a lot of people, I see no reason not to release a "seat of your pants" version at the weekend. Save for a few visual glitches, the thing works fine as is.