potatohead

Addons? Got my demo board today. It's a fun little beasty. Actually I've a coupla questions: Anyone care to comment on the video in capability of the 7800? Let's say I generate a NTSC signal and insert it. Assuming the necessary timing information can be provided by the 7800 (CPU maybe?), is this an overlay, meaning I can generate my own video on top of what the 7800 already does? The chip I'm tinkering with has onboard timers and video generation. (Composite video only takes a coupla resistors.) Thinking of an interesting blend where maybe I don't do much with the 7800 Maria chip and have the propeller chip do video generation or maybe just sound, like adding a POKEY currently does. Lots of fun possibilities that appeal to me because it would be both a hardware and software project. The end result would be programmable and not too expensive to replicate either as very few additional components would be required. My other question is along the lines of why bother? Is this going outside the classic computing aspect of things too much? I personally like the older hardware because of the kinds of games created. There are enough limitations to force the kinds of games I've always loved. This little project would very likely not exceed that boundary so much as to reset expectations beyond those in the norm here. Opinons? On the off chance that this idea sees some real hardware, how do you guys figure out what a target price would be? I know the core chip is the $14.00 or so. 5 resistors, maybe a buffer chip to handle the 3.3V to 5V conversion will cost some smaller amount, maybe a coupla bucks total. There is an on board timer that I don't know too much about yet, but would probably suffice to eliminate the need for an external oscillator. The 7800 could provide a baseline for programmers to assess what their particular timing variance is. The only real issue would be peak compute. Some kits would run faster than others, but all would run at a more than acceptable minimum. 32Kb of RAM is onboard the propeller. Looks like I would need a cheap eeprom and socket for that too. 32Kb minimum. If I were to use the 40pin DIP package, a socket would be all that is needed to mate the chip to the board, thus making kits a viable option. How much are custom boards and who might make them? Programming happens via USB or serial. It would also be possible to feed data through the 7800 itself, but that has a lot of development issues. Programming components can be put on board, or an inexpensive adapter from the producers of the chip is available. The chip has onboard ROM that can communicate with a PC and can program the eeprom. One could just program it themselves too... Too many components to be viable at all? Thinking of three potential options: Fully assembled, plug and play board, with USB programming cable. Partially assembled board, with core components soldered, and a kit bag of goodies or let user aquire own or use stock. Completely unassemblied kit. I'm just musing right now, trying to consider what I might use this great little chip for. An early idea of price and hassle might tell me right away if this is not a direction I should go for anything other than personal reasons.

It's not really Atari related, though it may well end up being useful for something that is related down the road. Here the toy: http://www.parallax.com/propeller/index.asp Here's a better description: http://www.parallax.com/dl/docs/article/RO...-PropReview.pdf I bumped into this device on a lark basically. Was discussing CPU's on a thread here, mentioned the desire for a nice computer that's cheap sort of like the classic ones we all know and love. Somebody pointed me to the Xgamestation based on the SX chip. Interesting, but not exactly what I was looking for. From there, I landed on the Parallax site and read about this chip and just had to have one. The details are in the review I linked to above. What I liked was the very original multi-processing design, easy development, low barrier to entry for little hardware projects and built in software controlled graphics capability. I've been watching what some of the hardware wizards here do and it's interesting frankly. This toy will let me dip my toes into the hardware scene as well. It's a fast design, with a lot of flexibility and tradeoffs. Very intriguing from a computing for fun point of view. And that was the point really. I'm on the road a lot these days. During the evenings, I enjoy working on computing projects, such as the 2600 game I wrote with bB a while back. The portability of this device really makes it ideal for continuing to enjoy computing. The unique design really is interesting and looks to be a lot of fun. Haven't ever seen anything like it. The hotel room television can be used as the monitor to boot! How can you beat that! The most interesting aspect of the design is it's completely deterministic nature. There are no interrupts, just the 8 32 bit CPU's all equipped with their 512 longs of RAM, supplied from a 8K long central memory pool. All the CPU's share access to on chip resources in a round robin fashion, being able to execute their local code independantly. The assembly language is interesting as well. It's a complex instruction set design, featuring conditional execution, but not featuring indexing! So, self modifying code is the norm and one can get a lot done in a few instructions! One can develop programs either in the interpeted high level spin language, or low level assembly or a combination of both. The beauty of the interpeted language is the byte code interpeter is located on chip. The graphics are generated in software, with a couple of on chip bits providing low-level functionality. So, graphic modes are for the most part, what you make of them. This is very interesting to me as it's the funnest aspect of the Atari machines. I suspect the same innovation elements we've seen for the Atari chips will end up being in play here on this chip as well. BTW: This chip can output broadcast video on it's own! Not needed, since there is composite and VGA outs on the demo board I linked to. On chip RAM is a bit limited, but that really just adds to the fun of it. Data can be loaded from memory card devices, or eeproms, so larger programs are possible with some effort. No biggie. The guy that build the Xgamestation has built a game system around this chip as well. It's not available for ordering, but will be soon. I might get one of these, depending on where this initial step takes me. Info on that can be found here: http://forums.parallax.com/forums/default....25&m=131973 The biggie with that whole project is the sample programs and game development book that comes with the system. I think the book can be had by itself. If so, most all of the code will run on the demo unit I just ordered. I've had a rough few months since my failed move. Haven't been that active anywhere really. None of this means I'll be leaving the AA community. There are still things I want to do with Atari stuff. However, this new piece of hardware really looks to be fun in it's own way --fun in the same way classic machines are. Maybe somebody will craft an emulator so more folks can give this a try without having to get hardware. It's memory constraints would make it a perfect addition to the minigame compo! That's it for now. I'm waiting for the package and just thought I would check in!

