Rather than keep posting in the forum, I thought I'd start this blog to chart the ongoing development of The Last Word, a word processor for the Atari 8-bit which first saw publication in December 2008. Since that time, it's been adapted to use a fast and efficient software driven 80-column text display, detect and use most popular RAM upgrades automatically, and incorporate a file manager which makes maximum use of SpartaDOS X. The program has a complex macro language, and can hold up to ten files in memory simultaneously on suitably equipped machines.LW 3.1 was released last November, and apart from the VBXE version which is currently in beta, I had assumed I'd done more or less all I could with the program, short of marrying it up with a GUI at some point in the distant future. However, a few enquiries from people who wanted to use the program with disk-based SpartaDOS versions (as of version 3.0, LW has been incompatible with disk versions of SpartaDOS because the program code sits in the "shadow RAM" under the XL/XE operating system) got me to thinking how much of a miss SpartaDOS 3.x compatibility actually is. Last week, I set about moving the 14K of program code back down from under the OS into conventional memory.One major side-effect of this change is that the program will require at least 128K to run (previous versions have all worked with stock 64K machines). However, with the profusion of RAM-expanded machines and the popularity of emulation, I don't see this as a drawback. Since the software driven 80 column display consumes a whopping 10K of RAM, moving all the code into main memory and making the program 128K-only - while freeing up 6K of code space - also means that the program code has to sit underneath the text buffers, which are accessed through the banked window at $4000-7FFF. While this means that direct LDA/STA operations on extended RAM need to be channeled through a custom routine in unbanked memory which transparently banks in the appropriate RAM, it also opens up the possibility of chaining extended banks together to form text buffers of more than 16K in size, using programming techniques not dissimilar to those found in RAMdisk handlers.Currently, indirect access to the banked RAM is handled as follows:

sta_pos_y  	pha  	lda textbankmask  	sta portb  	pla  	sta (pos),y  	pha  	lda banktab  	sta portb  	pla  	rts

This simply substitutes an STA (POS),Y instruction (POS being the current insertion point) with wrapper code which transparently handles the bank switching. The PORTB masks are pre-masked to ensure the proper OS and BASIC bits are always correct, and the system is pretty fast. CIO access (for loading and saving text) and the time-critical screen refresh routine are handled by code outside the banked region, which bypasses the indirect access for maxiumum speed.In order to chain banks together as a contiguous memory space, some augmentation to the indirect memory access code will be required, so that pointers containing values in the range $0000-$7FFF (for a 32K buffer) will be transparently translated to the $4000-$7FFF range with the appropriate bank automatically switched in. The keys to making such a system work will be economy and speed (bearing in mind the routines will be called many thousands of times by memory move routines, or when scrolling through a long document).I'll go into how I intend to approach this in the next installment.