Jump to content
flashjazzcat

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

Recommended Posts

I'm not far from finishing the 80 column version of LW. Here's a screenshot of the first working test:

 

post-21964-1231583759_thumb.png

 

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 by flashjazzcat

Share this post


Link to post
Share on other sites
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 by twh/f2

Share this post


Link to post
Share on other sites

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. :ponder:

Edited by flashjazzcat

Share this post


Link to post
Share on other sites
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. :ponder:

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

Share this post


Link to post
Share on other sites

Got the status line working:

 

post-21964-1231614483_thumb.png

 

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 by flashjazzcat

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. :D 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.

Share this post


Link to post
Share on other sites
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. :D 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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 by flashjazzcat

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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!!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by flashjazzcat

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by flashjazzcat

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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! :D ACE-80 is probably as fast as a software 80-column console driver could be.

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites

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.

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...