alex_79

The VC-4000 uses a 1x31 pins connector, 2.54mm (0.1") pitch.

Interesting! The label style, which seems late '70s - early '80s to me, and the titles of the three games (and those of the carts in the linked racketboy.com forum, assuming they're for the same console - the plastic of the "donley kong" cart has a different texture and it's probably a 2600 version) make me propend for an undocumented Arcadia 2001 clone using a different connector and pinout. A rom dump could solve the mistery, but since the pinout is unknown, the only way to do it is to remove the label and open the cart. Then the board could be traced and an adapter built allowing to dump the game without desoldering the rom chip.

Thanks for sharing this! I'd like to know more about the dev system used at the time. The fact that they didn't need bankswitching suggests they were using a full 6502 cpu (probably coupled with a ram board where they could upload the code from the dev system). Source of some of the later games on the 2600 Connection website ("Desert Falcon" and "Dark Chambers") were clearly programmed using the "2600/7800 devkit", composed by a 7800 console + a ramcart connected to an Atari ST. You can see that in those cases the very first operation is to store a value in the 7800 control register to lock the console in 2600 mode. The devkit had 24kB of non-bankswitched ram accessible in 6 4k chunks and the resulting code should run as-is in a 7800 with Eckard Stolberg DevOS and a 48K linear ram cart.

I do!

Nice! I knew this puzzle game as "Tower of Hanoi" (I actually have a wood set) and I tried your 2600 version on Stella and also real hardware (using an harmony cartridge). A couple of suggestions: - PAL version displays 311 scanlines. Older PAL TVs will display in black and white with an odd number of lines, so you should correct this. Standard values for 2600 games should be 262 lines for NTSC and 312 for PAL. You can deviate a bit from those values, but you must ensure that PAL has an even number of lines for best compatibility. - You should increase the "move counter" only when you drop a disk/marble on a rod, while currently it also increases when you pick-up one and each time you move from one rod to another while holding a disk. - Maybe you might add some (faint, or it might be annoying) sound effect when you drop a disk. Also, you could include a link to the roms for emulators and real hardware on your page. The current link only points to the directory with the bootable images of the osx16 operating system and you have to browse the google drive to find the roms (possibly throwing off inexperienced users)

Maybe it's labeled 32k because the game rom is 32 kilobit (4 kilobyte) in size, altough the actual prototype is on a board designed for 8 kilobyte games and they just repeated the rom twice on the larger eprom to make it work. (The picture is too small to read the markings on the chips, but the eprom has 28 pins, so it's definitely at least 8 kilobyte and the extra chips might be for bankswitching logic).

Depending on the jumper settings you can use the board for 2k games with a single 2716 (16Kbit) eprom, or 4k games using either a single 2732 (which is your case) or 2 2716 (there are pads to install another socket in the upper part of the board). By looking at the board, these should be the jumper settings: _ _ |o|o o|o| 2k game | | | | 1x2716 eprom |o|o o|o| |_| |_| _ _ o|o|o|o| 4k game | | | | 2x2716 eproms o|o|o|o| |_| |_| _ _ |o|o|o|o 4k game | | | | 1x2732 eprom |o|o|o|o |_| |_|

I put 10k pullup resistors on scl and sda pins on mine.

If you have a "Stella gets a new brain!" CD have a look at the extras. There are scans of original hand-written notes made during VCS development. @mos6507: It would be nice if those (I mean just the scans, not the full CD) could be made publicy available as they give a detailed insight on the evolution of the VCS console design. Here is some relevant info about the budget: In a late May '76 note by Joe Decuir, the estimated costs for the chips that were taken into consideration for the new system were: (for 100K quantity) 6502 CPU: 8.20 $ 6505 CPU: 5.50 $ 6530 (I/O + timer + 64bytes RAM + 1k ROM): 8.00 $ 6532 (I/O + timer + 128bytes RAM) : 7.20 $ 1k ROM : 5.00 $ 2k ROM : 6.50 $ Depending on various proposed system specs, the total cost for the chips was estimated beetween 13,50 $ (for a very minimal system with 1k rom and 64bytes of ram, discarded as too limited) and 28.40 $ (for a 4k rom , 128 bytes ram system using a full 6502). The 6505 was the only 24pin variant of the 6502 available at the time that was suited for the application, as the other ones (6503, 6504 and 6506) all lacked the required "Ready" line (used by the TIA to halt the CPU). A memo in June 9, 1976 states that development had to be focused on two system configurations: the first with 2k rom /128 bytes RAM, using a 6505 + 6532 + Stella + 2k rom. The second with 4k rom / 128 bytes ram using an extra 2k rom and a full 6502 or a special 6505 bonding (with an extra address line instead of an interrupt line). According to Decuir's notes, this could have been obtained at no extra cost over a 6505. We know this ended up being the 6507.

