alex_79

As said by others in this thread, this is mainly a matter of personal preference. For me, using a CRT screen is fundamental for experiencing these old consoles, but I prefer to get rid of the rf connection whenever I can. Here in Europe, almost every crt TV has composite and RGB inputs through scart. S-video is a bit uncommon (but there are external adapters which decode S-video to RGB without loss of quality). I have a 2600 modded for S-video (currently in need of servicing and probably will be upgraded to a better mod), a 7800 with composite mod and several unmodded consoles. The 2600 had a lot of hardware revisions during its life, and aging of components due to the conditions of use and storage influences the video output as well, so you won't find 2 2600 consoles with the same video quality. I have a 6-switch with a very clean and sharp rf ouptut, which looks very similar to the composite-modded 7800, but I also have others which are just plain terrible. The results also greatly differ depending on the specific TV set I use. Note also that there were a 2600jr with PAL composite out and a 7800 with RGB out (albeit decoded from chroma and luma natively generated by the video chips) officially sold by Atari in France back in the day, and those are technically "unmodified" hardware. From my experience (I did try some test roms on different consoles), a video mod doesn't impact flicker in a relevant way. The TV settings (Contrast, Luminosity, Saturation, Sharpness) can make a huge difference, on the other hand.

A couple of things to keep in mind if someone is having similar problems and he/she is not familiar with the 2600: - Paddles only works with games specifically designed to use them. You can't, for example, expect to use them in "Space Invaders" as that's a joystick game. (list of paddle games) - While usually player 1 and 2 uses the two paddles connected in the left port, some games might behave differently (Read the manual for the game! they are all available here on AA as well as on many other places). Also, There's not an estabilished standard on which paddle is player 1 and which one is player 2, so check both of them. - Older games require to depress the RESET switch in order to start playing (this is true also for non-paddle games). Pressing the buttons on the controllers doesn't have any effect until you hit RESET (Again, read the manual! The console switches, despite how they're labeled, are generic inputs for the console and each game can assign them different functions)

What games are you using to testing the paddles? Do you have an Harmony cart, a supercharger or other means to run a rom in your console?

The built-in games are Hockey (button 1) and Tennis (button 2) They both are pong-style games. Check the console manual in the link posted above.

Did you try the built-in games? If those work then the problem is in the cartridge (maybe a dirt/oxydized connector). There shouldn't be any screen flashing if no button is pressed. If you have the same behaviour with the built-in games, then maybe one of the switches is stuck or needs cleaning.

When the S? message appears, you can start the game by pressing the START (4) button. If you press the TIME (1) or MODE (2) button instead, you'll go to the game options selection (T? or M?). Read the console manual first, and try the built-in games to learn what the G?, T?, M? and S? messages mean and how to set the options. When you're familiar with the controls, read the manual for the cart, as some games might have specific options. You'll find all the manuals here: http://www.digitpress.com/library/manuals/channelf/index.html

The standard connector for TV antenna used in Europe is the Belling-Lee connector and it was already standard in the late '70s. So most consoles here (including the Atari) already came with the right plug. No switchbox or adapter needed. You just unplug the antenna cable and plug in the console.

Wow. I thought that after the snes-mini wrapped with tape was identified in a few minutes, they would have used some pcb from a dvd player, or a microwave oven... something hard to identify (because usually you don't find pictures of the boards, but only of the assembled product). Nope, they used a PC card! Something for which pictures of the pcb are available everywhere because the finished product IS the pcb itself! How stupid could they be to even think of doing that?

Simply, it is not the same cartridge. The one seen in the picture with the CRT TV and at the Toy Fair booth was a sd2snes board taped to the front half of a Jaguar cartridge shell. The tape seem to be in corrispondence with the mini usb port of the sd2snes board judging by the pictures I've seen. In the second "prototype" the cart shell is complete with the back half and they put the tape to match the one pictured before. For what we know, It can just be an empty cart shell in the latest picture, as the board in the clear console could be something scavenged from some random electronic equipment and therefore there might not be any connector to plug a cart into...

I just found this youtube series of videos and I think they're quite interesting. It's from an old VHS, so the quality isn't very good, and I noticed a couple of inaccuracies about how the 6532 is wired to the joystick ports, but it's still very useful for someone learning how the VCS works and how to fix the most common problems. https://www.youtube.com/watch?v=wc6CYLFjKoo https://www.youtube.com/watch?v=5eGJdNxFuXw https://www.youtube.com/watch?v=0rxuD4mxBZU https://www.youtube.com/watch?v=jb6FZ8rB5gU https://www.youtube.com/watch?v=xBHKWYJAPyQ https://www.youtube.com/watch?v=uBVjD84nwNU https://www.youtube.com/watch?v=zLYGMrUJado https://www.youtube.com/watch?v=OvjdP79m4go https://www.youtube.com/watch?v=XD1Ci9L1AuM https://www.youtube.com/watch?v=tdh4vt8UEtI

You can't do that. There are 2 screws fixing the cart connector to the plastic guide and the only way to reach them is to desolder the connector first.

If you have a multimeter, check that pin 1 of the controller port isn't shorted to ground (that's the pin for the 'UP' joystick direction). If it's shorted, check the pin itself and also the trace going to it to see if there's something evident on the board causing the short. If the board seems ok, try replacing capacitor c227. It is connected between pin 1 and GND and if it went bad could cause the short itself. If that didn't fix the problem, you probably need a new 6532 IC (A202 in the picture).

I searched the forums, but I didn't find this mentioned. I just found out that the "Color Bar Generator" cartridge from Videosoft was published in the "Radio Electronics" magazine as a DIY project. The article can be found in the August 1984 issue, pages 41-43 (you can download it from here). In the article by Jerry Lawson and Dan McElroy there are PCB layouts to etch your own board, a list of components (which only consists in the eprom and inverter IC) and a brief overview about the VCS hardware (the TIA is referred to as VIC, which stands for Video Interface Circuit and it's how it is called on VCS documentation from Coleco ) and the Color Bar Generator functions. There's also the address and pricelist for ordering from VideoSoft. You could buy the fully assembled cartridge, the kit or, interestingly, the source code listing, in case you wanted to burn your own eprom.

