Tyrop

Its for nothing other than my own curiosity.... to see if it can be done, to see if centipede can be written in Atari's highest res mode.

But then you would need characters pre-shifted in all directions, no? In other words, for an 8x8 character, I would need pre-shifted characters for each of the 8 character positions that surround the character so that the "B" for example, can shift over to any of the "A" positions: AAA ABA AAA Is that how you would do it?

I will try triggering the erase routine via a DLI on the last line. Heaps more time is what I need. Is there any other way to do it in Antic F beside bitmapping?

I experimented with different delay values. You can see the whole centipede even with a 2 VBI delay but it results in flicker. I tried your suggestion and placed the draw routine in the VBI (leaving the erase routine out in main code). Interesting result: it draws the whole centipede first but segments become invisible as it progresses down the screen (I have an NTSC Atari). As before, the erase routine waits for the VBI to trip a flag before execution. (Code and executable are attached - executable is the .65o file). It could be that the problem is simply that Antic F is too high for a centipede-like game. In Centipede, I would think that each segment must be separately tracked by the program because, in the game, when the centipede gets hit and segments break off, they become independent of the remaining main body and follow separate paths. Maybe this creates too much overhead. For instance, my draw code checks a variable for each segment to see which direction it is going and then sets up pointers to the appropriate shape table. Directions could be left, right, down, diagonal-right and diagonal-left (for when the segments swivel down the screen). I tried to optimize that part by creating a jump table - sort of like an ON-GOSUB in Basic. Cent23.zip

I think I have done a fair job of optimizing my draw and erase routine. By the way, I have an NTSC system. I cannot understand why the centipede is not visible at the top of the screen and then the segments become visible, one by one, as it gets lower. If I run it in Atari800WinPlus in PAL 50hz, you see more of the centipede at the top of the screen. I know that the program is always drawing the entire centipede (it has 7 segments) because if I run it with a machine lanuage monitor and slow down its execution, I can watch it draw and erase the entire thing at all times, so I think the invisible segments have something to do with the rate that the screen refreshes. Does that make sense? I use a wait loop after the draw routine and before the erase routine by waiting for the next VBI before it erases. If I delete the wait loop altogether, then I see the whole centipede but it flickers. Maybe the solution is to do page flipping. The executable is CENT22.65O. Cent22.zip

That is truly impressive. What are you doing there for 3D, calculus? I wish I could trace through your source code, it is so hard for me to trace other people's assembly language code. Where can I learn the concept of what you are doing? Are there any books or other materials you can recommend?

Thanks Rybags, that solved the problem I was having when I created two memory segments. Now to figure out this flicker problem...

Thanks for the explanation. I am learning more practical programming techniques from this forum than from any book!

Thank you Heaven for taking the time to look at my program and explain how to make it faster. I will digest the information and do some re-writing. Quick question, though. So far, the only thing I did was move my variables to page zero (starting at location $80), but now i am getting some stray pieces of my graphics scattered around the screen. The main program still works as it did (I have not yet optimized the draw routines). I am thinking that the problem has something to do with the fact that I now have two different program counter origins: one at *=$80 (for the zero page variables) and one at *=$2000 (for the main code). Now, when I binary load with DOS option L, it immediately runs the program, whereas before, I had to use option M to run at address $2000. Is there a way of telling the assembler what address the program is supposed to start at? I am attaching the source code and executable, and again, I really appreciate the time you take to look at this, and if you don't have the time, I totally understand. THe main program source code is CENT16.ASC and the executable is CENT16.65O. cent16.zip

THanks for the description. I think I am using unrolled loops. I am using a loop to copy the sprite to the screen and then another loop (very similar code) to copy sprite to the screen again to erase it using EOR.

