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

[flashjazzcat]

Hello!

 

This is my first post on the AtariAge forum, and I'm pleased to offer some new software for the Atari 8-bits in the form of a word processor called "The Last Word". I wrote the program in 1999/2000 using my own MA65 assembler (which I'll also be sharing shortly) but it never saw the light of day. Now, nearly ten years later, I've dusted off my old Atari equipment and got a few of my disks transferred to the PC. Owing to numerous problems with the transfer process, I don't yet have a copy of the manual or source code, but I hope to offer those for download within the next few weeks.

 

The Last Word (version 2.1) was an attempt to combine the best features of popular word processors like Textpro, Paperclip, and the 1st XLent Word Processor into one program. The program is written in very tight, pure machine code, and is designed to work well with all popular DOS packages, and offers special features for SpartaDOS and SpartaDOS X users. The Last Word offers a macro language, multi-file editing on a 130XE, a disk utlility menu akin to that found in SpartaDOS, high speed editing of large files, a comprehensive online help facility (just press the Help key), advanced formatting commands including multiple heading levels and indenting, a fast, scrolling 80 column print preview mode, printer driver editor, user-written machine code extensions and much more.

 

From a programming point of view, The Last Word attains its editing speed from the fact that the text buffer is not held contiguously in memory: text is quickly shuffled around using a pointer system so that text insertion does not slow down no matter how large the file. The program makes no use of OS floating point or CIO routines apart from when carrying out disk operations.

 

The program was a very interesting project: I wrote it because no other program available at the time offered all the features I needed, and - amazingly - in the year 2000, the 8-bit was still my primary computing platform. It's been fun to see my program running smoothly on the Atari800Win Plus emulator and I hope it's of interest to other enthusiasts. As I say - source code and documentation will hopefully follow soon.

 

The program is presented as an AtariDOS image file here:

 

The Last Word - with NTSC fix

 

The execuatable file is LW.COM. The program should be run with BASIC disabled (SpartaDOS X users should run the program using the "X" command).

 

Feedback welcome. In the meantime - enjoy!

 

Jonathan Halliday

Edited November 29, 2008 by flashjazzcat

[+Allan]

Sounds really cool. I tried loading it with Dos 2.5 and it just crashes. I tried it on the real thing and on Atari800macX.

 

Allan

[MEtalGuy66]

Does it work with the XEP80 for realtime 80 column editing?

[flashjazzcat]

Sounds really cool. I tried loading it with Dos 2.5 and it just crashes. I tried it on the real thing and on Atari800macX.

 

Allan

I can confirm this download works fine with Atari800Win Plus on Vista (my system). As for converting the image for use on original hardware - I don't yet have the ability to test this (nor to test the integrity of the file conversion - however it works on my emulator). Does it work with SpartaDOS?

 

Does it work with the XEP80 for realtime 80 column editing?

The Last Word doesn't support XEP80 - however, realtime 80 column editing is achieved in a horizontally scrolling window if you set the number of columns in the editor with the Shift+Ctrl+W (screen width) command. If you enter "80" at the prompt, the 40 column screen will become a window onto an 80 column page.

[+Allan]

Sounds really cool. I tried loading it with Dos 2.5 and it just crashes. I tried it on the real thing and on Atari800macX.

 

Allan

I can confirm this download works fine with Atari800Win Plus on Vista (my system). As for converting the image for use on original hardware - I don't yet have the ability to test this (nor to test the integrity of the file conversion - however it works on my emulator). Does it work with SpartaDOS?

 

I just tried it with a couple of versions of Spartados with no luck. Is it possible that it got corrupted when you put it up on the file sharing site? I tried taking some of the files out of the XFD file but many of them were corrupted. Could you post it right up here on Atariage?

 

Allan

[flashjazzcat]

I've just uploaded a bootable DOS 2.5 image here:

 

The Last Word - with NTSC fix

 

This image will boot to the DOS menu, which might make life easier for some folks. I've downloaded and run the file with no problems, so it's definitely not corrupted. I'm puzzled by the problems you're having, Allan.

 

I'd be happy to upload to the AtariAge site but not sure how to do that yet; I'll look into it first thing tomorrow Could it be the XFD image format causing problems with other emulators? I'll convert to ATR tomorrow...

Edited November 29, 2008 by flashjazzcat

[+MrFish]

Sounds really cool. I tried loading it with Dos 2.5 and it just crashes. I tried it on the real thing and on Atari800macX.

 

It loads fine for me in PAL mode. NTSC mode freezes. I used SpartaDOS X and DOS 2.5, and both worked fine.