There's another video showing the "prototype" at the show that I think has not been posted yet (go at 1:27): In this one, you can see the tape on the front is starting to fall off...

I think the best way to add cassette support to the compumate is not to use the converted binary data, but to define a tape format like the "C64 TAP", which store the duration of each pulse in terms of cpu cycles. You should map the emulated cassette interface to the correct input and output bits in Stella. For the compumate those are SWCHA bit 7 (input from tape) and bit 6 (output to tape). Then you would have a "RECORD" and "PLAY" function in Stella that you could call during the emulation. When doing so the emulation should be paused and the user prompted for the TAP file to load from/record into. Once selected the file, the emulation should resume and, in case of RECORD function, it should create a new TAP file by monitoring the output bit and storing the duration of the pulses on the file or, in case on PLAY function, set the input bit according to the TAP file. In both cases you use the emulated cpu cycles as the time base for the pulses duration. This method has a couple of advantages over using the already decoded binary data: - you don't need to worry about how the data is encoded and decoded, because you let the bios doing the job like on real hardware. If the binary data is needed, simple external utilities can be written to do the conversion to/from the TAP format. - once implemented, you can reuse the code for emulating other 2600 hardware just by changing the input/output bit mapping. For example: "Magicard" by "Commavid" - Incidentally, it uses the same bits as the Compumate, with the difference that those are shared with the keyboard controller. You need to disable the controller while recording or playing the tape which on real harware is obtained by phisically unplugging the keypad to plug the cas interface or installing a switch on the interface. "Supercharger" by "Starpath/Arcadia" - Only playback function here on bit 7 of address $1ff9 of the bios rom, if I remember correctly. And, if/when hardware information become available "Supercharger" by "Canal3" "Comp K7" by "Splice" "Copy Game" by "Micro Hard Equipamentos Electropnicos Ltda"

