supercat

Warren Robinett's "Basic Programming" cartridge gets twelve 8x8 characters per line with David Crane's kernel, which uses a combination of flicker and venetian blinds (using flicker alone would work, but adding venetian blinds makes the flicker less noticeable). Oddly, as far as I know this technique would never be used again within the next couple decades (some recent demos use it).

Well, I'd like to do it, but first on my agenda is a 2600 RAM-plus cart. But if I get that working, the 7800 cart hardware should be pretty easy.

You could probably get three kinds (hit once, unbreakable, hit-twice) without using significant extra RAM if you had two tables of data in ROM for each level and copied one to RAM. Use the following truth table: RAM/ROM 00 -- No brick 01 -- Unbreakable brick 10 -- Hit-once brick 11 -- Hit-twice brick Using color striping, the RAM bits would show in color on half the scan lines; the ROM bits would show in color on the other. If you didn't feel a need to copy the arcade layouts, you could save CPU time if you made the board layouts symmetrical. Although the RAM bits would not remain symmetrical, the ROM bits would. Thus you'd have a few cycles left to implement a 2LK. If you color the bricks as described, it should not be particularly RAM hungry.

Millipede on the FB2 seemed to be a PAL proto version (the player controlled a shaped sprite which whose vertical motion was 'stepwise', instead of controlling a smoothly-moving 'ball'.

Xilinx makes the software for the 95Cxx parts available for free. A programmer costs less than $100, or one can use plans available on-line to make one's own. While it is certainly true that most people who would program a homebrew game would have neither the interest nor expertise to design a new fusemap for it, using a CPLD which could be set for one of a few 'normal' configurations for people who weren't ambitious but could be programmed to a special configuration by someone who was, would seem the best approach.

Buy him a copy of THRUS+

Well, there could just be a range of addresses that's configured to always operate like that. Or the HALT line could be used (even better idea--wish I'd thought of it). My personal thinking is that CPLD's are getting sufficiently cheap that a board where a CPLD has near-total flexibility in memory layout would be quite practical. Once the board was laid out, new memory mapping schemes could be tried out simply by loading the CPLD with a new fusemap (which can even be done in-circuit). On the Atari 2600, a Xilinx 95C36 (a pretty cheap CPLD) can take all 13 address lines and 8 data lines as inputs, and have enough outputs to drive a 64Kx8 flash and 32Kx8 SRAM, controlling all but the bottom 7 address pins (which are supplied direct from the CPU). Because the 7800 has three more address bits from the CPU plus the timing signals, it would be necessary to lose some generality or else go to a larger CPLD (about $3-$4 more). The latter approach may be good from a development-community standard because the board could be made entirely general and then people could discover which features are really useful.

If you start with the first two shapes loaded into the first two sprites, and do the next store for the first shape at the first possible moment, there will be 32 pixels in which you must do three more stores. Doing three more stores in ten cycles would be fine if you had all the data in registers, but the 6502 doesn't have enough registers that can be directly 'stored' from. If there were an instruction that could store the stack pointer directly, then you could do it. Otherwise any attempt to cram in all the stores will end up being a pixel late. Back in the 1990's, my attempt at programming the 2600 used eleven cycles to do rapid-fire stores to the color registers, so as to yield a kernel for a Columns game. Never finished the rest of the game, though the colors looked pretty nice. Biggest peeve was probably that the columns were slightly off-center and there wasn't any way to fix that (given the CPU timing restrictions).

The correct register spelling is COLUBK.

I was just pondering how I might set up a game and was wondering whether there are any carts (CC2 perhaps?) that could be adapted a bank-switching scheme like this: Addresses $8000-$FFFF would map to 32K of ROM Addresses $4800-$7FFF would map to 14K of RAM Addresses $4000-$47FF would map to 16K of RAM through an interesting bank-switch arrangement: bits 6-7 of the address would be used in 4x3 LUT to select bits 11-13 of the address. Writing to address $3F00 would set the first LUT value; Address $3F40 would set the second; $3F80 the third; $3FC0 the fourth. If something like this could be arranged, it would allow a game to animate up to four groups of tiled characters separately. If a game has large groups of entities that all move in lockstep, this would allow such entities to be animated with minimal overhead. Anyone know of any existing cart designs that can do anything at all like that?