[Mathy]

Hello Jonathan

 

How much memory is supported? 64kB + 64kB (as in the 130XE) or more?

 

greetings

 

Mathy

[+Allan]

I've just uploaded a bootable DOS 2.5 image here:

 

The Last Word

 

This image will boot to the DOS menu, which might make life easier for some folks. I've downloaded and run the file with no problems, so it's definitely not corrupted. I'm puzzled by the problems you're having, Allan.

 

I'd be happy to upload to the AtariAge site but not sure how to do that yet; I'll look into it first thing tomorrow Could it be the XFD image format causing problems with other emulators? I'll convert to ATR tomorrow...

Well I downloaded the file, loaded it into Atari800macX, and listed the files in DOS, and loaded LW.com. It starts to load and then stops and freezes the emulator. I tried it on a real 130XE and it does the exact same thing. I converted it to an ATR but it doesn't make any difference. Anybody else have any luck?

 

Allan

[+Allan]

That's it. PAL ONLY! Luckily I can use it in an emulator. Maybe someone can fix it if you get the source off the disks.

 

Allan

[dwhyte]

Excellent work!!!

[flashjazzcat]

Thanks for the feedback and positive comments!

 

Hello Jonathan

 

How much memory is supported? 64kB + 64kB (as in the 130XE) or more?

 

greetings

 

Mathy

 

Up until now, only the standard 130XE banks have been tested, giving you a maximum of five 16K text buffers. However, SpartaDOS users who USE BANKED or have RAMDisks set up can use the LWCONFIG program to set up a config file (LW.CNF) which uses specific banks. Having just glanced at the manual, however, I notice that the config editor allows you to enter up to NINE bank selection masks in decimal (for $D301). Here's an extract:

 

"RAM Bank Masks" on the configuration program menu lets you type a comma separated list (up to 9 DECIMAL numbers) of the values which will switch in the banks you want to use. LW ignores bits 0,1 and 7 of these numbers. The 130XE uses bits 2, 3, 4 and 5 for bank selection. The main bank is ALWAYS selected with decimal 48, i.e. bits 4 and 5 set. The 130XE banked list is, in order, 0, 4, 8 and 12. These refer to the following banked regions:

 

0 = $0000 - $3FFF

4 = $4000 - $7FFF

8 = $8000 - $BFFF

12 = $C000 - $FFFF

 

If the banked list is 0, 4, 8, 12 and you type in 4 for the number of extended banks, LW will be set up to use all 4 130XE extended banks. If you type 1 in # ext banks, just the $0000 - $3FFF bank will be available, on <Shift+Ctrl+2>. You can arrange the banks in any order you like - 12 first in the list will put $C000 - $FFFF on <Shift+Ctrl+2>.

 

You'll need to enter values in decimal (not hex - sorry!). If you have a 130XE, just use the XE130.CFG file and modify it to use as many or as few banks as you want. If you have some other setup, consult the documentation for your RAM upgrade to see what values are required. I've left bit 6 available for alteration, but not bit 7 (the self-test bit). Hopefully this should cope with most memory set-ups.

 

-----------------------

 

Sadly I forgot to put XE130.CFG on the disk: I'll add that with the next disk image. It should be apparent, however, that all relevant bits of $D301 are available for alteration, so I'd like to see if people have any luck with larger memory upgrades. The system is designed to be as flexible as possible. Obviously I need to get the manual on line as soon as possible. I'll put a more carefully assembled disk image on the AtariAge site later today in the meantime.

 

That's it. PAL ONLY! Luckily I can use it in an emulator. Maybe someone can fix it if you get the source off the disks.

 

Allan

 

I've never used an NTSC system before, so I'm unsure what will be causing the problem. The program uses a custom VBI and DLI, and display list (the bottom two lines of the screen are removed during disk I/O to give the illusion that the DLI is still running), so I assume the problem lies there. It's frustrating not to have the source code but if someone gives me an idea of where the problem might lie I'll fix it as soon as I can.

 

I've just noticed that LW also uses the PATH environment variable in SpartaDOS X - so that, for example, loading a macro from the editor will search the directories in the PATH variable. I don't know why I didn't make the program look at an "LW" variable: if it isn't in the current release, I'll add it later. This would be a bit faster than searching the whole path.

 

Addendum: I've just tried the program in NTSC emulation mode and sure enough it hangs before the loading screen comes up, so I can't see it being due to the DLI or VBI (they start up when the editor screen appears). The program seems to crash after clearing out page zero and checking for DOS versions, MEMLO values, etc. Puzzling!

