The Last Word 3.21 Released

[drac030]

Sure. Folder structure:

 

1) LW.EXE in C:>DOS>

 

2) the rest of files in C:>TEXT>LW33>

 

3) LWSYS=D3:>TEXT>LW33>LW.SYS

 

LW.SYS:

 

 

banked off
banks 1,2,3,4,5,6,7,8,9,10
reserve 2
buffer on
extpages 7
docext LWD
;path D3:
; progbar off
loadvdr LW.VDR

 

Env variables:

 

 

BOOT=C:>
SYSERR=CAR:SYSERR.MSG
MAXDRV=O:
PROMPT=$L$P
PATH=CAR:;C:>DOS>
MANPATH=CAR:;C:>MAN;C:>HELP
BASIC=C:>TMP>BASIC.SAV
CAR=C:>TMP>CAR.SAV
TEMP=C:>TMP
DAYTIME=2
ED=0
PAGER=LESS;/C;
LWSYS=D3:>TEXT>LW33>LW.SYS
DIRCOLORS=$0E,$0A,$9E,$9A
SC=C:>SYS>SCMAIN.OVL

 

Optional:

 

 

LWPATH=D3:>TEXT>LW33>

[flashjazzcat]

Unfortunately, using this exact folder structure, that exact LW.SYS file, and the same pertinent environment variables, I can't trigger any problems yet. I can start LW from any folder (because the EXE is referenced in the DOS path), with or without a filespec on the command line... the text file is always loaded, and LW.VDR always installed. I DID discover another bug in the way config file syntax errors are reported at startup (my own typo), so this is good at least.

 

All I can venture at this point is that any pathing which has been set up is NOT used when accessing files to load into the editor (i.e. those names specified on the command line). That would be a crazy, of course, but it might be worth mentioning.

 

e.g. I have placed a file called TEST.TXT in the "text" folder of your disk structure. I can CD to > or >DOS and type:

 

X LW.EXE >TEXT>TEST.TXT

 

or (if I'm in >TEXT):

 

X LW.EXE TEST (.TXT is added if I omit it)

 

and the editor loads up (no loading screen), and LW.VDR is installed correctly. Whether VDR appears in LW.SYS is immaterial here, since it's the default driver name anyway, and you've specified no path.

 

LWSYS (environment variable) is really superfluous anyway under SDX, since the LWPATH will be searched for the SYS file. So - just specify the LWPATH in CONFIG.SYS, place all config files in that folder, and forget everything else.

 

I might as well dispense with LWSYS entirely anyway - I can't really recall its purpose and all it seems to create here is confusion. So your point about simplicity is - at last - well taken.

 

I'll remove this, fix the error reporting bug, and then we'll see if problems persist.

 

EDIT: heh... it seems I've already removed all references to LWSYS in this build anyway. The environment variable is being completely ignored anyway... so you may safely delete it.

Edited September 3, 2013 by flashjazzcat

[Roydea6]

 

The tab character at top of screen (down ward pointing arrow) seems to be not as clean as previous LW32b

 

And also the EOL character at end of a line looks like the ESC character.

 

Maybe I need a different font .F80 file..

Also why does the lw.cfg file CAPSLOCK ON revert to CTR(control) instead of UPR(uppercase)???

Edited September 4, 2013 by rdea6

[drac030]

Unfortunately, using this exact folder structure, that exact LW.SYS file, and the same pertinent environment variables, I can't trigger any problems yet. I can start LW from any folder (because the EXE is referenced in the DOS path), with or without a filespec on the command line... the text file is always loaded, and LW.VDR always installed. I DID discover another bug in the way config file syntax errors are reported at startup (my own typo), so this is good at least.

 

All I can venture at this point is that any pathing which has been set up is NOT used when accessing files to load into the editor (i.e. those names specified on the command line). That would be a crazy, of course, but it might be worth mentioning.

 

e.g. I have placed a file called TEST.TXT in the "text" folder of your disk structure. I can CD to > or >DOS and type:

 

X LW.EXE >TEXT>TEST.TXT

 

or (if I'm in >TEXT):

 

X LW.EXE TEST (.TXT is added if I omit it)

 

and the editor loads up (no loading screen), and LW.VDR is installed correctly. Whether VDR appears in LW.SYS is immaterial here, since it's the default driver name anyway, and you've specified no path.

Here, when I place a test file in >TEXT, do CD >DOS and do X LW.EXE >TEXT>TEST.TXT, this is what happens:

 

1) LW loads the file

 

2) on top of it, automatically adds the following: Welcome to the VBXE-enabled version of the last word. Rename VBXE.VDR to LW.VDR abd restart the program to use the VBXE driver.

 

