potatohead

Didn't the CoCo have an 8bit DAC built in for the cassette? It wasn't stereo, but the great CPU allowed for some excellent sounds. PITA, compared to having a chip, but not as bad as all that. The CoCo3, had it been released earlier, really would have shined IMHO. It's probably my favorite 8 bitter, next to the A800. On NTSC televisions, artifacting allowed for a *lot* of on screen colors. I think the 640x192x(4?) color mode, was the sweet one. Using an effective resolution of 160 pixels, it did at least 128 colors, if not more. One just had to setup a Color Lookup Table with all the bit patterns and go. At the time I had one, I wrote a fractal computation program with this mode. Looked sweet. The big feature, IMHO, was the nice and powerful onboard MMU. Any 8K bank could be swapped for any other 8K bank with relative ease. Where getting good use out of > 64K RAM is concerned, I think this machine was the most powerful of the 8bitters. Crappy game controllers, nice and fast disks, great cassette interface too. (worked with file names and had a very high tolerance for tape variations and ran at 1200 baud --screaming at the time. Fun CPU on that thing. Programming assembly on the 6809 was just pure fun. Beautiful 8 bit design. It was expensive, but clearly best in class. Lack of hardware sprites is kind of a bummer, but it had plenty of ram, making double buffered displays with lots of colors easy enough. Given the CPU, I'm not sure it's a big of a limitation as some people thought at the time. The real limitation was programs. Compared to other 8bitters, almost nothing good was released for it The ugliness of the CoCo 1 & 2 probably had a lot to do with that, as did the potential for outselling the Tandy 1000. That was a running joke too. With the CPU clocked down by half, it still performed well compared to the 1000. If I had it all to do over, I would have spent much more time on the CoCo3.

Totally! The Paddle games are really fun and are unique these days. My kids love them. WARLORDS and KABOOM! are two reasons I'll always have a VCS around. Everybody, who picks up the paddle, will play these two games period. Apple ][ paddles do not go 360, they are pots just like the Atari ones. Our school had them long ago. Paddle 0 and 1 form the analog joystick in common use on the Apple. The Apple didn't have that crisp, 1:1 display that somehow adds value to the paddle games. Joystick seemed much better on the Apple. Choplifter still plays very well on that computer, with the analog controls, than it does most everywhere else with digital ones. The driving controllers are also great fun, and under appreciated. They go all the way around, but lack that kind of absolute positioning the paddles can have, given good programming. (am I wrong on the driving controllers in this respect?) Would be really great to have a paddle controller where there was more than one button, and or being able to rotate it, tip it in 2 more axis. So, you get to push buttons, turn it along it's center axis, and either move it up and down, left right, or rotate on the other two remaining axis. (think space ball controller, only just simple analog control.)

Bitches? Yeah, that's a seller I want to deal with. It's funny. Go ahead laugh!

danger. Ok folks, take a moment, go here: http://www.savetheinternet.com/=act and do some stuff. Tell your friends. I would not normally engage in any advocacy here, but this matters and is highly likely to matter a whole lot. Early on, we saw the consolidation of the ISPs. At that time, this kind of affair was discussed, but there was enough diversity on the net to keep it at bay. Today, this is no longer true and those that own the few mega pipes are now wanting to take a greater role. IT DOES NOT MATTER HOW THEY SELL IT, THIS IS CONTENT DISCRIMINATION. This means, the relative equality we currently enjoy will go away. In it's place will be a strong emphasis on corporate controlled and sanctioned content. You know, the bland stuff you get on nearly every other option availiable today. Please make a personal phone call to your elected representatives. This is gonna seriously matter.

I think being mandatory on the cart would devalue some game releases for no good reason. I also think bB needs to be credited. It's just too great of an effort to consider doing otherwise. There is also some grey area. What if someone prototyped with bB, then polished up with assembly code? It's still kinda sorta a bB game, but might be differentiated from pure bB games. Should I ever get off my arse and re-do Ooze with the new bB, I'm gonna include the source in the manual, on a small CD, or something, with liberal comments. This is a really great value add, IMHO. The person playing the game gets to look inside, make changes, etc... Maybe even buy their own cart! (sorry guys, I'm smitten by the Propeller right now...)