Heaven, thanks for looking at my program. I looked at that thread and I viewed some of the source codes in some of those attachments. I wish I could follow what the programmers are doing. It is so hard for me to trace through assembly language listings. Can you describe the concept of what game programmers generally do to draw and move sprites, or point me to a book? How did you learn? I don't know what "buffering" or "double buffering" or "masking" is. I figure I should just draw and erase and re-draw. I guess I just need to know what do conceptually, and then I will try to figure out out how to translate the concept into code. Also, the draw routine I used is almost identical to the one in the book, Atari Graphics and Arcade Game Design, so I figured it was fairly optimized, but you say it can be optimized even more? Thank you to you and Rybags and anyone else that can give me some pointers. I would love to learn this stuff and it is something I've wanted to do since the early 80's. I've read De Re Atari and I've looked through the books that are on atariarchives.org. I am interested in learning to move sprites (as opposed to using PM graphics) because I like the high resolution of Antic F (even without color) or the fairly high resolution and multicolor ability of Antic E. My goal is to see how close I can get the Atari to look like the arcade version of centipede (resolution-wise, not color wise). Centipede 5200 impressed me by its smoothness but it lacks the resolution (Antic E?), and I realize that it is probably as close as you can get with color (and, I have no idea how that programmer drew and moved the centipede). I think the actual arcade version is in a mode that is essentially 320x200 or close to it.

I would love for someone to look at my code and let me know how to improve! I used Atasm. CENT15.ASC is the main program and CENT15.65O is the executable. Binary load it and run at address $2000. Thanks!! Centtest.zip