3) when I quit LW, the file WELCOMED appears in the current folder (C:>DOS> in this case)

 

When I run LW without a parameter, the text above appears too, and WELCOMED is created in the current folder.

 

That's if the current drive is the same drive LWPATH points to. When it is not the same drive, but f.e. F: is current, the LW behaves a bit different:

 

1) when D3:WELCOMED (note current dir!) exists, doing X LW.EXE DF:>ASM>XX>YYYY>DOC>CHANGES.TXT loads the file which appears on the screen for a second, then it is deleted from the memory, and LW presents blank buffer with UNNAMED.TXT as the name.

 

2) when D3:WELCOMED does not exist, doing the same as above loads the file, then adds on top of it: Welcome to the VBXE-enabled version of the last word etc. And D3:WELCOMED gets created.

 

3) when D3:WELCOMED exists, doing CD >ASM>XX>YYYY>DOC> then X LW.EXE CHANGES.TXT results in empty buffer and "Not found" message below.

 

4) when D3:WELCOMED does not exists, the result is identical, but WELCOMED is not created anywhere (?).

 

It looks like LWPATH is partly ignored (partly, because the program somehow can find LW.VDR). But generally I am a bit lost.

 

EDIT: heh... it seems I've already removed all references to LWSYS in this build anyway. The environment variable is being completely ignored anyway... so you may safely delete it.

Good

[flashjazzcat]

Here, when I place a test file in >TEXT, do CD >DOS and do X LW.EXE >TEXT>TEST.TXT, this is what happens:

 

1) LW loads the file

 

2) on top of it, automatically adds the following: Welcome to the VBXE-enabled version of the last word. Rename VBXE.VDR to LW.VDR abd restart the program to use the VBXE driver.

 

3) when I quit LW, the file WELCOMED appears in the current folder (C:>DOS> in this case)

 

When I run LW without a parameter, the text above appears too, and WELCOMED is created in the current folder.

 

That's if the current drive is the same drive LWPATH points to. When it is not the same drive, but f.e. F: is current, the LW behaves a bit different:

 

1) when D3:WELCOMED (note current dir!) exists, doing X LW.EXE DF:>ASM>XX>YYYY>DOC>CHANGES.TXT loads the file which appears on the screen for a second, then it is deleted from the memory, and LW presents blank buffer with UNNAMED.TXT as the name.

 

2) when D3:WELCOMED does not exist, doing the same as above loads the file, then adds on top of it: Welcome to the VBXE-enabled version of the last word etc. And D3:WELCOMED gets created.

 

3) when D3:WELCOMED exists, doing CD >ASM>XX>YYYY>DOC> then X LW.EXE CHANGES.TXT results in empty buffer and "Not found" message below.

 

4) when D3:WELCOMED does not exists, the result is identical, but WELCOMED is not created anywhere (?).

 

It looks like LWPATH is partly ignored (partly, because the program somehow can find LW.VDR). But generally I am a bit lost.

 

 

Good

 

Delete LW.MAC and tell me what happens. You've got an old autorun macro in the path somewhere, which I remember writing a greeting message on the screen. At least with this gone, the issues should be easier to comprehend. IIRC, the macro even checks for the pre-existence of WELCOME.TXT... so it will be causing you all manner of headaches, I think.

 

LWscreen.JPG

 

The tab character at top of screen (down ward pointing arrow) seems to be not as clean as previous LW32b

 

And also the EOL character at end of a line looks like the ESC character.

 

Maybe I need a different font .F80 file..

Also why does the lw.cfg file CAPSLOCK ON revert to CTR(control) instead of UPR(uppercase)???

 

Not sure what on earth is going on with your font. I'll have a look at the caps lock matter.

Edited September 4, 2013 by flashjazzcat

