The Last Word - A New Word Processor for the XL/XE! (now NTSC-compatible)

[flashjazzcat]

LWBeta22.zip

Version for testing with various memory upgrades, on real hardware and under emulation. LW will report a maximum of 10 banks since that's all it can use (that's 9 extended banks, plus the main bank). The main bank is on SHIFT+CTRL+1, and the rest are on SHIFT+CTRL+2 to SHIFT+CTRL+0. This version will avoid SDX banked usage and RAM disks, but will cause problems with RAM disks under other DOS versions. Any sample code for detecting RAM disk size under older versions of SpartaDOS, DOS 2.5, MyDOS and DOS XE would be appreciated, as would any bug reports for this version.

 

Note that this is a test copy, so please make this clear if you offer it for download elsewhere. I'm pleased to see LW hosted here http://atarionline.pl/v01/index.phtml?ct=u...d#The_Last_Word, but if you're hosting it, could you please let me know. This makes it easier for me to notify people when new versions come out. I also aim to host the program on my own website in the near future.

 

Thanks!

Edited December 21, 2008 by flashjazzcat

[+bf2k+]

- Use of memory under the OS for sections of program code. Obviously this knocks out compatibility with disk-based SpartaDOS and DOS XE.

 

Nooooo... (not that...)

[flashjazzcat]

- Use of memory under the OS for sections of program code. Obviously this knocks out compatibility with disk-based SpartaDOS and DOS XE.

 

Nooooo... (not that...)

Good! It would be a major headache to program, but I have about ten bytes free so the code's got to go somewhere. Using an extended bank for the macro and paste buffer would free up a couple of kilobytes, but the program would be virtually unusable on a stock 64K machine. When I wrote the program ten years ago I hit a brick wall with regard to lack of memory and the wall is still there...

[+bf2k+]

Good! It would be a major headache to program, but I have about ten bytes free so the code's got to go somewhere. Using an extended bank for the macro and paste buffer would free up a couple of kilobytes, but the program would be virtually unusable on a stock 64K machine. When I wrote the program ten years ago I hit a brick wall with regard to lack of memory and the wall is still there...

 

well.. I'll help you test it. I have Mega-HZ 512K in my desktop 800xl + AtariMax 32n1 OS and several Rambo 256k 800xl's also.

[flashjazzcat]

well.. I'll help you test it. I have Mega-HZ 512K in my desktop 800xl + AtariMax 32n1 OS and several Rambo 256k 800xl's also.

 

That would be great, thanks. Once we know these memory detection routines work, there's just the RAMdisk code for other DOS systems to add.

[flashjazzcat]

Latest beta test version and an add-in for testing with emulators here. I've found that many emulators don't properly process the keys needed to access extended memory with LW, and this was causing enormous confusion when testing the extended RAM detection routines in the latest beta versions. The BANKUTIL.MAC add-in is loaded just like a normal macro and lets you select extended memory banks with <CTRL>+<T>. It also displays a hex listing of the bank switching masks if you press <SHIFT>+<CTRL>+<T>. Hope this helps if you're using LW with an expanded machine.

 

I hope to get the DOS 2.5/MyDOS/DOS-XE RAM disk code finished soon, plus any amendments to the RAM routines, so if people are still having problems with LW not detecting their RAM properly, I'll need to hear about them soon.

[flashjazzcat]

For those who like this program, I have a new version in the pipeline which should see the light of day within the next week:

 

LW 3.0 for SpartaDOS X, DOS 2.5, MyDOS and any other compatible DOS packages which do (or can) leave RAM under the OS intact. This version will offer:

 

- 24K main text buffer, together with additional 16K banks on expanded memory machines

- 2K macro buffer (double the size of previous versions)

- More paste buffer space

- Room for extra features and further development

 