Edited November 29, 2008 by flashjazzcat

[Gury]

Thank you for sharing a program Jonathan. I tried a bootable image and it looks and works fine. I remember TextPro as freeware alternative to other professional word processors fro Atari 8-bit. It was feature-rich and developed by many. Now here is another good word processor to use freely and probably with open source code. Thank you again.

 

Greetz,

Gury

[flashjazzcat]

Thank you for sharing a program Jonathan. I tried a bootable image and it looks and works fine. I remember TextPro as freeware alternative to other professional word processors fro Atari 8-bit. It was feature-rich and developed by many. Now here is another good word processor to use freely and probably with open source code. Thank you again.

 

Greetz,

Gury

 

Thank you! I hope you'll find The Last Word to be one of the fastest and most versatile programs of its kind. It owes a great deal to the ideas in TextPro, which was my favourite word processor for a long time. Hopefully when I get the (fifty page) manual online, the more complex features such as macro programming and advanced print formatting will become apparent. In the meantime - use the help. Just press the Help key and hit a number (the screens run from 1-9 and 0 for the tenth screen).

 

It's so annoying not having the original source code on the PC but I had problems with the file conversion service I was using and I only got half my files copied over. However, I've just used the excellent DIS6502 by Eric Bacher to disassemble the program and I found the NTSC bug! The fixed version - which now works on both PAL and NTSC systems - is available here (complete with the XE130 configuration file - "XE130.CFG" - rename to "LW.CFG" to use as default, or load up in the editor with <Ctrl+Q>):

 

The Last Word - with NTSC fix

 

For those who are interested, the bug turned out to be in a timing routine which relies on the VCOUNT register at $D40B. The simple routine (designed to ensure display list changes happen at the end of the screen draw) loops until VCOUNT reaches 155 ($9B), which is the last line on the PAL system. Of course, on an NTSC Atari, VCOUNT never reaches 155 - the maximum value is 130 ($82). So it was a simple case of replacing $9B with $82 in all instances of this code (using DiskRx - no way of reassembling yet), and the problem was fixed.

 

This is clearly an example of poor forethought during the programming stage. Why did I assume the program would never run on an NTSC machine? Hopefully that's THE bug

 

Addendum: If the disk menu (accessed with <Ctrl+D>) hangs on first entry while reading the directory using the AtariWin800 Plus emulator, just hit reset and it should be fine after that. This has happened once or twice to me: unsure of the cause.

Edited November 29, 2008 by flashjazzcat

[+Allan]

It works great so far on a real NTSC machine. I can't wait to see what it can do. It looks great so far. I love the preview (print to screen) mode. Thanks for fixing it.

 

Allan

[spookt]

Thanks for the release! Shame this never saw the light of day back when. It works fine in Atari800MacX - have to wait until tomorrow to try it on my real kit. Looking forward to the manual, although the help system looks pretty comprehensive.

[Heaven/TQA]

cool stuff... what about German font?

[Tezz]

This looks very good Jonathan, thanks for sharing it here. I would definately of used this if it was created and available in the mid 80's prior to the 16-bit era. I've not looked too closely at it yet myself but from the description above it seems to be very highly featured. What made you write a WP for the A8 in 1999/2000? did you intend to release it freeware at the time?

[+Philsan]

This is my first post on the AtariAge forum, and I'm pleased to offer some new software for the Atari 8-bits in the form of a word processor called "The Last Word".

Nice way to introduce oneself!

[flashjazzcat]

Thanks again for the positive comments. I'm sure you'll be surprised by the depth and variety of features offered by the program when I get the manual uploaded. The macro language, for example, is quite advanced and impossible to describe in a couple of help screens. When I get the source code onto the PC, I'll also publish a toolkit for writing machine code extensions. That will require a complete equate list, which I don't have yet, although I'm hoping to get the source code transferred shortly.

 

This looks very good Jonathan, thanks for sharing it here. I would definately of used this if it was created and available in the mid 80's prior to the 16-bit era. I've not looked too closely at it yet myself but from the description above it seems to be very highly featured. What made you write a WP for the A8 in 1999/2000? did you intend to release it freeware at the time?

 

Thank you. Then best complement is for people to say they would actually use the program! I believe it would have been highly marketable if it had only been written at least ten years sooner! The Last Word WAS my primary word processor for a couple of years after I wrote it, until I got a PC and inevitably started using MS Word. I even wrote a novel (unpublished) using The Last Word!

 

