supercat

The AtariVox operates at 19200 baud 897085[/snapback] Why'd I think it topped out at 9600? Oh well... an 6-fold speedup in communications might still be useful. And building such a thing into cable that could double as the PC interface might not be a bad idea. Just a thought.

The AtariVox is a really cool piece of hardware, but unfortunately, its 9600-baud communication rate means that it takes 15 scan lines to output a byte. In many cases, this will limit games to 1 byte/frame of data, thus limiting the use of the AtariVox for things like background music, etc. My idea would be for an enhancement cable which would consist of a DB9 male, DB9 female, and a PIC12C508. The PIC would be programmed so that normal AVox communication would be passed through unaltered, but a programmer could, if desired, output up to 12 bytes per frame at hyper-speed (about 1.5 scan lines/byte) and the Enhancer would pass them on to the AVox at 9600 baud. I would think this would greatly enhance performance and versatility of the AtariVox unit. My one concern would be leaving out in the cold people who have the Avox but not the enhancer. I'd be more than happy to share the 12C508 code with the AVox designers if they want to produce an Avox with the enhancer built-in; since a 12C508 is very cheap it shouldn't add much to the cost. Anyone have any feelings pro or con?

Another thought: if having a two-hit brick flicker is desirable, what about declaring that a brick whose pixels are both set is a one-hit brick (unless it's unbreakable), but a brick only one of whose pixels is set is a two-hit brick. Then use a 256-byte translation table once per frame on all the bricks to switch any left-pixel-only bricks to right-pixel-only bricks.

Very nice. It would be useful, though, if you could add some sort of 'undo' feature. I know multi-level undo isn't likely on a stock 2600, but even a single-level undo would be very handy.

Well, I just got my AtariVox and the game is sorta cute with it (though I prefer my games not to use profanity no matter how badly I do). Unfortunately, the high scores don't seem to save properly. Has anyone else had this problem? I'm using the supplied 9-9 extension cord with my Atari 7800.

In doing comparisons, it would be good to be willing to 'swap' the operands if need be to improve code. For example: ; if a>=b goto foo lda a cmp b bcs foo ; if a<b goto foo lda a cmp b bcc foo ; if a<=b goto foo lda b cmp b bcs foo ; if a>b goto foo lda b cmp a bcc foo Oddly, I've seen a number of C compilers for various micros which, rather than swapping arguments, will use two branch instructions even when swapping arguments would cost nothing. Not quite sure why.

First of all, while you might get away for a little while with connecting the 2600 directly to the car's 12 volt supply, doing so would likely overheat the 7805 regulator and would also expose the Atari to some really nasty voltage transients. It might even cause the main supply cap in the Atari to spew nasty electrolyte stuff all over the 2600's internal circuitry. Not what you want to have happen. If you use a plug-in adapter to convert the 12 volts to 7.5 regulated, then you'd be drawing somewhere between 100-500mA, depending upon the efficiency of the adapter and your choice of cartridge. This would probably represent a load roughly comparable to leaving your dome light on (depending upon the dome light). You could get quite a few hours of service, but not unlimitted. Note that a switching-power-supply based voltage converter would almost certainly be a fair bit better than using an inverter and a 9 volt wall brick; even a linear supply would almost certainly be no worse.

If it does, then bB is broken. If score is 1, it should get set equal to zero. Once it's zero, it shouldn't get decremented anymore. Only way I can see that happening would be if bB is messing up the comparison and treating ">" like ">=" or something.

How does the 6x8 MSDOS-window font compare? The Apple II was 7x8, but the rightmost column was simply blank. Aside from character 127, I think the shapes should mostly be pretty close though I don't have an Apple II handy to check.

Why would one want a cart button for either of those things? IRQ is sorta useless if software can't tell what caused it (I suppose if you want to pause a game, an IRQ switch might sorta work, but it'd seem just as likely to crash). NMI is available from the keyboard [Restore key].

I liked the "Radioactivity" demo. Three voices plus "digitized" drums on the C64 (probably done by modulating a volume register or something).

