Just to check the basics, are there absolutely no serial interrupts expected ever if there is no link cable connected? Or can serial interrupts occur sometimes in certain cases? Looking at GBAHawk code it appears the answer is maybe the latter?
The GBA can run serial clocks under internal control, so an interrupt can occur even if no cable is connected, at least that's how it's coded up now. There's a lot of the serial port I don't have emulated yet too, so if the movie is doing stuff with it it might be wrong.
That might just be the issue then. The "sync" I got by completely disabling serial interrupts is probably just "fake sync" more or less, which of course didn't last long with the movies going further. The games like to use the serial port quite a bit on startup and on clicking one of the continue/new game/etc buttons, on hard reset it seems the timings here don't end mattering too much, but after some soft resets cracks begin to show with this.
Yeah you are probably right, since I currently fail even the basic tests in the mgba test suite related to serial port. I'm going to start working on those soon. The next version of GBAHawk should have those working. If you can make a test that recreates the basic idea of what the game is doing that would probably speed things up as well.
The mgba test suite FYI isn't really a great comparison. The test suite expects a link cable to be connected and without one some tests just fail (and some appear to be non-deterministic even). The timing tests (which probably what matter most in a sync context) too appear to have variable results on console (I would assume it's because internal clock uses clock divider bits internally like the timer, so the results wouldn't be consistent unless you properly aligned things beforehand).
Doing a little investigation against FRLG and using mGBA's suite's (flawed) tests:
1. FRLG appears to trigger serial interrupts on startup and when hitting New Game/Continue (which matches up with the serial activity I saw in those areas).
2. These interrupts are only done with Normal mode, 32-bits, with either 256KHz (and sometimes 2MHz?) clock (so at least for Pokemon, only that mode needs to be correct).
3. mGBA's suite's test results move around. At first I thought it was just due to them not "aligning" with the serial clock, but the results swing wildly on different iterations (thousands of cycles of difference doesn't seem like just an alignment difference).
4. GBAHawk doesn't appear to correctly do the 256KHz at all, it just makes it half the speed of the 2MHz clock (which isn't right, 256KHz is 1/8 of 2MHz, not 1/2). Of course, even if that is fixed it wouldn't match console due to this weird wild swinging.
5. Also on these different modes, the results on console don't make sense. There doesn't appear to be significant differences in the time it takes for all of these modes (at least within Normal mode, Multi mode appears to have a significant difference between its different speeds), which is extremely strange. I would wonder if this is specific to the GBP in the first place.
Doing a little investigation against FRLG and using mGBA's suite's (flawed) tests:
4. GBAHawk doesn't appear to correctly do the 256KHz at all, it just makes it half the speed of the 2MHz clock (which isn't right, 256KHz is 1/8 of 2MHz, not 1/2). Of course, even if that is fixed it wouldn't match console due to this weird wild swinging.
Oops, yeah I should have a 0x3F divider instead of 0xF. I'll fix that.
I tried running mGBA tests on GBP, I don't have a link cable so nothing is connected, and I get a timeout.
However sczther commented in the GitHub issue for the SIO tests:
With my Omega DE flashcart on a AGS-001 system, the tests pass even without any cable connected. Just the second test skips the multi mode, so it does only 4/8 tests. But it seems these should pass even without a link cable.
So yeah, maybe GBP is interfering. But I don't understand why / how this would impact internal clock mode? Obviously I'm missing something here.
EDIT: I also tried running a tas in 'no-enhance' mode and also got a timeout.
I am using multiboot to even load up the tests (as I lack a flashcart), so that probably is interfering and my results might be able to be thrown out just from that.
EDIT: To be clear, do you mean a timeout on the Normal mode tests or the Multi mode tests?
Oops, yeah I should have a 0x3F divider instead of 0xF. I'll fix that.
Applying that fix myself, it doesn't appear to actually affect the TAS sync (still results in the wrong TID). Of course, if it's expected that the mGBA SIO timing tests would actually pass (they don't pass in GBAHawk), then there's still some timing inaccuracy with serial timing somewhere.
I am using multiboot to even load up the tests (as I lack a flashcart), so that probably is interfering and my results might be able to be thrown out just from that.
Ooohhhh, ok now things are starting to make sense. So GBP is definitely interacting with the serial port in some way, even without games that have extra GBP features.
My first guess would be that the internal clock is simply disabled, but then I would expect Mesen to sync in the disabled tests you did. I'll have to make some basic test roms to figure out exactly what it is doing.
I am using multiboot to even load up the tests (as I lack a flashcart), so that probably is interfering and my results might be able to be thrown out just from that.
Ooohhhh, ok now things are starting to make sense. So GBP is definitely interacting with the serial port in some way, even without games that have extra GBP features.
My first guess would be that the internal clock is simply disabled, but then I would expect Mesen to sync in the disabled tests you did. I'll have to make some basic test roms to figure out exactly what it is doing.
The multiboot being used is provided by GBI (which as a note, GBI will provide a default multiboot ROM even if you didn't select your own via CLI settings). I'm not entirely sure it is exactly something that would be considered "accurate" anyways. Ideally, these tests should be double checked on the GBP using the GBP boot disc (which granted is probably sufficient to just be loaded up via an SD Card with Swiss) to eliminate any issues with GBI.
The multiboot being used is provided by GBI (which as a note, GBI will provide a default multiboot ROM even if you didn't select your own via CLI settings). I'm not entirely sure it is exactly something that would be considered "accurate" anyways. Ideally, these tests should be double checked on the GBP using the GBP boot disc (which granted is probably sufficient to just be loaded up via an SD Card with Swiss) to eliminate any issues with GBI.
Oh, good idea. I tried with the original disc just now and the mgba SIO normal mode timing tests pass. Huh, interesting.
At first I thought it was just due to them not "aligning" with the serial clock.
Actually, this is probably not an issue, or rather, simply aligning with VBlank is enough to "align" with the serial clock. VBlank is every 280896 cycles, which is already a multiple of 64 (cycles per bit).
Also on that, the results seem to at least indicate that Normal SIO does not trigger the IRQ until n + 1 bits are clocked through (n being 8 or 32). This probably indicates an "overflow" of the bits is what triggers the IRQ rather than meeting the bit target. Additionally, there is some kind of weird alignment issue at play too (notice how the cycle difference in GBAHawk to the test result is bit period - 2 (e.g. 8 - 2 -> 6 extra cycles, 64 - 2 -> 62 extra cycles, of course if you add an extra bit it becomes the inverse of GBAHawk being 2 cycles too late for the serial IRQ)
Oh, good idea. I tried with the original disc just now and the mgba SIO normal mode timing tests pass. Huh, interesting.
According to Extrems, GBI does not enable the link connection unless it sees the GBA bios screen without the Nintendo logo (i.e. what happens to start up multiboot). Which case, it should in theory be the same as a normal GBA without a link cable (although the tests timing out for you but not for another person on an AGS seems strange). The GBP boot disc apparently just always enables the internal link connection, even when it's not using it at all (so it functionally acts like a dummy link cable is connected?)
According to Extrems, GBI does not enable the link connection unless it sees the GBA bios screen without the Nintendo logo (i.e. what happens to start up multiboot). Which case, it should in theory be the same as a normal GBA without a link cable (although the tests timing out for you but not for another person on an AGS seems strange). The GBP boot disc apparently just always enables the internal link connection, even when it's not using it at all (so it functionally acts like a dummy link cable is connected?)
Ok, so it really is disabled. That's strange but at least it makes sense now. It seems like the 'mesen + SIO IRQ disabled' should have synced in that case, but maybe there are other side effects.
I tried triggering IRQ at bit count + 1 with an offset of the SIO counter to match expected results. With this I can pass each of the normal mode tests individually (pressing A on one of the tests) but not as a group (pressing A on the main page to go into the timing tests page.) Individually they all have the same relative starting point, but as a group they are all different. Probably there is some weird stuff like "starting condition = counter % x == y". I'll probably need to make a bunch of tests that each start 1 cycle later from the last to get it right.
EDIT: I guess it's also possible that SIO uses an internal counter that is reset on start, so it's not tied to global state, that would make the above observation easier to resolve, either way some test roms should decide this pretty easily.
I updated SIO emulation to pass the mgba tests. With tests on GBP (original disc with dev board) I get consistent pass every time on console, so under these conditions the tests seem consistent.
Now under GBI, is there an option to enable linking by default? Should I try to match the 'disabled' behavior? Based on real disc and scyther's post I would say disabled is incorrect behavior.
Now under GBI, is there an option to enable linking by default? Should I try to match the 'disabled' behavior? Based on real disc and scyther's post I would say disabled is incorrect behavior.
I think the only way to do that is to insert a dummy link cable into the console (that, or have Extrems change GBI to match GBP behavior). Have you confirmed anyways with more testroms that serial stuff appears to be completely disabled anyways?
Test ROMs will have to wait until this weekend, right now I'm just doing the simplest thing that works.
CasualPokePlayer wrote:
I think the only way to do that is to insert a dummy link cable into the console
I didn't understand why having a cable connected would make any difference until I actually looked at the port. Sure enough there is a depressible pin in there I never noticed before! Indeed if I keep it pressed down the SIO tests pass even in GBI mode!
I think I have enough info to get this working now. In fact you might want to try current dev build, it's possible it's good enough to work already.
Fixing Mesen to pass the normal timing tests ends up resulting in the correct TID (along with all later TIDs).
Interestingly Mesen's fix was just adding 6 cycles to its calculation.
Using the updated GBAHawk dev build does not result in the correct TID however for whatever reason.
I'm starting to make some tests for serial port. I started by making a very simple test to verify basic timing as well as confirm that GBI really does completely disable the port unless the pin on the serial port is pressed.
https://github.com/alyosha-tas/gba-tests/blob/master/Serial/serial_time.gba
If I run this test on GBI, I get a white screen, because it is waiting for a serial port IRQ. When I manually depress the pin, even while the test is still running, the port will start working and display a result.
If you run the test with the pin depressed from power on it will pass. I'll make some more tests to nail down precise behavior.
EDIT: Other findings:
- Transfer timing is relative to the write to the serial control starting the transfer, not some always running internal clock.
- Start bit is cleared at the same cycle IRQ is triggered.
- If no serial cable is connected, 1's are loaded into the data address during transfer.
If I run this test on GBI, I get a white screen, because it is waiting for a serial port IRQ. When I manually depress the pin, even while the test is still running, the port will start working and display a result.
This I'm really confused about, since this seemingly would indicate disabling the serial port would sync, but that is not the case at all, I only get sync from the test movies with proper serial timings, indicating it is functional on GBI?
I guess something to double check is using the latest GBI version possibly? (don't know how old the GBI version you're testing is, maybe it's something that was "fixed" in recent versions?) Also double check GBI-SR (what's being used normally to verify runs).
This I'm really confused about, since this seemingly would indicate disabling the serial port would sync, but that is not the case at all, I only get sync from the test movies with proper serial timings, indicating it is functional on GBI?
I guess something to double check is using the latest GBI version possibly? (don't know how old the GBI version you're testing is, maybe it's something that was "fixed" in recent versions?) Also double check GBI-SR (what's being used normally to verify runs).
Well, I don't really know. Two weeks ago I didn't even know that press pin on the serial port even existed, so at least some learning is taking place. I haven't updated GBI since I got it set up several years ago. This weekend I will go over my files and I guess upgrade to the latest version.
Follow up on serial port activation. I updated all my GBI / Swiss files and now the serial port works by default. So that is good. The 4 active tests in the test suite now pass, but 2 tests in the SIO reg test still fail: 'M: SIOCNT' and 'M: RCNT'. I don't have a stand alone GBA so not sure if this is a GBP difference or just a test typo.
For completeness I also tries Snood but it still crashes in the same place.
