Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

49 Excellent

About supercat

  • Rank

Recent Profile Visitors

23,690 profile views
  1. I would expect that the game wouldn't bother with sprites. With the proper "color" selection, it should be possible to use a 4-color 320-mode bitmap to achieve 16 colors using artifacting in a fashion similar to the Apple //e double-hi-res mode (simply have the CPU draw everything onto the bitmap).
  2. Hmm.... I know 8Kx8 chips existed, but I'd thought they were too expensive to be used in cartridges. Atari certainly seemed to think they were too expensive to go in the 7800 itself (the 7800 is laid out so it could use an 8K chip rather than two 2K chips, but it of course doesn't contain one). Given 16K of RAM, I would guess then 7800 could probably do a somewhat decent-looking version of tempest using one of the 320 modes along with aliasing, though the MARIA would gobble up a lot of cycles. The screen bitmap layout would need to be a little goofy, but probably no worse than the Apple II.
  3. The 7800 hardware is good for showing many non-scaled sprites at 160-dot resolution and tolerable for showing tiled backgrounds. I haven't seen the Atari 5200 version of Tempest, but I would guess it probably uses a 160x200 four-color bitmap screen. On either the 5200 or 7800, such a screen would require about 8K of RAM. Not a particular problem on a system which has 16K (like the 5200), but a bit difficult on a system with only 4K (like the 7800). Although 8Kx8 static RAM chips had become available late in the 7800's reign, they were pricey. The Atari 5200, if it was typical of its era, would have used eight 16Kx1 dynamic RAM chips along with some controller logic. Those were dirt cheap (all eight chips in the 5200 probably cost less than the two 2Kx8 chips in the 7800), but required complex controller logic that the 7800 lacked. Further, getting eight RAM chips to fit into a cartridge might have been difficult.
  4. I don't think Tempest would not have been practical on the 7800 with 1980's memory prices unless the cartridge included some interesting custom hardware. The hardware to create good-looking backgrounds while using a modest amount of memory might not have been too outrageous (it would probably be possible to combine connect four reasonable-sized ROMs and a little extra logic to generate background graphics) but I'm not sure how to handle the spikes at high enough resolution to avoid horrible jaggies without using 8K or more of RAM to hold a bitmapped screen. One of the ARM-based 7800 cartridges might be able to pull off a good Tempest clone, but that would seem like "cheating". Actually, I wouldn't be surprised if one of those carts could pull off a 7800 version of Wolf3d or even Doom, but that would really be cheating.
  5. Not to be overly vain, but in Strat-O-Gems is used with an AtariVox or other EEPROM device in port 2, the attract mode will show the play which resulted in the deepest combination and the play which yielded the most points. One day I left my nephew alone with that cartridge, and when he told me he'd gotten a 7-deep combination I might not have believed him except that the attract mode showed his amazing play.
  6. Having A11 feed an active-low chip select on the TIA and RIOT would have increased the cartridge address space to 6K, or made it easier to have 2K on the main board and 4K in a cart.
  7. I just saw the arcade game upon which it is based. Interestingly, from the look of it, I'd say the arcade machine was using flicker multiplexing to display the two on-screen enemies at once (the enemies scaled much more smoothly than the 2600, though).
  8. Both Mr. Do's Castle and BurgerTime were ambitious projects, whose programmers bit off a bit more than they could chew. I suspect that if programmers had known in advance the limits to what they'd be able to pull off, the projects would likely have been skipped in favor of games that would better fit the 2600's abilities. Incidentally, back in the day I estimated that BurgerTime would need more than 256 bytes of RAM and wondered how they pulled it off; I didn't realize (1) the 2600 only has 128 bytes [not 256] internally, and (2) some cartridges add a little RAM, and BurgerTime in particular adds a boatload (a whopping 2K!) Both 3d Tic Tac Toe and Stellar Track were implementations of games that were popular on the HP-2000 time-sharing system. A 3x3x3 version of Tic Tac Toe was sold under the name Tri-Tac-Toe and featured three glass shelves along with yellow and blue marbles; as a game, it leaves much to be desired since the center square is way too powerful. A 4x4x4 version using plastic shelves and tokens was sold under the name Qubic. One good thing not mentioned about Froggo's Karate is that if one removes the chip, one can solder in a 2764 socket (only 4K is used). That's how I got my start 2600 programming (I think I burned about half a dozen chips before I decided that 24hr turnaround (2600 was at home, and the programmer was at work) wasn't going to cut it. As for things like Star Ship, it was the first 2600 cartridge to multiplex sprites using flicker (perhaps the first game of any sort to do so?) Flicker multiplexing can certainly be abused, but without it a lot of very good 2600 games wouldn't work at all.
  9. I would think so. There are a relatively small number of features I've found myself wanting that could probably be added fairly easily. Given that 6502 code for the 2600 often has "unusual" address restrictions (e.g. a requirement that some branches and data structures must not cross page boundaries often implies that certain addresses may only be relocated to certain addresses within a page) I don't think a separate link is as helpful with 2600 code as with some other platforms. The things I would add would probably be the following: A mode in which DASM allocates buffers for specific addressing ranges, sends output to those buffers, and then outputs them at the end. This would facilitate use of constructs which allocate data non-sequentially. Better control over the number of passes, and the requirement that labels be resolved by a certain pass. Built-in opcodes for sbne, sbeq, sbcs, sbcs, etc. (which perform like bne, beq, etc. except that they will generate a diagnostic if, on the last pass of assembly, they cross a page boundary. This can be done with macros (I often define macros for that purpose), but using macros clutters the listing file. New .org-style directives which would set the logical or physical output address while keeping the same displacement between those two addresses Bounds checking on the ds directive. When I first started looking at Atari programming in 1994, I would have found DASM to be a massive improvement over any of the alternatives I could find at the time; I started Strat-O-Gems with an assembler that was a big quirky, and nowhere near as nice as DASM. I'm not sure what improvements are needed which couldn't be accomplished with a few tweaks to DASM. I'd been load to change DASM and make any code that used new features be incompatible with what everyone else was using, but if people are going to migrate to something else I think it might be better that it be a tweaked DASM than something completely different.
  10. While building a cartridge using a CPLD plus discrete RAM and ROM is an interesting challenge, I don't think it's really viable as a production-worthy approach. Using an ARM is just so much cheaper and easier. That having been said, my banking scheme was designed around the goal of using macrocells as efficiently as possible. It had four bankable areas: $1000-$17FF -- Bankable to any 2K chunk of RAM or ROM $1800-$1DFF -- Bankable to the first 1.5K of any 2K chunk of RAM or ROM $1E00-$1EFF -- Bankable to any 256-byte chunk of RAM or ROM $1F00-1FFFF -- Fixed at last bank of ROM, but accesses will copy bits 3-6 of the address to bits 8-11 of the address for the $1E00-$1EFF bank. The "interesting" behavior of the last bank was designed around high-res graphics. In particular, if $1F00-$1F5F was filled with $01,$02,$04,$08,$10,$20,$40,$80 and $1F80-$1FDF was filled with the complements of those, then a "pixel set" for coordinates in X and Y registers would be: lda $1F00,x ora $1E00,y sta $1E00,y and a "pixel clear" would be: lda $1F80,x and $1E00,y sta $1E00,y I also discovered that the same hardware worked very well for my game Ruby Runner; I defined the codes for various object types in such a way as to allow my board-scanning loop to be something like: ; Running from 6507 address $1E00 lax (scanPtr),y nop $1F00,x ; bank-switch ... start processing code for that type of object Rather than have to use a computed jump table to dispatch code for each type of object, I simply used the $1Fxx area to select one of 16 pieces of code to execute. If I were designing a CPLD-based banking system today, I think I would specify that code should only be run from addresses $1800-$1FFF or $0880-$08FF. If code is only executed from those addresses (and in particular, not from $1000-$17FF), then the normally-inaccessible address bits A13-A15 for any access to $1000-$17FF will have been on the data bus D5-D7 during the last access that wasn't in that range. Thus, one could fairly easily setup a scheme in which $1000-$17FF was one bankable "data" area, $3000-$37FF was another, $5000-$57FF was another and $7000-$7FFF was a fourth. It would be especially nice if one could have the start address of each such area be specified with resolution of a page rather than a 2K block, but I don't think that would be feasible in a 95C72; you'd probably have to go up at least one more size for that.
  11. For any reasonable-sized Atari project, the time required to assemble the whole thing is going to be pretty negligible. Using macros to arrange memory in DASM can be a bit tricky, but it can do some pretty neat tricks. There are some things that could be improved with DASM, but if the main objection is the lack of separate-link support, I'm not sure I see that as a problem.
  12. That design used a Xilinx 9536XL CPLD with 36 macrocells, clocked at 14.3818MHz (12x cycles per bus cycle), which was accurate enough that the timing would be correct at the end of a 75-cycle fetch following an STA WYNC,. I didn't watch for changes on all the address bits (not enough logic to do that). Instead, I resynched the clock every time I saw a change on A0. I'm pretty happy with the bank scheme I implemented back then, even though nowadays one could do better with an ARM.
  13. Does the linker have any means of issuing warnings if specified branches cross page boundaries? When coding in DASM, I rely upon "safe-branch" macros which will squawk if the target isn't in the proper page. If I get a squawk when I assemble my code, a little rearrangement will usually fix it. Unless link sections are aligned on 256-byte boundaries, I'm not sure how readily one would be able to detect such cross-page faults.
  14. A useful trick with writes, which I invented in 2006 I think, is to use a "bus keeper" circuit which weakly pulls pins on the data bus high if they're high, and low if they're low. On the first half of each cycle, read a byte from RAM at the appropriate address and output it briefly on the bus (whereupon the bus-keeper circuit will effectively latch it). Just before the end of the second half, copy the value on the bus. If the 6507 performed a read, the data will still be on the bus. If it performed a write, the new data will be on the bus.
  15. I've been out of 2600 programming for awhile, but would suggest that a useful trick for improving legibility of "flicker-blinds" text is to try to balance out the "even" and "odd" frames. This will work best with text that's either 7 or 11 lines high, so that something like an "E" will have the center line flickering opposite the top and bottom. Also, it can be helpful to design an "E" like: XXX X.X X.. XX. X.. X.X XXX so that the "serifs" balance out the even and odd frames.
  • Create New...