Cybernoid

Looks good, but it looks like you are doing something to stretch the screen horizontally. If it was not stretched, it would look great with artifacting turned on.

Yup, thanks for the feedback.. I am working on fixing the initial spurious cursor bug... Try a DOS 2.5 image and let me know what you get. DOS25.zip

Here is the beta version of my new E: handler. It is something I am working on for another Atari project, but it is pretty nice stand-alone...(ok, so I am biased... ) The keys are: CTRL-SHIFT-3 = change background HUE CTRL-SHIFT-4 = change foreground Brightness CTRL-SHIFT-5 = change background Brightness CTRL-SHIFT-A = switch between ATASCII and ANSI modes I put my ANSI processing code into the E: handler, so you can now switch into ANSI mode and read msdos/unix text files as well as ansi graphics directly from the Atari. Still some work to do... most of the code runs from extended bank 3. I also need to fix the character insertion. ATASCII Mode ANSI Mode FLASHE_BW130A.zip

Ok! Now this looks interesting... I'll give this a try!

Me too. Allan Me three - it was an option when I bought my SIO2USB but since it's German language I decided not to. BTW I have to say that the SIO2USB folks from ABBUC have given me great support and are extremely helpful and friendly me four ! Hey, maybe we can start an English SIG of ABBUC. I would certainly devote some of my time to translate the German magazine into English.

Never mind... found the bug in the code....

That is awesome. 80 columns with a virtual 240 width is very cool!

I have written my own E: handler. It really contains an S: and K: handler, too. It seems to work with most DOS 2.0 compliant doses, but when I run SpartaDOS (say version 3.2g), it prints the "D1:" prompt and displays any key you press on the screen after that, but it does not act on a command once you press the "RETURN" key. Does anyone know why? Or, does anyone know how SpartaDOS notices new key presses or new lines or new commands in a buffer somewhere to act upon? Thanks...

Sourceforge is great. I worked with sourceforge on the atari800 sources. It is not necessary, but it is a great spot for developers at different locations to get together and keep track of code.

Alright another Sourceforge Atari project! Yes, sign me up!

Ahem, even an "empty" (i.e. zeroed out) bank can be nevertheless occupied by something, so this doesn't seem a way to go. The idea with calling some resident device (let it be "M:") is much better. Agreed. Yes, that is true. Looking for zeros is not as safe. Again, just an example. Dan's idea of keeping tables and detecting DOSes is much better.

What if the bank the program wants to use is already taken or it does not exist? As it was pointed out above, you cannot do that without some sort of a TSR, that maintains the memory state. And this in turn is just reinventing SpartaDOS X, sort of. That was just an example piece of code. You can have anything in the function. For example, you could write some code that checks every memory location in every bank or every byte at the 0x100 boundaries and see if it is empty. Or, and this is more on the lines of what I was thinking, you have some XIO calls to the M: device to return the status of each bank. This way you load the M: device handler first and let the M: device retain a table of which banks are being used. As a side note, I remember reading in one of the mags about someone making a simple M: device handler. It would be great to expand upon...

I'll have to check out the programming forum. I have not gone into there that much... I probably should since I do alot of programming for the A8. I like the idea of adding the Atari implementation to the cc65 API. That would be great! Yes, I am interested in doing that and will help!

What I am doing, is pretty simple for CC65: I setup the header for the segment of code I want to put into extra banks like this .segment "LOHEADER" .word $02e2 .word $02e3 .word _extmem_set_bank0 .word __CODE_LOAD__ .word __BSS_LOAD__ - 1 The extmem_set_bank0 function is in a different code segment that is not part of the 0x4000-0x8000 address space. It is the following piece of code but could be anything as long as it is loaded into memory before the extra bank is: void extmem_set_bank0(void) { *(unsigned char *)0xd301 = ((*(unsigned char *) 0xd301) & 0xc3); } This way, when I link the code together any code destined for the extra bank 0 is automatically loaded there, no matter what dos you are using...

Good ideas! I am writing my E: handler in CC65, so a coordinated effort would be good. Also, I like flashjazzcat's idea of a M: handler. The only problem I see with that is it is only really good for reading and writing data to the extended banks, but what if you want to run code from extended banks... I suppose you could do a special XIO call for the M: handler that tells the handler to switch banks and run code at a specific address, then switch the banks bank and return.. The run code call could be use with an XIO 128 (or any number above 13): XIO 128,#6,2,0,4000 ICCOM = 128 IOCB = 6 ICAX1 = bank number ICBAL/H = run address or you could pot the bank number into the ICDNO, so you could do: OPEN #6, 12, 0, "M2:" (open extended bank 2) XIO 128, #6,2,0,4000 (run at address 4000) Of course, in basic, you cannot put the 4000 in the code, but you might have to poke the values in ICBAL/H directly, or change the address of a string somehow...

