supercat

Explosions flickering is fine. After all, they're explosions. And 30Hz flicker on missle tracks is fine, since it's barely perceptible. But 15Hz flicker on an airplane or satellite would be intollerable. Besides, if the code is expanded to an 8K+ cartridge and uses 7 copies of the display kernel (selected based upon the X coordinate of the plane/satellite) there should be no need for the plane or satellite to flicker.

If using an 8K+ cartridge, might it be possible to clear GRP0 immediately after the desired copy of the plane is drawn?

Satellites wouldn't be possible I don't think, since there's no spare player sprite available. A somewhat-goofy-looking bomber plane might be possible using the ball (if the cursor doesn't) but even that would probably require a kernel rewrite.

Am I the only guy who'll stand up for this game? To be sure, a couple of slight hacks would improve it considerably [change the background color between 'zones' to make the boundaries clearer, and erase the sprite data for the obstacles] but despite its limitations I do find the gameplay compelling. Perhaps I'll code my own version with a few more improvements and see how that plays.

What do the graphics look like? Since the O2 only has four sprites, I'd think they'd have to so something interesting to 'jinx' the graphics, but I can't think how that would work. I don't think the 8048 is fast enough for 'venetian blinds'; does the cart do somethng else?

Cute game. Somewhat addictive, though I never get past the Green Zone. Those chopper packs sure don't seem to last long (at least not with my piloting). But I can't figure out what the other power-ups are for or what they do. Can you enlighten me?

Uh, sure. Run this: ; Magnet-drawing demo processor 6502 include "vcs.h" include "macro.h" seg org $F800 magnet: byte $3E, $7F,$7F,$7F, $FF,$FF,$FF, $FF,$E7,$E7 byte $63,$63,$63, $63,$63,$63, $66,$66,$66 byte $66,$66,$66, $36,$36,$36, $36,$36 magmove: byte $00,$10,$00,$F0,$00,$10,$00,$F0,$00 magcolor: byte $4C,$48,$48,$48,$48,$48,$48,$48,$48 DoFrame: botlp: sta WSYNC lda INTIM bmi botlp lda #$42 sta VBLANK lda #2 sta VSYNC sta WSYNC sta WSYNC sta WSYNC lda #0 sta VSYNC sta WSYNC sta WSYNC lda #20+127 sta T1024T ldx #31 toplp: sta WSYNC dex bne toplp lda #0 sta VBLANK lda #$86 sta COLUPF lda #5 sta NUSIZ1 ldx #8 ldy #0 nop nop nop nop nop nop sta RESP1 nop nop sta RESM1 lda #$00 sta HMP1 sta HMM1 lda #2 sta ENAM1 drawlp: sta WSYNC sta HMOVE lda #$00 sta PF2 lda magnet,y sta GRP1 iny lda magcolor,x sta COLUP1 lda magmove,x sta HMP1 sta HMM1 sta WSYNC sta HMOVE lda #$FF sta PF2 lda magnet,y sta GRP1 iny nop ; Get clear of HMOVE 'no zone' nop nop nop nop sta HMCLR sta WSYNC sta HMOVE lda #$FF sta PF2 lda magnet,y sta GRP1 iny dex bpl drawlp sta WSYNC lda #0 sta GRP1 sta ENAM1 lda #$42 sta VBLANK rts RESET: lda #0 tax resloop: dex tsx pha bne resloop cld FrameLp: jsr DoFrame jmp FrameLp org $FFFA .word RESET,RESET,RESET END That should give you a pretty good idea of the effect I'm thinking of.

Eightfold ROM expansion; sixteen-fold RAM expansion. Seems like a reasonable balance. It would be possible to add more RAM if the upper-order address lines were shared with the ROM, but that would mean that each half of the RAM was only available from within half of the ROM blocks; I would expect that in most cases this would be more trouble than it was worth. Adding jumpers to control this option might be possible, but would add to the cost. Using a more sophisticated PLD instead of a 22V10 would eliminate this restriction, but it would also increase the cost.

