The Last Word 3.11 Public Beta

[MEtalGuy66]

Leave the damn icons as an "add-in" module.. Serious power users dont want that crap if it means added bloat, or waste of precious space that could be used for useful features or additional buffer..

And the ATARI is not a "GUI" based system, to begin with... Its not like theres any standard for menu icons.. They are really "out of place" when compared to any other serious apps you might be using on the atari..

[flashjazzcat]

Leave the damn icons as an "add-in" module.. Serious power users dont want that crap if it means added bloat, or waste of precious space that could be used for useful features or additional buffer..

And the ATARI is not a "GUI" based system, to begin with... Its not like theres any standard for menu icons.. They are really "out of place" when compared to any other serious apps you might be using on the atari..

You make a good point: it's a more vehement expression of my own thinking as I watched 800 bytes vanish into thin air...

 

The reclaimed RAM has already been used to:

 

• Enlarge the main text buffer
• Allow for proper shortening of long path names (i.e. "D:\LASTWORD\MANUALS\DRAFTS\LASTWORD.TXT" can be displayed as "D:\LASTWORD\MANU...FTS\LASTWORD.TXT" in the appropriate context)

[flashjazzcat]

Quick question regarding emulators: I'm thinking of checking for the H: device when reading directories in the disk menu and switching back to Atari DOS style directory listings if a hard disk read is attempted. This will ensure that "Command not implemented" errors won't occur through trying to read "H:" while in SpartaDOS "RAW" mode. Does this seem a sensible change? The next time "Dn:" is read, the prevailing directory style will be used.

Edited May 24, 2010 by flashjazzcat

[Mr.Amiga500]

Leave the damn icons as an "add-in" module.. Serious power users dont want that crap if it means added bloat, or waste of precious space that could be used for useful features or additional buffer..

And the ATARI is not a "GUI" based system, to begin with... Its not like theres any standard for menu icons.. They are really "out of place" when compared to any other serious apps you might be using on the atari..

 

Give me a friggin break. "Serious power users" wouldn't use a damn Atari 8-bit in the first place. And yes, I DO know Atari is not a "GUI" based system to begin with. I like the icons and don't give a shit if they're "out of place" compared to other Atari applications. It takes 800 bytes - hardly much "added bloat or waste". Adding more features that nobody will use is what I consider bloat.

 

You really need to cut back on caffeine.

[Roydea6]

Hmmm... don't forget to re-read the directory having set sort to "None". It should then come up in disk order. It's working fine in my 3.11 beta 3 copy. Perhaps Sort->None should force an automatic re-read of the folder???

Yes it does work after a disk refresh. I had not thought to do that because the other SORT options cause a refresh. Sort>None is fine the way it is without a refresh, probably not used often.

 

IF you could also change (take out) the Beta startup screen in the current BETA 3.11v3 the icons would still be usable. Name it 3.11vI 'for icons'.

[JamesD]

Leave the damn icons as an "add-in" module.. Serious power users dont want that crap if it means added bloat, or waste of precious space that could be used for useful features or additional buffer..

And the ATARI is not a "GUI" based system, to begin with... Its not like theres any standard for menu icons.. They are really "out of place" when compared to any other serious apps you might be using on the atari..

Yes, us serious power users will be using an 8 bit Atari so don't you dare use icons!

[+MrFish]

The icons are great for those who want to use them, which will still be possible. However, the editor keystroke command listing is only 2 printed pages.

Edited May 25, 2010 by MrFish

[flashjazzcat]

Hmmm... don't forget to re-read the directory having set sort to "None". It should then come up in disk order. It's working fine in my 3.11 beta 3 copy. Perhaps Sort->None should force an automatic re-read of the folder???

Yes it does work after a disk refresh. I had not thought to do that because the other SORT options cause a refresh. Sort>None is fine the way it is without a refresh, probably not used often.

 

IF you could also change (take out) the Beta startup screen in the current BETA 3.11v3 the icons would still be usable. Name it 3.11vI 'for icons'.

The "refresh" you see after choosing one of the other file sort options is simply the screen updating with the re-sorted list. The disk catalogue isn't re-read because there's no need. However, the original disk order of the files is impossible to retrieve without re-reading the whole lot from disk: that's what the latest change does automatically.

 

