The Last Word 4: Disk or Cart?

[flashjazzcat]

The Last Word 4.0 is in the pipeline. The program will offer multi-level undo/redo, larger text buffers, menus, scripted macro language, text editor mode, VBXE support, and more. The program can either be a larger executable which requires at least 128K, or a MaxFlash cartridge image. In either case, the program will use no memory under the OS. A cartridge version would probably be usable on a 64K machine. However, how limiting is a cartridge edition? That means non-flash MyIDE carts out of the window, non-piggyback SDX can't be used (unless you use IntSDX), and any cartridge slot hardware without a pass-thru won't be compatible. I've seen so many cartridge-based applications ported over to disk for convenience (MAC/65, Action, etc), but the nature of The Last Word means that it will not be adaptable in this way (it would be like trying to run SpartaDOS X from disk).

 

So what do folks think? I can see the advantages of a cart:

 

• Instant loading
• Flip in and out of DOS using SDX
• Attractive, tangible product
• Virtually limitless code size
• Works on 64K systems

And for a disk-based edition:

 

• Works with MyIDE
• Works with MaxFlash SpartaDOS X
• Totally free to run on any machine (no need to invest in a flash cart)

Views?

Edited September 5, 2010 by flashjazzcat

[spookt]

Hmm, interesting question.

 

At the moment I use SpartaDos X from a MaxFlash cart and I have a large ATR image on my SIO2USB where I keep applications and tools etc. At some point in the future I'll probably switch over to a MIO and hard drive setup on my main machine. Even if I were using some kind of internal SDX module I think I'd still like to be able to load up TLW from my SIO2USB / hard disk the same way as other applications.

 

I would *love* to see a retail edition, but I guess my preference would be for that to be a floppy release which was installable to a SpartaDos partition.

 

I'm not sure how limiting the 64Kb boundary is for other folks though. Personally none of the machines I use regularly have less than 128Kb. Even my old faithful 800XL has 256Kb,

[+Roydea6]

I think both options would be good. I have a internal MyIDE machine that is usually keep stored away. But the one I use for daily stuff would love to have a Cartridge. Anything with larger buffers.

[8bitguy1]

Could you get SDX and LW4 in the same cart? (forgive me if this is a ridiculous idea, but on the nature of it, it seems reasonable to ask)...otherwise I'd have to say disk based makes more sense from a purely functional point of view.

[flashjazzcat]

I'm not sure how limiting the 64Kb boundary is for other folks though. Personally none of the machines I use regularly have less than 128Kb. Even my old faithful 800XL has 256Kb,

I honestly think that if you want to run a "pro" word processor with large text buffers, you'd probably have expanded RAM anyway. Version 3.2 of LW miraculously fits 28K of code and 20 odd Kb of buffers into 64K, but that's mainly for the sake of purism. Even a cartridge based version would struggle to fit everything into 48K (while keeping clear of the Shadow RAM).

 

I think both options would be good. I have a internal MyIDE machine that is usually keep stored away. But the one I use for daily stuff would love to have a Cartridge. Anything with larger buffers.

I'd love both too, but sadly I only have time to write one (if that!). Larger buffers are a given, though - 32K minimum (there's no real practical ceiling on buffer size other than the speed of moving the cursor from start to end of file).

 

Could you get SDX and LW4 in the same cart? (forgive me if this is a ridiculous idea, but on the nature of it, it seems reasonable to ask)...otherwise I'd have to say disk based makes more sense from a purely functional point of view.

Well, if you have an 8Mbit FlashCart and suitable software, in theory there'll be nothing stopping you placing LW.EXE onto SpartaDOS X's CAR: volume (where all the external commands are stored). I actually think you've hit on rather an ingenious idea there: another plus for a disk-based version!

Edited September 5, 2010 by flashjazzcat

[Mathy]

Hello Jon

 

You could use a bank switching cartridge to get more code into a cart. And if you make a pass thrue cart out of it, you can even stack them.

 

sincerely

 

Mathy

[+Stephen]

Really tough choice! I like the cart option, but I voted disk because I can't guarantee my machine with internal SDX will always be the main one I have hooked up.

[flashjazzcat]

You could use a bank switching cartridge to get more code into a cart.

That's a given: the code would require at least 5 x 8K banks.

[Lord Thag]

I have a couple of Atari setups, only one of which is useable with sio2pc. I'd much prefer a cart that I can swap out between systems.

 