Burgertime didn't seem all that bad. To be sure, it used missles and the Ball to represent three of the enemies, but that allows the enemies to appear on the same scan line without flicker. The appearance might have been less annoying if the code moved those objects as it changed the width so as to make them spin about their center rather than the edge, but I would say the programmers did a reasonable job of trying to deal with the 2600's limitations. As for Basic Programming, I think it unfortunate that Atari didn't bundle a keyboard with it. Extending the normal keypad scanning techniques to a device that plugged into both controller ports would have allowed for 48 buttons. Not great, but it would have avoided the need for four different shift states. Be that as it may, the Basic Programming cart would seem like a pretty amazing accomplishment. Managing to get such a cart working while leaving half of the 2600's memory available is pretty amazing and I have no idea how Mr. Robinett accomplished it. My guess is that he must have re-used a lot of memory locations on-the-fly, but I still find it hard to believe. BTW, I wonder if would be adaptable to the SuperCharger? That'd allow enough user RAM to make things almost worthwhile. Also, BTW, I just tried Stellar Track. Pretty faithful adaptation of the classic 'mainframe' game, though I do find some things a bit puzzling. Although I remembered the directions 1-8, I have no clue why this game would use those instead of arrows. I also found irksome the fact that impulse engines won't allow the ship to leave a sector (in the classic versions, they would go to the edge of the next sector).

How about loading HMP1 every three scan lines with a value defined by the level data? This should allow you to create a magnet that's shaped like the horseshoe magnets used in grade school science classes. Also, any possibility of colorizing the string or going with the two-part popping sequence I mentioned earlier?

Well, most of the games for the O2 were pretty feeble, but there were a few real gems out there. I think my personal favorite is Killer Bees, but other great ones include UFO and Pick Axe Pete (I forget exactly how one plays PAP, but if you can find some instructions that would probably greatly enhance your enjoyment of the game.

What do you think would be "cheap enough" ? 880447[/snapback] No more than $5 or so cost over a 32K cart would be my guess, but I don't know the market situation.

It'd be good to have emulators support it, that's for sure. And it'd probably be good also if the makers of the KC/CC could support it. But before I invest $100 or so in a proto (along with hours building it), I'd want to make sure there'd be some usefulness. Note that my goal here is *NOT* to produce something like the KC/CC, but rather to produce something that would be cheap enough that the AA store could burn in Wormy III (once it's coded) and sell it as a Wormy III cart (assuming the game turns out to be any good).

Thanks for the information. The 2600 is clearly superior in terms of its playfield support (40 pixels wide), color output, and audio. The Odyssey has more independently-movable objects, however. The Atari's ability to 'clone' objects means that even without 'tricks' it can support a grid of 36 space invaders while the Odyssey cannot, but the Odyssey can let objects move without restriction, while the Atari is limitted to two freely-movable custom-shaped objects per scan line. If one views the Atari's abilities only as being those which Atari programmers demonstrated prior to Activision's appearance on the scene, I think the Odyssey fares quite decently in the comparison. The only real places the O2 would fall flat would be in the playfield graphics and in the support for a large grid of enemies (e.g. Space Invaders). If Adventure were coded on the O2, the mazes would be different but there could be up to four shaped objects on screen without flicker (as opposed to two) and not all objects would count against that (the player and the sword could be "character" objects instead of sprites). The real downfall of the Odyssey is not the hardware, but rather the quality of programming. The best games on the O2 are entirely beyond the abilities of the 2600. Of course, the best games of the 2600 are entirely beyond the abilities of the 2600. The biggest problem with the O2 is that developers have generally failed to push it to its potential. BTW, do you have any idea how "Killer Bees" is implemented? I'd think the player and enemy swarms are sprites, but what are the beebops and tombstones? Does the program do something tricky to use parts of different built-in character shapes to form them?