Looks pretty good. A few comments, if I may, which you'd be free to accept or ignore as you see fit. Your life might be easier if you have a couple of blank scan lines between rows of bricks. I do not think this would in any way detract from gameplay, and you could use the playfield on these rows to draw a border (which would not have to match any brick color). You could use these scan lines to process invisible bricks for either flickering or... ...you could draw bricks with alternating colored and gray scan lines. This might be a little tight on CPU cycles, but it would allow you to make three categories of bricks distinguishable: normal bricks (color only), indestructable bricks (gray only), and 'strong' bricks (gray + color, which would turn to color-only when hit). If you have cycles left, you could make the edges of the screen be gray. You could probably make the invaders disappear when the player gets a disrupter token. In that case, when the disrupter was active, there would be three balls bouncing around on screen but nothing else (use two players and a missile). If you make the both invaders and the paddle be one player and the falling tablets be the other, that would leave you with one missile to use for the ball and one missile to use for lasers. The laser's missile would be fairly easy to control since you would only have to turn it on and off in the boundary between bricks.

You got it. Sound like a workable approach for the 7800? It shouldn't take too many CPU cycles to update those five character map entries, meaning that the game would play just fine even with MARIA stealing 90% of the CPU cycles. For some reason I'd forgotten the data was laid out that way. Any way to make the rows be 128 bytes instead of 256? Otherwise I can think of a use for double-buffering the "text" display--have one copy contain character values that are offset by $40 [or whatever the highest character I use is, plus one]. Then I could get by using half as many fonts. Well, it has another possible purpose as well. BTW, animating the static items would be possible, but the speed of the animation would change depending upon the speed of the worm (which changes under user control). Not sure that would look good. It might be possible to do things creatively, however, and either (1) change character map entries for static items to animate them at whatever speed is desired (possible, but might be too slow unless the game uses dynamically-created code for that purpose; in that case, speed would be adequate but RAM would likely be inadequate); (2) use an address mapping PLD The latter might require a custom board design but if anything could be adapted to work with it, it'd be really cool and would also make possible a two-player version of Wormy. That would be positively sweet. Put A6, A7, A11, A12, A13, A14, and A15 through a Xilinx 95C36 and configure it to provide three separate character-set selections (one for characters 0-31 [player 1 snake], one for 32-63 [player 2 snake], and one for characters 64-127 [static stuff]). How does that sound for an idea? BTW, do you like the idea of doing Wormy as I've suggested? Do you agree with my judgement that tiles would be the way to go?

Basically, it's like some of the boards sold at the AtariAge store, except (1) it's in a more convenient package; (2) it includes a zero-insertion-force socket which makes it easier to insert and remove EPROMs. I have a couple of AA units (8K/16K) as well as one I made from a Froggo Karate (uses half of an 8K chip for a 4K cart). If you have access to an EPROM burner and baker (burning puts the bits in; baking takes them out again) I'd suggest buying AA carts in the 8K and 16K sizes. You can use 27C256 chips in all of the AA 8K/16K/32K carts (but not in the 2K/4K ones!) to play any size game that uses F8, F6, or F4 bank switching, but you may need to fill the chip with multiple copies of games smaller than 32K. Note that just about any cart will play nearly all 2K and 4K games; carts will play most games that are sized smaller than the carts, but not all (e.g. a 16K cart will play most 8K games but some may break). I'd suggest getting an 8K cart and a 16K cart since those seem to be the most common sizes over 4K. Getting 2 carts with pre-installed (non-ZIF) sockets and a half-dizen EPROMs will set you back $27.

