The Last Word 3.1 Released

[+Stephen]

Happy birthday (and AA anniversary) - you posted as much in a year as I have in 9! I'll have an extra drink for you this evening

 

Stephen Anderson

[flashjazzcat]

3.11 update is coming. I've decided to comprehensively back-up and then reformat the PC for the new year. Even went out and bought an external drive specially for the purpose.

 

The fast screen update is still buggy and I'm in two minds about it anyway. I may offer it as an option if I can get it working. Then, the first quick programming job after Christmas is a VBXE test version of LW. I can't wait to see a word processor running in VBXE's 80 column mode. I'll probably end up having a lot of fun fancying up the screens.

 

 

 

 

 

 

[flashjazzcat]

It seems there are more improvements to be made here than I thought. Firstly, the faster refresh routine finally works:

 

LW 3.11.wmv

 

The reason that took so long to get right will be of more interest to programmers than general users. Editing is just about as fast in the "quick" mode in 80 columns as it is in the normal 40 column mode. The feature - which I'm thinking of calling "Fastype" - will be user-selectable, so if you prefer the screen to update properly between each keystroke regardless of how fast you're typing, you can make it so.

 

I also have ideas which will drastically reduce the amount of code dealing with text selection highlighting, and I aim to eliminate the slow-down of the cursor when highlighting text. These are all concepts I'm introducing which will ultimately be used in the GUI word-processor which will hopefully see the light of day in a year or so. There are a lot of complicated tricks to be worked out in order to get a screenful of proportional text working at a useable speed, and those same ideas should make LW 3.11 double-fast. And I figure I might as well make LW 3.11 worth the mouse clicks necessary to download it!

[Mr.Amiga500]

Nice. I really like to see programmers optimise code for speed and size. It's totally unlike today's programming method of adding loads of unnecessary inefficient crap and just increasing minimum processor/memory requirements.

[+Stephen]

Looks great! I am finally setting up a dedicated Sparta DOS X Last Word disk. I am running a 320KB machine. By using BANKED and a 64KB RAMdisk (which I consider a scratchpad), I get a 19K main buffer and 9 extended 16K banks. Insanely cool.

 

Quick question - is it possible to set up LW so that everythnig is in subdirectories? I would like a LW folder which contains folders for fonts, macros, help files, etc.

 

Stephen Anderson

[flashjazzcat]

Quick question - is it possible to set up LW so that everythnig is in subdirectories? I would like a LW folder which contains folders for fonts, macros, help files, etc.

On my way out now (spent too long messing around: see "vertical lines" topic), but yes, you can have everything in subdirectories. Just edit LW.SYS and put a list of semi-colon separated paths after the "PATH" command, thus:

 

PATH D8:;D1:>LW>

 

This will cause LW to search the RAMdisk, then D1:>LW> when you try to load a font or macro, etc, by typing the name directly at the load prompt. You don't have to use more than one path, of course:

 

PATH D1:>LASTWORD>

 

will just search the LASTWORD folder on drive one. IIRC, the default drive (i.e. the drive catalogued on the disk menu) is always searched regardless of what you put in the path, but don't quote me on that since I forget for the moment!

 

Sadly the file selector doesn't automatically list the folder(s) in the PATH variable. This would have been nice but attempts to implement it introduced more problems than they solved.

 

However... if you're using SpartaDOS X, it's easier to just define an environment variable in DOS called "LWPATH" and define the paths in there. This has the advantage that LW.SYS will be loaded from the folder too. Note, don't use SDX type drive identifiers: the syntax is exactly the same as in LW.SYS.

 

And... you can specify a path on the SDX command line if you want to override the others.

Edited December 24, 2009 by flashjazzcat

[+Stephen]

On my way out now (spent too long messing around: see "vertical lines" topic), but yes, you can have everything in subdirectories. Just edit LW.SYS and put a list of semi-colon separated paths after the "PATH" command, thus:

 

PATH D8:;D1:>LW>

 

This will cause LW to search the RAMdisk, then D1:>LW> when you try to load a font or macro, etc, by typing the name directly at the load prompt. You don't have to use more than one path, of course:

 

PATH D1:>LASTWORD>

 

will just search the LASTWORD folder on drive one. IIRC, the default drive (i.e. the drive catalogued on the disk menu) is always searched regardless of what you put in the path, but don't quote me on that since I forget for the moment!

 

Sadly the file selector doesn't automatically list the folder(s) in the PATH variable. This would have been nice but attempts to implement it introduced more problems than they solved.

 

However... if you're using SpartaDOS X, it's easier to just define an environment variable in DOS called "LWPATH" and define the paths in there. This has the advantage that LW.SYS will be loaded from the folder too. Note, don't use SDX type drive identifiers: the syntax is exactly the same as in LW.SYS.

 

And... you can specify a path on the SDX command line if you want to override the others.

Thanks - been reading through the manual as well as the SDX manual, but it's a ton of reading. Thanks for the LWPATH variable - I do recall skimming that part.

 

Stephen Anderson

[flashjazzcat]

