supercat

Well, a 256-byte table would be a little big if you're shooting for a 4K cart, but not out of the question. And if you're going for a larger cart it'd be no problem at all. I do think that if you're going to have multi-hit bricks, they should be visually distinct. Striping the playfield (with alternating colored and gray lines) would be a nice way to achieve this if there's enough RAM, but RAM does seem rather tight. What do you think of the idea of having multi-hit bricks but keeping track of the 'ball's power' rather than the number of times each particular brick has been hit?

It does, though I forgot to mention you should skip every other byte. My music player is designed for two voices interleaved, so half the bytes are useless zeroes. I do think the lower-pitched one is best, but I wanted to give you choices since the higher-pitched one is closer to the tune you started with and I didn't know if you could handle using two different AUDCx values (which seems to have been no problem). The one advantage I can see to using only one AUDCx value [as in the third tune I posted] is that you can use different AUDCx values to pitch the tune differently. For example, you could use a lower-pitched AUDCx to play the tune on level 0, and a higher-pitched one to play it on level 15 while also increasing the tempo. It might be nice also to have level 15 run a 'script' where Hunchy does something to free Esmerelda and then wanders off screen with her, timed to end when the music does. This wouldn't have to take much code if you (1) reuse the music, and (2) use a simple symmetric playfield kernel for the top of the screen (cutting the storage required for the screen itself). Hunchy wouldn't have to do much to free Esmerelda, but he could perhaps grab a bell which triggers an extensible bridge or something. Also, btw, one thing I didn't do in the music I posted (so as to keep it simple) was code a duration in bits 5-6 of each note value. If you did that, you could eliminate a lot of the 'zero' bytes, thus saving code space. BTW, for some reason the first level has 'screechy' sound effects on the emulator (haven't tried it on my real 7800) and all the other levels have really quiet sound effects except for the beep when grabbing a bell. Is that normal?

Did you see my suggestion about only setting one of the two PF bits for a brick to make it a two-hit brick and then on each frame toggling all of those bits from the left side to the right (using a 256-byte lookup table)? That shouldn't take any extra time to process in the kernel and should be reasonably fast to handle during the retrace. Another possibility would be to, rather than tracking which multi-hit bricks had been hit, count how many multi-hit bricks have been hit since the last brick was broken. This could perhaps be indicated by changing the intensity of the ball. I think Atari's Centipede and Millipede do something like this, rather than keeping a hit count for every single mushroom.

If one used a RAM expansion like the Supercharger, one could produce a 96x128 hires flickerscreen (30Hz) with alternating red and blue scan lines. I don't know if the 2600's colors would be saturated enough to make the glasses work well, though.

Well, at least early in the game each wave gives 4 little bunnies. Seems I miscounted them, since I'd thought there were 144 (actually it looks like 104). So that screen shot marks 27 waves complete if the pattern continues. I wonder if the screen will start rolling if the bunny count falls off the overscan.

I'd be curious to see the SARA chip schematics, but I'm not sure how much better one will be able to do than a PLD plus a RAM chip, unless one wants to do custom silicon (which would not be practical for anything less than 10,000pcs). Homebrew 2600 development may be picking up steam, but I don't see it picking up that much.

The C128 would have been a 10x better machine if Commodore had left out a couple of gates. Allowing free switching between C-128 mode and C-64 mode (via hardware registers) would not have broken any C64 software that wouldn't have trouble anyway (the MMU banked itself out at $D500, but didn't bank out the 80-column chip at $D600, and there's no reason to believe anything would unintentionally access the former that wouldn't hit the latter) but would have made it possible to produce hybrid programs which could run on a C64 but would run even better on a C128.

For games whose scores would otherwise always be multiples of ten, why not do another add-with-carry on the LSB (after doing the MSB)? This would mean that if the player had 999,990 points and got 100, their score would go to 91. Unless they flip the counter nine more times, the last digit would show how many times it was flipped.

Is that 36 waves cleared?

True, but that particular game isn't exactly CPU intensive. Further, even with MGD, there is a noticeable lag on some of the sound effects, most notably the burp. I would guess that this lag is a result of having to send multiple bytes of data to set up the speech for the burp before it actually starts playing; if that guess is correct, the lag could be reduced by allowing the game to send 16 bytes of data per frame instead of one or two. Although a 100ms lag may not be particularly objectionable in a game like MGD where Atarivox sounds are relatively sparse, it would seem like it would be annoying in games with denser sounds (bearing in mind that the Avox is usable for more than just speech). I don't mind, in fact I would be pleased if guys came up with alternative intro's. I did the default one in just a few minutes. 898199[/snapback] Right, but if the Avox power-up sound varied depending upon what game was last used that could be somewhat confusing for users, so it would seem like a good idea to leave it alone.

Batari Basic is limited to two 'shaped' movable objects, two movable rectangles, and a a low-resolution playing field. I see no realistic way to do Satan's Hollow with those restrictions. Indeed, doing a faithful port of Satan's Hollow at all on the 2600 would seem rather difficult given that many waves feature birds flying in tricky formations with many birds on one scan line, not in a 'nice' formation. There may be some tricks to accomplish it without too much flicker, but it would require a highly-customized kernel.