Here are the binary conversion of the programs posted by Amstari in this thread. The Compumate basic programs are also 1.5kb each. Atari_Logo_Graphic.bin Number_Guess.bin PercentageCalc.bin Quest-A.bin Rock_Paper_Scissors_CompuMate.bin Square_Root.bin

I managed to convert the audio files into raw binary data. I used a modified version of an old utility I wrote for another project and it worked quite well. I had to manually fix some of the audio files or they wouldn't convert as is. Especially the first 2 or 3 Picturemate tracks had some issues (see picture) that could cause them not to work at all on real hardware altough I don't have a compumate an I cannot test it myself. The picturemate tracks holds 2052 bytes each, while the songmate ones are 1540 bytes. The first 4 bytes are some sort of header, so there are exactly 2kb and 1.5Kb respectively (the compumate has 2kb ram built-in). As you can see in the following picture, I I typed a few bytes from the first Picturmate track into the ram in the Stella debugger and the correct picture started to appear on the rendered screen. I also used the raw data to generate new audio files that should be more reliable. If someone wants to try them on real hardware and report if they work, it would be appreciated. Here are the files: compumate_tape_binary_v1.zip compumate_tapes_remastered_v1.zip

Those circular holes in the plexiglass look a tad on the small side to allow for the hardwired controllers to pass through... It might just be the perspective, but that controller on the table is pretty close to the plexiglass. How do they manage to put the console under there?

The problem is that the rom doesn't initialize correctly ram and stack. Probably the dev system used at the time (I think either a 7800 with devOS + ramcart or a supercharger) already initialized those so the bug wasn't evident. Here is a fixed version: cube_imp-fix.bin It seems to work fine on my crt TV. It doesn't use RSYNC, the interlaceing is enabled just by using different VSYNC timing for each field.

I'm not very expert in electronics, but why do you want to measure the voltage on that pin specifically? It is connected to a capacitor and to one of the TIA inputs. The voltage of the pin depends on what controller was connected to the port (paddles and keypads apply power to that pin and so charge the cap) and what game is running (paddle games periodically discharge the cap and then measure the time it takes to recharge through the paddle controller). Moreover I expect that the multimeter itself will discharge the cap quite quickly even if there's some voltage left on it, so I think the reading won't be of much use...

Cool! Thanks for sharing those dumps! By looking at the waveform (I used Audacity), you can figure out how the data is stored. 2 tones are used to record the binary data: - 1 cycle of a sinewave at about 1300 Hz - 2 cycles of sinewave at about 2600 Hz Assuming that the lower freq corresponds to a '0' and the higher one to a '1' bit, the data format is the following: 1 '0' start bit (green) 8 data bits (gray - we don't know if they are sent from least to most significant bit or the other way around) 4 '1' stop bits (red). The first about 10 seconds on each track is probably an header to sync the software in the compumate with the cassette. It follows the same format described above, but all the data bits are '1'. In this picture you can see a detail of the end of the header and the beginning of the actual data.

As Thomas said in the above post, the TV format of the firmware only affects the menu, not the games. If you're experiencing wrong colors in the games it means you are using NTSC roms. Just download the PAL versions. There are also a lot of PAL60 conversion here on AA (NTSC framerate with colors corrected for PAL 2600) for games which didn't exist in PAL format or which weren't speed corrected and played slower than the NTSC ones.

You must install the Harmony cart software on your PC and upload the firmware using an USB cable. The firmware upgrade without the USB cable is only available for the newest 1.06 firmware which is a beta version and NTSC only at the moment.

When a game is said to run at 15 fps, it means that it can it can do calculations to render 15 new frame of graphics per seconds, but the video signal must still be at 60Hz (or 30Hz interlaced or any other standard signal accepted by the TV or PC monitor in use). Some frame in the video output will be duplicated to reach the required framerate. This is achieved either by hardware (the video chip will just output the same image until it's updated by the cpu) or by software (as in the case of the 2600, when the programmer must ensure that the video timing is correct). I think that the only 2600 game that can have occasional framerate drop is Boulder Dash, which takes more time to calculate a new frame when there are many objects on screen. But it stills outputs a steady 60Hz signal, or the TV would lose sync...