I'm still thinking about the file selector issue. I was considering doing away with CHDIR commands altogether and keeping nine path buffers, one for each drive. Then the likes of the load macro and font commands could call the file selector and pass it the "LW" pathname without screwing up which ever folder that drive was set to the last time you loaded a document. Of course, the first obstacle was finding somewhere to put the path buffers. There are other was of tackling it, but they make the program rather DOS-specific, which I wanted to try and avoid. Not sure if I'll manage to get anywhere with this with the 3.11 update, but I think the VBXE version will free up space for refinements like these.

Edited December 25, 2009 by flashjazzcat

[+Stephen]

While you are considering upgrades, is there a way (even if by macro) to automatically link load a file in one step? The largest file I have messed with so far was about 36Kb which took 3 banks. But loading it took a while as it had to scan the entire 36Kb file 3 times. I would have to try that on a 160Kb file!

 

Stephen Anderson

[flashjazzcat]

While you are considering upgrades, is there a way (even if by macro) to automatically link load a file in one step? The largest file I have messed with so far was about 36Kb which took 3 banks. But loading it took a while as it had to scan the entire 36Kb file 3 times. I would have to try that on a 160Kb file!

The Linked Load feature - while fairly well tested - isn't something I've used that much myself. If a segment "overflows" the buffer, it will cause a running macro to branch to the conditional macro (assuming one was preselected with Select+Ctrl+B before the load command was issued). As for scanning the entire file: the program keeps a note of the file pointer after each segment is loaded, so I'm puzzled as to why the program appeared to be scanning the entire file. One possibility is that you were reading a DOS 2.x file under SpartaDOS. IIRC, SDX implements file pointer seeks by scanning through the whole file when the disk isn't using the native file structure.

Edited December 25, 2009 by flashjazzcat

[+Stephen]

While you are considering upgrades, is there a way (even if by macro) to automatically link load a file in one step? The largest file I have messed with so far was about 36Kb which took 3 banks. But loading it took a while as it had to scan the entire 36Kb file 3 times. I would have to try that on a 160Kb file!

The Linked Load feature - while fairly well tested - isn't something I've used that much myself. If a segment "overflows" the buffer, it will cause a running macro to branch to the conditional macro (assuming one was preselected with Select+Ctrl+B before the load command was issued). As for scanning the entire file: the program keeps a note of the file pointer after each segment is loaded, so I'm puzzled as to why the program appeared to be scanning the entire file. One possibility is that you were reading a DOS 2.x file under SpartaDOS. IIRC, SDX implements file pointer seeks by scanning through the whole file when the disk isn't using the native file structure.

Thanks, that was exactly the reason. I was loading a DOS 2.0 file under Sparta X. It shouldn't be too much longer and I will have Sparta X images for all of my common utility disks.

 

Stephen Anderson

[flashjazzcat]

Whoa... finally got a stable VBXE2 machine (with 1 meg RAM), SIO2PC, Aspeqt and Altirra with VBXE emulation. It's like a cosmic alignment... plus free time on my hands. If I get cracking this week, we could see a prototype of the first VBXE word processor...

[flashjazzcat]

It's gradually taking shape:

 

 

Slow progress, though. The code rewrites are more extensive than I'd expected.

[+Stephen]

It's gradually taking shape:

 

 

Slow progress, though. The code rewrites are more extensive than I'd expected.

Take your time - I don't have my VBXE yet It's in limbo at the moment (either on a boat somewhere or stuck in customs). I'll let you know when I receive it. I'll be glad to assist you in testing.

 

Stephen Anderson

[flashjazzcat]

Thanks!

 

By the way - if anyone has need of a non-shadow RAM version of LW, let me know and if there's sufficient demand I'd consider producing a cart-based version or some such. Actually quite like the idea of putting the WP on a cart, although the immediate drawback is not being able to use it with AtariMax based SDX versions owing to the lack of a pass-thru. Would be fine with INTSDX and modified/original SDX carts, though.

 

The VBXE version might actually fit entirely into conventional RAM, which would presumably solve a lot of problems.

 

...hmmm. Not much hope of getting it working this evening. Will have to use MEMACA window because LW leaves the extended RAM mapped in and this will override VBXE's bank-switching.

Edited January 12, 2010 by flashjazzcat

[flashjazzcat]

Some small bugs still to be ironed out...

 

 

Ahem. Not sure what's happened here but at least something is happening. Hardware and emulation are still poles apart as far as crash symptoms go (this is on real hardware).

Edited January 12, 2010 by flashjazzcat

[+Stephen]

Hey - at least you got some color in the intro screen

 

Stephen Anderson

[phaeron]

Some small bugs still to be ironed out...

 

 

Ahem. Not sure what's happened here but at least something is happening. Hardware and emulation are still poles apart as far as crash symptoms go (this is on real hardware).

 

There is always room for improvement.

 

You might want to check if you've accidentally triggered a hires mode swap or priority change in the attribute map -- neither of those are supported by Altirra at the moment.

[flashjazzcat]

There is always room for improvement.

 

You might want to check if you've accidentally triggered a hires mode swap or priority change in the attribute map -- neither of those are supported by Altirra at the moment.