Wow. This thread is very interesting. I have been working on an 80 column E: and S: handler that sits in an extended bank. I, too, have been wanting to make it configurable so that it could be a 40column or 80 column handler. Funny how several people start to do the same thing... What I have tried is to create the get_byte and put_byte routines, put the entry points for routines in the normal screen address space above $bc40. The first thing the code does is change the extended bank, then jump to code in the $4000-$6000 space. Then that code jumps back to the $bc40 space and turns extended banks off. For 80 columns in the extended bank you have 8k for screen ram and 8k for code. It works out okay. This way any time the OS needs to do the get_byte or put_byte routines it only modifies bits 5-2 of $d301 when these routines are called. This is kind of working so far, I just have not got it to work with all the doses I want yet. You are right it is a real pain to mess with the extended bank settings since different doses do different things with $d301. I'll post the handler when I get it kind of stable. It sounds like the Last Word handler is pretty cool so far...

Not that I know of, but I have thought of making an ATASCII version of VT-100 pacman http://spatula-city.org/~im14u2c/vt100_pacman.zip (I used to work with Joe at TI...)

My game Click! uses the CX-85. Can download here: http://atari.fandal.cz/detail.php?files_id=5924 Or form the link in my sig below...

Oh, ok. I forgot that you had the TCP/IP stack in there. Then, yes, that would be okay to do. I ran slip back in the day from my linux box to connect up the ST to. So that makes sense.

That is slick! Mind if I borrow this technique for use in FujiChat? Sure. That is why it is there. You can use it. You can put code to ask the user for the default host to connect to. Then reopen the R: device with that host. You may run into an issue with IRC though since the default port is 6667 and the icax2 number is only a byte. I'll have to check with the emulator code it may use icax2 and icax3. You could also store the default hostname and port and send to the APE R: device "open" command.

Also, I suppose that someone could patch bobterm or ICE-T to do the same thing...

No problem. You are using ANSITerm almost exactly how I tested it. I used it with the emulator under Linux. I wanted it to come up with the localhost prompt so you can log in and start using it straight away.

Fletch, I coded ANSITerm. I am actually working on some updates to it right now. The commands can be found in this thread: http://www.atariage.com/forums/index.php?s...amp;hl=ansiterm or here: http://www.atariage.com/forums/index.php?s...t&p=1211229 or here: * Terminal control: * CTRL-SHIFT-D - Delete Macros * CTRL-SHIFT-N - New Macro Save to Disk * CTRL-SHIFT-M - Macro Load * CTRL-SHIFT-R - Baud [R]ate * (Was CTRL-SHIFT-B) * CTRL-SHIFT-F - Toggle Line [F]eeds * (Was CTRL-SHIFT-L) * CTRL-SHIFT-E - Toggle Local [E]cho * CTRL-SHIFT-S - Toggle 80/40 columns (creen Size) * (Was CTRL-SHIFT-C) * CTRL-SHIFT-W - Toggle Word [W]rap * CTRL-SHIFT-T - Toggle [T]erminal Emulation (ATASCII, ANSI, VT52 mode) * CTRL-SHIFT-H - [H]angUp * CTRL-SHIFT-I - nsert char mode or Replace mode (replace is default) * CTRL-SHIFT-> - Move screen Right ([X] doesn't work on real Atari) * CTRL-SHIFT-(UP_ARROW) " * CTRL-SHIFT-< - Move screen Left ([Z] doesn't work on real Atari) * CTRL-SHIFT-(DOWN_ARROW) " * CTRL-SHIFT-? - Toggle screen left/right 40 columns * CTRL-SHIFT-[ - Toggle Foreground Color * CTRL-SHIFT-] - Toggle Background Color CTRL-Shift-E will toggle local echo. The default behavior of ANSITERM is to open the R: device like this: XIO_OPEN(R_DEV, 13, 23, "R:localhost"); // For Linux & Windows EMU If the string passed to the emulator is "R:hostname", it will open that hostname by default. AUX2 will also hold the port number; notice the 23 in the command. Since I had some hand in the emulator R: development, this works well for the emulator and does not seem to interfere with opening on a real 850. I'll check what is going on in the v1.0.0 release... It has a full 80 columns in there it only displays 40 at a time. Try pressing CTRL-SHIFT-(UP/DOWN Arrow)...

Thanks Thomas.

Awesome! I thought I had seen that, but I didn't search the forum for the right keywords... As always, Rybags, you have proven to be an excellent technical source... Thanks!