alex_79

I added an auto-detect to the 128 Chronocolour demo. If it works right you won't have any gaps or overlaps. It works! Alignment is now correct on both my 6 and 4 switches consoles. Anyway I cannot get the tv to sync correctly. At start the screen just rolls and by increasing the scanline count with the joystick the best I can get is a stable "split-screen" arrangement like in the pictures posted by iesposta above. Also, I only get the chronocolour car image (with NTSC colours), the firebutton doesn't cycle through different screens like previous demos. Is this the expected behaviour? The latest RPG demos work fine! Very nice! Previous version showed a screen-roll in SECAM mode.

Very nice indeed! The cart slot on the board is actually functioning, but you have to remove the rom chip in position "7" in order to use it. After that you can access the cart by selecting game 7 in the menu. It was meant for testing and troubleshooting (by plugging a diagnostic cartridge in it).

A reset button on the cart is not possible because the 2600 cart port lacks the signals to make that work. (see this post) I also believe that installing a button on the console to trigger the RESET line of the 6502 won't work, because it would reset the console, but not the Harmony Cart (I guess that would restart the current game, but it wouldn't go back to the menu). So the only way is to power cycle the console. You could install a momentary, normally closed push-button on the +5v output of the voltage regulator if you want to save wear on the toggle power switch, or use a bit more complex circuit to have a fixed duration pulse activate a relay that powers the console off and then back on when you press the button. In either case, you have to mod the console, not the Harmony cart itself.

If they have the same part number (27c64) then yes, they are the same thing internally. The only difference is that the OTP rom has a plastic package without window that prevents it to be erased using UV light. The plastic package is cheaper than the ceramic with quartz window used on standard eproms and it was used for small production run where a mask rom was too expensive (Mask roms have an high upfront cost and a low per-unit cost and are only economically viable for high production runs). Mask roms might or not be pin compatible with eproms, it depends on the specific model. For example a CXK3864 mask rom is compatible with 2764 and 27c64. Yes, or the board would have additional chips to implement the bankswitching which wouldn't make sense if the game only required 4k. One of the address lines is tied to either ground or +5v on the board making half of th eprom inaccessible.

Also there's no "ground" pin on a switch: there's a NO (normally open), a NC (normally close) and a COMMON pin. If one of these is ground depends on the circuit the swicth is connected to and, in the case of the 7800 joystick buttons, none of the pins is connected to ground. As CMR wrote, you need the NO and COMMON pins, and it makes no difference in what order you connect them. (it does only matter in applications that use all three pins of the switch, which is not the case here)

I love the magicard and I consider it the best "programming" add-on for the 2600, but I never managed to make the cassette interface working with any of my cassette players or the computer soundcard. I think audio levels on old shoebox tape recorders were stronger than those outputted by modern devices and I'm not able to design a new interface. I hope someone with the necessary skills will someday post a schematic for a more reliable circuit. The Spectravideo "Compumate" also has a built-in cassette interface and it uses basic.

If you mean the "basic programming" cartridge, then no, you can't save the program.

LS and HCT should both work fine, but with HCT you also need to connect all the unused inputs (pins 5,6,8,9,11,12 in the schematic above) which complicates a bit the wiring in this case. Depending on the specific application, HC might be unreliable when drived by TTL logic because uses different swithcing voltage levels, so I'd avoid that. I don't know. I'm more a 2600 enthusiast and not very familiar with the 7800... Don't know what happened. The lower 16k of the eprom are never accessed by the console, so it doesn't matter what's in there. If the eprom programmer software allows to start burning from a specific address, you should be able to just burn the 48k binary, else if it only accepts binary of the same size of the eprom you have to pad the first 16k with some data. No problem, I'm glad you got it to work!

