flashjazzcat Posted January 10, 2009 Author Share Posted January 10, 2009 (edited) I'm not far from finishing the 80 column version of LW. Here's a screenshot of the first working test: It's a little sluggish and needs some optimisation before release but it should be interesting to see how it runs on 65C816 hardware. It still has the horizontal windowing as an option so you can scroll an 80 column window across a 240 column document if you are so inclined! Rewriting the 80 column bit mapping routines made me realize how long-winded LW's original print preview code was. This version accomplishes 80 column output in far fewer cycles. The screen fully redraws in roughly a second, although full redraws are avoided as much as possible using a double-buffering system of sorts. Edited January 10, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
twh/f2 Posted January 10, 2009 Share Posted January 10, 2009 (edited) I'm not far from finishing the 80 column version of LW. Here's a screenshot of the first working test: amazing!! if you need beta testers don't hesitate to send me a copy grtx, \twh Edited January 10, 2009 by twh/f2 Quote Link to comment Share on other sites More sharing options...
spookt Posted January 10, 2009 Share Posted January 10, 2009 Wow ! Can't wait to try it Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 10, 2009 Author Share Posted January 10, 2009 (edited) No problem . It's kind of frustrating because I think I've reached the limit of how far I can push 1.7Mhz. It's just a bit too slow to be useable, but it runs great in high speed emulation. At least now I've laid the foundations for possible XEP-80 interfacing in the future. It wouldn't take long to adapt if only I had some docs for XEP-80 and some means of testing it. ...Just thinking, I might build in a type-ahead buffer which doesn't buffer auto-repeat keystrokes. The SDX buffer has a habit of running away with itself with this program. Edited January 10, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Allan Posted January 10, 2009 Share Posted January 10, 2009 No problem . It's kind of frustrating because I think I've reached the limit of how far I can push 1.7Mhz. It's just a bit too slow to be useable, but it runs great in high speed emulation. At least now I've laid the foundations for possible XEP-80 interfacing in the future. It wouldn't take long to adapt if only I had some docs for XEP-80 and some means of testing it. ...Just thinking, I might build in a type-ahead buffer which doesn't buffer auto-repeat keystrokes. The SDX buffer has a habit of running away with itself with this program. I'm assuming you checked Antic Online for any info on the XEP-80? The XEP-80 is almost like the original 400 and 800 with Atari not releasing much info originally for people to program them. The XEP-80 really needs to be figured out better so that it might be made more useful. Allan Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 10, 2009 Author Share Posted January 10, 2009 I'm assuming you checked Antic Online for any info on the XEP-80? I haven't, but I will. Thanks! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 10, 2009 Author Share Posted January 10, 2009 (edited) Got the status line working: I'm struggling to speed the thing up but it should be useable with the right keyboard buffer (it drops keystrokes without one). I'll build one into the program that doesn't buffer keys that are held down (the cursor tends to run away with itself if you hold it down), only individual keystrokes. This seems to be to be the most essential thing when typing quickly. There are a few nasty bugs I need to iron out, then I'll let folks play with the test version. The macro buffer and paste buffer will probably have to go into banked memory (this version also has the 25+K text buffer) because the graphics 8 screen ate all the main memory up! Note also that this version uses all the RAM under the OS ROM, so you're going to need the right DOS and at least 128K of RAM. Edited January 10, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
ClausB Posted January 10, 2009 Share Posted January 10, 2009 Looks very nice! I'm struggling to speed the thing up.... In ACE-80 I sped up scrolling by rearranging the display list instead of moving GR.8 data around. Feel free to borrow the technique or any posted code. See: http://www.atariage.com/forums/index.php?s...t&p=1496090 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 11, 2009 Author Share Posted January 11, 2009 In ACE-80 I sped up scrolling by rearranging the display list instead of moving GR.8 data around. Feel free to borrow the technique or any posted code. See:http://www.atariage.com/forums/index.php?s...t&p=1496090 Thanks! I think I'll use that technique, since every spare machine cycle counts. It'll be easy to implement too, since I'm already using a list of screen RAM pointers for each line of text (to speed things up: I just add X/2 to TABLE+Y and I have the address of the target byte). I'll just rotate that list along with the LMS addresses in the display list and no further modifications will be needed. The only block move operation during a scroll will then be of the 1,600 byte screen buffer which is used to check which characters have been changed during a screen re-draw (only the changed characters are re-drawn on the screen). If I scroll that up or down by 40 bytes as well, the refesh routine will automatically redraw only the top or bottom line. I'm also considering using an index table for the font data to save a few more cycles. The 80 column character set is 512 bytes long (64 8-byte cells, each containing two 4-bit wide characters side by side), so instead of adding CODE*4 to the base address of the font data, I'll divide CODE by 2 and use that as an index into a 64 byte table to get the correct bytes. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 11, 2009 Author Share Posted January 11, 2009 I've just fixed a bug which was causing the tab line to be redrawn on the screen after each keystroke. Result: the editor is much quicker. With a few more tweaks, cursor movement should be nearing the speed of the original 40 column version. It really is surprisingly quick. Just the display list scrolling and disk menu to implement and I'll have something for the testers. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 11, 2009 Share Posted January 11, 2009 I've just fixed a bug which was causing the tab line to be redrawn on the screen after each keystroke. Result: the editor is much quicker. With a few more tweaks, cursor movement should be nearing the speed of the original 40 column version. It really is surprisingly quick. Just the display list scrolling and disk menu to implement and I'll have something for the testers. Two or three more improvements and Microsoft will buy your program to avoid risks for Word! Awesome work. Quote Link to comment Share on other sites More sharing options...
twh/f2 Posted January 11, 2009 Share Posted January 11, 2009 On the 8bit Atari I'm only aware of one word processor which supported 80 columns while typing. It was called "S.A.M. Texter". It was part of Screen Aided Management "S.A.M.". The programm was okay, but it did not support realtime word wrap and was very simple editor all in all. But it was back in the time very very usefull. I remember that my Dad wrote CVs and job applications with that. I was a kid and usually printed my homework We had an East German printer "Robotron K6319" and only this yellow-brownish paper Once your tool is finished, I think it probably would be the most sophisticated word processor for the 8bit. And that in the year 2009... ... . . .. . still questionable if I would use today my Atari to print letters but why not? I mean I could use my AtariSIO-bridge and link to my laser printer .. how nice is that grtx, \twh Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 11, 2009 Author Share Posted January 11, 2009 (edited) Two or three more improvements and Microsoft will buy your program to avoid risks for Word!Awesome work. LOL! I hear Windows 7 is to have an Atari8 word processor built in... Thanks. Once your tool is finished, I think it probably would be the most sophisticated word processor for the 8bit. Thank you - I hope the finished product lives up to expectations. If you're hoping to see a full-speed, seamless implementation of The Last Word in 80 columns, you will not be disappointed. I only wish this had all happened twenty years ago, but I'm glad there's still such an active Atari8 community with which I can share my efforts. Only with the benefit of passing years, expert help from people on this forum, and hindsight has this project come to fruition. I'm only hoping I can get something released within the next couple of days - the proof is in the pudding, as they say. Edited January 11, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
spookt Posted January 11, 2009 Share Posted January 11, 2009 Thank you - I hope the finished product lives up to expectations. If you're hoping to see a full-speed, seamless implementation of The Last Word in 80 columns, you will not be disappointed. I only wish this had all happened twenty years ago, but I'm glad there's still such an active Atari8 community with which I can share my efforts. Only with the benefit of passing years, expert help from people on this forum, and hindsight has this project come to fruition. I'm only hoping I can get something released within the next couple of days - the proof is in the pudding, as they say. And I think I can safely say that the 8 bit community is grateful to all the coders such as yourself who continue pushing the machine and bringing us great new releases. Thanks! Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted January 12, 2009 Share Posted January 12, 2009 And I think I can safely say that the 8 bit community is grateful to all the coders such as yourself who continue pushing the machine and bringing us great new releases. Thanks! Amen to that!! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 12, 2009 Author Share Posted January 12, 2009 And I think I can safely say that the 8 bit community is grateful to all the coders such as yourself who continue pushing the machine and bringing us great new releases. Thanks! Amen to that!! Your kind remarks are appreciated! The motivation this forum has given me is incredible - if it wasn't for AtariAge and its members, the great ideas for new features would never have found their way into the program. The Atari8 scene seems more alive today by virtue of emulation and the online community than it did in the dying days of New Atari User magazine in the late nineties. The way the program is going, it looks like it might be possible (eventually) to flip dynamically betwteen 40 and 80 column views of the same document (the beta version won't be able to do this, though). I feel this would be useful when writing macros, as defining a special character set for macro editing on a 4x8 grid might prove difficult. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 12, 2009 Author Share Posted January 12, 2009 (edited) Here's a short video of some simple text editing and scrolling: LW80.wmv I'll keep quiet now until the beta relase in a couple of days' time! Edited January 12, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Allan Posted January 12, 2009 Share Posted January 12, 2009 Here's a short video of some simple text editing and scrolling: LW80.wmv I'll keep quiet now until the beta relase in a couple of days' time! WOW! Allan Quote Link to comment Share on other sites More sharing options...
spookt Posted January 12, 2009 Share Posted January 12, 2009 Good grief that looks fantastic! Can't wait! Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted January 12, 2009 Share Posted January 12, 2009 Here's a short video of some simple text editing and scrolling: LW80.wmv I agree. Just fantastic.. Can't wait, which DOS were you using for the capture. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 12, 2009 Author Share Posted January 12, 2009 (edited) Can't wait, which DOS were you using for the capture. Funnily enough I was in Atari800Win Plus (with SpartaDOS 4.22) at the time and I tried the video capture but I couldn't get it to work. The screen just went black, and the resulting video was the same. So I fired up TechSmith's Snagit screen recorder, framed the emulator window and pressed record. I just ran the 10MB AVI that it produced through Windows Movie Maker. I've been thinking that the core 80 column code from LW could be modified into a high speed generic 80 column driver, patched into E: or SDX's CON device... that's for another day, though. Edited January 12, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
ClausB Posted January 12, 2009 Share Posted January 12, 2009 I've been thinking that the core 80 column code from LW could be modified into a high speed generic 80 column driver, patched into E: ... That's what ACE-80 is. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 13, 2009 Author Share Posted January 13, 2009 I've been thinking that the core 80 column code from LW could be modified into a high speed generic 80 column driver, patched into E: ... That's what ACE-80 is. Indeed so! My 80 column system owes a lot to the excellent ACE-80 (especially the DL scrolling), but owing to the buffering techniques used in LW, I'd be interested in writing a handler to to see how fast it runs without the considerable processing overhead of the word processor's "background" screen refresh routine. Before mapping characters to the graphics 8 screen, LW first compares the character to be written against an 80 column character buffer and only maps the character if it's different to the one in the buffer. This requires absolute synchronisation of the character buffer and the graphics screen, but means that programs which regularly do direct screen updates (such as the SpartaDOS MENU.COM program) could really fly. Of course you could achieve the same effect in ACE-80 by "vetting" application calls to the character print routine, but I'd like to see what happened if the flitering took place at the OS level. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 13, 2009 Author Share Posted January 13, 2009 (edited) On closer inspection of ACE-80's source code, I see that it does indeed use a "vetting" technique so that only the changed characters are written to the screen. Great minds think alike! ACE-80 is probably as fast as a software 80-column console driver could be. Edited January 13, 2009 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
yorgle Posted January 14, 2009 Share Posted January 14, 2009 Wow! I can hardly wait! THANK YOU for your work develping this. With an efficient 80 column display, I may actually start using my 1200XL to type letters at my office just for fun. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.