Jump to content
IGNORED

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


flashjazzcat

Recommended Posts

Last night I finished cleaning and fixing my 1200xl. No MOD's -- . The first program I booted was Last Word 3.0 beta 1. The screen looks great, but the keyed input just typed gibberish. I finally decided that the program probably can't find the Keyboard Matrix. Basic and Dos key input looks normal. Now I am going to hook up my 800 and see if it has the same problem with Last Word 3.0 Hoping that this is not OS dependant.

Link to comment
Share on other sites

Hoping that this is not OS dependant.

Strange indeed, because although prior versions of LW used the table pointed to by KEYDEF ($79,$7A), version 3.0 uses a custom, built-in 256 byte table (which includes an extra 64 bytes of SHIFT+CTRL keystrokes). This has been done to (eventually) allow total user redefinition of the keyboard layout. LW's keyboard handler is now totally OS-independent. I haven't noticed any problems with 1200XLs before. Sounds like something is corrupting LW's key table: I can't imagine what, though.

Link to comment
Share on other sites

Main problems I've noted so far:

 

- Inconsistent allocation of memory and avoidance of RAMdisks in DOS 2.5/MyDOS (which was kind of expected)

- 1200XL keyboard problems (without any known cause at the moment)

- Screen flickering and corruption when switching between 40 and 80 column displays (known issue)

- Crashing when exiting to DOS (generally associated with extended memory management)

 

Other issues include:

 

- When typing text at the last position on the screen, the display does not scroll up when the line wraps; instead the whole thing redraws. It should really scroll.

- Curruption of status line when switching display modes or returning prematurely (with Break Key) from a print preview operation.

- Unspecified behaviour/presence of preview window during print/print to disk operations.

- Inconsistent redefinition of false space/end of line characters when loading new fonts.

 

If anyone else has any other data, please let me know. If only I had a spare SQL database on the web server, I'd set up a bug-tracker!

 

I aim to get LW close to finished over the weekend. I've started using it as a source code editor myself and it's generally been pretty stable under SpartaDOS 4.42.

Link to comment
Share on other sites

What exactly are the 1200xl keyboard problems? I haven't noticed any on my 1200xl. It may be that the "gibberish" being reported is actually just bad video. That's how things looked on mine before doing the video mod.

From a few posts back:

Last night I finished cleaning and fixing my 1200xl. No MOD's -- . The first program I booted was Last Word 3.0 beta 1. The screen looks great, but the keyed input just typed gibberish. I finally decided that the program probably can't find the Keyboard Matrix. Basic and Dos key input looks normal. Now I am going to hook up my 800 and see if it has the same problem with Last Word 3.0 Hoping that this is not OS dependant.

There should be no keyboard problems with ANY OS. This is why I can't understand it. Until I have more info I can't fix it, because there's nothing to fix! :)

Link to comment
Share on other sites

There should be no keyboard problems with ANY OS. This is why I can't understand it. Until I have more info I can't fix it, because there's nothing to fix! :)

 

Hi,

This morning I re-connected the un modified 1200xl and ran LW to verify my problems, but there is no problem this morning. All keys respond properly. :)

Link to comment
Share on other sites

There should be no keyboard problems with ANY OS. This is why I can't understand it. Until I have more info I can't fix it, because there's nothing to fix! :)

 

Hi,

This morning I re-connected the un modified 1200xl and ran LW to verify my problems, but there is no problem this morning. All keys respond properly. :)

 

See what a good night sleep can do :D

Link to comment
Share on other sites

This morning I re-connected the un modified 1200xl and ran LW to verify my problems, but there is no problem this morning. All keys respond properly. :)

Great! Now we can move on; just gotta debug the expanded RAM routines, test the macro processor, fix various other issues, alter the config file format, implement the add-ins, and write a keymap editor... Better get on with it! :D

Link to comment
Share on other sites

This morning I re-connected the un modified 1200xl and ran LW to verify my problems, but there is no problem this morning. All keys respond properly. :)

Great! Now we can move on; just gotta debug the expanded RAM routines, test the macro processor, fix various other issues, alter the config file format, implement the add-ins, and write a keymap editor... Better get on with it! :D

 

