Jump to content

alex_79

Members
  • Content Count

    1,596
  • Joined

  • Last visited

Everything posted by alex_79

  1. Seems to happen on certain consoles: https://atariage.com/forums/topic/318076-ex-activision-designers-launch-retro-game-publisher-audacity-games%E2%84%A2/?do=findComment&comment=4792815
  2. The extra button functionality is known to cause incompatibilities with some controllers (for example with trackballs), and/or some specific games. https://atariage.com/forums/topic/243453-atari-2600-trak-ball-games/?do=findComment&comment=4268750 https://atariage.com/forums/topic/317432-2600-jr-strange-joystick-behaviour-help-needed/ The Extra + Down combination would almost always exit emulation on the PlusCart, as it triggers Right + Reset.
  3. Double check using the attached pdf: see pages 31-32 for a descriptions of the pins, and the diagram on page 35 for the active state of the "chip select" pins. ColecoVision_Expansion_Module_1_Tech_Specs.pdf
  4. Good point, I assumed that only games that need to set it as output did that. Actually, I think there's no need for that: you can read back SWACNT/SWBCNT, so it doesn't really matter to know if it's a write or read operation: the data bus will in any case have the SWBCNT value. So, on any access to SWBCNT, just check the data bus, and if it's not 0 then disable the emulation exit function.
  5. It can see an access, while it cannot know if it's a write or read operation. Anyway there shouldn't be any reason for a game to access SWACNT / SWBCNT unless it's using the ports as output.
  6. What about this: As soon as there's an access to SWACNT or SWBCNT (and mirrors), then disable the emulation exit for the current game. This takes care of games that use the ports as outputs: you wouldn't be able to use the exit functions for those, but that's still better than unexpected exit. There's still the problem of controllers (e.g. trackballs) that can leave one input constantly low, but that could be solved by using a combination that only involves the console switches, like the previously proposed "long RESET press while SELECT is NOT pressed". In this case you don't even need to check SWACNT anymore.
  7. I think the problem might be that both games, in addition to reading the switches, perform several writes to SWCHB (because they have some unused bits set as output and use them as extra ram), and the value written has bit d0=0, according to the Stella debugger. To the Pluscart, this appears identical to a read from SWCHB with the RESET switch pressed, as it cannot differentiate a read operation from a write one. In both cases it sees SWCHB on the address bus followed by a value with bit d0=0 on the data bus, and there's no way to know if the latter comes from the RIOT (read) or the CPU (write).
  8. You can find a detailed explanation of sprite re-triggering behavior in Andrew Towers' "TIA Hardware Notes".
  9. The dumper described in this thread isn't exactly user friendly but might be of use for people who like to tinker a bit with hardware and software In its basic configuration, that involves hot-swapping cartridges and using the audio transfer method, it doesn't require custom hardware. You might need to play with the recording volume and sometimes to fine tune TV channel to get the best audio (which often doesn't correspond to the best video!) before it works reliably. If you want to try it out you need: - a working Atari 2600 - a TV with an audio output (e.g. a headphone jack) so that you can pick the audio signal from the console. An old VCR might be used too to convert rf into separate audio and video or, better yet, an A/V modded console which bypasses rf completely. - a suitable cable to connect between the audio output of your console/TV and your PC soundcard input. - an audio recording software on the PC - a programmable cartridge to run the dumper rom (e.g. Supercharger, Harmony cart, Unocart, etc.) Before attempting to dump the actual cart, you can test the software by making it dump itself. This doesn't involves swapping cartridges so it's perfectly safe. Other solutions: @SvOlli's ROM dumper https://atariage.com/forums/topic/305662-little-home-project-rom-dumper/ Retron 77 with latest community build installed (allows to save the dump on the SD cart, but compatibility of the r77 built-in dumper is low) https://github.com/DirtyHairy/r77-firmware-ng/releases/tag/stella-6.5.3 @Thomas Jentzsch's savekey dumper (it still requires to hot-swap cartridges, but saves the rom on a savekey) see here: https://atariage.com/forums/topic/297125-pursuit-of-the-pink-panther-rom-released/?do=findComment&comment=4368885 Atarimax cartridge + adapter https://atarimax.com/flashcart/documentation/chapter9.html Harmony cart + custom firmware and diy cable https://atariage.com/forums/topic/164988-harmony-as-a-copycart/
  10. Scramble auto detects if a Genesis controller is connected and, if so, it uses two independent buttons (B and C). Else it reverts to single button mode like in the Parker Brothers cart.
  11. It might be the result of the color trimmer adjustment in your console. Also the TV might make a difference (colors look a bit different on LCD TVs compared to old CRTs) Here are screenshots of a test rom showing the entire palette on another PAL-M console (the rom can be found in post #48 of that thread): https://atariage.com/forums/topic/254053-a-new-marauder/?do=findComment&comment=3548524 Could you try that on your console? Here is a service manual for PAL-M atari 2600 that includes the NTSC to PAL conversion circuit found on these consoles. Maybe some expert might determine if the conversion also causes some differences in the resulting colors. Manual_tecnico_Atari_2600-br.pdf
  12. An auto-responder seems plausible to me. "It could happen" is indeed the correct translation. And "È successo" in the subject line means "It happened".
  13. Today I stumbled across this article about an old Apple II Italian text adventure called "Un Marasma Galattico" by Piero Cavina. Many people here on AA will probably recognize that name as the author of "Oystron", one of the earliest homebrews for the 2600 (and still one of the best IMO), and the e-mail address in the "leggimi.txt" file included with the download matches the one in this page, confirming he was in fact the same person. Intrigued by this find, I clicked on the link to the related forum thread in the article. In the last post, a moderator replies to a user who asked if the author published other adventure games: Translation I'm very saddened to hear about Piero passing away. He wasn't an active member here anymore when I first joined AA back in 2006, so I never actually talked to him, but he was one of the early homebrewers that contributed to start this hobby and I enjoyed playing his games and reading his old posts in the Stella mailing list. My thoughts are with his family.
  14. As Thomas said, it has nothing to do with piracy protection and Audacity Games is not actively preventing the cart from working in non original console. The fact is simply that a modern replacement for an Atari 2600 is not available so far, so the original is the only option, if you want to play actual cartriges. You can buy a digital copy (rom) together with the cart, and you can play that on the Retron 77.
  15. BTW, here is an example of an original cart misbehaving on a stock console (a 7800 in this case) because of this kind of bug.
  16. Most consoles will work very consistently, so you'll basically never notice the bug. Many original games have this sort of bug (because of a missing "#" in front of a constant in the source code, which cause an access to a TIA register instead of an immediate load) and they'll glitch if you enable that developer option in Stella (that's why it's disabled by default in "player" mode). But some consoles, or some combination of consoles and cartridges (e.g. when using some specific brand of eproms), will cause some pins to be consistently driven high or low. You'll not find any real hardware behaving exactly like the "drive unused TIA pins" option does in Stella, with all the bits perfectly random on every read. The purpose of that option is to make bugs more evident so that you can correct them early during development, rather than simulating a real world behavior.
  17. That was a bug that was fixed a while ago. Download an updated version of Stella.
  18. That's not how the "Drive unused TIA pins..." should behave, and it's not how it works for me. Do you have an up to date Stella version (6.5.3 has just been released)? And did you reload the rom after changing the setting? The TIA only drives bit 7 and 6. If the register don't use one of those two bits, it will read as 0 (e.g. CXBLPF only uses bit 7, bit 6 will always result as 0). Bits 5 to 0 are undriven and their value must not relied upon. On most consoles those bits usually keep the last value they were driven with, and that's what Stella emulates if the "Drive unused TIA pins.." option is disabled. e.g. with lda CXM1P the last value that appeared on the data bus before reading the register is the address $01 If you access the same register with the instruction lda CXM0P,x with x=1, the last value on the bus is $00, while using e.g. lda $FF,x with x=2, the last value on the bus is $FF (so bits 5 to 0 will usually be all "1" in this case. If you're coding for the 2600, keep the developers' settings enabled in Stella.
  19. I guess all cartridges have tri-state data pins, else there would be bus contention every time the VCS accesses TIA, RAM and I/O registers, which are mapped to the low 4k of the memory area (A12 low).
  20. Switching off power to a cartridge while still having it connected to the address and data bus is BAD. Don't do that! The correct way to is to switch the "chip select" pin (which on the VCS is connected to CPU address A12). CPU A12 should be connected only to the "selected" cartridge, while the corresponding pin on the "deselected" one must be tied to GND. So you need a DPDT switch. See here: https://atariage.com/forums/topic/164987-modify-your-video-game-brain/
  21. To get an idea on why there's such a limitation, here is a (oversimplified and not accurate 😄) description of how TIA handles sprite positioning: Each sprite has its own position counter, which runs only during the visible part of the scanline (for 160 TIA cycles, from 68 to 228), while it's "paused" during HBlank (TIA cycles 0 to 67). When the counter wraps around, the corresponding sprite is drawn, and the counter takes exactly 160 TIA clocks to wrap around, so the sprite normally appears in the same position on every scanline. Strobing RESxx immediately resets the position counter, making the current position the "new" one for the sprite from now on. HMOVE is different, as it doesn't change the position counter immediately to a new value, but instead sends extra clock pulses (up to 15 of them) to the counter, one every 4 TIA cycles (or 1.33 CPU cycles). The problem is that if those extra pulses occur in the visible part of the scanline, the interaction with the "normal" pulses to the position counter produces unpredictable results, which differ between different consoles, and even on the same console (e.g. depending on temperature). The only way to have reliable results is to send those extra pulses when the "normal" ones are not occurring, that is during the Horizontal Blank. This is why you can't move more pixels per scanline: there's no time to reliably feed more pulses to the counters. This is also the reason for the HMOVE timing limitation: only strobing the register at CPU cycle 73 to 3 ensures that you have enough time during HBLANK for all the possible 15 pulses to the position counters. HMOVE strobes that occurs later than cycle 3, but still in HBLANK can only be used for certain HMxx values, corresponding to fewer pulses, but that's not very useful in practice (To know how many pulses correspond to a HMxx value, invert bit 7 and take the high nybble. E.g. a HMxx value of "$70" produces 15 pulses, while "$80" results in no pulses). Finally, that's where the "do not mess with the position registers for 24 cycles after HMOVE" in the Stella guide comes from: you should ensure that HMOVE operations are completed before altering the registers, else you won't get the intended results.
  22. All 3 work fine on my 14" HITACHI CRT, using a Light sixer through RF. I tried several QR codes with each rom. I kept the TV settings I normally use (Contrast ~50%, Brightness ~25%, Color ~50%)
  23. Here is another test rom for "score mode": And in this post @supercat gives a more technical explanation about how it works:
×
×
  • Create New...