The Last Word 3.11 Public Beta

[flashjazzcat]

That icon bar looks great! I think the 1K loss is worth it.

Thanks. It's reached via the Escape key, just like The First XLEnt Word Processor. Escape used to run macros, but you can also get at them with the Option key and I'll just reassign another alternative keystroke.

[Mirage]

I just gave this a quick try -- extremely impressive. Even on my 1702, the 80 columns was readable, but I'll hook it up to a larger monitor this weekend and I'm sure it will be much better. The whole thing was of stunning quality, very impressive. Looking forward to more details on a possible cart for this.

[flashjazzcat]

I just gave this a quick try -- extremely impressive. Even on my 1702, the 80 columns was readable, but I'll hook it up to a larger monitor this weekend and I'm sure it will be much better. The whole thing was of stunning quality, very impressive. Looking forward to more details on a possible cart for this.

Thank you. I don't know what will happen with version 3.x, but version 4.0 (when I have time to write it) will come out on a cartridge later this year.

 

I'm looking into the idea of making 3.x auto-detect VBXE (if present) so it can use the 80 column hardware text mode.

[Velcro_SP]

I have an Atari 800 w. 64k (do not know the configuration of that last 16k of memory). Is there a Last Word version that will support any non-XL/XE 8-bits at all?

[flashjazzcat]

I have an Atari 800 w. 64k (do not know the configuration of that last 16k of memory). Is there a Last Word version that will support any non-XL/XE 8-bits at all?

Unfortunately not right now. There's no reason why the cartridge based version shouldn't run on an 800. It won't be written for some months yet, though.

[flashjazzcat]

There was a feature request some posts ago for a fit-to-page preview function. I'm thinking about implementing this, but it will involve some clever rescaling (i.e. downsampling the 80 column characters down from 4x8 to 1x2 at the very least). A good downsampling algorithm is my first task (contributions or suggestions welcome, especially regarding something that will handle pages of unpredictable dimensions being scaled down to the same 160 scanline window). A two-up, side-by-side page preview would probably be possible.

[flashjazzcat]

Hmmm... I meant to add this to the previous post but the damned blasted edit facility timed out while I was eating dinner...

 

I was also fiddling about with ProText on the ST the other day, and familiarising myself with the formatting conventions used in that program. I noticed that the editor formats lines "on the fly" (not via the screen refresh routine) and only re-formats edited text when the cursor leaves the current paragraph or when explicitly instructed to reformat. The fact that you can click the mouse in empty space and start typing suggests that the text might conveniently be held in a fixed "matrix" and more or less blitted straight to the screen. This - coupled with the slow screen refresh of various ST WYSIWYG word processors on the ST - leads me to think that manual reformatting might be a path worth following. We could then have justification, centering, etc, on the screen and make the scrolling pretty fast (particularly when using character mode with a 40 column display or 80 columns with VBXE). If the entire document was held, formatted, in - say - a 128 x 256 matrix - the screen refresh routine would be simplified and scrolling speeds greatly improved (the latter could be a accomplished using the display list). A drawback is that an empty line would consume 128 bytes. However, on expanded RAM machines, this wouldn't matter as much.

 

I haven't made any definite decisions yet, but my ultimate goal is to end up with something which approximates ProText on the 8-bit. Since LW currently word-wraps in real-time and doesn't display any formatting in the editor, a change of methodology would involve a fairly hefty re-write. However, I quite like the idea of embedded rulers, and the whole thing is eminently "doable" on the 8-bit. One way or another, the cart version of The Last Word should in many respects resemble Protext on the ST (drop down menus, dialogues, possibly even the com processor). On a VBXE equipped machine, a like-for-like port could almost be made.

[flashjazzcat]

I know a few people were quite keen on the icon menu demonstrated in the 3.11 beta of The Last Word. However, it was a bit of a memory hog and I've been experimenting with something slightly more practical and less gimmicky:

 

LW Menus.wmv

 

Yes, the icons looked good but there are a lot of other things I can do with 800 bytes of RAM.

[dwhyte]

I know a few people were quite keen on the icon menu demonstrated in the 3.11 beta of The Last Word. However, it was a bit of a memory hog and I've been experimenting with something slightly more practical and less gimmicky:

 

LW Menus.wmv

 

Yes, the icons looked good but there are a lot of other things I can do with 800 bytes of RAM.

 

I like the look of the new menu setup, Jon. However, I also liked the look of the icon menu as well. Perhaps we will see its return in the cartridge version?

Edited March 30, 2010 by dwhyte

[Roydea6]

However, it was a bit of a memory hog and I've been experimenting with something slightly more practical and less gimmicky:

 

Yes, the icons looked good but there are a lot of other things I can do with 800 bytes of RAM.

 

I agree that you should wisely use the memory. Icons are good,,,,,but. Does this new practical gimmic still allow the use of keystrokes also..????

[flashjazzcat]

