The Last Word 3.21 Released

[flashjazzcat]

OK. Here's a slightly regressed build which reintroduces support for the SDX TD Line. I still keep the text in ATASCII order in the buffer (rather than converting it to internal codes and back again), but I got around the font character order problem by introducing a 256-byte look up table for efficient on-the-fly conversion to internal codes when drawing to the screen. A lot of stuff had to be squashed down in the video driver code to accommodate this, but it's done. The VBXE driver thus didn't need any changes, but as ever you need to use the driver which comes with this build (as opposed to an old one).

 

I also discovered some more bugs in the print processor which were introduced when I (fairly recently) converted the source code to MADS format. Turns out .BYTE +$80,59,61 does not produce $BB,$BD, but .BY $80,59,61 does. This had comprehensively broken half of the print processor directives, so FOOTNOTE.TXT wouldn't even print at all. This is hopefully fixed now.

 

Another minor improvement is in the code which clears the screen. This is now optimised so that typing the first few lines of text into an empty file should feel a lot quicker.

 

So - please update. If this one proves stable, I'll do a final release and draw a line under it.

 

LW33_Test2.zip

 

Also at:

 

http://www.atari8.co.uk/lastword/

Edited August 26, 2013 by flashjazzcat

[Mr.Amiga500]

Is 3.21b the final version that doesn't require VBXE or does 3.3 work on a non-VBXE machine but require more than 64k? I see no mention of requirements anywhere.

[flashjazzcat]

Is 3.21b the final version that doesn't require VBXE or does 3.3 work on a non-VBXE machine but require more than 64k? I see no mention of requirements anywhere.

 

Yeah - I haven't written release notes yet, but 3.3 doesn't require VBXE: just get rid of the VDR file if you don't have one. Version 3.3 has the same RAM requirements as all previous versions too.

[Mr.Amiga500]

Oh good. I thought I was stuck at 3.21b.

 

I tried 3.3 earlier, but didn't realise that it was just the executable - and assumed it didn't load the support files because lack of memory.

 

I put lw.exe in my ATR, changed PADCHAR and EOLCHAR in the lw.cfg (was getting some á characters) and now everything seems to be working. It definitely seems faster. Thanks!

[flashjazzcat]

I put lw.exe in my ATR, changed PADCHAR and EOLCHAR in the lw.cfg (was getting some á characters) and now everything seems to be working. It definitely seems faster. Thanks!

 

I just found a README from a year ago which describes the change needed to PADCHAR and EOLCHAR... basically, they're ASCII now (they used to be internal codes). I should have made them ASCII codes from version 1...

[Mr.Amiga500]

I read about the PADCHAR and EOLCHAR on page 6 of this thread. If it wasn't for that post, I'd be saying, "What the f...."

 

I do read README files, but The Last Word 3.21b was two years ago. I read that whole thing. I didn't see the one from last year because that's when I thought you started making it VBXE-only, so didn't bother reading anything (even posts). I shall read every README you make from now on... starting.......NOW!

[flashjazzcat]

I read about the PADCHAR and EOLCHAR on page 6 of this thread. If it wasn't for that post, I'd be saying, "What the f...."

 

I do read README files, but The Last Word 3.21b was two years ago. I read that whole thing. I didn't see the one from last year because that's when I thought you started making it VBXE-only, so didn't bother reading anything (even posts). I shall read every README you make from now on... starting.......NOW!

 

There was actually a topic for the VBXE version and I suppose that's where I should have uploaded these new versions. Anyway - that's where I found the README for the RC of version 3.3. I'll work on updating the docs and compiling the extensions, then we'll be pretty much finished.

[Kyle22]

Looks good, except for the help screens, where the PADCHAR appears to be a 3 character sequence a@[], where the a has an accent mark, and [] represents a space.

 

-K

[drac030]

I finally have managed to install the latest binaries, i.e. from 28 August. Well, still no luck here, LW 3.3 ran once, any later attempt causes a spectacular crash. If I look at the number of settings defined in the number of different places, I really feel lost a bit, what to try next. Anyway, I tried it on the default SDX config, crash too.

 