Nice game, but the intonation on "The Teddybear Picnic" really bothers me. Here are three better-in-tune versions. My music player uses the MSB of a byte to indicate whether to use AUDCx of 12 or 4. First version (E major) byte $8C,$00,$1B,$00,$00,$00,$17,$00,$18,$00,$17,$00,$18,$00,$1B,$00,$00,$00,$17,$00,$18,$00,$00,$00,$17,$00,$1B,$00,$18,$00,$17,$00 byte $18,$00,$00,$00,$17,$00,$1B,$00,$00,$00,$00,$00,$00,$00,$00,$00,$1F,$00,$17,$00,$00,$00,$12,$00,$14,$00,$12,$00,$14,$00,$17,$00 byte $00,$00,$12,$00,$14,$00,$00,$00,$12,$00,$17,$00,$14,$00,$12,$00,$14,$00,$00,$00,$12,$00,$17,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $0F,$00,$0D,$00,$00,$00,$0F,$00,$0D,$00,$00,$00,$0F,$00,$12,$00,$11,$00,$0F,$00,$12,$00,$00,$00,$17,$00,$14,$00,$00,$00,$17,$00 byte $14,$00,$00,$00,$17,$00,$1F,$00,$1B,$00,$17,$00,$1B,$00,$00,$00,$1F,$00,$1B,$00,$00,$00,$17,$00,$1F,$00,$00,$00,$17,$00,$8B,$00 byte $1F,$00,$1B,$00,$1F,$00,$00,$00,$12,$00,$14,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$17,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 If you want something lower pitched, you could try this one (D major an octave down) byte $9B,$00,$94,$00,$00,$00,$91,$00,$92,$00,$91,$00,$92,$00,$94,$00,$00,$00,$91,$00,$92,$00,$00,$00,$91,$00,$94,$00,$92,$00,$91,$00 byte $92,$00,$00,$00,$91,$00,$94,$00,$00,$00,$00,$00,$00,$00,$00,$00,$97,$00,$91,$00,$00,$00,$8D,$00,$8F,$00,$8D,$00,$8F,$00,$91,$00 byte $00,$00,$8D,$00,$8F,$00,$00,$00,$8D,$00,$91,$00,$8F,$00,$8D,$00,$8F,$00,$00,$00,$8D,$00,$91,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $8B,$00,$1F,$00,$00,$00,$8B,$00,$1F,$00,$00,$00,$8B,$00,$8D,$00,$8C,$00,$8B,$00,$8D,$00,$00,$00,$91,$00,$8F,$00,$00,$00,$91,$00 byte $8F,$00,$00,$00,$91,$00,$97,$00,$94,$00,$91,$00,$94,$00,$00,$00,$97,$00,$94,$00,$00,$00,$91,$00,$97,$00,$00,$00,$91,$00,$9A,$00 byte $97,$00,$94,$00,$97,$00,$00,$00,$8D,$00,$8F,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$91,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 If you can't handle using two AUDCx values, this version has a couple of notes adjusted (E major, or A major, or whatever, depending upon AUDCx) byte $18,$00,$1B,$00,$00,$00,$17,$00,$18,$00,$17,$00,$18,$00,$1B,$00,$00,$00,$17,$00,$18,$00,$00,$00,$17,$00,$1B,$00,$18,$00,$17,$00 byte $18,$00,$00,$00,$17,$00,$1B,$00,$00,$00,$00,$00,$00,$00,$00,$00,$1F,$00,$17,$00,$00,$00,$12,$00,$14,$00,$12,$00,$14,$00,$17,$00 byte $00,$00,$12,$00,$14,$00,$00,$00,$12,$00,$17,$00,$14,$00,$12,$00,$14,$00,$00,$00,$12,$00,$17,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $0F,$00,$0D,$00,$00,$00,$0F,$00,$0D,$00,$00,$00,$0F,$00,$12,$00,$11,$00,$0F,$00,$12,$00,$00,$00,$17,$00,$14,$00,$00,$00,$17,$00 byte $14,$00,$00,$00,$17,$00,$1F,$00,$1B,$00,$17,$00,$1B,$00,$00,$00,$1F,$00,$1B,$00,$00,$00,$17,$00,$1F,$00,$00,$00,$17,$00,$1B,$00 byte $1F,$00,$1B,$00,$1F,$00,$00,$00,$12,$00,$14,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$17,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00

