potatohead

As for the ball movement, if you factor out english (paddle velocity), then you can divide the paddle into zones. Change the ball angle depending on the zone. You do this by comparing the paddle x coordinate and the ball x coordinate at the moment they collide.

I'm a bit old school in that regard. If there is a register, I prefer to just use it as I would any other variable.

I didn't see any DIM statements, what in the world is CXP1FB? That's a collision register. All of the key memory addresses has a label like this. Sometimes, it's easier to just use the label than anything else. Here is one list of them, I know there are others: http://alienbill.com/2600/101/docs/stella.html There are things that happen in the 2600, such as a bit getting set when the playfield and a player overlap. Those bits exist at the memory addresses defined by the label. The statement in the sample game checks to see if a player (the ball shape) touches the playfield. If it does, then the brick closest to the ball (based on it's xy coordinates) is removed.

Here is that old version. Took a while to track down the post. http://www.atariage.com/forums/index.php?s...72428&st=50 1 rem smartbranching on 5 AUDC0 = 12 : AUDF0 = 3 10 x = 50 : y = 90 : w = rand : v = 60 11 d = 1 : e = 255 : f = 0 : g = 0 : h = 1 : i = 0 : j = 0 : k = 0 : l = 0 12 if w > 100 then w = 100 14 if w < 40 then w = 40 20 COLUPF = 54 : COLUBK = 17 22 pfhline 0 2 31 on 23 pfhline 0 3 31 on 30 COLUP0 = 120 : player0x = x : player0y = y : l = l - 1 40 scorecolor = 10 45 player0: %01000010 %11111111 %11111111 %00000000 end 46 player1: %00011000 %00111100 %01111110 %00111100 %00011000 end 47 a = a + 1 : if a < 3 then 90 49 a = 0 : i = INPT4 51 w = w + d : v = v + e 52 if l = 0 then l = 4 : w = w - d 64 player1x = w : player1y = v 65 pfvline 0 0 11 on 66 pfhline 0 0 31 on 67 pfvline 31 0 11 on 68 pfhline 0 11 31 on 69 AUDV0 = 0 90 drawscreen 92 f = x + 250 : g = x + 5 93 if CXP1FB < 64 then 154 94 if l = 1 then 154 110 j = w - 28 : j = j / 2 : j = j / 2 112 pfpixel j 3 off : l = 1 118 AUDF0 = 58 : h = 1 130 if e = 1 then e = 255 134 if e = 255 then e = 1 154 if v > 88 then 159 157 goto 173 159 e = 255 : h = 1 : l = 0 160 if w < f then e = 1 : h = 0 : AUDF0 = 50 162 if w > g then e = 1 : h = 0 : AUDF0 = 50 173 if v < 15 then e = 1 : h = 1 : AUDF0 = 40 : l = 0 175 if w > 148 then d = 255 : h = 1 : AUDF0 = 70 : l = 0 177 if w < 35 then d = 1 : h = 1 : AUDF0 = 70 : l = 0 179 if h = 1 then h = 0 : AUDV0 = 15 180 if joy0left then x = x - 1 190 if joy0right then x = x + 1 195 if i < 15 then 5 200 goto 30 This was waay back in bB history. Line numbers required, only simple expressions allowed, etc.... Maybe I'll do this again with the latest version.

I wrote that. It was the first build of bB that Batari released. I'm not sure the code would run, unchanged in more recent versions of bB. The machine I wrote it on is not up at the moment. I've got to power it up anyway for some unrelated things, I'll go digging to see what I find.

Ahh but he did his job well. That frustration you feel when the pixellation is at it's peak, is a cultivated thing. Without it, Tempest 2000 would be a great game, but would not so easily invoke that trance state all shooter, twitch gamers go for. Pixellation at it's finest! That kind of thing is rare these days.

