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.

I don't think so. the game dissassembly should privde enough guidence here. Ex. does it read from the collision registers or not. 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.

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.

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.

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!

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

Very impressive game. I downloaded it to give it a try, but I think there is a small glitch in the HUD. 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.

Ah ok thanks for the info. It seems strange that they would release a game with such an obvious bug, but if that is the case then so be it. At least I know I don't need to try to 'fix' it.

Hi, I noticed this really obvious tow line glitch occur in both my emulator and the newly released A7800 emulator. 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!

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!

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.

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.

Thank you Trebor, I appreciate that capture video immensely. :thumbsup: Thanks to RevEng as well for the A7800 Software Guide and the research in this thread, which has already saved me many headaches.

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

I mean the test ROM by RevEng in the opening post. I don't see any results from hardware, so I am wondering if any are available or could be done.