The Last Word 3.11 Public Beta

[flashjazzcat]

Download public beta of The Last Word 3.11 here. The will be the last version capable of running on a machine with no extended RAM. Please read the notes, since various keyboard shortcuts have changed.

 

Direct Download Link

 

The next beta to appear after the final version 3.11 is released will handle up to 10 x 32K text files simultaneously, have a built in menu system, and a multi-level undo/redo facility as well as numerous other new features. An Atari 130XE will be its absolute minimum hardware requirement (a 320K or 1MB Atari will be optimum for advanced use).

Edited February 15, 2010 by flashjazzcat

[flashjazzcat]

I'm getting lots of feedback from the atarionline forum. A bug's already been reported in the International keyboard lock. CTRL+; wasn't being allowed through. It's fixed now.

[Roydea6]

On the emulator after CTRL+G and doing the find and replace I get a jumble of characters on the prompt for (all etc.. ).. I have not tested on real hardware yet.

 

But other wise great improvements. I like it.

[flashjazzcat]

On the emulator after CTRL+G and doing the find and replace I get a jumble of characters on the prompt for (all etc.. ).. I have not tested on real hardware yet.

 

But other wise great improvements. I like it.

Well spotted! I temporarily commented out the prompt for global search and replace when looking for spare memory and I forgot to uncomment it out again. That should just about consume any code space that's left over.

 

Thanks for your attention and comments.

Edited February 16, 2010 by flashjazzcat

[JonnyBritish]

Are there any plans to release this on a catridge via the atariage store?

[flashjazzcat]

Are there any plans to release this on a catridge via the atariage store?

There are many directions it could go in, cartridge-based being one of them, although nothing's been arranged as per manufacturing/marketing. GR8 were supposed to be selling a version on disk (several emails were exchanged) but nothing came of it.

 

Actually I don't actually know if it would be possible to put LW on a cart, since the display RAM occupies 10K and it has to be outside the banking window between $4000-$7FFF. Currently the screen starts at $9B6C and occupies all the memory under the cart region at $A000.

Edited February 16, 2010 by flashjazzcat

[spookt]

Are there any plans to release this on a catridge via the atariage store?

There are many directions it could go in, cartridge-based being one of them, although nothing's been arranged as per manufacturing/marketing. GR8 were supposed to be selling a version on disk (several emails were exchanged) but nothing came of it.

 

Actually I don't actually know if it would be possible to put LW on a cart, since the display RAM occupies 10K and it has to be outside the banking window between $4000-$7FFF. Currently the screen starts at $9B6C and occupies all the memory under the cart region at $A000.

 

It might be worth giving GR8 another shout now that Nosty has recovered. I know I'd pay for a nice boxed version

[JonnyBritish]

Dont the guys over in Poland have some unique cartridge? Disks are great but a cartridge would be awesome

[spookt]

Yep just recieved Bomb Jake on the Corina cart this morning. Awesome

[flashjazzcat]

I'll dig through my message box for the GR8 conversation. I can't remember offhand who I was talking to, it was so long ago.

 

I'd love to put LW on a cart because it would immediately alleviate a lot of problems regarding code space. But surely the screen RAM/memory map problem is insurmountable? The only thing I can think of is to split the screen RAM into two separate chunks - one below $4000 and the other above $8000 but below $A000. Then there's the job of re-writing 25K of code so it'll run in a bank-switched 8K cartridge space... or could the existing code just be flashed to a cart, then unfurled under the OS and into low memory, and the cart then switched off once the program had loaded??? That idea appeals...

 

Because I still see so much to improve, it's difficult to pick the best time to commit the software to a commercial package. Perhaps now would be a good time, though, to mark the last version which will run on 64K machines with a nice disk or cart based boxed package.

 