The 400 and 5200 have 16K of RAM. The 7800 has 4K. Those two machines also include a 160x100 graphics mode which uses 4K of RAM for a full-screen bitmap; the 7800 has no such mode and would thus likely require 8K of RAM for a 160x200 full-screen 4-color bitmap. I keep hearing about these limitations on the 7800... sounds to me like the old 2600 is actually more flexible --or nobody has really put the screws to the 7800 just yet. Couldn't sprites be dynamically aligned where they need to be to draw the lines? No worse than the 2600 way of doing things is it?

This is a wonderful game. It's on my list of carts to purchase this year. (Playing the RC release right now and it's solid!)

Isn't the word Album still appropriate as in a collection of individual recordings? Asking if one has gotten the LP or the Record is old news, but an album is still an album, regardless of the media carrying it. (Tape, CD, Vinyl, 8 Track, Zip file, mp3, etc...) Think of it like Photo Album, which is a collection of individual photos.

No kidding. Back then it was possible to completely understand a computer. Well, a lot more completely than is generally possible today. Of all the Atari machines, I like the 400 for it's sleek lines and the 2600 because the original said Video Computer System on it. There was an air of professionalism and innovation to that name that really stuck in my mind. Fast forward to today... I've still got the 400, looking to get a 2600 that says VCS on it and a 7800 + supercharger. For me the real interest was the technology vision --lots of interesting ways of doing things on the Atari --some of which are still relevant today. I guess that's not totally honest. I also loved --and still do love the hardware. Jay Miner had a special touch when it came to these things. The Atari video sub-systems (one could argue the 2600 is a video sub-system that just happens to play games!) are a wonderful melding of software and hardware. This has turned out to be distinctive as new display techniques have been innovated to this day. The smarter you are, the more the machine will do. Not many other systems are like that. Those two attributes remain a core influence on how I view computing today. Having multiple platforms, each with strengths and weaknesses, serve to highlight the difference between what is computing and the actual computing platform used to compute! That may sound Zen, but it's as important of a realization as the difference between software and data, for example. I'm glad I got to learn computing when I did. It's a wonderful time when one could go to the grocery store and purchase magazines filled with code, news, games and HACKING! Not only was hacking accepted, but encouraged! Getting more out of your hardware and making it do what you want were the issues of the day. Somehow in this bland, largely win32 and Mac world, we have lost some of that. (Well, unless you embrace the beast that is Linux!) My old 400 and 7800 are connected to an SGI indy. I use the video in to display their displays in a little window, not unlike the one you get when you run an emulator. Puts things in perspective some times. Somebody needs to make a $50 computer that connects to a TV that makes use of the amazing portable media we have today. Make it open, simple with a good CPU that is easily programmed in assembler. Mix in a Jay style video system with just enough limits to make creating displays and games the artform it is on the Atari machines. (And it is art too. Look at the excellent homebrews seen here these days. Done for the fun of it, they all would be worth millions back in the day. We won't see the same for modern day machines because the simple joy of computing and the art of realizing immersion within sharp limits is not there on modern hardware.)

Good catch! New build: - fixed a bug that would cause a level to skip if the last letter in EXTRA or SPECIAL was collected to finish the current level Thanks! PS: New high score: Part 23: 435,220 Just tried playing this one. Great job BTW! It's stuck on the first screen. All dots gone, but no advancement to the next level. Playing on the latest Stella release.

I started a couple Supercharger games, but found it hard to get excited about coding for a platform that requires exotic hardware but can't use it to anything near its capabilities. Something like 4A50 seems much more interesting, though I'm wondering whether I should have included "magic writes". They're rather nice, but they mean that 4A50 games won't be supportable on the Krokodile Cart. The magic writes are not the only reason why 4A50 can't be supported. The chip is full and I simply can't support anything new with the current design. So it would make very little sense to modify your design. If I had space, the next thing I would add is F0, E0, AR or FE (because I think the original bs modes have highest priority). And If I should ever make a modification to the Krokodiles design, then I can support 4A50 no matter how it would finally look like. I want the 4a50 to become a reality. The magic writes are gonna open some doors that will make very good use of the hardware. In the end, they will be worth it, IMHO.

(big ass quote removed) Yeah, got rid of my CoCo 3, but kept the Atari too. Still miss that damn 6809 though. I've always thought at 6809 computer with atari style hardware would be damn cool. Wonder if that's possible in the older A8's where the CPU is on a card? "Jay Miner got it" --yes he did. Software controlled video hardware forces a style of programming that is keyed to the video output. It also allows for innovation to occur that can extend the life of the system far beyond it's years. For me, watching that happen and tinkering once in a while, is what makes the Atari machines stand out. Machines with Jay's touch are really Atari machines. (Which is exactly why I never owned an ST.) Jay went on to create many specialized display systems for medical imaging and other highly sensitive visual applications. Too bad his vision never moved forward past the Amiga in the home computer scene. Wonder how he would have done 3D? There is a strong case for saying most of the 8bitters participated in the revolution in some way too. All of them brought something interesting to the table and got a lot of us computing. One nice thing about that time was the differences. If a person had exposure to different machines, then that thing we call computing became seperated from the hardware in a healthy way. I run Linux, IRIX and win32 today for that very reason. Having different platforms around feels like home in a way that's hard to explain? Anyone here feel the same? Another thread idea maybe: What machines today are the most Atari like? I nominate the SGI O2 as one. Cool custom hardware, Unified Memory Archeture (however you spell it), interesting GUI, video in, out, etc... Kind of closed such that it takes some hacking to really make the chips go, etc...

I think it's OS was revolutionary. Device independant I/O, in 8K of assembly was no small feat. The while interrupt driven display system was revolutionary too, display lists in particular being a distinctive feature at the time. Open? Nope. Ataris were closed as hell. I had a whole lot of fun on My Atari --still do. But it was the totally open Apple ][ that showed me the ropes. I had to spend money to do cool things on the Atari in assembler. The apple came ready to program on all levels out of the box. Big difference. Expandability was a big minus with the Atari, on the other hand, having 4 bi-directional latched I/O ports was a big plus. Most powerful? Apple ][, because of it's ability to scale. I'm gonna set all of this aside though and point to the CoCo 2 & 3 as the most powerful 8Bitters around. Too bad we didn't see the 6809 in more 8 bit machines. Pure assembly nirvana.

Get UFO. Simple shooting fun. Lots of moving things and an interesting play dynamic. I didn't play very many games on the O2, but just loved that one!

Good work so far. Where the author has posted their source code, you should include it as well. Having just the binaries kind of limits the overall utility of an archive, IMHO. Also, in the Homebrew Discussion forum, Ooze is at version 0.9x. Probably should get that one and source from my blog (if you are gonna do sources.) Another source of games is the computer science students projects. Might be a good idea to contact the instructor to see if those games can be archived as well. That thread is in the Basic Programming forum. I would link, but am short on time. Sorry...

Totally. Old hardware is just cool! That's why I'm involved when I can. And it is good!

Put me in that boat too (there is light at the end of the tunnel though) Greets, everyone!

Hi! I've got a Jag, AvP, Tempest 2000 and Doom. We get it out to play the first two games every so often. Would I buy a homebrew? Yes, if it was a game I like.

Ah... never really occurred to me... can you just copy Starpath games with a dual deck cassette player? Yep. First thing I did was make a backup and play from that. My Starpath games work to this day.

Ditto Batari's lifesaver... lots 'o fun and fairly easy to grok out of the gate. I'm wondering if 8bit assembly newbies would not be better off doing some simple things with the Atari 8bitters in emulation. That's how I started on assembly language and I remember much of it to this day. It's much easier to do little things in assembly, within an established framework, than it is to just haul off and do the whole works in assembly from the get go. Of course, that's what Batari Basic is all about too... just rambling this afternoon I guess.

Breakout

The DC does not require kernel time. However, I have had some trouble reading it in bB - I could never get the assembly routines posted by Thomas to work, so I wrote my own rather inefficient (but 100% working) routine and posted it here: http://www.atariage.com/forums/index.php?showtopic=87310 In other news, the bB kernel now has paddle support in exchange for Missile 1. I have been doing some bB kernel hacking lately, and in doing so I've been finding cycles where I never thought I would. The SBX instruction is proving to be indispensable. For example, there have been requests for a kernel with no blank lines between playfield blocks. This is also now an option by removing missile 1. However, in doing so, I found free cycles, which was enough to read any of the four paddles, so I decided to make paddle reading a feature of the no-blank-lines kernel option. Well, it's not perfect, as the paddle is read only every other scanline, so on the horizontal axis this translates to roughly a 2-pixel resolution (but should be adequate for most games.) You can also read multiple paddles, but must do so on alternate frames. The driving controller is worse for a game like Ooze, as the DC has just 16 positions. However, I posted a demo a while back showing how one can measure the angular velocity of the DC and move a variable number of pixels accordingly. The end result is workable, if a little choppy. It takes a while to get accustomed to the control, but once you are used to it, it can feel much like a paddle. Demo is here: http://www.atariage.com/forums/index.php?a...e=post&id=41269 Note that the demo must be played on real hardware with a real DC. It will not work as expected in any sort of emulator, as these limit the DC to a fixed angular velocity. As usual, nice work Batari. I can't wait to begin toying with this stuff again. It's a ton of fun compared to the nasty systems I deal with daily... Many thanks (I think) for creating such a wonderful timesink!

Just checked in... This is REALLY COOL. Keep up the good work!

My thought on the driving controller was to treat it as a joystick, and nestle the reads in the game logic code. There is enough time, I just don't know if there is enough consistancy. Should be entertaining to find out. At least with the driving controllers, small timing differences won't result in jitter when the player is not interacting with the controller. However, there might be jitter on motion as well as a general inability to read the device fast enough to track state changes. We shall see. Native windowing systems are a problem, if they are other than X window ones! That's a big reason why I run Linux / IRIX as my main desktop. On win32 Exceed is just great and interacts nicely with win32 desktops, but it's pricey... I've not had any real trouble with network traffic. Guess the networks I work on are fast enough. Low latency is important though. Agreed on focus issues. Having the background I do, the default win32 focus drives me nuts! Should be able to interact with a window without having it pop to the foreground... point to focus and click in border to raise is my favorite --particularly when doing admin with lots of shells. Ordinary users hate this however, so I use Exceed and the native win32 window manager. That way the focus behavior is what they expect. A font server is a must, once done it can be left on and running no worries there. Managing processes is a nasty one sometimes... A lot of what I have done over the years involves a couple of high-end applications. Once their behavior is known, a few scripts to assist program start and exit do wonders. It's a tradeoff to be sure. Given the current mess win32 makes, I'll take these problems any day of the week over registry coruption, dll conflicts, and virii / malware. Things in win32 land are nicer these days for sure. I do manage both and find myself thrashing in win32 land far more than I do Linux / Unix land. IMHO, it's easier to know exactly what the machine is doing in Unix land than it is under win32. Too many things lumped together and too difficult to limit what a user can and cannot do. For win32, the core permission set and management tools recently released are actually quite good. Problem is most developers have not taken the time to code their stuff in a way that makes sense given the needs of administrators today. It will catch up, but it's just not there yet... On the matter of security I've got problems on both sides of the fence.... It's just tough today, no getting around it. I tend to have strong outer layer security, then different subnets internally depending on the user needs. This is one thing X is nice for. It is possible to have one box locked down tight, only allowing an application server to serve it's application on managed data. Users can't touch anything on it, except via X. For engineering CAD data, for example, this is just fantastic in that the same system can run for years without any real need to manage it's interactions with the rapidly changing client environment and it's potential contaminants. You give up some nice integration, but you get robustness and consistancy in return. Not a bad tradeoff, IMHO.