Jump to content
IGNORED

Atari OS - Finished!


Recommended Posts

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. :ponder:

 

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. :D

 

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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....... :roll:

 

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) :sad:

 

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.

Link to comment
Share on other sites

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:

post-8100-1153418257_thumb.pngpost-8100-1153418248_thumb.png

Link to comment
Share on other sites

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:

post-8100-1153418257_thumb.pngpost-8100-1153418248_thumb.png

 

That should help, thx. :)

Link to comment
Share on other sites

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. :P)

 

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.

Link to comment
Share on other sites

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 :roll:. Here's the more helpful source. HINT: Try compiling it.

 

AtariOS.bas

AtariOS.bas

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.). :D

Link to comment
Share on other sites

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.). :D

 

Well I was able to solve the problem myself! :cool: 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 :roll:. I haven't seen anybody else for nearly a full page!!! :o

Link to comment
Share on other sites

Well I was able to solve the problem myself! :cool: 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!).

:thumbsup:

 

 

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. :)

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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. :D

Edited by Dragnerok X
Link to comment
Share on other sites

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. :D

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. :ponder:

 

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

Link to comment
Share on other sites

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. :D

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. :ponder:

 

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

Link to comment
Share on other sites

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 :D . 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!

Link to comment
Share on other sites

Finally! I just finished adding the "smart" collision detection jbanes earlier asked for :cool: . 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

Link to comment
Share on other sites

Finally! I just finished adding the "smart" collision detection jbanes earlier asked for :cool: . 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. ;)

Link to comment
Share on other sites

It works beautifully! Good job!

 

yes, it does. :D

 

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 by Dragnerok X
Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...