This icon business is becoming a real bugbear. They look nice but I don't even think you need to be a "power user" to outgrow them pretty quickly. The situatuion with (unfinished and buggy) 3.11 Beta 3 is that the icons consumed space which was required by a lot of incomplete, new functions. The CTRL+7 command gives you a complete list of all the text files loaded in memory, along with word counts and file sizes, together with a total word count. There were also a lot of bug fixes, and they consumed additional memory. I could make the CTRL+7 command an add-in and make the icons permanent.

 

LW on a 64K machine allows the editing of only ONE file, the main buffer is 16K, you can't really use SpartaDOS X, the cut and paste buffer is 1K long, the macro buffer a paltry 256 bytes... LW is really a 128K app which can run in 64K.

[flashjazzcat]

OK: I think I can manage a 768 byte add-in buffer, so if I can get the icon add-in down to that size, we can run it (and other extensions) in 64K. That's with a 1 page macro buffer (same as the 3.11 beta 3), but I'm not aware of anyone worrying about macros anyway - least of all 64K users.

 

I'll actually supply the program with ICONMENU.EXT renamed to LW.EXT, so by default, the icons will appear on the <Esc> key and will function in exactly the same way as the icons in Beta 3. Once users - whether they're running 64K or 1088K - get sick of them and want to use the 768 bytes for extra buffer space or other add-ins (which you can chop and change during an editing session), they can just rename the file back and the icons will be banished forever.

 

Now - does that sound acceptable? And no-one answered my query about the H: device further up the page, by the way.

Edited May 25, 2010 by flashjazzcat

[MEtalGuy66]

Leave the damn icons as an "add-in" module.. Serious power users dont want that crap if it means added bloat, or waste of precious space that could be used for useful features or additional buffer..

And the ATARI is not a "GUI" based system, to begin with... Its not like theres any standard for menu icons.. They are really "out of place" when compared to any other serious apps you might be using on the atari..

 

Give me a friggin break. "Serious power users" wouldn't use a damn Atari 8-bit in the first place.

Speak for yourself.. I plan to use this app to edit source code.. And yeah there are still plenty of people who use their atari for real world tasks..

 

And yes, I DO know Atari is not a "GUI" based system to begin with. I like the icons and don't give a shit if they're "out of place" compared to other Atari applications. It takes 800 bytes - hardly much "added bloat or waste". Adding more features that nobody will use is what I consider bloat.

How do you know what features any one person will or wont use? In my oppinion, icons definitely have no useful purpose on this app, other than looking out of place and unprofessional..

You really need to cut back on caffeine.

You are probably right about that, but you need to quit taking such a defensive stance. I wasn't attacking you.. As I said before, I have plans to make serious use of this app, and I'd like to see it developed in the best possible manner to facilitate those who have similar interests.. If you like the icons, then by all means, use them.. All I said was make it modular so thatr I don't have to...

Edited May 25, 2010 by MEtalGuy66

[Mr.Amiga500]

You are probably right about that, but you need to quit taking such a defensive stance. I wasn't attacking you.. As I said before, I have plans to make serious use of this app, and I'd like to see it developed in the best possible manner to facilitate those who have similar interests.. If you like the icons, then by all means, use them.. All I said was make it modular so thatr I don't have to...

Well, you can see in the last three pages of this thread I keep going on about how I like the icons and I keep trying to convince him to keep them, then you come along and "piss on my parade" (...so to speak), saying to "leave the damn icons", calling it "crap" and "bloat" and implying I'm not a "serious power user". Your wording certainly seemed hostile to me.

 

In my oppinion, icons definitely have no useful purpose on this app, other than looking out of place and unprofessional..

 

That's your opinion. In my opinion, they make it look more professional. I don't know why you'd think they look out of place when they're not even visible unless you press escape.

 

I try to use the Atari for real world tasks too. I also like to demonstrate to kids & people who have never seen an old computer before what the old computers could do. If I show them the wordprocessor and tell them to press escape for the icons, they'll be able to figure out the features without me having to tell them, "OK, now press Control + [whatever]+ [whatever else]". (kids give up quickly when they can't easily figure something out)

 

I can understand not wanting icons in a wordprocessor/editor. I use microgolded on the Amiga and I removed the default icon bar and have text only. The icon bar on The Last Word is different though, because it is hidden and doesn't require clicking with a mouse.

 

Anyway, even arguing about this seems pretty pathetic when you think about it. We're arguing about wordprocessor on a 30-year-old computer which was designed mainly to play games. Using the words "professional" and "power user" is a bit of a joke.

 

Icons.... no icons... I've decided I don't really care. Whatever.

[flashjazzcat]