There's one thing to fix I managed to identify, though, mainly because 3.21 has the same problem. Namely, when LW quits, it forces the Break key interrupt vector to point to the address valid for XL OS (ie. $C093), instead of restoring its previous value. Could you fix it, Jon?

 

EDIT:

 

Some additional info:

 

1) it seems to crash when loading LW.VDR. At least that's the last filename visible on the splash screen while loading. This file is 4486 bytes, date 5 March 2013.

 

2) it seems to ignore CONFIG.SYS settings: I have set LWSPLASH=0 but the splash screen still appears (also when I set LWSPLASH=1, no difference).

 

3) the rest of settings:

 

 

LWDRIVE=D3:
LWPATH=D3:>TEXT>LW33>
LWSYS=D3:>TEXT>LW33>LW.SYS

Edited September 1, 2013 by drac030

[flashjazzcat]

I finally have managed to install the latest binaries, i.e. from 28 August. Well, still no luck here, LW 3.3 ran once, any later attempt causes a spectacular crash. If I see at the number of settings defined in the number of different places, I really feel lost a bit, what to try next. Anyway, I tried it on the default SDX config, crash too.

 

There's one thing to fix I managed to identify, though, mainly because 3.21 has the same problem. Namely, when LW quits, it forces the Break key interrupt vector to point to the address valid for XL OS (ie. $C093), instead of restoring its previous value. Could you fix it, Jon?

 

Certainly I'll fix the Break bug right away - a serious oversight on my part, for which apologies.

 

Regarding your troubles / confusion... I'm a bit puzzled, to be honest. LW runs "out of the box" with SDX (providing SDX is using banked RAM) without any config files at all, so perhaps you should delete everything and start again. I got rid of a couple of settings in the latest build (although these changes aren't properly written up yet in published form), but I have to urge against overstating the problem of proliferating settings. I haven't had other complaints since we simplified the RAM configuration back in 2008/2009, and normally I can get folks up and running if they're having problems after a couple of exchanged emails. If you're really up against a brick wall for some reason, drop me a mail, or better yet arrange a time to get on chat or something. I'll be glad to help.

[drac030]

Hope you saw my "additional info" above. I also first try it on a different machine. As for deleting everything and installing again, I would like to do try that too, of course, but I don't see where is the 3.3-beta distribution. The archive you posted contains only two files, not even a LW.VDR.

 

EDIT:

 

 

 

LW runs "out of the box" with SDX (providing SDX is using banked RAM) without any config files at all

 

Correct. I deleted all the env. variables related to LW, removed LW.EXE from $PATH, did CD TEXT>LW33 then LW and this time it ran. So it seems defining the settings makes a trouble to the program.

 

But anyway, I need it to run even when LW.EXE is in $PATH and the current drive/dir is not D3:>TEXT>LW33 (but for example D6:>DOC>MAN).

Edited September 1, 2013 by drac030

[flashjazzcat]

Hope you saw my "additional info" above. I also first try it on a different machine. As for deleting everything and installing again, I would like to do try that too, of course, but I don't see where is the 3.3-beta distribution. The archive you posted contains only two files, not even a LW.VDR.

 

I didn't... but suddenly I do.

 

1) Don't use anything but the VDR file which came out of the same archive as LW.EXE. If the VDR file is called VBXE.VDR (instead of LW.VDR) it was to stop it being loaded when non-VBXE users (i.e. the majority) unwittingly copied both files across to their disks. Solution: rename latest VBXE.VDR to LW.VDR, and delete the old one. Observe the rule of "only use latest driver with latest binary", and you will avoid problems.

 

2) Maybe this is broken - I'll test. Does the splash screen disappear if you specify a filename to load on the command line (it should)?

 

3) Looks reasonable.

[drac030]

1) the archive does not contain any LW.VDR so I have touse what I have here.

 

2) the machine I am trying this on does not have VBXE installed, so when I follow your advice, it only (quite correctly) says that there is no VBXE detected.

 

3) I cannot test if the splash screen appears when a parameter is given, because it stopped working again - I've moved it to D3:>LW33 to see if the path is not too long... now there's some difference, namely when loading LW.VDR it just hangs, with no special video effects. When I give a file name as a parameter, a spectacular crash occurs. But no splash screen before it, as far as I can say.

[flashjazzcat]

