Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

AlyoshaTAS

New Members
 View Profile  See their activity

  • Content Count

    26

  • Joined

  • Last visited

Posts posted by AlyoshaTAS

  1. Posted · Edited by AlyoshaTAS

    Hi,

     

    So I recently ran into this game on emulator and it kept resetting on me. I decided to figure out why, and it turns out the reason is because of the upper RAM mirroring at $2800 that apparently doesn't exist on hardware.

     

    (In particular, when the game is processing enemies, it overwrites display variables when this mirroring domain exists in the emulator. The particular address that causes the reset is $53.)

     

    After removing this mirrored domain from my emulator it now runs just fine.

     

    I hope this information is helpful to anyone in the future who is having trouble with this particular game.

  2. Posted · Edited by AlyoshaTAS

     

    Wouldn't a more complete model be required in order to know that it's not more complicated? Sounds like a self fulfilling prophecy to me.

     

    I don't think so. the game dissassembly should privde enough guidence here. Ex. does it read from the collision registers or not.

     

    It's just more BS cause Todd, while an amazing gamer, has multiple impossible records tarnishing his otherwise great gaming feats. It's like the uber baseball player who uses steroids even though they are already of the best in the world.

     

    The reason I'm skeptical of outright lies is that it would very difficult in some of these cases to know what time to pick if it were just a lie. Maybe not so much for Dragster, but certainly for Barn Storming or Grand Prix.

  3. Posted

     

    I'm just being devils advocate here. We are all still learning about the quirks of the system, and a year from now will probably still be learning new things. Maybe this has nothing to do with this ROM and highscore, but it can't just be discounted just because we haven't discovered it so far.

     

    I think one of the interesting things about Dragster in this regard is how little of the A2600 it needs to work. If it didn't need to read the controller, it could be run exclusively from the CPU in the exact same way (minus the time spent in !RDY.) Many other games at least use the collision detection in the TIA, but nope Dragster can do without it. I think it's this simplicity that lends a lot of weight to Omnigamer's analysis, the game cares very little about the world outside of the 6507. If it were more complicated I might be one of the people calling for a more complete model, but there really doesn't seem to be any need in this particular case.

     

    Aside from that, my money is on prototype cart. Another record given to Todd Rogers is for Grand Prix, and that time certainly appears impossible, but would be a proper time if some of the car mechanics that slowed it down weren't in place at the time, i.e. a prototype, like the BarnStorming one was.

  4. Posted

    I didn't realize a formal challenge was made on this, thanks for making this thread.

     

    I think Omnigamer's work is pretty thorough, and with thomas Jentzsch reaching the same conclusion I don't think there are really any open ends here.

     

    But now there will be some kind of live event? That's an interesting result.

     

    I'll be interested to see what comes from all of this.

  5. Posted · Edited by AlyoshaTAS

    Ok I took another look. I was wrong, what I'm seeing is the midscanline change in read mode when writing to the CTRL register:

    552F:  A9  LDA #$58        A:CB X:00 Y:00 P:27 SP:F5 Cy:25054346 nvTbdIZC
5531:  85  STA $3C         A:58 X:00 Y:00 P:25 SP:F5 Cy:25054348 nvTbdIzC

    So, if this doesn't show up on hardware, then I guess read mode is latched at the time the first pixel is rendered and kept for the entire scanline (unlike background color which is known to be able to change at any time.)

     

    Good to know! (and sorry for the confusion)

     

    Also cool game! :)

    • Like 2

  6. Posted · Edited by AlyoshaTAS

    Hi Smitty..

    to check it out...i Need an actual Version....all Versions....i got here work fine for me on real Hardware.

    greetings Walter

    I tested with the version attached to post # 130. So if that one displays correctly on hardware then i guess we've got an answer.

     

    I don't see how it could though, the game is pretty clearly changing background color midscanline:

    5542:  85  STA $24         A:60 X:01 Y:00 P:25 SP:F5 Cy:11143343 nvTbdIzC
