alex_79

If someone has a collection of those, I can check them. Probably they will form just one big group. Yup. I tested the old "hacks and homebrews v. 1.2b (sorted)" (you can find it here). I only ran the utility in the "homebrews" directory and the result is 141 unique files out of 463 total. By looking at the resulting Clones.txt file, you can see a huge group of 190 related roms. Clones.zip I couldn't generate the csv file out of it using Clones2CSV. I got a "Runtime error 216". Don't know if that's due to my setup or if the utility just can't handle such a large table. It works without problems on the rom collection I use in Stella and Harmony cart, which is the atarimania.com one plus a selection of homebrews and hacks for a total of over 2400 roms, but the largest group in there is about 40 roms.

Tried and it worked flawlessy in Wine on my linux machine (both Clonespy and the CSV convert utility). Thanks for the update!

It might be an OTP eprom (that is, standard eprom in a plastic package without the window). Can you read the markings on the chip? EDIT: Nevermind, I see you posted a picture of the chip and it appears to be a mask rom.

Keep in mind that when dealing with AC, we refer to "root-mean-squared" voltage, not the peak voltage (not useful to compare power with DC), nor the average voltage (that would be 0). In 9V AC, the voltage peak-to-peak amplitude is 25.4V (that is, the waveform oscillates between +12.7V and -12.7V).

Yeah, being a forum in the first place, I don't think adding a mandatory "shipping location" in the profile would be a good idea. Just ask the buyer. If you post stuff for sale in the marketplace, add shipping rates for different counties, or put a notice "ask for shipping rate outside US" or something like that.

That component is a trimmer potentiometer. It just looks like that, nothing it's missing.

That schematic is from the 2600 Service Manual. CX2600-CX2600A_schematics.pdf

CS pins are used to allow more than one memory or I/O IC on the CPU address and data bus. On the 2600 only 2 of the TIA CS are used (/CS0 and /CS3), the other two are just tied to +5V and GND. The 7800 uses 1 more CS pin . If you don't have anything else sharing the same data and address lines with the TIA, then I guess that you can leave it always selected (that is, pin 21,22 and 24 low and 23 high. But don't take my word for it, as this is beyond my basic skills in electronics.

TIA outputs are open-collector, so you need to put pullup resistors in order to make them work. READY (pin 3) is an output used to halt the 6502 until the end of a scanline when the TIA WSYNC register is strobed. Since you're not using the graphics, you probably don't need it in this application. CSYNC (pin 2) is an output! It's the Composite SYNC for the video signal. There are 4 CHIP SELECT inputs on the TIA: 3 active-low (pin 21, 22 and 24) and 1 active-high (pin 23). These must be set correctly before accessing the TIA. EDIT: the picture I was using as reference had 2 of the CS pin active state swapped. I fixed both the picture and the post Phi0 (pin 4) is an output and it's the clock divided by 3, used as the main clock for the 6502 inside the 2600 console. Phi2 (pin 26) is an input and it's the phase-2 clock (generated by the 6502 in the 2600). This is used by the TIA to know when valid data can be read/output on the bus, so I'm pretty sure you'll need it to make it work. Take a look at the timing charts in the Stella Programmer's Guide and in the 650x processor datasheet. I'd suggest to open a thread in the "hardware" section here on AA, where it's more likely that the electronics experts will see it.

I'm glad it worked! No, with games larger than 4k things complicates a lot. You can't just place existing roms of those games in the eprom. Instead, they need to be disassembled so that the part of the code that handles the bank switching can be modified to work with the multicart scheme. You need to decide where the game will be on the eprom before modifying it, as it will be hacked to use specific banks of the multicart, and it won't work if you move it in a different position. Moreover, you can't lock the bankswitch as with 4k games after you select them from the menu, so you must also ensure that the rest of the code doesn't accidentally trigger a bankswitch that will cause the game to crash. The design is flexible because allows mixing different size roms in the same multicart, but requires some knowledge of 6502 programming to hack the games larger than 4k to work with it.

The junior with the bigger box was actually sold in Europe. There was a version with 2 joystick and a pack-in game (centipede) and another with only 1 controller and no game (They used the same picture on the box, but the second controller was covered with a big "NEW" sign in the latter). Those were probably available during 1984 and soon replaced by the smaller "luchbox" version with the "black" jr pictured on it. I received my 2600 in Christmas 1985 and it was in the smaller box already. While the picture on the larger box showed a "short rainbow" version and the one on the smaller one the "black" version, you could find both type of consoles in both type of boxes. (Mine is a "short rainbow")

