The Last Word 3.0 Release Candidate 1

[flashjazzcat]

This of you who volunteered to test the final pre-release copy of LW 3.0 have now been sent an ATR containing the program, help files, etc. Please use this thread to discuss the program and report any bugs using the LW Bug Tracker.

 

If anyone else wants a copy of the program to test, please PM me directly. The program is not yet fully feature complete and is NOT intended for upload to other websites, etc. The finished program will be freely available soon enough.

 

Important note for testers:

• Press the <Help> key to access ten screens of help on command keystrokes, etc. Just press a number key from 1-0 (0 = 10).
  
• <CTRL+S> accesses the Save function as before, but it just "quietly" saves the current file under the current name. <CTRL+SHIFT+S> now accesses "Save as" (where you can actually name the file).
  

Edited July 5, 2009 by flashjazzcat

[dwhyte]

:thumbsup:

 

[Gury]

That's great to have a new word processor, fresh and maintained as needed. I nearly wait to test new version.

[flashjazzcat]

That's great to have a new word processor, fresh and maintained as needed. I nearly wait to test new version.

Copy sent by PM.

 

Can someone send me a dump of the 1200XL keyboard table (192 bytes), or an OS ROM dump from a 1200XL - which ever is easier. Since I stopped using the OS keyboard table, 1200XL users have reported many problems but I have little data to work with.

 

Is there no way to emulate a 1200XL???

[spookt]

That's great to have a new word processor, fresh and maintained as needed. I nearly wait to test new version.

Copy sent by PM.

 

Can someone send me a dump of the 1200XL keyboard table (192 bytes), or an OS ROM dump from a 1200XL - which ever is easier. Since I stopped using the OS keyboard table, 1200XL users have reported many problems but I have little data to work with.

 

Is there no way to emulate a 1200XL???

 

 

Not sure where you are in the UK but if you get stuck I could probably lend you my 1200XL. I'm disappearing for a couple of days so I don't have time to pull it out and do dumps right now - sorry If no one else chimes in with a dump (unlikely I know ) drop me a PM and I'll dump what you need later in the week.

[dwhyte]

That's great to have a new word processor, fresh and maintained as needed. I nearly wait to test new version.

Copy sent by PM.

 

Can someone send me a dump of the 1200XL keyboard table (192 bytes), or an OS ROM dump from a 1200XL - which ever is easier. Since I stopped using the OS keyboard table, 1200XL users have reported many problems but I have little data to work with.

 

Is there no way to emulate a 1200XL???

 

The atari++ emulator will emulate a 1200XL if you have a 1200 OS image...

[candle]

atari800win also is up to the task, and dumps are sent

[flashjazzcat]

Thanks everyone for the offers and suggestions. I've just come back to the PC to find candle's OS dump, so I'm good to go.

[candle]

dump is not mine, i've spent some time digging for it on this very forum when i've received Dan's 1200XL

[flashjazzcat]

dump is not mine, i've spent some time digging for it on this very forum when i've received Dan's 1200XL

Well many thanks anyway!

[flashjazzcat]

I can't seem to get the 1200XL ROM to work in AtariWin. It says the CRC in the ROM doesn't match and it just locks up. What am I doing wrong?

 

Anyway, the rewrite of the file selector is going well and is actually shaving off lots of bloated code. It should have been done ages ago. Pressing <Tab> at a file prompt now closes the input line, runs the disk menu, which then feeds any selected file name back to the input prompt just as if it had been typed at the keyboard. The disk menu when run "stand-alone" (i.e. not as a file selector) is run contained in "wrapper" code that takes any selected filename on exit and attempts to load it as a document. These changes keep all the awkward situations caused by the "Save changes..." prompts OUTSIDE of the file selector code. Consider the following situation before the code changes:

 

User enters the disk menu.

User presses <CTRL+L> or <Return> to load file under the cursor.

File in memory hasn't been saved, so "Save changes" prompt appears at the bottom of the file selector.

User presses <Tab> at the prompt to enter the file selector because he's not in the right folder.

...hang on. We're already in the file selector.

 