[drac030]

Delete LW.MAC and tell me what happens.

Thanks for the tip, LW seems to work better now. It loads the specified file as long as it is located on the drive where LW resides (and the one specified in LWPATH). When I want to load something from another drive, I have to specify the drive, e.g.:

 

1) F:, CD >, LW >ASM>XX>YYYY>DOC>CHANGES.TXT doesn't work (Error 150), but:

 

2) F:, CD >, LW DF:>ASM>XX>YYYY>DOC>CHANGES.TXT does.

[flashjazzcat]

Thanks for the tip, LW seems to work better now. It loads the specified file as long as it is located on the drive where LW resides (and the one specified in LWPATH). When I want to load something from another drive, I have to specify the drive, e.g.:

 

1) F:, CD >, LW >ASM>XX>YYYY>DOC>CHANGES.TXT doesn't work (Error 150), but:

 

2) F:, CD >, LW DF:>ASM>XX>YYYY>DOC>CHANGES.TXT does.

 

Right - that's a little better. This is surely a bug, though, so I'll check it out.

[flashjazzcat]

Thanks for the tip, LW seems to work better now. It loads the specified file as long as it is located on the drive where LW resides (and the one specified in LWPATH). When I want to load something from another drive, I have to specify the drive, e.g.:

 

1) F:, CD >, LW >ASM>XX>YYYY>DOC>CHANGES.TXT doesn't work (Error 150), but:

 

2) F:, CD >, LW DF:>ASM>XX>YYYY>DOC>CHANGES.TXT does.

 

Getting different results here, I'm afraid:

 

LWPATH=D3:>TEXT>LW33>

 

PATH=CAR:;C:>DOS>

 

LW.SYS and LW.VDR in C:>TEXT>LW33

 

TEST.TXT in D:>TEXT>DOCS

 

D:

CD >

X LW.EXE >TEXT>DOCS>TEST - results in D4:>TEXT>DOCS>TEST.TXT being loaded into the editor.

 

So I'm a bit lost myself now...

[drac030]

Retried the experiment with D4:>TEXT>DOCS>, after clean reboot, with default CAR:CONFIG.SYS.

 

At evening I'll try to find out what path it is trying to access, but I am pretty sure that it will be D3:>TEXT>DOCS>.

[flashjazzcat]

Retried the experiment with D4:>TEXT>DOCS>, after clean reboot, with default CAR:CONFIG.SYS.

 

At evening I'll try to find out what path it is trying to access, but I am pretty sure that it will be D3:>TEXT>DOCS>.

 

Just noticed that SET LWDRIVE=D3: in CONFIG.SYS will cause this exact issue. That's because it overrides the DOS default drive, so best leave it out. Without this environment variable, the currently logged DOS drive is used as the default ID when none is specified (and is also the drive which will be called up by default when you catalogue a drive in LW).

[drac030]

Notice that CAR:CONFIG.SYS does not define LWDRIVE, so this is not the case.

 

But I managed to make the following set of commands succeed:

 

1) D:

2) CD >

3) X LW.EXE >TEXT>DOCS>TEST

 

It "succeeds" when D3:>TEXT>DOCS>TEST.TXT exists. When this folder structure on D3 does not exist, an attempt to load from D4 causes Error 150. When the folder structure exists, and the file does not, it is only "Not found".

 

It also succeeds when the actual D4:>TEXT>DOCS>TEST.TXT does not exist. It seems the LW always tries to load from the drive which it has in LWPATH.

[flashjazzcat]

