Jump to content
flashjazzcat

The Last Word - A New Word Processor for the XL/XE! (now NTSC-compatible)

Recommended Posts

I used the LWCONFIG.COM utility from the original LW package to create a config file which loaded into the 80 column version fine. I had a similar issue with the text being a little too light to be comfortable on my TV so I just used the config program to play around with the settings until I found something that worked.

Share this post


Link to post
Share on other sites
I used the LWCONFIG.COM utility from the original LW package to create a config file which loaded into the 80 column version fine. I had a similar issue with the text being a little too light to be comfortable on my TV so I just used the config program to play around with the settings until I found something that worked.

Yep - luckily the CFG file format produced by the config program hasn't changed at all (although it will probably have to eventually), so you can use that to make black on white text in the editor (or whatever works best). I'm hoping the output will look OK on my LG LCD TV once it's hooked up to my 130XE with an s-video or composite lead, but by the sound of things the upscaling might hurt the image quality. Come back bulky CRT portable telly or yore, all is forgiven... Hopefully my SIO2SD will be here in a couple of days, too. Can't wait to try LW80 on a real machine myself.

 

I've fixed a good number of the reported bugs. The next job is to sort out the crippled or unimplemented features, such as extended memory and multi-language support. I'll release an interim version in a day or two which should be more-or-less bug-free, and hopefully good enough to use until the finished article arrives.

 

Possibly the biggest job (and this will have to be carefully synchronised with both 80 and 40 column versions of the program) will be to re-arrange the memory allocation and create a data table (similar to the COMTAB table in SpartaDOS X) which will contain vectors to LW's variables and editor routines for the purpose of writing machine code add-ins. At the moment, add-ins call routines directly and when the program is reassembled, equates change, and the add-ins have to be recompiled. Using a vector table with spare "padding" bytes, add-ins written for LW80 and its 40 column counterpart should remain compatible regardless of further amendments to the main program. Direct calls to routines in memory is a messy way of doing things and I'd rather abandon support for add-ins than continue in that vein. So, a little more work but it should be worth it in the long-run. :)

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Hi!

 

Pin/Tristesse has tested that 3.8 pre-alpha and...

 

"Either on emu and on real atari the program acts unpredictably. Just try to fill first line with text the way that the last word written will be placed in the next line. Then try to delete that last word with the Backspace key. The effect of it is that part of this word is erased, and the rest of it additionally returns to previous line together with cursor where we can continue the destruction".

Share this post


Link to post
Share on other sites

It would be a good idea to let him know what kind of machine and setup your using to help him know exactly what the problem is and on what....

 

for example

 

on a 130XE ntsc, 320k peterson and antic access mod

 

LW a3.8

default configuration

both 192k and 320 mode

Dos 2.5 and SpartaDosX 4.42

 

the program is only reporting 16127 free

 

type a few word and press enter about 15 time then hold down delete backspace. white boxes appear on the left edge of the screen even though nothing should be there.

 

sometimes the tab stops vanish from the ruler at the top of the page after exiting disk directory functions.

 

running tdline with lw the tab stop problem no longer occurred. Very nice to see lw work with TDLINE!

Edited by _The Doctor__

Share this post


Link to post
Share on other sites
It would be a good idea to let him know what kind of machine and setup your using to help him know exactly what the problem is and on what....

 

for example

 

on a 130XE ntsc, 320k peterson and antic access mod

 

LW a3.8

default configuration

both 192k and 320 mode

Dos 2.5 and SpartaDosX 4.42

 

the program is only reporting 16127 free

 

type a few word and press enter about 15 time then hold down delete backspace. white boxes appear on the left edge of the screen even though nothing should be there.

 

sometimes the tab stops vanish from the ruler at the top of the page after exiting disk directory functions.

 

running tdline with lw the tab stop problem no longer occurred. Very nice to see lw work with TDLINE!

I haven't noticed any problems with the tab line during testing; hopefully any glitches will have disappeared because I've done a lot of work on the disk utility screen over the past few days. It worked straight out of the box when I implemented the 80 column system, but since it used to refresh up to 80 filenames on the screen after each keystroke, it was a bit slow so I had to do a big rewrite.

 