You'll find a schematic for your board here: http://www.atarihq.com/danb/7800cart/C026445.shtml The "Chip Enable" pins on both roms should be labeled "/CE" in that schematic, as they must be active LOW. Basically U1 (16k rom) is selected when A14 is HIGH and A15 is LOW, that is for addresses $4000 to $7FFF, while U2 (32k rom) is selected when A15 is HIGH ($8000-$FFFF). I would have used a single 64K eprom in U2 (you only need to isolate pins 1 and 22 by cutting traces on the board) and a NOR gate (7402) for address decoding: You need the eprom active (pin 22 LOW) when A14, A15 or both are HIGH, not active (pin 22 HIGH) when both A14 and A15 are LOW. So you just connect A14 and A15 to the inputs of the NOR gate and the output to pin 22 of the eprom. You also need to connect A15 to pin 1 of the eprom in U2. A14 and A15 can be found on pins 22 and 20 of U1. The 48K rom must be burned on top of the 64K eprom space (from $4000 to $FFFF), the lower 16k ($0000 to $3FFF) are not used. If using a 74HC02 or 74HCT02, you cannot leave the inputs of the 3 unused gates floating, but you need to connect them to something (+5V, GND, or any of the data or address lines, so that they're always in a defined state) P.S. I like tinkering with this stuff, but I'm no way an expert, so use this info at your own risk!

Yup. Interesting that it supports bankswitching for 8k games.

I did similar tests on my TV a while ago and it can handle between 360 and 244 scanlines without rolling (that is between about 43Hz and 64Hz). It uses PAL aspect ratio (scanlines closer together) from 288 lines and up and NTSC one from 287 and below. The strange thing is that I can actually get a stable picture with lower scanline counts: With 122-180 scanlines (which is half of the supported values), I get a stable picture with 2 frames displayed in a "split-screen" arrangement. The TV seems to just ignore the VSYNC signal which happens too early after the first frame outputted by the console, while it detects the second one and since the sum of the scanline counts for the two frames is in the supported range, it displays a stable picture. With 82-120 scanlines I get a 'stack' of 3 frames and so on...

Flcker is quite heavy. The TV I'm using is multistandard CRT that also support 60Hz (when it receives a 60Hz signals it also adjust the aspect ratio by stretching the image in the vertical direction), so I guess the phosphors are no different than those used in NTSC sets. When looking at the road and driveway in the picture, which should come up almost white, I can clearly see the RGB triplet stripes moving up. I have to back away from the screen to make the colors more recognizable. I guess it would look better on smaller TV. Mine is 32" 16/9, which corresponds to about 26" when in 4/3 mode (pillarbox). Yes, it displays correctly with right diff in 'A' position on my sixer!

Thanks for the update! Unfortunately, with my L6 the glitch is present in the chronocolour screen as well. I will try it on the other consoles and report back.