The shapes do overlap but not the actual graphics parts. Hopefully, I can put this into words The first segment is drawn, and depending on its horizontal location, there will be blank bits on the left and/or the right of the graphic. Then, the second segment is drawn behind it (to the right of the first segment), and it also will have a blank area on its left and/or right side. So there is overlap, but only where one of the shapes has blank bits, but I OR it so the graphic parts do not get overwritten. The result is a centipede that looks like the arcade: there is one blank pixel separating each of the segments from each other. But when I erase, I do it by EOR'ing the first shape with itself, then the second with itself, etc. I will try your other suggestions, and maybe a longer pause between draw and un-draw - maybe 3 VBI's just to see if that does the trick (even though 3 VBI's = a pretty slow centipede!) Is there a better way to move shapes around the screen than 1) draw shapes; 2) small pause; 3) completey erase shapes; 4)immediately re-draw shapes at new location; repeat... ?

I am trying to program a centipede game in assembly language. I am doing it in Antic F and I am using the technique in the book, Atari Graphics and Arcade Game Design, Chapter 8 (Raster Graphics) which draws, and then erases, a shape table to screen memory. Basically, I am using the same shape table for each of 7 centipede segments (The shape table consists of 8 separate versions of the centipede segment - each one shifted over one bit from the previous one). The actual shape itself is small - it is only 8 pixels x 8 pixels (because of the 8 shifted patterns, it is 2 bytes wide by 8 bytes high). It is only the size of a keyboard character. I am copying the shape, byte by byte, to screen memory (or'ing it with screen memory). Then I erase it, byte by byte, by copying the shape to screen memory again and eor'ing it with the bytes that are aleady there. WHat I do is I copy the shape (centipede segment) 7 times so that you see 7 segments next to each other in a straight line. THen, I need to have a delay so that the centipede is visible longer than it is invisible. So for a delay, I have the computer keep looping until a flag is set in the vertical blank. THen, it immediately un-draws the entire 7 segments and draws them all again one pixel to the left, and so on. SO basically, it draws the centipede as fast as it can, waits for the next vertical blank interrupt, and then immediatley erases, and then draws at the next position (so the centipede advances to the left one pixel per 1/60th of a second or 60 pixels per second). I figure that the amount of time it must wait for the VBI is very long in comparison to the the amount of time it takes to erase and re-draw. When I have it drawing one centipede segment, it is nice and smooth. But with 7, it flickers. There must be a better technique. How does a game like Drol, with so much larger shapes, draw, erase, and re-draw without flicker? I was looking at the code for soft-sprites and cannot follow it at all and I am not sure what the author meant by "masking." How do people learn this stuff? Is there a book that teaches how to smoothly move shape tables?

Kenfused was right... I needed to set concurrent mode on channel 16, so that fixed the repeated errors. Now, the Atari can only output. It does not seem to accept input from R1. I am using Atari Terminal Simulator (an ATASCII terminal program from the APE web page) on the PC side to connect, so I am transmitting carriage returns as 155, but the Aatari is not even echoing characters. THe following program outputs to R1, and its output on the Atari Terminal simulator shows HELLO, followed by the program listing, followed by the READY prompt, followed by the cursor. But after that, if I try typing on the Atari Terminal Simulator, I see nothing (although the APE Internet Proxy Monitor is flashes RX every time I type a character). THank you all for responding to my post, I greatly appreciate all the helpful advice. I wrote a rudimentary BBS in the early 80's and I would like to try running it again, adding the ability to get into BASIC and DOS remotely. Here is the short program: 10 CLOSE #16:OPEN#16,12,0,"R:" 20 XIO 40,#16,0,0,"R:" (sets concurrent mode I/O) 30 XIO 36,#16,15,0,"R:" (sets 9600 baud, 8 bits, 1 stop bit, no line monitoring) 40 XIO 38,#16,32,0,"R:" (no ASCII translation, ignore parity, do not change parity bit, do not append line feeds) 50 PRINT"HELLO" 60 LIST That program outputs to R:, but does not accept input. If anyone is willing to give this a shot with APE, you can set APE's R: internet modem in server mode, and telnet from the same computer running APE by putting in your PC's ip address. If you are behind a router, you can use your local ip address.

Im not sure that concurrent mode matters. The Atari is receiveing something which is causing it to display this error over and over again. I can't figure this out, I think it may have something to do with APE.

THe error does not seem to have anything to do with ATASCII differences. In fact, I cannot eveb get to type anytning in. The Atari sends that error over and over all by itself. Maybe it has something to do with APE?

Wow, nice trick in Basic using OPEN #16,12,0,"R:"... I am using APE as an internet modem, and when I connect using WIndows Hyperterminal or telnet, I get the following repeated over and over again in Hyperterminal or in telnet: ERROR- ~}|{zyxwvutsrqponmlkjihgfedcba`_^]\[[email protected]?>=<;:9 876543210/.-,+*)('&%$#"! Any idea what this is? Even when I do ENTER "R:", the same error shows up repeated over and over, except on the Atari side (all in inverse except "ERROR-")

I want to be able to redirect the Atari's input and output from the keyboard/screen to the RS232 so that I could operate the Atari remotely, i.e., use a modem or telnet into the Atari and be able to access DOS and Basic. Basically, the Atari would look to R1: for its input instead of the keyboard, and it would send its output to R1: instead of the screen. Would it be as simple as swapping the 'E' and the 'R' in the handler address table (HATABS)? I remember that IBM made it easy to redirect the standard input and output "stdin" and "stdout" via a simple DOS command. How complicated would it be to do this on the Atari?

I just got a SpartaDOS X cartridge and I notice that I am not getting warp speed with APE even when I create a 16 meg ATR image. I formatted it with SpartaDOS X Format. I ran the Ape warp utility that came on the utility disk, but it did not work either.

I'd like to make multicolored shapes for a centipede-like game, i.e. the centipede has eyes and legs with a different color than the body. I'd like to use Antic mode E. Is there a good shape editor or a font editor that will do multicolored shapes and write data lines which can be entered into an assemble language program?

THanks again Heaven. That worked! Wrathchild, is video quality of your capture card good? I bought something called VGA Box to hook the Atari to a VGA monitor using the video cable, but it is a bit fuzzy, and terrible using the XEP80 80 column box.

Thanks! I should have thought of something like that. I did not see any crimson editor syntax files on xasm.atari.org - only that xasm comes with a scite syntax file.

Problem - when I load a mac/65 source file in crimson editor that was created in mac/65 on the Atari (using LIST - not SAVE), the listing comes out all on one line. The line feeds (atascii 155) are not translating to ascii carriage returns (ascii 13).

Thaks for the responses. Cross-assemblers sound interesting. I downloaded notepad++ and crimson editor. In crimson editor, under user tools, I was able to set it up to compile using xasm. Dragging and dropping the resulting obx file onto Atari800Win Plus results in boot errors, though. What am I doing wrong? Also, the text is al monchrome (black). I guess it does not recognize 6502 syntax Both notepad++ and crimson editor support lots of different language syntaxes, including assembler (for x86, I guess). Is there, or has anyone set up, a good color template for one of the syntax of any of the Atari cross assemblers?