Quite bizarre - but thanks for that extra information: really helpful. However, I completely got rid of the LW path (so it can't find any config files) and I can still load TEST.TXT from the D4:>TEXT>DOCS without a corresponding file/folder structure on the C: drive. How odd is that...

[drac030]

Yep, without LWPATH it loads from the drive/path specified in the command line. With LWPATH it loads from the path specified in the command line and the drive specified in LWPATH.

[flashjazzcat]

Yep, without LWPATH it loads from the drive/path specified in the command line. With LWPATH it loads from the path specified in the command line and the drive specified in LWPATH.

 

Finally managed to reproduce this by placing DRIVE D3: in LW.CFG. Comment that out, and it should work. If cause is different, let me know.

 

I think these drive settings (if they are preserved at all) should simply be applied after the editor has finished loading files specified on the command line.

[drac030]

Excellent, it works now. Thank you.

[flashjazzcat]

Excellent, it works now. Thank you.

 

Great. I'll perhaps move DRIVE to LW.SYS and prevent it from overriding whatever the default SDX drive is until after the command line list has been dealt with. Many thanks for your scrupulous testing.

[flashjazzcat]

Yep, without LWPATH it loads from the drive/path specified in the command line. With LWPATH it loads from the path specified in the command line and the drive specified in LWPATH.

 

Here's a version with the changes mentioned earlier:

 

LW33_Test5.zip

 

• Changes to the default drive (either via environment variable, LW.SYS "DRIVE" statement, or command line switch) are now not applied until after any text files specified on the command line are loaded. If you don't specify a drive ID at the start of a text file's name on the command line under SDX, therefore, the drive ID used will always been the currently logged DOS drive.
• As implied above: the "DRIVE" option has been moved from LW.CFG (which can be loaded / saved at any time during an editing session, saved files reflecting current settings, loaded files applying changes immediately) to LW.SYS. So, if you have "DRIVE D3:" in LW.SYS, it won't come into play until you first load a text file in the editor without supplying a drive spec, or when you first catalogue a disk. There's therefore now no way to inadvertently cause problems by saving "LW.CFG" from the editor, and creating a DRIVE Dn: line which later upsets command line loading.
• Syntax errors in config files are now properly reported even when the VBXE driver is in use.

 

It should be obvious that the presence of "DRIVE Dn:" in LW.CFG is now a syntax error. You will have to edit this out.

 

There may yet be another couple of tweaks to make, but hopefully not too many.

Edited September 4, 2013 by flashjazzcat

[drac030]

Unfortunately, this one does not start on a no-VBXE Atari. Renaming or deleting LW.VDR is required to fix it.

[flashjazzcat]

Unfortunately, this one does not start on a no-VBXE Atari. Renaming or deleting LW.VDR is required to fix it.

 

Sorry about that. I had implemented some CIO error checking in the loader, but it had undesired results, apparently.

 

Try this:

 

LW33_Test6.zip

 

This one also corrects a bug in the VBXE palette in print preview mode (apparent only if you selected an alternative border colour in one of the older versions), as well as one line of spurious crap at the end of the new shorter CFG file when you save it from the editor with Shift+Ctrl+O.

 

EDIT: Found SHFLOK bug reported earlier - basically caused by config loader thinking "ON" is always $80. Needs translating to $40 in the case of uppercase lock. I'll also add a delay in print preview (VBXE mode).

Edited September 4, 2013 by flashjazzcat

[flashjazzcat]

Bug in UPPERCASE ON fixed, and delay introduced in print preview to slow down the VBXE mode scrolling slightly. Another small bug in initial config file loading phase also fixed.

 

LW33_Test7.zip

 

[Roydea6]

Bug in UPPERCASE ON fixed, and delay introduced in print preview to slow down the VBXE mode scrolling slightly. Another small bug in initial config file loading phase also fixed.

 

LW33_Test7.zip

 

For this update works nice with my Atari800 Incognito setup and also my 800 XL with Ultimate and Side, Side2, MyIDE, MyIDE2 & of course Altirra [Emulator]

 

Someday I will probably install my VBXE2, still looking for a compatible Monitor.

[flashjazzcat]

Nice article in Re.Bit magazine (Italian):

 

The Last Word (Re.Bit)

 

Thanks to Francesco Ugga for posting this on Facebook.

[+Larry]

Before I dig out an XEP80 and hook it up, will the Last Word work properly with it's replacement E: device? Looked/searched briefly in the manual, but didn't see anything about the XEP80?

 

Since I discovered that my AIW capture can display overscan, it's probably worth a try. What a pain this XEP80 has been! but it did work fine with the Bob1200xl RGB conversion from Atari Classics when used with AtariWriter 80.

 

-Larry

[flashjazzcat]

Definitely not. TLW does direct screen writes. You're better off using the VBXE version.

[w1k]

i cant run LW33_test7 from SDX 4.47 - freeze on loading VDR file