Many problems are caused by a hastily cobbled together system of buffer space allocation: again, this will be corrected when I finalise the memory map. Speaking of which, this version will ALWAYS report a 16K text buffer, since it doesn't yet include routines to take advantage of various memory set-ups.

 

The biggest bug is the one where stray characters were left on the screen after the last character in the document. I fixed this yesterday...

 

LW was designed to work with TDLINE; I haven't tested it for a while so I'm glad to hear it still works! :)

Share this post


Link to post
Share on other sites

As part of the reorganization of LW80's memory map, I have redesigned the way the program interfaces with the 80 column system to the point at which it could become virtually device independent, which is to say any device which can output a character at X,Y on the screen could be made to work with LW (previously the screen updates were tightly entwined with the core code of the word processor). This means support for XEP-80 and other hardware or software screen drivers will be MUCH easier to implement in the future.

 

I should have a beta version ready for the weekend, which will include extended RAM support, a built-in keyboard buffer (which will switch itself off if the SpartaDOS or any other system-wide buffer is installed and active), and a large main text buffer. Multi-language support is still something I'm thinking about, subject to space constraints. It would probably require a resource file, which I'd rely on other people to author in the relevant languages.

 

I'm still waiting for my composite video cable, and when that arrives I'll be able to do some testing of my own on a real Atari 130XE. :D

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

I've got all the kit I ordered so I can now test LW on a real machine prior to release. It's amazing to see the 80 column WP running on the little Atari. :) There's still lots of work to do on the program, as I've decided to make the macro buffer and add-in buffer separate (therefore you can mix and match add-on programs and macros at will during an editing session). I'm also going to rewrite the keyboard handler so that it will be possible totally remap the keyboard by loading an altered 256 byte index.

Share this post


Link to post
Share on other sites
I've got all the kit I ordered so I can now test LW on a real machine prior to release. It's amazing to see the 80 column WP running on the little Atari. :) There's still lots of work to do on the program, as I've decided to make the macro buffer and add-in buffer separate (therefore you can mix and match add-on programs and macros at will during an editing session). I'm also going to rewrite the keyboard handler so that it will be possible totally remap the keyboard by loading an altered 256 byte index.

 

I look forward to your thoughts after testing on a real machine. Sadly, my 1200xl just can't seem to crank out a decent enough picture to make the program usable. I tried it with my 600xl which has near perfect picture quality and the characters still get mushed.

Share this post


Link to post
Share on other sites

Pin has also mentioned some display-color-setup. In the 80-column mode text sometimes becomes unreadable se setting the colors may be handy.

Share this post


Link to post
Share on other sites
Pin has also mentioned some display-color-setup. In the 80-column mode text sometimes becomes unreadable se setting the colors may be handy.

Yep - this can be accomplished with the config program but I could write an add-in for "in situ" alerations to the screeen colours. I didn't have high hopes for the clarity of the display through s-video on my LCD TV, but white on blue, black on white and white on black all look pretty readable, especially if I ramp up the "sharpness" setting on the TV. White on black or blue won't look so good on all sets, however, so black text on white or light green on dark green is probably the best scheme in those cases.

Share this post


Link to post
Share on other sites
Pin has also mentioned some display-color-setup. In the 80-column mode text sometimes becomes unreadable se setting the colors may be handy.

Yep - this can be accomplished with the config program but I could write an add-in for "in situ" alerations to the screeen colours. I didn't have high hopes for the clarity of the display through s-video on my LCD TV, but white on blue, black on white and white on black all look pretty readable, especially if I ramp up the "sharpness" setting on the TV. White on black or blue won't look so good on all sets, however, so black text on white or light green on dark green is probably the best scheme in those cases.

 

Yes, please, please do this. Keep up the great work/ :)

Share this post


Link to post
Share on other sites
Yes, please, please do this. Keep up the great work/ :)

