Jump to content

alex_79

Members
  • Content Count

    1,613
  • Joined

  • Last visited

Everything posted by alex_79

  1. 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.
  2. Might be worth trying the solution described in this (ancient!) thread: https://atariage.com/forums/topic/26719-help-with-7800-pal-composite-mod/
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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:
  9. I'm not sure either...😄 I just found a bit odd at first to see "sbc $1f" on the disassembled line and "e5 0f" in the corresponding byte sequence. Never had that feeling when a register name is shown instead of the address. e.g "lda INPT0" might correspond to "a9 08" as well as "a9 18" But it makes sense now that I thought a bit more about it, and I'm fine with the current behaviour.
  10. It works fine if you set paddles manually in current Stella (6.2). Anyway, there's a bug that cause the paddle to jitter badly if you enable the developer options, and in particular "Drive unused TIA pins ..." This typically indicates a missing "#" in front of a constant in the source code, and it's the case here too: In bank 1, address $f1d5 there's a "sbc $0f"* that was obviously intended to be "sbc #$0f". Changing the opcode at that address from $e5 to $e9 fixes the problems. Note that the disassembly in the debugger actually shows "sbc $1f" at that line before the fix. I guess it has to do with the fact that $1f is a mirror of $0f (for read accesses). @Thomas Jentzsch (I think this part of the stella code is your area), maybe it should show the actual value in this case, as there's no read register defined at that address?
  11. I played a bit with it (despite the fact that my old PC can't run it at full speed) and it keeps getting better. The overlays are very effective, and it's interesting watching the game running with those enabled. The mouse tooltips showing the line of code corresponding to the screen area you're pointing to (with correct variable names if you have a dasm sym file alongside the rom) are a nice touch. I like the UI with separate windows that can be independently moved and resized, and how each window is layed out (e.g. in the TIA window, I find useful the little dot that indicates the pixel of the gfx register corresponding to the current cycle). Keep up the great work!
  12. It is my understanding that, with the RGB mod installed, the TIA is not directly connected to the 2600 address and data bus anymore. When a write to a TIA address occurs, the RGB board sees it, it checks if it's a write to one of the 5 color registers and in that case, it records the value internally (to associate that color register to a RGB color of the current selected palette), then replaces it with a standard value that uses an unique pattern for the 3 luma bits for each color register, and finally performs the write to the TIA. In that way, the RGB board knows what color is supposed to generate just by looking at the luma pins of the TIA, and bypasses the TIA internal color generation entirely (this also makes possible to have different palettes and play games made for a different TV standard with correct colors). This process inevitably introduces a little lag, and I guess that depending on the tolerance of the specific TIA or console, in some cases this might result in the TIA color/gfx registers to be updated a full color clock later than normal and cause those glitches. It might be worth testing with a different TIA after the new mod is installed, to see if it makes any difference.
  13. The wiring for the joystick extra button cause problems with some controllers (notably, trackballs and mice) or when using the left port as output. A workaround is to install a switch to disable the extra button functionality when you're using an incompatible controller. The existing "palette switch" can be used to pause a game instead of the extra button.
  14. It's by @SeaGtGruff: https://atariage.com/forums/topic/149228-a-simple-display-timing-diagram/?do=findComment&comment=1820187
  15. Yes, the separate roms are only useful for some older flashcarts. The exception is "Party Mix": that's not a multiload game, but actually three separate games. So, only for that one, keep the separate files and delete the combined rom.
  16. Since you're talking about "channel 1", and that channel was discontinued in most of Europe in the 50's, I guess you're confusing the the term "channel" intended as frequency allocated for TV broadcast transmission, with the "presets" on your TV or VCR (that is, the "numbers" on the remote, which can be individually programmed to any channel). Your console is probably fine. The PAL-B Atari 2600 outputs on channel VHF 3 and 4 (despite what it's stamped on the case, which is in common with the US models). Power on the console with a cart plugged in and do a channel scan on your TV/VCR (refer to your device instructions to do that) until the image appear. Then save the channel on a preset number. Do not mess around with the variable inductor, unless you know what you're doing. The ferrite core inside it is very brittle and it's easy to break it while trying to adjust it, especially if you use a metal tool.
  17. If you set the cart type to "4k" in the PC version of Stella, the behaviour matches what @Charlie_ is describing: only the upper part of the screen is rendered, and the the music play faster (frame rate is over 70fps). So maybe the r77 dumper is failing to detect the cart type correctly and provides a bad rom to Stella. Is it possible to enable the "console info overlay" in the r77 port of Stella, to check what size is the rom from the dumper?
  18. The hardware is identical, only the bios rom is different. You can use a NTSC supercharger with a PAL console. The loading screen will be displayed at 60Hz (PAL60), and the colors will be different (only in the loading screen). In Europe, most TVs since the 90s support PAL60 without problems. If your TV cannot handle the 60Hz display, the screen might roll, but you will still be able to load the game properly. Once the game is loaded, the TV format of the Supercharger doesn't matter anymore. Just ensure to load the PAL version of the game you want to play and it will run just fine no matter if you're using a PAL or NTSC Supercharger I have a NTSC Supercharger too and I always used it with PAL consoles.
  19. You can in fact, (that's exactly what the jitter.bin test rom in the above post by Spiceware is doing) but as stated, it's not recommended, as there will be incompatibilities with TVs and monitors the more you diverge from the standard values of 50Hz or 60Hz. Moreover varying the scanline count during the game might cause the image to jitter, so that should be avoided too. The TIA automatically handles the horizontal sync, so the time it takes to draw a scanline is fixed, while the program controls the vertical sync, and by increasing or reducing the number of scanlines in a frame, you change the time it takes to draw a frame, and so the frequency (more scanlines, lower frequency, less scanlines, higher frequency). But, again, you shouldn't do that to adjust the speed, but use fractional math instead, as explained Thomas, karl G and Spiceware in the above posts
  20. Yes, on 4-switch models. AFAIK, jr. console don't have any cover on the switch hole. SECAM consoles have that plug, as the output channel is fixed there, too. Here's mine:
  21. That's definitely a NTSC console. I've seen a few pictures of NTSC units with that "PAL" sticker on the modulator, but it's unclear to me what it means.
  22. That's a standard PAL-I Atari 2600 (for U.K and Ireland markets). The presence of the switch depends on the PAL variant: All (6-switch, 4 switch, junior) PAL-I Atari 2600 output on channel UHF 36 and they do not have a channel switch All PAL-B Atari 2600 have the switch to set output on channel VHF 3 or 4
  23. The problem was the Y-cable: Y-cables can be used to split an audio signal in most cases, but they must never be used to mix 2 signals together. As you experienced, it won't work, and there's even the risk of damaging your equipment in doing so. You need a resistive network to achieve what you want, like explained in the page linked by @Nathan Strum a few posts above.
  24. Turns out it has, but apparently passed under the radar... This is from the "Kim-1/6502 User's notes" newsletter, issue 12 (July 1978). (Note tha the KIM-1 uses a 6530 RRIOT (Rom, Ram, I/O, Timer) and the timer part works the same as the 6532.) Note tha the proposed workaround is to write the timer twice, as suggested by @RevEng
  25. Unless that last instruction of the code jumps somewhere else, the cpu would continue reading the next instruction at the following address, that is $0100. But $0100 is a mirror of $00 in the VCS and that's in the area where TIA registers are mapped, so the program would interpret what it reads there (the collision registers) as code and would likely crash (or behave in an unintended way in any case)
×
×
  • Create New...