Yes, "Stella" was the codename of the project and of the TIA chip. Curiously, in the "Jan Programming Guide" the TIA is referred to as "Stephanie"! ("Jan" is the single chip version of the 2600 hardware found on some "junior" consoles)

I can't help with your issue, but you might start by taking a look at the official field service manual. You can find revision 1 and 2 here: http://www.atarimania.com/documents-atari-400-800-xl-xe-technical-documents_3_8.html

If you have an "Air-Sea Battle" cart, start the game with RESET and flip the TV TYPE switch to "B/W". The sky in the game will show all 8 shades of luma from black to white. If there are less than 8 shades, or if they are not in the right order , then something is wrong with your mod (less than 8 shades might also be the result of a bad TIA).

It doesn't jitter, it's a steady 263 lines for the screen with the 32 character text, while is 262 for the second one (the one with lines) that you access by pressing the firebutton. Also the dpc+ 32 char demo has 263 scanlines. This is the one that does show 262 lines in Stella, not the bus-stuffing one (which doesn't run in Stella yet). I mixed things up in my previous post...

I investigated a bit on this issue. I have a cheap logic analyzer and connected it to the TIA output pins of my 4-switch while running the 128bus_20161005.bin demo and found that the first screen is outputting 263 scanlines instead of 262 as reported by Stella. In this screenshot you can see a capture while running the first screen (text demo). There are 260 "Horizontal Sync" pulses to which you must add the 3 scanlines of Vertical Sync. This one is for the second screen (line demo): Here you have 259+3 scanlines. So it seems that the timing is incorrect in Stella emulation.

Everyone has his own personal idea about what's the limit between an authentic 2600 game and what should be considered a different platform, and I don't see the point in trying to estabilish a "standard". Anyone would just keep programming/playing the games he likes and just ignore such a standard. That said, here is my personal idea (and I reserve the right to change it anytime without notice ): Any game that you can plug in an unmodded Atari 2600 console, and that uses the TIA output is an Atari 2600 game. In consoles using mass storage media (tapes, floppies, CDs, etc) you have a full working microprocessor based system with it's own memory and I/O. The software is read from the media and copied into the system memory to be executed. Hardware add-ons are well distinct from software in this case. The storage media only contains the software to be executed in the machine. On the other hand, a 2600 without a cartridge plugged in is not a complete system. It doesn't work at all, actually. The cartridge is by definition "hardware" and by plugging it you complete the system architecture by connecting components (rom, ram, i/o ports, coprocessors and whatever) to the system bus. A 2600 with Combat cart is different hardware-wise than a 2600 with Pac-Man cart, which in turn is different than a 2600 with a Supercharger module or a 2600 with Harmony Cart. What's a "vanilla" 2600 system here? It's just up to the programmer to decide what are the goals and limitations. You can take advantage of modern hardware like it would have happened if the 2600 was still produced today, or only use hardware which was avialable while the console was in production, or only use what was available in 1977 when the VCS was launched. The same can be applied to the development tools. You can use modern cross-assemblers, emulators and debuggers or decide to only use dev systems of th e'70s and '80s. All these approaches are completely arbitrary. And I appreciate them all! As for the topic starter, I think that producing games that require a separate hardware expansion is just a very bad idea. The effect is to further reduce an already niche market. All the hardware must be included in the cartridge itself, like it has been done so far. Add-ons (like the AtariVox or custom controllers) are ok if they're optional (that is, the game works also without them albeit with reduced features). Also I don't think programmers will ever run out of ideas. More probably we'll run out of programmers interested in the console at some point...

Yes, it's a Secam VCS. Atari didn't develop a specific TIA chip for French market and instead added external ciruit to generate SECAM signal using just the 3 luma output of the PAL or NTSC chip. The result is a palette with only 8 colors compared to 128 for NTSC and 104 for PAL. A handful of PAL Atari games in the early '80s were programmed to look good on SECAM too, including Pole Position, Mario Bros, Obelix, Asteroids, Battlezone. Activision also released separate version of a few games for PAL and SECAM. In addition to that, the "TV TYPE" switch actually turn on/off color in the video signal, while on PAL and NTSC its behaviour is controlled by software and later games used it for other function. "Secret Quest", for example, needs the switch to access the status screen, and it's unplayable on a SECAM console. Only 4-switch consoles were produced in SECAM, all the "jr" are PAL. There was also a junior with SCART output (PAL composite signal) sold in France, while the RF version seems more common. And all the Atari 7800 for French market were equipped with RGB SCART output and they're based on the PAL version, so they'll play PAL games with correct colors. Interesting to note the score in the "Space invaders" picture, showing extra colors: that's an artifact which only happens on SECAM, due to the way the color information is split into two components and sent over two scanlines. http://atariage.com/forums/topic/212910-early-vcs-secam-version-differences/?do=findComment&comment=2767356

I suspect a bad RIOT ic. The TV TYPE switch is connected to pin 21 and shorts that pin to ground when in B/W position, while it leaves it unconnected in COLOR position. Usually if a switch is oxidated or if there's a bad solder joint, the result is an open contact, which in this case would correspond to the "COLOR" position. Anyway check the switch first, maybe there's something in it causing a short. You can open it with with thin pliers by bending the little tabs under the metal body. This is easy to do if you first desolder the switch, but can also be done (with a lot more efforts) while it's mounted on the board. There is also a capacitor between pin 21 and ground which might be worth checking. If it's bad it could cause a short.

I'd drop the model number completely: 1. Atari Trak-Ball 2. Atari Mouse 3. Amiga Mouse

You can find pictures of two cx80 with the same mod applied here and here. That mod preserves the joystick mode functionality, but I've also seen pictures of units (both cx80 and cx22) with different mods.

No, because a 4k rom needs an additional address line. This is the pinout used in 4k and 2k Atari mask roms. They're the same except for pin 18, which is A11 in a 4k rom while it's a "chip select" line in a 2k one. In this picture that I found online of a NTSC board (solder side), you can see (in red) that pin 20 (CS1) and 21 (CS2) of the rom are tied to +5V (TIA pin 20), while (in yellow) pin 18 (CS3) is tied to TIA pin 24 (/CS0). From the schematic in the service manual, you can see that TIA (/CS0) is connected to address line A12. A 2k rom installed there would be selected with A12 high, and so it would work, but there will be bus contention if a cart is plugged in the cart port without modification. A 4k rom wouldnt work: it would be always selected with the lower 2k repeated twice in addresses $0000-$0FFF (bus contention with TIA and RIOT) and the upper 2k doubled in $1000-$1FFF (bus contention with the cart port).

Actually, I was thinking that the RPG kernel would be well suited for a "Boulder Dash" style game, so my subconscious made me write "rocks"... I like the new colors better, btw!

If you make the atari output a true interlaced video by adding the extra half line to each frame (which will then be more correctly called fields, as they will be alternately offset by half scanline up or down), that would be the same as the TV analog standard definition signal, that is 525 lines interlaced at 30Hz (framerate) / 60Hz (fieldrate) , or 625 25Hz / 50Hz in Europe. Note that "frame" here just means the totality of the visible scanlines on the screen, not a still picture like a frame in a film. Vertical and Horizontal speed of the electron beam in a CRT are fixed (they're determined by the circuitry in the TV and are not part of the video signal), To display more frames with the same resolution you should tell the TV to increase the speed of the beam and that is not possible. 480i and 576i only refers to digital video (for example the mpeg2 video stored on a dvd or broadcast using the DVB-T or ATSC standards).

It's also better than non-interlaced 30Hz flicker, altough a little worse than a standard 625/525 lines interlaced TV signal, where scanlines are closer together. The RPG demo looks really good on real hardware. Especially for large solid tiles (like the rocks and the trees), the perceived flicker is minimal and it gets even better if you back away a bit from the screen. In the "grass" tiles with small green dots on black background flicker is a bit more evident. Anyway, by tweaking the colors and the graphics to minimize the effect, I think that the kernel could be very well used in a game.

Try the one in this post: http://atariage.com/forums/topic/159159-interesting-devos-cartridge-dumping-issue/page-2?do=findComment&comment=1958565 That's the command line program, I don't know if it will work with the "Run7800" frontend.

I think that most probably it is caused by some bad ram bits in the console. If that's the case, you have to replace the 6532 "RIOT" ic.