I don't know whether to say "thank you" or "seek help" :D You certainly have put your heart into this project. I, for one, certainly appreciate all the work you've done and am looking forward to the finished version. Rest assured, it will actually get used at least for some small projects here at my office.

Link to comment
Share on other sites

You could just restrict yourself to fixing the outright bugs in the current build before going on to further additions. I know I'd like a stable version to use and test with...the bells and whistles can be added in subsequent releases. Just a suggestion :)

It's a good suggestion. If you want a bug fixed version of the current build, I'll be happy to provide it. The main thing holding me up is MyDOS and DOS 2.5 RAMdisk detection. If I strip this out altogether and leave it up to the user to configure multiple banks with those DOSes, things will move on a whole lot quicker. I'm thinking of putting the generic RAM detection routine in the config editor, and then letting the user just pick whatever banking codes he wants LW to use from a list on the screen. This would mean no extended banks would be used with DOS 2.5 and MyDOS "Out of the Box".

 

SpartaDOS X users have no such problems, since LW lives in perfect harmony with any upgrades, RAMdisks and OS banks that this DOS throws at it.

 

That's the way I'm thinking of heading with this, anyway. I just wanted to know how people felt about it. SDX happens to my preferred OS, but I'm trying to cater for everyone's tastes here! :)

I don't know whether to say "thank you" or "seek help" :D You certainly have put your heart into this project. I, for one, certainly appreciate all the work you've done and am looking forward to the finished version. Rest assured, it will actually get used at least for some small projects here at my office.

LOL! :D I must just have an obsessive personality when it comes to problem solving (see recursive file copier!). I already put so much work into this project ten years ago and I'm having such fun (most of the time) developing it further, it would be as crazy not to finish it to a professional standard now as it was to write a WP for the Atari8 in 1999 in the first place! :) If the limit of my computing achievement is to be the guy who wrote one of the better Atari8 text editors, and one which is actually used by enthusiasts, that's good enough for me.

Edited by flashjazzcat
Link to comment
Share on other sites

*** SNIP ***

 

SpartaDOS X users have no such problems, since LW lives in perfect harmony with any upgrades, RAMdisks and OS banks that this DOS throws at it.

 

That's the way I'm thinking of heading with this, anyway. I just wanted to know how people felt about it. SDX happens to my preferred OS, but I'm trying to cater for everyone's tastes here! :)

Here's one vote for manual config under DOS2.5 / MyDOS. I never use them, especially with the latest revision of Sparta X 4.42 working on flashcarts.

 

Stephen Anderson

Link to comment
Share on other sites

Aye, I agree as well. So let it be written....so let it be DONE!

......

LOL! Hugely ironic, this, since the first version of LW I released here last December was entirely manually configured when it came to RAM banks. Auto-RAM detection was a much requested feature. I'd be in hysterics now if the SDX memory code hadn't been such a worthwhile and effective addition!

 

DOS 2.5/MyDOS are from now on manually configured. I can easily supply some ready-made config files for these DOSes to get people started.

 

So let it be written in assembler, and let it work! :D

Link to comment
Share on other sites

so maybe the config program can detect the dos, then use the appropriate ramdisk/.sav detection routine for that Dos and blammo we're in bussiness?

 

Aye, I agree as well. So let it be written....so let it be DONE!

......

LOL! Hugely ironic, this, since the first version of LW I released here last December was entirely manually configured when it came to RAM banks. Auto-RAM detection was a much requested feature. I'd be in hysterics now if the SDX memory code hadn't been such a worthwhile and effective addition!

 

DOS 2.5/MyDOS are from now on manually configured. I can easily supply some ready-made config files for these DOSes to get people started.

 

So let it be written in assembler, and let it work! :D

 

Link to comment
Share on other sites

Well, there are a plethora of popular disk operating systems out there and I want LW to work with as many of them as possible, so this is the logic I've come up with:

 

The config file contains #banks and a list of ten banking values, all of which the user can configure as they wish. The aim is to make the config editor agressively detect the installed RAM upgrade; the user then just picks which banks they want to use from a list on the screen. Couldn't be easier.

 

For the benefit of SDX users, the config file also contains a flag to say whether the banking table in said config file should be used in preference to the list the OS returns when LW interrogates it during the loading process. This enables SDX users to customise the system, should they need to.

 

So - in short:

 