Thanks - I'll try! :) The massive re-write is mostly done now; hopefully I'll be able to find a spare key combination or two to permanently map colour changing capability to the keyboard. If not, it will go on an add-in. Non-English users will be pleased to hear that it's now possible to remap the entire keyboard if you don't like the default key assignments (I haven't written a key map editor yet, though). This includes all the SHIFT+CTRL key combinations (which now send inverse control characters to the editor rather than raw keyboard codes). The internal functions of the program are mapped to the ASCII codes so redefining the keyboard won't mess up the macro commands. This also means there are no SHIFT+CTRL commands that macros can't call now. And on the subject of multi-language support, I'm not far off designing a system that will allow all the prompts and key responses in the program to go into a resource file; hopefully I'll be able to recruit a few volunteers to write resource files in different languages when I get around to implementing this.

 

Oh... and the Exit to DOS bug is fixed. I wasn't re-instating the OS before jumping through $0A. :ponder:

 

Another thought... having the program dynamically switch between 80 column and 40 column views may be too much of a headache. I'm thinking of making two distinct versions (although even that will involve a fair bit of work since because the program has changed so much, I'll have to downgrade the 80 column version to a 40 column variant rather than bring the existing 40 column version up to date). The 80 column version is running very well, though: I've just implemented the extended RAM routines and they work great so we should have a beta out in a few days.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

You might consider a config file, ie., a config.sys style item to control startup capabilities so that you dont have to come up with arcane key combos and so forth. I am assuming you havent already done that, so forgive me if you have.

 

Yes, please, please do this. Keep up the great work/ :)

Thanks - I'll try! :) The massive re-write is mostly done now; hopefully I'll be able to find a spare key combination or two to permanently map colour changing capability to the keyboard. If not, it will go on an add-in. Non-English users will be pleased to hear that it's now possible to remap the entire keyboard if you don't like the default key assignments (I haven't written a key map editor yet, though). This includes all the SHIFT+CTRL key combinations (which now send inverse control characters to the editor rather than raw keyboard codes). The internal functions of the program are mapped to the ASCII codes so redefining the keyboard won't mess up the macro commands. This also means there are no SHIFT+CTRL commands that macros can't call now. And on the subject of multi-language support, I'm not far off designing a system that will allow all the prompts and key responses in the program to go into a resource file; hopefully I'll be able to recruit a few volunteers to write resource files in different languages when I get around to implementing this.

 

Oh... and the Exit to DOS bug is fixed. I wasn't re-instating the OS before jumping through $0A. :ponder:

 

Another thought... having the program dynamically switch between 80 column and 40 column views may be too much of a headache. I'm thinking of making two distinct versions (although even that will involve a fair bit of work since because the program has changed so much, I'll have to downgrade the 80 column version to a 40 column variant rather than bring the existing 40 column version up to date). The 80 column version is running very well, though: I've just implemented the extended RAM routines and they work great so we should have a beta out in a few days.

Share this post


Link to post
Share on other sites
You might consider a config file, ie., a config.sys style item to control startup capabilities so that you dont have to come up with arcane key combos and so forth. I am assuming you havent already done that, so forgive me if you have.

Not at all - I absolutely agree with you! :) LW already has the LW.CFG configuration file, which you can edit using the separate config utility. All user-preferences are saved in this file, but only some can be set (and saved) within the word processor itself. Setting screen colours isn't something that can currently be accomplished in situ, but because the 80 column text often requires experimentation with screen colours in order for it to be readable, I feel it should be possible to alter the colours from within the main application (you'll then be able to save the colours so that they are the default). One obvious solution is to write a machine code add-in, which will allow the user to set various parameters in the program. The add-in can then be discarded (or overwritten by another add-in). The latest (forthcoming) version of LW is going to make it much easier to write add-ins, and their scope is virtually unlimited (the old version of LW had an add-in which acted like the auto-correct function in Microsoft Word).

 

Re my earlier comments about switching between 40 and 80 column modes: I now feel this should be possible, and this will mean there will only be a single version of the program as opposed to two.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites
Add-ins? Do you have any interface details about them? I'd be happy to write an API for people to use in the various popular atari languages.

I will have interface details as soon as all the equates are finalized. Clearly this will be a fairly large job since I'll have to document all the calling parameters for LW's internal routines as well as their addresses so that the add-ins can call them properly. However, the equates will never change once documented (even if the program itself changes). Any language which produces a stand-alone, unsegmented binary module at a fixed address will be capable of producing add-ins for LW. A good API would make the job a whole lot easier for interested parties so I'd be happy to take you up on your offer once I've documented everything. :)

 

