Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by alex_79

  1. Even without considering the RNG bytes at the end, I'd still think it's a bad dump because of the one byte (actually just one bit) difference in bank 0, which causes the gfx glitch when falling into a pit. I find unlikely that it would have made it into a review copy without being noticed before. Interestingly, there are also 4 bytes that differ at the start of bank 1 (address $1000 in the binary): the beta contains the sequence "78 4c 81 fb" there, while in the release is all 'ff'. That byte sequence is the code SEI JMP $F081 Anyway, the VCS can never access that area of the rom, as the DPC registers are mapped there. And any difference there can be caused by the method used to dump the game. The code is maybe a leftover from the development system?
  2. I found the answer in this old thread: This also match with the fact that there aren't repeated values in those bytes. I guess modern emulators don't need those 255 bytes and just emulate the DPC random number generator instead. I tried stripping those bytes from the rom of the release NTSC "Pitfall II" and it plays just fine in Stella, Gopher2600, Stellerator and Javatari, while it does not work in Z26.
  3. Is there a document explaining the file format for DPC binary files used by emulators? It's my understanding that Pitfall 2 has 8k of program rom (2x4k banks using "F8" bankswitching), plus an extra 2k of rom built into the DPC chip itself which is indirectly accessible using the chip data fetchers. The binary file contains the program rom from $0000 to $1fff, and the DPC rom from $2000 to $27ff. The beta rom posted above ends there, while the known dumps have 255 extra bytes at the end of the file ($2800 to $28fe). What are those for? At first glance, they are all the values from $00 to $fe in random order without repetitions.
  4. I don't think that would work: the joystick pulls either pin 1 or 2 low when moved 'up' or 'down', therefore it will be activating the motor when moving it in those directions. Doesn't matter if the pins are pulled low by the RIOT or by the switch inside the joystick: the result is the same. I only have basic skills in electronics, so take the following with a grain of salt: I think a way to make it work is to connect both pin 1 and 2 as inputs of an 'OR' gate (e.g a 7432 IC) and use the output of that gate as the signal to activate the motor (low=on, as before). The output will be low only if both pin 1 and 2 are low at the same time, and while you can do that by setting those pins as output, it cannot accidentally happen simply by moving the stick. As before, you cannot read the joystick and keep the motor running at the same time: you need to (briefly) set the pins as inputs to read the stick and during that time the motor would switch off. But that would take only a few CPU cycles, so shouldn't be a problem. You can put another OR gate on pins 3 and 4 ('left' and right' directions) to add another function to the controller, or maybe combine it with the other gate to control a SR latch so that the motor can run continuously even while you're reading the stick...
  5. While I'm not following the Atari scene very much lately, I fire up Stella quite regularly for a quick round, or to tinker with the debugger to see how existing games work, sometimes also to troubleshoot my occasional attempts at programming. So, thank you so much to the Stella team for the continuous work to refine and upgrade this amazing emulator!
  6. By writing a 0 to SWACNT you set the bits back to input mode, and they're at logical "1" in that mode, so it should work. But typically, you initially just set to '1' the bits corresponding to the pins you want to use as outputs in SWACNT, then you control the output value by only writing to SWCHA. So, to return them to 5v, while leaving the pins in output mode, you can write #%00010001 to SWCHA. I think there are differences in how much current you can source from the pins when in input mode compared to output mode, but I'm not expert here, and it might not matter for your application, anyway.
  7. The screenshots posted above show a NTSC version of "Pitfall II" running on a PAL console. You'll never get correct colors with that combination (unless you install the RGB mod, which bypasses the 2600 color generation and allows to switch between NTSC and PAL palettes). You need to use PAL games.
  8. All of this is is just "to the best of my knowledge", and mostly comes from reading about this subject in audio/electronics forums. I am by no means an expert. The fact that one channel is physically shorted just comes from the design of the connectors: when you insert a mono plug in a stereo jack, the two contacts in the socket intended to connect to the "ring" (left channel) and "sleeve" (ground) of a stereo plug, will instead both make contact with the single longer "sleeve" of the mono plug, causing them to be shorted together. As to whether this is an issue for the audio source, most articles and discussions that I read state that usually this isn't a problem (and as you say, the devices can even detect it and automatically switch to mono output), but also that there are exceptions such as some older equipment, or simply badly designed ones (those always exist) that can potentially be damaged. So to be safe you should first ensure that the specific audio equipment you're using can accept a mono connector (assuming this is documented somewhere). The adapter just avoids the shorting to happen in the first place, so you don't have to worry about it. A couple of links from a quick search: https://www.majorcom.fr/web/en/569-le-cablage-electronique.php https://forums.radioreference.com/threads/icom-external-speaker-jack.224792/#post-1635976 http://escortradarforum.com/forums/showthread.php?p=89940#post89940
  9. Sure, the Supercharger will load the games just fine when connecting it to a stereo device. That's not the issue. The reason to use an adapter is to prevent damage of the audio equipment. In fact, if you connect a mono plug into a stereo jack, the right channel output of the audio equipment gets shorted to ground. Some devices are designed to cope with the shorting of one channel, but others are not. By using a simple adapterr you don't have to worry about it. Mine is just a stereo plug connected to an inline mono socket; only the left channel and ground are wired between the two, while the right channel of the plug is left unconnected.
  10. If I'm understanding correctly the "F8" pld source code from the page you linked, pin 26 (not connected on a 2764, address A13 on a 27128 and 27256) is always low, while pin 27 (/PGM on a 2764 and 27128, A14 on a 27256) is always high. Which means that if you're using a 27256 for a F8 game, the rom must be burned starting from address 4000 (hex value). So you'll have 16k of unused space, then the 8k rom, then another 8k of unused space.
  11. I guess it went unnoticed as the TF version also works with a joystick and so the non-TF version didn't get much testing. Remove the "lsr" at line 716, and replace the value #$07 with #$0e in the 2 following instructions. lda SWCHA ;4 ; lsr ;2 removed and #$0e ;2 was "and #$07" eor #$0e ;2 was "eor #$07" bne LF270 ;2³
  12. I like Exidy's Circus, an hack of "Circus Atari": 256(!) variations, including simultaneous 2 player modes, where the second player moves a barrier to defend the balloons. (check the instructions included in the zip file in the first post for the huge game select matrix). Unfortunately there are some glitches in the title screen. (13 years ago 2600 emulators weren't as accurate as they are now). Here's my attempt to fix the issues (hopefully I didn't break anything in the process...) Exidy_Circus_VSYNC_fix.zip
  13. With RGB, the color information is not encoded using PAL (or NTSC, or SECAM), so by definition it can't show PAL color loss (RGB is not PAL!). Chances are that it won't show the issue even when using the built in composite or S-video outputs of the RGB mod (assuming you had connectors installed for those signals), because that mod completely bypasses the TIA color generation circuit. PAL color loss with an odd number of scanlines is the result of how PAL TIA generates the signal. For example, the PAL Atari 7800, in 7800 mode, always outputs 313 scanlines and displays colors just fine, because it's using the MARIA chip color generation in that case and not the TIA. The issue only shows with a PAL 2600 if using stock RF, or a composite / S-video mod that still uses the TIA color circuit (the RGB mod is the only mod I'm aware of that uses its own color generation). Note finally that not all TVs will show the color loss. Some more recent CRTs display wrong colors in the top area of the screen instead, and digital TVs might not show the issue at all.
  14. I'm very saddened to hear this. RIP Nukey.
  15. Those boards swap around the data and address signals going to the eprom, and therefore the rom programmed in there has to be "scrambled" in such a way that will appear correct when read from the cartridge port. Both the bits in each byte as well as the order of the bytes has been altered. That's why they are so different (and why they don't work in an emulator), if you dump them directly from the chips. Here are the roms rearranged to match what the CPU in the Atari would actually see when those carts are plugged in (and this is what you would get by using a cartridge dumper). These can be run on emulators, flashcarts or burned on standard carts. Mr._DO.binKangaroo.bin Only a few bytes differ between these and the original NTSC roms.
  16. Wow. Was the intent of quoting those posts to encourage a discussion? The only result for me is that I will immediately put that idiot @Kitrinxon ignore, as well as this thread.
  17. Nope. The consoles are fine. I linked to a technincal article explaining what's going on in one of my previous posts.
  18. Not at all. Your new retrothink doesn't have any bug, and the issues you're having is because of the signal that the VCS is outputting (and not because of the aging components, but because of its design). It is advertised that some console with out-the spec signal might not work correctly. And the VCS is the worst in this area, because it's up to the games themselves to generate the video signal, so you can have different results based on the specific game. On the other hand, the new CC game has bugs in it. The consoles that show the bug are working just fine. I seriously will NEVER believe that they didn't use Stella, anyway that's not an excuse. You can find those bugs with little effort even without Stella. The PAL color loss just requires.... a PAL console and TV. The rabbit bug can be found by writing a script that checks the list file generated by the assembler (you could do that in the 80s, too), or by installing 8 resistors with a switch that connects them to either GND and +5V on the console data bus. If the game has the bug, it will fail with the switches in one (or both) of the positions. (Switches and resistors existed in the 80s) Yep, in response of your post. Like I said, NO ONE ever talked about that before your post. You brought up that subject. I mean, that's a fact, there's nothing to argue about. The posts are there, just read them yourself.
  19. I can't believe I'm agreeing with you on something, but I'm agreeing with you. I 100% agree with this too. But, this is not happening in this thread. In fact the post you quoted is the first one bringing up the subject of "instant response" customer service. No one talked about that before.
  20. The retrothink incompatibilities due to out of specs signals produced by different consoles isn't really related with what's being discussed here. The two reported issues with the game are not the result of machines that are out of specs because of aging, but they're instead bugs in the code. The bug is still there even on machines where apparently doesn't show up (and even if it doesn't show up today on a particular machine, it could tomorrow). If you re-read the previous posts, no-one was expecting a 0-day response. The issue with the loss of color in PAL consoles has been reported a month ago, and so far only got an indirect response with a post basically saying "Yeah, there's a bug, but it's only showing on PAL, so it's not a big deal". I'm pretty sure people in Europe paid the same amount for the game and are entitled to feel a bit upset. And the comparison with how similar issues are handled by AtariAge came up naturally.
  21. They're not compatible, and it's better not trying to plug them into an Atari, as Power and Gnd are on different pins and you risk shorting something. http://wiki.icomp.de/wiki/DE-9_Paddle
  22. Try fine tuning the TV channel frequency, if doesn't help try also tuning the other channel by flipping the switch on the consoles. Re-flashing the firmware won't serve any purpose in this case.
  23. Yes, it's reading a TIA register instead of the immediate value, but the TIA only drives 2 bits, and the value of the other 6 is undetermined. Many old games have this kind of bug and will glitch in Stella in developer mode, but only very rarely on real hardware. Apparently eproms are more likely to affect the undriven bits than the mask roms used in original games, so in this case the bug shows up more frequently also on real hardware. It is a bug in the game anyway, not an issue with the consoles themselves.
  24. For those who also own the digital download, does the glitch happen in Stella with the developer options on? (In particular, with "Drive unused TIA pins randomly on a read/peek")
  • Create New...