SDX: always uses what banked memory OS says is installed, unless overridden by config file with "USE CONFIG FILE TABLE" flag to TRUE.

 

Other DOSes: never uses banked memory unless suitable config file is provided. Use of banked memory can be disabled by renaming config file, setting # banks to 0, or setting "USE CONFIG FILE TABLE" flag to FALSE.

Edited by flashjazzcat
Link to comment
Share on other sites

I only use MyDOS. (And Mac OS X ofcourse :D )

I'm considering releasing an OS X version of LW once the Win32 version is finished. :D

 

Does anyone have a clue why my screen is going out of sync when switching between 40 and 80 column modes? It seems to be a timing issue; the first few times, it's OK, but eventually we get flashing and flickering. I've studied the code and it's obviously something to do with the DLI. The swap routine waits for the VBLANK, turns off the DLI bit, swaps display lists, then segues into the main initialisation routine, which in turn calls DLION to re-enable the interrupt. Is everything best done during VBLANK, or am I missing something? I'm considering writing a VBI routine which will handle switching the DLI on and off.

Edited by flashjazzcat
Link to comment
Share on other sites

I'm considering releasing an OS X version of LW once the Win32 version is finished. :D

 

Does anyone have a clue why my screen is going out of sync when switching between 40 and 80 column modes? It seems to be a timing issue; the first few times, it's OK, but eventually we get flashing and flickering. I've studied the code and it's obviously something to do with the DLI. The swap routine waits for the VBLANK, turns off the DLI bit, swaps display lists, then segues into the main initialisation routine, which in turn calls DLION to re-enable the interrupt. Is everything best done during VBLANK, or am I missing something? I'm considering writing a VBI routine which will handle switching the DLI on and off.

Is the VBI routine really complicated where it doesn't finish until after the screen is already being drawn past the first DLI? I am guessing waiting for VBI code will not get called until the after the RTI because the VBI preempts it. Maybe you should always set the address of the first DLI always earlyish in the VBI.

 

--Ken

Link to comment
Share on other sites

Is the VBI routine really complicated where it doesn't finish until after the screen is already being drawn past the first DLI? I am guessing waiting for VBI code will not get called until the after the RTI because the VBI preempts it. Maybe you should always set the address of the first DLI always earlyish in the VBI.

Sorry, I explained that pretty badly! :) There's no custom VBI in the program. What I meant was that I'm waiting for the VBLANK in the sense I'm waiting for the screen to be drawn (using VCOUNT) before setting or clearing the DLI enable bit. There's only ever a single DLI on the screen, and it's a short service routine. What I'm wondering is whether I need to get around this problem by setting up a custom VBI routine which will reliably set/clear the DLI enable bit during the vblank period. Other than that, I don't suppose use of one of the console keys could be causing the problem??? I'll find out soon, because switching screen modes will soon be moved off the START key (the START key runs a macro in final versions of the program).

Link to comment
Share on other sites

Is the VBI routine really complicated where it doesn't finish until after the screen is already being drawn past the first DLI? I am guessing waiting for VBI code will not get called until the after the RTI because the VBI preempts it. Maybe you should always set the address of the first DLI always earlyish in the VBI.

Sorry, I explained that pretty badly! :) There's no custom VBI in the program. What I meant was that I'm waiting for the VBLANK in the sense I'm waiting for the screen to be drawn (using VCOUNT) before setting or clearing the DLI enable bit. There's only ever a single DLI on the screen, and it's a short service routine. What I'm wondering is whether I need to get around this problem by setting up a custom VBI routine which will reliably set/clear the DLI enable bit during the vblank period. Other than that, I don't suppose use of one of the console keys could be causing the problem??? I'll find out soon, because switching screen modes will soon be moved off the START key (the START key runs a macro in final versions of the program).

Hmmm. No idea comes to mind. I assume you are doing some kind of debouncing or delaying so holding the console key down doesn't it make it flip back and forth sometimes.

Link to comment
Share on other sites

Hmmm. No idea comes to mind. I assume you are doing some kind of debouncing or delaying so holding the console key down doesn't it make it flip back and forth sometimes.

Yeah; once the console key latches on, the program doesn't do anything until the key is released. It's a puzzling problem. I guess all I can do is shuffle the coding around a bit until I hit something that works.

Link to comment
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...