supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
Thank you very much for the explanation, supercat. Could that technique still work with a 2 line kernel, or would the color have to alternate every third scanline instead?For best results, use a single-line kernel. Here's a demo which shows a few different styles of "rain" and sprite coloring. Use right difficulty and color/bw to select four styles of 'rain'. Use left difficulty to select between two styles of flicker. Use up/down to force the sprite to show frame #1 or frame #2. Note that for this demo I used half resolution (even and odd lines show the same data) but that would not be a requirement. Best results may be to use Venetian blinds without flicker, but you'll have to try for yourself to see what you like best.
-
Im working on the Wiz of Wor port "The Wizar Of Odyssey Square" but I am doing it via emulator at the moment. Sinistar is something someone is working on actually.Wizard of Wor would seem a pretty good fit for the O2, if one can manage to do a 'raster split' just below the bottom of the main map. The CBS version was playable on the 2600 showing two sprites at once; the O2 version could easily push that to four, and if you could manage to do a raster split it could do a nice job with the scanner as well (show two sets of two sprites side by side to show a 16x8 2-colors-plus-black bitmap). It might be possible to do the scanner with a bunch of period characters in close proximity, but I'm not sure the system would render those correctly.
-
I was in the business for many years at the time.never saw any use for an Apple, sure it's expandable etc but it was just awful for games and that was what sold at the time.The Apple ][+ had two hardware advantages over the C64 and Atari. (1) Its standard floppy-drive interface that was actually designed to be fast, and (2) it allowed more than one bus-based expansion device to be installed simultaneously. In nearly all other regards, the Atari and C64 hardware were superior. On the other hand, if people are trying to actually get things done and may need to switch between programs fairly quickly, a drive that lets a user switch between programs in under 10 seconds is vastly superior to one that takes minutes to do so.
There's also a curious 'image' aspect with displays. A program which designed to run in black and white on the C64 or Atari would look just as good on a monochrome display, if not better, than a similar program running on a monochrome display with a stock Apple ][+. On the other hand, programmers didn't generally code for black and white displays. A program designed for a color display will look more colorful on a color display than one designed for black and white, but won't match the crispness of black and white text on a monochrome display.
-
The basic approach for acceleration in Toyshop Trouble was something like:
(pseudo-code) target_speed = 0 if joystick is left then if firebutton then target_speed = -8 else target_speed = -3 endif if joystick is right then if firebutton then target_speed = 8 else target_speed = 3 endif if current_speed < target_speed then current_speed = current_speed + 2 if current_speed > target_speed then current_speed = target_speed else if current_speed > target_speed then current_speed = current_speed - 2 if current_speed < target_speed then current_speed = target_speed endif
A key question in your acceleration logic is going to be whether you can manage enough animation frames to keep the character's feet on the ground. If so, different approaches will be required.
-
Only with a hardware hack to the drive mechanism. The Disk II interface would pull bytes off the disk synchronously as fast as they were delivered by the drive heads. You can't speed that up with a "fast loader" a-la the 1541, you need to actually spin the drive faster. Or, as was done with DOS 3.3, improve the GCR coding to get more data onto a single track.The data stored on an Apple-formatted floppy has to be encoded so as to meet certain requirements. It's not possible to simply store arbitrary data bytes to the disk and read them back. IIRC, the processor has about 30 clock cycles to deal with each raw byte of data coming off the disk; unless one has some massive pre-calculated translation tables, that isn't enough time to do much decoding. Under DOS 3.3, the system would read a sector of raw data, then decode it, then read the next sector, decode that, etc. Reading a track of data would thus require multiple passes. Even under ProDOS, I don't think a whole track could be read in a single pass. If, however, software uses a simpler coding scheme to store information on the disk or else uses some suitable translation tables, then it may be possible to read data off disk in one smooth operation.
-
You know, I've heard the term "flicker blinds" tossed around before, but I'm not sure I understand what it is. I assume that it has to do with an interlaced display. If there is a good explanation of it on AA, could you point me in the right direction?The basic concept behind flicker is that the display alternates between states on (typically) alternate frames. Having large areas of the screen flicker can be very annoying. The idea behind flicker blinds is that rather than having solid areas of the screen flicker between two states, alternate lines of the screen will have the opposite state. As a simple example, one could show an object in a mixture of show tan, pink, and magenta by setting the sprite color to tan and displaying the tan and pink parts, and the setting the sprite color to magenta and displaying the pink and magenta parts. The pink parts would flicker between tan and magenta on alternate frames; the other parts would alternate between being displayed and not being displayed. Depending upon the nature and shape of the tan and pink parts, the flicker here may or may not be objectionable.
A second approach is to have the sprite color alternate between tan and magenta every scan line, keeping the mapping constant from frame to frame. This approach works, but the color striping may in some cases be objectionable. Further, it effectively negates half of one's vertical resolution.
A third approach is to combine the above two approaches: on one frame, make the even scan lines tan and the odd scan lines magenta, and on the next frame make the even scan lines magenta and the odd ones tan. In some cases, having alternate scan lines flicker alternately will make the flicker less noticeable; in other cases, it will make it more noticeable. I'll post a kernel demo later tonight to show the different approaches.
-
Why I'm posting on this thread I have no idea.... Maybe I'm the piano player who thinks the whorehouse should have good music.
I was doing that by flickering the ball in an insane, completely convoluted way. For some reason I thought I could eventually make each ball look like a falling stream of water... nope, I couldn't.
With a custom kernel, it would indeed be possible to do that, thus allowing the main sprite to be displayed without flicker or to use flicker or flicker-blinds to add more color to the main sprite. I'm not quite sure what the enemy is supposed to be, but if it will always have vertical separation with the main sprite there should be no problem with displaying it and the main sprite simultaneously.
Adding some more intermediate frames when moving would improve things. Your rotation demo before was very nice.
-
Pong, Space Invaders, Pacman. Even E.T. (2600) could rate a mention as it could be regarded as a catalyst of the '83 crash.An inescapable cause of the '83 crash was the fact that there were so many companies trying to develop games that the amount of money spent on development exceeded the total revenue customers had to spend. Things might have happened differently were it not for Atari's mis-steps with Pac-Man and E.T. but the crash was going to happen regardless.
-
Wow. No Quake? MANY other major omissions...Tetris certainly belongs on the list, though it should rank behind Super Mario Bros (a game which drove the second video game revolution, targeting those who already had home computers). Off the top of my head, here are some important games:
Odyssey -- First home console.
Pong -- Certainly in the arcade; knock-offs were by far the most common home video machines until ROM-cartridge systems took over.
Combat -- Launch title for the first massively successful game console.
Space Invaders -- Major arcade license that dwarfed what came before.
Adventure/Superman -- Pioneered the use of a world larger than the screen (Superman was published first, but it was derived from preliminary work on Adventure).
Kaboom! -- Put Activision on the map.
Pitfall! -- First game to try to create a realistic running-man animation (Donkey Kong had good graphics, but Mario shuffled around, while Pitfall
Harry ran smoothly). Perhaps the first game to create the illusion of a world which was too large to be fully tracked, but which allowed one to revisit previously-seen areas.
Wolf3d -- Not the first 3d texture-map game on the PC (id software's Catacombs 3d predates it) but the first such game to become popular.
Doom -- Introduced a new style of texture-mapped gaming, with arbitrarily-angled walls and variable-height floors and ceilings.
Quake -- Introduced a new style of texture-mapped gaming, with full support for arbitrary 3d angles as well as real-time lighting and precomputed shadows.
Are there even a dozen games on Guiness' list that were as influential as even the least significant of the ones listed above?
-
by serial there would be one address and the index counter load and count strait down.. or up whichever works for the instance.Sorry I didn't respond to this thread earlier.
Your question is whether, given four tables, it makes more sense to store the data as:
A0 A1 A2 A3 ... B0 B1 B2 B3 ... C0 C1 C2 C3 ... D0 D1 D2 D3 ... (parallel)
or
A0 B0 C0 D0 A1 B1 C1 D1 A2 B2 C2 D2 A3 B3 C3 D3 ... (serial)
The answer is: it depends.
If it will be useful to access the data for the tables using the same zero-page pointer, then serial data format is apt to be much more efficient. If the tables will be accessed using separate zero-page pointers, or will only be accessed using absolute addressing, then parallel will often be more efficient, but with an important wrinkle: because zero-page pointers have to be stored with both bytes consecutive, programs which are going to run a loop simultaneously on zero-page pointers and on other data may benefit from having data items spaced two bytes apart, with the data from two tables interleaved. The BTP2 music player in Stella's Stocking does that quite a bit.
-
I'd say 90% or better of the titles that feature at least one 2-digit onscreen counter do...it's just more efficient. The best-known example of a game that doesn't use decimal mode at all is River Raid, I suppose (neither does Pesco for a more-recent example).If one is trying to save RAM by storing two digits per byte, BCD mode is the only practical way to go. If one isn't trying to save RAM in such a fashion, other approaches may be better. For example, if one can spare 12 bytes to keep pointers to digit shapes "full time", and if one were always adding a multiple of a power of ten points at a time, one could do something like:
AddScore:; Assume X points to the digit to be bumped, and accumulator holds 7*value to add. ; The LSB of each digit pointer is are 186+7*digit clc AddScore_lp: adc score,x bcc done_adding sbc #70 sta score,x lda #7 dex dex bpl AddScore_lp ; Score is over 999,999 so do something with that... done_adding: sta score,x rts
Note that this approach is easily adaptable for any size score digit, unlike BCD approaches which usually require that digit shapes be stored at 8-byte intervals.
-
It sounds like all the code in bank E must access the TIA via $00 to $3F, whereas all the code in bank F must access the TIA via $40 to $7F.That's precisely what it does.
-
Every time this discussion comes up and inevitably turns to the possibility of completely gutting the play mechanics in order to produce a game that only vaguely looks like Killer Bees! it gives O2 owners something to feel smug about.Killer Bees! features five bee-bots that are 8 pixels wide by IIRC 16 or 18 scan lines tall. Rendering those using 3-block-wide playfield graphics (12 pixels) would not be totally outrageous. The swarms could be drawn using P0/P1/M0/M1. The issue of colors might pose some difficulty, but might be ameliorated by blanking the swarms on alternate lines. Not sure if there'd be enough cycles for that. Let's see:
; Even lines: 14 Load two GRPx. 10 Load two COLUPx. 8 Zero two ENAMx. 28 Load four playfield bytes. 5 Load playfield color. 3 Strobe HMOVE. *68 total ; Odd lines: 8 Zero two GRPx. 10 Load two COLUPx. 20 Load two ENAMx and two HMMxx. 28 Load four playfield bytes. 5 Load playfield color. * 71 total
Seems like that might be workable, at least in theory.
-
The game I always wanted on the Atari was the Spin-Out. That was a great game. Indy 500 wasn't even close to as good - or fun.I had an Odyssey2 when I was growing up and I tried to like Spin-Out!, but I just plain couldn't. When the barriers were enabled at the faster speed, going through them was a little tricky, but the lack of any sort of inertia made the game pretty feeble.
-
FAST floppy drives. Apple floppy drives were faster than anyone else's, by how much I don't know.The Apple's floppy drive controller was a brilliant piece of engineering, conceptually not unlike the TIA. It exploited the fact that the system's CPU didn't have any interrupts or cycle-robbing DMA to jinx its timing, and could manage better than a 10kbyte/second transfer speed (I wouldn't be surprised if specialized loaders could manage better than 20kbytes/second). Since the CPU that was grabbing data off the disk was the same CPU that was connected to main memory, data could go from disk into RAM without any bottlenecks.
The Commodore could actually manage a pretty respectable transfer rate on the 1541 when data was stored in specialized format. It's too bad that as far as I know Epyx never licensed that technology to any other vendors.
-
The O2 can have 28 objects on screen with no fancy cycle countingand not a drop of flicker.
The biggest limitation with the O2 is its poor selection of colors (second only to a SECAM 2600). There are eight background colors and eight foreground colors (which are lighter version of the eight background colors). That's it. The sound also makes the 2600's seem brilliant by comparison (one channel, without even a real volume control).
-
So, are you saying that's what the 7800's expansion port can do? Stream video/images from a LD/CD/DVD/Blueray (or whatever) and put sprites on top of that?The expansion port may have been engineered onto the 7800 board at a time when MARIA was expected to be capable of handling video overlay, but since MARIA does not have any genlock support it would have been impossible to engineer a practical video disk unit that could handle video overlay (today's DVD players all have frame buffers, so a DVD player could be engineered to sync to a 7800, but that would seem a bit silly).
-
but here's another way using addition(I'm going to be all cagey and not
comment it, it's more fun that way
)That is cute. How'd you come up with that? That ranks right up there with the following routine someone came up with (on another platform, but adaptable to 6502):
; Magical mystery routine (hint: use with acc = 0-15) sed adc #$90 adc #$40 cld
Anyone ever seen anything like that one before?
It's pretty impressive managing to do the nybble swap with only two "extra" instructions totaling four bytes/four cycles (considering the 4 two-cycle shift/rotate instructions as the "base"). I think the best I would have been able to manage would have been two instructions totalling four bytes/six cycles, plus a magically-pre-initialized register:
asl rol rol rol sax temp; Assumes X=$07 or $0F adc temp
-
Is this unstable with some versions of the 2600?I wouldn't expect so. During one half of each 6502 cycle, the internal data buses are unconditionally set to all "1"s; during the other half, any register which is supposed to output its contents will set to "0" any bus wire which should be "0". This requires considerably less circuitry than allowing each register to output both "1"'s and "0"'s. It also means that in case two registers try to put data on a bus simultaneously, any bit which is "0" in either registers will be "0" on the bus.
Some opcodes have some odd behaviors I don't understand, but SAX is very straightforward.
-
Would the Missile Command bonus tally count? It doesn't show the tally on screen the way the arcade machine does, but I'd call the arcade version a cut-scene and thus the 2600 one as well.
Maze Craze and Chess have cut scenes, sort of. Okay, that's really stretching it...
-
Supercat: I think the use of the MOS6502 would have been better than the VCS's MOS6507 processor, as Joe basically has said. The availability of the 16? registers in the 6502, vs. the 13 registers in the special made 6507 that the VCS uses, surely would have been a nice benefit to software programmers then and now.
A 6502 is a chip in a 40-pin package; I think 37 of the pins are actually used. A 6507 is the same chip in a 28-pin package; nine of the connection points on the chip are left unused. There were actually a number of 28-pin parts available, using different combinations of signals on three of the pins.
Using a 6502 instead of a 6507 would have only provided two extra features: -1- It would have expanded the available address space from 8K to 64K. Unless a larger edge connector were used for the cartridge port, however, the extra space wouldn't have really been good for much; -2- It would have allowed the RIOT to interrupt the 6502 when the timer expired. This would have made it easier for games that have a long 'think' to maintain some sort of video display while thinking, but for the most part the 2600 does just fine without such a feature.
Given that the machine originally used 2K cartridges, I think the 8K address space is entirely reasonable. It might have been nice to use another 74xx gate so the TIA and RIOT wouldn't be selected at addresses $0800-$0FFF (thus allowing carts up to 6K) but I don't know that even that would have been worth the cost.
The design of the 2600 manages to provide 'just enough' in many ways. The 128-byte RAM is cramped, but for many games it is quite workable. The TIA is pretty minimalist, but it too provides enough features to make things work. The color circuitry is simpler than that on some other consoles (which use translation logic to turn e.g. 4-bit colors into different combinations of luma and chroma), and yet works much better. The audio isn't great, but it provides serviceable music. Wonderful machine.
-
I've finally updated my website with reviews of Androman on the Moon and Actionauts. Check them out: http://www.atariprotos.com/The description of Actionauts gameplay is not accurate. Each arrow will move the robot one space regardless of the speed selected, so changing the speed will not allow the player to avoid walls. Further, running into walls is harmless for the robot, and in some levels is necessary (note: it wasn't necessary in any of the original levels, but it was harmless). The purpose of the speed control is essentially user convenience. At faster speeds, it's difficult to see what the robot is doing, but at slower speeds it may take awhile for the user to test out a program.
Speed could impact gameplay if the cartridge were more developed, since every time the robot completes all the steps in its program it fires a shot and restarts the program; this shot always travels in the direction the robot is facing. At faster speeds, it's possible for the robot to turn before the shot hits a wall, thus causing the shot to reach places it otherwise could not. Since there was never any code to make the shot do anything, such behavior doesn't really affect gameplay, but it is an interesting thing to notice.
-
One more point of curiosity: how fast was the logic in the TIA? Would it have been practical to derive a two-phase non-overlapping clock at 3.579MHz using the chroma circuit, as opposed to generating two-phase non-overlapping clocks at 3.579/4? Or was NMOS not fast enough to allow such an approach?
-
I don't know what you mean by the 'playfield module'.Page 5 of the TIA schematic (look in the 2600 area at the top, then "Archives"), in the lower-right corner. "Playfield module" may not be a technical term, but I'm not sure what else you'd call that bit of circuitry that holds the playfield registers and shifters. My question with regards to layout had to do with the fact that the shifter interconnects go from the top of one column to the top of the adjacent column, rather than running from the top of one to the bottom of the next. Small savings in silicon (avoiding four vertical traces), but taking such opportunities when they present themselves can be important.
I thought long and hard about this.The design used is descended from PONG, and repeated in things like TANK.
Those were built in descrete MSI logic; no processors were used.
For a programmable system, the obvious logical thing to do is:
- binary horizontal counter (228 color clock cycles)
- 5 x 8 bit horizontal position registers with comparators
You are correct that it doesn't facilitate easy replication.
It also is a lot larger in chip area. The counters are implemented in polynomial counters, not binary counters.
(That makes them about 1/3rd the size of binary counters.)
True, the polynomial counters are smaller than binary counters. But with a comparator-based approach one would only need one binary counter, instead of needing a two-bit sync counter and six-bit polynomial counter for each sprite. Given that the system already has a four-bit binary counter and a 4-bit comparator for each sprite to handle the HMOVE logic, I would think that adding two bits to that and adding two bits of fine position control would have been easier than adding five 6-bit polynomial counters and five 2-bit sync counters.
Too late to change the design, I though of replacing the 5 Hmove registers (which are also counters) with 5 Hposition registers. Basically, they would compare against the Hsync counter, and determine when to reposition the corresponding object horizontal position counter = reset it when the value in the position register matched.The trick: to get binary positioning, the cartridge would need to contain a 160 byte lookup table to the correct 8-bit polynomial counter values.
To meet the programmers' needs, I wrote the CHRST subroutine. Given a binary horizontal position, it figures out how to issue a reset at the right time (running a 15 color clock cycle loop), and then perform the correct Hmove (+/- 7 color clocks). The programmers liked it, so we left the hardware alone.
Have you seen the motion routine that from what I understand was first used in BattleZone, but has been used in many homebrews since? It takes advantage of the fact that "lp: SBC #15 / BCS lp" takes five cycles (i.e. 15 pixels). It ends up having to either use a 15-byte lookup table for HMOVE values or four ASL instructions to position bits for storage in HMxx, but still works quite nicely.
we came up with this almost for fun. We replicated the little biplanes and jets in what would become Combat.It was easy: just additional hard decodes off the object's horizontal counter, and then control bits to choose when to display the sprite bits. If we know that people would try to display characters with them, it might have been different...
I guess what I find really curious is that the slip-counter plus HMOVE approach ended up being more complicated than necessary for the main purpose, but allowed the 'just for fun' feature that turned out to be very useful. Nice bit of lucking out.
As for characters, when did you become aware of what Bob Whitehead was doing with Blackjack?
When we designed it, CHRST was only being executed once per object per frame, in VBLANK.Later, clever programmers started using it in mid-frame. We realized the error then, too late to fix...
What do you mean by "the error"? The artifact produced by doing an HMOVE at the normal time?
for many moving objects in the Combat display (the original target game) the motion vector for the tank had a 4 bit horizontal and a 4 bit vertical component. We used the high nibble for horizontal; I don't remember why. Probably because we could mask off the top 4 bits to add to the current vertical position value (a memory byte) without having to shift anything.I guess that makes sense. A slightly unfortunate decision, but not a particularly horrible one.
big questions!Main luck out: putting the display in firmware (to be cheap) opened it up to the creativity of the programmers.
It wasn't luck that led to the collision detection logic; we realized that it would save a great deal of processor time.
That wasn't luck. That was genius.
Examples of 'wish we had done it differently':- use 40 pin 6502 (cost 50 cents more, all in packaging)
- connect IRQ pin to 6532, so that we could run two threads: display, and game processing
- use 30 pin cartridge connector (cost 50 cents) to add top three address lines, R/W, clock, decode back
- hposition comparators (see above) instead of hmove register/counters
- if we could have afforded the chip area, have 40 bits of playfield instead of 20, used in one of three ways:
1) 40 bits across (cover the whole line with 4 clocks/bit)
2) 80 bits across, reflected (40 then 40)
3) 80 bits across, repeated (40 then 40)
Your first three items would have increased the cost of the unit, and I'm not sure there would have been much benefit. Cartridges did come along with bank switching, on-board RAM, etc. despite the lack of pins for them.
My wish-list items would have been:
- Separate NUSIZx enables for players and missiles (how much silicon would that have taken, including routing)?
- A 'divide-by-two' option in AUDCx (possibly using bit 0 or adding a new bit 4). If the counter could hold value for 64us, the feature could be implemented by killing one of the clock phases feeding the main counter. Probably less than eight transistors per channel if done using AUDCx.0; a little more if it used bit 4. Still, I shouldn't complain too much about the 2600's musical abilities. It's really quite good compared to almost anything else of the era.
- A 20-pixel mode for the playfield using double-sized pixels. Adding too many playfield registers would, I think, have been a mistake, since there's only a finite time available to update them. For most games, the existing set is more useful than a five-byte set of registers would be, unless the latter happened to include a means to update multiple registers with one write.
- For PAL 2600's, an read bit to report even-odd scan line (this would make it easier for games to avoid losing color if something slips by a scan line).
- A means to write a sprite without copying the other sprite's delay register (see note below (*))
Of course, some of those notions are created with the benefit of 30 years' hindsight. I'm amazed at what you pulled off.
Out of curiosity, have you seen any of my projects? Strat-O-Gems, Toyshop Trouble, or the Stella's Stocking menu? And have you read at all about my 4A50 cart?
Strat-O-Gems is a game I started back in 1994 but abandoned because I couldn't figure out the RIOT. I finished it in 2005. It manages to do 'thinking' processes that take multiple frames to complete, without causing loss of video. Things would be a little more efficient of the 2600 had interrupts, but the lack of interrupts is hardly a major problem.
Toyshop Trouble is my favorite of the games I've done. It shows four player sprites per line with independent color and shape; three of the objects move together horizontally, while the other has free horizontal and vertical motion. I sometimes like to imagine what you guys would have done if I'd smuggled a copy of the game back in time and showed it to you; there are a lot of TIA tricks in that thing. Incidentally, the game uses an 8K EPROM with one off-the-shelf 74xx chip, something I don't think was ever done in the day (games either used multiple chips or custom logic).
The Stella's Stocking menu must be seen to be believed. Four-voice music through a five octave range, with full chromatic support. The music driver uses 46 cycles/scan line, leaving 30 to draw the display.
The 4A50 cart includes 32K RAM and 128K flash, using my own banking scheme. What makes it unique is that writes and reads can be performed at the same addresses with no special coding tricks required. Even code execution and read-modify-write instructions work 'normally', despite the lack of a R/W line to the cartridge.
(*) Handy sprite addressing:
Given that the TIA has a fair number of free addresses, it might have been handy to make address 11xxxx write to sprite registers thusly:
11xxx1 -- Write to player 0 write register
11xx1x -- Copy player 0 write register to display register
11x1xx -- Write to player 1 write register
111xxx -- Copy player 1 write register to display register
I can't see that anyone would have seen any use for such a thing when the 2600 was designed, but it would have allowed a 'write' register to be latched without copying the other sprite's 'delay' register, thus allowing four bytes' worth of data to be latched in sprite registers before the start of sprite display. It would also have made it easier to show identical data on both sprites, and to clear both sprites when switching between screen zones. It might have required a little routing, but otherwise would not have required any extra silicon.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
How hard is it to program for Atari 2600?
in Atari 2600 Programming
Posted
The 2600 definitely has its challenges. That having been said, there are somewhat different expectations with different platforms. While an NES version of something like Toyshop Trouble would probably be considered a pretty good even if it did very little beyond what the 2600 version does, the expectations for NES games tend to be higher than anything the 2600 can realistically do. Though sometimes (as with e.g. Thrust) the 2600 does things it can't realistically do (but does anyway).