Cybernoid

Do you know how big the handler is. The code for my program starts at $2000. So, if it is bigger than 256 bytes, my code is more than likely overwriting it. I'll mess with changing the load location... I *think* I am using code that *should* work with a real 850 interface. I wrote the XIO routines myself, so there is potential there for them not to work. (Just another thing to debug.... ) Basically, I have functions that should do the same thing as the basic OPEN, CLOSE, GET, and XIO routines... my init routine is: #define R_DEV 4 xio(36, R_DEV, 0xf, 0, "R:", 0); // Set 19.2kbps (BB), 9600bps (850), 8N1 xio(38, R_DEV, 0x20, 0, "R:", 0); // No Translation, no LF, No Parity XIO_OPEN(R_DEV, 13, 0, "R:"); // Do we need to set DTR ? xio(34, R_DEV, 0xc0, 0, "R:", 0); // DTR ON // Set concurrent mode. xio(40, R_DEV, 13, 0, "R:", 0); // For 850 & Linux EMU Ooh, yeah. Looks like I have a typo for the xio 40 line... where did that 13 come from? --C

Thanks Steve! I forgot about this. (It's been too many years since I used it.) I found the RS232.COM program. Ran it. It beeeeeped. And, it seems to slow down the screen draws while still not working. Hmmm, there is still something wrong here. I am trying to figure out why this doesn't work on a real Atari with APE. Do you know how the R-handler that APE installs works? Does it install anything for deferred or immediate VBI? Where in the memory does it install? Also, do you know what the differences are between the RS232.COM and the AT_RS232.COM found on the SpartaDOS disks? (I know... Lots of questions...) Thanks, Chris

Hi. I have been coding a simple Color ANSI Terminal for the 8bit. The first thing you are probably going to think when you read this is, "Why?". Well, I have been writing this program just as an example and to familiarize myself with programming for the 8bit in the hope that some of what I have learned could be applied to a game or two. I have included the current executable and source code. ANSITERM.COM is coded in C and compiled using CC65. The terminal is 40 columns wide, but has a virtual 80 column screen (you can scroll left and right). It uses 8 colors for the characters, but it makes use of interlaced color to do this. I have tried to minimize the flicker, and it looks good on an NTSC TV. The emulator is okay, but I do not like how it emulates the interlacing. I am not sure how it would look on PAL, but I think that the flicker would be more noticable. Also, the VT102 and VT52 state-machines are mostly implemented with the exception of inserting/deleting lines and chars (back space does work). The character set has room to grow to make use of special graphics characters as well. I have finally gotten the code into a state with which I am happy, however, there are now a few problems I just cannot figure out: If I try to read more than 1 character at a time, the char draws mess up. The characters are not placed where I expect them. While trying to use ansiterm with APE and when it opens the R: dev, I think it is trying to access a disk drive. Is there an R-handler I have to install? I thought APE did this automatically... could be wrong. Well, I thought that a terminal emulator would be an easy thing to code... Anyway, there are a few other bugs and things I want to change. The code is currently a little messy.... If any one has any ideas, or wants to look at the code and help figure out a few things, GREAT!!! LMK! Here are the CTRL-SHIFT key commands: CTRL-SHIFT-R - Baud [R]ate (Was CTRL-SHIFT-B, need to check) 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-X - Move screen Right ([X] doesn't work on real Atari) CTRL-SHIFT-> " CTRL-SHIFT-(UP_ARROW) " CTRL-SHIFT-Z - Move screen Left ([Z] doesn't work on real Atari) CTRL-SHIFT-< " CTRL-SHIFT-(DOWN_ARROW) " Thanks, Chris ansiterm_1.1.zip

Ah, come on!!! I have a 130XE at work!

Ah, I was afraid that there were some key combos that you cannot detect. I know that CTRL and shift are bits 7 and 6, but I couldn't seem to use this with the left and right arrows. Darn! Happy Easter from Texas!

Is there a way to detect a CTRL-SHIFT key press on the 8bit? For example, can I detect a CTRL-SHIFT-A, or more importantly, can I detect a CTRL-SHIFT-'+'(LEFT ARROW) or CTRL-SHIFT-'*'(RIGHT ARROW)? Have any assembly, C or BASIC code examples? Thanks... --C

Why would you mix Antic Modes 4 & 5? Isn't the only difference between 4 & 5 is the number of lines used per char? Is this to save memory if you know that the graphics in that region do not need the high-detail? Say, use mode 5 for sky (more lines per char) and mode 4 for close-up objects? Just curious....as a newbie A8 game developer.... --Chris

There is a potentiometer within the 130XE that controls the HUE. I had to adjust mine after doing the Super Video upgrade. For more info, try here: http://www.geocities.com/atarimods/sv130-1.html The color pot is shown in this picture: I am not sure that this will help, and I am not sure how this thing could have been loosened during shipment, but it may be useful. Also, he will have to open the machne up to look at & adjust this. Cheers, --Chris

I have a MyIDE and it works great! I even have it working with SpartaDOS, but I really have Marius to thanks for that. Here is the ATR image that he gave me for using MyIDE with SpartaDOS. Cheeers, Chris chris_myide_sp33a.zip

Ah, thanks. I seem to be getting different results with DMA off versus DMA on, but that could just be my stupidity in doing something wrong. Oh well, thanks for all the information! I think I will mess with this a little more anyway...It does make some interest effects. Cheers, Chris

Also, the reason why I am asking is I am working on a 8bit application and a game in my spare time, and it looks like in Antic E mode, you can have: 4 colors (one for each playfield) plus 5 colors (one for each player/missile) But, for each line, if you can OR each player with each playfield color, you can have a total of 20 colors per line, but dependent on player position. Is this right? Thanks, Chris

Hmmm, I have a couple of questions for the gurus regarding PM graphics and priority. While, messing with PM graphics and an emulator, I have noticed that if I disable the PM graphics DMA and write directly to the Graphics registers (0xd00d-0xd011) AND turn priority off (0xd01b = 0), then a few weird things happen. In Antic E mode, Players 2 and 3 and all Missile colors are ORed with the Playfield colors. Player 0 and 1 seem to be on top (higher priority) of some of the Playfield colors, but not all of them. So Player 0 and 1 colors are ORed with some Playfield colors, but I haven't figured out which ones yet. I haven't noticed this Playfield/PM color ORing with the DMA turned on. I was wondering if anyone out there has messed with this and knows exactly what happens in this priority-0 mode. Does anyone know how Player/Playfield colors are ORed? Thanks, Chris

If you want to connect to the monitor port, then you always can cut a MIDI cable (or a keyboard extender cable) and an RCA cable in half and build a new A/V Cable... You can even add an S-video cable. This is what I use for my Ataris (a MIDI, S-Video RCA hybrid). Cheers, Chris

Thanks Shawn! That's got it! I moved RODATA and DATA to RAM28, and it started working. Alright, now I am back on track... and I have more room to add code. I wish that the RAMBO and the COMPY upgrades were compatible with ANTIC only accesses to the extended memory. If this were the case, then I would have just loaded my code into the whole range from 0x2800 to 0xbc1f, and tell ANTIC to use the extended banks for Screen data. But, I don't think that the "after-market" memory upgrades allow this feature. Again, thanks Shawn and thanks Mark, you guys saved the day... Cheers, Chris

Ah, I did not know that the BREAK command existed in the emulator. That is cool (and useful). I tried setting the BREAK command at the address of _main, but the computer never reaches _main, so I think that the problem lies before that. I have managed to set break-points for SpartaDOS and that seems to work... hmm... I have tried re-ording the MEMORY section so that SECHDR is before RAM28, but that has no effect. could this be dependent on the version of CC65 that I am using (2.9.5)? Thanks, Chris

You can definitely surround just the code you want to place within the segment. I have taken a look at both the .map file and the assembly output and it has only placed the one function within the CODE2 space (for a total of 0xe6 bytes). I did have problems running out of room, once the code started to grow to about address 0xa900. I believe that this was because I was starting to overwrite heap/stack. However, I do not think that this is problem now, since I have optimized the code and made sure that it would all work from the CODE (0x8000-0xBC1F) address space, first. Then, I tried to break it up and place one function in the CODE2 space. Putting anything in CODE2 doesn't work, for some reason... I just hang the machine at address 0xc02c. (okay, over-use of the emoticons... ) --Chris

Thanks Shawn. Thanks Mark. I now can compile and place code within the 0x2800-0x3fff or 0x8000-0xbc1f address spaces; however, the code no longer runs. I have only placed one function in the 0x2800-0x3fff range, everything else is within 0x8000 and above. I have surrounded this one function with: #pragma codeseg("CODE2") ... #pragma codeseg("CODE") When I load the code in the emulator, the Atari hangs at PC address 0xc02c, which according to "Mapping the Atari" is the IRQ processor. Here is my new link.cfg file: MEMORY { ZP: start = $82, size = $7E, type = rw, define = yes; HEADER: start = $0000, size = $6, file = %O; RAM: start = $8000, size = $3c1f, file = %O; # $8E1F: matches upper bound $BC1F RAM28: start = $2800, size = $1800, file = %O; # $1800: matches upper bound $3FFF #BANK: start = $4000, size = $4000, type = ro; SECHDR: start = $0006, size = $4, file = %O; } SEGMENTS { EXEHDR: load = HEADER, type = wprot; CODE: load = RAM, type = wprot, define = yes; BSS: load = RAM, type = bss, define = yes; CHKHDR: load = SECHDR, type = wprot; CODE2: load = RAM28, type = wprot, define = yes; DATA: load = RAM, type = rw; RODATA: load = RAM, type = wprot; ZEROPAGE: load = ZP, type = zp; AUTOSTRT: load = RAM, type = wprot, define = yes; } FEATURES { CONDES: segment = RODATA, type = constructor, label = __CONSTRUCTOR_TABLE__, count = __CONSTRUCTOR_COUNT__; CONDES: segment = RODATA, type = destructor, label = __DESTRUCTOR_TABLE__, count = __DESTRUCTOR_COUNT__; } SYMBOLS { __STACKSIZE__ = $200; # 512B stack (was 2K stack) } I have linked this file in order to enable the second load... .import __CODE2_LOAD__, __AUTOSTRT_LOAD__ ; CHUNK HEADER .segment "CHKHDR" .word __CODE2_LOAD__ .word __AUTOSTRT_LOAD__ - 1 .code .reloc Any ideas? I am working on a full color VT100/VT52 terminal program. (Well, okay it currently handles 8-color text, 8 color background, 40 columns with a virtual 80 column window.) This is close to working, but it currently only grabs input from the keyboard. I have other code for running the XIO commands to control the R:device, but I need to get this extra address space working before I can integrate this together. Thanks again for the help.... Chris

Doh! Yeah, I forgot the define = yes to the Data segment. Okay, I added this. Now, it compiles, but when I load the program from SpartaDOS, it gives me an error 146. Which, I think is "Function not implemented in handler". I am not sure what the problem is here...

.import __DATA_LOAD__, __DATA_SIZE__ ; .segment "H_DATA" ; .word $FFFF .word __DATA_LOAD__ .word __DATA_LOAD__ + __DATA_SIZE__ - 1 ; Thanks Mark! This information is very useful. I received a similar message from Shawn Jefferson basically saying to do the same thing. Unfortunately, I am still having some issues. I have created a file with the code above, but when I link, I receive the following: ca65 -o segload.o segload.S cl65 -m ansiterm.map -Ln labels -C link.cfg -o ansiterm.com -t atari ansiterm.o segload.o Unresolved external `__DATA_LOAD__' referenced in: segload.S(1) Unresolved external `__DATA_SIZE__' referenced in: segload.S(1) ld65: Error: 2 unresolved external(s) found - cannot create output file

The following is a question that I posted to the cc65 mailing list, but since there are many accomplished coders (hopefully some with C), I thought I would cross post this question here: Hello, I have a quick question about using the linker config file. Please let me know if you have some ideas.... Here is what I have: I have some code that uses the Atari 130XE bank switching to do some things. In my link.cfg file, I have basically defined all code to be placed between the 0x8000 and 0xbc1f address space. However, my code has grown to a point where it will no longer fit in this space. The Atari 130XE allows you to bank switch the address space from 0x4000-0x7fff, so initially I do not want to put any code here. I would like to place code in the address spaces: 0x2800-0x3fff and 0x8000-0xbc1f. I am not sure exactly how to break this up. Here is my link.cfg file (more comments below): MEMORY { ZP: start = $82, size = $7E, type = rw, define = yes; HEADER: start = $0000, size = $6, file = %O; RAM28: start = $2800, size = $1800, file = %O; RAM: start = $8000, size = $3c1f, file = %O;# $8E1F: matches up bound $BC1F } SEGMENTS { EXEHDR: load = HEADER, type = wprot; CODE: load = RAM, type = wprot, define = yes; RODATA: load = RAM, type = wprot; DATA: load = RAM, type = rw; BSS: load = RAM, type = bss, define = yes; ZEROPAGE: load = ZP, type = zp; AUTOSTRT: load = RAM, type = wprot; } FEATURES { CONDES: segment = RODATA, type = constructor, label = __CONSTRUCTOR_TABLE__, count = __CONSTRUCTOR_COUNT__; CONDES: segment = RODATA, type = destructor, label = __DESTRUCTOR_TABLE__, count = __DESTRUCTOR_COUNT__; } SYMBOLS { __STACKSIZE__ = $200; # 512B stack (was 2K stack) } --------------------------------------------------- I have tried changing the DATA line to: DATA: load = RAM28, type = rw; This compiles, but when I load the code, the computer crashes. Does anyone know why this would be? Also, a related question: Is there a way to specify which structures are placed into which address space? For example, say I want to use the 0x4000-0x7fff address space for code. I would then want to place a piece of code to handle the bank switching outside of this address space. But, how do I place one function at a certain location? Thanks for the help, and sorry for the long post. Cheers, --Chris

The 40x40 example is very interesting. I wonder what this method would look like applying it to Antic modes 4 and 5. This could be used for character mapped background graphics for a game, for example. You sacrifice 2 lines per character, but you can fit more on the screen. Also, is this really more than 40 characters wide, since you are using wide playfield?

Guys, Yeah sorry, my previous web-site provider, decided that they could no longer provide FREE websites with CGI, so I have put the Ethernet Project page here: http://home.comcast.net/~atariguy1/atari/a8ether You will hear more about this project very shortly.... Chris!

I have: 3 x 130XE (1 with 3 OSes - OSB, OSXLXE, Omnimon; 1 with SuperVideo done by myself; 1 with built-in MyIDE done by Mr. Atari himself) 2 x 800XL 1 x 600XL 2 x XEGS 3 x 1050 Disk Drives (1 with Happy) 2 x SIO2PC (1 hand soldered) 1 EtherCart ProtoType (http://home.comcast.net/~atariguy1/atari/a8ether/) Those are the things I use, here are the things laying around not being used that often: Koala Pad CX85 850 MPP1000C Modem MPP1000E Modem Star XG10 Printer MPP printer interface PR: Connection 410 Cassette Drive Various other Joysticks, Rotary Sticks, Track Balls, Mice, Printers, Disk Drives that I need to go through

Hi, The Atari Ethernet Cartridge Site it mine. Although, I am getting ready to update the information here: http://home.comcast.net/~atariguy1/atari/a8ether. To give a quick update, I have finished the version 3.0 of the board layout, but am waiting for the money to build some boards. I have also ported Version 1.1 of Contiki...it works much better than 1.0. Anyway, I've been lurking around the message boards and newsgroups and will try to keep everyone updated. I have to say that there is still a great deal of cool stuff coming out for our 8-bit's including cool graphics and a Mario Clone... good job Analmux... l8r, Chris

Have you seen this project? http://www.mindspring.com/~2600onachip/index.html http://atariage.com/forums/viewtopic.php?t...ht=2600+onachip Collaboration with Carlos may be useful.