As an aside, an add-in starts with a vector table (after the usual six-byte binary header) to its own routines, which the main program inspects and hooks into when the files are loaded. There are hooks for the editor, print formatter, and disk menu.

 

...flipping between 80 and 40 columns is working well - thankfully I only have one version of the program to worry about now!

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Sounds great. Any info at all would be enough to get me started...maybe if you have an example you could send me the source code? If not, I'll just wait for docs.

 

As an aside, an add-in starts with a vector table (after the usual six-byte binary header) to its own routines, which the main program inspects and hooks into when the files are loaded. There are hooks for the editor, print formatter, and disk menu.

 

Hmmm. The description you gave sounds like they are 'replacements for' rather that add-ins. By 'hooks' do you mean a 'call this instead of that' type hook or a 'call this in addition to that' chained hook?

 

I assume that the ability to see the internals ( such as the line list, etc.) would be available, either as hard locations or ( much better ) as offsets to a symbol. A query function on your side could allow the name of a symbol to be passed in and would return an address. This very important step isolates you from breaking add-ins by changing your code. The query function itself would have to remain static, but you would be free to change other things.

 

On the add-in side, there should be a standard 'start-up' and 'shut-down' vector in the table so that you would always call a particular entry for startup and one for shutdown. Add-ins also should be able to register for things, like a 'call me when a keypress happens' or 'call me when a print is requested' but that may be a bit much to ask.

Edited by danwinslow

Share this post


Link to post
Share on other sites
Sounds great. Any info at all would be enough to get me started...maybe if you have an example you could send me the source code? If not, I'll just wait for docs.

None of the current add-ins (which I have source code for) will work with the new version, so I'll have to at least prepare some brief documentation. Hopefully I'll have something you can make a start with by the weekend. Roughly speaking, though, add-ins need to reference a large jump table at a fixed memory location, and will be passing arguments mostly via page zero pointers. In assembler, I envisage a calling procedure along the lines of:

 

INSCHAR = $21
DELCHAR = $22
UMOVE = $23
JUMPTABLE = $8000
...

START:
LDA #$9B; END OF LINE
LDY #INSCHAR; LOAD WITH # OF INSERT ROUTINE
JSR CALL

...

CALL:; PASS Y REGISTER WITH # OF ROUTINE TO CALL
PHA; SAVE A
TYA
ASL A
TAY
LDA JUMPTABLE,Y
STA VECT+1
LDA JUMPTABLE+1,Y
STA VECT+2
PLA; RESTORE A
VECT:
JMP $FFFF
;

...or something like that. Things may become more complicated if LW's internal routine expects an argument to be passed in the Y register... :ponder:

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Ok. Btw, I edited a few more comments in my post above, but I'll restate here.

 

QUOTE

As an aside, an add-in starts with a vector table (after the usual six-byte binary header) to its own routines, which the main program inspects and hooks into when the files are loaded. There are hooks for the editor, print formatter, and disk menu.

 

 

Hmmm. The description you gave sounds like they are 'replacements for' rather that add-ins. By 'hooks' do you mean a 'call this instead of that' type hook or a 'call this in addition to that' chained hook?

 

I assume that the ability to see the internals ( such as the line list, etc.) would be available, either as hard locations or ( much better ) as offsets to a symbol. A query function on your side could allow the name of a symbol to be passed in and would return an address. This very important step isolates you from breaking add-ins by changing your code. The query function itself would have to remain static, but you would be free to change other things.

 

On the add-in side, there should be a standard 'start-up' and 'shut-down' vector in the table so that you would always call a particular entry for startup and one for shutdown. Add-ins also should be able to register for things, like a 'call me when a keypress happens' or 'call me when a print is requested' but that may be a bit much to ask.

 

 

We can talk more about this offline or in another thread, I don't want to hold you up or distract you now. Feel free to PM me later.

Share this post


Link to post
Share on other sites
Ok. Btw, I edited a few more comments in my post above, but I'll restate here.

 

QUOTE

As an aside, an add-in starts with a vector table (after the usual six-byte binary header) to its own routines, which the main program inspects and hooks into when the files are loaded. There are hooks for the editor, print formatter, and disk menu.

 

 

