Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

flashjazzcat

Members
 View Profile  See their activity

  • Content Count

    17,025

  • Joined

  • Last visited

  • Days Won

    25

Posts posted by flashjazzcat

  2. Posted

    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! :)

  3. Posted · Edited by flashjazzcat

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

  6. Posted

    Would be great if you could post some of your software out on one of the active Atari BBSES (such as Mousnet bbs) so that those of us still using Modems and Atari A8's can download some of your software. Thanks!

    I'd be happy to! I've just visited Mousenet BBS, though, and it's unclear how to upload files or contact the admin (I've never used a BBS before).

  7. Posted

    The program is amazaing! I'm sitting here in front of a 15 inch screen with my 800XL connected over RF (yes I can't be bothered to unplug the kid's Playstation from the Scart socket right now) and there is perfectly readable 80 column text with zero flicker in front of me :-o

     

    OK 2 small "features" not listed above that I've seen:

     

    1) Print preview stayed in the window after I went back to the editor. This was with a very small amount of text in the editor window. The preview text was visible in the lower part of the window.

     

    2) I need to hit reset after a quit since it leaves a screen full of "snow" behind.

     

    Minor, minor things but I thought you might like some feedback since you didn't list them.

    Thanks! The "snow" is a known issue which I forgot to list; it sometimes goes away after a couple of seconds, sometimes not. It needs fixing. The print preview problem is a new one on me. Hopefully my SIO2SD will arrive soon and I can test the program on my 130XE (the 80 column version was entirely designed under emulation).

     

    This kind of feedback is exactly what I wanted. :) The original program went through a huge amount of testing and once the NTSC bug was fixed it was reasonably bullet-proof. I want this one to be the same...

  8. Posted · Edited by flashjazzcat

    Garage door fixed! I immediately booted up LW and though I've only typed a few sentences on it, I must say this is absolutely the best thing I've seen yet for the 8bit! I love the title screen. The font looks great. One interesting thing-- once the program started both the L1 and L2 lights on my 1200xl lit and stay lit. Hopefully, I'll have some time later tonight to really get into it. Again, FANTASTIC WORK!!!!

    Great! And thanks. :) The 1200XL lights must be to do with the PORTB mask used to select the main text bank; I'll look into that. As long as you're using the hastily fixed second upload, otherwise the cursor comes to a halt after you've typed a screenful of text. :ponder: I'm glad you like the title screen. I've been trying to design a new one using a 1-bit bitmap on the PC with true-type fonts but I can't come up with anything that looks as good as the original.

     

    A couple of general tips particularly relevant to speedy use of the 80 column editor: use the SHIFT+CTRL+UP and DOWN arrows to quickly move up and down the document by a screenful of text. CTRL+A moves to the start of a line, and CTRL+Z moves to the end of a line. CTRL+D opens up the disk menu, and CTRL+V opens a print preview.

     

    Sorry I haven't included help screens with this version, but they'll need to be completely redesigned for the new display. Pretty much everything in the original manual still applies, though.

  9. Posted · Edited by flashjazzcat

    I was supposed to fix the garage door opener today. Forget that! :D
    You realise this means I'm not going to get anything done this afternoon don't you ;)

    I've been getting a lot of hassle lately from my wife over the length of time I'm spending on the PC! :D

     

    There was a nasty bug which prevented the cursor getting past the end of the screen in the original upload which I've just fixed, so please download again:

     

    http://www.atari8.co.uk/downloads/LW80TEST.zip

     

    Anyway, now that's fixed, a bit more information about this release (I was in a hurry uploading it at lunch time, as you can probably tell)...

     

    Firstly: this version RUNS UNDER THE OS ROM, so won't work with SpartaDOS 3.x, DOS-XE, SDX using OSRAM, or any other DOS occupying $C000-$FFFF.

     

    Many features are incomplete or known to be buggy.

     

    Known bugs:

     

    • The print routine outputs the page number at the extreme left of the line preceding a header or footer containing a page number reference.

    • Tagged files on the disk menu don't show up properly.

    • The status line is subject to corruption after an aborted print preview.

    • The filename input routine leaves an extraneous cursor character behind after return is pressed.

    • The disk menu often has screen corruption when first called up.

     

    Incomplete features:

     

    • The disk menu filename buffer is small and not subject to bounds checking yet. Cataloguing more than a screen full of files will likely crash the program or cause screen corruption.

    • Extended memory text banks are not yet implemented (actually disabled until everything else is done).

    • There is no built-in keyboard buffer; characters will be dropped unless the SDX buffer is active. LW will eventually have its own key buffer which won't buffer auto-repeat keys.

    • Horizontal scrolling is not properly windowed yet (test it with SHIFT+CTRL+W and set with width to 240 characters).

    • The option to store the paste buffer and file catalogues in an extended bank isn't implemented yet.

    • The memory needs totally reorganizing and tidying up.

     

    No doubt there will be many more problems to fix...

  11. Posted · Edited by flashjazzcat

    Excellent work! The possibilities are endless here. Could prove useful for an 80 column "flickerterm" type display: in theory, you could have 80x48 character cells...

    You could do that, but it would make the flicker twice as bad. Flickerterm alternates between even and odd columns every video frame. Interlaced video alternates between even and odd rows every video frame. To get solid interlaced characters on a Flickerterm-type display, you'd have to display each column for two frames at a time instead of one. This would suck.

    Yes it would... "Flickerterm" was the wrong way to describe it. What I was actually thinking was using only the horizontal interlacing with something like the ACE-80 system or LW80, which run in graphics 8. I think that would work well, providing we could still use a dynamic display list for scrolling, etc. :)

  12. Posted · Edited by flashjazzcat

    Is there an easy way of porting a bitmap design from, say, Photoshop to the Atari so it could be converted to a graphics 8 screen?

     

    Yea. Just save your photoshop file as a 1-bit bmp. Then write a short conversions program in BASIC or whatever.

    Thanks - I think that's the technique I'll adopt. I've looked into what bytes to skip in the BMP header, so I should have no problems.

     

    I'll definitely release a beta version tomorrow. :D I'm fairly happy that the core code works, and apart from the macro buffer and paste buffer (which still need somewhere to live), most of the remaining work is cosmetic (such as altering the display list during VBLANK to avoid screen glitches, making the print preview screen white, etc). Actually I wasted best part of a day's work debugging the disk menu after changing it to be faster with the 80 column display. There are a few lingering gremlins, too, which might have more to do with the OS banking than the 80 column display, but hopefully these will be tracked down during testing. And on a positive note, the executable has actually shrunk slightly.

     

    Here's a shot of the disk menu showing a folder with sixty files in it:

     

    post-21964-1232133880_thumb.png

     

    I think the 26K main text buffer will have to be reduced in size to make way for the macro and paste buffers: ultimately I'll add the option to house these in an extended bank, but the test version won't include this facility. I'll also add the option to display full SpartaDOS style directory listings eventually...

  14. Posted

    It also would be nice to buy this program in a beautiful box like Yoomp! or Hobgoblin.

    Perhaps GR8 Software could do the packaging.

    I'm thinking of designing some kind of logo for the program to incorporate into the splash screen (eventually - lots to do before that happens). Is there an easy way of porting a bitmap design from, say, Photoshop to the Atari so it could be converted to a graphics 8 screen?

     

    The coding's going slowly today, but the "view file" and disk utility screen is just about done. I'll take a break this evening and hopefully cover a lot more ground by Saturday. There's a bug which is knocking the document line number out of sync when scrolling upwards; that's hard to trace because the program builds a list of line lengths when scrolling down through the document which is used when scrolling back up again. Then there's the added problem of the macro buffer having to move: if it's not at a fixed location any more, binary add-ins won't work. I think the version I'll release on Saturday will be a bare-bones editor designed to check that the core code is bullet-proof. I can add the niceties later on...

  15. Posted · Edited by flashjazzcat

    You ought to consider setting up a paypal donation page. I always feel better using stuff that someone really worked hard on if I have a chance at least to offer some small token. It's important for the community.

    I've been thinking the same thing myself. I'm sure I could have sold The Last Word back in the day but by the time I wrote it in 1999 I realized it had to be regarded as a labour of love. Nevertheless, donations would certainly encourage me to keep going, and would help with hardware acquisition (I've just ordered an SIO2SD :)).

     

    I plan on using the hell out of this fine software.

    Good! That's what it's for and the best motivation for me to keep going is the fact that people are interested and want to use the program.

  16. Posted · Edited by flashjazzcat

    I'm happy with the memory detection routines, the scrolling is now working beautifully apart from a couple of minor glitches... you will like the disk menu, which now displays 80 filenames in a four-column scrolling list. The cursor co-ordinates on the status line now refer to the line number in the document rather than the row number on the screen (useful for those who want to use LW as a program text editor: set the display to 200 columns and you'll have line numbers on a horizontally scrolling 80 column display - like XEDIT but in 80 columns; I'll carry the line number feature over to the 40 column version as well as it's pretty handy). Print preview will now be displayed on the normal 80x20 window in the usual scrolling format, but will be faster. There'll be the option to have a 16K main text bank with the paste and macro buffers between MEMLO and $3FFF, or paste and macro buffers sharing an entire extended bank between them, leaving more than 25K for the main text bank, plus up to nine extended 16K text banks. :)

     

    I'm wondering what to call it... LW80? A new splash screen would be nice, too.

     

    Anyway, I'm working hard to get something ready by Friday. :D

  20. Posted

    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.

  21. Posted · Edited by flashjazzcat

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

  23. Posted

    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.

  24. Posted · Edited by flashjazzcat

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

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...