Mathy Posted February 12, 2009 Share Posted February 12, 2009 Hello dwhyte I'd just like to let you know, flashjazzcat, that I'll be using The Last Word to write this book. Are you going to mention the program and/or the Atari 8 bit in your book? greetings Mathy Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted February 16, 2009 Share Posted February 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 16, 2009 Author Share Posted February 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2009 Author Share Posted February 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
yorgle Posted February 19, 2009 Share Posted February 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2009 Author Share Posted February 19, 2009 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! Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted February 19, 2009 Share Posted February 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
yorgle Posted February 19, 2009 Share Posted February 19, 2009 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2009 Author Share Posted February 19, 2009 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! Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 19, 2009 Share Posted February 19, 2009 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 Quote Link to comment Share on other sites More sharing options...
yorgle Posted February 19, 2009 Share Posted February 19, 2009 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! I don't know whether to say "thank you" or "seek help" 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2009 Author Share Posted February 19, 2009 (edited) 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" 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! 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 February 19, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 19, 2009 Share Posted February 19, 2009 *** 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 Quote Link to comment Share on other sites More sharing options...
danwinslow Posted February 19, 2009 Share Posted February 19, 2009 Aye, I agree as well. So let it be written....so let it be DONE! Quote Link to comment Share on other sites More sharing options...
yorgle Posted February 19, 2009 Share Posted February 19, 2009 Aye, I agree as well. So let it be written....so let it be DONE! ...... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2009 Author Share Posted February 19, 2009 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! Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 19, 2009 Share Posted February 19, 2009 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! Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted February 20, 2009 Share Posted February 20, 2009 (edited) 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 Me either! SDX rulez! Edited February 20, 2009 by bf2k+ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 20, 2009 Author Share Posted February 20, 2009 (edited) 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 February 20, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Mathy Posted February 20, 2009 Share Posted February 20, 2009 Hello guys I only use MyDOS. (And Mac OS X ofcourse ) greetings Mathy Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Author Share Posted February 21, 2009 (edited) I only use MyDOS. (And Mac OS X ofcourse ) I'm considering releasing an OS X version of LW once the Win32 version is finished. 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 February 21, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
kenfused Posted February 21, 2009 Share Posted February 21, 2009 I'm considering releasing an OS X version of LW once the Win32 version is finished. 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Author Share Posted February 21, 2009 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). Quote Link to comment Share on other sites More sharing options...
kenfused Posted February 21, 2009 Share Posted February 21, 2009 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Author Share Posted February 21, 2009 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.