Back in the dawn of time (around '81-82), I wrote a n implementation of TECO (DEC's Text Editor and COrrector) for the 6502. It was written as part of an operating system I developed for the Ohio Scientific line of beasts. The OS was called GenerOS (Generic Operating System), and barely saw the light of day. Years ago I posted the source on Usenet, hoping someone would port it to Atari, Apple, Commodore or whatever, but I think it was forgotten. A few years back someone nudged me about it, hoping to port it to the Atari. No word back on that, so I thought I'd have a look at doing it myself.
Digging through what I can find, I've installed Altirra on my windows box and both ATASM and MADS and am looking at the next steps to take. After browsing several assembly language manuals for the Atari, I have a few starter questions that may speed my efforts. No really obvious answers have presented themselves.
- Is there some preferred starting address for my program? It seems like the start of available memory varies depending on configuration. I'd like a fixed address, and I gather $600 doesn't assure me something else might not live there.
Yes, on the Atari OS start of available memory depends on DOS version/configuration. A safe address should be $2000, but if you don't need as much memory for your program, $3000 is better.
- Where should I place my text editor buffer? I'd want it to be as large as possible.
This is in direct conflict with the above. If you want the text buffer to be as large as possible, there are tow possibilities:
1) Assume at least 48K ram and place your program at the TOP of RAM, up to $BFFF. You would need to move the screen address to bellow your program after loading, by writing to RAMTOP, closing and reopening IOCB #0. You now can use all the memory from MEMLO up to MEMTOP the for your buffer.
Sadly, this is not as easy as it seems because older OS versions will overwrite your program when clearing the screen (as the clear-screen routine has a bug that clears more memory than needed), not all values for RAMTOP are valid (depending on graphics mode the value should be aligned to 1k or 4k), and to reliably change RAMTOM you need to wait for a VBI to occur.
2) Use a split buffer. Simply load your program at an address "high enough", for example $3000, and use two buffers: from MEMLO to start of your program, and from end of your program to MEMTOP. This is a lot simpler and more compatible, but you have to deal with the two buffers with a hole in the middle.
3) Simply use a low enough load address (like $2000) and use as buffer the memory from the end of your program to MEMTOP. This is the simpler, but you loose all free memory before tour program, this could be up to 4K in SpartaDOS-X.
- It seems like there should be simple routines I can JSR to put a character on the screen, check for a key pressed, and return the key pressed, but I can't find them. Do I need to set up an IOCB to do all this?
If you want to reliably read from keyboard / write to screen, you must use CIO. But, you don't need to call OPEN/CLOSE for each operation, you can use the ICPT (IOCB PUT VECTOR) directly to write one character to the screen, and most programs call the GET vector for the keyboard handler directly, like:
ldx #0 ; IOCB #0
lda ICAX1, x
lda ICPTH, x
lda ICPTL, x
Sadly, the OS put-char routine is rather slow and can't write reliably to the last column of the screen (as tend to scroll-down the rest of the text). The editor included in my FastBasic uses only OS calls to write the screen and is a little slow.
- I hear great things about MADS, but my code uses '*=addr' instead of 'ORG addr', and '.BYTE 00' instead of whatever MADS uses. Should I bother converting? I'm not using any macros or conditional compilation.
I personally use MADS for simple/small programs, and CA65 for larger, multi-segment programs (as I like using a linker). Note that MADS also understands ".byte".
Once I get these basic things running, I should be mostly there. The only other details would be file I/O, which looks manageable.
Any help would be appreciated!
BTW, this TECO is a pretty full implementation based on TECO for the PDP-11.
If you need help, better to post in the programming sub-forum, as it will get more visibility.