Users of SpartaDOS 3.x and DOS-XE will be limited to the forthcoming version 2.2 of LW (which doesn't use RAM under the OS), and includes only slight changes and bug fixes from version 2.1.

 

As far as extended RAM support goes, after some experimentation with RAM detection routines, I'm considering making LW default to standard 130XE banked configuration, with the facility to alter the bank selection bitmasks for users who want more flexibility. This means LW would give 4 extra banks "out of the box", although extended RAM usage will have to be explicitly enabled (this is to avoid conflicts with RAM disks, etc). I believe this kind of set-up is the best compromise between ease of use and flexibility for more advanced users.

 

Machine code add-ins for version 2.1 will remain compatible with 2.2 but NOT with 3.0 (which uses shadow RAM), since the memory map for this version has been totally rewritten. All that will be required is a new equate file for inclusion into the add-in source code. The job of documenting the calls needed for writing add-ins is immense, so in the meantime I will endeavour to write add-ins to order.

 

On the subject of extra features, if you want to see something included in the 3.0 release of LW, speak up now. Within reason, I will attempt to address requests in the code space available (which has been freed up by moving 14K of the executable under the OS).

 

Finally, the source code will be issued after the final release of version 3.0. It's commented (if a little sparsely), and will need running through a conversion utility I aim to write in order to be compatible with MAC/65 and some of the popular cross-compilers. LW is at the moment being developed with my own MA65 assembler, and I'll provide the original .A65 source files for people who want to compile the program on the Atari8 using MA65.

 

Happy New Year!

Edited December 31, 2008 by flashjazzcat

[Mathy]

Hello Flashjazzcat

 

How about 80 column support? There will be an 80 column upgrade for the MIO (it's planned and development has started AFAIK), somebody was working on an 80 column cartridge, all we need for the VideoBoard XE is someone who can make us some PCB's and ofcourse there's the XEP80 and simulated 80 columns. I'm not sure if you can split "80 column support" into non-device specific and device specific. But if you can, you could have the non-device specific code in LW and just load the device specific stuff depending on the device one has/wants to use.

 

greetings

 

Mathy

[+Allan]

Hello Flashjazzcat

 

How about 80 column support? There will be an 80 column upgrade for the MIO (it's planned and development has started AFAIK), somebody was working on an 80 column cartridge, all we need for the VideoBoard XE is someone who can make us some PCB's and ofcourse there's the XEP80 and simulated 80 columns. I'm not sure if you can split "80 column support" into non-device specific and device specific. But if you can, you could have the non-device specific code in LW and just load the device specific stuff depending on the device one has/wants to use.

 

greetings

 

Mathy

I second support for the Xep-80. Support for the MIO and Videoboard would be great but right now have a very limited user base.

 

Allan

[Mathy]

Hello Allan

 

That's why I want the device specific code to be loaded separately. If a new piece of hardware becomes available that will do 80 columns, all you need is the code for THAT piece of hardware. The stuff all 80 column devices need, would already be in LW. This makes it possible to support lots of different 80 column devices, even rare ones, while at the same time reducing the amount of memory taken up by 80 column device drives.

 

Kinda like a printer driver. You only load the driver that is required for your printer. No need for a printer driver that supports all those other printers that are available.

 

greetings

 

Mathy

[sl0re]

Hello Allan

 

That's why I want the device specific code to be loaded separately. If a new piece of hardware becomes available that will do 80 columns, all you need is the code for THAT piece of hardware. The stuff all 80 column devices need, would already be in LW. This makes it possible to support lots of different 80 column devices, even rare ones, while at the same time reducing the amount of memory taken up by 80 column device drives.

 

Kinda like a printer driver. You only load the driver that is required for your printer. No need for a printer driver that supports all those other printers that are available.

 

greetings

 

Mathy

 

Also cool for people with rare older 80 col devices... bit 3... franklin.. et cetera.

 

A lot of people know their own codes to turn on their card / device. If there was just a way to write your own config file it would get the job done for most people (re: write 'config.sys' and put it here and the program will load it while booting, et cetera)....

[sl0re]

Hello Allan

 

That's why I want the device specific code to be loaded separately. If a new piece of hardware becomes available that will do 80 columns, all you need is the code for THAT piece of hardware. The stuff all 80 column devices need, would already be in LW. This makes it possible to support lots of different 80 column devices, even rare ones, while at the same time reducing the amount of memory taken up by 80 column device drives.

 

Kinda like a printer driver. You only load the driver that is required for your printer. No need for a printer driver that supports all those other printers that are available.

 

greetings

 

Mathy

 

Also cool for people with rare older 80 col devices... bit 3... franklin.. et cetera.

 

A lot of people know their own codes to turn on their card / device. If there was just a way to write your own config file it would get the job done for most people (re: write 'config.sys' and put it here and the program will load it while booting, et cetera)....

[flashjazzcat]

Hello Flashjazzcat

 

How about 80 column support? There will be an 80 column upgrade for the MIO (it's planned and development has started AFAIK), somebody was working on an 80 column cartridge, all we need for the VideoBoard XE is someone who can make us some PCB's and ofcourse there's the XEP80 and simulated 80 columns. I'm not sure if you can split "80 column support" into non-device specific and device specific. But if you can, you could have the non-device specific code in LW and just load the device specific stuff depending on the device one has/wants to use.

 

greetings

 

Mathy

I second support for the Xep-80. Support for the MIO and Videoboard would be great but right now have a very limited user base.

 

Allan

This is probably the most requested feature next to support for larger files. It's frustrating in a way, since support for an 80 column display is already built into the program in the form of the print preview screen. So we have the character set, and the routines to write to the screen. So one approach would be to re-write the editor refresh routine to map the 80 column character set onto a bitmapped screen. The trouble is that this would make the program unusably slow, because - like most Atari8 word processors - the screen refresh in LW, while fast and efficient, is primitive in as much as it completely redraws the screen regardless of which part of the display needs updating. To use a bitmapped 80 column display, one would need to selectively update only those lines which have changed due to editing, and that would require a complete rewrite of most of the memory management and screen update routines. More do-able would be an interlaced pseudo 80 column screen mode, flipping between two graphics 0 screens and two 80 column character sets.

 

As for MIO and XEP-80: LW's screen handling, being memory-mapped and device independent, would be hard to convert to a device-oriented methodology. Of course I don't know how these devices work, but I assume they display a linear input stream of text (I may be wrong - I don't know yet). It would certainly be possible to replace the direct screen addressing with a routine which, say, sent the same character to a device's put byte routine, and to adjust the limits of the display to 80 columns, but I can imagine this being very slow in practice.

 

It will be interesting to see what people can do with the source code when I eventually get it into a digestible format. The screen refresh is complex, taking care of block highlighting, horizontal scrolling, word-wrap, and the skipping of empty memory ahead of the cursor. A cursor right movement actually pulls a character from high memory and moves it to the first free location in the empty block and then updates a couple of pointers. This actually makes for quite neat programming, but also introduces complications which have, for example, made the idea of combining two 16K extended banks into a single 32K text buffer a mind-boggling headache.

 

I'd be interested in seeing an outline of how to interface with XEP-80 and other 80 column devices, however. Perhaps it won't be as complicated as I'm assuming it will be...

[GoodByteXL]

Hi!

 

I am absolutely amazed about your word processor. As a retired text workaholic I still use my 800XL for writing from time to time. My preferred word processor is TurboWord from Micromiser, which is supporting XEP80.

 

The big disadvantage with TurboWord and most of all other word processors (or office applications on 8-bit ATARI in general) is the missing flexibility to derive localized versions in other languages.

 

I'd be interested in seeing an outline of how to interface with XEP-80 and other 80 column devices, however. Perhaps it won't be as complicated as I'm assuming it will be...

 

As a simple user I don't know much about programming, but my guess is that it should be possible without getting too much headache since TurboWord is written in BASIC, which makes it relatively slow.

 

I second two issues:

 

XEP80 support & localized versions

 

Gtx

[+David_P]

The XEP-80 is less than ideal, given that (a) it requires additional hardware, and (b) it's driven through a serial connection on a joystick port.

 

One option might be to look at Clay Halliwell's Flickerterm, where two screens are switched on and off, using 4 bit wide characters in GR.0 - giving 80 columns, 40 per screen. It looks better on NTSC than PAL, I suspect, as you're getting 20% more rotations per second.

 

However, since you're only managing 2K in screen display vice the 8K for any of the 80 column modes using a GR.8 screen, speed should be better.

[flashjazzcat]

I haven't got hold of a copy of TurboWord yet, which I was going to use to investigate how to drive the XEP-80. However, from what I can gather, editing is slow and any high-speed editing has to be done in a special text entry window. It would certainly be possible to redirect output from LW's write-to-screen routine (which simply maps a character to the screen RAM at a given address), but whether the XEP-80 device is fast enough to display some 1,600 characters after each keystroke I do not know.

The XEP-80 is less than ideal, given that (a) it requires additional hardware, and (b) it's driven through a serial connection on a joystick port.

 

One option might be to look at Clay Halliwell's Flickerterm, where two screens are switched on and off, using 4 bit wide characters in GR.0 - giving 80 columns, 40 per screen. It looks better on NTSC than PAL, I suspect, as you're getting 20% more rotations per second.

 

However, since you're only managing 2K in screen display vice the 8K for any of the 80 column modes using a GR.8 screen, speed should be better.

This sounds worth looking into; it's basically the system I outlined in my previous post. It would be relatively easy to implement, too, but I'm unsure of how pleasing to the eye the results would be. I'll write it at the weekend if I get time. Meanwhile, I'll look out a copy of Flickerterm and see what it looks like (it occurs to me that a text mode with 80 4-bit wide columns would have been a useful extra on the Atari8, if a bit of a kludge).

Edited January 2, 2009 by flashjazzcat

[+Allan]

I haven't got hold of a copy of TurboWord yet, which I was going to use to investigate how to drive the XEP-80. However, from what I can gather, editing is slow and any high-speed editing has to be done in a special text entry window. It would certainly be possible to redirect output from LW's write-to-screen routine (which simply maps a character to the screen RAM at a given address), but whether the XEP-80 device is fast enough to display some 1,600 characters after each keystroke I do not know.

The XEP-80 is less than ideal, given that (a) it requires additional hardware, and (b) it's driven through a serial connection on a joystick port.

 

One option might be to look at Clay Halliwell's Flickerterm, where two screens are switched on and off, using 4 bit wide characters in GR.0 - giving 80 columns, 40 per screen. It looks better on NTSC than PAL, I suspect, as you're getting 20% more rotations per second.

 

However, since you're only managing 2K in screen display vice the 8K for any of the 80 column modes using a GR.8 screen, speed should be better.

This sounds worth looking into; it's basically the system I outlined in my previous post. It would be relatively easy to implement, too, but I'm unsure of how pleasing to the eye the results would be. I'll write it at the weekend if I get time. Meanwhile, I'll look out a copy of Flickerterm and see what it looks like (it occurs to me that a text mode with 80 4-bit wide columns would have been a useful extra on the Atari8, if a bit of a kludge).

 

You might want to look at this program as well.

 

http://www.atariage.com/forums/index.php?s...6&hl=column

 

Allan

[drac030]

It is planned in SDX to develop an unified screen driver, that works in similar fashion as CAR:CON64.SYS and CAR:CON80.SYS. This driver (as these two already do) will provide a "direct screen access" routines for programs which require it, like, for example, word processors. CAR:MENU.COM can already run this way on 64- and 80-column screen display without containing any specific code. Compatible drivers for XEP80 and VBXE are also planned. This way, once a program can use such a driver, it will be enough to swap the CONFIG.SYS file to make the program use another display hardware.

[+Allan]

There is also this 80-column program:

 

http://www.jdcasten.info/Frame.html?http:/.../AtariInfo.html

 

Allan

[flashjazzcat]

Any device which allows for a character to be written at position X,Y on the screen could conceivably be made to work with LW, providing it's fast. However, having written the program and optimised the screen refresh routine, I can't imagine any handler that maps 80 column text to the screen using software would be fast enough to tag onto the existing system. The simplest way of providing 80 column support is by using the "Flickerterm" method, but if we really wanted to use bit-mapped text, there are ways of amending the screen refresh routine so that it only redraws those parts of the screen which have changed since the last keystroke. It's still a headache, though, since the DOS menu part of the program also uses a fast screen refresh routine to display the directory listing (in a similar manner to the SDX "menu" program). There are simply so many different routes we could take to build-in 80 column support, but many of them are at the expense of program efficiency. I'll experiment with the "Flickerterm" system, although my main priority is to take care of support for larger text files, and I'm figuring out the best way of including multiple language support (I'm considering having a resource-file containing all the program prompts, etc, which can be customised and replaced. That would mean someone else could write the resource files for different languages ). At the moment, having shifted 14K of the 17K executable under the operating system, I'm experimenting with different memory layouts. There's about 4K of code in main memory at $8000, and everything else is for buffers. The main text bank extends from MEMLO to $7FFF, and the extended banks of course occupy $4000-$7FFF as usual. From $9000 upwards are the character set, macro buffer, preview/directory buffer, and the paste buffer, which will now be of a fixed size (around 4K). The software won't change much in operation, save for perhaps a couple of extra screen lines in the editor, and support for switches on filenames to allow for linked loads and appended saves (further ways to handle extremely large files). It will be hard to please everyone, and none of the above is cast in stone yet, but this is a great opportunity to experiment with different ideas and see how popular they prove.

Edited January 2, 2009 by flashjazzcat

[sl0re]

It is planned in SDX to develop an unified screen driver, that works in similar fashion as CAR:CON64.SYS and CAR:CON80.SYS. This driver (as these two already do) will provide a "direct screen access" routines for programs which require it, like, for example, word processors. CAR:MENU.COM can already run this way on 64- and 80-column screen display without containing any specific code. Compatible drivers for XEP80 and VBXE are also planned. This way, once a program can use such a driver, it will be enough to swap the CONFIG.SYS file to make the program use another display hardware.

 

Thats cool. Now that atari 8 bits are branching out more (one to three vendors don't provide all the hardware) we need that.

 

Guess it's time to build one of those devices to put the newer SDX on to.

[flashjazzcat]

Current test version of LW reports 26,623 bytes free in the main text buffer under SpartaDOS X 4.22 using banked memory .

Edited January 2, 2009 by flashjazzcat

[flashjazzcat]

I've been busy trying a few different enhancements with LW, with varying degrees of success. I had a go at writing a virtual memory mapping system for extended RAM banks that mapped a 32K buffer onto 2 extended 16 banks, but the extra processing made the screen refresh really sluggish. Hardly surprising, given that a simple page-zero indexed load instruction was replaced with a JSR to a routine which calculated the actual memory address using bit tests and masks and switched the appropriate extended bank in and out again. For the time being, then, I've proceeded with a version very similar to the existing release, but which resides under the OS ROM and under SpartaDOS X provides a 27K main text buffer, plus access to additional 16K banks on extended machines. The macro buffer has increased in size from 1K to 2K, and the cut and paste buffer is now fixed at 4K. Not much else has changed yet; I'm investigating XEP-80 support (although documentation is scant and I'm having trouble emulating the device), and I've yet to implement the "flickerterm" style 80 column screen. There's only 1K of code space left without these enhancements, but I think the large main buffer is a big improvment (I can now edit all my source code using LW).

[+Stephen]

I've been busy trying a few different enhancements with LW, with varying degrees of success. I had a go at writing a virtual memory mapping system for extended RAM banks that mapped a 32K buffer onto 2 extended 16 banks, but the extra processing made the screen refresh really sluggish. Hardly surprising, given that a simple page-zero indexed load instruction was replaced with a JSR to a routine which calculated the actual memory address using bit tests and masks and switched the appropriate extended bank in and out again. For the time being, then, I've proceeded with a version very similar to the existing release, but which resides under the OS ROM and under SpartaDOS X provides a 27K main text buffer, plus access to additional 16K banks on extended machines. The macro buffer has increased in size from 1K to 2K, and the cut and paste buffer is now fixed at 4K. Not much else has changed yet; I'm investigating XEP-80 support (although documentation is scant and I'm having trouble emulating the device), and I've yet to implement the "flickerterm" style 80 column screen. There's only 1K of code space left without these enhancements, but I think the large main buffer is a big improvment (I can now edit all my source code using LW).

Very cool - how hard was it to get back into this code after such a long long time away? I forget stuff that I am doing down at work after just a few months! Course, I still remember tons of the Atari error codes and RAM locations.

 

Stephen Anderson

[flashjazzcat]

Very cool - how hard was it to get back into this code after such a long long time away? I forget stuff that I am doing down at work after just a few months! Course, I still remember tons of the Atari error codes and RAM locations.

 

Stephen Anderson

Yeah - I'm absent minded with everything but programming, I think! A couple of months ago, when I got the Atari back after nearly ten years, I wondered how hard it would be to get back into things, but strangely enough it's like I was never away. I really hammered the programming back in the nineties, though, and having spent several hundred hours on the word processor alone, the 6502 op codes, Atari memory map, SpartaDOS commands, etc, must be hard-wired into my brain. I only wish I knew the PC inside out the way I feel I know the Atari8 - perhaps I could make some money then! I actually think I prefer the emulated platform now, certainly for programming. In any case, I find programming the Atari8 as addictive now as I did ten or more years ago - nothing's changed!