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

  1. Posted

    I emailed both websites about replacement keyboards on Monday, but no replies yet. :sad:

     

    All of these stereo / pokey boards that also have 'aki' can allow you to use an external PC keyboard.

     

    Then hide the computer. :)

     

    I'm thinking of going that way with 1200xls where the keyboard fix doesn't work.

     

    But if you really want a keyboard, I'd try calling Best (maybe your in a spam trap or something). They answer the phone and they tend to ship the same day...

    Yep - there was an email in my inbox from Best today. Total cost for a new keyboard, including the cheapest postage, is around £38. I guess that's much cheaper than a new machine - bearing in mind there's nothing wrong with the case and motherboard - so I might go for that. If I'd been going for a new machine I would have been upgrading the RAM straight away. I'm still considering boosting the RAM on the existing machine. It's a 65XE with the extra 64K fitted to the motherboard in the empty slots. Not sure how to proceed to bring it up to something like a 320XE. Will have to investigate; maybe use the cash I'd have spent on a new machine on a decent memory upgrade instead.

  5. Posted · Edited by flashjazzcat

    Ok. Btw, I edited a few more comments in my post above, but I'll restate here.

     

    QUOTE

    As an aside, an add-in starts with a vector table (after the usual six-byte binary header) to its own routines, which the main program inspects and hooks into when the files are loaded. There are hooks for the editor, print formatter, and disk menu.

     

     

    Hmmm. The description you gave sounds like they are 'replacements for' rather that add-ins. By 'hooks' do you mean a 'call this instead of that' type hook or a 'call this in addition to that' chained hook?

     

    I assume that the ability to see the internals ( such as the line list, etc.) would be available, either as hard locations or ( much better ) as offsets to a symbol. A query function on your side could allow the name of a symbol to be passed in and would return an address. This very important step isolates you from breaking add-ins by changing your code. The query function itself would have to remain static, but you would be free to change other things.

     

    On the add-in side, there should be a standard 'start-up' and 'shut-down' vector in the table so that you would always call a particular entry for startup and one for shutdown. Add-ins also should be able to register for things, like a 'call me when a keypress happens' or 'call me when a print is requested' but that may be a bit much to ask.

     

     

    We can talk more about this offline or in another thread, I don't want to hold you up or distract you now. Feel free to PM me later.

    The "hooks" are additions rather than replacements. The add-in format (as it stands - but I'll change it if need be) starts with a number of 16 bit pointers. If they're null, LW ignores them. If a pointer is the address of a routine in the add-in binary, however, LW will JSR through that vector everytime the appropriate key is pressed or formatting character is encountered. At the moment, two (unused) editor keys and six formatting characters have "slots" in the vector table. If I recall correctly, there's also an "init" vector will will be executed as soon as the add-in is loaded. I'll add one for a macro command, and anything else I can think of.

     

    As for symbols and absolute addresses: in previous versions of LW, add-ins called routines with absolute addresses. Clearly this will break the whole system when the code changes (as you point out), but at the time I didn't have the code space to implement anything better. Now that I've freed up space, however, I've placed a vector table at a fixed point in LW's executable. The table has entries for all LW's commands and utility routines (print message, move memory, etc), followed by the variable table and various buffers. These tables will be padded out with null bytes (for future expansion) and will never be moved. This way, we at least get some of the security of a symbol system, without the overheads (an SDX-type symbol system would be nice but it would be overkill in this instance: code will still be quite readable if the vectors are accessed using named labels in assembler).

     

    The idea of "registering" is excellent; hopefully the liberal use of hook points at likely points of interest will achieve the same effect. Once again, the add-in header has spare entries, in case additional hook points are added in the future.

     

    Hopefully add-ins will warrant a thread of their own if people are interested in writing them. In any case - feel free to contact me if you want to exchange ideas over the next few days (before the add-in system is finalised). You have some good ideas which I'd like to incorporate into the program, space permitting!

  6. Posted · Edited by flashjazzcat

    Sounds great. Any info at all would be enough to get me started...maybe if you have an example you could send me the source code? If not, I'll just wait for docs.

    None of the current add-ins (which I have source code for) will work with the new version, so I'll have to at least prepare some brief documentation. Hopefully I'll have something you can make a start with by the weekend. Roughly speaking, though, add-ins need to reference a large jump table at a fixed memory location, and will be passing arguments mostly via page zero pointers. In assembler, I envisage a calling procedure along the lines of:

     

    INSCHAR = $21
DELCHAR = $22
UMOVE = $23
JUMPTABLE = $8000
...

START:
LDA #$9B; END OF LINE
LDY #INSCHAR; LOAD WITH # OF INSERT ROUTINE
JSR CALL

...

CALL:; PASS Y REGISTER WITH # OF ROUTINE TO CALL
PHA; SAVE A
TYA
ASL A
TAY
LDA JUMPTABLE,Y
STA VECT+1
LDA JUMPTABLE+1,Y
STA VECT+2
PLA; RESTORE A
VECT:
JMP $FFFF
;

    ...or something like that. Things may become more complicated if LW's internal routine expects an argument to be passed in the Y register... :ponder:

  7. Posted · Edited by flashjazzcat

    Add-ins? Do you have any interface details about them? I'd be happy to write an API for people to use in the various popular atari languages.

    I will have interface details as soon as all the equates are finalized. Clearly this will be a fairly large job since I'll have to document all the calling parameters for LW's internal routines as well as their addresses so that the add-ins can call them properly. However, the equates will never change once documented (even if the program itself changes). Any language which produces a stand-alone, unsegmented binary module at a fixed address will be capable of producing add-ins for LW. A good API would make the job a whole lot easier for interested parties so I'd be happy to take you up on your offer once I've documented everything. :)

     

    As an aside, an add-in starts with a vector table (after the usual six-byte binary header) to its own routines, which the main program inspects and hooks into when the files are loaded. There are hooks for the editor, print formatter, and disk menu.

     

    ...flipping between 80 and 40 columns is working well - thankfully I only have one version of the program to worry about now!

  8. Posted · Edited by flashjazzcat

    You might consider a config file, ie., a config.sys style item to control startup capabilities so that you dont have to come up with arcane key combos and so forth. I am assuming you havent already done that, so forgive me if you have.

    Not at all - I absolutely agree with you! :) LW already has the LW.CFG configuration file, which you can edit using the separate config utility. All user-preferences are saved in this file, but only some can be set (and saved) within the word processor itself. Setting screen colours isn't something that can currently be accomplished in situ, but because the 80 column text often requires experimentation with screen colours in order for it to be readable, I feel it should be possible to alter the colours from within the main application (you'll then be able to save the colours so that they are the default). One obvious solution is to write a machine code add-in, which will allow the user to set various parameters in the program. The add-in can then be discarded (or overwritten by another add-in). The latest (forthcoming) version of LW is going to make it much easier to write add-ins, and their scope is virtually unlimited (the old version of LW had an add-in which acted like the auto-correct function in Microsoft Word).

     

    Re my earlier comments about switching between 40 and 80 column modes: I now feel this should be possible, and this will mean there will only be a single version of the program as opposed to two.

  11. Posted · Edited by flashjazzcat

    Yes, please, please do this. Keep up the great work/ :)

    Thanks - I'll try! :) The massive re-write is mostly done now; hopefully I'll be able to find a spare key combination or two to permanently map colour changing capability to the keyboard. If not, it will go on an add-in. Non-English users will be pleased to hear that it's now possible to remap the entire keyboard if you don't like the default key assignments (I haven't written a key map editor yet, though). This includes all the SHIFT+CTRL key combinations (which now send inverse control characters to the editor rather than raw keyboard codes). The internal functions of the program are mapped to the ASCII codes so redefining the keyboard won't mess up the macro commands. This also means there are no SHIFT+CTRL commands that macros can't call now. And on the subject of multi-language support, I'm not far off designing a system that will allow all the prompts and key responses in the program to go into a resource file; hopefully I'll be able to recruit a few volunteers to write resource files in different languages when I get around to implementing this.

     

    Oh... and the Exit to DOS bug is fixed. I wasn't re-instating the OS before jumping through $0A. :ponder:

     

    Another thought... having the program dynamically switch between 80 column and 40 column views may be too much of a headache. I'm thinking of making two distinct versions (although even that will involve a fair bit of work since because the program has changed so much, I'll have to downgrade the 80 column version to a 40 column variant rather than bring the existing 40 column version up to date). The 80 column version is running very well, though: I've just implemented the extended RAM routines and they work great so we should have a beta out in a few days.

  12. Posted · Edited by flashjazzcat

    You could try Best They are American but have pretty much everything you could need. I have bought from Bradley a few times and his service is excellent

    You could also try B+C again I have bought from Bruce and Cathy on numerous occasions and they have very good service. B+C sell PAL 130XEs New for $60 but I think they have the faulty GTIA chips.Or they sell at $95 the "good" ones.

    Thanks for those links! I think the site I remember was a different one, but those two look just as good. :)

     

    They have querty keyboards here:

     

    Best Electronics

     

    For $36, that looks to be what I'm after, since it's primarily the keyboard which is looking a mess. I'll get in touch with them.

  13. Posted

    I wonder if someone can help me... A few weeks ago there was a topic with a link to a large Atari website which had second-hand equipment for sale. Try as I might, I can't locate it again. The site may have been American - not sure - but one of the pages had a large unillustrated catalogue of Atari systems and prices. I thought it was called Atari Vintage Computers or something but I can't find it using Google. I'm looking around for a new 65XE or 130XE bacause the case and keyboard on my upgraded 65XE are looking pretty shabby. I think there would be a definite market for someone producing moulded shell casings and keys for old systems like these; as we know, the plastic suffers terribly from prolonged exposure to sunlight.

  15. Posted

    My 65XE (expanded to 128K) was recently retrieved from a box above my old wardrobe after a nine year absence and now I've got it set up next to a grey LG LCD TV, it's looking decidedly yellowed. The keys are the main problem, and clearly show more yellowing where the sunlight used to hit them when the computer was situated in the same position for several years. The other day I decided to try cotton buds soaked in nail polish remover on the keys. This has the effect of taking off the top layer of plastic, and will - with considerable patience and care - remove most of the yellowing, reducing the plastic to a rough, matte finish. However, rubbing too hard will definitely take the print off the keys. I only tried this on a couple of keys and one console key. I'm wondering if T-Cut (car paint polish) might be a better bet???

  16. Posted · Edited by flashjazzcat

    The foundations for a good emulator seem to be present here. Numen has some of the things I'd really love to see in Atari800Win: a clear, uncluttered full-screen mode and a scaleable windowed mode. The GUI is among the smoothest of the Atari emulators I've seen under Windows... sadly the emulation is lacking. For example, I just tried LW80 and the whole status bar is missing. Promising is the word for it. Let's hope the author continues to develop it, and responds to feedback. Active emulator development is to me as important as continued hardware development for the Atari 8...

  18. Posted

    Pin has also mentioned some display-color-setup. In the 80-column mode text sometimes becomes unreadable se setting the colors may be handy.

    Yep - this can be accomplished with the config program but I could write an add-in for "in situ" alerations to the screeen colours. I didn't have high hopes for the clarity of the display through s-video on my LCD TV, but white on blue, black on white and white on black all look pretty readable, especially if I ramp up the "sharpness" setting on the TV. White on black or blue won't look so good on all sets, however, so black text on white or light green on dark green is probably the best scheme in those cases.

  19. Posted

    I've got all the kit I ordered so I can now test LW on a real machine prior to release. It's amazing to see the 80 column WP running on the little Atari. :) There's still lots of work to do on the program, as I've decided to make the macro buffer and add-in buffer separate (therefore you can mix and match add-on programs and macros at will during an editing session). I'm also going to rewrite the keyboard handler so that it will be possible totally remap the keyboard by loading an altered 256 byte index.

  20. Posted

    Finally got my composite cable today, so I hooked the 130XE up to the s-video in on the LG LCD TV, copied my 16MB hard disk ATR onto an SD card and put it in the SIO2SD, powered up and everything worked perfectly! The latest version of LW80 runs great on the real Atari with the SpartaDOS 4.17 cart. I may have to buy a flash cart so I can run one of the later versions. But the SIO2SD is a fantastic device. I can't wait to get even more stuff copied across from my old Atari disks (especially all my old Turbo Basic programs, including a font editor and database, and all the University assignments I wrote on the Atari - including my dissertation!).

  22. Posted

    Ooh - I will have to download it this way. I am pretty sure the last WP I downloaded for the little 8 was TextPro 4.5.

     

    Stephen Anderson

    I don't think there have been many since Textpro 5.2, and that was way back in the early nineties! TextPro was always my other favourite word processor, though.

  23. Posted · Edited by flashjazzcat

    As part of the reorganization of LW80's memory map, I have redesigned the way the program interfaces with the 80 column system to the point at which it could become virtually device independent, which is to say any device which can output a character at X,Y on the screen could be made to work with LW (previously the screen updates were tightly entwined with the core code of the word processor). This means support for XEP-80 and other hardware or software screen drivers will be MUCH easier to implement in the future.

     

    I should have a beta version ready for the weekend, which will include extended RAM support, a built-in keyboard buffer (which will switch itself off if the SpartaDOS or any other system-wide buffer is installed and active), and a large main text buffer. Multi-language support is still something I'm thinking about, subject to space constraints. It would probably require a resource file, which I'd rely on other people to author in the relevant languages.

     

    I'm still waiting for my composite video cable, and when that arrives I'll be able to do some testing of my own on a real Atari 130XE. :D

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...