Well, if someone never ships an item and never leaves feedback for the people who pay, he'll never get a neg. IMHO, the scale should be extended to distinguish 'annoyance' negs from unresolved black eyes (people who accept payment without shipment, or people who accept shipment and revoke payment). In some cases, an issue which is 'resolved' should clear any black mark (e.g. if an item not received is a result of a fire at a UPS facility) while in other cases it should not. Still, it would probably not be unreasonable to allow people to submit a tentative positive feedback with the minimum acceptable return feedback to post it (e.g. I may decide to give someone a positive if they give a neutral or positive, but may be disinclined to give one it if they leave a negative).

Since the title of the game is "MANGOES down"...

What about just blt'ing the little guys onto the bitmapped background? I'm pretty sure that's what all the other versions do. They'd probably be no more than five pixels wide (remember we're in fat-pixel mode), so using preshifted shape tables should allow for pretty quick plotting. What's the memory layout for a hi-res bitmap on the Maria? Is it row-major, column-major, or some goofy hybrid?

I just tried this game on a real machine. It's great, and I did much better with a joystick than with keyboard. When are cartridges going to be available?

Yup. I wish I could figure out how to do a screen shot--it would make things so much eaiser to explain. Despite the name, the 'worm' looks a lot like a Centipede (complete with animated legs). The play mechanic moves things a character at a time, but the visual effect is smooth motion. To accomplish this, I defined character shapes for e.g. "worm entering from left and leaving out top". In the first character set, this character shape would feature an up-facing worm segment that was one pixel above center (cropped at the top) superimposed with the rightmost column of a right-facing worm segment that was seven pixels left of center. In the second character set, these segments would be two pixels above center and six pixels left. In the seventh, they would be seven pixels above center and one pixel left. In the eighth, the right-facing segment would appear centered with nothing superimposed, the up-facing segment having shifted completely out of the character block. The effect of this is that the entire length of an arbitrarily-long worm can be smoothly animated by simply changing character sets. There are twelve shapes to deal with the interior of the worm body, four to deal with the rear of the last segment, four to deal with the front of the head, and twelve to deal with head-body joins. Well, the original game was animated at 60Hz so I would want an Atari 7800 version to be so as well. Double-buffering the display would thus not be terribly helpful--either stuff would happen fast enough or it wouldn't. I'm thinking the best approach would be to simply use character-set cycling in a 16K ROM; the second-best approach would be to copy 240 bytes of character-shape data each frame.

If the game mechanic were such that fish could only be raised/lowered at a certain X coordinate, then it would have been possible to use a Freeway-style double sprite. And if Activision's policy allowed flicker, two freely-movable fish in addition to the 'laned' fish could have been handled that way. But given that neither of those things could be done, only one fish could be 'out of lane' at a time.

While the NES does not do interlacing, it does interleave the chroma phase on consecutive lines and fields. This yields a considerable improvement in color quality at the expense of getting occasional motion artifacts (visible when approaching the flagpole at the end of a level in SMB).

The binary is two bytes to small. Doesn't run with z26. 888700[/snapback] The clunky assembler I was using would die if it crossed the address $8000 boundary, and the Dodgson cart required a $7000 base address. So yeah it is a couple bytes short. It runs in Z26, though, if you start it in windowed mode. It's 271 scan lines which isn't right, but I didn't have a scan line counter when I did it--just a TV. Not sure why Z26 likes it in when starting windowed mode but not when starting in full-screen mode.

My recollection of playing the 7800 is that the color phase is the same every line. Cutting a half cycle would reduce artifacting (breaking games that relied upon it, but making other games look better). Is this piece suggesting that the Maria chip should have been modified to do this?

Joining the pieces with no exposed metal and having the joints be strong is non-trivial. I would not pay the quoted prices, but if the quality of worksmanship is good they are not totally out of line (aside from the fact that, compared to other things, quality woodwork costs a lot more today than 100 year ago).

I got mine from 4jays.net a bit over a month ago.

How about getting a second edition "Stella Gets a New Brain" CD? About $20 for licensed copies of all the games including printed instructions.