OK folks: the icons are going to be modular and dispensable. With 64K, the program will pay a macro buffer size penalty for having them, but extended memory machines won't have this issue. If you have a 130XE and up, you can pretend they don't exist.

 

As for "serious power users" not using the 8-bit in the first place, the statement is a misreading of MetalGuy's original remark: he meant "power user" in the sense that SpartaDOS X users are "power users" (and I believe that exact phrase was in one of the SDX manuals). Basically he meant an 8-bit power user - not someone who wants to transcode MPEG2 videos or write a Win32 app in Visual Studio. Just because you can't do these things with an 8-bit computer, doesn't mean you can't do some serious work which demands a capable text editor. LW is a "serious" application, and if we're going to dismiss the Atari as something which can't run "power" apps, then this whole project is a waste of time. Whether the icons look unprofessional or gimmicky is down to personal taste: I've already established that the application programmer cannot please all users. Making the icons dispensable with virtually no overhead is the ONLY way to settle this.

 

Regarding bloat: 800 bytes is a lot of RAM on the 8-bit. And when those 800 bytes store data which is never being used by someone who never uses icons, they're out and out waste. Apart from the icon shape data, I would struggle to find 256 bytes of code in The Last Word which are not commonly executed by all users on a fairly regular basis. The program in memory is about 26K in size: the rest of the 34K executable is jettisoned after use and what's left would be twenty per cent bigger if it hadn't been relentlessly optimised over a period of years. That's why I had second thoughts about throwing away 800 plus bytes on a feature aimed at beginners and casual users and which half the regular users were ambivalent about.

Edited May 25, 2010 by flashjazzcat

[MEtalGuy66]

Yeah.. Flashjazzcat makes alot of points better than I did..

 

One thing Ill add is that yeah, it is a 30 year old computer.. And this app is one that is better than any previous word processor ever written for the machine.. I am really looking forward to finally having a word processor that makes the best possible use of the ATARI's resources.. we alwayse knew it could be done..

 

Also, you mentioned releaseing a "stripped down editor" version at some future time.. Will that version be compatable with disk based versions of SpartaDOS?

Edited May 25, 2010 by MEtalGuy66

[flashjazzcat]

Also, you mentioned releaseing a "stripped down editor" version at some future time.. Will that version be compatable with disk based versions of SpartaDOS?

I think only the cart version of LW will be compatible with disk SpartaDOS, and this is mainly down to the 80 column mode. That said, I played with a version a while back which kept the program code under the text buffer at $4000-$7FFF. It's not a trivial job, but something I might revisit again. I think the most desirable feature of a text editor version would be larger text buffers (32K and up).

 

We're arguing about wordprocessor on a 30-year-old computer which was designed mainly to play games. Using the words "professional" and "power user" is a bit of a joke.

 

Icons.... no icons... I've decided I don't really care. Whatever.

If I thought that were the case, I'd throw all my Atari equipment in the trash right now. And don't forget who actually writes this application: your views and opinions have been listened to and have informed the design of the software.

[JamesD]

I can definitely see someone using Last Word to edit source code, but I would think a power user would have more than 64K RAM so I'm not sure the icons will be much of an issue as far as RAM goes.

 

For the programmers it might be a good idea to offer a program editor version which could have extra features that make sense for programming but not for word processing, and remove some features that are of no use for programming.

 

I do think some people see icons and the GUI as major contributors to the death of 8 bits so there may be some animosity over including them because of that. I can also see people that use it on a daily basis not needing them. However, it makes the application friendlier to people that may occasionally use it, which will probably be the majority of users given the recreational nature of much of the 8 bit crowed.

[flashjazzcat]

I definitely agree about the program text editor; the whole print formatter can be binned, then we can have stuff like expanding tabs, pair matching, line numbering, etc, etc. Definitely something I'll look into in the interim. Eventually the cart version will have two modes: text editor and word processor, and will of course work in VBXE 80 column mode where possible.

[MEtalGuy66]

a disk based version is much more useful to me thana cart version.

[flashjazzcat]

a disk based version is much more useful to me thana cart version.

There are two ways to proceed. The cart version is a given since many people prefer that medium and the massive code space will permit a huge amount of functionality. The other way to obtain space is to require a 128K and up machine. The version which keeps code under the buffer at $4000-$7FFF assumes the text is stored in banked RAM. This scheme actually nets an extra 2K of code space over keeping the bulk of the program under the OS ROM. It's a fairly appealing offshoot.