Though that said, it's really the sio 2pc functionality that is key for me. If I could actually write/save to the pc in a standard pc readable format, I would actually USE this to work on my novel, poetry etc. Really. Nothing beats a 1200xl keyboard

[flashjazzcat]

I have a couple of Atari setups, only one of which is useable with sio2pc. I'd much prefer a cart that I can swap out between systems.

 

Though that said, it's really the sio 2pc functionality that is key for me. If I could actually write/save to the pc in a standard pc readable format, I would actually USE this to work on my novel, poetry etc. Really. Nothing beats a 1200xl keyboard

With the aid of a text converter, you can do this already. I was thinking of writing an add-in to automatically do the CR/LF conversions. In the next version, it could be a built-in feature. The ability to do automatic filtering on selected drives would be a useful feature in peripheral emulators.

Edited September 5, 2010 by flashjazzcat

[flashjazzcat]

Here's a quick macro I've just found useful while converting a load of Fast Assembler source files:

 

crlf2ret.zip

 

<Option+R> to convert CR/LFs to Atari EOLs, and <Option+C> to convert them back again.

[+Roydea6]

Here's a quick macro I've just found useful while converting a load of Fast Assembler source files:

 

crlf2ret.zip

 

<Option+R> to convert CR/LFs to Atari EOLs, and <Option+C> to convert them back again.

 

 

Very worthy macro. Next to saveall.mac this is most usable. Cuts down on a lot of global replace of CR/LFs.

Thank You!

[+bf2k+]

As an SDX user, I'd have to go with disk based!

[flashjazzcat]

Very worthy macro. Next to saveall.mac this is most usable. Cuts down on a lot of global replace of CR/LFs.

Thank You!

