Jump to content

alex_79

Members
  • Content Count

    1,605
  • Joined

  • Last visited

Everything posted by alex_79

  1. Very interesting, thanks for sharing! That one with the touch switches is really cool! Never seen a 2600 cart like that.
  2. Another try... tapper_fa0_v3.bin
  3. You're right, and I'd have expected pins 4 and 5 to be connected together too. But the pictures with the IC in place showed no solder on pin 4 on either side of the board, and another similar PCB documented a while ago leaves an input of a used gate floating too, so I thought they did the same here. Note that in both cases they could have connected the floating input to a pin right next to it.
  4. Many thanks for taking the pics of the board with the logic ICs removed! This confirms that the schematic I posted above is correct. Not sure why Tapper is not running on real hardware. I'll look into it. I'm glad that at least the other roms are working.
  5. There are a couple of errors regarding the 2600 in chapter 8: The console is from 1977, and the 6507 has 13 address lines so it can address 8k of memory
  6. Here are some modified roms for Centipede, Tapper, Beamrider, Galaxian and Pengo: fa0_conversions.zip These should work with your board.
  7. Because it was easier and cheaper to implement with standard logic ICs compared to the original scheme. In the original carts, the mask rom and bankswitching logic were typically integrated into a single custom IC, but that was only cost effective for large production numbers. Unfortunately, there's no an automated way to convert the games. It requires to "disassembly" the rom and examine the code. Some games are easy to convert just by changing a few bytes, others requires more extensive changes to the code. It really depends on the specific game. Here is an example of standard "f8" bankswitching (used by most, but not all, of the 8k original games) implemented with 3 logic ICs: https://web.archive.org/web/20150508151346/http://www94.pair.com:80/jsoper/bankswitch_f8.html
  8. Those roms were modified to run on this board, because it implements a different bankswitching scheme compared to the original games. They access address $FA0 for bank 0 and $FC0 for bank 1. If you want to program the eprom with different games, you'll need to modify the roms as well for use with this board. Stella doesn't yet support this as there were no known roms using these hotspots addresses before. I drawn a schematic of the bankswitching logic using your pictures as reference (I had to guess a couple of connections, as some traces are not visible without desoldering the two logic ICs, but I'm quite confident that this is correct. It's very similar to the scheme used in this other board (from brazil too), but this one uses more address bits, so the hotspots are a subset of those that trigger the bankswitch on that other board. Any address with A12=0, A10=1, A9=1, A7=1, A6=0, A5=1 cause a switch to bank 0 Any address with A12=0, A10=1, A9=1, A7=1, A6=1, A5=0 cause a switch to bank 1 Any address with A12=0, A10=1, A9=1, A7=1, A6=1, A5=1 may or not cause a bankswitch (undefined state of the NAND SR latch). Thanks for sharing the dumps and pictures of the board!
  9. BTW, it would be nice if someone with an unmodified PAL-M (TV system used in Brazil) console could test this. It should be autodetected as NTSC (PAL-M consoles use the same palette as NTSC) PAL-M has a slightly slower color clock compared to NTSC (3.575611 MHz VS 3.579575).
  10. Autodetection never failed for me when running Draconian on my consoles, including my SECAM one.
  11. I had a look at the cx22 schematic, and I think the issue might just be contact oxidation in the joystick/trak-ball switch itself (which is likely if the switch has not been operated for decades). The mode selection circuit uses a CD4019B (quad AND/OR select gate). The control pins Ka and Kb are pulled high through 10k resistors, and the switch grounds one or the other to pass the joystick (R,L,D,U) or trak-ball (Yck,Ydir,Xck,Ydir) signals to the 9 pin plug. What I think might be happening here is that the switch doesn't make contact when in Trak-ball mode and thus fails to ground the "Ka" pin as it should. According to the CD4019B datasheet, if both control pins are high, the output will be a logical OR of the inputs. The result would be that the trackball would only move down and to the right. In fact, in "up" and "left" directions, the R and D joystick signals are HIGH and the result of the OR operation with the two axis clocks Xck and Yck would be always a HIGH logic level. Which means that the clocks aren't passed to the console and therefore there isn't movement of the cursor. Additionally, this behavior would only be reliable above a certain speed, as if you spin the ball slowly, the joystick directions become a series of pulses instead of continuous signals (this would explain the "very sporadic and unpredictable" response described by the OP). Proposed solution: Try toggling the switch back and forth several times, in the hopes that this "scrubs" the oxidation out of the contacts and restore functionality. Sprying contact cleaner inside the switch it might help too, if possible.
  12. Sorry I can't help, that's beyond my basic skills in electronics... There aren't freely available scans of the junior service manual AFAIK. I have a 1981 PAL one that only covers the 6 switch console (I don't remember where I downloaded it from), and I always used the J. Sobola schematics for 4-swicth and Jr versions. Atari_2600_PAL_Service_Manual.pdf
  13. I don't think that's related. Paddle pots and trak-ball directions uses different pins which are connected to different ICs. It might be a faulty IC inside the trak-ball itself. Could you try the test rom posted here? There are 4 yellow squares on the bottom left of the image, which show the status of the 4 input pins used for the directions. On a working trak-ball, if you slowly move the ball you should observe the following behavior: the 1st square pulses on and off when moving in the VERTICAL axis the 2nd square is constantly OFF if you're moving UP, and constantly ON if moving DOWN the 3rd square pulses when moving in the HORIZONTAL axis the 4th square is ON when moving RIGHT and OFF when moving LEFT.
  14. No, the plugs are not needed for the color bar test of the diagnostic cartridge. On the console I currently have hooked up, the results are similar to Stella with default values: (The picture of the CRT screen looks much more washed out than it is in reality) This is from the PAL Service manual:
  15. alex_79

    The Jr. List

    Those are the release dates for the US. The junior was available at least in 1984 in Europe, and it was produced in Ireland in the "short rainbow" and "black" version. Mine is made in Ireland too, but it's a later version with the smaller box. I got it for christmas 1985.
  16. Could the issue be related to the starting bank? The original NTSC version of Congo Bongo doesn't initialize the console if it starts from bank 0 and typically crashes in that case. The alternate version (marked with "[a]" in Romhunter's collection) fixes this and the PAL version runs correctly regardless of the starting bank. Moonsweeper has the same issue: both NTSC roms usually glitch if started from bank 0, while the PAL one starts fine from either bank.
  17. alex_79

    Chess

    Thinking more about it, the cartridge slot on 6 switch consoles is about 4 cm deep (the slot is less recessed on 4-switch and juniors models). So, apart for that area, you can get creative with the design of the top of the cartridge. For example, it could be shaped like a chess piece...
  18. alex_79

    Chess

    II you're going to print the cart shells too, you could probably make it shorter than the standard atari ones (depending on the size of the PCB you're going to use).
  19. The max size without bankswitcing is 4k (any address with A12 low will cause bus contention with TIA/RIOT), so you need bankswitching for the 8k games in this cart.
  20. Looks like the same board as the carts shown in these threads:
  21. Despite what the "Stella programmer's Guide" says, Port B is fully configurable as output. The value read from Port B will always be the one written to it when set as output (On port A, a controller or other device connected to the port can override the value), so in theory you could use SWCHB as an extra byte of memory. The problem is that the switches short the pins to ground in one of the two positions, and I read contrasting opinions on whether the 6532 can handle this safely or not. Anyway, it is surely safe to set the 3 unused bits of Port B as output (as they're not connected to anything in a 2600), so they can be used as extra storage. IIRC "Combat" uses one of the bits.
  22. In the same github repository where the latest version is. Just click on "Releases"
  23. The input/output pins provide very little current and are designed to interface with other logic ICs, not to drive a load. You need to build a driving circuit. Similar to the examples in this page (for Arduino) http://www.thebox.myzen.co.uk/Workshop/Motors_1.html
  24. The per-game property file feature in Stella is almost fully implemented already: The emulator will read such file (same filename with .pro extension, in the same directory as the game), and the file can be created within Stella itself using the "save" button in the "game properties" dialog. The only thing missing is the ability to read the property file when it's in a zip archive together with the rom. Anyway, the property file contains the md5sum of the rom, so it must be updated each time you make a change and reassemble. What I do is to first generate the property file in Stella, delete the first line (the md5sum field) and save as "template.pro" in the same dir as the source. I then generate the md5sum field with this simple bash script #!/bin/sh md5=$(echo "$(md5sum [email protected])" | awk '{print $1;}') echo "\"Cart.MD5\" \"$md5\" " Finally, I concatenate it with the template into a new property file. Since I already use a bash script to assemble different versions of a rom (e.g. different TV formats) by passing parameters to dasm, I added the property file generation to it as well.
×
×
  • Create New...