The top, for a full frame NTSC image is 720x486, that includes overscan and interlaced color. I'm not sure how the colors are done though. I'm working with the Propeller, which is a little microcontroller type chip that has onboard, largely software driven NTSC / PAL / VGA capability. It will do the 720x486, and it does it in color too. I don't fully understand all the mechanics behind color when driving it this high. Perhaps, the double vertical resolution permits some more complex color interleave scheme. I just don't know.

I've really enjoyed this project. Nicely done! You really do need to go and play some good pinball machines. A well designed machine has lots of action, strategy and great tradeoffs where playing it safe or really going for a score are concerned. And then there is multi-ball, getting a ball stuck in one of the moving things, hitting it out with another, smacks on the glass, almost tilts that save your arse, etc... Pinball really does begin to appeal over 30. As a young gamer, I gravitated toward the Eugene Jarvis style of game pretty huge. It's all about the trance, right? Well, for some reason, I never was quite able to get a good trance on a pinball machine. It's as if the level of stimulation required just isn't there. Maybe it's just the attraction of the other games is too great... Today, in my late 30's pinball is just excellent! I nearly always play when I see a good coin-op standing somewhere. My games are a lot longer now too and the comments above regarding paitence are spot on. Anyway, I just wanted to drop you a quick note to say your project is cool, and that I enjoy reading.

Missed this reply. I'll get the calipers, cable and CAD together and do it next week.

To expand on that just a bit. How the color is clocked can affect this. By default, if you do nothing but generate a plain old NTSC signal, nice and simple, there are about 160 pixels in the NTSC safe area. The Atari graphics, on the 8 bitters, are keyed to this pixel clock. The C64, and other newer video systems, choose different means of syncing the color to the TV. If you interlace the color, as in offset it 1/2 pixel every other scanline, the solid pixel resolution goes up to 320 pixels per scanline, without artifacts. Wait for some colored text on a tv broadcast sometime and go take a close look at the pixels. You will see them shifting back and forth. Ignoring the vertical interlace, which is every even scan line drawn, then every odd one, this is interlaced color. The 7800 does not do this, so it's 320 resolution mode is somewhat bizzare in how it handles pixels. I suspect this is to avoid artifacting and maintain a stable pixel clock for every scanline. There are more complexities than this in play as well that I don't understand, particularly on the NES. It's 228 pixel resolution seems oddball to me. Maybe they clocked it to minimize jitter in the display or something. IMHO, I'm not sure ANTIC was limited to 40 bytes per scanline for speed reasons. Had it been capable of 80, or 64 or something where more color information would have been made possible per scanline, the overall speed impact would not have been that great. I believe the decision surrounded the sprite engine and how overlays, underlays and variable resolutions all working together impact the overall complexity of the video circuit. Keeping everything keyed to the 160 pixel resolution likely simplified all of that --and when the chips were designed, that was a lot of capability! Perhaps the 7800, being designed to be compatable with the VCS, involved some design choices, where generating pixels and colors is concerned, that managed expectations between the two over providing a better signal at the higher resolutions. Many aspects of the design, follow the minimal approach taken before with the VCS. It may have been thought that few, if any games, would leverage the higher resolution graphics, or that moving objects really didn't need to be at the highest resolution possible either. Had ANTIC been expanded to see color control, above the 160 pixel (for default 40 byte DMA) resolution, it may have seen similar limitations on how things are placed, color sets used, etc... as seen in the 7800. Personally, I like the 160 pixel solid color look. Combined with a robust palette, it has a look that's distinctive. Newer video systems, that had increased color control, also came with lower numbers of directly addressable colors, tile / character modes, and heavier sprite capabilities. These are all resolution and color density choices over intensity and overall color bandwidth choices made in the Atari systems. That's the key to the Atari look, BTW.