1) What does the archive contain, if not LW.VDR nor the aforementioned VBXE.VDR?

 

2) In that case - forget the above. Get rid of all versions of LW.VDR on your hard drive if the machine has no VBXE installed. LW.VDR (VBXE.VDR if you will) is a driver for VBXE, so running it makes no sense when the hardware is not present. All that will happen (if you manage to use the correct driver version) is that the screen will display "VBXE not present".

 

3) To reiterate: get rid of LW.VDR. It's clearly the wrong version (as I've explained), and you don't require it anyway on this machine (as I said above).

 

The reason the application crashes if the wrong driver is used is that the driver is an overlay (whose segments are loaded by the program, not via DOS binary load), and if the driver has the wrong equates, naturally problems will ensue.

Edited September 1, 2013 by flashjazzcat

[drac030]

 

 

 

1) What does the archive contain, if not LW.VDR nor the aforementioned VBXE.VDR?

 

LW.EXE and VBXE.VDR, which, I presume, is for VBXE

 

 

 

2) In that case - forget the above. Get rid of all versions of LW.VDR on your hard drive if the machine has no VBXE installed. LW.VDR (VBXE.VDR if you will) is a driver for VBXE, so running it makes no sense when the hardware is not present. All that will happen (if you manage to use the correct driver version) is that the screen will display "VBXE not present".

 

Well, this seems to fix all problems I didn't realize that LW.VDR is for VBXE - I though that's the vanilla GR.8 driver you use instead of VBXE.VDR on non-VBXE Ataris.

 

LW33 seems to work now. Hopefully I will now be able to get rid of 3.21

 

Anyway, could it be done so that the VBXE driver, when loaded on a non-VBXE machine, would just fall back to default routines instead of saying what it says and quitting? This way the same installation LW could be used on a machine with VBXE and one without VBXE, without forcing the user to change settings whenever he plugs the hard drive into a different computer. I myself, being a huge fan of VBXE, nevertheless own another Atari without one.

 

Thanks anyway.

Edited September 1, 2013 by drac030

[flashjazzcat]

 

 

LW.EXE and VBXE.VDR, which, I presume, is for VBXE

 

 

 

 

Well, this seems to fix all problems I didn't realize that LW.VDR is for VBXE - I though that's the vanilla GR.8 driver you use instead of VBXE.VDR on non-VBXE Ataris.

 

LW33 seems to work now. Hopefully I will now be able to get rid of 3.21

 

Anyway, could it be done so that the VBXE driver, when loaded on a non-VBXE machine, would just fall back to default routines instead of saying what it says and quitting? This way the same installation LW could be used on a machine with VBXE and one without VBXE, without forcing the user to change settings whenever he plugs the hard drive into a different computer. I myself, being a huge fan of VBXE, nevertheless own another Atari without one.

 

Thanks anyway.

 

Ah - the veil of confusion lifts! The vanilla GR.8 driver is built into the executable. The idea here is that it's convenient to be able to run the program using only a single file.

 

I'll be glad if you could start using the latest version, and perhaps report back any problems. There's a known bug in the one I uploaded here a while back (concerning view file / help), but I fixed that at this end and am just waiting to find more issues.

 

Interesting suggestion regarding driver installation. This could be done if the driver init block (which is jettisoned after use) were loaded and executed before the main overlay block. The VBXE detection routines are in the disposable code, so I'll have a look at how feasible this is. Of course even the jettisoned code overwrites some vanilla driver stuff, so it may not be that easy.

Edited September 1, 2013 by flashjazzcat

[+Stephen]

Got the update installed on my IDE+2 SDX setup. It seems fine so far (minus the already mentioned and fixed help viewer).

[flashjazzcat]

Here's a test version which doesn't bail out if the VBXE driver is loaded when there's no VBXE hardware present:

 

LW33Test3.zip

 

I'll add some kind of version check in the driver loader later, but for now: don't use other versions of LW.VDR. Even if you don't have VBXE, the wrong driver version will simply crash the program. If you don't have any VBXE machines, simply jettison LW.VDR and forget it ever existed.

 