I got my first computer - an Atari 65XE - when I was fifteen and I spent lots of my spare time learning to program, first in BASIC, then in C and 6502 Assembler. I'd always wanted to write a word-processor, but it took a LOT of years till I knew enough to have a crack at it. I knew there were good commercial offerings available, like 1st XLent and Paperclip, but they were expensive, hard to get hold of, and I could never be sure they'd work with SpartaDOS X. During the nineties I used the PD program TextPro (which was based on Speedscript), which I liked because of the macros, SpartaDOS support and the disk menu. While TextPro was an excellent program which gave me many ideas, there were things I didn't like, such as the way TextPro slowed down when editing at the top of a large file (a common problem), and there were many other things I would do differently. I hit upon the idea of keeping all the text in front of the cursor at the top of memory so there'd be no need to perform large block moves every time a character was typed. The text is moved through memory as you scroll through the document, and the screen refresh routine uses a pointer to skip past the empty space ahead of the cursor. This is one of the reasons The Last Word is so fast in operation.

 

Having just finished a macro assembler for SpartaDOS, I started writing The Last Word in 1999 and version 1 was finished in three months and debugged and tested in a further three months. I sent it to New Atari User Magazine (formerly Page 6 Magazine) in late 1999 (as freeware) but I never heard anything back from them. With no Internet access and unaware of the online Atari community, I got the feeling my program had completely missed the boat. In 2000 I submitted version 2.1 which incorporated a few bug fixes and quite a number of new features, but I never heard anything back from New Atari User. As it happened, the magazine's intermittent issues had completely dried up by then. I used the program until I got a PC, at which point the Atari was packed away, not to see the light of day until a few weeks ago, when a nostalgic conversation with a friend about 6502 assembler programming made me dig the old computer out again.

 

And now, nearly ten years after it was written, The Last Word has finally been released! I've also had the chance to briefly try out Paperclip and 1st XLent WP and I think The Last Word compares favourably with them both. I'd like to have a look at Superscript, too, but I can't find a copy.

 

cool stuff... what about German font?

 

You can load any font you like into the editor with the <Shift+Ctrl+N>ew Font command: further than that, multi-language support is unfortunately something I never looked at. It would certainly be possible to compile a version with German prompts if someone wants to translate everything for me. Or why not edit the object code directly with a sector editor? In any case, there is virtually NO ROOM AT ALL for code expansion - the program is a very tight squeeze in RAM. If I ever get around to developing it, I'll have to resort to using RAM under the OS, which will decrease flexibility with DOS packages.

 

I must add that Atari800MacX is absolutely brilliant!

Edited November 30, 2008 by flashjazzcat

[Tezz]

That's great stuff. Thanks for the info about it's history. It's a shame that it wasn't sent somewhere that gave it the correct attention. Glad you only packed the Atari away and didn't sell it on at the time. It's excellent nowadays with cross platform tools available, emulation and an online community, it's a lot of fun to work with. I agree DIS6502 is great too, I use it a lot for various things. Have you taken a look at Tebe's MADS macro assembler. It's excellent. Just a bit of relearning with the syntax and formatting from MAC65 that you'll be used to. Very handy to write code on the pc and launch stuff via emulation

[Heaven/TQA]

or use ATASM which is Mac/65 compatible?

[flashjazzcat]