Can you read the markings on the eprom chip? The 4.2 DOM eprom shown on atariprotos is a 2716 (16 kbits - 2 kbytes). Some of the game you mentioned are 4k, some 2k. What type of eprom are they? (2k games work on 4k eprom if they're copied twice on it). Do your eprom cart accept both 4k and 2k eproms? In that case there should be a switch or a jumper to select betwen the two. Also note that the 2.6 version requires two test plugs in the controller ports to work correctly, but it still display an image without them. Maybe the 4.2 doesn't display anything without the test plugs. Instructions for the 2.6 version can be found in the 2600 service manual which is available in several places on-line, but I found nothing about the 4.2. If you have access to an eprom programmer or can send the eproms to someone who has one, a dump of the rom might shed some light.

Also, note that many 7800 games does not use the controller in 2-button mode. And in that case both buttons will be read as the standard 2600 single fire button. Check this post: http://atariage.com/forums/topic/256081-2-button-and-2-player-games/?do=findComment&comment=3574877

It wasn't. The video shows how it looks when played on a Gameboy color with the default palette (different palettes can be selected when playing classic GB games on a GB color).

All CX80 trackballs natively use the same encoding as CX22 unless they've been modified (by cutting a few traces and soldering some jumpers on the circuit board). And there's no way to tell if a unit has been modified without testing it or looking at the board. Instructions to mod atari trackballs (both the CX22 and the CX80) to be compatible with Atari ST or Amiga computers could be found in magazines, newsletters and mailing lists in the late '80s - early '90s. Some units might as well been modified in bulk by some atari distributors as many games and programs compatible with ST mouse were available also on the 8-bit computer line (actually they were more than those that supported the original atari Trackball protocol). When the trackballs were first documented in the stella-mailing-list in the late '90s, they happened to use one of the modified cx80. The mod in that unit was professionally done, and the joystick/trackball switch was still functional and this led to believe that all CX80 used the ST mouse protocol. It later turned out that the majority of CX80 trackballs are not modified, and therefore compatible with the CX22 and not with the ST mouse.

The 2600 is unable to distinguish between the two buttons of a 7800 controller. Because of the controller's design, they both appear as the standard 2600 firebutton. The 7800 console has extra circuitry to enable a "two button mode".

Check dasm documentation: dasm.txt Pseudo-ops are commands for the assembler (dasm is the one almost universally used by 2600 homebrewers). Different assemblers can have different pseudo-ops.

Do you have an updated CSV convert utility that calculates the relation-rating?

On text-label sears carts, the title is on the end-label. The front label may list the game variations, or the number of skill levels, or the goal of the game (and in some cases that correspond to the game title). pictures are from atarimania.com

That's the pinout of the female connector (that is, the joystick plug). The male connector (controller port on the console) pin numbering is specular (pin 1 is on the left)

Free shipping! What a bargain!

Almost the entire first 4k bank of the 05-24-1984 proto is filled with the byte sequence "ff ff 01 01". I guess that confuses CloneSpy. This is part of the hexdump of the rom. Asterisks indicate areas where the byte sequence repeats: 00000000 ad f9 ff ea ea ea ea ea ea ea 4c 3c f0 ea ea ea |..........L<....| 00000010 ea d8 a2 00 8a 95 00 9a e8 d0 fa a9 06 85 89 a9 |................| 00000020 00 85 d2 a9 11 85 d3 a9 31 85 0a a9 b0 8d 96 02 |........1.......| 00000030 e6 81 d0 02 e6 82 20 5e f0 4c 00 f0 ad 84 02 30 |...... ^.L.....0| 00000040 fb 85 02 a9 02 85 02 85 01 85 02 85 02 85 02 85 |................| 00000050 00 85 02 85 02 a9 00 85 02 85 00 4c 2b f0 a2 01 |...........L+...| 00000060 b5 d0 30 22 d0 1a b4 d2 b9 a2 f0 10 06 a9 ff 95 |..0"............| 00000070 d0 30 13 95 17 a9 0c 95 d0 bd a0 f0 95 15 f6 d2 |.0..............| 00000080 d6 d0 b5 d0 95 19 ca 10 d7 a5 d0 10 12 a5 d1 10 |................| 00000090 0e a9 22 85 d2 a9 43 85 d3 a9 00 85 d0 85 d1 60 |.."...C........`| 000000a0 04 0c 1a 11 1a 11 14 11 14 11 11 13 14 17 1a 1a |................| 000000b0 1a 1a ff 11 0d 11 0d 11 0d 11 0d 12 0f 17 17 11 |................| 000000c0 17 11 11 ff 00 1b 1b 17 11 0f 11 17 00 1b 1b 17 |................| 000000d0 11 11 11 11 00 1a 1a 14 0f 0d 0f 14 00 1a 1a 14 |................| 000000e0 0f 0f 0f 0f ff 17 0f 18 0f 1b 0f 18 0f 17 0f 18 |................| 000000f0 0f 1b 0f 1f 0f 14 0d 15 0d 17 0d 15 0d 14 0d 15 |................| 00000100 0d 17 0d 18 0d ff 01 01 ff ff 01 01 ff ff 01 01 |................| 00000110 ff ff 01 01 ff ff 01 01 ff ff 01 01 ff ff 01 01 |................| * 00000da0 ff ff 01 01 ff ff 4c 01 ff ff 01 01 ff ff 01 01 |......L.........| 00000db0 ff ff 01 01 ff ff 01 01 ff ff 01 01 ff ff 01 01 |................| * 00000ff0 ff ff 01 01 ff ff 01 01 ff ff 01 01 0d f0 0d f0 |................| 00001000 ea ea ea 4c 10 f0 ea ad f8 ff 4c 00 e0 ad f8 ff |...L......L.....| 00001010 a9 ff 85 b1 85 b3 a9 14 85 b0 a9 4a 85 b2 a9 34 |...........J...4| 00001020 85 b5 a9 03 85 b6 a9 39 85 b7 a9 fe 85 a1 a9 ff |.......9........| 00001030 85 a3 a9 14 85 a6 a9 09 85 a7 a9 13 85 a4 85 b9 |................| [...]

Same here. It was obvious that games written in Basic would have part of the code in common, even if the authors programmed them from scratch, but it's interesting to see to what extent. Moreover, as Thomas pointed out, an analysis of the program's output can still provide some indicators about the amount of original work put into the game. (including example programs from the bB tutorials in the group of roms to test would probably help in that respect).