As a brainstorm, if you can spare a couple bytes (and a few cycles between playfield 'rows') it might be useful to have a 'display list' which is accessed via indirect pointer and which lists, for each playfield 'row' the number of scan lines it should occupy and the source of the row's graphics. Using an indirect pointer for this would allow the user to switch among display lists during program execution, but would be much more 'affordable' than keeping display lists in RAM. If the total size of all display lists was 256 bytes or less, the RAM requirement could be reduced to 1 byte (index into the start of the display list area). In that case, I would expect the display list code (run before each row of the screen) to look something like: RowStart: ldx dispIndex lda DisplayList,x ; Number of rows beq DisplayEnd sta shortcount inx lda DisplayList,x inx stx dispIndex tax lda 0,x sta column0 lda 1,x sta column1 lda 2,x sta column2 lda 3,x sta column3 ... DisplayEnd: lda DisplayList+1,x sta dispIndex Each display-list entry would contain the number of scan lines for which that row of playfield pixels should be displayed, and the source of the playfield data. Including the data source in the display list would allow for some more complex playfields than would otherwise be possible without increasing RAM requirements. The last display list entry would be a "0" followed by the index of the first display list entry for the current display list (thus avoiding the need to keep a pointer to the start of the current list in addition to a pointer to the current index within it).

Never tried PIS, but I just tried the three Mythicon titles last night (had to see what this 'Fire Fly' was that people kept dogging on). I do think that some of the people who dog on Mythicon's games probably failed to read the directions, since the games default to 'practice' mode with unlimitted lives and no score. While the addition of a life counter and scoring doesn't exactly make them great games, it does at least give them some sort of point. I'll admit, though, I found myself wondering what the box meant when it said "First in the Fire Fly series". It's interesting, though, to compare Fire Fly and Solar Plexus. Fire Fly has bright colorful objects while Solar Plexus just has single-color objects. But despite being bright and colorful the objects in FF for the most part look terrible. And the gameplay in FF is annoying. SP isn't exactly sophisticated gameplay, but it's playable and amusing despite its simplicity.

How hard would it be to add an option (static and/or run-time) to change the on-screen dimensions and positions of the playfield? The pixels right now are rather big and bulky--necessary to fill up the screen without using two much RAM, but not all games require filling the screen. A game like Breakout probably wouldn't need more than 11 rows, but it would benefit greatly from having the rows be smaller and located at the top of the screen.

I suspect that the reason a lot of games have scores that count up quickly is to avoid having to do any 'real' binary to BCD conversion. This approach can be used very nicely whether adding by ones, tens, or some other increment (multiple variables may be used if counting will be by various different increments). It can also be useful for implementing score multipliers (if scores will be multiplied by 1x-9x, simply add the unmultiplied score to 't', and then each time 't' is decremented add the multiplier to the score).

Well, I think we need to avoid cluttering up the store with junk in a repeat of 1984. What's important I think, though, is not to decide that bB games--no matter how good they may be--shouldn't go in carts while asm games--no matter how bad--should, but instead to look at games on their individual merits. Perhaps it would be good to make a multicart of different people's efforts. A 32K cart with a menu and seven 4K games won't cost much more than a single 4K cart, but will show off seven times as many games. Further, nothing terribly fancy is required to allow 4K games to be 'multiplexed' on a 32K cart if programmers are told not to put anything except the reset vector above $1FF3. The person combining all the carts simply has to copy the reset vector of each bank (except the seventh) to $1FFE, point the reset vector to $1FFB, and put a $4C there. would be contain the menu, and would select a game by copying a small piece of code into ZP RAM and executing it. To run the game selected by the X register, simply CMP $1FF4,X JMP ($1FFE) Piece of cake, with no other coordination among the different programs necessary (though if they wanted to exit to the menu, they could by doing a JMP $1FFB).

Sorry, I hadn't noticed 't' was used for something else. Well, pick some variable that isn't (is 'g' free?). In the frame loop, if it's not zero, add 10 to the score and subtract 1 from it. Otherwise, to add some value (times ten) to the score, just add it to the variable and a few frames later it will be added to the score.