This had my head in knots for a whole night until I realized the file selector module itself should not get involved in the "Save changes" stuff at all. The calling code does all that now. It still gets quite complicated:

 

User enters disk menu.

User presses <CTRL+L> or <Return> to load file under cursor.

[file selector does an RTS and passes filename in INBUFF to calling routine]

Main program realises a "Load" command has been issued and prints "Save changes..." because file in RAM isn't saved.

User says "Yes" and the "Save" prompt appears.

User presses <Tab> to get the file selector again because he wants to save the file in a different folder.

He opens the right folder, then presses <Return>.

The "Save" prompt appears, with the hightlighted filename in the input field.

Once the file has saved, the load routine takes over to load the originally selected file, but can't find it because the working directory has changed...

 

It's an extreme example and I'm still in two minds whether to allow the file selector to be invoked at "Save" prompts. Protext (which I've grabbed many ideas from since it's a great program) on the Atari ST doesn't bother with "Save changes..." functionality at all. It does what I originally had in mind and prints "Abandon changes (Y/N)", and if you say no, it leaves it up to you to go off and save the file. I can see why: it's the way LW originally worked. However, I've gotten used to the sensible logic of "Save changes (Y/N)" and the way it brings up the save dialogue, so I'll keep it that way.

 

What would have been nice is to make the file selector display the contents of the "LW" folder by default when looking for fonts, drivers, etc. LW already has a path variable, so if you type literal filenames at the prompts, LW automatically prepends them with, for example, "D1:>LW>" so that you can keep all your fonts, macros, help files, etc, all in the same folder. Trouble is, if you press <Tab> at a load font prompt, LW just displays the current directory in the file selector window, which probably isn't the one you want to look at. We could open the path to the LW path variable instead, but the file selector uses CWD commands to navigate the tree, so we really don't want to be viewing a folder we're not actually sitting in. We could do a temporary CWD to the LW path, display the files, then change back to the current directory, but that would leave MyDOS out in the cold (unless you can read the current path in MyDOS?).

 

Anyway, once the filing parts are thoroughly debugged, the macros need to be disabled during these unforeseeable excursions into "Save changes" territory. Imagine, for example, a macro which says:

 

Load "D:TEST.TXT"<Return>

<Go to top of document>

Insert "Hello"

 

If there's already an unsaved document in memory when this is run, the macro will collapse the moment "Save changes (Y/N)" appears on the screen. That's why keystrokes will be taken from the keyboard from the moment "Save changes" appears until the load file prompt comes back again.

 

My head hurts!

Edited July 8, 2009 by flashjazzcat

[candle]

i got this working under Atari800Win Plus 4.0

machine type: XL/XE

memory: 1088kB

video system: ntsc

sio patch, etc - all off

[flashjazzcat]

Seems to work. Doesn't seem to be any way to test the function keys, though???

[+Stephen]

Seems to work. Doesn't seem to be any way to test the function keys, though???

I have a 1200XL I can dig out and test on, but I will not be able to get to it until Sunday at the earliest.

 

Stephen Anderson

[spookt]

FJC - PM me a copy and I'll fire up the 1200 tonight. If you give me a couple of test cases too so I can test exactly what you need that would be great.

[flashjazzcat]

I have a 1200XL I can dig out and test on, but I will not be able to get to it until Sunday at the earliest.

Sunday's fine: there's no hurry.

FJC - PM me a copy and I'll fire up the 1200 tonight. If you give me a couple of test cases too so I can test exactly what you need that would be great.

On its way... mainly I want to see if all the CTRL+Key and SHIFT+CTRL+Key combinations work and if the function keys work as cursor keys. See the bug tracker for a detailed description of the problems experienced with the previous beta running on a 1200XL.

[spookt]

I have a 1200XL I can dig out and test on, but I will not be able to get to it until Sunday at the earliest.

Sunday's fine: there's no hurry.

FJC - PM me a copy and I'll fire up the 1200 tonight. If you give me a couple of test cases too so I can test exactly what you need that would be great.