Seems to me, you have tied the playing of the sound to the collision between the player and the playfield. Does this remain the case the entire time your sound is supposed to play? It's a whole second, probably not. You probably should seperate the two, so that the sound can be playing no matter what happens to the player object. That way, if you animate it, or move it in response to the collision, then the sound can run it's course.

Sweet! We live in one of the very best places IMHO! I've enjoyed watching all your creative efforts. You are clearly having a good time with bB!

Hey all, I've been busy lately... Been toying with Bb some recently. Lots of changes. A quick answer to 2600land's movement question prompted me to post this now before it slips again. It would be really handy to be able to push one var onto the stack, then pull it again. Of course this can be done with a temp, but I think less overall code would be used with a push [var], pull [var] instruction set. It's also very intuitive. a = x + 30 [some logic] push a a = a / 2 player1xpos = a + 30 : player0xpos = a + 60 pull a [more logic] Assume the stack is one level deep. (Which is all that is needed) Whatever is in the stack would be put into whatever var is named. push a a = a + 20 pull t : pull v Is this a savings over the usual temp approach? I kind of like it because it's more assembly like, IMHO. (Which is what bB is supposed to be about right?) I don't expect a response to this anytime soon. Just wanted to post it here for Batari when he once again sees fit to hack on bB. Maybe it's crap, maybe it's a good idea, but it's not forgotten this time!

Without using the fixed point math, posted above, you can do the following: Use a delay loop, so that the movement is only updated every so many frames. Setup a variable counter that counts from 0 to 3, or whatever you think is good. Let's say it's b, for now. Instead of updating your movement every frame, do this instead: if b = 3 then b=0 : x = x + 1 This will only happen every four screens, thus your movement will be 1/4 the full speed. 1/4 = .25 If you made the count three, instead of 4, then you would get 1/3 the full speed, etc.... You can vary the counter to change movement speeds as multiples of your 60 frames per second game loop. You can also change the x value from 1 to 2 or maybe 4 max, to get other movements. Using the two together gives you a fair number of different movement speeds possible, with only simple whole 8 bit number math. Another approach is to divide your movement before actually doing it. say x is the position to be moved, and you are adding 1 every frame. If you do this player1x = x / 2, then you essentially are moving every other frame, as in the example above. This only works for multiples of two, so x/2 x/4 x/8, etc.. are ok. x/3 is not, err is not the last time I tried it in bB. Think of binary numbers: 0000 = 0 0001 = 1 0010 = 2 0011 = 3 0100 = 4 etc.... a divide by two is just like lopping off the right most digit. 000 = 0 000 = 0 001 = 1 001 = 1 010 = 2 etc... All of this works for simple linear movements. Does not work for anything more complex, because it takes too many loops and divides to make any solid sense. If you need intertia, curves, accelleration, etc... Better to use the fixed point math. The divide takes more ROM program space, and the counter consumes a variable. The advantage of the divide is that you don't have to give up one of your few RAM bytes to get things done. An advantage of the counter is that you can use it for lots of things. It can control sounds, be used to trigger more than one movement (just need more than one if statement), etc... I used these techniques for my early game Ooze. Largely because I needed the space and the fixed point stuff was just not where it needed to be. You can find code in my blog. Some of the early versions are a lot simpler to read, BTW. It's a messy program, but it's got some of that stuff in there, along with flags.

