Dragnerok X Posted July 19, 2006 Author Share Posted July 19, 2006 Ironically last night I was brainstorming a few program ideas and thought ...o0(What the heck! Why not stick a game in. GEEZ! Why didn't I think of this earlier?) and so it happened and what game did I choose which probably was the only which would be realistic considering my programming expieriance.....PONG!!! Whoops. Sorry. Oh, it's fine. Besides, Yours DID turn out pretty well, and I have yet to find a bug. I figured you'd be too busy adding all those features AtariOS needs. I try to. Wow, pretty good for 1 night. Standing on the shoulders of giants. It's wonderful how there's a tool for everything these days. .....and a service pack for every version of windows....... Yours is probably better though because I was going to use the Ball y = player1 y game engine Ugh. That would have been... not good. Besides being (potentially) able to move faster than the paddle is supposed to, such an engine would mean that the computer would never miss. A game isn't much fun if you can't win. But it does make a pretty good pong trainer though! 1. It needs to be bug-free. I think you mean "stable". Making bug-free code is close to impossible, even if you mathematically prove it. The probability of code being 100% bug free drops with each line of code you add. Well...it'll be as bug free as humanly possible. 2. It needs to be flicker-free. This is doable, but you'll need to upgrade to the multisprite kernal -OR- write a kernal in embedded ASM. This is what I'm having some trouble on, I can't quite figure out how to port Atari OS to the multisprite kernel (v99b) because I wired it so that the click detection is controlled by whether it's displaying one sprite (f = 0) or the other (f = 1). Also i've had just some pure general problems with the kernal (tested working code won't compile) . I also don't know where to start IF I WROTE a multisprite kernel. 3. It should be functional enough that it is not considered a tech-demo. I presume this means you're looking to add more programs? Yes, but to a reasonable degree. I don't plan on even writing ten. Just enough so it doesn't strangle me with work, but enough so it isn't boring. (3 - 4 programs) . Besides, I'm working with limited rom space here. The cart I ordered, (and what I want it to be) is 4k. 4. It should provide SOME level of computer-like functionality. Is this a constraint on which programs you'll add? I presume you'll want things like a Caculator, a Notepad(?), a playfield-based Paint program, a sound/music player and composer, and (of course) games? If you're a hardware wizard, you could even add printer and disk drive (memcard? AtariVox?) attachment points into the cart to make permanent copies of the files. What I meant by computer-like functionality was something like a basic interpreter, powerful enough to drive the system, but doesn't clog precious rom space. I don't plan on porting windows xp pro to the 2600.I will add what I CAN with what was said the last paragraph. P.S. If you hadn't seen it already (you must have because you are in this topic) I posted a bug-fix which should help with the dev-kit . Yes. I saw it. It doesn't seem to be compatible with the devkit. Speaking of which, feel free to take the devkit as your own. I whipped it up just to show you the way, not to do all the work for you. (You wouldn't get any personal education or fullfillment that way! ) I'll happily answer any questions you have, as well as provide you with webspace for distributing kits if you'd like, but I'm not looking to take over the development from you. It's your baby, not mine. I'm just trying to help out. One of the key things you need to do if you want to reach your goals is to provide a method for handling more than one program. Which means that the current devkit is fine for development, but not very useful for deployment. You'll need to work out a more complex methodology, then create an engine to support it. I'll happily help with any technical difficulties you have. Good luck! Thx for the support. I didn't expect as much. Just keep note that I am new(er) at this thing we all call "programming" (I started programming in Qbasic for ms-dos a few years ago (about 3) and I'm sort of in that "i need to find a better language to use" phase) and can't whip out assembly code faster than reading what was just said (or even a bug list for windows )so don't expect the atari to be revolutionized per-say. Expect batari basic be well....just used. PERIOD. But thx for your help. It's nice knowing I'm not the only one going into programming this 30-year-old marvel. Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 20, 2006 Share Posted July 20, 2006 Oh, it's fine. Besides, Yours DID turn out pretty well, and I have yet to find a bug. I found one. I forgot to add 10 to the SetBallHeight routine (the ball is supposed to only start within the middle 55 pixels), which means two things: 1. The ball favors the top half of the screen. 2. The SetBallHeight routine can occasionally return a value less than 15, causing the ball to get "stuck in the rafters" as it were. This is pretty rare, but I have seen it happen. 2. It needs to be flicker-free. This is doable, but you'll need to upgrade to the multisprite kernal -OR- write a kernal in embedded ASM. This is what I'm having some trouble on, I can't quite figure out how to port Atari OS to the multisprite kernel (v99b) because I wired it so that the click detection is controlled by whether it's displaying one sprite (f = 0) or the other (f = 1). Also i've had just some pure general problems with the kernal (tested working code won't compile) . I also don't know where to start IF I WROTE a multisprite kernel. I had some trouble compiling AtariOS on the later version, too. The "c = c + 1" doesn't seem to be generating valid code. Without diving into bBASIC to see what's actually wrong, I'd guess that you have too many commands on one line, possibly causing a buffer overflow or truncation. The click problem is easily solvable with bounds checking. Put simply, the icon describes a square. Anything inside that square is a "hit" area. Anything outside the square is a "miss" area. When you "hit" the square, a click should be registered. For example, this is the pong icon: .X...... .X...... .X...... ....X... ........ ......X. ......X. ......X. It's 8 pixels wide by 8 pixels high. Which means that the four sides would have these coordinates: 0,0______7,0 | | | | | | 0,7______7,7 If we place it at 10 pixels to the right, then we need to add ten to each of the X coordinates: 10,0____17,0 | | | | | | 10,7____17,7 If we then place it at 10 pixels down, then we need to add ten to each of the Y coordinates: 10,10__17,10 | | | | | | 10,17__17,17 With those coordinates, we can check the bounds like in this psuedocode: let result = true if cursorx < 10 then result = false if cursorx > 17 then result = false if cursory < 10 then result = false if cursory > 17 then result = false rem Do something here if result is true! Does that make sense? 3. It should be functional enough that it is not considered a tech-demo. I presume this means you're looking to add more programs? Yes, but to a reasonable degree. I don't plan on even writing ten. Just enough so it doesn't strangle me with work, but enough so it isn't boring. (3 - 4 programs) . Besides, I'm working with limited rom space here. The cart I ordered, (and what I want it to be) is 4k. I don't think that 10 is unreasonable if you have the space. It all depends on the particular set of programs. You probably want to draw up a list of which programs you think you want, order them by which ones are the highest priority, then work on them from high to low priority. If you run out of space, you simply leave out the low priority programs. What I meant by computer-like functionality was something like a basic interpreter, powerful enough to drive the system, but doesn't clog precious rom space. I don't plan on porting windows xp pro to the 2600.I will add what I CAN with what was said the last paragraph. I don't think you have room for a BASIC interpreter. Just the symbol table alone would kill you, much less the function support. Besides, the 2600 isn't very good at text. Thx for the support. I didn't expect as much. Just keep note that I am new(er) at this thing we all call "programming" (I started programming in Qbasic for ms-dos a few years ago (about 3) and I'm sort of in that "i need to find a better language to use" phase) and can't whip out assembly code faster than reading what was just said (or even a bug list for windows )so don't expect the atari to be revolutionized per-say. Expect batari basic be well....just used. PERIOD. But thx for your help. It's nice knowing I'm not the only one going into programming this 30-year-old marvel. Well, feel free to ask questions. I have a lot of information crammed up my noggin' (ow, ow, ow!), and can usually find anything I don't know or am unsure about. Asking questions is how you learn, so don't be afraid to ask. Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 20, 2006 Author Share Posted July 20, 2006 Hey everyone! I'd like to post Atari OS's schedule for the next few weeks so people can see where I'm going with this. 1. "upgrade" Atari OS from Batari basic version .35 to version .99b thus removing the flicker. 2. Update the collision detection (mouse-click wise) so you don't have to be right on the icon for it to open 3. remove the reset function (right now all it is is an annoying waste of space) and standardize that reset = exit program 4 port: -calculator 5 fix pong bug 6 clean resulting code ....so theoretically right now Atari OS v1.0 is more like version .90 but that's another story....... Just to help me remember here is my Atari OS cartridge to do list: 1 find a way to burn an eprom at a VERY reasonable cost (<$30.00) 2 burn game code on 3 solder to board 4 put the case together and attach the label and done! There it is, I hope your not overwhelmed, because I sure am. I'll try to post the multisprite kernel update A.S.A.P. Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 20, 2006 Share Posted July 20, 2006 2. Update the collision detection (mouse-click wise) so you don't have to be right on the icon for it to open 4 port: -calculator I did up a Calculator screen to help you out: Binary: AtariOS.binSource: calculator.zip It's non-functional (I figured I'd leave that to you. ), but it is a complete interface to get you started. You'll need item 2 to make it functional, as well as APIs for handling the mouse. You'll also need to replace the score at the bottom with something else once you move to the multisprite kernal. Here's a few screenies: Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 20, 2006 Author Share Posted July 20, 2006 I did up a Calculator screen to help you out:Binary: AtariOS.binSource: calculator.zip It's non-functional (I figured I'd leave that to you. ), but it is a complete interface to get you started. You'll need item 2 to make it functional, as well as APIs for handling the mouse. You'll also need to replace the score at the bottom with something else once you move to the multisprite kernal. Here's a few screenies: That should help, thx. Quote Link to comment Share on other sites More sharing options...
mos6507 Posted July 21, 2006 Share Posted July 21, 2006 I don't think the B&W switch is really necessary. In fact, I never really understood it to begin with. B&W TVs generally ignored the colorburst information, so it always seemed kind of redundant. I suppose the programmer could try to tweak the game that way, but by the late 70's B&W for the family television was on its way out. (It still survived in portable TVs and Servalan's televiewer console, however. ) Same reason B&W cinematography is different from color photography. It's because two colors of the same brightness when rendered to B&W will appear to completely blend together into one. Games that do the B&W thing properly adjust the palette to get enough contrast so this doesn't happen. They shouldn't just chop the chroma off the color setting. For instance, in a game where one player is bright green and another is bright red, same brightness, when rendered to B&W they will both appear white. The proper thing to do is drop the brightness of one player down to a medium grey. Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 22, 2006 Author Share Posted July 22, 2006 (edited) Hey everyone. I'm (still) plunking along on the multisprite kernel and ran into a small pronblem..... MY CODE ISN'T COMPILING!!! Here it is. AtariOS.bas Any suggestions? It's compiled using Batari basic v99b Edited July 22, 2006 by Dragnerok X Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 23, 2006 Author Share Posted July 23, 2006 Well...still debuging. I have good news though. I was able to find that when I took out the code for the pong game in the source, I was able to get a (slightly) more helpful error message . Instead of getting a bunch of jumbled up numbers it listed a few unresolved symbols! A still am having quite a bit of trouble with the multisprite kernal and would like as much suggestions as you can on what I have to do to get this running . Here's the more helpful source. HINT: Try compiling it. AtariOS.bas AtariOS.bas Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 23, 2006 Share Posted July 23, 2006 I haven't been able to find the necessary docs yet (I'm feeling kind of sick, so you'll have to forgive me if I'm a little slow to help), but I'm guessing that the multisprite and ball might be incompatible. Use the corner of a sprite instead. You could even give it a cool looking image. Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 23, 2006 Author Share Posted July 23, 2006 I haven't been able to find the necessary docs yet (I'm feeling kind of sick, so you'll have to forgive me if I'm a little slow to help), but I'm guessing that the multisprite and ball might be incompatible. Use the corner of a sprite instead. You could even give it a cool looking image. Oh, I see. It's fine. I'll figure it out. Besides, back in the 70's and 80's the developers didn't even have THIS much time (think of E.T.). Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 24, 2006 Author Share Posted July 24, 2006 I haven't been able to find the necessary docs yet (I'm feeling kind of sick, so you'll have to forgive me if I'm a little slow to help), but I'm guessing that the multisprite and ball might be incompatible. Use the corner of a sprite instead. You could even give it a cool looking image. Oh, I see. It's fine. I'll figure it out. Besides, back in the 70's and 80's the developers didn't even have THIS much time (think of E.T.). Well I was able to solve the problem myself! The problem was my code was WAY to cryptic and I was able to solve it by taking the source from my last stable release (which was irronically the source you suggested me to put on this site) and decided to update it from there doing as many of the changes *now* as I can, not while porting to the multisprite kernel. I was able to get quite a bit done (Remove the reset function, lay your pong code nicely in a segment of atari os perfectly, and even start plunking along on the pong bug!). I also concluded my goals as of now are slightly unrealistic so I updated my to-do list. 1. "upgrade" Atari OS from Batari basic version .35 to version .99b thus removing the flicker. 2. Update the collision detection (mouse-click wise) so you don't have to be right on the icon for it to open (I am working on an Icon for pong right now which is easier to click on.) 3. remove the reset function (right now all it is is an annoying waste of space) and standardize that reset = exit program done! 4 port: -calculator Decided pong was good enough ( Yes, this will be a fairly advanced tech demo) 5 fix pong bug...working on... 6 clean resulting code Oh, BTW is it just me or has this topic been horendously empty lately . I haven't seen anybody else for nearly a full page!!! Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 24, 2006 Share Posted July 24, 2006 Well I was able to solve the problem myself! The problem was my code was WAY to cryptic and I was able to solve it by taking the source from my last stable release (which was irronically the source you suggested me to put on this site) and decided to update it from there doing as many of the changes *now* as I can, not while porting to the multisprite kernel. I was able to get quite a bit done (Remove the reset function, lay your pong code nicely in a segment of atari os perfectly, and even start plunking along on the pong bug!). I also concluded my goals as of now are slightly unrealistic so I updated my to-do list. 2. Update the collision detection (mouse-click wise) so you don't have to be right on the icon for it to open (I am working on an Icon for pong right now which is easier to click on.) I still highly recommend you do this. It's not a critical priority (especially now that you've eliminated the calculator), but you might consider putting it on the bottom of the list. It will really improve the ability of the "OS" to function. Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 24, 2006 Author Share Posted July 24, 2006 I still highly recommend you do this. It's not a critical priority (especially now that you've eliminated the calculator), but you might consider putting it on the bottom of the list. It will really improve the ability of the "OS" to function. Sure! I'll see what I can do... Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 24, 2006 Author Share Posted July 24, 2006 I think I fixed the Pong bug! Try this!!! pongtari.bas.bin Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 24, 2006 Share Posted July 24, 2006 I think I fixed the Pong bug! Try this!! I presume it was a one line fix? Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 24, 2006 Author Share Posted July 24, 2006 (edited) I presume it was a one line fix? Exactly, All I did was stick this line in just before it checks the vertical position if temp1 < 15 then goto SetBallHeight ...and that way if it IS under 15 it re-randomizes it. Edited July 24, 2006 by Dragnerok X Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 24, 2006 Share Posted July 24, 2006 All I did was stick this line in just before it checks the vertical position if temp1 < 15 then goto SetBallHeight ...and that way if it IS under 15 it re-randomizes it. There's a much easier fix. Just add 25 to BallY just before the "return" statement. i.e.: SetBallHeight temp1 = rand NormalizeBallHeight if temp1 > 55 then temp1 = temp1 - 55 : goto NormalizeBallHeight BallY = temp1 + 25 return That will also stop the ball from favoring the top of the screen. Mathematically, I intended for the ball to appear within the middle 55 pixels of the screen. (The playable area is 75 pixels. 75 - 20 = 55) To accomplish this, I intended to use the following formula: BallY = rand%(75 - 20) + (20/2) Where rand is a value from 0-255. Simplifying, the formula ends up like this: BallY = rand%55 + 10 Unfortunately, I made a mistake, resulting in the formula being like this: BallY = rand%55 Whoops. In addition, there's a 15 pixels border at the top of the screen which must be accounted for. Which makes the final formula: BallY = rand%55 + 25 Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 24, 2006 Author Share Posted July 24, 2006 All I did was stick this line in just before it checks the vertical position if temp1 < 15 then goto SetBallHeight ...and that way if it IS under 15 it re-randomizes it. There's a much easier fix. Just add 25 to BallY just before the "return" statement. i.e.: SetBallHeight temp1 = rand NormalizeBallHeight if temp1 > 55 then temp1 = temp1 - 55 : goto NormalizeBallHeight BallY = temp1 + 25 return That will also stop the ball from favoring the top of the screen. Mathematically, I intended for the ball to appear within the middle 55 pixels of the screen. (The playable area is 75 pixels. 75 - 20 = 55) To accomplish this, I intended to use the following formula: BallY = rand%(75 - 20) + (20/2) Where rand is a value from 0-255. Simplifying, the formula ends up like this: BallY = rand%55 + 10 Unfortunately, I made a mistake, resulting in the formula being like this: BallY = rand%55 Whoops. In addition, there's a 15 pixels border at the top of the screen which must be accounted for. Which makes the final formula: BallY = rand%55 + 25 Wow, that works great! I see what you mean. I guess than I should update my to-do list. 1. "upgrade" Atari OS from Batari basic version .35 to version .99b thus removing the flicker. 2. Update the collision detection (mouse-click wise) so you don't have to be right on the icon for it to open (I am working on an Icon for pong right now which is easier to click on.) -- going to work on next. 3.remove the reset function (right now all it is is an annoying waste of space) and standardize that reset = exit program done! 4. fix pong bug Done! 5. clean resulting code Oh, and if you ever get bored here is the final pong binary. Pong.bin Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 26, 2006 Author Share Posted July 26, 2006 I'm still working on getting the collision detection to work for me, but I'd like to post the newest stable release and it's source because it's DEFINETLY been a while. Sorry I'm taking so long on this, i've been quite busy lately so forgive me . Oh, here it is. AtariOS.bas AtariOS.bas.bin The good news is is it's pretty stable so it shouldn't take me that long to finish this after i'm done fixing the collision detection so expect the true 1.0 release real soon! Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 26, 2006 Author Share Posted July 26, 2006 Finally! I just finished adding the "smart" collision detection jbanes earlier asked for . It works great . This way you don't have to be touching an icon for it to open, you just have to be in it's general 8 x 8 pixel area. Now all I have to do is get rid of the icon flicker (the hard part) by porting it to the Multisprite kernel unless I can find an easier way (like that's ever going to happen ) I am nearly done though so expect, like I said earlier, this to be finished real soon. BTW here are the updated files. AtariOS.bas AtariOS.bas.bin Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 26, 2006 Share Posted July 26, 2006 Finally! I just finished adding the "smart" collision detection jbanes earlier asked for . It works great . This way you don't have to be touching an icon for it to open, you just have to be in it's general 8 x 8 pixel area. It works beautifully! Good job! Now all you need to do is make it a generic routine rather than hardcoding the parameters. Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 26, 2006 Author Share Posted July 26, 2006 (edited) It works beautifully! Good job! yes, it does. Now all you need to do is make it a generic routine rather than hardcoding the parameters. Well...first things first. I have to get rid of that annoying flicker. I'm still a little bit stumped on how i'll pulll this off though . I just can't "port" it to the multisprite kernel. It's WAY too buggy and everytime I have tried porting it, no matter how much sense it makes, i get an error message. Ugh! I've gotten this far though so there HAS to be a way to do this....... Edited July 26, 2006 by Dragnerok X Quote Link to comment Share on other sites More sharing options...
jbanes Posted July 26, 2006 Share Posted July 26, 2006 Well...first things first. I have to get rid of that annoying flicker. I'm still a little bit stumped on how i'll pulll this off though . I just can't "port" it to the multisprite kernel. It's WAY too buggy and everytime I have tried porting it, no matter how much sense it makes, i get an error message. Ugh! I've gotten this far though so there HAS to be a way to do this....... Have you tried asking Batari about the error message? He's the one most familiar with the multisprite kernel, so he should be able to get you on the right track. Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 26, 2006 Author Share Posted July 26, 2006 Have you tried asking Batari about the error message? He's the one most familiar with the multisprite kernel, so he should be able to get you on the right track. Hmm.....How obvious! Thx! Quote Link to comment Share on other sites More sharing options...
Dragnerok X Posted July 30, 2006 Author Share Posted July 30, 2006 Well I'm back after a couple of days and it sounds like Batari basic 99b just won't work for this... Not only would I end up having to rewrite the whole OS, but I would also have to make the cursor (ball) 1 pixel high (it doesn't support ballheight). So, on a lighter note does anyone have ideas on how I could at least REDUCE the flicker to a tolerable level? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.