potatohead

Adventure -- It was the first game where you were in a place and could do stuff. KABOOM! -- Because it's dead simple, razor sharp and fast. Plus, any amount of serious effort led to "the trance". Videogame nirvana. PITFALL2 -- Depth, and that sense of place. The music and graphics were great too. FROGGER -- On the SuperCharger, this was just a great conversion. Showed that gameplay really does matter. STAR RAIDERS -- Depth, and 3D places. I like this better on the computers, of course, but it's a fantastic game. INDY 500 -- Oh man I liked this one because it was totally fun with two people. Again, rock solid controls, fast and fun. WARLORDS -- Multi player fun, lots of color, fast, solid, and perfect with friends. The best of shared gaming right there.

I still enjoy my atari stuff. When I'm in the mood for classic games, it's almost always the Atari stuff. To be fair, I've got some personal stuff going on that gets in the way of this right now. Enjoyed the programming with Batari Basic, hope to finish Ooze. (finally worked out the core game issues!) I recently bought a parallax propeller chip and am currently working on programming for it. It's a lot of fun and has that retro feel, but also has relevance --or at least more relevance than the older Atari stuff has. It's also a multi-processor and that makes it very interesting, along with software video generation. For what it's worth, I enjoy the varied discussion here. Classic gaming, on the 8bit machines of all kinds is a fun area of computing, generally. Might as well enjoy it while it all still runs!

I've done the 640x200 bit on an 8bit 800xl. On one of the older high persistance monochrome monitors, it looked really good. I used a VBI to stagger the color changes by scanline. Slowed the machine down, but it did generate nice high resolution displays. In color mode, you could get quite a few artifacted colors as well.

You just did! Thanks. I mean that, it's very nice. This whole mess will easily hit 5 digits --well into 5 digits is likely. Not the kind of thing I could ever accept from others like that. Having said that, it's damn nice to know there are people out there who want to make things better because they think they can! Good on you for that. I'll take the prayers though! Every little bit helps. Looks like it's all coming to a head next month. If all goes well, I'll soon have my family running as it should and I can begin to work out payment, start having free time again, and there will be light at the end of the tunnel. After having done some checking, I can pay this over time. Gonna be a long time, but that's a managable thing --thank god for that! One other realization came to me, that really helps with the bitter aspect of this. I've got options and friends. In the end, I can sell everything, but for the cool goodies that are hard to replace, camp out with them and rebuild. Setting aside the material things does a lot to change ones outlook. We cannot take it with us in the end, so why worry so much now? So the biggie is time. That's where experiences happen. I'll have that back soon. I'll spend that time doing things I love and being with people I love. I'm going to go forward with time being the primary thing to maximize. That means life style changes above those I've already made and I'm gonna be ok with that. Thanks again! That made my day!

Been a while since I last posted anything. There is a reason for that! My wife has been seriously ill. We thought the fix would be quick, but it just isn't. She is having major surgery this week. I'm nervous and excited. If things go well, I will be able to get things back to normal, catch up on the financial end of things and work on gaming stuff. I've some Ooze ideas that make sense and will make it a more complete and less futile game. Can't wait to try those. The HYDRA machine is a lot of fun. People are just now starting to code for it. Ideally we will see some up and coming stuff for it this year. The state of health care in this country is horrible. I've carried insurance for years. The one fucking time I have it hard, (company I worked for went bankrupt, forcing me to drop it for a short time) this crap hits me. All of it pre-existing, which is complete and utter bull shit. To think of the dollars I paid in... So, it's on my tab and I'll be paying for it over the next 20 years... Makes getting that new policy just that much harder too. How easily one can fall into a trap these days. The hospital is actually great. They will allow payments, but do require some stiff payments for some procedures no matter what. This month it's go another month behind on the mortgage or don't get my wife fixed. Good grief! (I'll split the middle and hit everybody I know up for a few bucks, then do a lot of favors and cross fingers!) Yes I'm bitter --sorry. Well, not sorry, but just bitter. Take it for what it is. I do read the forum each week and watch the various projects carry on. Keep all this going guys, it's just great.