On its way... mainly I want to see if all the CTRL+Key and SHIFT+CTRL+Key combinations work and if the function keys work as cursor keys. See the bug tracker for a detailed description of the problems experienced with the previous beta running on a 1200XL.

 

Got it here - thanks. Just about to give it a spin. (Forgot that I never got around to doing the SIO power mod on my 1200 so my SIO2USB doesn't work there)

[spookt]

OK - Loaded it up. I have a stock (except for the +5V SIO mod) 1200XL.

 

The F1-F4 keys do not work as cursor keys. In fact they seem to freeze the LW display. I can still hear the keyboard beep if I hit keys but there is no screen update.

 

I have also noticed that pressing reset seems to hang the machine. This happens before I try the function keys and after. The only way back is power off / power on.

 

I'll keep playing

[flashjazzcat]

Got it here - thanks. Just about to give it a spin. (Forgot that I never got around to doing the SIO power mod on my 1200 so my SIO2USB doesn't work there)

Check out the Bug Tracker. The Shift+Letter problem is fixed now. I just need to know if the F keys work the cursor and how the LEDs behave. Perhaps we can think up a practical use for the LEDs...

 

...Posted before your last post. F key problem is puzzling. Under emulation, the program does NOT hang on Reset. Are you using DOS 2.5?

Edited July 9, 2009 by flashjazzcat

[spookt]

Yep - I'm using the ATR that you PM'd to boot from my SIO2USB. Haven't seen any strange lights (recently ) but then I'm not bank switching.

 

Hold on I'll go swap in my 800XL and check out reset.

 

Right - checked my usual machine (800XL, 256Kb, 32-in-1 OS) and a stock 800XL and both have no reset issue.

Edited July 9, 2009 by spookt

[flashjazzcat]

Yep - I'm using the ATR that you PM'd to boot from my SIO2USB. Haven't seen any strange lights (recently ) but then I'm not bank switching.

 

Hold on I'll go swap in my 800XL and check out reset.

 

Right - checked my usual machine (800XL, 256Kb, 32-in-1 OS) and a stock 800XL and both have no reset issue.

No strange lights is good: they used to come on and STAY on with previous versions of LW regardless of whether or not there was any extended RAM in use. 1200XL Reset issue is still puzzling, especially after I took such pains to eridicate the DOS 2.5 Reset problems... I'm trying to set up a couple of emulators to check this out.

 

On an unconnected note, I've started revising the user manual tonight and it is hard going. Then there's the technical docs to write if the add-ins ever get implemented (the add-ins are likely to be direct patches of the program code: I had grand ideas of making them location-independent, but there's just not any room left. I think for the number of add-ins there are likely to be - a character map, icon menu bar, calculator, etc - this isn't going to be a great problem).

 

I can honestly say that the program has that almost-finished feel about it: starting work on the manual must mean I'm running out of bugs to fix and features to add.

[flashjazzcat]

Revised version will be issued to the testers shortly. Filing problems are all fixed, and print/preview has been cleaned up (a few nasty bugs had crept in there: I don't think the print formatter gets much attention!).

 

The final point of contention is the add-ins feature, which I used to really like in older versions of LW. Executables (which made direct calls to absolute addresses in the main program) could be embedded in macro files and loaded "on the fly" to provide extra, interchangeable functionality in the program. Well - the absolute calls will be staying because designing a relocatable API for the add-ins would take me another six months and the executable would likely top 40K by then. What I'm trying to decide now is between two options:

 

1. The "old" way, whereby add-ins were loaded like macro files (in fact, occupying the same buffer space and able to co-exist with macros) and were lost when a new add-in/macro is loaded
   
2. The "new" way, whereby add-ins are installed at run-time. If they're relocatable, they can be chained together and they're totally independent from macros, etc. However, there are only one or two spare editor keystrokes left to use to activate add-ins.
   

If I go with the "old" way, the macro buffer will occupy a fixed address in main RAM and this is the target address the non-relocatable add-in will be assembled to. You can then merrily load calculators, icon menus, character maps, etc, as and when you need them, activating them all with the same keystroke in the editor. One slight drawback is that the macro buffer will be 4K long and will sit at $3000 or thereabouts, trimming the main text buffer down to 16K (see below), just like all the buffers in extended RAM.

 

The new way requires much more effort when it comes to actually writing the add-ins, as well as a relocatable loader built in to LW's initialisation stage. You could chain together an icon bar, calculator, etc, and have them all loaded at the same time, but quite how to access all these extra functions when there's only one or two spare keystrokes in the editor has me stumped. Far easier with things like the print formatter, where there are plenty of unused codes which can be hooked into by add-ins.

 

The new method is better for intrusive stuff, like patching the program to work with VBXE or some such, purely because the code-space is non-volatile. The old method is more akin to loading an executable at the DOS prompt: You press <SHIFT+CTRL+M> to load a macro, type ICONS.EXT, and then the next time you press the add-in key in the editor, up pops a nice icon menu at the bottom of the screen. When you want a scrolling character map instead, you just load CHARMAP.EXT.

 

The "old" way is easier for me: it used to be quite fun with LW 2.1 writing different stand-alone extensions.

 

Even if I go the "old" way, the 16K main text buffer isn't such a limitation. There's a new way to handle large files, borrowed from TextPro. I've managed to sqeeze in the ability to handle files bigger than the 16K limit. If you load a file which overflows the buffer, you can go to an empty bank, and load the next chunk of the file by typing <CTRL+L>, the filename, an the "/C" switch at the end. You can continue to load the large file across banks like this until the whole thing's loaded. Then, when saving, you can use the "/A" switch to append each chunk to the end of the file. Seat-of-your-pants stuff, but quite functional. I'll build some extra macro conditionals into the program so the whole process of loading a large file can be automated.

 

These new features should be ready to hit the road by the weekend, so I'll send the testers a copy then. I'll hang fire on the add-ins for a while: hopefully I'll get some feedback in the meantime.

Edited July 16, 2009 by flashjazzcat

[flashjazzcat]

No strong views about the 16K buffers, then...

 

The ability to split files is proving interesting to program. If a file (TEST.TXT) doesn't fit into, say, bank 1, its name will be displayed thus:

 

1:D:TEST.TXT[1]

 

Denoting this is the bank 1, containing the first segment of TEST.TXT. If you then load TEST.TXT into bank 2 with the /C switch, this will be displayed:

 

2:D:TEST.TXT[2]

 

Denoting that this is the second segment of the file. You can then save the original file after editing by saving the banks in order, using the /A switch with segement 2 to append that section of the file. Having the segment numbers displayed like this should make things a little easier. Note that the order you save the segments in won't affect the numbering sequence: just the order you load them in.

 

LW has the ability to "Include" not only external files when printing but also the contents of edit banks. This means you could load a very large file which splits across banks but still print the whole thing all in one go using the GET BANK print directive in the "master" bank.

 

Time for a major documentation update, I think.

Edited July 18, 2009 by flashjazzcat

[+Stephen]

You make what I do at my day job seem like child's play - I have an unlimited resource server farm, and you have a lone 6502! I bow down.

 

Stephen Anderson

[flashjazzcat]

You make what I do at my day job seem like child's play - I have an unlimited resource server farm, and you have a lone 6502! I bow down.

Thanks! I only wish my day job was anything to do with computing: that's my dream!

 

I've actually been reading this interesting review from Antic, comparing seven of the major-player word processors. Comparing The Last Word 3.0 to the entries in this table, it's easy to become concerned about editor file size, lack of double-column printing, etc. Of course LW 3.0 is the only one to offer an on-screen 80 column software driven display, full SpartaDOS X and MyDOS folder support, etc, etc, but it's still interesting and worthwhile to look at how the older software packages stacked up against one another. I could go on indefinitely making LW tick various boxes. Paperclip seems to me the most impressive of the bunch but I've yet to get to grips with using that program. I notice it has an undo function: that set me thinking it would be possible (and fairly simple) to use an extended bank to hold a multi-level undo history. LW only performs two core operations on text: insertion and deletion. The length and location of any inserted text would be pushed onto the list, and any deleted text would be stored, along with its location. You could then even have a "redo" function... but no... there's no code space left!