The Last Word 3.21 Released

[flashjazzcat]

Download here:

 

The Last Word 3.21

 

See SPELL.TXT and Chapter 7 of the manual for an explanation of the spelling checker.

 

I will add MyDOS and BeweDOS based distributions later on.

Edited November 28, 2010 by flashjazzcat

[+Roydea6]

OK spell checker loads and seems to work, BUT it didn't AUTOSKIP words that were in the DCT files. So I re-read the Doc's and decided to delete all my DCT FILES as suggested in the doc's and started with a new spell check on a file I made with all words starting with A that I could do quick and easy (about 20 words). I then re-ran Spell.EXT on the file and ADDED all twenty words. Verified my LWA.DCT file. reloaded the testfile of all 'A' words and ran Spell.EXT again and it wanted me to ADD,SKIP,CHANGE, OR QUIT. on all the files again.

 

On a side note I and A-a's are always found.

 

SDX pathing works now that I figured it out.

 

SDX and LW321 kicks ass. Thank you.

[flashjazzcat]

I wouldn't be surprised if there's a bug or two in the spell-checker, but the beauty of it is that I can fix the extension without touching the main program. That said, I have a nice working spell-checker setup here. Just be sure that the target folder for the spell-checker files is the LAST entry in the LW path, otherwise your new dictionary files will end up being created in the wrong place. Also ensure, naturally, that the dictionary folder itself is referenced in the PATH in the first place (and this is the LW path - nothing to do with SDX's PATH).

 

I'll give things another test later.

[flashjazzcat]

Spell-checker doesn't work on anything but my hard disk. Can't track the problem down at the moment, so I've withdrawn the download for now.

[flashjazzcat]

Found the bug: spell checker only works with SpartaDOS X if you have "DEVICE ENV" at the top of CONFIG.SYS. I have no idea why yet...

[+Roydea6]

Found the bug: spell checker only works with SpartaDOS X if you have "DEVICE ENV" at the top of CONFIG.SYS. I have no idea why yet...

Thanks for info... I'll put DEVICE ENV in my config.sys..

[flashjazzcat]

OK: we're good to go. Get version 3.21 here. If you downloaded before today, delete that copy and download again.

 

The reason having ENV.SYS installed worked for me was simply that it altered the banking list (since ENV.SYS reserves an entire bank of extended RAM), and thus happened to cause the correct value to be in the accumulator after the spelling checker switched in the dictionary bank. And LDX #0 instead of the required LDA #0 in the spelling checker code meant that only in these circumstances would the spell checker work.

 

At least it was a simple fix (although it had me foxed for a few hours), and I'm relieved all the bugs were confined to SPELL.EXT.

 

If you just want the corrected SPELL.EXT, download here:

 

spell.zip

 

Enjoy.

Edited December 1, 2010 by flashjazzcat

[flashjazzcat]

Hmmm... bad time of year, I guess.

 

I was toying with the idea of pressing on with a cartridge version of LW, but right now I'd be unable to use it with a hard disk, so it would be useless to me. I've been analysing the segment map for LW 3.21 (44 segments, many of which load over the top of one another and get jettisoned or moved elsewhere, and some of which load into areas later used as buffer space), and it's so complicated it would probably take me a couple of years to make it occupy main memory or run from extended banks, etc. The neatest solution (to my mind) is to forget about SpartaDOS 3.x compatibility (which anyway introduces a whole sh... erm, boatload of compatibility issues I left behind two years ago), and - when assuming the presence of extended RAM for buffers (which the next version will) - keep on using the Shadow RAM, and then stuff another 16KB of code under the text buffer window at $4000-$7FFF. That gives me 54K to play with, without worrying about overlays or complex banking schemes (providing I just keep code which accesses the text buffer outside of the banked region, of course).

 

With all the throw-away bits and the loading screen, the executable could well top 60KB eventually. I guess it might do something to boost hard disk sales...

 

Of course, when my system's more cartridge friendly, I might have a rethink.

[MEtalGuy66]

Its useless to me as a text editor without compatability with disk based versions of SpartaDOS..

 

I like SpartaDOS X, but it's not a universal solution. I have to have the flexibility of a command line DOS, but I like to boot a specific DOS from a disk, based on what I'm doing with that disk, and what's stored on it.

 

And if I write any formal papers, Im doing it in MS WORD on the PC.. So a cart based, or MyDOS/DOS 2 based version basically amounts to a nice demo program to show people that the ATARI is capable of a fast 80-column editor.

 

Have you considered making a stripped down version of it that runs as a standalone .COM file without all the support files, extra fonts, macro features, etc. etc.?

Just a fast 80 column editor with good keyboard controls, cut/paste, and file management would be great.

[flashjazzcat]

I think it's debatable which is the most intrusive: a DOS which sits in the shadow RAM, or an app. Turbo Basic has got to be one of the best (free) languages written for the Atari back in the day, and it was totally incompatible with SD 3.x...

 

But that's moot, anyway. The aim is to be as compatible and flexible as possible. Just because I see SDX as the answer to everything, doesn't mean everyone else has to (although - frankly - when you get into SDX system programming, one starts to wish that SDX had been built into every Atari as it left the factory).

 

Running code out of the extended banks is possible, but it's more complex than simply assuming the code is all present somewhere within main memory. We have to use banking techniques similar to those used in cart banking, and at that stage, one might as well write a cart. Unfortunately, I need an IDE interface with a cartridge pass-through before I can think of doing that. Seriously: if I could actually use the thing every day, I'd probably have started a cart version already.

 

Speaking of the standalone, strippped-down version: that's also planned. I'm working on the UI library right now (as used in the MyIDE FDISK), which will ultimately be merged with the business-end code of LW to form a very smart little text editor that will run entirely in conventional memory. There'll be an SDX-only version (loading the UI library as a DLL), but there'll also be a generalized version. It will be capable of editing contiguous 48K blocks of text if you have enough RAM.

Edited December 9, 2010 by flashjazzcat

[MEtalGuy66]

SDX is a damn nice OS.. But it's not "the solution for everything" on the ATARI.. And this type of viewpoint where your coding is concerned is going to severely limit the usefulness of your programs to the community as a whole. There are ALOT of really kewl custom hardware and firmware based products for the ATARI. I have a huge list of them that I like to use for specific applications. SDX is an awesome solution for a limited number of applications. There is a TON of stuff that will not run with it. The BBS Sysop guys (for example) love it, because it will be used on a machine that is alwayse used for the same thing. Therefore, as long as the apps being run as part of a BBS system like it, who cares whether or not you can boot Racing Destruction Set with it. The cart will stay inserted at all times, and it provides a very powerful OS, available instantly from ROM, leaving max RAM resources free for the BBS applications. In the event of an unattended reboot, the OS is guaranteed to come up.. and damn quick. I personally dont like plugging and unplugging carts all the time, because of the wear & tear on the cart connectors. I might consider a switched internal installation of SDX, for my own personal preferences, but its not realistic to expect all atari users to do so. There are quite a few people who religeously leave their machines comlpletely stock and/or have a purposely limited budget, and aren't interested in anything that wont load via SIO2PC, or from a standard floppy. OSS and ICD made ALOT of great stuff that offers a ton of support for disk based versions of Sparta.. MAC/65 & DDT running under SD3.2x has classicly been the dev. environment choice of a whole lot of people who have written alot of great stuff. Wouldve been great if there was a good 80 column editor to round out the package. Is SDX a superior OS? Of course it is.. I would even go as far as saying it's one of the most advanced OSes ever made for a specific 8-bit microcomputer platform. Does it offer extended capabilities to those who choose to buy/use additional hardware? You bet.. Does everyone fall into this group? Not by a long shot.

 

I really like separate ANTIC/CPU access on the 130xe.. But I wouldnt write a graphics utility that will not run without it. I really like the features present in quite a few custom OS roms, but I wouldnt write a program that depends on their presence to run.

 

What I'm trying to say is that you have done something that noone has ever done on the ATARI before. Your application is awesome by ATARI standards.. It's what we all wished we had back in the HeyDay, and alwayse knew the machine was truly capable of. In development of this app, you are doing a great service to the ATARI community. It would be a shame to cripple it's usefulness (range of application) in the same way that the authors of TurboBASIC did.

Edited December 9, 2010 by MEtalGuy66

[flashjazzcat]

SDX is a damn nice OS.. But it's not "the solution for everything" on the ATARI.. And this type of viewpoint where your coding is concerned is going to severely limit the usefulness of your programs to the community as a whole. There are ALOT of really kewl custom hardware and firmware based products for the ATARI. I have a huge list of them that I like to use for specific applications. SDX is an awesome solution for a limited number of applications. There is a TON of stuff that will not run with it. The BBS Sysop guys (for example) love it, because it will be used on a machine that is alwayse used for the same thing. Therefore, as long as the apps being run as part of a BBS system like it, who cares whether or not you can boot Racing Destruction Set with it. The cart will stay inserted at all times, and it provides a very powerful OS, available instantly from ROM, leaving max RAM resources free for the BBS applications. In the event of an unattended reboot, the OS is guaranteed to come up.. and damn quick. I personally dont like plugging and unplugging carts all the time, because of the wear & tear on the cart connectors. I might consider a switched internal installation of SDX, for my own personal preferences, but its not realistic to expect all atari users to do so. There are quite a few people who religeously leave their machines comlpletely stock and/or have a purposely limited budget, and aren't interested in anything that wont load via SIO2PC, or from a standard floppy. OSS and ICD made ALOT of great stuff that offers a ton of support for disk based versions of Sparta.. Is SDX a superior OS? Of course it is.. I would even go as far as saying it's one of the most advanced OSes ever made for a specific 8-bit microcomputer platform. Does it offer extended capabilities to those who choose to buy/use additional hardware? You bet.. Does everyone fall into this group? Not by a long shot.

 

I really like separate ANTIC/CPU access on the 130xe.. But I wouldnt write a graphics utility that will not run without it. I really like the features present in quite a few custom OS roms, but I wouldnt write a program that depends on their presence to run.

 

What I'm trying to say is that you have done something that noone has ever done on the ATARI before. Your application is awesome by ATARI standards.. It's what we all wished we had back in the HeyDay, and alwayse knew the machine was truly capable of. In development of this app, you are doing a great service to the ATARI community. It would be a shame to cripple it's usefulness (range of application) in the same way that the authors of TurboBASIC did.

Well... erm, I can't really disagree with any of that. I think my commitment to diversity is already made apparent by the fact that the word processor in its existing form provides specific support to four different disk operating systems (DOS 2.5 + variants, MyDOS, BeweDOS, and SpartaDOS X). I know the fact LW started using RAM under the OS as of version 3.0 caused some disgruntlement. It's certainly not my intention to limit my user-base; I simply lacked the time, knowledge, and incentive to do things a different way back then (by lack of incentive, I mean I had no idea that the program would take off in quite the way it did, and I thank you for the kind evaluation, by the way!).

 

I imagine every hardware/software developer is keenly aware of how difficult it is to keep every user and every machine happy. SpartaDOS 3.x support alone will probably consume a few A4 pages of notes and pseudo code and many hours of testing. Of course, this is half the fun (and I must admit, I miss being able to re-enter the WP from the DOS prompt with "RUN" in SD 3.x as was possible in LW 2.1).

 

One of my reasons for wanting to keep on using the Shadow RAM in the short term was just to keep the development incremental. Converting a 44 segment, 20,000 line, 35K binary which sits in main and shadow RAM into a banked cartridge or something which runs out of extended banks while also keeping the data in extended RAM is not something to be approached lightly. I have so many things I want to do with this program that my intention is to get things (most urgently the large text buffers) working with the existing code layout, and then decide the most flexible way of presenting the code.

 

But the argument of variance could be taken to the Nth degree: the program is now so big it must break out of the 64K limit, so that immediately shuts out users without extended RAM. If we put the program on a cartridge, that shuts out users of SpartaDOS X who don't have original pass-thru carts or internally mounted SDX boards. The cartridge format also leaves behind many MyIDE users, or XE users using PBI devices which don't have a cart pass-thru.

 

So really there's no really hard and fast way to proceed. You're clearly a fan of the cartridge approach. Now that my IDEa interface is working, so am I. But that's not to say there won't be a compelling reason for doing it some different way.

 

In any case, I want to get this finalized before I start. I have the MyIDE driver, UI library, and text editor to keep myself busy into the New Year. As for The Last Word, I guess source code tailored for running out of extended RAM will be pretty closely related to what's required to run out of a banked cartridge. So I can hedge my bets a little. To be clear - I'm as keen as you are to get the code out from under the OS. The reason I bring up the topic is to get feedback which will help me make the right decision first time around.

Edited December 9, 2010 by flashjazzcat

[MEtalGuy66]

Well, for a task-specific stand alone "Word Processor" that's made to encompass all the roles/requirements of formal writing, and includes all the necessary embellishments, its not a big deal to run it from a standalone disk, or cart.. The user can just save his/her work to a disk made under an OS that the program does support.

 

My point of view is that I hope you'll at least consider making the smaller, more utilitarian "text editor" compatable with OSes that use the RAM under the OS..

Edited December 9, 2010 by MEtalGuy66

[+bf2k+]

The BBS Sysop guys (for example) love it, because it will be used on a machine that is alwayse used for the same thing. Therefore, as long as the apps being run as part of a BBS system like it, who cares whether or not you can boot Racing Destruction Set with it.

 

Actually... none of the BBS programs I have messed with will run under SDX. Are there any around that do?

[flashjazzcat]

My point of view is that I hope you'll at least consider making the smaller, more utilitarian "text editor" compatable with OSes that use the RAM under the OS..

Certainly. In fact that's the project I'm planning right now.

[+wood_jl]

For less-technical dumb-asses <raising hand here> can someone please restate - in simple language - what is the complaint/incompatibility here? Last Word requires SDX? Won't work with what? I just want to make sure I'm understanding this correctly. Due to the fact that my intelligence is clearly less than that of flashjazzcat and metalguy66, can someone please describe this situation in baby-talk for me?

[flashjazzcat]

For less-technical dumb-asses <raising hand here> can someone please restate - in simple language - what is the complaint/incompatibility here? Last Word requires SDX? Won't work with what? I just want to make sure I'm understanding this correctly. Due to the fact that my intelligence is clearly less than that of flashjazzcat and metalguy66, can someone please describe this situation in baby-talk for me?

OK. When I originally wrote The Last Word in 1999 it was compatible with just about every available DOS (this was the case up to version 2.1). The main reason for this - and the main issue we're discussing here - is that it only used conventional application memory (i.e. between MEMLO and MEMTOP, just below the display memory), and - optionally - extended RAM if you had it.

 

The current versions of The Last Word use RAM under the operating system. That's a 14KB block available only on the XL/XE computers ($C000-$D800 and $E000-$FFF9). Disk operating systems which use the same area of memory include:

 

Disk-based SpartaDOS (usually version 3.x)

RealDOS

DOS XE

 

So The Last Word 3.0 and up is NOT compatible with these DOSes.

 

The Last Word does NOT require SpartaDOS X. However, it has many features designed to take advantage of SDX if that's what you happen to be using. SDX can be configured to use the RAM under the OS (in which case it wouldn't work with LW), but most commonly, SDX uses extended RAM.

 