5544:  A2  LDX #$01        A:60 X:01 Y:00 P:25 SP:F5 Cy:11143358 nvTbdIzC
5546:  A0  LDY #$38        A:60 X:01 Y:00 P:25 SP:F5 Cy:11143360 nvTbdIzC
5548:  AD  LDA $22B0       A:60 X:01 Y:38 P:25 SP:F5 Cy:11143362 nvTbdIzC
554B:  85  STA $20         A:92 X:01 Y:38 P:A5 SP:F5 Cy:11143433 NvTbdIzC
554D:  85  STA $24         A:92 X:01 Y:38 P:A5 SP:F5 Cy:11143436 NvTbdIzC
554F:  88  DEY             A:92 X:01 Y:38 P:A5 SP:F5 Cy:11143471 NvTbdIzC

    Swapping the order of STA $20 and STA $24 would prevent this from happening.... but if it's already not happening on hardware then I'm stumped.

     

    EDIT: are the .bin and .a78 different versions? They appear slightly different in hex editor

  7. Posted · Edited by AlyoshaTAS

    Very impressive game. I downloaded it to give it a try, but I think there is a small glitch in the HUD.

     

    game.png

     

    The bottom line of the HUD border is half cut off (I tested both NTSC and PAL just to be sure and got the same result.) BizHawk (the emulator used to capture this image) allows midscanline register changes in MARIA, so you can see effects like this that don't show up in MAME. I'm pretty sure BizHawk is correct here as it also correctly displays the midscanline tests in RevEng's test ROM.

     

    Of course maybe the emulator is wrong, but it would be nice to know for sure if someone can confirm on hardware.

    • Like 2

  9. Posted

    Hi,

     

    I noticed this really obvious tow line glitch occur in both my emulator and the newly released A7800 emulator.

     

    34y1rn8.png

     

    But, I can't determine anything that is wrong with emulation that would cause it.

     

    So I am wondering if maybe this occurs on real hardware as well? If anyone has this game and might be willing to confirm if this glitch happens on console I would be appreciative.

     

    Or, if this is already a known glitch and there is a reference as to what is happening that would be helpful too.

     

    Thanks!

  10. Posted

    Cool! I always had trouble using Mame but this stand alone one seems to work just fine.

     

    One usability critique though. Ctrl+alt+direction-arrow defauls to screen rotation on windows 10 (at least on my laptop), so it might be a better idea to default the 2 buttons on the proline controller to something else. (I found this out the hard way :) )

     

    Also, for your test rom, the RIOT timer tests are coming up a little short, I had this problem too, turns out the RIOT timer ticks also get slowed down during TIA access just like the CPU (which would make sense if they run off the same clock.) If you make this adjustment the tests will come out perfect.

     

    Anyway nice work!

    • Like 4

  11. Posted

    Here is another useful bit of information I learned while developing my emulator that helps clarify the software guide.

     

    DMA reads DO incur a penalty for the first read that would take place in a hole. This makes sense actually, since the DMA unit cannot know if it is in a DMA hole before it does the first read. Subsequent reads in the same header do not incur a penalty.

     

    This makes both DMA hole tests in RevEng's test ROM work correctly, and also fixes the incredibly precise water effect in the sewer level of Scrapyard Dog.

    • Like 2

  12. Posted

    This guide is really good, it has helped me a lot in developing my emulator. I thought I might mention a few things and post some information that I did not find anywhere else.

     

    First, there is a small error on page 10. In the CTRL register, CW bit should be 1 = two byte characters and 0 = single byte characters.

     

    Also, mostly of interest to emulator authors, here is some information on line RAM that I deduced from the display modes. I think it helps clarify what Maria is actually doing.

     

    Line RAM is 320 bytes of data that makes up a scanline (probably implemented in silicon as only 5 bits since that's all that's used.)

     

    Given a graphics byte G=[G7, G6, G5, G4, G3, G2, G1, G0], and palette entry P = [P2, P1, P0], line RAM is written to depending on the 'write mode' flag.

     

    if 'write mode' is true, 4 consecutive bytes are written (starting at the appropriate position given by the header.) They are:

    [0, 0, 0, P2, G3, G2, G7, G6]

    [0, 0, 0, P2, G3, G2, G7, G6]

    [0, 0, 0, P2, G1, G0, G5, G4]

    [0, 0, 0, P2, G1, G0, G5, G4]

     

    if 'write mode' is false, 8 bytes are written in the following form:

    [0, 0, 0, P2, P1, P0, G7, G6]

    [0, 0, 0, P2, P1, P0, G7, G6]

    [0, 0, 0, P2, P1, P0, G5, G4]

    [0, 0, 0, P2, P1, P0, G5, G4]

    [0, 0, 0, P2, P1, P0, G3, G2]

    [0, 0, 0, P2, P1, P0, G3, G2]

    [0, 0, 0, P2, P1, P0, G1, G0]

    [0, 0, 0, P2, P1, P0, G1, G0]

     

    NOTE: A byte is only written to line RAM if the value & 3 does not equal zero. If it does equal zero, it is transparent and therefore not written (or if kangaroo mode is active, written with 0x00). With this you can see why transparency doesn't work in some of the 320 modes.

     

    The benefit of knowing this is that the 'read modes' now become very simple to understand.

    Consider a byte of line RAM given by D = [0, 0, 0, D4, D3, D2, D1, D0]

     

    'Read Mode 0' just reads the line RAM data directly, can't get simpler then that!

     

    'Read Mode 2' reads depending on whether a pixel is even or odd

    If it is even, the color you get is [0, 0, 0, D4, 0, 0, D1, D3]

    If it is odd, then the color becomes:[0, 0, 0, D4, 0, 0, D0, D2]

     

    'Read Mode 3' also depends on whether a pixel is even or odd

    If it is even, the color you get is [0, 0, 0, D4, D3, D2, D1, 0]

    If it is odd, then the color becomes [0, 0, 0, D4, D3, D2, D0, 0]

     

    NOTE: This even/odd operation works because you can only place objects at 160 scale precision.

     

    I think this clearly illustrates how Maria works internally, and provides a simpler explanation of display modes then what is in the guide. Anyway I hope it's useful. it certainly helped me make my emulator code much cleaner.

    • Like 3

  14. Posted

    @RevEng: Yes it does support midscanline color changes.

     

    @SoundGammon: The timer is too fast but the players move at the correct speed. The emulator is BizHawk from TASVideos.org, I am making a new core to replace EMU7800, so I am aiming for accuracy.

    • Like 3

  16. Posted

    Hi,

     

    I am making an A7800 emulator, and I am wondering if there are pictorial results from a real console for the tests in the opening post of this thread.

     

    So far I have all the DMA logic implemented and everything works correctly, including all the typical troublemakers like Xenophobe, Kung Fu Master, and top line of Centipede.

    But, when I run these tests the marker doesn't quite reach to where it is supposed to, and I don't know exactly what the results of tests 6 and 13 should be.

     

    Any help is appreciated!

  18. Posted

    Hello again,

     

    I have a question about how the PSG is clocked.

     

    My emulator currently has the PSG working, and it sounds correct. It passes the MTE201 test cart and the sounds are correct compared to what I hear from youtube as well as other emulators. Game sounds all sound correct.

     

    But in order to achieve that, I have to only clock the PSG during the visible part of the frame. Is this correct?

    It doesn't quite make sense to me that this would be the case, but anything else I try sounds way off, and doing it that way sounds perfect.

     

    I see that the chips enable pin is tied to the System ROM chip somehow, are these things related? Is there something I'm missing?

     

    I appreciate any insight, thanks!

     

     

     

     

  21. Posted

    The emulator is BizHawk, TASVIdeos.org's in house emulator, it's mainly for Windows.

     

    Thanks for the advice, I tested Defender, Centipede and Dig Dug and all 3 worked without errors. Looked, sounded and played fine.

     

    I tried Ms Pac-Man and it crashed with random garbage on the screen. Something I should be looking for there?

  22. Posted

    Hello!

     

    I am working on an Intellvision Emulator. It is quite far along, to the point where almost all games look, play, and sound correct. However I am stuck on one game and can't seem to find what I'm doing wrong. Pac Man is the game, and it loads and plays fine except that pac man passes right through the ghosts most of the time. The collision detection itself doesn't seem to be the problem, as I can look at what collision bits are set when and they all are in order. Also every other game has functioning collision.

     

    I must be missing some detail somewhere about what the game is doing but I don't know where to look. You do occasionally do get killed by the ghosts but it seems to happen randomly. Also I can collect pellets and fruits just fine.

     

    If anyone has any ideas on where I should be looking or what this game is doing I would be very grateful to hear them.

     

    Thank you!

  23. Posted

    Hi all,

     

    I am trying to figure out how the score in Kool Aid Man is positioned but I always come up 1 pixel short.

     

    The code is:

     

    STA HMOVE

    STA Colbrk

    STA CTRLPF

    LDA #$D0

    STA HMP0

    LDA #$20

    STA HMP1

    .

    .

    .

    RESP0

    RESP1

    .

    .

    .

    WSYNC

    HMOVE

    So I understand that the first part of the code cuases an effect similar to Cosmic Ark 'starfield effect', where one position clock is eaten up every 4 clocks during hblank and the HMove latches are never cleared.

    Next we get RESP0 , RESP1 right next to each other. So at this point the players are 9 pixels apart.

    Then we come to a normal WSYNC, HMOVE

    In the time it takes to register the HMOVE, the 'starfield effect' has moved player0 3 pixels to the left. The HMove itslef will have a net effect moving player0 3 pixels back to the right, and player1 2 pixels to the left.

    The net effect is that player0 and player1 are 7 pixels apart. But to display the score correctly they should be 8 pixels apart.

    So my question is, where does the extra pixel come from? I just can't seem to find it. If anyone could help me account for it I would definitely be grateful! (If it's just that the 'starfield effect' is 4 pixels instead of 3, an explanation of why would also be much appreciated.)

    Thanks for any insights!

  24. Posted

    Hello again, I have another question that I think is easy to answer but I can't really find a lot of documentation on.

     

    enam_zpsebiqrho5.png

     

    So here are 5 consecutive frames in FlapPing. On the fourth frame you can see the ball dip into Pterry's head, thus causing a collision and throwing it backwards.

     

    This isn't happening because the ball (technically it's missile1) is moving downwards though, it actually has a slight upward velocity at this point. It dips down because an ENAM write is happening at this exact spot, 1 pixel behind where the ball is on that fourth frame.

     

    So it looks like there is a 1 color clk delay here in processing the ENAM, but my question is what exactly is happening here hardware wise. Does it simply take 1 extra clock to process the enam after the write to it, or is there something more complicated happening?

     

    Thanks for any insight!

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...