[MEtalGuy66]

a disk based version is much more useful to me thana cart version.

There are two ways to proceed. The cart version is a given since many people prefer that medium and the massive code space will permit a huge amount of functionality. The other way to obtain space is to require a 128K and up machine. The version which keeps code under the buffer at $4000-$7FFF assumes the text is stored in banked RAM. This scheme actually nets an extra 2K of code space over keeping the bulk of the program under the OS ROM. It's a fairly appealing offshoot.

 

YEah, from the standpoint of a quality word-processor, the cart does have its merits.. basically unlimited code space..

 

Maybe the "fully embellished word-processor" version should be cart based, and the "stripped down editor" version could be disk based.

[JamesD]

a disk based version is much more useful to me thana cart version.

There are two ways to proceed. The cart version is a given since many people prefer that medium and the massive code space will permit a huge amount of functionality. The other way to obtain space is to require a 128K and up machine. The version which keeps code under the buffer at $4000-$7FFF assumes the text is stored in banked RAM. This scheme actually nets an extra 2K of code space over keeping the bulk of the program under the OS ROM. It's a fairly appealing offshoot.

 

YEah, from the standpoint of a quality word-processor, the cart does have its merits.. basically unlimited code space..

 

Maybe the "fully embellished word-processor" version should be cart based, and the "stripped down editor" version could be disk based.

That's exactly what I was thinking. If you throw both in the same cart I don't see anything wrong with it, but the editor should have a disk based version.

[flashjazzcat]

I think the text editor version should also detect VBXE and use its 80 column mode if it's available. The difference is appreciable on my 1084ST monitor. If I could have built VBXE detection into the current "full fat" disk version, I would do, but then we get people wondering why it doesn't also have multi-coloured fonts, etc, etc...

 

Needless to say the 3.11 release is behind schedule while I ruminate and finish other stuff. It will be worth holding back for a week or two, though.

[flashjazzcat]

I'm considering replacing the DLIs in the program with PMGs to perform the colour changes at the foot of the screen. This is to get rid of the annoying flicker when using high baud rate SIO or (presumably) fast PIO file transfers. Good idea?

[Rybags]

Does the whole background flicker below a point or is it just one scanline?

 

If just one scanline then a Blank line might be the best idea.

 

And wouldn't using PMGs be a bit costly. Can't really use the spare bytes since you'd need them static for the entire display duration if your DLI's getting disrupted.

[flashjazzcat]

Does the whole background flicker below a point or is it just one scanline?

 

If just one scanline then a Blank line might be the best idea.

 

And wouldn't using PMGs be a bit costly. Can't really use the spare bytes since you'd need them static for the entire display duration if your DLI's getting disrupted.

SIO baud rates above a certain (admittedly high) threshold cause the entire status bar to flicker like crazy under SpartaDOS X, since that DOS turns off DLIs when SIO operations hit a certain speed. It would be nice to use the super high-speed SIO2SD baud rates with SDX.

 

I've considered the overhead of PMGs, but at least with double line resolution the buffer is only 1K and 384 bytes of that are unused and can be occupied by general purpose buffers. So that's a total overhead of 640 bytes plus the small amount of code required to run the PMGs (which will replace the DLI code).

 

Certainly frustrating to allocate even this small amount of RAM, but the more SIO2SDs I test, the more this crops up and with this being the "final" disk based edition of the software, I'm wondering how it will cope with SpeedDrive, etc., when those devices come on the scene. The program as it stands really needs a caveat about the higher baud rates. The other alternative is to ditch the colour change, but that will radically change (or ruin) the look of the program.

 

A conflicting factor is that the PMGs will have to be adjusted if the TD line is detected, since that shifts the whole display down by a few scanlines. And if TD line changes in the future, the code to detect it will fail... not sure which way to go with this, to be honest!

 

...and while I'm thinking aloud about this: LW already has to patch the DOS 2.5 and MyDOS RAMdisk handlers so they don't disable the DLIs during RAMdisk access. It takes a lot to keep that colour change steady during I/O. The old versions of the program used to shorted the DL during I/O (the status bar effectively disappeared). I'm wondering if I should go back to that...

Edited June 8, 2010 by flashjazzcat

[Rybags]

Isn't it just a status/menu type thing anyway?

 

How about just replace it temporarily with some kind of I/O meter thing when disk access occurs? Maybe something like Graphics 5, 2 pixels high. Fill it with the same colour that the background of the window was, then use another colour for the growing progress indicator.