Thanks - I've downloaded both MADS and ATASM and I'm looking forward to trying them out. The Last Word was compiled using my own MA65 Assembler (which I'll release soon), but there's no doubt about it: these excellent cross-assembly tools will speed up the development process ten fold at least! DIS6502 is so fast and has just the features I always wanted in a disassembler.

[drac030]

flashjazzcat: your editor is bloody cool. I have written a lot (around 2 MB) of text with the 1st XLEnt (most of them for publication), and the LW indeed has some features which I missed in the 1stXLEnt, when I used it as my primary text editor.

 

I noticed few things to fix. First, I failed to setup (with LWCONFIG) the access to extended RAM. No matter how much banks I type there, it seems to only see the base 64k, and so the editor buffer is about 15k, too small (1stXLEnt has about 32K if I remember correctly). The problem may be in the portb masks, but I think that this is too cryptic and the program, ant the other hand, could find out automatically, how much banks are there and how to access them. Under SDX you can also find out how much banks are not allocated, so that the destruction of possible ramdisks could be avoided.

 

The more serious thing, that, if there is no way to work this around, will make the editor unusable for me, is the system of keyboard shortcuts you implemented. IIRC, the 1st XLEnt left all Ctrl/key combos for user definition. With replacement font, this allowed to write texts with Polish diacritics, where Ctrl/A is ą, Ctrl/E is ę and so on. I noticed, that in the LW the Ctrl/key combos invoke functions like Ctrl/S = Save. This is a good idea, but unfortunately, when one writes in Polish, Ctrl/S is needed to get the letter ś. These characters can't be remapped arbitrarily, because they're used too often and the access to them must be convenient.

 

That's the only disadvantage I noticed (for me, though, it is a killer one). Otherwise, as I wrote above, the LW is really bloody cool.

[flashjazzcat]

flashjazzcat: your editor is bloody cool. I have written a lot (around 2 MB) of text with the 1st XLEnt (most of them for publication), and the LW indeed has some features which I missed in the 1stXLEnt, when I used it as my primary text editor.

Thanks for the comments! And now, to your problems...

 

I noticed few things to fix. First, I failed to setup (with LWCONFIG) the access to extended RAM. No matter how much banks I type there, it seems to only see the base 64k, and so the editor buffer is about 15k, too small (1stXLEnt has about 32K if I remember correctly). The problem may be in the portb masks, but I think that this is too cryptic and the program, ant the other hand, could find out automatically, how much banks are there and how to access them. Under SDX you can also find out how much banks are not allocated, so that the destruction of possible ramdisks could be avoided.

I have just tried loading the XE130.CFG file (in the Atari800MacX emulator) and I was only able (by pressing <Shift+Ctrl+3>) to access the second extended bank. However, using the default config file with the Win32 version of Atari800Win, all bank switching works perfectly (although only the first two banks are enabled in that config file). The exact same program code you're using is able to access all 4 banks on my real 130XE with the appropriate config file. I'll continue to look into it, though. What kind of expanded memory setup are you using? I think the idea of the program auto-sensing expanded RAM is excellent, by the way, and I have a couple of ideas how I would go about implementing it. It could be throw-away code in the initialization routines, so the actual program in memory need not grow in size.

 

The more serious thing, that, if there is no way to work this around, will make the editor unusable for me, is the system of keyboard shortcuts you implemented. IIRC, the 1st XLEnt left all Ctrl/key combos for user definition. With replacement font, this allowed to write texts with Polish diacritics, where Ctrl/A is ą, Ctrl/E is ę and so on. I noticed, that in the LW the Ctrl/key combos invoke functions like Ctrl/S = Save. This is a good idea, but unfortunately, when one writes in Polish, Ctrl/S is needed to get the letter ś. These characters can't be remapped arbitrarily, because they're used too often and the access to them must be convenient.

 

That's the only disadvantage I noticed (for me, though, it is a killer one). Otherwise, as I wrote above, the LW is really bloody cool.

It's easy to get around the keyboard problem, but an explanation is necessary since it's not obvious how to get control characters to show up in the editor. To get the characters you want, load up your redefined character set, then press <Ctrl+Esc> followed by the <Ctrl+Key> combination you want. In version 1.0 of the program, the escape key worked as normal, but in this version, I decided to make the escape key a trigger for macros. Therefore I had to move its normal function to <Ctrl+Esc> (you can also use <Shift+Esc>). Even the help screens aren't very clear about this: my apologies!

 

You could also set up macros to save a couple of keystrokes. To set up a macro so that pressing <Esc> then <S> will produce the 'ś' character, create a macro file thus:

 

s<Select>+<=><Esc>ś

 

That's 's', then <Select> with the '=' character, then <Ctrl+Esc> followed by <Esc>, then <Ctrl+Esc> followed by <Ctrl+S>. If you save that as POLISH.MAC, then load it with <Shift+Ctrl+M> (Load Macros), then <Esc> 'S' will put the character you want into the text.

 

Also, to enter a string of control characters, press <Ctrl+Caps Lock>. This will put the editor into control lock mode until you press <Caps Lock> again.

 

I hope this helps. Thanks for pointing these issues out, and I'm glad you like the program! I hope to have the manual online pretty soon. In the meantime, if you want any example macros, let me know.

 

Addendum: I've been reading through the manual and I'd forgotten that RAM Bank configuration is only implemented from the config file loaded when the program first starts (usually LW.CFG). So loading, for example, XE130.CFG during an editing session won't open up the 130XE banks (this was done to ensure you don't accidentally lock out a bank of text during an editing session). The XE130.CFG file was really designed to be renamed LW.CFG by those who want to use all four banks. This MIGHT explain some - if not all - expanded RAM issues.

 

I should be able to get the manual on line by the weekend, either by scanning the original or getting the files converted (I have to send the disks away because I have no way of converting them myself). Ultimately I'll make a proper PDF document when I get time.

Edited December 2, 2008 by flashjazzcat