I like the look of the new menu setup, Jon. However, I also liked the look of the icon menu as well. Perhaps we will see its return in the cartridge version?

 

I agree that you should wisely use the memory. Icons are good,,,,,but. Does this new practical gimmic still allow the use of keystrokes also..????

The icon menu only represented 20 main functions. There was never enough memory to do an icon sub-menu. At least with the menus, virtually all editor functions can be included, so when using "International Lock" mode, users who eschew keyboard shortcuts can still get at all the functions. The menu items will have "accelerator" keys, so you'll be able to key in <Esc><F><L> to load a file. If you prefer the cursor keys, you can use those. The menu is called up with the <Escape> key, which seems entirely intuitive.

 

Really we should have both the menu system and the icon bar. It's hard deciding which to put in the final disk-based version of this program. The problem is that I also want to add a couple of other things (like cross-bank document statistics), and this is impossible with the icons in place: they just consumed a lot of RAM and there's no way around it.

[+Stephen]

I know a few people were quite keen on the icon menu demonstrated in the 3.11 beta of The Last Word. However, it was a bit of a memory hog and I've been experimenting with something slightly more practical and less gimmicky:

 

LW Menus.wmv

 

Yes, the icons looked good but there are a lot of other things I can do with 800 bytes of RAM.

It looks cool, but I kept waiting for a menu to drop down

[Rybags]

Something I was thinking about once you get this finalised, might be worthy of your consideration:

 

How about a bare-bones "Editor" using the core parts of the program.

 

I'm thinking mainly about the VBXE version here... it'd be nice to have a piece of software that actually warrants using the Atari to do more of it's own dev-work again.

 

Nice features would be modern editing facilities like bulk cut/paste, multiple files open at a time, and the ability to save files with line numbers (and have them omitted whilst editing).

[flashjazzcat]

Something I was thinking about once you get this finalised, might be worthy of your consideration:

 

How about a bare-bones "Editor" using the core parts of the program.

 

I'm thinking mainly about the VBXE version here... it'd be nice to have a piece of software that actually warrants using the Atari to do more of it's own dev-work again.

 

Nice features would be modern editing facilities like bulk cut/paste, multiple files open at a time, and the ability to save files with line numbers (and have them omitted whilst editing).

That's a good idea. Funnily enough Draco has been asking me to do something like this for ages, but I just never had the time yet. Such a "stripped down" editor would necessarily work via whichever screen handler is installed at the time (the software 80 column mode would likely be dumped). Line numbers, expanding tabs, etc, etc, are all things I want to put in the cart version of the word processor, which will load instantly and have a "program" mode which will allow for all the text editor functionality. But the stripped down editor is worth doing in the meantime. It's a question of getting it done, since I have about half a dozen development versions of this program at the moment.

 

As for the menus dropping down: believe me, I'm considering it!

[Mr.Amiga500]

As for the menus dropping down: believe me, I'm considering it!

 

Nooooo!! I've got enough drop down menus in my life.... so many that I think I'm getting psychologically damaged. When I go to a restaurant, I half expect the menu to have a little drop down menu for each item.

 

