Search the Community
Showing results for tags 'current projects'.
-
Well, I just started playing with 7800 programming and it seems somewhat interesting. Haven't really figured out what to do, though. I've been thinking it might be interesting to see if I can manage a missile defense or area-filling game using only the 4K of internal RAM. The location of the zero-page and stack shadows is nuisancesome, but I have a kernel that seems like it should work for 128x96x4 colors with some cycles left over for a few overlay objects. The bitmap is stored linearly at 32 bytes/row, except for an annoying gap at $2000 to allow for the zero-page and stack shadow areas. I was also thinking that if I can manage to do some CPLD design it might be interesting to try to push the 7800 to its limits like I did for 4A50. Probably should invest more time and effort in 4A50 first, but I would think that with the right hardware the 7800 might be able to do a pretty decent rendition of a color vector graphics game. The first key, if possible, would be to use the HALT signal to distinguish CPU cycles from MARIA cycles. 16K of the Maria address space would fetch data from one of four 16K banks; another 16K would access a different one of four 16K banks but assert R/W and drive the data bus low. This would provide a fast means of clearing display memory. For graphics plotting, I'd tweak things a little bit beyond my 4A50 design. If $1000-$17FF is open, I'd set things up to allow pixel plotting via something like: cmp $1000,x; X=x coordinate of pixel cmp $16FF,y; Y=y coordinate of pixel The $10xx read would latch bits 3-7 of the address and data bits 0-7 (controlling what's plotted). The $16xx read would fetch data from an address formed by munging the bits 3-7 latched above along with some other address registers and the 8 LSBs of the specified address and then latch data bits 0-7 into a second register. The $17xx read would use the same address as the $16xx read, but perform a write there with the masked contents of the first two reads and a "color" register. Combining these techniques, I think a color vector game in the style of Tempest could probably run at 20fps in NTSC--possibly even 30--even using a 256x192x4 bitmap screen.
-
I've restarted work on my Matchie game after finding a solution for an annoying TIA quirk. Although the 2600 shows 160 pixels across the screen, SCORE mode can corrupt the color of the last HALF-pixel on the left half of the screen. If the last playfield pixel on the left half of the screen is set, the 77th through 80th pixels should appear in P0 color. Unfortunately, the right half of that playfield pixel will show up in an indeterminate color which may be affected by COLUPF even though the playfield should appear entirely in P0 and P1 colors. For quite awhile i shelved the game because I couldn't get it to look good on a real 2600. Finally, though, I figured out the solution: display Missile 0 at pixel 79 on any scan line where that playfield pixel is set. Problem solved. I'm curious, though, does anyone know any other race conditions that can cause Atari 2600 to be "split"?
-
This version adds explosions when monsters are hit by falling rocks or rubies. I'm not really happy with it, but figured I'd let CC2 users play with it. There are a surprising number of different ways a rock can hit a monster, and I don't yet have special handling for most of them, so things can get a little strange. Setting difficulty to B/A allows the game to be single-stepped via the fire button. This makes it possible to see what's happening with monster and rock movements as well as with explosions. Watching the details closely will reveal a lot about how the game actually works. Even though things seem to move smoothly, the game uses a character-based display kernel and all action takes place with character cells. To move a monster smoothly to the right, I have defined characters for "Monster exit right" and "Monster enter from left". Using character-set animation, the monster will move smoothly from left to right without my having to worry about handling the individual steps. This works out extremely nicely for most things, but collision handling becomes surprisingly tricky. If a monster is leaving a square and a falling rock is immediately above it ready to enter, should that register a collision? Yes. What if the monster is entering a square with the rock above? That too should register a collision. But what if there are rocks over both squares? Presently, the game registers two collisions. To see this, dig down under the lower-left clock monster and leave when it's facing upward. Get out of the way of the emerging clock monsters and you'll see a monster get double-splatted. If anyone plays with the demo and has any ideas for improving explosion logic, I'd be glad to hear them.
-
It's been awhile since I've posted about the 4A50 cart, so many people may be thinking it's been abandoned. It actually still is a work in progress, despite some "shiny object syndrome" that resulted in things like Strat-O-Gems.I worked awhile ago with Chad Schell to produce some VHDL for 4A50 and unfortunately did not have time then to diagnose it other than to determine that something didn't work. Hopefully within the next few days I'll be able to diagnose exactly what it IS doing and take things from there. Too bad I can't use Z26's handy trace log to figure out where the code is going when it gets lost in the weeds--that can sure be handy sometimes!Once the VHDL is working, it should be possible for CC2 owners to do development for the cartridge. I do have a real one, and it works great in a Heavy Sixer, 2600jr, and 7800. Unfortunately, it seems like it will be a bit pricey; the board is all surface-mount; while the components are cheap, assembly is not (at least not in the volumes we'd be dealing with). I'd expect 4A50-based carts would have a minimum SRP of $45-$50 at the AA store as compared with $20 for 4K carts and $25 for bankswitch carts.For more detailed technical info, see the other blog entry "4A50 cart--hardware".
-
The original "Wormy", written by a young man named Matt Gokey, was a Commodore 64 game (written in BASIC) in which the player would move a snake around the screen to collect all the goodies while avoiding mines (or his tail). Very much like Commodore's VIC-20 game Slither, except that the screen was filled with non-moving goodies and obstacles rather than having randomly-appearing targets. My first real game on the PC (CGA) was a variation called "Wormy II", which smoothly animated the snake's motion at 60fps, added various power-ups and power-downs, and allowed the player to control the snake's speed (above a minimum controlled by level and power-ups/power-downs). It also featured a nice rendition of a tune I'd written at music camp some years previously.The 2600 Wormy was planned to be closer to the original (no power-ups or power-downs) but feature the smooth motion and speed control from Wormy II. It would also feature a slightly-shrunk playing area (32x16 instead of 38x20). At the time I designed it, I was unaware of Tapeworm (which is the 2600 game closest to it) but the game as planned has a number of differences from that cart: All objects for a level (up to 128, randomly placed) will be placed at the start and shown on screen, Good and bad objects will be visually distinct from the snake's tail, without flicker, using striped playfield colors. Snake should move at least somewhat smoothly, using a player/missile sprite for the snake's head and the Ball for the tail, and player will control the snake's speed. None of the annoying critters that appear randomly and cross the screen. What makes this interesting is that a 32x16 playfield, showing up to 128 objects, where each square can be black (empty), green (snake), red (mine), or green+red (goodie) would seem to take up 128 bytes of memory, leaving none for anyything else. Nonetheless, I have a proof-of-concept kernel that works to display precisely that.The trick is to allow eight objects (good or bad) per line, using one byte per line to hold a present/not-present indicator for each. The distribution of those eight objects among the 32 squares on the line is controlled by a pseudo-random generator which is 'run' while the screen is drawn. Thus, instead of taking 128 bytes, the screen takes 80 bytes plus the random seed. That at least leaves some space for other things, but there's still a lot to store and not much room to store it.There's more I could say on the subject, but that will be in another entry.