The O2 is in some ways technically superior to the Atari 2600, but it never had the benefit of third-party support. From what I understand, the O2's display design is based upon the notion that the processor sets up a display during the vertical blank and then lets the display chip draw it. This is distinct from the 2600 where the CPU is responsible for generating the display "on the fly". The O2 display chip allows much more powerful graphics than anything Atari seemed to have in mind when they designed the 2600, but because the latter is designed around (in fact relies upon) on-the-fly display modifications, it can do things the O2 generally can't. I would be curious to see technical docs for the 2600 if anyone knows of any. I think the video chip was an off-the-shelf Intel part, but even in ancient data books I've never found it.

I owned QftR way back when (still have the cart probably but the pieces are long gone) and found the board-game part a real disappointment. Did anyone actually play the board-game part and enjoy it?

Well, I hope all goes well. Your game seems pretty good though I wonder why Z26 goes to the high score screen at the end of the game (but then never saves scores). Is the game getting faked out into thinking there's an Atarivox installed? I'd really like to see this game go forward--it's really cool.

I didn't like the title music at first, but it sorta grew on me. I do wish the Atari allowed things to be better in tune, but wotcher gonna do? The tunes for level-advance and game-over seem rather wimpy compared to the title music. If you have space, fleshing them out a little more might be nice.

