Luigi301

It's pretty easy to modify this kernel to allow paddle control but you'll need to sacrifice one of the objects. Which object would you be willing to give up: player0, player1, missile0, missile1, or the ball? 972402[/snapback] missile1 can go, I'm not using it. Okay, here's my "cleaned up" version, which does more or less the same things that your original code does. (Paddle 0 is getting positioned a little to the right of paddle 1, even though they have the same X position, don't know why.) I added some DIMs so that all variables have meaningful names, and I made a few other changes, so you might want to compare it closely to your original code to see if there's anything you want to change back. Well, now I'm not checking p against j so it's not bigger than q! As it is, there are a few problems with the code that you need to work out, mostly dealing with how the ball hits the bricks. For one thing, your routine to turn off the bricks when they're hit is turning off only the bricks in row 7. This can be fixed by calculating the bricky position in a similar manner to the way brickx is calculated. Also, it's possible for the ball to hit more than one brick at once, which is why the bricks in the middle don't get turned off when the ball keeps hitting them (the calculation to get the equivalent brick position keeps returning the brick that's already been turned off, since the ballx position straddles two bricks). Also, if the ball hits the side walls without actually hitting a brick, you want to bounce it but not turn off any bricks, so your "hit_something" routine needs to check for that. And I figure you might want to modify the way the ball bounces so it doesn't always go back the way it came (e.g., after the first hit, bounce it down to the left instead of back down to the right). I wasn't finished with the routine, which is why it's horribly broken. The hardest part about getting a brickrow value is turning bally into a value that corresponds to a row number. Also, the ball going off the bottom isn't quite working yet. bally eventually wraps and the ball appears at the top of the screen. PS -- The good news is that I redesigned your make_screen routine in a way that uses up less ROM, so there's more room for additional levels-- although the logic to handle the ball/brick problems mentioned above will eat up most of the saved ROM, if not more than what was saved. 600 bytes saved? Shows how bloated my code is. 972436[/snapback]

I didn't see a lot number on the PCB, just a sticker with an alphanumeric sequence on it. The same sticker was on the switch panel board and RF shield itself.

Nintendo can throw money at the Revolution if they need to in a hurry. As of July, they had over $7.5 billion in liquid cash reserves.

I think we need a WHORE-OFF!

So basically you buy the main unit with a buggy version of the game then they squeeze $10 out of you for a fixed version?

Nice. Better than my 2600 bitmap viewer! *shudder*

Yeah, it's getting too hard to add things without fixing pieces in 10 different spots. Here's my latest code. breakout.bas

Where do you mean, on the inside of the shield itself or on the PCB? I didn't see a lot number on the board.

I tore it open, and confirmed it was a Heavy Sixer. The switch panel board had "Atari: Intelligent Design" and "Rev B" silkscreened onto it. The main PCB, surrounded by thick shielding, had © 1977 silkscreened, along with three sets of initials. I guess that'd make it a 1977 model, one of the first few lots?

I'm going to pop the thing open to see if I can find a date or lot number. Is there anything I should watch out for so I don't break it, or is it a simple unscrew-and-pull like the 7800?

Well, that was odd. I tried to hack in paddle support to my program and somehow made my bat's position COLUPF, even though I didn't touch COLUPF!

I had a custom paddle kernel by batari, but Alpha 0.3 broke it. I'm using joystick controls right now.

Collision detection works! DONE: Paddles Graphics Engine Controls 5 screens Ball Collision Detection TO DO: Scoring More screens Bugfixes

My game might be done by Christmas*, I could turn the bricks into santa hats or something *2006

Yeah, having un-spaghettied code would really help And so would that Stella with uber-debugger someone posted a few months ago, is that out yet?

Borrowed a friend's camera.

Aha, got it. The side molding on izzy's goes from horizontal to vertical at a very tight angle. russell's goes up gradually. The side molding on mine goes up to 90 degrees at a gradual angle. Also, the rear marks on mine (LEFT CONTROLLER, etc) don't match up to izzy's, they're molded into the plastic instead of printed on it. Also, I've got speaker grilles, and no channel select switch. Based on that, I'd say I beat everyone in their Tele-Games oldness with an R-suffixed unit.

Gah, my camera's broken How can I tell if it's a Heavy or a Light?

Well... it weighs about as much as my Xbox if that counts for anything. I'll get a pic when I get home later.

I've got the lowest Sears number so far. 76861R, Mfg. by Atari for Sears-Roebuck, Sunnyvale CA. No channel select switch or hole.

What's the variable for paddle position in the default kernel? I get an error when I try to look at paddle0.

Did you see my reply from Oct. 21? The problem was being caused by a reference to a line number that didn't exist. So in making other changes, you probably fixed the line number problem without realizing it! Michael Rideout 970161[/snapback] I fixed that and it still didn't work, I figured out I was checking variable M, which I never set.

Just checked, my little bitmap drawer weighs in at 800 bytes. Not bad when images are 4 bytes each. DONE: Paddles Graphics Engine Controls 5 screens TO DO: Ball Collision Detection Scoring

I don't know what the @!*# I did, but it works again. Now to put in a working ball.

Heh, just realized that I've basically made a bitmap displayer with images weighing in at 8 bytes. Not bad, I guess.