I like the icon bar best. (yes, I've been psychologically damaged by icons too... but they remind me of Lucky Charms breakfast cereal when I was a kid )

[flashjazzcat]

OK: public opinion has decided the issue. Icons it shall be for LW 3.11. The extra stuff I was going to add can wait till the cart version (and as for that, I frankly quake in my boots at the thought of splitting 32K of code and data into discreet 8K bank switched blocks).

[Rybags]

VBXE can come in handy there. Thanks to the versatility of MEMAC_A, you can emulate many of the cart schemes out there.

Of course, the bank-select method is all different and it's RAM not ROM, but if you structure the program and use a subroutine for all bank-switches it should make developing it a lot easier.

[flashjazzcat]

VBXE can come in handy there. Thanks to the versatility of MEMAC_A, you can emulate many of the cart schemes out there.

Of course, the bank-select method is all different and it's RAM not ROM, but if you structure the program and use a subroutine for all bank-switches it should make developing it a lot easier.

I've been thinking about this quite a lot because I'm keen to make the jump to cartridge. To my mind, there are a couple of possible approaches (remembering that the program needs to work on non-VBXE machines also):

 

• Organize the program in descreet sections: i.e. print processor in one bank, disk menu in another, main editor functions in another, I/O in another. "Common" routines would be held in low RAM (copied from an init bank on startup).
• Or: perform all JSR/RTS operations via a bank-switching routine, so providing no routine crosses a bank boundary, the code can more or less be organized arbitrarily.

I tend to favour the first method, for compactness and speed. To add a menu/dialogue system, I'd just code it up in an 8K bank and use the bank-switching JSR subroutine to enter and exit that bank. On the other hand, using an indirect method for everything would make life easier when accessing data in an 8K bank. Whichever way you look at it, it's not going to be a breeze. One saving grace is that using indirectly accessed text buffers, the $4000-$7FFF area can be occupied by code and data too. This is important, given the bitmapped 10K screen RAM will consume memory either side of the extended RAM window (8K of the screen below the cart space, and a further 2K of it below $4000).

 

 

 

 

 

[flashjazzcat]

Here we go with a second public beta. This one has:

 

• Faster screen refresh and upsampled 80 column fonts which eliminate bit-shifting
• The icon menu bar accessed with <Escape>
• Windows style cut/copy/paste/print shortcut keys
• Extra functions on CTRL+4 through CTRL+7
• "International Lock" keyboard mode for easy typing of CTRL+alpha characters
• Various bug fixes
• Defaults to long style directory listing under SpartaDOS X
• Document statistics for all open text files

A known bug in this version is that reset results in an exit to DOS when running with a DOS 2.5 RAMdisk. No rational explanation for that yet, but needless to say everything will get ironed out soon. If the icon bar proves really popular, I might include an icon editor with the cart version of the program when the time comes. The user would be able to assign icons of their own design to built-in commands or user-written macros of their choice.

 

Special thanks to dwhyte for his help in getting the print processor debugged.

 

Information

 

Download

Edited April 5, 2010 by flashjazzcat

[Roydea6]

I like most of this version If I don't want icons I just avoid hitting the ESC key. One note I couldn't find in the DOC's, CTRL+2 acts like the CTRL+SHIFT+CLEAR, and toggles EOLS on and off. Also the text file made comment about this running with SDX33a and BEWEdos, but it didn't with SDX33a. I haven't tried to use BEWEdos or RealDOS yet..

 

Thanks !

[flashjazzcat]

I like most of this version If I don't want icons I just avoid hitting the ESC key. One note I couldn't find in the DOC's, CTRL+2 acts like the CTRL+SHIFT+CLEAR, and toggles EOLS on and off. Also the text file made comment about this running with SDX33a and BEWEdos, but it didn't with SDX33a. I haven't tried to use BEWEdos or RealDOS yet..

Well, you can't please all of the people all of the time.

 

If you read the text file again, you'll find that it does NOT claim the program works with SpartaDOS 3.3. It will theoretically run under BeweDOS (I can't remember if I left the checks in this version), which is compatible with the FMS of SpartaDOS. BeweDOS, however, uses no RAM under the OS, which is how it works with LW.

 

In LW, all the SHIFT+CTRL+key combinations actually produce ATASCII codes. SHIFT+CTRL+CLEAR just produces the inverse version of ATASCII 125, which is 253 (the bell), which you'd normally only get with CTRL+2. CTRL+3 will take you to the end of the text, apeing the normal "EOF" function of that keystroke.

Edited April 5, 2010 by flashjazzcat

[+Stephen]

Well, you can't please all of the people all of the time.

 

If you read the text file again, you'll find that it does NOT claim the program works with SpartaDOS 3.3. It will theoretically run under BeweDOS (I can't remember if I left the checks in this version), which is compatible with the FMS of SpartaDOS. BeweDOS, however, uses no RAM under the OS, which is how it works with LW.

 

In LW, all the SHIFT+CTRL+key combinations actually produce ATASCII codes. SHIFT+CTRL+CLEAR just produces the inverse version of ATASCII 125, which is 253 (the bell), which you'd normally only get with CTRL+2. CTRL+3 will take you to the end of the text, apeing the normal "EOF" function of that keystroke.

Looks awesome, I am glad the icon bar remained. The editor is very responsive too, the speed increases are really adding up

[+Stephen]

There is something satisfying about posting a URL to new A8 software via the A8. I left a message on Darkforce BBS about the latest Last Word beta. FCJ - that should get you at least another 5 to 10 hits this month

 

*** EDIT ***

I guess I can't embed a telnet hyperlink.

[Mr.Amiga500]

I see the border text colour behaviour has changed... now how do I set it independently of the border background colour?

 

I had my colour scheme perfected and now I can't get it back. D'oh!

[flashjazzcat]

There is something satisfying about posting a URL to new A8 software via the A8. I left a message on Darkforce BBS about the latest Last Word beta. FCJ - that should get you at least another 5 to 10 hits this month

 

*** EDIT ***

I guess I can't embed a telnet hyperlink.

I've been wanting to get on one of the chats using a telnet client on the A8 via SIO2PC for a while. Must be fun, but I never got around to it yet.

 

Anyway - thanks for the posting!

 

I see the border text colour behaviour has changed... now how do I set it independently of the border background colour?

 

I had my colour scheme perfected and now I can't get it back. D'oh!

Just fired it up and <CTRL+K> to change colours and <P> to advance border text luma and <CTRL+P> to reverse it (and <B> to advance border colour and <CTRL+B> to decrease it) seems to work fine. What you've probably discovered is that print preview takes on the border colour and luma now. This was done months ago because no-one could agree what was the best background colour for the print preview screen. I'm open to suggestions if this isn't suitable.