Welcome to a life long addiction. Programming is addictive as music is! Enjoy yourself, and don't forget to go looking for other programs you can look at! This is an excellent way to learn new techniques. Even if they are not quite the same BASIC you are working with, it's not all that big of a stretch to get to learn to read. Soon, you will be looking at many programs in many dialects and learning. For your gender, just make a string variable set to the value of the gender, based on input from the user, or have the user type it directly! This works for names too, BTW. So, you capture the gender with either direct input: Input "What is your gender?"; gender$ ,or Input "Choose your gender 1=male 2=female"; genderid if genderid = 1 then gender$ = "He", etc.. or if gender$ = "Male" then assign some pronoun strings. The problem with direct input is the user can input anything! So, you gotta check it and ask them again, if it does not make sense to the rest of the program. Offering them choices is a lot easier. Printing the stuff then involves mixing the variable strings with your hardcoded stuff. print name$; " is screwed before he/she even starts." (might be a comma there too, I don't know for your BASIC)

UFO would be an excellent idea. BTW, is there an emulator that makes sense? I would enjoy replaying this game --been a while.

Had an extra day of hotel room time, so I went ahead and did some exploring of color potential on the Propeller. IMHO, it's not bad at all! Just using the reference video output circuit, I was able to get 400 colors on screen, by over clocking the pixel clock to twice it's normal NTSC running rate. Essentially, it's two pixels into what would otherwise be a single pixel Atari style NTSC color clock. Initial results were pretty decent. There are plenty more colors possible, given some serious thought to choosing palette choices, etc... This is a 320x96 image, which consumes nearly all the RAM. Looks like I'll likely either need to generate video on the fly, or get the SRAM addon to do more than just plot some dots. One other thing that could be done is interlace this color, so that the effective resolution would be 320x192. Edit: Another user helped me with the timing stuff. Was far simpler than I thought it might be. Turns out, the only real requirement is that the overscan must be a multiple of the pixel clock. Of course this makes perfect sense, after having seen it in action... arrgh. In any case, the prop can display 400 colors no problem. This does allow for overlay graphics, more than one generator rendering the same scanline at the same time, more greys, etc... Edit: I think I'm gonna work through a simple Breakout game. This technique does make overlay graphics possible, but they are or'ed with the graphics underneath in a fashion similar, but not quite like a PM overlay. Breakout can have a solid background, so this is not a problem just to explore two generators working together to produce a display. Since the high color depth consumes pretty much all the prop RAM, what I want to do is a 2600 style scenario where the background graphics are fairly low resolution (maybe 48, 64 or 80 pixels horizontal and 4 scanlines high), and a higher resolution object for the ball. (Maybe a 160 pixel resolution object, also 4 scanlines high) I'll use timing to position the ball object, in a fashion similar to how it's done on the 2600, so it's gonna consume very little RAM. I'm also thinking collision detection might be possible, but tricky to get right. Essentially, the video generators are gonna be drawing the main game graphics. The ball video generator cog, could look at the pins, right when it's about to output it's pixel and store a value. Problem is that case won't really occur until the exact moment a pixel needs to be drawn. At lower resolutions, there might be enough time, but at higher ones, no way... Gonna ignore this for the first pass, but it's something to think about. I suppose a third cog could be watching for collisions, but that's three freaking COGs. Maybe dealing with a hardware collision detection emulation is just not worth it. The prop is fast, so detecting for collisions in the usual way, based of off the game state is just the way things need to happen. All things considered, I'll build a display kernel that has score, number of remaining balls, level and whatever else in the top scanlines. These will either be a bitmap, or maybe character mode style graphics for easy, in game manupulation from the higher level spin language. Then will come the playfield, at the low resolution, high color depth. This will be followed by a high resolution (160 pixels horizontal x 3 scanlines vertical) area for the paddle, followed finally by nothing but blank scans. This will consume perhaps a 5th of the ram that would otherwise be consumed drawing these objects as a full on high-color bitmap. The ball overlay will just be a small bitmap that is positioned via timing that is keyed off of two position memory locations. From there, it's just the game logic and some sound, to be done by another COG.

If there is interest, I'll model this in CAD this evening. Would do it right now, but calipers are at work.

That's freaking hilarious! Place still in business?

DRAIN BRAMAGE?

DRAIN BRAMAGE?

Hmmm... perhaps the minimum requirements are not met? Sorry, just thought your post was funny, given the title.

bB has the RAM playfield. The very first thing I did was make a crude breakout game with the early alpha release. It all worked just fine --I just never finished it because it was a test to validate bB more than a game effort. There is plenty in bB now to make a very interesting breakout game, IMHO. Make your ball one sprite. No need to make it a four sided thing. I'm sure you were thinking about using that element to control bricks and ball bounce, but you don't need it. Some if - then statements and a small amount of logic thinking through the ball states at different times will get you through. When a collision is detected between the ball and the playfield, you compare the ball position to that of the bricks and erase the closest brick. ballx / 4 = brickx (do some math to figure out which brick to erase) At the same time, you flip the motion of the ball, which gets you the bounce. Be sure and constrain the position of the ball such that it never touches the playfield edges, or you get false collisions. It's easiest if you have a motion component you can change, so that bouncing the ball ends up being changing the sign of either the x or y motion vector. ballx = ballx + ballxmotion where ballxmotion = a positive or negative number, depending on how it's gonna bounce. You will have if statements for the playfield edges that set the motion to known values. eg: if ballx < left_playfield_side_limit then ballxmotion = positive_value if ballx > right_playfield_side_limit then ballxmotion = negative_value The key to the bricks is that hitting one simply changes the sign of the ballymotion! Hit a brick, just end up going the other direction in the y, leave x alone --or not, if you want to have some fun with your game. And there is paddle support now! This is perhaps the biggest reason I never did much early on. Breakout is just no fun with no paddle...

I'm doing some coding right now, looking to put together something that runs Erik's sprite video driver code. I'm eager to try that one out. Thought I would take a moment and mention two Propeller game projects: Manic Miner Originally a Spectrum game, this port is spot on and has that nice retro feel. Never bumped into this game before, but I like it! Uses keyboard for control. ManicMiner002.zip And the only screenshot online so far... This one requires a two stage load. The EEPROM holds the game assets and is loaded first. It then, programs the necessary data into the upper EEPROM memory above 32K. Stage two then can be loaded whenever you want to play, and runs in the 32K RAM. Both can be programmed into the EEPROM for instant on play too. Donkey Kong This one is near complete. The files here are totally playable. Very nice! When this one gets through the spit and polish stage, it's gonna be a spot on port of DK to the Propeller. It's aimed at the HYDRA, but currently runs completely in the 32K of RAM, so it could run on any Propeller setup. Uses Nintendo NES style game controller. Can be hacked to use other control schemes. sw_dkong_016.zip Here is a screenshot, taken from the Parallax forum. I've no way to grab a screenie right now, or I would! Edit: A debugged version, with near excellent in game sounds. sw_dkong_021.zip

That's both rough news and good news. He's alive and kicking, so that's all good. Project coming to a halt though is a serious bummer. Sorry for that. Maybe he can get things sorted out and step back in someday.

Of course!! Not enough coffee today... I'm looking at the last set of code you sent my way. Maybe there is something that can go in there that will save cycles later..

It's probably easier to just check all the player positions, when the hardware collision detect goes off, and make your decisions from there.

Ok then... That's not a bad idea! Perhaps I'll tag some friends tonight and see how that goes. It is easy to lose track and never thought of that feature as a selection tool. The whole popularity contest part is a turn off. Using it this way though seems practical. Thanks!

I remember when Slashdot added this feature. At first, there was this flurry of activity. Picked up a batch of friends, and a coupla foes. After that, it all tapered down to a point where nobody cared. Are we there at AA? This community is significantly different from the Slashdot one. People know each other, the focus is far tighter in general, than Slashdot is, fewer users overall and a much higher signal to noise ratio, likely from the high number of regulars all sharing the same interest. That's it really. Just wondering aloud about the whole thing, which I'm likely to continue to ignore...

"Anyway, I will add it to site and Readme file." Cool! (And the right thing to do) That's the important thing, and was the point of my post. I've no beef with what you wrote, nor how it works. Inviting people to run it, without making sure they know the score, was very worrysome to me, that's all. Sorry for going off.