supercat

It would be bit 5 of the cycle following the 1FE access (could be $01FF for an RTS, or it could be the last byte of a JSR instruction). The actual bank switch needs to be delayed long enough to ensure that the operand fetch for the JSR isn't corrupted. It would seem the timing would be a little fussy. I can imagine that it might be handy, for some games, to simply switch one way on every JSR, and the other way on every RTS. That would be easy enough to do, though there are a number of ways one could do it, with differing effects for accesses other than JSR or RTS.

I've read varied descriptions of how it works. To really find out, one would have to do something like design a board which would feed address/data values to a cart with particular timings and see the result. From some descriptions, it sounded as though the FE cart might be sampling one of the data bits some time after an 01Fx access. Doing that with the proper timing would allow one to JSR/RTS between banks arbitrarily (the cycle following the second stack access will be the MSB of the next code address).

I tried to load it into VC++express 2008, and it can't find SDL.H and other SDL-related files. Is that another package I need to download?

DASM uses square brackets for arithmetic grouping. Ordinary parentheses will also work for arithmetic grouping in some contexts, but will be interpreted as special addressing modes in other contests. I tend to just use square brackets in DASM instructions whether or not it's necessary in any particular context. For example: if FOO is $4321 and BAR is $1234, "JMP [FOO-BAR]" will be regarded as "JMP $30ED", while "JMP (FOO-BAR)" will be assembled as "JMP ($303D)", a different instruction.

Word for the day: retronym. Examples: black-and-white television, silent movie, acoustic guitar, pocket watch, reel-to-reel tape.

Tough call. There's something cool about having a cart power on with some music (as E.T. did, or Toyshop Trouble, or Stella's Stocking) but at times it may get annoying. Probably if music is included, the best thing to do would be to have the music and screen both time out after a few minutes until a controller is bumped. I'd generally be disinclined to include game sound effects, though.

I think that standard was published at a time when a lot of games were 16K, and code space wasn't seen as a severe constraint. Adding an attract mode does make a game look more professional.

I was looking at the thing briefly yesterday; I like the idea a lot, but would like it even better if it were annotated. One thing I'd be curious about is what would happen if each phase were subdivided into two sub-phases and used three-state ('0','1','X') logic thus: In the first sub-phase, any node which is, or may be, pulled to a value other than its current value, is assigned a value of 'X'; simulation iterates in that state until all nodes that are going to be assigned 'X' have been. In the second sub-phase, nodes whose state can be determined to be '0' or '1' would be resolved. This would mean that any node whose result was affected by a race condition would report a value of "X", even if in hardware one state would be guaranteed to "win". My guess would be that ANE (the non-working "LAX #imm") would load the accumulator with all "X"'s, but most opcodes wouldn't. Not sure about "JAM".

My guess as to what ANE is doing, without seeing a transistor-level simulation, is that on one internal bus the 6507 is outputting the value read from the accumulator, and on another bus the 6507 is outputting the value of the first bus and the value read from the data bus. If the second bus has inverted logic levels compared with the first, the effect would be a race condition, since both buses would be precharged to '1', and once either bus was pulled low the system would become stable. I wonder it that's what's actually happening?

I do think one light-up indicator would have been nice. It wasn't uncommon for people to try to play a game and get nothing but static; since both video cabling and power connections were common problems, having a power indicator would have been very helpful. Additionally, since Atari was trying to stress the importance of not inserting or removing cartridges with power on, a light near the cartridge port could have helped convey that message.