Anyway, suggestions for getting the current version on a cartridge are welcomed (I've never done any cart programming before). The VBXE and "Pro" standard versions are a good few months off completion yet.

 

By the way: fixed version without the disastrous search/replace bug here.

Edited February 16, 2010 by flashjazzcat

[+David_P]

The AtariMax 1Mb (128K) should be able to do what you ask - it's 16 8K banks. Though, with a bit of forethought, it should be possible to have all the executable within the 8K cart space, flipping to the needed banks as required - though perhaps some elements of the display driver would have to be in RAM. That way, the program occupies only 8K at a time, plus, perhaps, some low RAM - thus freeing up more base RAM

for features or documents.

[Rybags]

128K cart sounds good.

 

You can then go apeshit with the bloatware if you feel so-inclined.

 

Or, better idea - you can unroll and optimise the code to maximum effect. You could even bundle a DOS or three onboard the cartridge and have the option to use one of them or boot the user's choice of DOS the old-fashioned way.

 

You could leave RAM alone from $700-$2000 or so, which could allow DOS + DUP to remain resident.

[flashjazzcat]

Interesting ideas. The display RAM needs to be at least 10K, so if the software is to run in the cart space at $A000-$BFFF, the screen will have to be split in two, with one half around $2000 and the other half at $8000 or thereabouts. No other way I can think of doing it. It's doable, though, because the screen lines are accessed via pointers, and the pointers for each line can point anywhere we need them to. Only the screen clear routines will have to be made to work with non-contiguous RAM.

 

Even though the cart will allow me to add a lot of the stuff I haven't had room to do in the past, reorganizing things to reside in 3 or 4 discreet 8K blocks isn't going to be an easy task. It's hard enough trying to arrange the code in the "Pro" version (where the codebase and text buffers share the $4000-$7FFF area and avoid the shadow RAM). Doable, though, and if I elect to go down the 128K cart road now, I think it would be wise to commit the software totally to cartridge in the future. It's too much of a headache to keep a disk-based non-shadow RAM version, a VBXE version, and a different cart version all on the go at the same time.

 

Ideally, I'd say we should have a boxed disk version of 3.11 first, and thereafter perhaps switch all development to a cart-based product? What do people think? It's probably the most labour-intensive option, but it will yield the best results. We could even build the VBXE sensing and functionality onto the cartridge. Then, six months or a year down the line, release it boxed on a cart.

[Rybags]

It's always feasible to just have the cart act as a virtual disk - just swap it out for RAM when not needed.

 

Then the code between it and disk version can be practically identical - the cart just offers the advantage of much quicker loading, and the possibility of instant-start DOSes.

[flashjazzcat]

It's always feasible to just have the cart act as a virtual disk - just swap it out for RAM when not needed.

 

Then the code between it and disk version can be practically identical - the cart just offers the advantage of much quicker loading, and the possibility of instant-start DOSes.

That was my first thought on the matter, and would work with the current version. Presumably that's what Nosty's trying to do at the moment with version 3.11.

 

Writing a "proper" bank-switched cart (in the future) would ultimately be more flexible, though. I'd be interested to hear how people think it should proceed.

[+David_P]

Bank switches don't cost a lot of time, but need to be optimized; where possible, related routines should be in the same bank. If a routine knows its friends are in the same bank it can use normal means to go there, otherwise, it needs a formal calling mechanism.

 

A small memory resident routine could be used for banking, so code can be bank agnostic. Macro GOSUB could be defined to access routines:

 

 

GOSUB #Routine_ID would be expanded to:

 

LDX #Routine_ID ; which routine are we executing?

JSR Bank_Select_Routine; Installed somewhere in low memory or, alternatively, copied in each bank to free up RAM at the cost of space in each bank

 

 

Bank_Select_Routine

 

LDA Current_Bank; Where are we? So we can get back here!

PHA

...

; from the Routine_ID, get the bank number (one byte) and address in that bank to jump to. Store the bank number in the Cart bank select register, JSR to the address (self modifying code, perhaps)

...

PLA ; get back the bank we were in before we left

STA Bank_Select_Register ; reset the cart

RTS ; and right back where we started

 

This is limited to 256 possible routines, and requires 3 bytes per routine for the vectors. It also does not define any means of parameter passing between routines.

 

Sorry if this is a bit unclear; I'm doing it off the top of my head.

[Rybags]

I'd probably just maintain the vector table within ROM.

 

The save/restore to stack for "Current_Bank" is superfluous in many cases, you'd only really need it for nested situations where the sub you're calling is going to call something in another bank.

 

The RAM-based code to do it all is tiny anyway - just have a CALL and a CALLNEST to cater for situations where nested calls will happen.

[flashjazzcat]

Thanks for those ideas. I see what you'e getting at - it's quite clear. The method isn't dissimilar to the system I use at the moment to handle buffers spread across different extended banks. That said, stuff like the print processor and disk menu could probably be packaged into nice 8K chunks if I put my mind to it. This would allow for direct JSRs most of the time. It should be an interesting project.

[Mr.Amiga500]

I was just playing around with the new beta. It seems fast and I haven't found any bugs yet.

 

I noticed that now border text colour = text colour. (strangely changes to text colour only after accepting new colour settings)

 

Is there any way to change border text colour independently? Another thing - text colour can only be a shade of the background colour. Is that a limitation of the Atari graphics or by choice? Is it possible to choose from the full palette for each of the colour settings?

 

It's not that I'm a colour freak (though I admit... I am). I just want to pick the best colours for maximum text visibility. It's tricky getting a good combination for viewable 80-column text on composite.

Edited February 20, 2010 by Mr.Amiga500

[flashjazzcat]

I was just playing around with the new beta. It seems fast and I haven't found any bugs yet.

 

I noticed that now border text colour = text colour. (strangely changes to text colour only after accepting new colour settings)

 

Is there any way to change border text colour independently? Another thing - text colour can only be a shade of the background colour. Is that a limitation of the Atari graphics or by choice? Is it possible to choose from the full palette for each of the colour settings?

 

It's not that I'm a colour freak (though I admit... I am). I just want to pick the best colours for maximum text visibility. It's tricky getting a good combination for viewable 80-column text on composite.

You may have found a bug here, since border colour is supposed to be independent of the text colour. I'll look into it. Thanks!

 

The text colour being a shade of the background colour is indeed a limitation of the Atari graphics: one of its direst design flaws. You can, however, have any of the 128 colours for the background and border. The editor text can be any luminance of the background colours, and the status bar text any luminance of the border colour. Print preview enforces black text on a while background with a black border no matter what your colour settings. That's intentional, and the dark grey print preview text I momentarily adopted in the first beta has been dropped for simplicity's sake (it involved an extra DLI).

 

I never mess with the colours in this program since I always liked the pale blue text on a turquoise background, and I've gone to immense pains to make all six of my 8-bits display a picture wherein the 80-column display is crisp and sharp. However, I realize stock machines can look pretty dire and colour changes can make all the difference. Black text on a white background usually works well if you have poor vertical definition on the characters.

 

VBXE users are lucky, since the colour of the text and background is entirely independent (although not quite as independent as it could have been ). There's a beta version of LW for VBXE which you can read about on my website, and these is a screenshot (enlargable) of the lovely 80 column display. Fine tuning the colour isn't implemented yet in the beta, however. God knows when I'll get around to finishing the VBXE version. Once 3.11 is out of the way, the next major release will be on a cartridge (downloadable AtariMax 128K image) and will work with all available DOSes (including SpartaDOS 3.x and RealDOS, as well as - of course - all versions of the pre-eminent SpartaDOS X). Since that version will be bloat-crazy, I might just program VBXE detection into it and then we'll have a one-fits-all word processor for almost all popular hardware set-ups.

 

Another change in the 3.11 final: under SpartaDOS X, the disk menu will default to "long" format (i.e. with data, time, byte size and attributes displayed) unless overridden, since I suspect the feature gets missed a lot.

Edited February 20, 2010 by flashjazzcat

[Mr.Amiga500]

You may have found a bug here, since border colour is supposed to be independent of the text colour. I'll look into it. Thanks!

 

No, not border colour, border text colour. Here's the problem: if I have a light screen with dark text and dark border, I won't see border text. If I have a dark screen with light text and a light border, I won't see border text. If I could adjust border text colour independently, I wouldn't have a problem.

 

Print preview enforces black text on a while background with a black border no matter what your colour settings. That's intentional, and the dark grey print preview text I momentarily adopted in the first beta has been dropped for simplicity's sake (it involved an extra DLI).

 

Good. I don't like dark grey background with black text. That reminds me - why does the print preview just scroll by without stopping? Isn't it possible to have it pause (waiting for keypress) for every "page"? (screen page, not print page)

 

I never mess with the colours in this program since I always liked the pale blue text on a turquoise background, and I've gone to immense pains to make all six of my 8-bits display a picture wherein the 80-column display is crisp and sharp. However, I realize stock machines can look pretty dire and colour changes can make all the difference. Black text on a white background usually works well if you have poor vertical definition on the characters.

 

I like the standard Atari colours too, but with 80-column text in composite it is hard to read. I also like the default AtariWriter colours, but they are completely unreadable in 80-column. It's tricky picking useful colours. Even swapping identical colours (border/screen) changes the brightness and makes them appear to be different shades. The reds, yellows, purples and most greens are utterly useless. There are only a few colours I can use - mainly blues, blue/green and grey shades.

 

I don't ever plan on getting VBXE or doing any display mods, so I just need to be able to pick the best colours.

[flashjazzcat]

You may have found a bug here, since border colour is supposed to be independent of the text colour. I'll look into it. Thanks!

 

No, not border colour, border text colour. Here's the problem: if I have a light screen with dark text and dark border, I won't see border text. If I have a dark screen with light text and a light border, I won't see border text. If I could adjust border text colour independently, I wouldn't have a problem.

I've just tested it and it is a bug. The fact is the border text colour change is broken. I thought I'd fixed that bug but obviously not. It'll be fixed in the final version, so you'll be able to accomplish exactly what you describe.

 

Print preview enforces black text on a while background with a black border no matter what your colour settings. That's intentional, and the dark grey print preview text I momentarily adopted in the first beta has been dropped for simplicity's sake (it involved an extra DLI).

 

Good. I don't like dark grey background with black text. That reminds me - why does the print preview just scroll by without stopping? Isn't it possible to have it pause (waiting for keypress) for every "page"? (screen page, not print page)

You can pause the preview listing with CTRL-1 as usual (or <Select> or <Option>, while the <Start> key advances to the next page), and if you have "Page Wait" mode active (just stick "w1" [without quotes] in reverse video at the top of the document), preview will pause between each page (as you probably already know). However, there's nothing in place to pause it after each screenful (the way CTRL+V will "page" a file on the disk menu, while "V" on its own just scrolls the file by. You can page a file in the editor with CTRL+J: type the name, and add /P after it.); I'll try and add it as an option? It's an excellent observation, anyway: thanks again.

Edited February 20, 2010 by flashjazzcat

[nosty]

It's always feasible to just have the cart act as a virtual disk - just swap it out for RAM when not needed.

 

Then the code between it and disk version can be practically identical - the cart just offers the advantage of much quicker loading, and the possibility of instant-start DOSes.

That was my first thought on the matter, and would work with the current version. Presumably that's what Nosty's trying to do at the moment with version 3.11.

 

Hi,

Yes, I have tried exactly this way today I have 128kB cartridge which works as Rybags described. So I put LW (renamed to AUTORUN.SYS) and DOS into cartridge. This cartridge can works as virtual readonly disc. The LW works fine and can use files without loading any DOS from disk So I have a first prototype od The Last Word 3.11 cartridge now

 

And I have two different ideas how LW can works with cartridge... And I must talk with flashjazzcat

[flashjazzcat]

And I have two different ideas how LW can works with cartridge... And I must talk with flashjazzcat

Great. I'm listening...

[+Philsan]

Months ago I proposed a boxed version of LW by GR8 Software.

Moreover Corina cartridge could do wonders.

GR8 news!