AeroWings 2 - Airstrike slow on Bay levels

[skmp]

From @gamax92 on May 17, 2015 21:6

Rested with 76b09876f8b8c99a7a1e6d0d61b06e9a5decdc0e on Arch Linux x64 Bay Noon will get through the small "Start, Now" sequence at the beginning of every flight and then starts to spam:

[sh4]Read32 from 0x126B1A8C, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A88, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A94, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A90, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A9C, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A98, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1AA4, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1AA0, not mapped [_vmem default handler]
(and so on)

It always starts from that address and continues infinitely upwards in that pattern.

Bay Night runs for a little bit now but then after some time starts to spam the following looped messages

[sh4]Read32 from 0x7129412C, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294130, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B78C, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B788, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B788, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B790, not mapped [_vmem default handler]
[sh4]Read32 from 0x7129412C, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294130, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93895, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93891, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93891, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93899, not mapped [_vmem default handler]
(the above repeats exactly)

As far as I'm aware, no other maps have issues like this.

---

Game: AeroWings 2 - Airstrike

Format: game.gdi track01.bin track02.raw track03.bin

Bay Noon spams tons of read errors, frames advance really slowly and lots of stuttering:

[sh4]Read32 from 0x########, not mapped [_vmem default handler]
over and over

Bay Night runs smoothly but eventually crashes:

Verify Failed  : w == 1
 in ngen_Rewrite -> ../../core/rec-x86/win86_driver.cpp : 762 

Trace/breakpoint trap

For what its worth, nullDC will also crash on these levels. This seems to have been fixed in nullDC, it used to crash before though. nullDC flickers the ground like crazy though

Using Linux Mint MATE 17.1 Compiled at commit: 341c421dd7068171f1e14fa293ad8105bcafec05 from skmp/linux86

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/60867586-aerowings-2-airstrike-slow-on-bay-levels?utm_campaign=plugin&utm_content=tracker%2F91046168&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F91046168&utm_medium=issues&utm_source=github).

[skmp]

From @gamax92 on May 17, 2015 23:33

Also just tested on Android from commit db284eb4b7b45e6e5c587df7ada788f00eb5ad94 Both levels get really slow as well, from what I assume is the same reading error described above, neither levels cause any crashes though.

[skmp]

@gamax92 can you retest this with latest master?

[skmp]

From @gamax92 on April 11, 2018 20:32

Rested with 76b09876f8b8c99a7a1e6d0d61b06e9a5decdc0e on Arch Linux x64 Bay Noon will get through the small "Start, Now" sequence at the beginning of every flight and then starts to spam:

[sh4]Read32 from 0x126B1A8C, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A88, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A94, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A90, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A9C, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1A98, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1AA4, not mapped [_vmem default handler]
[sh4]Read32 from 0x126B1AA0, not mapped [_vmem default handler]
(and so on)

It always starts from that address and continues infinitely upwards in that pattern.

Bay Night runs for a little bit now but then after some time starts to spam the following looped messages

[sh4]Read32 from 0x7129412C, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294130, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B78C, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B788, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B788, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E8B790, not mapped [_vmem default handler]
[sh4]Read32 from 0x7129412C, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294128, not mapped [_vmem default handler]
[sh4]Read32 from 0x71294130, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93895, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93891, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93891, not mapped [_vmem default handler]
[sh4]Read32 from 0xA9E93899, not mapped [_vmem default handler]
(the above repeats exactly)

As far as I'm aware, no other maps have issues like this.

[skmp]

Thanks. Updated the ticket with the new information

[skmp]

From @gamax92 on April 11, 2018 23:4

Err, as a test I had removed the printf from the _vmem.cpp file and it still crawls to a halt with no logging.

I'm sure the logging is making it even slower, but it's probably not supposed to be doing that in the first place.