Yes, I think I can tweak this display a little.

 

This was basically the first run after the first successful (i.e. no missing labels) complile, so no wonder it's rough! Thanks for the suggestions, though.

[+Roydea6]

Hi Jon,

I just now tried The Last Word 3.1 with XBW130.DOS a Spartdos look alike. I think it should run under this dos because it doesn't use the shadow ram. Turbobasic 1.5 works okay with this dos. And this dos is also MyIDE ready, with large file directories. Could you explain or look for a quick fix.

 

 

BW130A.ATR

 

TIA

Edited January 25, 2010 by rdea6

[flashjazzcat]

Hi Jon,

I just now tried The Last Word 3.1 with XBW130.DOS a Spartdos look alike. I think it should run under this dos because it doesn't use the shadow ram. Turbobasic 1.5 works okay with this dos. And this dos is also MyIDE ready, with large file directories. Could you explain or look for a quick fix.

 

 

BW130A.ATR

 

TIA

I just mounted the ATR under Atari800Win and booted from it, then mounted LW31.ATR but this DOS won't even recognize the disk. Is it supposed to be DOS 2.x compatible?

Edited January 26, 2010 by flashjazzcat

[+bf2k+]

Hi Jon,

I just now tried The Last Word 3.1 with XBW130.DOS a Spartdos look alike. I think it should run under this dos because it doesn't use the shadow ram. Turbobasic 1.5 works okay with this dos. And this dos is also MyIDE ready, with large file directories. Could you explain or look for a quick fix.

 

 

BW130A.ATR

 

TIA

I just mounted the ATR under Atari800Win and booted from it, then mounted LW31.ATR but this DOS won't even recognize the disk. Is it supposed to be DOS 2.x compatible?

 

Try LW31 on a SpartaDOS disk.

[flashjazzcat]

Thanks. I just copied the EXE from H: to the boot disk and I get "Not compatible with disk SpartaDOS". XBW130.DOS appears to have the same DOS ID bytes at $700/$701 as SpartaDOS 3.2. LW 3.x won't even try to launch under disk based SpartaDOS (although version 2.1 on my website should work fine). The first job is to either get the authors of XBW to put proper DOS ID bytes in page seven, or to establish how an updated version of LW 3.1 (and there'll be one on the way soon, so now is the time) can reliably tell the difference between XBW DOS and Sparta 3.x. I'll quite happily build detection code into the program, but I need to be told what bytes to look for. I can understand the reasoning behind leaving "S" at $700 to tell apps that the system is Sparta compatible, but the version number at $701 really ought to be different: it's misleading for the application in this instance.

 

EDIT: OK, thought up a simple solution and used the Atari800Win monitor to put $40 at $701. LW then loads (thinking it's running under SDX), but crashes at the end of the loading process. Tried loading LW with its keyboard buffer disabled, but no luck yet. Will keep looking into it.

Edited January 26, 2010 by flashjazzcat

[cyco130]

how (...) LW 3.1 (...) can reliably tell the difference between XBW DOS and Sparta 3.x.

 

Hi,

 

The following is from the BW-DOS manual here.

 

 

$700: There is allways the character "S" to provide the best compatibility with SpartaDOS. Many programs

will determine by this adress, if they can use advanced SpartaDOS (BW-DOS) functions.

$701: There is allways the number $32 to provide the best compatibility with SpartaDOS.

$703 (two bytes): There are the letters "BW" when any version of BW-DOS is installed.

$705: BW-DOS version. $10 is for version 1.0x, $13 is for version 1.3x etc.

$706 (two bytes): Adress of the "GETTD" routine. This routine reads the date and time from BW-DOS's

clock, and store it into "DATER" and "TIMER" in the "COMTAB".

$708 (two bytes): Adress of the "SETTD" routine. This routine reads the date and time from "DATER" and

"TIMER" in the "COMTAB", and store it into BW-DOS's clock.

$70A (two bytes): Adress of "CONVDC" routine. This routine will convert a 24-bit binary number from

"DECIN" in the "COMTAB" to the 8 characters long ASCII text in the "DECOUT".

$70C (three bytes): There is an instruction, which jumps to the SIO routine defined by "LSIO" in the

"COMTAB". (This is provided for compatibility with BiboDOS.) Any changes done to this adress may not

change function of BW-DOS.

 

I think it's always a good idea to support BW-DOS. It's my favourite DOS when using emulators because it's slim, it uses the OS SIO routines that enables me to use the emulator's SIO patch and works with H: devices without problem. I've also heard SD 3.x has many bugs that BW-DOS doesn't have but I can't comment on this...

[flashjazzcat]

Thanks for the info. From what you say, it does indeed seem a good DOS and well worth supporting. The slow PRINTF routine when doing a DIR list reminds me of the early SpartaDOS versions, but the pros outweigh the cons here: the fact it works with MyIDE is a grand recommendation. Shame it's not open source like MyDOS - wouldn't mind tweaking it a bit.

 

The page 7 table can easily be handled by LW: the problem remains the inexplicable crashing after the title screen. Will work on this. If anyone can trace the cause of the crash before I do, a gold star will be yours!