Writing it (and it isn't complex) made me realize that this kind of functionality is a fairly major undertaking. To provide load/save with automatic CR/LF filtering would probably be best accomplished by double-buffering the I/O stream, since the data changes size on the fly. Say, read 1024 bytes, do the conversion, then feed the result into the input stream.

 

Glad disk-based is winning, anyway. I'd love to do a cart version but it's humanly impossible to do both in a reasonable time-frame.

[Kaz atarionline.pl]

My question: what would be the price of cartridge version?

[Marius]

100% a disk.

 

Another Benefit of a disk: you can easily make backup of the program itself, by yourself!

 

I don't like carts at all, since there are so much better alternatives.

 

But it is only my opinion...

 

Marius

[NuY]

Not being a coder, the following suggestion might not be doable, but I'll throw it out there anyway.

 

Assuming the code itself for a cart version would reside fully in 64k (I would say this is the lowest common denominator), what if there was an option to edit a file on a disk instead of having the text buffer in RAM? Have say, 1k of buffer for whatever is on screen currently and page in the rest from disk as needed when going up/down the document being edited. This in theory would allow any 800XL (or machine with 64k) to have the fully featured cart version on a disk, instead of having to cut down on features. If one has a 128k or higher machine, then the RAMdisk could be used in the same manner.

 

For a disk based system, obviously this would be some wear on the disk drive with constant access, so I suppose it would depend if a user thought that this was a reasonable trade off.

[flashjazzcat]

My question: what would be the price of cartridge version?

Probably my health or my marriage. Seriously: no idea. I think a plush disk package would be just as nice, but it's all down to whether someone wants to produce it.

 

Not being a coder, the following suggestion might not be doable, but I'll throw it out there anyway.

 

Assuming the code itself for a cart version would reside fully in 64k (I would say this is the lowest common denominator), what if there was an option to edit a file on a disk instead of having the text buffer in RAM? Have say, 1k of buffer for whatever is on screen currently and page in the rest from disk as needed when going up/down the document being edited. This in theory would allow any 800XL (or machine with 64k) to have the fully featured cart version on a disk, instead of having to cut down on features. If one has a 128k or higher machine, then the RAMdisk could be used in the same manner.

 

For a disk based system, obviously this would be some wear on the disk drive with constant access, so I suppose it would depend if a user thought that this was a reasonable trade off.

The cartridge, since it's banked in 8K blocks, wouldn't really care whether it was running on a machine with 64K or 1088K. The difficulty is in handling the bank-switching in the code; the rest of RAM outside of $A000-$BFFF can be used for buffers, variables and text, and $4000-$7FFF is perfectly accessible for banking in extended RAM. All a 64K machine would be missing out on is the ability to handle large documents, undo/redo, etc. Absolutely requiring the program runs on a 128K minimum machine removes a lot of variables.

 

Many 8-bit and 16-bit text editors, IIRC, used to buffer portions of the file on disk. Really you need a lot of disk space so that you can create a new copy of the file with the deletions and insertions as you work from top to bottom through the document. I should imagine it would be fast enough with an HDD or high speed SIO device, but stuff like global search and replace would really suffer. With extended RAM, we have the opportunity to "see" two or three 16K banks as a single linear entity using the virtual access I've devised, and experiments have shown that editing a 32K or 48K file in RAM will be almost as fast as the 16K files we're limted to now (this is almost entirely due to the fact that LW never has to move the text in front of the cursor to make way for insertions and deletions).

 

The fact is I'd really like to have undo/redo and the large buffers active right from the off, and this demands a 130XE and up. The idea of having a cart which won't run on a 64K machine seeming somehow odd to me, my bets are on a disk version.

Edited September 6, 2010 by flashjazzcat

[tomo]

Definetly disk based version. Since I have brought atarimax 8Mb flash cartridge witch allows me to use SDX. Sio2IDE as a disk drive. So i don't like idea of switching cartridges to just run extended text editor.

 

Thanks for superior program. tomo

[Rybags]

A decent sized cartridge can be used as a virtual disk anyway.

 

That way, you can save the pain of cross-bank calls.

 

Of course that can lead to programming something as being modular where parts that are needed are copied to RAM and deleted as required - all fine and good for something cartridge-based (as virtual disk), but can be a pain if disk-based.

 

On the other hand, you can just use some of expanded RAM as a RAMDisk and load most of the modular stuff in, so both versions could be similar in speed once loaded, and the coding could be identical except for the virtual disk on ROM handler.

[Kylev]

I voted disk. I don't use SpartaDos X (not currently having any real hardware available, at the moment) so compatability with the cartridge based dos was not a consideration.

I just like the portability and ease of access for emulator work that a disk-based application provides. I haven't put your latest version to work, yet, but I intend to try it out shortly. The documentation I have read is very well written and easy to follow. Thanks for your efforts in developing and producing this application.

 

Russ

[flashjazzcat]

Well, looks like this poll is finished (although I'm at a loss as to how I close it: admins?), and disk won out by almost two to one. That's good, because I favour a disk edition.

 

Settling down to some coding with my super-fast MyIDE interface and a 32MB partition under SpartaDOS X, I suddenly realize the need for a text editor which can handle files bigger than 16K. Source files tend to be long... Of course, while such programs exist, LW is one of the faster editors around (especially in 80 columns), so I'd like to use that for source code editing. This is giving me the hurry-up on the next version of LW. So, this is how the next release will look:

 

• Disk based, and requiring AT LEAST 128K
• No RAM under the OS used (Sparta 3.x compatible)
• Multiple 32K text buffers (might even stretch it to 48K a piece)
• VBXE support (see below)

Other than that, I expect it'll look more or less the same as the recently released version 3.2. I mainly want the bigger buffers for my own use. Things which will take a little longer and which I'm going to push back to - say - version five, include:

 

• Multi-level undo/redo
• Display drivers
• Drop-down menu/dialogue box interface
• Redesigned macro language

Display drivers basically open the door for a unified approach to VBXE, XEP-80, etc, and since I'm doing things in stages, I'm unsure how long it will take to design and implement the driver scheme (and which version usher in support for 80 column VBXE mode). The program will load its own specially written display drivers at startup, which means no performance overhead, no need to load drivers before starting the program, and complete control of display memory usage, scrolling, etc. Of course we already have a beta version of LW which runs in VBXE 80 column mode (although it lacks all the other forthcoming features) which I may finish and release first.

 

Dragging all the code out from under the OS ROM and arranging it in conventional RAM with the edit buffer bank-switching in sections on top of the program code is quite a daunting task in its own right: hence the incremental versions.

Edited September 15, 2010 by flashjazzcat

[Defender II]

Can you release a cart based version after the disk one is done? Carts last longer and I don't usually have a disk drive hooked up. I could use an ATR image on my SIO2SD, but I like carts so I don't have to search for it on the SD card.

[Fox-1 / mnx]

Carts last longer and I don't usually have a disk drive hooked up.

 

If I write some TXT's I usually want to store them onto something in stead of only making a hard copy and forget about it when I reset the system :-)

[OldAtarian]

Doesn't anybody use cassettes anymore?