|
Post by dshadoff on Feb 8, 2020 15:06:17 GMT
Thanks turboxray. Any additional information is always helpful. As I said, I'm currently playing with the 6270 code in MiSTer FPGA, and while it's not bad, it's still got a bunch of little edge-case issues like this. I never spent too much time on the edge cases of the 6270, so I'm poking around in the dark, and learning. As an aside, a person on Twitter called @furrtek has decapped the 6270 which has a few rudimentary photos here: imgur.com/a/UPPIE1iI'm working on convincing him to get a full imaging of stitched-together snapshots so that some more of its secrets can be unlocked. (He has done this before for some NeoGeo chips.) Let me know if you want to join in on the decoding (I don't know how to interpret the images yet either, but I'm curious to learn).
|
|
|
Post by dshadoff on Feb 16, 2020 23:28:58 GMT
OK, so I've implemented the VBLANK interrupt and RCR interrupt at the right points, and fixed all the related off-by-one issues.
Since the existing code currently does its best to center the HDW on the screen by ignoring HDS, I had a bit of trouble working out the exact latch points for BYR and BXR; for best results I ended up using: BYR: relative to the beginning of HDW, SUBTRACT render pipeline length (something like 21 clocks there), and SUBTRACT again 6 VDC cycles. BXR: 1 clock later
-> elmer, did you say that CR needs to be latched as well ? If so, where relative to BYR/BXR ?
I found that if I didn't subtract that addiitonal 6 cycles, things would get flashy and Outrun's lane separation dotted lines ended up as duplicates. I'm not sure why that would be the case, but I suspect that properly calculating and using HDS is a better overall approach.
I also got the feeling that 21 clocks is a longer-than-actual hardware pipeline (which I am given the impression is only 16 cycles).
This fixed about half of the outstanding bug reports against the core, but a few remain (and it made Andre Panza boxing worse than before).
I'm kind of curious about what's going on with Wonder Momo (seems to be a duplicate RCR interrupt which is misinterpreted - probably interpreted as the wrong sequence).
Any comments to any of the thoughts above ?
|
|
|
Post by turboxray on Feb 16, 2020 23:48:14 GMT
I remember mednafen author had issues with Wonder Momo.
|
|
|
Post by elmer on Feb 17, 2020 3:03:15 GMT
-> elmer, did you say that CR needs to be latched as well ? If so, where relative to BYR/BXR ? Yes, I've tested it, and the Background Enable bit (and presumably the Sprite Enable bit) are shadowed/locked one cycle after BXR, so the order is BYR/BXR/CR all one-cycle after the other. Any comments to any of the thoughts above ? Unless I'm being a complete idiot, the critical thing is the number of CPU cycles between the RCR interrupt firing, and when the BYR/BXR/CR registers are shadowed/locked for the next line, because that is the only thing that really effects the game code. As long as your logic gives the right number of cycles, then I suspect that it will be good, and that the actual HDS positioning on the TV screen won't actually matter. But if the logic is wrong, then there are bound to be games that will glitch, either because they write the registers too soon, or too late (depending upon how they expect things to work). Now there could also be games that do software-timing-loops in order to change other settings part way through the line, but I would hope that there are only a very limited number that do that. I remember mednafen author had issues with Wonder Momo. Yep, it's well worth downloading the mednafen source and reading the file mednafen\src\pce\notes\GAME_NOTES to see a list of "problem" games, and the edge-case behaviors that they rely on.
|
|
|
Post by dshadoff on Feb 17, 2020 3:40:18 GMT
I'm still running an old (maybe 2-3 years old) version of Mednafen, and it has the issue with Wonder Momo. Do you know if there was a subsequent release that fixed this ? I am seeing that 2 interrupts appear - one VBLANK and one RCR. It seems to assume that the VBLANK is the RCR, and vice-versa.
I don't think this is a problem which happens within every single frame; it could be something which is just a simple flip-flop, and is set incorrectly at inital setup time (in which case, I should look for the issue there...)
|
|
|
Post by elmer on Feb 17, 2020 5:13:01 GMT
I'm still running an old (maybe 2-3 years old) version of Mednafen, and it has the issue with Wonder Momo. Do you know if there was a subsequent release that fixed this ? I am seeing that 2 interrupts appear - one VBLANK and one RCR. It seems to assume that the VBLANK is the RCR, and vice-versa. Nope, the problem still exists with the current version of Mednafen. The Wonder Momo code doesn't seem to take a look at which type of interrupt happens, it just reports that either-an-RCR-or-a-VBLANK occurred. The game code just waits for the-next-interrupt-whatever-it-is, and does it's timing based on that. So, as you say, the whole thing depends upon some weird timing-specific initialization setup that Mednafen isn't emulating. Yuk for Wonder Momo ... that's horrible code!
|
|
|
Post by dshadoff on Feb 17, 2020 23:04:27 GMT
Minor update for the chip decapping: The gentleman with the equipment has agreed to help with this task. ( siliconpr0n.org ) Furrtek did a quick recon on what he could see, tracing back from the IRQ (output) pin, finding a 6-input AND (or maybe OR) gate. Since these also go to the status register, it should be helpful in working back to identify which areas of the die are involved in what operations. (Small portion, partial view:) imgur.com/ulZ3gNe
|
|
|
Post by dshadoff on Apr 4, 2020 2:15:12 GMT
...And the decapped photos are now available. Thanks to John McMaster for this help. siliconpr0n.org/map/hudson/huc6270/mz_mit20x/Let me know if anybody is interested - either in helping break it down (once a standard cell document is created), or just progress updates.
|
|