This falls into the same category as the ending to the Sixth Sense and Empire Strikes Back. If you don't know by now, you deserve to have it ruined for you... Tempest Naah, it's way too good of a video game moment for that. Play on, and enjoy this game! It's got a great story and lots of interesting side tasks. FYI, the game goes way better if you spend a nice chunk of time battling. Spend a few days just leveling up. It pays off down the line when it all really starts to rock.

Something kinda like this? http://www.xgamestation.com/index.php Very interesting link. What a useful little chip that one is. Also found from that site is this: http://www.parallax.com/propeller/index.asp A simple game machine, like the XGS, that uses this chip as the core, is nearly complete. I really like the hardware aspect of this design, and it has some relevance in that it's modern and has many applications beyond just gaming. I think I'll pass on the XGS and follow this hardware for a while. Looks cheap, very powerful and a whole lot of fun. I'm wanting to get into the hardware aspect of things for hobby purposes. Both microcontrollers are very flexible and easy to put to use.

Night Driver. I know, wierd pick. But it's spooky. The blocky graphics and sound are just kind of off enough to really give the player a wierd feeling. Like the others, turn out the lights and crank the sound for a high contrast all 2600 gaming experience.

The CoCo3 had great graphics. No sprites though. I stand corrected. I agree. Was really thinking about the coco2. When displayed on a television, the 16 color mode would artifact into a pseudo 256 color mode, with most of the colors being pretty useful. Nice memory management unit too. The only real decent game I had for the system I used to own was Rad Warrior on cart. It played very well. Even without hardware sprites, the machine was fast enough to shove a lot of bits around the screen without flicker. I didn't vote though. The Atari 8bitters are my favorites for all time.

One vote for the tandy! Nice CPU, decent sound, but poor controllers and graphics... Bummer. Anyone play "Madness and the Minotar"? Was a fun real time text adventure game. Things were happening all the time. Type slow and miss out! (Sorry for OT)

8 bitters are simple. That's what attracts me. It makes fun experiences possible without having to have a phd in programming and or a small team to develop assets to go with it. Look at the home brews. Great fun from one person, or maybe a couple doing it because they can. The expectations are low too. That lets people explore all aspects of the presentation in a way that's very accessable compared to more complex machines. The system resources required to display a single desktop icon on more powerful computers will often exceed those of an entire 8bitter! Despite this, they are still fun and engaging machines. IMHO, the 8bit basic is pretty damn cool. I enjoyed it a lot more than I did other basics. I've often thought of getting an Amiga for the cool hardware. I don't bother because with that comes more complexity. If I'm gonna compute for fun 'n games, it's always a better experience on 8 bit machines. (Might eventually get another CoCo 3 though. I really miss programming the 6809. Somebody needs to make a $50 6809 game unit with Atari style graphics systems! Enough screen limitations to keep the 8bit allure alive, but a more powerful CPU to enable more complex experiences. (I know, nobody but a few of us would care, but still....)

8 bitters are simple. That's what attracts me. It makes fun experiences possible without having to have a phd in programming and or a small team to develop assets to go with it. Look at the home brews. Great fun from one person, or maybe a couple doing it because they can. The expectations are low too. That lets people explore all aspects of the presentation in a way that's very accessable compared to more complex machines. The system resources required to display a single desktop icon on more powerful computers will often exceed those of an entire 8bitter! Despite this, they are still fun and engaging machines. IMHO, the 8bit basic is pretty damn cool. I enjoyed it a lot more than I did other basics.

Sweet! I'm all for this game. It's an excellent two player experience. Can't wait to see how this shakes out. This homebrew scene is way more fun and compelling than the bland license-based gaming scene we've been stuck with on the new consoles. Game on!

