flashjazzcat
-
Content Count
17,025 -
Joined
-
Last visited
-
Days Won
25
Posts posted by flashjazzcat
-
-
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.
-
I'm assuming you checked Antic Online for any info on the XEP-80?I haven't, but I will. Thanks!
-
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 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.
-
don't take me too seriously as all info is dated 1997/98!!! (Man...why did I not setup my own start up and went public and got riiiiiiich....
)Lol!
Okay, I've been testing my routine some more and I still can't replicate the errors that other people have reported but I'll keep at it. It's certainly close to being finished. The problems with the SDX cart were limited to 4.21 and 4.22. For some reason, direct access to some of the bigger extended RAM upgrades using my routine was fouling up the filing system. I don't think these versions of SDX like bits 7 or 1 of PORTB being altered when the library is disabled with the X command. Later versions of SDX don't have this problem, but I wanted to preserve support for all versions, so I'm using my routine unless SDX is detected, in which case I use this one:
; OFFSET = $014E START; SPARTADOS X RAM TEST LDA COMTAB SEC SBC #< OFFSET STA XRPTR+1 LDA COMTAB+1 SBC #> OFFSET STA XRPTR+2 LDY #$1D LDA (COMTAB),Y STA NBANKS DEY LDA (COMTAB),Y STA EXTBITS LDA #0 STA BANKS SDXRLP LDY NBANKS DEY STY NBANKS BMI SDXIT TYA AND #$03 ASL A ASL A STA TMP1 TYA LSR A LSR A TAX XRPTR LDA $FFFF,X ORA TMP1 EOR PORTB AND EXTBITS EOR PORTB LDY BANKS STA BANKTABLE,Y INC BANKS BNE SDXRLP ; SDXIT RTS ; EXTBITS BYTE 0 NBANKS BYTE 0 BANK BYTE 0 BANKS WORD 0 BANKTABLE DS 64
This routine was adapted from a translation of the Polish SDX programming docs kindly provided by drac030, and works well. It relies on the fact that SDX has its own table of PORTB masks in the user-accessible data table. I did notice that SDX 4.21 and 4.22 themselves don't recognize some of the bigger RAM upgrades properly either. LW will, however, go along with whatever SDX reports since I don't want to risk crashing into any banks used by the OS. All other operating systems should work well with the earlier routine, including SpartaDOS 3.x. Anything other than SDX will require the user to state how many of the available banks to use, however; this is to save the program having to look for and avoid RAM disks, etc.
-
Another strange problem: my detection routine works fine in SDX 4.22 (AtariWin800 emulator) with or without the X command, but when appended to the LW executable in the init routine at $3000, SDX crashes after an exit to DOS.
More specifically, if my detection routine is loaded with the X command as the first segment at $3000 of a larger executable, it works fine (subject to errors). However, after the application exits to DOS, any subsequent attempt to run an application with the X command results in a jump back into corrupted application code. Clearly this routine is screwing up the X command, but I can't see how. Must be something to do with the way it switches BASIC in and out, but the same routine doesn't cause a problem when the routine is a standalone app... weird.
Also, RAMBO 256K upgrade reports 16 banks in SDX and 8 banks in SpartaDOS 3.2G with my routine. Really weird... it's totally OS independent.
-
Thanks for writing this utility.Unfortunately I had 3 problems
1) There is something odd about your ATR. DOS 2.0d could read the directory but not load the program.
2) After recreating your ATR, your program would now load but immediiately following the display of the bank information the screen clears and the DOS menu appears.
The problem occurs with both Atari DOS 2.0d and MyDOS 4.53
3) With SpartaDOS 3.2g your program runs fine BUT it mistakenly detects 15 banks (83, 8B, 8F, A3, A7, AB, AF, C3, C7, CB, CF, E3, E7, EB, EF).
My memory upgrade is a Wiztronics 256K (total RAM) which I believe is a Rambo XL type. There are only 12 banks.
I'm not 100% sure but I believe banks 83, 8B, and BF are not part of this upgrade.
- Steve Sheppard
Sorry about the problems with the ATR: I'll upload another version since I have a feeling I may have accidentally created a MyDOS formatted image.
Also, I meant to point out that the program works best with SpartaDOS because of the screen clearing problem. Again, this will be rectified in the next upload.As to point 3), there's clearly a problem there so I'll go away and test it some more. Does XRAM report your memory correctly? Thanks for the feedback - I can't make this work without bug reports!
Witazije polish coders! Try using extended memory in this way...(special message to Coders of VENT and JOURNEY)Let me give Tamas Bene of HARD the keyboard...
Wow... thanks for the very copious information. It's going to take me some time to digest all of that, but hopefully it'll result in a working program. Universal RAM detection is something of a subtle problem, it would seem...
It should also be said that in my routine, the RESTORE loop should run backwards (with the X reg starting at $FF) in order to properly restore the main bank. That just occured to me last night.
I thought I had this sewn up... clearly not!
An even simpler way would be to let the user configure the number of memory banks and the actual $d301 values he want to use. For example, the ramdisk in DOSes like TurboDOS and MyDOS work in that way. Other example is the excellent game The Brundles by KE-Soft.LOL... this is the way The Last Word worked before I got requests to make it auto-detect RAM upgrades. Maybe I should go back to that!
On the other hand...Hello AndreasAlas, this "bug" is a hardware problem and afaik cannot be avoided or solved with software...AFAIK all RAMtesters store different values in each bank and compare them. Same value means same bank. If main memory is compared with banked memory in the same way, these upgrades (64kB + 192kB instead of 64kB + 256kB) should return the same values for both main and part of extended memory. So it is possible to detect them.
greetings
Mathy
...I agree. It must be possible to write a catch-all routine.
-
I was getting lots of people reporting errors with LW beta 2.2's extended RAM detection routine, which was adapted from the "SmartRAM" RAMdisk driver and therefore unable to correctly detect several more modern memory upgrades. I decided to have a look at the XRAM utility with a disassembler and there's a section of code in there like this:
ldx #0 txa clearloop: sta banktable,x inx bne clearloop testlp1: stx PORTB stx $4000 txa clc adc #4 sta $4001 inx bne testlp1 testlp2: stx PORTB ldy $4000 tya clc adc #4 cmp $4001 bne notsame lda #$FF sta banktable,y notsame: inx bne testlp2 rts
This appeared to build a table "banktable", with $FF in locations corresponding to a portb value which resulted in a bank switch. However, I built a test program around it and the cmp $4001 always came out false so the routine never worked. To be honest I'm unclear about how it's supposed to work. Clearly it works in XRAM, so I'm obviously not following the logic of the algorithm properly. Anyway, I sat and thought about it for an hour and then came up with something I could understand.
; Expanded RAM test ; INCLUDE D:STDIO.INC ; *= $3000 ; START: SEI LDA NMIEN; TURN OFF INTERRUPTS PHA LDA #0 STA NMIEN LDA PORTB PHA ; LDX #0 TESTLP1: STX PORTB LDA $4000; SAVE MEMORY STA SAVETABLE,X LDA $4001 STA SAVETABLE+256,X TXA STA $4000 CLC ADC #4 STA $4001 INX BNE TESTLP1 LDY #0 TESTLP2: STX PORTB CPX $4000 BNE NOTSAME TXA CLC ADC #4 CMP $4001 BNE NOTSAME TXA STA BANKTABLE,Y; ADD TO TABLE INY NOTSAME: INX BNE TESTLP2 DEY; IGNORE MAIN BANK ($FF) STY BANKS; # EXPANDED BANKS IN Y ; LDX #0 RESTORE: STX PORTB LDA SAVETABLE,X; RESTORE OLD VALUES STA $4000 LDA SAVETABLE+256,X STA $4001 INX BNE RESTORE ; PLA STA PORTB PLA STA NMIEN; RE-ENABLE INTERRUPTS CLI ; JSR _PRINTF BYTE "%d extended banks",155,0 WORD BANKS ; LDA BANKS BEQ ALLDONE LDA #0 STA BANK DISPLOOP: LDA #< BANKTABLE CLC ADC BANK STA MASK LDA #> BANKTABLE ADC #0 STA MASK+1 JSR _PRINTF BYTE "%02x ",0 MASK: WORD $FFFF INC BANK LDA BANK CMP BANKS BCC DISPLOOP ; ALLDONE: RTS ; BANK: BYTE 0 BANKS: WORD 0 BANKTABLE: DS 256 SAVETABLE: DS 512 ; INCLUDE D:PRINTF.INC ; END START
This builds a table (banktable) of portb bitmasks, one for every 16K bank in the system. The non-destructive routine writes two unique test values to $4000/$4001, then loops through again to check for them. The last value in the table is always $FF, which is just ignored. The program also displays the number of extended banks and a list of all the portb values. I've tested this with every memory upgrade emulated by Atari800Win and it's worked every time (or should I say the output corresponds to that of XRAM).
The advantage of this method is that it should work with every conceivable memory upgrade for the Atari8. Apologies if this is nothing new to some people, but I've been stuck on this problem for ages and I thought it might be of interest to programmers.
I've also included a disk image of the program, along with source code:
-
Very cool - how hard was it to get back into this code after such a long long time away? I forget stuff that I am doing down at work after just a few months! Course, I still remember tons of the Atari error codes and RAM locations.Stephen Anderson
Yeah - I'm absent minded with everything but programming, I think!
A couple of months ago, when I got the Atari back after nearly ten years, I wondered how hard it would be to get back into things, but strangely enough it's like I was never away. I really hammered the programming back in the nineties, though, and having spent several hundred hours on the word processor alone, the 6502 op codes, Atari memory map, SpartaDOS commands, etc, must be hard-wired into my brain. I only wish I knew the PC inside out the way I feel I know the Atari8 - perhaps I could make some money then! I actually think I prefer the emulated platform now, certainly for programming. In any case, I find programming the Atari8 as addictive now as I did ten or more years ago - nothing's changed! -
Well I have it almost working.I have the emulator running an NTSC 130 XE using the SDX 4.42 cart image. If I turn on the XEP80 and then type XEP80.SYS I get a display in the XEP80 window:
However I can't do anything useful with it as when I hit return the cursor scrolls forever.
I'll try making a config.sys file later to see if it makes any difference.
BTW - by default Atari800MacX connects the XEP80 to Joystick port 1. You can change it to 2 in the Preferences.
That's more or less the best I can get; just some fragmented text but no cohesive output.
-
Just tried 4.42 in NTSC and it still doesn't work. I can't coldstart the emulator with XEP80 switched on, either. There were a few characters on the 80 column screen, but no output when I hit any keys.Aha, but you didn't try on real machine? Then there must be something wrong with the emulator, I think.
Absolutely - I didn't mean to suggest this is down to a bug in SDX 4.42.
Sadly I don't have real XEP-80 or SDX 4.42 hardware, so I rely on emulation prior to releasing betas which people can test on actual machines! -
I've been busy trying a few different enhancements with LW, with varying degrees of success. I had a go at writing a virtual memory mapping system for extended RAM banks that mapped a 32K buffer onto 2 extended 16 banks, but the extra processing made the screen refresh really sluggish. Hardly surprising, given that a simple page-zero indexed load instruction was replaced with a JSR to a routine which calculated the actual memory address using bit tests and masks and switched the appropriate extended bank in and out again. For the time being, then, I've proceeded with a version very similar to the existing release, but which resides under the OS ROM and under SpartaDOS X provides a 27K main text buffer, plus access to additional 16K banks on extended machines. The macro buffer has increased in size from 1K to 2K, and the cut and paste buffer is now fixed at 4K. Not much else has changed yet; I'm investigating XEP-80 support (although documentation is scant and I'm having trouble emulating the device), and I've yet to implement the "flickerterm" style 80 column screen. There's only 1K of code space left without these enhancements, but I think the large main buffer is a big improvment (I can now edit all my source code using LW).
-
I tried version 4.22 and 4.42. Neither worked in PAL.Are you sure? 4.42 should work in PAL.
Just tried 4.42 in NTSC and it still doesn't work. I can't coldstart the emulator with XEP80 switched on, either. There were a few characters on the 80 column screen, but no output when I hit any keys.
-
What version of SpartaDOS X is that? If it is 4.20 or 4.22, then the XEP80 driver has a bug and only works in NTSC.That's probably it; I tried version 4.22 and 4.42. Neither worked in PAL. I'll give it a go.
-
Will do, thanks.
-
I want to experiment with the XEP-80 device as emulated in Atari800MacX but I can't get the SpartaDOS X cart driver to recognize the emulated device. Are there any known problems or am I likely doing something wrong? I have "DEVICE XEP80" in CONFIG.SYS and it reports no XEP-80 in Joystick Port 2.
-
Current test version of LW reports 26,623 bytes free in the main text buffer under SpartaDOS X 4.22 using banked memory
. -
Any device which allows for a character to be written at position X,Y on the screen could conceivably be made to work with LW, providing it's fast. However, having written the program and optimised the screen refresh routine, I can't imagine any handler that maps 80 column text to the screen using software would be fast enough to tag onto the existing system. The simplest way of providing 80 column support is by using the "Flickerterm" method, but if we really wanted to use bit-mapped text, there are ways of amending the screen refresh routine so that it only redraws those parts of the screen which have changed since the last keystroke. It's still a headache, though, since the DOS menu part of the program also uses a fast screen refresh routine to display the directory listing (in a similar manner to the SDX "menu" program). There are simply so many different routes we could take to build-in 80 column support, but many of them are at the expense of program efficiency. I'll experiment with the "Flickerterm" system, although my main priority is to take care of support for larger text files, and I'm figuring out the best way of including multiple language support (I'm considering having a resource-file containing all the program prompts, etc, which can be customised and replaced. That would mean someone else could write the resource files for different languages
). At the moment, having shifted 14K of the 17K executable under the operating system, I'm experimenting with different memory layouts. There's about 4K of code in main memory at $8000, and everything else is for buffers. The main text bank extends from MEMLO to $7FFF, and the extended banks of course occupy $4000-$7FFF as usual. From $9000 upwards are the character set, macro buffer, preview/directory buffer, and the paste buffer, which will now be of a fixed size (around 4K). The software won't change much in operation, save for perhaps a couple of extra screen lines in the editor, and support for switches on filenames to allow for linked loads and appended saves (further ways to handle extremely large files). It will be hard to please everyone, and none of the above is cast in stone yet, but this is a great opportunity to experiment with different ideas and see how popular they prove. -
I haven't got hold of a copy of TurboWord yet, which I was going to use to investigate how to drive the XEP-80. However, from what I can gather, editing is slow and any high-speed editing has to be done in a special text entry window. It would certainly be possible to redirect output from LW's write-to-screen routine (which simply maps a character to the screen RAM at a given address), but whether the XEP-80 device is fast enough to display some 1,600 characters after each keystroke I do not know.
The XEP-80 is less than ideal, given that (a) it requires additional hardware, and (b) it's driven through a serial connection on a joystick port.One option might be to look at Clay Halliwell's Flickerterm, where two screens are switched on and off, using 4 bit wide characters in GR.0 - giving 80 columns, 40 per screen. It looks better on NTSC than PAL, I suspect, as you're getting 20% more rotations per second.
However, since you're only managing 2K in screen display vice the 8K for any of the 80 column modes using a GR.8 screen, speed should be better.
This sounds worth looking into; it's basically the system I outlined in my previous post. It would be relatively easy to implement, too, but I'm unsure of how pleasing to the eye the results would be. I'll write it at the weekend if I get time. Meanwhile, I'll look out a copy of Flickerterm and see what it looks like (it occurs to me that a text mode with 80 4-bit wide columns would have been a useful extra on the Atari8, if a bit of a kludge).
-
Hello FlashjazzcatHow about 80 column support? There will be an 80 column upgrade for the MIO (it's planned and development has started AFAIK), somebody was working on an 80 column cartridge, all we need for the VideoBoard XE is someone who can make us some PCB's and ofcourse there's the XEP80 and simulated 80 columns. I'm not sure if you can split "80 column support" into non-device specific and device specific. But if you can, you could have the non-device specific code in LW and just load the device specific stuff depending on the device one has/wants to use.
greetings
Mathy
I second support for the Xep-80. Support for the MIO and Videoboard would be great but right now have a very limited user base.
Allan
This is probably the most requested feature next to support for larger files. It's frustrating in a way, since support for an 80 column display is already built into the program in the form of the print preview screen. So we have the character set, and the routines to write to the screen. So one approach would be to re-write the editor refresh routine to map the 80 column character set onto a bitmapped screen. The trouble is that this would make the program unusably slow, because - like most Atari8 word processors - the screen refresh in LW, while fast and efficient, is primitive in as much as it completely redraws the screen regardless of which part of the display needs updating. To use a bitmapped 80 column display, one would need to selectively update only those lines which have changed due to editing, and that would require a complete rewrite of most of the memory management and screen update routines. More do-able would be an interlaced pseudo 80 column screen mode, flipping between two graphics 0 screens and two 80 column character sets.
As for MIO and XEP-80: LW's screen handling, being memory-mapped and device independent, would be hard to convert to a device-oriented methodology. Of course I don't know how these devices work, but I assume they display a linear input stream of text (I may be wrong - I don't know yet). It would certainly be possible to replace the direct screen addressing with a routine which, say, sent the same character to a device's put byte routine, and to adjust the limits of the display to 80 columns, but I can imagine this being very slow in practice.
It will be interesting to see what people can do with the source code when I eventually get it into a digestible format. The screen refresh is complex, taking care of block highlighting, horizontal scrolling, word-wrap, and the skipping of empty memory ahead of the cursor. A cursor right movement actually pulls a character from high memory and moves it to the first free location in the empty block and then updates a couple of pointers. This actually makes for quite neat programming, but also introduces complications which have, for example, made the idea of combining two 16K extended banks into a single 32K text buffer a mind-boggling headache.
I'd be interested in seeing an outline of how to interface with XEP-80 and other 80 column devices, however. Perhaps it won't be as complicated as I'm assuming it will be...
-
Also note it's doing INC/DEC of PORTB.That will toggle whether the OS is in or out, so you have to ensure it's switched out when that bit of code is executed.
That was one to watch out for, since an interrupt is bound to occur during a CIOV operation, and my patched CIOV routine switches in the OS-ROM before doing a JSR to $E456. To make the patched interrupt service routines (and the patched CIOV calls) as flexible (and reliable) as possible, I always OR PORTB with 1 to re-enable the OS, regardless of whether the OS was switched in beforehand. The code I posted above - with this modification - works perfectly now.
-
For those who like this program, I have a new version in the pipeline which should see the light of day within the next week:
LW 3.0 for SpartaDOS X, DOS 2.5, MyDOS and any other compatible DOS packages which do (or can) leave RAM under the OS intact. This version will offer:
- 24K main text buffer, together with additional 16K banks on expanded memory machines
- 2K macro buffer (double the size of previous versions)
- More paste buffer space
- Room for extra features and further development
Users of SpartaDOS 3.x and DOS-XE will be limited to the forthcoming version 2.2 of LW (which doesn't use RAM under the OS), and includes only slight changes and bug fixes from version 2.1.
As far as extended RAM support goes, after some experimentation with RAM detection routines, I'm considering making LW default to standard 130XE banked configuration, with the facility to alter the bank selection bitmasks for users who want more flexibility. This means LW would give 4 extra banks "out of the box", although extended RAM usage will have to be explicitly enabled (this is to avoid conflicts with RAM disks, etc). I believe this kind of set-up is the best compromise between ease of use and flexibility for more advanced users.
Machine code add-ins for version 2.1 will remain compatible with 2.2 but NOT with 3.0 (which uses shadow RAM), since the memory map for this version has been totally rewritten. All that will be required is a new equate file for inclusion into the add-in source code. The job of documenting the calls needed for writing add-ins is immense, so in the meantime I will endeavour to write add-ins to order.
On the subject of extra features, if you want to see something included in the 3.0 release of LW, speak up now. Within reason, I will attempt to address requests in the code space available (which has been freed up by moving 14K of the executable under the OS).
Finally, the source code will be issued after the final release of version 3.0. It's commented (if a little sparsely), and will need running through a conversion utility I aim to write in order to be compatible with MAC/65 and some of the popular cross-compilers. LW is at the moment being developed with my own MA65 assembler, and I'll provide the original .A65 source files for people who want to compile the program on the Atari8 using MA65.
Happy New Year!
-
Hi flashjazzcat,Congratulations for a great site you brought to us in such a short while. It is well done with descriptions of your products. I included The Last Word program to my online library, I also didn't forgot to include your site to my Links section. Thanks!
Thanks, that's great. I'm pleased to see The Last Word hosted on several great sites, including your own. I've just added your site to my links page, and many more will follow. I'm working on a big update for the Last Word which I hoped to have ready for New Year's Day, but it's taking a little longer because it's a big re-write.
http://getsly.com/atari/lastword/lastword.htm
That's the original download page if you want to add it - it will always host the most up to date versions.
Also please note the mediafire download link is now dead...
-
That would be the "P" status from when the NMI occurred.Since it's setting up a dummy interrupt stack entry to get control back, it's ensuring the "P" entry is the same.
The OS needs it because it checks it before Stage 2 - it skips Stage 2 if the IRQ mask is set.
Thanks for the quick answer. My problems must lie elsewhere!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
The Last Word - A New Word Processor for the XL/XE! (now NTSC-compatible)
in Atari 8-Bit Computers
Posted
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.