Hmmm. The description you gave sounds like they are 'replacements for' rather that add-ins. By 'hooks' do you mean a 'call this instead of that' type hook or a 'call this in addition to that' chained hook?

 

I assume that the ability to see the internals ( such as the line list, etc.) would be available, either as hard locations or ( much better ) as offsets to a symbol. A query function on your side could allow the name of a symbol to be passed in and would return an address. This very important step isolates you from breaking add-ins by changing your code. The query function itself would have to remain static, but you would be free to change other things.

 

On the add-in side, there should be a standard 'start-up' and 'shut-down' vector in the table so that you would always call a particular entry for startup and one for shutdown. Add-ins also should be able to register for things, like a 'call me when a keypress happens' or 'call me when a print is requested' but that may be a bit much to ask.

 

 

We can talk more about this offline or in another thread, I don't want to hold you up or distract you now. Feel free to PM me later.

The "hooks" are additions rather than replacements. The add-in format (as it stands - but I'll change it if need be) starts with a number of 16 bit pointers. If they're null, LW ignores them. If a pointer is the address of a routine in the add-in binary, however, LW will JSR through that vector everytime the appropriate key is pressed or formatting character is encountered. At the moment, two (unused) editor keys and six formatting characters have "slots" in the vector table. If I recall correctly, there's also an "init" vector will will be executed as soon as the add-in is loaded. I'll add one for a macro command, and anything else I can think of.

 

As for symbols and absolute addresses: in previous versions of LW, add-ins called routines with absolute addresses. Clearly this will break the whole system when the code changes (as you point out), but at the time I didn't have the code space to implement anything better. Now that I've freed up space, however, I've placed a vector table at a fixed point in LW's executable. The table has entries for all LW's commands and utility routines (print message, move memory, etc), followed by the variable table and various buffers. These tables will be padded out with null bytes (for future expansion) and will never be moved. This way, we at least get some of the security of a symbol system, without the overheads (an SDX-type symbol system would be nice but it would be overkill in this instance: code will still be quite readable if the vectors are accessed using named labels in assembler).

 

The idea of "registering" is excellent; hopefully the liberal use of hook points at likely points of interest will achieve the same effect. Once again, the add-in header has spare entries, in case additional hook points are added in the future.

 

Hopefully add-ins will warrant a thread of their own if people are interested in writing them. In any case - feel free to contact me if you want to exchange ideas over the next few days (before the add-in system is finalised). You have some good ideas which I'd like to incorporate into the program, space permitting!

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

If anyone is willing to translate the screen prompts for LW into different languages, please let me know. If there's sufficient interest, I'll make all the prompts editable in the final version (though not in the beta).

 

This weekend's beta includes:

 

• 40 and 80 column editing (40 for speed and clarity, 80 columns for layout), switchable on the same document "on the fly"

• Detection of most known memory expansions

• The ability to use an extended bank for the paste and macro buffers, yielding a main text bank of up to 25K

• Reconfigurable keyboard layout

• The ability to use user-defined 80 column fonts

• 20 line, 80 column print preview (regardless of whether the editor is in 40 or 80 column mode)

• The ability to use 1K machine code add-ins which won't rely on absolute addresses in the main program (so they won't break when the program is changed)

• Built-in keyboard buffer (automatically deactivated if an OS type-ahead buffer is present)

• Macros can now call every single editor function

 

LW80 will work on unexpanded 64K machines or Ataris with up to 1MB of RAM. The only proviso is that DOS doesn't use code under the OS.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

I just finished the Clearpic2 mod on a 1200xl I'm selling and thought I'd give LW a try on this machine-- WOW! Perfect! All of the characters are sharp and solid. No blurring or smudging whatsoever.

 

Does the new Beta address the L1 and L2 light issues for 1200xl's?

Share this post


Link to post
Share on other sites
I just finished the Clearpic2 mod on a 1200xl I'm selling and thought I'd give LW a try on this machine-- WOW! Perfect! All of the characters are sharp and solid. No blurring or smudging whatsoever.

 

Does the new Beta address the L1 and L2 light issues for 1200xl's?

Glad you like it! It works great if you have the right display (it looks pretty good on my LCD TV via s-video with an unmodified 65XE).

 

Yes - the new beta uses the proper PORTB banking values so the 1200XL lights should stay turned off. :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...