Well, I've got 2 bytes left (if the moderator agrees with my tally that the headers that count total 16 bytes) and know where I can probably get three more. Maybe with 5 bytes I could do something, but my sound code is already pretty minimal. Check this out: ldx #1 audlp: lda booms,x sta AUDV0,x lsr booms,x dex bpl audlp To set up AUDC0, AUDC1, and AUDF1, I arranged the initialized data section so the last value written would be an 8 (so I'd have an 8 in the accumulator when init was completed) thus allowing me to store it without having to waste two bytes on a load. To set up AUDF0, I found a spot where X was loaded with 3 and stuck a store there. To trigger a player shot is 4 bytes (lda/sta). Likewise a missle explosion. A ground explosion is two bytes (STY with a handy value in Y). A gameover is a DEC AUDF1 and fall through to the ground explosion. I just noticed something: if I rearrage my frame-handling logic so that the least-significant four bits of the value loaded into the frame counter are an "8", I could save two bytes by sticking "sta AUDC0,x" in my audlp. Does seem a little desperate, though. Besides, by my tally, I've got four different sound effects in a whopping 11+8+4+4+2+2 bytes (31 total). I'd say that's doing pretty well.

Was the player represented by a box (i.e. the "ball") or by a shaped sprite?

I seem to be stuck in this game. On power-up I'm outside the castle but can't get anywhere. After using the reset button, I can't find the castle again.

And do you know where to find one for less than $15? I'm currently working on one (32K RAM + 64K flash + a new bankswitching method to aid hi-res graphics) but it's not done yet.

They don't include the tethered modes in Space Duel. If you want tethered spaceship action you'll have to Paypal $35 to Albert and buy a copy of THRUS+, with the most amazing tethered spae ship action the Atari 2600 has ever seen.

I've run 14-bit PICs at 115,200 without problem (using a 7.37MHz resonator) without problem. But I don't know whether the Speakjet uses the internal UART; its pinout seemed a little strange. I recognize that the SpeakJet has a buffer; my main concern is that if a game can't spare much time in vblank it won't be able to transmit more than a byte or two per frame. If the game could send data into a buffering chip at a rate of 100,000 bits/second, it could use less time transmitting its data and have more time available for other computations. Otherwise, what conventions should games obey in writing to the Speakjet's EEPROM? I assume you'd like them to leave the "Atarivox" chime alone, but what portions of EEPROM are available?

Consider also that while it doesn't happen often, it's possible for a cart to be in a factory-sealed box and yet be DOA. If the box has been opened, the dead cart can be blamed on the seller. But if it's sealed?

17777. The first half of each level seems pretty easy, but the second half gets nasty. I always seem to run out of time.

On the Z26 default (easy) difficulty? Play the game a bit more and you should get better. I usually make it to around level 17-20. I'm working on a RAM cartridge design; if I get that working, I'll code a deluxe version of SDI with scoring, space ships, better sound, etc. But in a 1K minigame I really can't afford the 50 bytes or so that would be required to replace the 'dot display' with a numerical score readout unless I sacrifice a lot of other features. The explosions are a little shorter, true. I might be able to adjust them, but an earlier version with bigger and slower explosions was a little ridiculous. BTW, who said anything about missiles? You do need more practice. In the later waves, the enemy rockets come in dense enough groups to trigger chain reactions. If you only reached wave 5, that's nine rockets on screen at once. Wait until you get to wave 14. Then you'll have twice as many. BTW, the program will handle a combined total of 31 rockets and explosions.

Well, some programs end up using much less than 128 bytes, in which case one enjoys such luxiries, and some programs end up using more than 128 bytes, in which case one pinches out RAM usage anywhere one can, even doing things like using one-bit flags to indicate which of two places called a routine. My SuperCharger minigame actually ended up with an unbelievable amount of ZP-RAM left over; until today (when I traded a boatload of ZP-RAM for a few bytes of code) I had almost 64 bytes of ZP-RAM left. It is funny some of the tradeoffs that one makes in such circumstances. For example, my code had a few 'lda $F000,y" instructions, so I used two bytes of RAM to hold the constant $F000 so I could use "LDA (f0ptr),y" instead. Took two bytes of code to hold the constant, and saved a byte of code each time it was used. If I need to free up two more bytes of code space, I have a couple of 4-byte tables I could move to RAM, thus saving a byte off the reference to each.

True. Unfortunately, since the Atari can't really do much while transmitting data, 19200 really isn't the ideal speed. A higher speed like 38,400 or 57,600 would be better since that Atari could output its data and then get back to what it was doing as quickly as possible. The idea with the enhancer cable would be to allow the Atari to sent up to 12 (or maybe 16) bytes very quickly, so that it could get back to doing other things while the data was forwarded more slowly to the Atarivox. This would allow much more data to be sent per frame in most applications, thus allowing complex multivoice music and other such effects.

I just completed a 1K minigame entry. The .bin file is 8,448 bytes because that's what emulators expect, but the actual data on tape would be 1,040 bytes of which the last 18 would be unused. Enjoy! The enclosed .bin file will load using Z26 or, better yet, using WPlaybin with a real 2600 and SuperCharger. I've not tested it with Stella; perhaps someone could oblige? sdi.zip

For the rightmost ring in the penultimate row, move the block down, right, down, right, down. Then move the slotted hockey puck down and right. For the other one, the block and hockey puck can build out from the left edge near the top until the hockey puck is in the right column, whereupon it can go down.