The Last Word currently works with SDX, DOS 2.5 and variants, MyDOS, and BeweDOS. It also works on a 64K XL/XE machine (unless you're using SpartaDOS X), since the use of extended memory (although recommended) is optional.

 

The Last Word has reached the point where the next version will require more memory than is available under the operating system. The decision is now whether to keep it disk-based and oblige the use of a 128K+ Atari, or put the program on a cartridge. I've gone into some detail above about the pros and cons of both approaches.

 

A number of people who'd like to use The Last Word with an advanced DOS happen to prefer SpartaDOS 3.x or RealDOS to SpartaDOS X. A nice compromise for coders, etc, would be a text-editor version which works in 80 columns, but doesn't use any RAM under the OS.

Edited December 10, 2010 by flashjazzcat

[MEtalGuy66]

A number of people who'd like to use The Last Word with an advanced DOS happen to prefer SpartaDOS 3.x or RealDOS to SpartaDOS X. A nice compromise for coders, etc, would be a text-editor version which works in 80 columns, but doesn't use any RAM under the OS.

 

Actually, many people PREFER the functionality of SDX, but the reality is that SDX is not suitable for everything. In fact, theres quite a bit of stuff out there that SDX does not work with. I wish SDX was in fact the "universal solution" for everyhting you'd ever want to do on an ATARI.

[flashjazzcat]

Actually, many people PREFER the functionality of SDX, but the reality is that SDX is not suitable for everything. In fact, theres quite a bit of stuff out there that SDX does not work with. I wish SDX was in fact the "universal solution" for everyhting you'd ever want to do on an ATARI.

In that case, we need a lot of new, SDX compatible apps. Give me a list.

[MEtalGuy66]

You can't single handedly rewrite everything that has ever been worth running on the ATARI to make it work with SDX. Your talking about 30 years worth of software. Even if what you write is hands down better than previous apps of that type (and the Last Word certainly is,) you can't act like people are willing to just forget about previous software and not care to run it. You have to remember that if anyone was only interested in running the best/greatest/most functional software, they'd be using a modern platform rather than the ATARI. Like it or not, there is 30 years of pre-existing standards.. Part of being a truly GOOD developer is to realize the bases of compatability that have been established based on these standards, and do your best to make your stuff "play nice" with them.

Edited December 10, 2010 by MEtalGuy66

[flashjazzcat]

You can't single handedly rewrite everything that has ever been worth running on the ATARI to make it work with SDX. Your talking about 30 years worth of software. Even if what you write is hands down better than previous apps of that type (and the Last Word certainly is,) you can't act like people are willing to just forget about previous software and not care to run it. You have to remember that if anyone was only interested in running the best/greatest/most functional software, they'd be using a modern platform rather than the ATARI. Like it or not, there is 30 years of pre-existing standards.. Part of being a truly GOOD developer is to realize the bases of compatability that have been established based on these standards, and do your best to make your stuff "play nice" with them.

Sorry - I mustn't have expressed my humour properly. It was a joke...

[kurtm]

Sorry - I mustn't have expressed my humour properly. It was a joke...

 

I saw the big smiley.

 

Maybe considering what you've done for the 8bit SW scene lately, he assumed you were only partly kidding...

 

--Kurt

[+wood_jl]

OK. When I originally wrote The Last Word in 1999 it was compatible with just about every available DOS (this was the case up to version 2.1). The main reason for this - and the main issue we're discussing here - is that it only used conventional application memory (i.e. between MEMLO and MEMTOP, just below the display memory), and - optionally - extended RAM if you had it.

 

The current versions of The Last Word use RAM under the operating system. That's a 14KB block available only on the XL/XE computers ($C000-$D800 and $E000-$FFF9). Disk operating systems which use the same area of memory include:

 

Disk-based SpartaDOS (usually version 3.x)

RealDOS

DOS XE

 

So The Last Word 3.0 and up is NOT compatible with these DOSes.

 

Gotcha. So obviously, 400/800 won't work (with any DOS) because it lacks this 14K, eh?

 

The Last Word does NOT require SpartaDOS X. However, it has many features designed to take advantage of SDX if that's what you happen to be using. SDX can be configured to use the RAM under the OS (in which case it wouldn't work with LW), but most commonly, SDX uses extended RAM.

 