Some of the unstable instructions decode to multiple instructions with behavior which is contradictory or involves odd feedback. The LAX instruction, for any mode other than immediate, decodes to two instuctions (LDA and LDX) whose behavior is identical except that one hits the load-enable signal for the accumulator, and the other hits load-enable for the X register. Since both instructions cause the same data to be loaded onto the internal operand-input bus, the effect is that the data gets loaded into both registers. The SAX instruction decodes to two instructions (STA and STX) whose behavior is identical except that one hits the output-enable signal for the accumulator, and the other hits the output-enable signal for the X register. Although it would seem that this would cause ambiguous behavior, it turns out that during one half each cycle the inernal operand-output bus is set to all "1"'s, and the read-enable signals for the accumulator and X register (and Y register, stack pointer, etc.) only allow those registers to set the internal operand-output bus bits to "0". Thus, if a bit is zero in either the accumulator or the X register, it will be stored as zero; if it's set to "1" in both, then nothing will pull down the bus so it will output "1". The problem with LAX immediate is that its decode is a combination of LDA, LDX, and TAX. This causes the current contents of the accumulator to be merged in with the value loaded from the data bus. Normally, during an LDA or LDX instruction, it doesn't matter if the operand-input bus is stable during the whole half-cycle for which they're enabled. Nothing is reading from the registers while they are being loaded; as long as the bus has stabilized before the load-enable signal goes away, the registers will end up with the correct value. The LAX opcode, however, enables the "output accumulator" signal as well as the "feed output bus to input bus" signal. My 6507 documentation doesn't show which buses have "true" or "inverted" logic levels, but a natural implementation would likely use the opposite signal polarity for the output bus and input bus (so the connections between them would be inverting buffers). Under that scenario, LAX would represent a race condition to see which bus got a "low" signal first. A variety of factors could influence "who wins" such a race. It's interesting to note that both the TIA and 6507 share some design techniques, both would appear to be designs which sufficiently well-synchronized to be free of odd timing dependencies, but both have at least one seemingly-impossible race condition (the TIA's race condition occurs at mid-screen when using score mode if PF2.7 is set; there may be a half-pixel-wide odd-color stripe in that case).

I thought asr was stable at least when the D flag is clear; with the D flag set, its behavior is weird whether or not it's stable.

An efficient multi-byte comparison requires use of the carry flag for multi-precision arithmetic; a three-byte comparison can be done with six instructions totaling 12 bytes to get the result into the carry flag. If multi-precision arithmetic is not available, the logic should be: if score_top > highscore_top then YEP if score_top < highscore_top then NOPE if score_mid > highscore_mid then YEP if score_mid < highscore_mid then NOPE if score_bot > highscore_bot then YEP if score_bot < highscore_bot then NOPE Otherwise, optimal 6502 code would be: lda highscore_bot cmp score_bot lda highscore_mid sbc score_mid lda highscore_top sbc score_top ; Carry will be clear if score > highscore The CMP will clear the carry if score_bot > highscore_bot and set it otherwise. Each SBC will clear the carry if the corresponding byte of score is greater than the corresponding byte of highscore, set it if the corresponding byte of score is less than the corresponding byte of highscore, and leave it alone if they're equal. Thus, the state of the flag after earlier comparisons is relevant only if later bytes are equal.

One probably could program a GUI on the Harmony cartridge, and use it to launch games stored on the SD card.

It seems odd, though, that they used a fancy chrome switch for color/bw while putting the more-useful difficulty switches on the back. I'd have thought that it would make more sense to change the design of the power switch, and then have four chrome switches for diff1/diff2/select/reset.

I hadn't seen that video before. As the guy who coded the music, I wish the video had included more of it. The "Stay Frosty" theme is still one of my favorite musical compositions (the Toyshop Trouble theme is another). The menus (which I also programmed), btw, make use of a banking trick I invented to allow the code easy access to about 7K of data without having to waste time on banking instructions.

To be sure, using CFB means that someone can create an image with any desired first block. So what? Design the boot loader so that the first block won't be stored anyplace and then the first block could be filled with 128 bits of random garbage.

Would there be any difficulty with using some of the ARM's RAM to hold code to set up the RIOT RAM the way programs are going to expect it?

A lot of games hit the sound registers more than once per frame. I'd suggest storing the cycle count where each TIA sound write occurred. A good format might store each write as one byte indicating the register to write and the value thereof (5 bits), and 1-2 bytes for the number of cycles preceding it. Since there are slightly less than 128 meaningful register writes, one bit of the data could be used to select a one or two byte time value.

The so-called "B" flag isn't really a flag. When the 6502 stores the flag register in memory (either because of a BRK, an interrupt, or a PHP instruction) it stores the implemented flag bits along with a the state of a control line which indicates whether an interrupt is being taken. From what I've read, this usually but not always indicates whether the interrupt is being dispatched as a result of the IRQ line; a not-totally-safe assumption is that if the IRQ line isn't causing an interrupt, a BRK instruction is. If a BRK instruction occurs just as an IRQ arrives, the BRK flag will not be set (oops).

Star Ship uses flicker for the stars, so that would represent the first game to use flicker. Football and Home Run used flicker for the players at certain times. Missile Command used flicker for the missiles, shots, and explosions. Worm War I used flicker for the player's ship and the worms. Quite a few games, actually, used full-time flicker to show four players.

What's happening is a race condition between disabling the player 0 color and enabling the player 1 color. Normally, race conditions are avoided by having a color latch which holds the previous pixel's color while the present pixel's color is determined. The signal which determines whether to use the left- or right-side color, however, changes state on the opposite clock edge from everything else, when the output latch is transparent.

To be hyper-precise, Score Mode causes the player 0/1 color circuits to be activated anyplace the playfield is active. When sprites have priority over playfield, this "covers up" the playfield color there. If playfield priority is enabled, the activated 0/1 colors get overruled by the playfield color, rendering score mode ineffective. Note that in score mode, the left half of the playfield has priority over the player/missile 1 sprites.

Reading keypad controllers. The bidirectional ability was used and acknowledged 'back in the day'; I don't know if the keypads were part of the original 2600 design concept, but Atari certainly produced them soon after the 2600 was released.

My wife and I have enjoyed Heron's Steam Machine for the WII, and I was thinking with some tweaks it might be fun on the 2600. The goal of the game is to rotate pipe segments to connect from one side of the screen to the other. One of the cool aspects of the game is the two-player cooperative mode, where both players control half the board, but I think the wii's board is a little too small in the two-player mode. The real game will feature pipes that connect on the top and bottom edges (unlike the Nintendo's left/right). Partially-connected pipes will be highlighted with a moving pattern similar to what's shown here. The real game is going to have to be coded for the ARM/Melody chip, since the kernel shown here would otherwise be unsuitable for anything other than precalculated images. Still, I think this looks promising. Fire button selects an alternate color scheme; no other controls do anything. piper.bin