supercat

Ultimate is last. Penultimate is second-to-last. Antepenultimate is third-to-last. So what's fourth-to-last?

Non-integer doesn't imply that there wouldn't be a small integer ratio. Imagine a machine with a 512x400 resolution (interlaced) with four colors. Dot clock is chroma*10/3, so the data rate would be chroma*5/6 (one byte ever 4 pixels). If the memory rate were chroma precisely, there would be 525 clocks every two scan lines, and on each scan line pair during the visible frame, a particular 256 of those clocks would get used by display memory fetches. No less predictable than things are now; the difference would be that the stolen clocks would not all be consecutive. From a hardware standpoint, it would be necessary to add one or two levels of synchronization registers, but that's just an extra 8 or 16 latches. No biggie.

What's your objection with Galaxian? The yellow border? Galaxian has to use the Ball for the player's shots. Missile 1 used for enemy shots, and Missile 0 can't be used because of NUSIZ0. The Ball is the only thing left. The multi-RESP0 trick used for the aliens doesn't work well near the left edge of the screen. It is thus necessary to mark off part of the screen so that aliens have something to fly into (rather than just vanishing from mid-space). If the Ball and playfield could have been colored independently, that would have been great, but they can't. One must thus either -1- Use a bright shot and put up with a bright border, or -2- Use a dim border and put up with a dim shot, or -3- Skip the border, but have enemies disappear from the edge of their motion range (which does not reach the edge of the screen). Atari chose the first option. Some people might prefer the third, but I think it's better to simply tolerate the bright border.

To test paddles, I'd suggest wiring each pot input to its corresponding button input, and the measuring the resistance between "power" and "ground". Use a resistance-controlled oscillator and you can make a device which will use zero current when a button isn't pushed, and will also let you hear if there's any jitter in the paddles.

What CPU was the BBC machine using? The Z80, IIRC allows almost two full T-states between outputting address and sampling data; the 6502 allows slightly less than one cycle. Still, if the Atari could have run its memory system at 3.579MHz while keeping the CPU at 1.79MHz, that could have made more bus cycles available for the display hardware, allowing higher-resolution modes like 160x200x16 or 320x200x4 with no CPU slowdown, or 160x200x256 or 320x200x16 with significant CPU slowdown. Alternatively, it could have allowed a 7800-style oodles-of-sprites system. BTW, I wonder if there were any systems which shared RAM between the CPU and display, and didn't have an integer number of CPU cycles for each display column. If one is trying to use RAM at its maximum speed all the time (as opposed to interleaving, which leaves cycles idle outside the vertical display interval), I would think that it might make sense to use a non-integer number of cycles so that the CPU would never have to be stalled for very long. For example, if each display column took four chroma clocks and on the badlines required two bytes, and if the memory clock rate was 9/16 the chroma rate (2.24MHz), then even on the badlines the CPU could use cycle every 16 chroma cycles (223Khz). A standard 6502 can't have its clock rate fall below 100KHz, and it takes a few cycles to suspend operation while its clock is running, but if the display controller could run the CPU in slow motion without violating the minimum speed, the extra DMA startup cycles could be eliminated.

