supercat

Yes; my 32-character routine works as two groups of sixteen (or, more specifically, two groups of 64 pixels wide, with a 16-pixel gap, at 50% flicker. BTW, I also have a routine to do flickerless three groups of three sprites, and a specialized routine to show "ATARIAGE" at 50% Venetian blinds with 15-pixel-wide characters.

I would think the most logical way to implement copy protection would be to have game disks kept in a caddy with some electronics. The caddy could protect the disks from damage, and the electronics could include logic which would be required for a game to function. In some cases, the electronics could even include some of the game logic. For example, the game might feed part of the game state through the chip and ask it whether any new monsters should spawn. The only way one could bypass the chip and play the same game would be if one knew the exact monster-spawning rules.

There's no requirement that any particular information about any portion of the display above or below the current raster position be stored anyplace. The TIA has to have stored in it information about what should be displayed at the current raster position, but that's it. Anything else may be generated on the fly in any convenient manner. That's part of what makes the 2600 so neat.

How about Stella's Stocking? 8-) Four-voice music from the TIA; each voice could independently play any note from a five-octave range in "loud" or "soft" mode, and the code took 46 cycles per scan line. On the 7800, the cycles stolen by MARIA would make it necessary to WSYNC each line, increasing the cycle count to 49, but since there are 114 cycles per line instead of 76, and since the 6502 wouldn't have to worry about generating the video frame, it should be possible to do some pretty cool stuff with just TIA. Playing an audio sample that was compressed via some simple means (e.g. 2-bit ADPCM) should be pretty straightforward if the processor didn't have to do anything else--a scenario that should work fine for the speech in Impossible Mission.

MTBF is a measure of reliability, not lifetime. An MTBF of 65,000 days means that if one were to run 65,000 drives continuously, you'd get about one failure per day.

Until 2006, every bank-switched 2600 cartridge either used a custom ROM chip, a custom or semi-custom/programmable bank-switching chip, or else two or more chips in addition to the ROM (Tigervision 3F might have only used two; I think most required three). Toyshop Trouble is an 8K game for the 2600 that uses a PROM plus one standard 74xx chip to control both banking and chip-select.

One of my first ideas for a 2600 cart, circa 1994, was a snake game called "Wormy". I started working out the memory layout and a title screen even before I started what would eventually become Strat-O-Gems. I can't find anything that's close to being a legible title screen; I vaguely remember having an almost-working title screen, but my archives don't seem to have one. If I studied the code I might find that something was just a few cycles off, and I neglected to save my best version before I changed something that made it worse. I might have some title screen graphics on a 2" disk, but I have no idea where I could find equipment that could read it. One of the design challenges with Wormy was figuring out how to have lots of goodies to pick up as well as obstacles and the snake, all in a ROM-only cart. I revisited the code around 2007 and wrote an amazingly memory-efficient kernel. Perhaps I should revisit it. Your game is a little simpler than what I'd been trying to do; on the other hand, yours is actually playable. I think the game could probably benefit from a bigger playfield and the addition of more goodies and/or obstacles. RAM would quickly become tight if you want to use a ROM-only cart, but since carts with added RAM are no problem, it might be good to see what you could do with an extra 128 bytes.

It most likely contains some sort of switching power supply, as that would be the most natural way of boosting +5 from the USB to the +12 or +21 required by some EPROMs. Most newer switchers operate at sufficiently high frequencies that they wouldn't be even remotely audible, but older ones can often produce whining noises.

Sounds like a simple boost-mode switcher charging a relatively large capacitance. Except for things like electronic flash units, which demand that a lot of energy be supplied quickly, but which can tolerate some time between dumps, most switching supplies are apt to be able to charge their output caps very quickly. Not necessarily a problem, though if a unit does it and no others of the same design do so, it may indicate something wrong with the coil in the switcher.

Cartridge_MD5, Cartridge_Manufacturer, AtariAge Cartridge_ModelNo, Cartridge_Name, Toyshop Trouble Cartridge_Note, F8 Emulator Release Cartridge_Rarity, Cartridge_Sound, Cartridge_Type, Console_LeftDifficulty, Console_RightDifficulty, Console_TelevisionType, Console_SwapPorts, Controller_Left, Joystick Controller_Right, Paddle Controller_SwapPaddles, Display_Format, Display_YStart, Display_Height, Display_Phosphor, Off Display_PPBlend

BTW, I'm surprised nobody BITD ever made a 48-key keypad for the 2600. Electrically, it would have required nothing more than two keypad controllers, but it would have allowed Basic Programming, as well as letter and number learning games, to be a lot more practical.

If your scope is analoguey, Set the scope to trigger off 60Hz line frequency, throw an Asteroids cart in both machines, and look at each pin in sequence. From experience working on my 4A50 cart, many of the pins have very distinctive patterns on an analogue scope while running Asteroids.

How about building an adapter to connect a Harmony cart up to a monitor and a couple joysticks? Such an adapter would probably require a little soldering, but not much. It'd be limited to component video rather than composite, but I think all one would need would be a bunch of resistors and connectors.

Magic writes won't work with D6, since that has a pull-up, but couldn't you try magic writes for the remaining seven bits? Put $40 on the data bus and $0000 on the address bus, then float the data bus and put $1000 on the address bus for 700ns and back to $0000. Then read $1080, $1100, and $1400 (looking for 128b, 256b, or 1K of RAM). Then repeat the procedure starting with $FF on the data bus. I think you should clearly see whether there's RAM there or not.

Accessing $1000-$107F will store to RAM whatever happens to be sitting on the bus. Some EEPROM readers pull the data pins down weakly; Harmony has a weak pullup on D6. If one were to read $1080-$10FF before accessing $1000-$107F, one would probably get random data. In any case, the RAM values aren't important.

How about adding an SD-card slot for a teensy-weensy cart-based gaming system?

BTW, another couple useful features would be: (1) Note the approximate time when the data changes, to identify cycles where timing is dubious; (2) use 'rolling buffer' mode until a trigger event occurs (maybe 78 cycles with no address change). A CPU jam could then be used as a crude trigger if something is found to have gone wrong.

I wonder if one could use a Harmony cart sitting in parallel with another cart on a 2600's bus as a means of capturing bus transactions for debugging. It wouldn't have a huge trace capacity, but if it could be set to start logging some amount of time after some particular memory access it could be very handy.

I have a disk called Circus Games which I'd like except for one thing: so far as I can tell, there's no way to avoid exiting to the menu at the end of every game, and both the menu reload and game reload take seemingly forever. I'd like playing the games if I could actually spend some time playing them, but it seems I spend as much time loading as playing.

I would guess that the cable is probably just outputting the luminance signal from the Atari. I had a Commodore rather than an Atari, but the Commodore at least had both composite and luma-only outputs (I think the 128 had a chroma-only output as well). Connecting the composite output up to a monochrome monitor would not give nearly as good a picture as using the luminance output (on early C64's the composite output, viewed on a monochrome screen, was downright crummy). Most cables that just had one video output plug would output the composite signal, but I've seen some which would just output luminance.

The X08 banking scheme (Stella's Stocking) can switch between the last two banks with zero overhead. Code in bank 14 which executes any access of $0040-$007F will switch to bank 15, and code in bank 15 which accesses $0000-$003F will switch to bank 14. Since the TIA will respond identically to both address ranges, every TIA access is an opportunity for a "free" bank switch. If I recall, the Stella's Stocking menu uses most of bank 14 to hold the graphics and most of bank 15 to hold the audio wave tables (I might have those backward). During the main displayed portion of the frame, data from both banks is accessed on literally every scan line so I couldn't afford any overhead for bank switching. I'm not working on a new scheme that will allow zero-overhead access of 16K of code and 16K of data.

The Colecovision's VDP included DRAM control circuitry for its own DRAM. To use DRAM for the main memory would have required entirely separate DRAM control circuitry. The "refresh counter" on the Z80 saves a little bit of DRAM-control logic, but using a DRAM will still require a fair amount of extra circuitry. Hooking an SRAM up to a processor circuit often requires only one or two gates; using DRAM will require an address multiplexer along with some sequencing circuitry. Certainly not impossible, but not particularly easy.

DRAM requires more complicated circuitry to address. The VIC-20 used ten 1Kx4 SRAM chips for main memory, plus one for color data. The VIC-20 output chip-select signals for three 1K blocks from $0400 to $0FFF, and for 8K blocks at and above $2000. This would allow convenient use of six 1Kx4 SRAMs for a 3K expander, or one 8Kx8 SRAM for each 8K in larger expanders.

I wonder how the chip-enable speed of SRAMs compared with the random-access speed? I wonder if it would have been practical to wire a machine such that the LSB of the address selected between two or four RAM chips, and arrange to access both of them one after the other in the same cycle? That would seem to ease the timing requirements.

For some bank-switching schemes (e.g. Parker Brothers, 4A50, the upcoming JX10, etc., I would think one would want to show both the 6507 address and the mapped address (since each physical address in a Parker Brothers cart can be mapped into three or four different places). As for the question of showing labels, I think it might be helpful to show small and/or dimly-colored addresses for every instruction, and labels for those which seem to be branch targets.