How about doing something like: ; To add 'i' to score: t=t+i ; Elsewhere in the frame loop if t>0 then t=t-1:score=score+10 This should work for adding any number of points up to 2550, with the caveat that adding too many points too quickly could cause overflow in 't'.

Yeah, well that's even further before my time than the 1960's. BTW, I developed an interesting method for doing long division which would be really cool if someone hadn't patented the same thing shortly before (and unbeknownst to me). It would be especially useful for performing really huge divisions on machines with a fast multiply but slow divide. Cute bit of code. Looks like it should be extendable to produce 16-bit results also.

Mr. Baer, the inventor of the kid-vid, used a "kiddy-looking" tape player for his prototype. He was rather annoyed that the real units were so dull looking. Also annoyed that it was sold for the Gemini (a 2600 clone) rather than for the 2600.

I'm not a big fan of big single-color PF graphic title screens. But a kernel option to replace specified rows of the PF and everything else with a 48-wide vdel sprite or a 96-wide flickersprite might be cool, especially if the data was 7 or 13 bytes wide to accommodate colors.

Basically, you're replacing division by a constant with multiplication by a constant. This is an optimization approach which goes back at least to the 1960's, and probably even earlier. It's often an effective approach, but one needs to be careful to ensure that the results will aways be rounded in the expected direction (if one cares). By the way, there are some interesting table-based approaches to multiplication by non-constants which can be somewhat practical if one is doing a lot of multiplication, but require some care to ensure correct operation. One nice method, for example, takes advantage of the fact that A*A-B*B = (A+B)*(A-B). FastMult:; Multiplies n1 by n2. Requires that n1+n2 be 255 or less, and n1>=n2. lda n1 clc adc n2 tax lda n1 sec sbc n2 tay lda squareL,x sbc squareL,y sta resultL lda squareH,x sbc squareH,y sta resultH Fourty-two cycles for an 8x8->16 multiply, subject to the restrictions noted above. Considerably faster than the shift-add method, but at the expense of 512 bytes worth of tables. The tables should be computed such that ([squareH+n]:[squareL+n]) equals int(n*n/4).

That's what the "dec mul2" and "inc mul2" instructions are for. Other ways of dealing with the issue would be to subtract mul1 from the accumulator before the multiplication (which would work nicely for the low-half, but correctly dealing with the high half would be more work), inverting mul1 beforehand and then reversing the sense of the branch (adds two bytes/two cycles at the spot where mul1 gets loaded, but makes the routine more 'opaque'), or adding a "clc" before the "adc" [which costs one byte instead of four, but sixteen cycles instead of ten].

I'd forgotten for some reason that if you have 1 bit per block stored in ROM, you can't change it during the game. Maybe I'm too used to the Supercharger (where all the code is in RAM). Still, you might be able to do okay if you don't mind sprawling out your kernel a little bit, using an extra few bytes of RAM, and possibly adding two no-bricks scan lines between the rows of bricks. The key is to observe that right now you're using two bits of RAM per brick (because each brick is two lores pixels wide). What you need to do is pack one bit from each of eight bricks into each byte. Then you can use something like: ldy bricks1,x lda translate1,y sta PF1 lda translate2,y sta PF2 lda bricks2,x lda translate1,y sta PF2 ; Be sure to time this one right lda translate1,y sta PF1 Unfortunately, doing the translations like that probably takes a little more time than you've really got available (since you also want to display other things as well). Thus, I would expect you'd probably have to make some clever use of temp variables in a sprawling kernel design (which would probably not be a problem in an 8K or 16K cart, but might not be possible in a 4K cart).

Well, for $7 you can buy a board at AtariAge.com that you can stick a 2K/4K eprom into, and for $9 you can get one for 8K, 16K, or 32K. I'd suggest buying an 8K board and burning a Hack'Em EPROM. If you really want to get fun, remove the label from a Pac-Man cart, replace the guts with your new board, and carefully seal it all up. Then if someone jokes about how terrible 2600 Pac-Man is, you can show 'em yours.