IIRC, the expansion board contains all the signals that would be necessary to generate a composite signal for 7800-mode games (I'm not sure about audio), but it does not contain any of the video signals from the TIA.

Check the blog entry "What the dickens".

I would suggest using TIM64 and experimenting with values. To make it easy to detect upcoming or entry, I would suggest that instead of having INTIM count down to zero, you have it count to a value like 125 (tripping at 124). Thus, the code would be something like: lda #125+40 ; Experiment with this value sta TIM64T ... lda #125 ; Next three lines are optional sta WSYNC cmp INTIM bcc INTIM_Wait ; Set 'oops' flag if desired INTIM_Wait: sta WSYNC cmp INTIM bcc INTIM_Wait Rather than calculating the TIM64T values to use, it's often easier in the age of emulation to simply experiment. Make a guess and then adjust up or down as needed. To see if INTIM is 127 or less, you may use the instruction BIT INTIM without disturbing other registers. If the N flag is clear, that means that you have 256 or fewer cycles remaining before you should be at your VBLANK routine (180 or fewer with optional code included). Using such an approach makes it practical to have loops that run at variable speeds and which will take multiple frames to complete (Strat-O-Gems uses that technique heavily, btw).

I wonder how hard it would be to make an "artifacter" mod for PAL machines? Generate a square wave at half the pixel rate, along with a couple of out-of-phase sine waves at the PAL chroma rate, and feed the latter waves into a multiplexer controlled by the former. Use the output of that to modulate the luminance output and I think one would end up with a bad-looking but functional artifact-color display.

I would think Venetian Blinds would be the right approach. Limit the size of the QIX bouncy thing to 64 pixels so it could be drawn using a 4x4 cluster of sprites on half the frames; on the other half of the frames, the player and sparks would be drawn (once the sparks split, their flicker speed would drop to 15fps, but they're sparks so they should flicker).

The VIC-20 had lots of unused address space; putting the Super Expander's ROM into that address space did not cause any difficulty. Note that even with a Super Expander installed, the BASIC ROM from from $C000-$DFFF is entirely unaffected. Despite that, there are many programs that require that the Super Expander be unplugged or disabled in order to work. Simons' Basic (which I own, somewhere) isn't really compatible with anything; there are many programs that won't run with it plugged in. As for the Plus/4, C128, etc. none of those are compatible with the C64, with the exception of the C128 in compatibility mode. BTW, the niftiest "development system" I ever saw back in the day was the Fast Assembler published in Compute's Gazette. That thing was slick. PS--Back in the day I wished I could have somehow sneaked into Commodore and removed the logic that prevented the creation of a useful "enhanced" C64-compatible mode. Imagine some of the software development possibilities if one could, e.g., use 64K of the 128K as a RAM disk. That would have been amazing. Too bad it's not possible.

There was a lot of software that relied upon the precise inner workings of the BASIC ROM. Had Commodore moved anything around, much of that software would have been broken. Indeed, if one looks at various revisions of the KERNEL ROM, one will notice that changes are carefully patched in so as to avoid disturbing anything. E.g. if it was necessary to change something like patch: lda #1 ldy #0 so that it would load the accumulator from somewhere in memory (not zero page) rather than using the constant 1, it would be patched as something like patch: jmp wasBlank brk ; Blank byte endPatch: ... wasBlank: ; Some spot that had been blank lda magicLocation ldy #0 jmp endPatch Not a perfect patch, since a program that attempted to enter the kernel at address patch+2 would fail, but it would nonetheless avoid the massive problems that would result from simply replacing the "lda #1" with "lda magicLocation".

I'm not sure it's really meaningful to compare entries against all different systems. If a 4K game on the C64 behaves identically to one on the 2600, should the latter get more credit for doing more with less? How much? Given that many people have different biases toward different systems, I think it might be better to have separate contests for different platforms. Also, I don't think the contest will be worth much of anything if there isn't a forum that actually works.

Well, 5.5 bits if one doesn't mind generating some extra noise at the sample rate (and harmonics thereof) and the sample rate is high enough that aliasing isn't a problem. Set one of the waves to be full-time "on" and the other to 50% duty cycle. Voila--46 output levels instead of 31.

Hint: In the original release of the game, the message included the word "GREETINGS". The clue doesn't make sense without that; in the re-release, I forgot about the importance of that word when I changed the message (everything else about the game plays identically in all releases so for HSC versions they are interchangeable).

No, in that situation it should simply figure the cycles are used. Likewise on cycles 3 and 4 of a branch instruction. Trying to exploit those particular cycles would require way too much effort to be worthwhile.

It would involve basically to have a 2nd emulated 6502 outside to find out which cycles are "free" because 6502 doesn't tell you that. And then there hardly are any cycles at all to be gained. Most cycles are neccessary bus cycles too. The 6502 includes a signal that indicates the first bus cycle of any instruction. The state machine necessary to identify most of the read/ignore cycles would not be particularly difficult, but trying to take advantage of cycles that are available here and there would add complications of its own; further, I really don't think there are enough such cycles to be worth worrying about.

Existed for C64. So did Anteater, IIRC.

From what I understand, the kill screen isn't a result of the level counter itself overflowing into other areas of RAM. Instead, it's a result of two factors: -1- The 'show fruit' routine works by showing a fruit, decrementing a counter, and seeing if the result is zero. If not, it loops and keeps drawing fruits until the result is zero. Thus, an attempt to draw zero fruits will draw 256. -2- Since the game would malfunction if it tried to draw dozens of fruits, the game limits the number of fruits drawn if it's greater than seven. The kill screen occurs because the game decides it's save to draw zero fruits (since zero is less than seven), but it actually ends up drawing 256. BTW, on Ms. Pac Man, I once saw a copyright notice appear near the bottom the screen, obliterating some of the dots. The player and ghosts were able to pass over the copyright notice without impediment, but there were no dots there. After the player died, the copyright notice disappeared but the board was still short of dots and so the game was unwinnable. I think the player was on the second level--it certainly wasn't a level-256 killscreen, but it was an anomaly I'd never seen before or since. Has anyone else ever seen such a thing?

The Toyshop Trouble music is interesting from a coding perspective. It's divided up into groups of four eight-quarter-note-long phrases; each phrase has two bass notes (an octave apart) and four melody notes, and the pattern of bass and melody notes repeats every four phrases. The bass and melody notes for the whole tune, both major- and minor-key versions, fit in 20 bytes. BTW, the major version of the song is in "melodic major" sort of--the memody voice has a rather sharp B natural and an even more flat B natural. When I use the B natural as a leading tone (phrase 4), I use the sharp one; when it's not a leading tone (phrase 3) I use the flat one. I don't particularly like the horrible intonation in the major-key version, but it's the best the 2600 can do without some serious magic. In the minor-key variation, I like the intonation a bit better. I think the B-kinda-flat note works very nicely in phrase 3 of the minor-key version. Better than a proper B-flat or B-natural would. I tried to do a mini-game version. If I'd started out targeting 4K, I might have managed something decent, but squishing everything into 4K would be hard. On the other hand, if Atari could have had that game in Christmas 1979 I don't think they would have balked at the extra cost of 8K cartridges. I seriously considered doing that, but I was afraid that people would too likely end up confused since many people don't know the state of their difficulty switches at any given time (some may not even know where they are!) Somehow the idea of pushing the fire button to not paint toys doesn't seem very intuitive. Besides, when people complain about sore thumbs, that's how I know I have a good game.

I wish Microsoft would either do a decent job of providing a virtual old-style PC, or else provide the OS hooks for someone else to do it. Even if it would be necessary to do cycle-by-cycle emulation, modern machines could still run programs that were written for something like a 386 at least as fast as the original machines would run.

E.T. was overhyped, but a lot of people who had the game back in the day liked it. Not quite enough time play-testing (IMHO, changing the collision-detect logic for the pits and adjusting a player's position off a pit when traveling to the lots-of-pits screen would have helped enormously) but I don't think people felt ripped off. Pac Man, on the other hand, was an obvious piece of shovel-ware. Games with no flicker or intelligent flicker were already pretty common; using full-time 15fps flicker for the ghosts was just plain lazy.

I'm glad you like it. I sometimes wonder what would have happened if I got in a time machine and showed up at Atari in, say, 1979 and asked them to release the game. To start with, just show them some screen shots, etc. Don't mention what system it's for (they'd probably guess 400/800). Then ask if they thought a 2600 version would sell, or if there would have to be too many compromises to make it a workable game.

Best of luck to you. I just hacked things so I could test out levels after the second duck wave. The first level after the second duck wave is hard (too hard for me--don't know if it's possible), but the next one is easy enough that I could clear it with time to spare. Then hard, then easy. Then more hard levels. I really don't think anyone's going to clear Jan 25. But from Jan. 26 until the 'wrap' are all pretty easy.

I think you've got me beat. I wonder if anyone will clear the second duck wave? I know I've never gotten that far. What's your secret?