First of all that's opinion and video generated interrupts aren't unique to the Atari. The coprocessor was but the things it did could be duplicated just with the CPU on other machines. Yeah, it's opinion. More below! Interrupt driven programming is pretty common in game development on all machines. Even on the C64. No disagreement there. It's the overall structure of the Atari that makes a difference. Again below. Less overall effect on the game? You mean I wouldn't have to program around hardware limitations? Yes! This is it exactly. The hardware limitations provide an interesting canvas for games. This means, some games will be just excellent. IMHO, this is largely because the game evolved around the hardware. It's the whole, "I created this cool effect, let's make a game of it." method of game conception. By nature, other machines with a different canvas are likely to reproduce the same game, but will lack some precision in general that affects the monor details of how it interacts with the player overall. What's really great about the Atari is the reality that in many cases, the display is an intergal part of the game itself. It's an extreme on the VCS, but still very true on many great 8 bitter titles. When one is talking about the greatest 8 bit gaming computer, the types of games that really appeal have a lot to do with that. I've always been in the Atari camp because I believe there is more art involved to building both a great game and a great display. The C64, made great displays easier for a lot of scenarios. Less art in many cases as it's simple competency in execution that matters. Fast forward to today. A really great game on the PlayStation, has some degree of art to it where the same title can be easily reproduced on the newer consoles with ease. The differences are not as stark as they were for the 8 bit era, but they are still there. Getting back to the Atari vs other 8 bitters, the hardware design presented a lot of interesting tradeoffs that provided a rich playfield for those wanting to explore it and game on it. If one thinks this stuff is great, then the Atari was the greatest... (Sorry for sloppy post, I'm outta time) Will try to get back and edit later.

They share an 8 bit external data bus, but the 65816 certainly has a 16 bit internal data bus. I'm not sure about the 6809 though as I don't have a schematic to hand. Edit: I found one and the ALU in the 6809 appears to only output to the 8 bit bus, so I'm guessing it uses a similar trick to the Z80. Ok, that nails it. They are 8 bitters, in that regard. Fair enough.

It's an 8/16 bit CPU. Same as the 6809, which could easily do the same thing. IMHO, the rule was always about the data bus and the operators. The 6502 has nothing really in the way of 16 bit operators. Indexing is a biggie for me. If the chip has 16 bit indexes, then it's a 16 bit chip on the inside. The Z80 was always called an 8 bit CPU in spite of having 16 bit index registers. The size of the index registers is strictly so you can index the entire 16 bit address space. The 8/16 bit designation of the 6809 is marketing on Motorola's part. It's register capabilities were similar to older 8 bits. It's extensive addressing modes, instruction set and fast execution speed are what set it apart. I think I agree with the Z80 being an 8bitter. Been a long while since I last reviews ops for that one. If it's really just 16 bit indexing, then that's no biggie. I would still argue for 8/16 bit status for the 6809 however. It featured a lot of 16 bit operations and two 16 bit stacks. Agreed on execution speed and addressing modes. Fun chip! Of course the downside of this position is it being difficult to then claim the 6809 as being the most powerful 8 bitter made. That leaves us with the 65816. It's got 16 bit registers and lots of operations and addressing modes to make use of them. How is this different from the 6809 where the two accumulators could be treated as a 16 bit register, with most operators being valid? Also, the 16 bit stack pointers could easily serve to operate on, as 16 bit numbers as well? The two share an 8 bit data bus. I'm not sure I see the distinction.

An excellent point. IF you have a master than knows all the tricks for one CPU / machine do one port and someone that doesn't know them all for another CPU / machine for another port then using the game to compare the two machines is meaningless. It's a 16 bit machine too, although I suppose you could debate that when it runs 6502 compatible mode. It has an 8 bit data buss and to the best of my knowlege uses 8 bit opcodes. The Z80 can represent 16 bit numbers in the same way as the 65816 so then what is it? It's an 8/16 bit CPU. Same as the 6809, which could easily do the same thing. IMHO, the rule was always about the data bus and the operators. The 6502 has nothing really in the way of 16 bit operators. Indexing is a biggie for me. If the chip has 16 bit indexes, then it's a 16 bit chip on the inside.

I'd be pissed. This is a great community.

I'd love to see the article if you could dig it up, but I can't help but feel that it would have been flawed. I can't think of any reason why the Atari 800 wouldn't be a fair bit quicker than the C64; the CPUs are almost the same and the former is clocked a lot faster. Unless there are some horrendous memory contention issues that I'm not aware of, it's an open and shut case. In any case, if you want a realistic benchmark, just try playing Mercenary on both machines. Even the Spectrum ought to come out faster than the C64; A 3.5:1 ratio in CPU speeds ought to be more than enough to compensate for the efficiencies of the 6502; I know for a fact that the Spectrum has 32K of uncontended memory, so the only possible explanation would be a naive translation of code without any re-optimization and that would work both ways. Again, you can play almost any 3D game on both machines and the Spectrum version will have a visible edge in speed. By the way, the Spectrum's CPU power might not be that great overall, but since the screen only used 6.75K of RAM, where most of its competitors had to address around 16K, that gave it a huge advantage in games where the hardware implementation couldn't do most of the work. It also gave programmers good reason to break out of the sprite/scrolling trap and develop more innovative graphics engines. Anyway, the BBC was definitely the fastest machine of the era with a 2 MHz 6502 CPU and no memory contention. It was just too expensive to compete against the other machines in the marketplace and the attempt to produce a cheaper model ended up with the flawed and incompatible Electron. You can't knock the games for it though; Elite is almost synonymous with 8 bit gaming in the UK. Edit: I think I've found the article and, althoug the CPUs do get a mention, its just benchmarking the BASIC implementations on the machines: http://www.gondolin.org.uk/hchof/reviews/yc-atari800xl.html Is that the one? I had the chance to write assembler code on both machines. In terms of raw compute, the atari was the faster of the two. Where memory I/O is concerned, the C64 has the edge in some cases because of how it's memory DMA worked. On the Atari, memory contention for high bit rate, full screen display modes (48 byte scans), would slow things down somewhat. Still, no real advantage to the C64 overall. For games, how the game is structured really makes a difference. Both systems had their advantages. How quickly the platform performed depended on how the hardware supported the gaming environment. On the matter of the best, I still say the Atari 8bitters rule because of how the video system worked. Games that were keyed to the screen display, in particular those that took advantage of the video sub-system, ended up with a crisp real-time feel, other systems did not reproduce as well. This is interrupt, event driven programming, and the Atari really emphasizes it because of how it operates. Display list interrupts, vblank interrupts, latched inputs, etc... all combined to allow some low-level linking directly to the metal that affected the overall game design in a unique way. The 2600 is the extreme of this, with the 8bitters being a nice hybrid. On the C64, these kinds of things were not done as often because of the focus on more detailed on screen graphics. I suppose one could argue the types of color displays on the C64 are more general case, allowing for more colors in more parts of the graphics screen without the vertical limitations. However, that also means building your display has less overall effect on the game itself. That's where the Jay Miner magic is --and it's a superior experience when game and hardware become one for the player.

Yeah, me too! Well if you do take an official pre-order list Curt, definitely put me down for one cart/keyboard Add me to the list as well.

Just caught what Batari was saying about releasing on tape for Supercharger. Will on tape capabilities be an option for Glenn Saunders Super-Supercharger? And is that the Chimera? If so, that's huge, IMHO. Shipping games on CD for use with that thing would really open up some doors, IMHO. Just rambling, anyone have any new info to share?

Hey all! Ooze is stalled because: Personal issues. (move from hell soaked every dime I had --still catching up and working lots of OT to do it) That's the biggie. Coupla smaller issues are: New Bb environment will allow for most of the feature ideas tossed out to be completed. That means there is a game there, I just need to get into a space to complete it. For some features, I'll need some hardware to actually test on. Long story short, keep it on the list, there is time yet this year to get what I want to get done! BTW: This community rocks. The moment I get some free cash (and actually get it in my hand instead of thinking I'll get it), I'll be buying some carts! Amazing work on these.

As an alternative to the range, simply compare one way or another, keeping the dividing value close enough to the open state to allow for as much variation as possible, without getting unwanted closed conditions.

Use the collision registers. The 2600 will tell you, by setting a bit in one of them, when your ball object hits your brick object. If {register from the list I linked above} = some value, then gosub get_rid_of_block. Once you have detected the collision, then you need to compare the position of the ball to where the blocks are and erase one. This is going to take some math, typically dividing the ball position by something to get the x block number for the pfpixel command. bB has collision commands, take a look at them. Do something goofy, like change the color of the ball first, to let you know you have successfully detected the collision state, then work on getting rid of the blocks.