For those interested: the code which loads the driver is now a full binary loader which can deal with any number of file segments and also observes the DOS INIT vector at $2E2. The VBXE driver loads a very small segment of hardware detection code in "safe" memory, then runs it during the driver load process. The init code returns $FF on fail, $01 on success. This tells the main application whether to continue loading the main overlay, or to simply close it and load the rest of the config files.

 

I also fixed the LWSPLASH environment variable bug.

 

[drac030]

Thanks, Jon, it seems to work as advertised. The only thing I hate to mention is that the Break key vector value is still wrong after the LW quits. It is very annoying, because after using LW you suddenly can't Break a long directory listing for example (otherwise than with a RESET).

[flashjazzcat]

The only thing I hate to mention is that the Break key vector value is still wrong after the LW quits. It is very annoying, because after using LW you suddenly can't Break a long directory listing for example (otherwise than with a RESET).

 

Apologies - completely forgot about that. Hopefully fixed:

 

LW33_Test4.zip

 

Now saves the original Break vector and restores it on exit. I'll add the final touches later (including some optional colour-cycling for the VBXE driver, if not something more fancy).

 

Edit: Do you think print preview and file view (the latter when using a hard disk, at least) scrolling is a little too fast when using the VBXE display?

Edited September 2, 2013 by flashjazzcat

[+Stephen]

Last ZIP file seems to be empty. Also - the view help file is still showing odd characters where the spaces should be.

[flashjazzcat]

Oops...

 

LW33_Test4.zip

 

Help files (from older version) are fine here:

 

 

Can you post a screenie of how your help files look?

Edited September 3, 2013 by flashjazzcat

[+Stephen]

Awesome - this latest version is working perfectly.

[drac030]

 

Apologies - completely forgot about that. Hopefully fixed:

 

LW33_Test4.zip

 

Now saves the original Break vector and restores it on exit. I'll add the final touches later (including some optional colour-cycling for the VBXE driver, if not something more fancy).

 

Edit: Do you think print preview and file view (the latter when using a hard disk, at least) scrolling is a little too fast when using the VBXE display?

 

Yes, at least the print preview may seem too fast.

 

Another thing: there's a problem or I am doing something wrong again, but on my VBXE Atari I can see that LW behaves as follows:

 

1) when no LWPATH is defined, LW loads the file specified in the command line (e.g. LW CHANGES.TXT from a random drive/path outside the place where LW resides), but apparently does not load LW.VDR, judging from the fact that the display is in GR.8.

 

2) when LWPATH is defined, LW loads LW.VDR and runs in VBXE text mode, but does not load the text specified in the command line - only says "Not found".

 

As about the LW.VDR - when the VDR stuff finally stabilizes, could you describe the format and requirements for a VDR module? This would greatly help people in customizing LW for new display hardware (if any ever appears).

[flashjazzcat]

 

Yes, at least the print preview may seem too fast.

 

Another thing: there's a problem or I am doing something wrong again, but on my VBXE Atari I can see that LW behaves as follows:

 

1) when no LWPATH is defined, LW loads the file specified in the command line (e.g. LW CHANGES.TXT from a random drive/path outside the place where LW resides), but apparently does not load LW.VDR, judging from the fact that the display is in GR.8.

 

2) when LWPATH is defined, LW loads LW.VDR and runs in VBXE text mode, but does not load the text specified in the command line - only says "Not found".

 

As about the LW.VDR - when the VDR stuff finally stabilizes, could you describe the format and requirements for a VDR module? This would greatly help people in customizing LW for new display hardware (if any ever appears).

 

Thanks for this. I've really struggled to get detailed testing feedback on these new versions in the past - at least until now.

 

1) and 2) - I'll look into these.

 

Regarding the driver format: certainly I'll do exactly this. It should be possible to write modules for other hardware, although the proof will be in the doing, and it's likely that some flaw in the driver architecture (to use a grandiose term for it) will be thrown up if and when someone attempts to do it. For one thing, when the 10KB Antic frame buffer isn't needed, it should really be used for text buffer space, but this would require yet another hefty re-write of the mainline code.

 

EDIT: I cannot currently duplicate the failure to load either the VDR module nor the text file specified on the command line. Note that LW.VDR will be loaded from one of the folders specified in the LWPATH. Can you describe the exact folder structure in use, and send across SYS file and a dump of environment variables?

Edited September 3, 2013 by flashjazzcat