TRS 80 was the first one I ever got to program. Apple ][ at school. Finally got an A800, good friend ended up with a CoCo 2. Basic was not fast enough, ended up writing 6502 / 6809 assembly language on both machines depending on the task at hand.

Yep. My Brother in law and I played through all three characters. No cheats, but for one time we let health get too low. Turns out it is possible to save, take a step, save, take a step, etc... We ended up with a critical item and in poor shape. Too much game time to just surrender. So, I inched the character out a save at a time until the coast was clear enough to go for a medpack! BTW: The level 10 card is deep in the bowels of the Alien nest found at the bottom of sublevel 5? The Queen baddie is in there, and if you run around the card is near her in the back corner of the room. I remember stepping in to size up the room, seeing the eggs, stepping out to equip the flame thrower and hozing them all down good. I borked this up, ended up running around and snagged the card! So, I bailed and saved with almost no health left. That's when the save trick came into play. We inched outta there with only a sliver of health left, got in the clear and continued on. For it's time the game was simply huge. IMHO, it's still nicely sized today. We really could use a solid port to modern systems. Heck, with the new discoveries on how to actually run GPU code from main RAM, the game might end up faster on the Jag! Anyhow, this is a fantastic game. Scary, fun and non-linear for the most part. You've got plenty of choices that break up the 3D on rails effect so many other similar games have. One nice touch was the need for little in the way of back story and manuals. If you looked around, the in game elements told the story nicely giving you a little help along the way.

Make setting the clock a game of sorts! (yeah, I know --ducks!)

As mentioned above, one can get more than 4 colors with artifacting. That's a good reason right there. Texture is another. On monochrome screens, the different textures make things stand out. If the object is the solid color, then it can be fully defined in the higher resolution. This can yield smooth movement, which is why so many early games featured a white ship, for example. Text and detail. Having the option of addressing higher resolution pixels helps with this. Overall appearance. Some graphics look good this way! So, it becomes a personal preference thing.

I really liked the Apple. Frankly, I learned on it first before the Atari because it was completely open. The ROM included nice tools for programming the machine, and the source was in the manual. Hardware wise it was not as cool as the Atari was, but it was easy to understand.

Nice little beasty. It's essentially a prop, coupled with a homebrew cart slot, 128K eeprom for larger program storage, sound, video, network ?!? and Nintendo game ports. (Cool) Comes with a number of playable games. Some are really decent, others are clearly demo hacks. No biggie because there is a book and a *lot* of code to play with. Custom graphics engines too. The book covers a lot of ground on game programming in general, with some great additional information and techniques not supplied with the standard Parallax offerings. I'll post up some screenies later. A project is coming to mind... more on that later after I think about it some. It also comes with one blank prototype card for your own addons. Key components are socketed, board is clean and well labeled. Overall a nice package.

Well, I've had some time to get more familar with this little device. So far I've been able to get lots of interesting video out of the thing. Pretty much any multiple of 16 pixels horizontally is possible. That's pretty cool. There is built in scaling as well, so it makes for some interesting displays. It's totally doable to get 640 pixels of horizontal resolution if you want it. That's monochrome, with color happening at half that. Overscan will take some tinkering with the driver software. Currently working on color issues. The 4 color per tile limitation is not the end of the world, but annoying. (each tile is 16 x 16 pixels) I think it's possible to have a color map that's different than tiles though. Will be playing with that some on my next go around. Also, I've got the SGI O2 up and running, so I can grab some screenies... One biggie that's both good and bad. The color burst appears to be nintendo style. Not sure what the technical term for this is, but I've always called it interlaced color horizontally. Essentially, the color clock shifts phase every other frame. This is why your broadcast TV weather maps look so good, for example. It basically doubles your color resolution at the expense of shifting the color phase every other frame. Cool feature in that once you've asked for a specific color, you are going to get it no matter what the scale is, pixels, etc... Nice! For text and other visuals that demand some detail, this little chip will output quality video with the best of them. This means the prop is also capable of that nice Namco square pixel look by default. Always liked that as it seems to present fonts, characters and such in a far nicer way than the Atari style graphics do. Still love the overall Atari feel better though. Guess it all comes down to your first console love doesn't it? The bummer is no artifacting --yet. Was hoping to leverage artifacting, along with higher density pixel clocks to get more color. The CoCo3 had a nice high resolution graphics mode (think it was 640x192) that ended up being capable of nearly 256 unique colors at a resolution of 160x192. Had some game developers taken advantage of that, we would have seen some mighty fine looking CoCo games. Anyway, this seemed just perfect for the prop. Getting the 256 might be tough, but 32 or 64 seems viable, depending on pixel size and what one chooses to do with the tiles. I made some nice fractal programs and a coupla quickie game demos with this mode that looked damn sharp. Never see this mentioned, perhaps nobody actually tried it! So, I'm digging into the video driver innards in the hopes of learning some more before I begin any projects. Still at the hacking and tinkering stage learning my way around the hardware. I suspect it will be possible to tinker with the color clock to get the color cycles on the same phase every frame. If so, then I'll have the ability to generate a visual at pretty much any resolution I want, with the feel I want. The scaling hardware is very interesting as well. It goes way down to 2600 playfield type pixels, and way up to broadcast quality video output. Same for the vertical. RAM is a bit tight for a bitmap, but a 320x192 non-interlaced, or 320x384 display looks sharp. On the other extreme, I've done a 64x48 screen that looks spooky 2600 like, color interlace issues aside. I'm confident this little chip will do a full on 720x486 interlaced display, with character mode graphics. The HYDRA game console is out. This is like Andre's last effort, the XGameStation, only prop powered. Has Nintendo game ports, drivers, networking, 128K eeprom and a cart slot for addons or just for storing games. I've got one of these on order. Looks to be a fun device. It's gonna be a tough choice deciding to either wire up some Atari style controllers, or go with Nintendo ones. I really like both, but the Atari stuff includes the driving controller that's just begging for some additional gaming goodness. Since the demo board only has keyboard and mouse set up, perhaps I'll do the Atari controllers there. Update: Went ahead and fired up the SGI O2 workstation. It's got a pro quality NTSC capture card. Configured the prop for 256x192 & 640x192 interlaced display. The screenies are attached: UPDATE: It's easy to get the color clocks in sync every frame, Atari style. That completes the picture for now. All the interesting NTSC modes can be done. That puts artifacting in play, meaning more colors per tile. I'm off to check that out quickly before moving on. Actually it's not yet that easy. I've managed to get the color clocks the same every frame, but with two problems. 1. They are only the same phase every other scan... Artifacted colors are complex this way. 2. It's a 50/50 shot how it all works out. Red might be blue, blue might be red....

Nice link! Thanks for sharing it. Here's one I put together along with Scott, a local audio production guy.... http://www.pdxradiospots.com

Yep. My kids love the Atari stuff. A few times per year, I'll set it all up and let them go at it. Warlords and KABOOM! are favorites, as is Combat. They will play them for hours. Another sleeper turned out to be Star Raiders on the computer. One kid will man the computer, taking the scotty role, while the other will pilot the craft. When they were younger, they had trouble with the spherical coordinates used to locate enemies. No biggie, they learned that over time --or just flew around until they found the baddies. My oldest ended up really connecting with KABOOM! though. I grabbed a paddle once and went for the trance. Knocked down a nice respectable score and the kids were amazed. It was so fast to them, compared to the games they usually play. A lot of kids today have not had the trance experience. I'm totally sold on that being the addiction we all have experienced. We wouldn't be here otherwise! She played the game for a long while, then managed to hit it. Boom! Her score just jumped way up there. After a couple of long sessions, she told me this game had changed her. --and could she borrow it for a while. Hmmm... been there, done that! Warlords is just great though. Gonna have to get Medieval Mayhem as an upgrade one of these days. They have had their friends over for long Warlords sessions more than once! The dead simple paddle does not get in the way of the fun.

I hear that. Personally, I'm not that sensitive to taxes. Hate 'em like everyone else, but if there is a solid return, I'm ok with that. Guess it really comes down to waste with me. Maybe we will see less of it now. My real concern is the change in direction where core American principles are concerned. It all comes down to freedom, democracy and equality. New legislation needs to embody those, or it does harm. The last 6+ years have seen a lot of harm in this regard. Looks like the senate is going Dem too.... The court battles will start tomorrow I'm sure!

Not gonna post much about this, save that it means we no longer are under one party rule. Been too long. Having some checks and balances back is a good thing long overdue.

Pretty sure it does. Had one of these for a while. Get Rad Warrior for it. One of the very best titles, IMHO. And if they like text adventures, Madness and the Minoutar is excellent. Unlike most turn based text adventures, it's got things going on in real time, requiring you to think and type fast at times!

Been tinkering with the supplied graphics engine. It reminds me of the C64 in that color defintions are tile based. Essentially, you get 4 color values per pixel. What colors those values actually generate depends on the color information defined for that particular 16 x 16 pixel tile. There is no real limit on the number of unique tile color set definitions however. Essentially, you get a full color screen, but only 4 of them per tile area. Interesting... The assembly language is cool and I'm starting to get it. Like this little chip a lot. There are no in-cpu registers, there is no indexing and it's 32 bit across the board. Does have barrel shifter. Nearly all instructions local to the CPU (there are 8 running together) take 4 cycles to complete. "Registers" are really pointers to the 512 longs that compose the 2Kb local memory. So, a move between memory locations is really just move x,y. Compares, adds, all work the same way! To index, you self modify one of the instructions with another one and branch accordingly. What's nice is the lack of having to deal with lots of addressing modes. Really operands are immediate and specified by direct address. That's it, aside from dealing with the program counter. The higher level language maps almost directly to the assembly language and provides structure. It's really easy to mix the two for the best balance of speed and utility. Their own graphics kernel is assembly, wrapped in a higher object that gets called by other programs. frankly, the provided environment reminds me a lot of a higher level Batari Basic environment. First real task is to code a readpixel function object into their graphics library. It's missing this, making simple games difficult! I'm working through their write pixel routine for this. If what I do works out, they will probably just include it with the next distribution. I'm liking the openness of it all so far. A budding demo scene is beginning to show, egged on by the chips creator having worked out a very decent software speech engine on the thing. Was really bummed about my total mistake about how the 7800 cart port works. Not sure what I plan to do with this chip and classic machines just yet. Still thinking.. Might not do anything in the end. For now, the plan is to just get myself up to speed on the programming and see where that leads. With the talent here, some really great stuff could be built. In the end, I suppose that's why I'm posting this stuff here. --that and this is really the closest venue besides there own more EE and robotics based forums. After watching what has happened so far, a simple yet very functional console could be produced for the price of a really great homebrew cart. One has been designed that's quite advanced --it's gonna be about $250. For now I'm gonna ignore that in favor of the core processor and demo board I'm working on now.

If you want formatted input, you are going to have to write your own character by character input subroutine. A good alternative is to let them input, then check it. If it does not pass, have them input again. Label the input so they know what to do. use the len function to get the number of characters ( if len(a$) > 6 then ....) use the string functions to evaluate the string char by char with a short loop. (if a$(2,1) < asc ("a")..... Use the asc function to get the ASCII values of the characters then compare them to the ones found in the user input. Since you are post processing their input, you might consider padding the numerics to 6 characters as well, displaying the corrected input then moving on. This would increase the number of possible correct inputs for the user.

Inaccurate emulation is a very poor option. I like my games to look, sound, and play as the developers intended. This is completely stupid. Either you want the game as it was originally produced or you don't. That leaves you three options: -play it on the SNES -play it on an accurate emulator that may or may not have options to reduce slowdown -play it on a known emulator that is known to solve the slowdown problem. Basically you either deal, or load some emulators and check them out. If you really want it on the TV, add that option to your computer and go from there.

There's no video pin on the 7800 cartridge port. (Only a mono audio pin, used for POKEY output.) The expansion port has the MARIA video outputs, and a CVIDEO pin, but I don't think you can use those pins as inputs. (Even in 2600 mode the MARIA video pins would be pulled low.) So any mixing would have the be done on your board. (Probably easiest to use the MARIA video outputs (which are digital) rather than CVIDEO, although MCOL might be tricky since that's more of an analog signal.) You could probably use the MSYNC (or BLANK) to genlock the propeller video output to the 7800; you'd just need to modify the propeller code to match the 7800 line & frame timing. Hmm... unfortunately, the expansion port doesn't have much in the way of true I/O pins. (I'm not sure it has any input capabilities at all...) Now, if you wanted to be tricky, you could use the MARIA video outputs to send data from the 7800 to the propeller board during the "offscreen" rasters. Kinda like closed captioning. (That's assuming that you don't go for some kind of cart+expansion port hybrid.) Of course you are right! I mistook the expansion port for the cart port! That does put the nix on my idea, unless I want to hack the actual hardware. (might consider this at some point, thus making it a one time deal for sure.) I think only one of my 7800 machines has the expansion port. The hybrid idea is viable, but only applicable to a subset of the 7800s out there. Gonna park this for now and get my video kernels done on the prop, then go from there. Thanks for entertaining me for a bit. It's educational being able to talk about these things!

You are gonna want to put your code into a file that you feed into DASM. Said file will contain: your program equates and labels data (Those things at a minimum --there are others, but not a worry now. You just need to know what you are looking at.) If you look at some of the examples, you should be able to see all of these things and begin to see the structure of how it all goes together. Here are some things to look for: SOMETHING = $C000 ANOTHER = $E000 Those are equates. They are so you can use brief words in your assembly instead of the actual addresses. So, LDA $C000 (This means put whatever number is contained in address $C000 into the A register of the CPU. (Accumulator) Therefore: LDA SOMETHING (SOMETHING = $C000) (Tells DASM to put whatever value you have equated to SOMETHING into the assembly program, so that when it runs you get the previous example) Data is strings of numbers, either hex or decimal or binary. Can be game shapes, level data, sound data, etc... $C0, $FE, $DD, $45, etc..... %00000001, %10001000, etc.... Depending on the program, you might see blocks of these or just a single line. The rest is the program. IMHO, you need to get hold of something that is known to work. Then get all the pieces necessary for it to assemble. Assemble it until you get a binary, then test it. It's gonna take quite a few tries to test out the entire toolchain, but until you do, it will all be frustrating. Once you've gone from some text in a file to an executable that's doing something (does not matter what) on your console, you are ready to begin learning how to write your own stuff, knowing you've probably got a solid toolchain upon which to write. At that point, you can start by making small changes to the demo you've got running already. Change the position of something, perhaps it's color, etc... After that comes using that as a template for your own programs. Keep all the setup stuff and begin inserting your own logic. Soon you will reach a point where you can write your own simple programs from start to finish, without using the sample codes as a crutch. (That's nirvana --have fun!) That's essentially the same process I've used on every language / system I've ever programmed for. It sucks at first, but then goes fairly quickly after that. Here's the biggie: Make damn sure you have a complete copy of something that will actually run unmodified on your console. That way you are left with only having to figure out how best to assemble it into a binary. It helps just a little to have a working binary too. That way you know what to expect on the screen and can compare your results to the finished product. Ask around here, someobdy will have something to get you started.

Actually that's a really interesting idea! But it's not where I was headed. I've not had a chance to test the video pin on the 7800 yet (outta town at the moment, just playing with the prop), but I was hoping it works like the sound one does in that whatever is there gets mixed in with the 7800 output. That's what I plan to test with a composite signal when I get a chance. If that's the case, then the prop generated video would get mixed in with the 7800 video, with both images ending up on the TV. One could choose to graphics with either display system, but not have the two interact directly. The case I am seriously considering, if the prop video capability is what I think it is, would be one where the 7800 is not drawing much with the MARIA chip. On screen graphics would largely reside on the prop, using the 7800 for I/O and perhaps some graphic display as well. Sound could come from either place, probably the 7800 would be easiest. Game logic could be both places, depending on what graphics system does what. The prop is not a memory mapped design. It's CPU's and RAM are internal. When powered on, it loads it's internal ram from an eeprom, via a very simple serial communication scheme that takes a coupla pins. After that, each of it's 32 i/o pins are completely general purpose. So a few of them would get used up to generate the composite video to be sent into the 7800 cart video line. A few more could be dedicated to create sound. (Both of these methods use a few resistors to form a DAC.) The remainder could be used to facillitate communication between the prop and the 7800. The prop is fairly fast in that each of the 8 COGs run at about 20mips each. This appears to be fast enough to generate lots of different kinds of video, particularly when a couple of them work together. It also seems fast enough to allow emulation of memory mapped I/O, so the 7800 CPU would not know the difference between talking to the prop software and real RAM/ROM located at some address just like an ordinary cart would present. (And that's a guess at this stage) One issue I've identified is timing between the two. A program in the 7800 would have to signal the prop in such a way that it's onboard video signal would be synced with the 7800 one. Of course the other is timing for RAM / ROM emulation. Communication between the two would have to happen via software running on the prop to interact with the 7800 CPU via the cart port pins. If software is fast enough to allow this, lots of very interesting things would be possible because the software could emulate most any addressing scheme. Thus, your idea comes into play as well. I had not thought it through that far. Did some tinkering last night with the assembly video drivers that ship with the chip. It will do NTSC, full color clock per pixel by default, interlaced or not. Timing is software controlled and adjustable as it's basically a big software loop running on one of the COGs. In this way, the thing is very 2600 like. No kernel, no video. Sub color clock pixel widths are possible as well. The primary issue seems to be color. The drivers that ship with the unit are fairly color limited. (4) They did a C64 style color tile scheme where two colors per 16 x 16 pixel area are permitted, with lots of combinations avaliable to choose from for each tile, along with a color or two that works anywhere on screen. I'm assuming this was to only consume one COG and maximize memory use for other things besides graphics. (It is a microcontroller after all) If one applied more than one COG to the problem, lots of other video possibilities become an option. My musings about hardware collision detection really were out of place in the other post. Where I was going with that is the COGs run at the same time, in sync. It's possible to have more than one of them helping to build the video display, as the output pins are shared. One could be generating what we would call playfield graphics on the 2600, while another draws what we would call sprites. The state of the video signal, as it appears electrically on the pins, is shared among all COG's. So a quick read before changing that state would enable one COG to know if it is drawing on top of, or underneath what the other COG is doing, based on some flags set in memory before hand. That's really what I was writing about --the ability to literally build a video generator that is applicable to the game at hand, similar to how I see people here do it for the 2600, only with the added ability to craft collisions detection that's necessary without having to do more than that. Prop memory and speed constraints prevent one from just throwing up a full color bitmap and going for it however. That's where the art of it lies, again similar in concept to the systems we all play with here. Anyhow, where you write above about creative wiring, etc... , I'm thinking of using one COG to handle the communication issues where logic gates and such would be used otherwise. That's essentially 4 software loops running on half the avaliable COG's, two handling video, one doing sound, and one handling communication via some sort of memory address emulation. (Maybe two doing that) That leaves a lot of compute on both sides to do actual game stuff. Here's the chunk of assembly that reads from RAM and outputs an NTSC bitmapped display: --- '******************************* '* Assembly language TV driver * '******************************* org ' ' ' Entry ' entry mov taskptr,#tasks 'reset tasks mov x,#10 'perform task sections initially :init jmpret taskret,taskptr djnz x,#:init ' ' ' Superfield ' superfield mov taskptr,#tasks 'reset tasks test _mode,#%0001 wc 'if ntsc, set phaseflip if_nc mov phaseflip,phasemask test _mode,#%0010 wz 'get interlace into nz ' ' ' Field ' field mov x,vinv 'do invisible back porch lines :black call #hsync 'do hsync waitvid burst,sync_high2 'do black jmpret taskret,taskptr 'call task section (z undisturbed) djnz x,#:black 'another black line? wrlong visible,par 'set status to visible mov x,vb 'do visible back porch lines call #blank_lines mov screen,_screen 'point to first tile (upper-leftmost) mov y,_vt 'set vertical tiles :line mov vx,_vx 'set vertical expand :vert if_z xor interlace,#1 'interlace skip? if_z tjz interlace,#:skip call #hsync 'do hsync mov vscl,hb 'do visible back porch pixels xor tile,colortable waitvid tile,#0 mov x,_ht 'set horizontal tiles mov vscl,hx 'set horizontal expand :tile rdword tile,screen 'read tile or tile,line 'set pointer bits into tile rol tile,#6 'read tile pixels rdlong pixels,tile '(2 instructions between reads) shr tile,#10+6 'set tile colors movs :color,tile add screen,#2 'point to next tile mov tile,phaseflip :color xor tile,colortable waitvid tile,pixels 'pass colors and pixels to video djnz x,#:tile 'another tile? sub screen,hc2x 'repoint to first tile in same line mov vscl,hf 'do visible front porch pixels mov tile,phaseflip xor tile,colortable waitvid tile,#0 :skip djnz vx,#:vert 'vertical expand? ror line,linerot 'set next line add line,lineadd wc rol line,linerot if_nc jmp #:line add screen,hc2x 'point to first tile in next line djnz y,#:line 'another tile line? if_z xor interlace,#1 wz 'get interlace and field1 into z test _mode,#%0001 wc 'do visible front porch lines mov x,vf if_nz_and_c add x,#1 call #blank_lines if_nz wrlong invisible,par 'unless interlace and field1, set status to invisible if_z_eq_c call #hsync 'if required, do short line if_z_eq_c mov vscl,hrest if_z_eq_c waitvid burst,sync_high2 if_z_eq_c xor phaseflip,phasemask call #vsync_high 'do high vsync pulses movs vsync1,#sync_low1 'do low vsync pulses movs vsync2,#sync_low2 call #vsync_low call #vsync_high 'do high vsync pulses if_nz mov vscl,hhalf 'if odd frame, do half line if_nz waitvid burst,sync_high2 if_z jmp #field 'if interlace and field1, display field2 jmp #superfield 'else, new superfield ' ' ' Blank lines ' blank_lines call #hsync 'do hsync xor tile,colortable 'do background waitvid tile,#0 djnz x,#blank_lines blank_lines_ret ret ' ' ' Horizontal sync ' hsync test _mode,#%0001 wc 'if pal, toggle phaseflip if_c xor phaseflip,phasemask mov vscl,sync_scale1 'do hsync mov tile,phaseflip xor tile,burst waitvid tile,sync_normal mov vscl,hvis 'setup in case blank line mov tile,phaseflip hsync_ret ret ' ' ' Vertical sync ' vsync_high movs vsync1,#sync_high1 'vertical sync movs vsync2,#sync_high2 vsync_low mov x,vrep vsyncx mov vscl,sync_scale1 vsync1 waitvid burst,sync_high1 mov vscl,sync_scale2 vsync2 waitvid burst,sync_high2 djnz x,#vsyncx vsync_low_ret vsync_high_ret ret ' ' ' Tasks - performed in sections during invisible back porch lines ' tasks mov t1,par 'load parameters movd :par,#_enable '(skip _status) mov t2,#paramcount - 1 :load add t1,#4 :par rdlong 0,t1 add :par,d0 djnz t2,#:load '+119 mov t1,_pins 'set video pins and directions test t1,#$08 wc if_nc mov t2,pins0 if_c mov t2,pins1 test t1,#$40 wc shr t1,#1 shl t1,#3 shr t2,t1 movs vcfg,t2 shr t1,#6 movd vcfg,t1 shl t1,#3 and t2,#$FF shl t2,t1 if_nc mov dira,t2 if_nc mov dirb,#0 if_c mov dira,#0 if_c mov dirb,t2 '+18 tjz _enable,#disabled '+2, disabled? jmpret taskptr,taskret '+1=140, break and return later movs :rd,#wtab 'load ntsc/pal metrics from word table movd :wr,#hvis mov t1,#wtabx - wtab test _mode,#%0001 wc :rd mov t2,0 add :rd,#1 if_nc shl t2,#16 shr t2,#16 :wr mov 0,t2 add :wr,d0 djnz t1,#:rd '+54 if_nc movs :ltab,#ltab 'load ntsc/pal metrics from long table if_c movs :ltab,#ltab+1 movd :ltab,#fcolor mov t1,#(ltabx - ltab) >> 1 :ltab mov 0,0 add :ltab,d0s1 djnz t1,#:ltab '+17 rdlong t1,#0 'get CLKFREQ shr t1,#1 'if CLKFREQ < 16MHz, cancel _broadcast cmp t1,m8 wc if_c mov _broadcast,#0 shr t1,#1 'if CLKFREQ < color frequency * 4, disable cmp t1,fcolor wc if_c jmp #disabled '+11 jmpret taskptr,taskret '+1=83, break and return later mov t1,fcolor 'set ctra pll to fcolor * 16 call #divide 'if ntsc, set vco to fcolor * 32 (114.5454 MHz) test _mode,#%0001 wc 'if pal, set vco to fcolor * 16 (70.9379 MHz) if_c movi ctra,#%00001_111 'select fcolor * 16 output (ntsc=/2, pal=/1) if_nc movi ctra,#%00001_110 if_nc shl t2,#1 mov frqa,t2 '+147 jmpret taskptr,taskret '+1=148, break and return later mov t1,_broadcast 'set ctrb pll to _broadcast mov t2,#0 'if 0, turn off ctrb tjz t1,#:off min t1,m8 'limit from 8MHz to 128MHz max t1,m128 mov t2,#%00001_100 'adjust _broadcast to be within 4MHz-8MHz :scale shr t1,#1 '(vco will be within 64MHz-128MHz) cmp m8,t1 wc if_c add t2,#%00000_001 if_c jmp #:scale :off movi ctrb,t2 call #divide mov frqb,t2 '+165 jmpret taskptr,taskret '+1=166, break and return later mov t1,#%10100_000 'set video configuration test _pins,#$01 wc '(swap broadcast/baseband output bits?) if_c or t1,#%01000_000 test _mode,#%1000 wc '(strip chroma from broadcast?) if_nc or t1,#%00010_000 test _mode,#%0100 wc '(strip chroma from baseband?) if_nc or t1,#%00001_000 and _auralcog,#%111 '(set aural cog) or t1,_auralcog movi vcfg,t1 '+10 mov hx,_hx 'compute horizontal metrics shl hx,#8 or hx,_hx shl hx,#4 mov hc2x,_ht shl hc2x,#1 mov t1,_ht mov t2,_hx call #multiply mov hf,hvis sub hf,t1 shr hf,#1 wc mov hb,_ho addx hb,hf sub hf,_ho '+52 mov t1,_vt 'compute vertical metrics mov t2,_vx call #multiply test _mode,#%10000 wc 'consider tile size muxc linerot,#1 mov lineadd,lineinc if_c shr lineadd,#1 if_c shl t1,#1 test _mode,#%0010 wc 'consider interlace if_c shr t1,#1 mov vf,vvis sub vf,t1 shr vf,#1 wc neg vb,_vo addx vb,vf add vf,_vo '+53 xor _mode,#%0010 '+1, flip interlace bit for display :colors jmpret taskptr,taskret '+1=117/160, break and return later mov t1,#13 'load next 13 colors into colortable :colorloop mov t2,:colorreg '5 times = 65 (all 64 colors loaded) shr t2,#9-2 and t2,#$FC add t2,_colors :colorreg rdlong colortable,t2 add :colorreg,d0 andn :colorreg,d6 djnz t1,#:colorloop '+158 jmp #:colors '+1, keep loading colors ' ' ' Divide t1/CLKFREQ to get frqa or frqb value into t2 ' divide rdlong m1,#0 'get CLKFREQ mov m2,#32+1 :loop cmpsub t1,m1 wc rcl t2,#1 shl t1,#1 djnz m2,#:loop divide_ret ret '+140 ' ' ' Multiply t1 * t2 * 16 (t1, t2 = bytes) ' multiply shl t2,#8+4-1 mov m1,#8 :loop shr t1,#1 wc if_c add t1,t2 djnz m1,#:loop multiply_ret ret '+37 ' ' ' Disabled - reset status, nap ~4ms, try again ' disabled mov ctra,#0 'reset ctra mov ctrb,#0 'reset ctrb mov vcfg,#0 'reset video wrlong outa,par 'set status to disabled rdlong t1,#0 'get CLKFREQ shr t1,#8 'nap for ~4ms min t1,#3 add t1,cnt waitcnt t1,#0 jmp #entry 'reload parameters ' ' ' Initialized data ' m8 long 8_000_000 m128 long 128_000_000 d0 long 1 << 9 << 0 d6 long 1 << 9 << 6 d0s1 long 1 << 9 << 0 + 1 << 1 interlace long 0 invisible long 1 visible long 2 phaseflip long $00000000 phasemask &n

Potatohead came from an impulse registration at Slashdot when it was first getting started. I ended up liking the name because it's not often taken. (This is not so true these days, but still mostly true.) Besides, I really liked my Mr. Potatohead toy!

Hmm... thanks for the pointer. I think I'm just going to hack a cart and inject some video and see what happens. The video generation capability of the propeller chip is a largely software affair. (Which is why I really like it.) What you output is really up to you. (within some limits) At this stage, the out of spec issue does not appear to be a show stopper. (Their own demo is not quite NTSC from what I can see.) I've just begun looking their video output demo over at the assembly level. One must write a display kernel to map memory to video output, or draw on the fly 2600 style. Interestingly, things like sprites and hardware collision are not part of the system. These are done with the software kernel. From what I can tell, the approach so far is to dedicate at least one of 8 CPU cores to the task of generating video images. That provides a graphics 'mode' similar to how a 2600 kernel would provide the graphics mode upon which the game then runs. That's what triggered my purchase. Very interesting hardware that just might end up being able to reproduce that Atari feel that comes with the intermingling of display generation and game logic. At the end of the day, it's that feel that I really enjoy. We'll see if this actually ends up being the driver. Right now I think it is. The CPU cores, called COGS, each run in parallel with one another at the same time and can share access to the video output. This really is what interests me from a hobby computing stand point. There are lots of limitations but lots of power too. Hackability. If one wanted a 2600 style video display with a playfield, some sprites, etc... two COGS could perform in software, what is normally done in silicon, leaving the rest of the unit to actually handle I/O and actually run the game engine. Of course you are completely right about doing it for the love of it. My only real question was one of possible shared interest down the line. If the project would end up being some $200 thing, I'll be the only one that ever enjoys it. On the other hand, $35.00 and a few folks might be able to afford to have some fun too. That's really the meat of it. Plenty of time for that assessment later, I suppose. Right now, I've got to finish getting my head wrapped around the development environment and write a video kernel or two. Wondering if a kernel can really do something like hardware collision detection does.