Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by alex_79

  1. What games did you try?
  2. alex_79


    Some more recent PAL CRTs behave like that instead of showing color loss. See here: https://github.com/stella-emu/stella/issues/265#issuecomment-350328199
  3. You could also build a pass-through adapter that will connect between the Atari and the 8Bitdo receiver. It requires more soldering, but you don't need to mod the receiver.
  4. alex_79


    Tapper: I experimented a bit with interlacing on the 2600 a while ago, and I remember that I got issues with PAL color loss. IIRC, adding one scanline to one of the field eliminated the color loss (e.g alternarting between 312.5 and 313.5 lines), but these field with different line count screwed the image at least in an old BW TV.
  5. The values only refer to where the page will be copied in the SC ram and are encoded like this: [address page offset] * 4 + [bank number] The values are in the same order as the pages in the first 6k block of the binary file. So the first value refers to the first page in the binary, the second value to the second page in the binary and so on. So in your example a value "$04" as the second index in the page table means that the second page in the binary ($0100-$01ff) will be copied in the second page of bank 0 You can find some more info in the following docs: https://web.archive.org/web/20110423060211/http://www.io.com/~nickb/atari/doc/sctech.txt https://www.biglist.com/lists/stella/archives/199901/msg00026.html The Cuttle Cart manual is a good source of info about the Sc too: https://atariage.com/manual_page.php?SystemID=2600&SoftwareLabelID=1160&ItemTypeID=&currentPage=10&maxPages=24
  6. The 6.2.1 version for r77 has been released already a couple of weeks ago. https://stella-emu.github.io/downloads.html
  7. Sega and Atari controllers use a different pin for power. Standard 3 and 6 buttons Genesis/Mega Drive pads work on an Atari 2600 even if power is applied to the wrong pin, but that just happens "by chance" and you can't assume that any sega controller will work on the Atari. In fact it's generally a bad idea to connect a controller designed for a different console without first ensuring (by reading a schematic or tracing the board) that it won't damage the console, the controller itself, or both. The Arcade Powerstick contains extra electronics (leds, autofire, etc) compared to a standard genesis pad, and I guess that's why it doesn't work. Possible solutions: 1) add a jumper inside the controller itself to connect the wires going to pins 5 and 7 of the plug together. PROS: very simple mod, no components required apart from a piece of wire. CONS: Requires soldering The stick cannot be used anymore with a sega console 2) build a pass-through adapter PROS: You don't need to modify the controller, so it's still compatible with a sega console The adapter is simple to build (2 connectors and some wire) CONS: Requires soldering (but you might find someone here on the forums who can build it and ship it to you). 3) buy a Seagull 78 adapter PROS: Ready to use, no soldering CONS: Overkill if you only use it for a 2600 (it's designed for 7800 2 button games) Considerably more expensive than the DIY solutions above You lose the possibility to play recent homebrews and hacks that make use of the sega "C" button, as the adapter makes the stick behave like a 7800 controller, and the 2600 won't be able to differentiate between the "B" and "C" buttons anymore.
  8. It depends on the game. The console switches are under software control, therefore their functions can change from game to game. Refer to the instructions of the specific game you're trying (you'll find most manuals on the main AtariAge webpage, but also on Atarimania, the Internet Archive and many other places). The Harmony cannot alter the functionality of the switches, so if they don't work properly, it's a hardware problem.
  9. Replacing the ports is only needed if they're physically damaged (e.g. there are missing/broken/bent pins). What games did you try?
  10. Just download them from here: http://www.atarimania.com/rom_collection_archive_atari_2600_roms.html You must use the combined files for multiload games, except for "Party Mix" for which you need the separate files instead.
  11. AFAIK, in the US the Jr only came with the regular "cx40" joystick. In Europe it was initially packaged with the prolines, then the cx40 and finally the joypads.
  12. I still have the console I had a s a kid. I got it in 1985 and it's an early Jr. made in Ireland (note the "Atari, Inc" copyright). It came packaged in the smaller "lunchbox" style box, so it's a later production compared to the one in the large box posted by @high voltage above. The label on mine just says "model no. CX 2600", no "JR." So, Atari wasn't very consistent on this. But I agree that since it is printed on some labels, "Jr." can be considered an official designation.
  13. I just noticed that you can disable the flickering with the left difficulty switch...
  14. https://atariage.com/store/index.php?l=product_detail&p=42
  15. If you're in the US, you screw the adapter to the antenna F-connector on the back of your TV, then plug the rca cable coming from the Atari console on the adapter. If you're in Europe, that adapter is useless as 1- TVs use a different connector for antenna (Belling-Lee connector) 2- The RF cable of PAL Atari already has the right connector and just plugs directly in PAL TVs. No adapter required.
  16. I played a bit. It's looking great so far Sometimes the last invader gets stuck (but you can shoot him and continue playing). savestates.zip
  17. late PAL Jr. console (1991): and with the test rom by Spiceware posted in this thread: https://atariage.com/forums/topic/298427-weirdest-bug-you-ever-had/?do=findComment&comment=4394131 Back to "Space Invaders"... I tested all 3 versions on that same console with Harmony cart (doubled up v. 0.1 and 0.2 to 8k and added extension "F8S"). They work, but what's up with those stripes (playfield, I guess) on the background? They don't appear in Stella. Moreover, shots are gray instead of the sprite color (green on Stella, blue on my hardware because of PAL colors). Those stripes are visible also in alfredtdk's screenshots posted earlier. The score starts on the very first visible line on my TV, but it's fully visible.
  18. Might be worth trying the solution described in this (ancient!) thread: https://atariage.com/forums/topic/26719-help-with-7800-pal-composite-mod/
  19. It's worth mentioning that paddle and joysticks are not interchangeable. A game that requires a joystick won't work with paddle controllers and vice-versa. This might not be obvious for people new to the 2600.
  20. On real hardware, the undriven bits (0-5) typically keep the last state they were in, that is determined by the last byte that was on the data bus. This is the behavior of Stella with the "Drive unused TIA pins.." option disabled. In zero page addressing mode (which is what you get if you forget the "#" in a constant), the last thing on the bus is the zero page address itself. So "bit D0" will read from address %00000001, that is register "CXM1P" (from the table posted by Spiceware in a previous post). Bit 7 and 6 depend on the status of that TIA registers, bit 0-5 will keep the value they previously had on bus ("000001"). So, if there aren't collisions, bit 6 and 7 are both 0, and the result of that instruction will be the intended one, even with the missing "#" (and ignoring the fact that "bit" doesn't have an immediate addressing mode) . The problem is that on some very rare occasions, with some console, or some combination of console + cart, one or more of those undriven bits might behave differently from the typical case and constantly read "0" or "1" when undriven, no matter what the last value on the bus was. This occurs so rarely, that many games (original from back in the day and homebrews) have those bugs. The developer option in Stella helps identifying the bug as it returns random values for bits 0-5, ignoring the bus state. This doesn't represent a real-world scenario (no real console would behave exactly like that), but in this case the point is to make the bug more evident rather than represent the typical behavior.
  21. I seem to remember that an option that allows to play the game inside the debugger was proposed in a discussion a while ago. That would incidentally also meet Nathan's needs, as the debugger window shows a raw TIA output with no aspect ratio adjustment (every TIA pixel is always 2 screen pixels wide x 1 heigh) and no effects, exactly like the 1x snapshots. On the other hand, I think an option to have a "RAW" output in the normal window should only be considered if it doesn't complicate the code and the UI, because, as stated before, it generates an image that is actually deformed (it's compressed vertically for NTSC games, and stretched for PAL ones), while Stella focuses on accurate emulation which includes giving an image with correct aspect ratio (and this took efforts to implement). Therefore it should have no options: no zoom, no fullscreen, no phosphor emulation, no effects. Basically, it should be clearly an option only needed in special cases like those discussed here, and should be off normally.
  22. A small correction to Spiceware's post above: bit 6 is actually always defined and it's 0 if the TIA register doesn't use it. It was my understanding too that only bits actually used by the TIA registers were valid, until, during tests of the new TIA core in Stella 5.0, a rom showed a different behaviour for bits 6-7. The explanation is that the TIA has output transistors to drive bits 6 and 7 and, on a read access, will always drive those (also in addresses that do not correspond to any register, like $0E, $0F and mirrors). If unused, they default to 0. Bits 0-5 are undriven and you shouldn't rely on their value. (and you should use the mentioned "Drive unused TIA bits..." developer option to easily spot bugs) There's a recent bugfix in Stella regarding this (bit 6 of INPTx was considered undriven like bits 0-5) that will be in the upcoming release.
  23. If you disable interpolation and TV filters and use a reasonably high zoom factor (e.g 300% or more), you can obtain screenshots which are very close in look to the pixel-perfect ones (no blurred edges), but scaled up and with correct aspect ratio (so, same size for NTSC and PAL): Example: with these settings You get this PAL NTSC
  24. That sort of bug causes issues on real hardware only in rare cases, so the jittery paddle on your console is probably due to the controller itself. The purpose of the Stella developer option that drive bits 0-5 randomly on TIA reads is to make that bug much more evident than it is on real hardware, so that it can be identified and corrected. Many original and homebrew games have those bugs and that's why the option defaults to "off" in "player" settings in Stella. A great description of what's happening on real hardware can be found in this post by supercat, and in particular the last few paragraphs:
  • Create New...