Jump to content

alex_79

Members
  • Content Count

    1,596
  • Joined

  • Last visited

Posts 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. On 11/24/2021 at 11:54 AM, alex_79 said:

    [...] the known dumps have 255 extra bytes at the end of the file ($2800 to $28fe).

    What are those for?

    I found the answer in this old thread:

    On 10/6/2003 at 3:06 PM, Eckhard Stolberg said:

    The 10K version of the Pitfall 2 ROM contains 8K of program code, 2K of graphics data for the sprites, and 256 bytes with all the values for the random number generator. The random number generator could be emulated with a formula if needed, so those 256 bytes aren't really nessessary. But the 2K of graphics data get read from the DPC chip. Without it Pitfall 2 will only have garbled sprites.

    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.

     

     

     

    • Like 1

  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).

    diff.thumb.png.68667c3b9c225fa83a72f3114f5ea08d.png
    What are those for?
    At first glance, they are all the values from $00 to $fe in random order without repetitions.

     

     


  4. 16 hours ago, flickertail said:

    ... pin 7 power will only flow to the motor if either the pin 1 or pin 2 is pulled low (I don't know if I'm using the proper terminology - if the pin drops to 0V), and thus, when playing existing games, the joystick would act as originally intended as the power to the motor will always be off.

    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!

     

    • Like 2

  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.

     

    • Like 1
    • Thanks 1

  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.

    plugs.png.f86ad317fc35c7959816aa670c158715.png

     

    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

    Quote

     

    [...]

    If a mono TS plug is inserted into three-conductor stereo TRS socket, the result is that the right channel (ring) of the socket is grounded. The signal from the right channel will be lost. If the grounding of the right channel short circuits the right channel of the amplifier, this could damage the amplifier.

     

     

    https://forums.radioreference.com/threads/icom-external-speaker-jack.224792/#post-1635976

    Quote

    Stereo plug into a mono jack is alright, but a mono plug into a stereo jack will short the ring (middle band) to ground, which will short one of the stereo channels to ground

     

    http://escortradarforum.com/forums/showthread.php?p=89940#post89940

    Quote

    It is not physically possible for a stereo plug to short out anything or cause damage when plugged into a mono jack, no matter what the product is. It simply cannot happen.
    [...]
    However, a mono plug into a stereo jack (the opposite) can cause a problem because it can short out two pins, but most products are designed to handle that.

     

     

     

    • Like 1

  9. 12 hours ago, Superkitten said:

    I've never found stereo vs mono to be an issue:  A mono cassette will just output the same thing into left and right speakers, so if youre reading only one channel, that's fine - there is no "blank" channel being played that you might accidentally jack into - it does not work that way.

    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.

    • Like 1

  10. 52 minutes ago, SkalTura said:

    Now I just programmed the 27C256 with 1 time Ms.Pacman, and filled the blank space with "FF", just like I would do on any other Eproms.

    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.

    pldcode.thumb.png.8e6790194d7dd9c36b01d8027a2a626c.pngf8schem.thumb.png.1a048d45af960c9fa2cb002a4e7ef007.png

     

    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.

     

    • Like 2

  11. 4 hours ago, Al_Nafuur said:

    I compiled the source code and it looks like the non Track & Field version (TF = 0 ) doesn't work correctly. I can't fire from the right base (tested on stella and on my 2600 PAL hardware with PlusCart)

    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³
     

     

     

    • Thanks 1

  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

    • Thanks 1

  13. 4 hours ago, SavyIsJoshoArts said:

    this is showing on a PAL Atari 2600Jr that is RGB modded using Tim Worthington's 2600RGB kit.

    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.

     

    • Like 3

  14. 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.

    a26_mex_board.thumb.jpeg.61a47b701aa83b451a5a1e5635ec06fc.jpegeprom.thumb.png.8c09dde4d706f59c34117994422bf05a.png


    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.

     

    • Like 3

  15. Just now, John Stamos Mullet said:

    I mean - if there are consoles that play the game without showing the bug (like mine) - does that mean they aren't working fine because they DON'T have a problem?

     

    I realize the bug can be fixed in code, so it's clearly a game bug - but if it only is a problem on certain consoles, and not across the board - that would seem to be a buggy console revision, and not the other way around.

    Nope. The consoles are fine.

    I linked to a technincal article explaining what's going on in one of my previous posts.


  16. 1 hour ago, John Stamos Mullet said:

    They are related in the sense that they are both bugs that happen in old tech, because these small hobbyist projects aren't perfect, don't have giant corporate product testing, and they cannot possibly account for every single possible bug scenario, and also deliver a product that meets the insanely entitled delivery demands of the typical consumers of these products.

     

    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.

    37 minutes ago, John Stamos Mullet said:

    From everything I've read - Crane and Kitchen didn't use any modern development tools, such as Stella, and instead coded using their original dev platforms to keep everything authentic.

     

    Maybe they should have used Stella, sure. But they didn't.

    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)

    1 hour ago, John Stamos Mullet said:

    It absolutely happened because that's exactly what Keatah said to me, directly. I even quoted him. You and others may disagree, but it was definitely said.

    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.


  17. 1 hour ago, Tempest said:
    10 hours ago, John Stamos Mullet said:

    The internet has absolutely spoiled people into thinking they are entitled to instant gratification for every minor consumer gripe or dislike.

    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.

    • Like 1

  18. 1 hour ago, John Stamos Mullet said:

    For example: I recently bought a Retrotink 2x mini to connect my old consoles to my HDMI-only TV. It makes the s-video modded 7800 I have look beautiful on it. What I found out later was that some Atari games don't work on it at all - like Starmaster because of the scanline count. and The entire Sega 32x Console is unstable and mostly unplayable due to the out of spec chroma signal it outputs/

     

    You know what I did about it?

     

    Nothing.

     

    Because it's a 30 year old console, and these kinds of technical issue are unavoidable with ancient tech, and I didn't read up enough about it before purchasing.

     

    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).

     

     

    1 hour ago, John Stamos Mullet said:

    So do the purchasers of Circus Convoy whose copies don't work deserve a refund or a working exchange? Sure, absolutely.

     

    Are then entitled to a response within a "0 day" window? Absolutely not, under any circumstances. That's flat out bananas entitlement.

    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.

     

     

    • Like 1

  19. 33 minutes ago, Dionoid said:

    I think this indicates a bug where a memory address is read instead of an immediate value?

    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.

    • Like 2
×
×
  • Create New...