I tested the binary you posted in Stella and every game works fine here, including Keystone, Pacman4k, Qbert and Reactor. If it doesn't work for you in Stella, ensure you're using the latest version (http://stella.sourceforge.net/downloads.php). If, instead, the problems you described happen on real hardware I can't be of much help as my skills in electronics are quite limited, but there are many experts here on Atariage who surely can figure out what's going on.

Scans of the first 7 issues of the newsletter have been posted here: http://atariage.com/forums/topic/209519-rca-studio-ii-gold-mine-an-interview-with-the-studio-2-production-manager/page-20?do=findComment&comment=2918924 I too would be very interested in looking at the programming cart tech docs.

Did you include the "safe net rom" before the menu in the eprom? You must have the safe net rom in the first 4kb, then the menu, then the 30 games, for a total of 128Kb With this configuration works fine for me (in Stella emulator). If I only put the menu and the 30 games (124Kb) I got the behaviour you described (offset by 5).

The menu you posted works correctly if it's placed in the first 4k of the eprom. But since you have 30 titles I guess you want the "safe net ROM" (the one in this post) in the first bank so you can use the reset button on the cart. In that case you should change "FirstTitleBank" value to "2" in the source file. ; --------------------------------------------------------------------------- ; These settings control the behaviour of the menu (Change This) ; --------------------------------------------------------------------------- FirstTitleBank = 2 ; Indicates the real BankNr of the first bank in the menu. ; When setting this to 4, the menu will load the 5th bank ; when selecting the first title. ; By default this would be 1 if bank 0 contains a menu, ; or 2 if bank 0 would contain a safety net and 1 the menu. NrTitles = 30 ; The actual number of menu items, currently a range of 8 to 230, ; But since bank 128 to 255 are mirrors of 0-127, this number of ; Entries/Titles will not be needed. PAL = 0 ; 1 = PAL 0 = NTSC Here is the resulting rom after making that change: megacard.bin Let me know if it works.

I tried compiling the menu and it seem to work in Stella. Can you post the file with your adjustements?

Yes, you can wire a button between pin 7 (+5V) and pin 5 (booster grip "trigger") for firing and you can use the normal button for thrust. But since the CX40 doesn't have pins 7 or 5 connected, you'll need to replace the cable and plug (you can use a sega extension cable, that has all 9 pins connected). But why do that, if with the same effort you can build an adapter that will allow you to use an unmodded cx40 or any other atari compatibile joystick with Omega Race? http://www94.pair.com/jsoper/2600_omega_adap.html https://sites.google.com/site/halfbaker2/2600omegaraceadapter With one of these adapters you can play an original Omega Race cart using the same control scheme as Asteroids (Joystick UP= Thrust, Button = Fire). The only difference between the two is that one use an inverter IC, while the other uses discrete components (a transistor and a few resistors) to achieve the same result. If you have an Harmony cart, just play the hacked rom without any adapter: http://atariage.com/hack_page.php?SystemID=2600&SoftwareHackID=83

I'm not an electronic expert, but I guess the additional circuit is a latch that prevents further bankswitch after the first one. If so, you only need it if you're using a 8Mbit EPROM like the 27C80 in the schematic, having 255 4k games on the cart. If using the original schematic, in fact, only the upper 128 games would have the bankswitch locked. The advantage of it is that you can have games larger than 4k in the lower half of the eprom (but the games have to be modified to work with the multicart). If you're using smaller eprom (for 127 4k games or less), you don't need the extra circuit, because you can make the menu itself to lock the bankswitching after the game is selected, and you can do that for each game independently, allowing to mix 4k and larger games in any order (you still need to modify games larger than 4k). In the source attached previously in this thread, you need to change the values in the "BankList" table. Here is how it looks like in the source: BankList .byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 .byte 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 .byte 20, 21, 22, 23, 24, 25, 26, 27, 28, 29 .byte 30, 31, 32, 33, 34, 35, 36, 37, 38, 39 .byte 40, 41, 42, 43, 44, 45, 46, 47, 48, 49 .byte 50, 51, 52, 53, 54, 55, 56, 57, 58, 59 .byte 60, 61, 62, 63, 64, 65, 66, 67, 68, 69 .byte 70, 71, 72, 73, 74, 75, 76, 77, 78, 79 .byte 80, 81, 82, 83, 84, 85, 86, 87, 88, 89 .byte 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 .byte 100,101,102,103,104,105,106,107,108,109 .byte 110,111,112,113,114,115,116,117,118,119 .byte 120,121,122,123,124,125,126,127 If you leave it like that, bankswitching will still be active after a game is loaded, which could cause some 4k games to crash. If you add 128 to a number in the table, the game in that position will have the bankswitch locked after it's selected. So, if you only need 4k games, just replace the entire table with the one below, and you won't have any game crash even without the extra circuit. BankList .byte 128, 129, 130, 131, 132, 133, 134, 135, 136, 137 .byte 138, 139, 140, 141, 142, 143, 144, 145, 146, 147 .byte 148, 149, 150, 151, 152, 153, 154, 155, 156, 157 .byte 158, 159, 160, 161, 162, 163, 164, 165, 166, 167 .byte 168, 169, 170, 171, 172, 173, 174, 175, 176, 177 .byte 178, 179, 180, 181, 182, 183, 184, 185, 186, 187 .byte 188, 189, 190, 191, 192, 193, 194, 195, 196, 197 .byte 198, 199, 200, 201, 202, 203, 204, 205, 206, 207 .byte 208, 209, 210, 211, 212, 213, 214, 215, 216, 217 .byte 218, 219, 220, 221, 222, 223, 224, 225, 226, 227 .byte 228, 229, 230, 231, 232, 233, 234, 235, 236, 237 .byte 238, 239, 240, 241, 242, 243, 244, 245, 246, 247 .byte 248, 249, 250, 251, 252, 253, 254, 255 Here is the source code with the table already replaced. megacardmenu_v2_3--all_games_locked.asm Remember to set the number of games by changing the "NrTitles" value (this menu software supports up to 127 titles, for more titles you'll need to modify it or use a different one) ; --------------------------------------------------------------------------- ; These settings control the behaviour of the menu (Change This) ; --------------------------------------------------------------------------- FirstTitleBank = 1 ; Indicates the real BankNr of the first bank in the menu. ; When setting this to 4, the menu will load the 5th bank ; when selecting the first title. ; By default this would be 1 if bank 0 contains a menu, ; or 2 if bank 0 would contain a safety net and 1 the menu. NrTitles = 127 ; The actual number of menu items, currently a range of 8 to 230, ; But since bank 128 to 255 are mirrors of 0-127, this number of ; Entries/Titles will not be needed. PAL = 0 ; 1 = PAL 0 = NTSC

I joined the club! A few months ago I finally bought a vc4000 on ebay (EUR 25,50 shipped). It came with the two controllers, the power supply and the "invaders" cartridge. Untested, but was the first affordable one I found in months (and I was looking for any console of the APVS family, not specifically the Interton). I bought it from France and it turned out being the SECAM model. The board is the one of the later "single board" PAL model, but there's not the RF modulator on it and the area where the PAL encoder chip and supporting circuitry would be is unpopulated. A daughterboard is attached below the main pcb, for the SECAM encoding circuit and the modulator. It was already my intention to mod the console for RGB before buying it, but since I don't have any TV that can tune a SECAM RF signal, that became a necessity. With little modification to the daughterboard I was able to get the required TTL RGB signals. I then used a few resitors to reduce the voltage from 5V to 1v as required by the TV to get a perfect, crystal clear RGB output! (I used the diagram on this page about the BBC micro as reference for resistor values) I left the console with a bunch of temporary wires going from the board to a scart socket scavenged from old equipment until yesterday, when I finally managed to solder a proper cable and close the case...

You might try to manually turn off all the picture-enhancing options, but it seems that the problem is that the TV is applying a deinterlacing filter because it doesn't recognize the non-standard progressive signal from the Atari. Usually there's nothing you can do to fix that, other than using an external upscaler. If you have a dvd recorder or PVR with analog inputs (composite and/or RF) and hdmi outputs you can try connecting the console to that. If you're lucky it can deal with the progressive signal and you can use it to bypass the TV built-in decoder/upscaler.

Yeah, TIMINT isn't mentioned in the Stella Programmer's Guide but you can find info in the 6532 datasheet. Btw, "INTIM" and "TIMINT" aren't the most descriptive names, I never remember which is which without looking at the docs... I tested the rom in a few more consoles and I can mostly confirm my previous results: - the increment seem to be always set to 1024T (unless you just played a game and swap it with the testrom leaving the console unpowered for a very short time) - the actual timer value is random - the interrupt flag is also random: while in the light sixer I tested yesterday it seemed always set, this isn't true for the other consoles I tried. Here is a fixed testrom if anyone is interested. The old one could incorrectly detect the increment for low initial values, if the timer decremented to 0 before the increment calculation routine started. Now it should work correctly for any value between $01 and $FF. If the initial INTIM value is $00 the increment isn't displayed as there's no reliable way to calculate it in that case. The INTIM value and interrupt flag is always displayed. timer_test_v2.zip

I made a simple test rom to check the timer at startup and display the results. The screen looks like this: The 'I' indicates that the 'timer flag' (bit 7) is set in the interrupt flag register (TIMINT). The following two digits are the timer value (INTIM register) at startup (in hex) On the right there's the time interval (1T,8T,64T or 1024T). I only tried this on one console (a PAL light sixer). In my tests the timer is almost always set to 1024T (like in Stella) and the "timer flag" is set (While it's cleared in Stella). The actual value seems to be random. If I run the test shortly after having played a game cartridge, though, the timer is almost always set to 64T (which is the value most used in 2600 games as it's similar to the scanline duration). If I leave the console powered off for a few seconds more and try again, it gets back to 1024T The testrom need to be the executed at power-on, so if you use an Harmony, you must flash it in single game mode. If you launch it from the menu, the results are influenced by the menu software itself (I always get "I 05 64T", in that case). For the same reasons you cannot use a supercharger, cuttle cart or other flahcarts with a menu. timer_test.zip

I voted "others", beacuse I only play old consoles using CRT TVs or in emulation with CRT filters active, but not because I think there's need to be color bleed or fuzzyness/interference on the picture (In fact I av-mod my consoles with RGB or if not possible s-video output to get rid of those). Intead, I want to display the output of those old consoles (mostly the atari 2600 in my case) with the best possible, crystal clear image. And that means CRT! I disagree on the fact that the crt shadow mask or scanlines are just a technical limitation of the time and that eliminating them (using an emulator without any filters, for example) makes the image like it was intended to be. When those games were developed the only way to test them was displaying on a CRT. Graphics were designed and then adjusted depending on how they looked on that technology. If you use an RGB modded console, connected to an arcade-quality rgb monitor you have a perfect picture, with no color bleed, where all the pixels are perfectly visible. But those pixels are not little colored squares, they're small spots of light, with the bright ones slighly larger than the dark ones, with scanlines to separate them vertically (again, those are thinner in bright areas, and more visible in dark ones) and shadow mask/aperture grille giving a sort of "texture" to large colored areas. Those characteristics of the CRT technology have the effect of smoothing and merge the pixels to form the full image. When you remove them, you break that illusion and you see the single pixels instead. This get worse by increasing the size of the display. Some examples from stella emulator with CRT filters (RGB mode) and without: Here you can see two menacing starships approaching your base on Atlantis: Here you have a bunch of colored tiles: Other examples: These pictures are often posted in similar discussion on other forums to show the difference in using TV filters in emulation: with crt filters: without: Look at them in fullscreen. Which one looks better? I agree with what have been said by others about the advantages of CRT when using real hardware (no lag, compatibility with lightgus, vivid colors, etc). CRTs are still cheap and availables, and that's the best solution to enjoy old consoles. Using a digital TV is ALWAYS a compromise and in that case I prefer emulation (with CRT filters).

Right. I missed the 2nd overlap line in the screenshot I posted. It makes sense, altough I thought that those kind of differences were caused by different TIA revisions, while in my tests the same TIA that shows the bug in the sixer works fine in the vader and viceversa, so it's something else on the board that causes the shift. The TIA in the 7800 is soldered so I didn't tried swapping that one... yet! Judging by threads about some projects here on AA and elsewhere (the H2, for example), the 7800 seems to have much more variability across different revisions/batches of consoles causing many compability problems difficult to track down... Thanks for your clear and helpful explanation. I find projects like this really interesting.

@Rom Hunter: Yesterday I reorganized my rom collection for use in Stella and Harmony cart (which is basically your collection integrated with a selection of homebrews, demos, hacks and NTSCtoPAL conversions and subdivided in folders by TV format and then alphabetically). I like the long filenames (the Harmony can display them just fine) and I also keep the variations and duplicate roms with alternate names. A couple of suggestion for the next version: - You should add back these "Superman" and "Seaquest" roms: they were removed as bad dumps, but later I found them again in a pirate console, which confirms that they were actually released. (see this post). Seaquest (Megatronix Game Over 2600 Console) (PAL).bin Superman (Megatronix Game Over 2600 Console) (PAL).bin - You should remove the "joined" "Party Mix" roms (both PAL and NTSC), as it is not a multiload game. Those roms won't work in emulators nor in flashcarts, you only need the split ones for this game. @Wickeycolumbus: The "Missile Command CCE" rom you posted differs by 4 bytes if compared with the Atari release with the Rob Fulop's initals removed, but only by 1 byte (the high address break vector) compared with the original version.