Right. Even if someone has an original idea from which they'll want to produce a 2600 game, it will often be far less frustrating to produce the game on some other platform first, get everything working so the game is fun to play, and then port it to the 2600. If a game isn't going to be any fun, it's best to find that out after spending a few hours coding it for an 'easy' system rather than spending two weeks coding it for the 2600. And if a game concept will need reworking, it's best to discover that before coding, especially if the rework would entail a major code overhaul (e.g. when writing kernels, one often has to choose restrictions to enforce on a game to make the kernel workable such as confining objects to certain parts of the screen; if play testing shows that such a restriction makes a game boring, it may be necessary to rewrite the kernel from scratch to eliminate it. Far better to make such discoveries before time is wasted on a no-good kernel.

One thing I'd like to see for the 2600 but haven't would be an inexpensive RAM-plus cartridge that could be used to produce saleable games. To be sure, the SuperCharger and Cuttle Cart are excellent devices which supply lots of RAM, but I can't realistically imagine someone taking a Cuttle Cart, slapping a game label on it, and selling it as a 'dedicated' game cartridge (i.e. a cartridge which is designed to simply play a single game). I've sketched out a design and I think it should be possible to construct an inexpensive three-chip cartridge which would offer the following features: 32K of ROM, in eight 4K banks 2K of RAM, in eight 256-byte pages Self-programming, assuming presence of a flash chip and boot loader Three jumper-selectable configurations The heart of the design would be a 22V10 or similar device. The mode-select inputs should be wired with RC delays so that they will both be low for a few miliseconds on initial power-up and will then be pulled up if jumpers are absent. Modes: -01- (first jumper only): Setting the RAM page address to 7 would deselect the RAM from the address space, making the flash available there. -10- (second jumper only): RAM page 7 works like any other RAM page; the first 512 bytes of each flash block are inaccessible. -11- (neither jumper): RAM page 7 deselects the RAM and makes flash available; requesting RAM page 6 deselects RAM and turns all flash accesses into writes. In addition, there should be a jumper for disconnecting the 22V10's write-enable output from the Flash's write-enable control pin (which should be pulled up). Anyone think such a thing seems feasible and interesting?

If one starts with a flash that contains a boot loader, does one even need a separate microcontroller? I would think the Atari should be able to program itself (a routine to program a 64-byte block of flash would be copied into RIOT RAM and run from there). One wouldn't have niceties like a hardware UART and would thus likely be limitted to 19200-N-8-2 or maybe 38400-N-8-2, but that shouldn't be a problem. Right now I'm working on sketching out an as-cheap-as-possible design for a RAM+flash cart intended to be a platform for SALEABLE games by homebrew developers. The goal is to use one RAM, one flash, a 22V10, some resistors, and some caps. In the cheapest configuration I could envision, the cart would support 32K flash and 1.75K of RAM and would have two jumpers. With both jumpers installed, the cart could be programmed by a bootloader; with them removed, the cart would be write-protected. There would be one bank-switching method available which does not AFAIK match any other known method (though if someone could direct me to something close that might be useful). Adding a few more jumpers would allow the use of larger RAM, though with some loss of ability to control RAM and flash addresses separately. I don't know what different programmers would want to do, so leaving such options open might be desirable. Flash would be divided into eight 4K blocks. Removing a jumper would force A14 high, mirroring the bottom four into the top four and allowing more easily the use of more RAM with 16K or smaller programs. In minimal configuration, RAM would be divided into eight 256-byte page, accessed at $1000-$11FF in Superchip fashion. Depending upon the status of a jumper, selecting RAM page 0 would disable the RAM and make the flash available there. For applications requiring more RAM, jumpers would allow upper-order address banking bits from the flash to be directed to the RAM chip, allowing up to a total of 16K RAM, but with restrictions on access. If the bootloader jumper was installed, selecting a RAM bank 4-7 would cause all accesses in the $1000-$1FFF range to be interpreted as flash writes. The bootloader would have to copy a small routine into ZP RAM, switch RAM banks (turning on write mode), do any necessary writes, switch RAM banks back, and return to running from flash. Bank switching would be keyed on reads or writes to selected addresses in the range $0400-$0F7F. Note that Stella and/or RIOT would be mirrored here, but the addresses could be chosen that would have no effect. Note that address bits 2-7 would not be decoded but are assumed below to be '0'. Address %0 010a **** **bc - Select RAM page abc Address %0 1abc **** **de -- Sets flash block bits XYZ thus: X=dX+a; Y=dY+b; Z=eY+c. Note that it's possible to manipulate either the first two or the last bit of the flash block address without affecting the rest. This should allow for easy sharing of the register between RAM and flash addressing. Anyone know of any bank-switching methods that are remotely similar (that would already be supported in emulators, CC, KC, etc.)?

The center card is a nine. The rest should be obvious.

Interesting. I can see that could offer a performance benefit over doing constant checks. If the code is broken up into pieces of about 64 cycles each, that benefit would amount to about 8%. Possibly worthwhile for programming wizards trying to eke out every possible bit of speed in a processor-intensive game, but not so import for mere mortals merely trying to avoid losing vsync while recalculating information for the start of a new level, etc. (users won't care if it takes 5 frames or 10 frames to place all the obstacles in a new level, but losing vsync is ugly).

The dot clock is derived using a PLL which operates as a frequency multiplier to boost the colorburst-based frequency to 8181817Hz. IIRC, it multiplies a 1438180Mhz (common crystal, 3579545*4) signal by 4/7. BTW, I believe Atari 8-bit computers just use a 1438180Mhz clock divided by two for the pixel clock, which gives them somewhat wider pixels than the C64. This results in somewhat slower processing, and also a wider screen display. This is why the Atari defaults to only using the center 38 columns with its BASIC cartridge.

If the goal is to simply share I2C and a joystick, I would offer an easy approach using two NFETs and a resistor. Wire the I2C pins to the left and right joystick inputs. In-line with the joystick itself, wire something like this on the left and right joystick signals [the paddle pin and resistor can be shared for both] Joystick/I2C ----, | | +5 ----------. | | | R | | D Paddle ------+--G S | | `----- From joystick During most code, the joysticks would work exactly as they normally would since the paddle input would charge to +5 and stay there. When it's necessary to access the I2C, discharge the paddle inputs and the joystick will be momentarily disabled allowing unfettered I2C access. Note that it would probably be possible to switch the joystick's ground pin instead of switching the left/right inputs, but that could cause problems with I2C communication if the cable wasn't well shielded. The biggest problem I could see with this approach would be that emulators might think the game used paddles.