The Last Word currently works with SDX, DOS 2.5 and variants, MyDOS, and BeweDOS. It also works on a 64K XL/XE machine (unless you're using SpartaDOS X), since the use of extended memory (although recommended) is optional.

 

That means what you say above, you must configure SDX not to use the 14K? Then it will work on a 64K XL/XE? (I've never even seen SDX)

 

The Last Word has reached the point where the next version will require more memory than is available under the operating system. The decision is now whether to keep it disk-based and oblige the use of a 128K+ Atari, or put the program on a cartridge. I've gone into some detail above about the pros and cons of both approaches.

 

A number of people who'd like to use The Last Word with an advanced DOS happen to prefer SpartaDOS 3.x or RealDOS to SpartaDOS X. A nice compromise for coders, etc, would be a text-editor version which works in 80 columns, but doesn't use any RAM under the OS.

 

So you can make a disk-based version which requires a 130XE (or above) that will work with any DOS? This would be cool. This would require lots of fancy bank switching?

 

I just think the cart is going to be hard to distribute. What about an Atarimax cart version in a file?

 

Thanks for breaking this down for me. Do people make SDX carts out of Atarimax carts?

Edited December 12, 2010 by wood_jl

[BillC]

 

snip

Do people make SDX carts out of Atarimax carts?

ATR disk images for flashing SpartaDOS X onto Atarimax 1Mb and 8Mb cartridges, and several other flash cartridges, are available at the following url: http://trub.atari8.info/index.php?ref=sdx_upgrade_en

 

Bill

[flashjazzcat]

So obviously, 400/800 won't work (with any DOS) because it lacks this 14K, eh?

Correct. I don't think version 2.1 will work on an 800 either, since it references the XL/XE OS keyboard table.

 

That means what you say above, you must configure SDX not to use the 14K? Then it will work on a 64K XL/XE?

Exactly so.

 

So you can make a disk-based version which requires a 130XE (or above) that will work with any DOS? This would be cool. This would require lots of fancy bank switching?

I can. It would clearly be most efficient when using a hard disk, since the executable would be 50-60K in size. As for the bank switching, code and data would both live in extended RAM banks, performing indirect access on data via routines in conventional memory.

 

I just think the cart is going to be hard to distribute. What about an Atarimax cart version in a file?

No so much hard to distribute, since we can produce bootable ATRs which automatically flash AtariMax or other programmable cartridges. The problem is that the end user needs a programmable cartridge, and if they want to use an AtariMax SDX cart or MyIDE with LW also on a cart, they're totally stuffed. SDX users represent a significant proportion of the LW user base.

Edited December 12, 2010 by flashjazzcat