xemu
xemu copied to clipboard
xemu-project
Steel Battalion : pgraph_bind_textures: Assertion `levels > 0' failed.
Title
https://xemu.app/titles/43430009/#Steel-Battalion-Line-of-Contact https://xemu.app/titles/43430002/#Steel-Battalion
Bug Description
Game Crashes when getting ingame for starting the campaign or loading a replay transfered from a hardward xbox with the described assert
I captured this backtrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x00007ffff6460536 in __GI_abort () at abort.c:79
#2 0x00007ffff646041f in __assert_fail_base (
fmt=0x7ffff65c8ea8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x5555560d6e88 "levels > 0", file=0x5555560d6b80 "../hw/xbox/nv2a/pgraph.c",
line=6647, function=<optimized out>) at assert.c:92
#3 0x00007ffff646f792 in __GI___assert_fail (
assertion=assertion@entry=0x5555560d6e88 "levels > 0",
file=file@entry=0x5555560d6b80 "../hw/xbox/nv2a/pgraph.c", line=line@entry=6647,
function=function@entry=0x5555560d5710 <__PRETTY_FUNCTION__.34> "pgraph_bind_textures")
at assert.c:101
#4 0x0000555555a9d869 in pgraph_bind_textures (d=d@entry=0x7fff794ca010)
at ../hw/xbox/nv2a/pgraph.c:6647
#5 0x0000555555aa1214 in pgraph_NV097_SET_BEGIN_END_handler (d=d@entry=0x7fff794ca010,
pg=pg@entry=0x7fff794eccd0, subchannel=subchannel@entry=0, method=method@entry=6140,
parameter=parameter@entry=6, parameters=parameters@entry=0x7ffee7d78f90,
num_words_available=1, num_words_consumed=0x7ffeeebf22a0, inc=true)
at ../hw/xbox/nv2a/pgraph.c:2896
#6 0x0000555555aa2bd7 in pgraph_method (d=d@entry=0x7fff794ca010,
subchannel=subchannel@entry=0, method=method@entry=6140, parameter=parameter@entry=6,
parameters=parameters@entry=0x7ffee7d78f90,
num_words_available=num_words_available@entry=1, max_lookahead_words=1693, inc=true)
at ../hw/xbox/nv2a/pgraph.c:1146
#7 0x0000555555a9070c in pfifo_run_puller (d=d@entry=0x7fff794ca010,
method_entry=<optimized out>, parameter=6, parameters=0x7ffee7d78f90,
num_words_available=1, max_lookahead_words=1693) at ../hw/xbox/nv2a/pfifo.c:226
#8 0x0000555555a908ab in pfifo_run_pusher (d=d@entry=0x7fff794ca010)
at ../hw/xbox/nv2a/pfifo.c:337
#9 0x0000555555a90f52 in pfifo_thread (arg=arg@entry=0x7fff794ca010)
at ../hw/xbox/nv2a/pfifo.c:489
#10 0x0000555555c5c035 in qemu_thread_start (args=0x7fff823bfdd0)
at ../util/qemu-thread-posix.c:541
#11 0x00007ffff6608eae in start_thread (arg=0x7ffeeebf6640) at pthread_create.c:463
#12 0x00007ffff65382ff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Expected Behavior
The game to get ingame like Line of Contact appears to do.(Though the performance is abysmal).
xemu Version
Version: 0.7.56-15-g940bee452c Branch: master Commit: 940bee452cc34127ecf3f364c3c5f52e4e6a80a4 Date: Thu Aug 18 08:13:32 PM UTC 2022
System Information
CPU: AMD Ryzen 7 2700X Eight-Core Processor
OS Platform: Linux
OS Version: Void Linux
Manufacturer: AMD
GPU Model: AMD Radeon RX Vega (vega10, LLVM 12.0.1, DRM 3.46, 5.18.16_1)
Driver: 4.6 (Core Profile) Mesa 22.1.7
Shader: 4.60
Additional Context
This does require passing the controller through to test. I figured out my passthrough woes were due to permissions and not xemu so I'd like to apologize for blaming a commit for it. I'm not sure why it used to work without changing bus permissions but probably something to do with my system.
I'm guessing this assert is now here: https://github.com/xemu-project/xemu/blob/ebec5e30284a6ef2c55fe4f1d1c123eb88c19a74/hw/xbox/nv2a/pgraph/texture.c#L294
It'd be interesting to look at the values printed above (https://github.com/xemu-project/xemu/blob/ebec5e30284a6ef2c55fe4f1d1c123eb88c19a74/hw/xbox/nv2a/pgraph/texture.c#L248 ) to see what the raw values passed in are. A pgraph log filtered to show NV097_SET_TEXTURE_FORMAT lines would indicate exactly what the game is trying to do.
I verified that attempting to set texture format w/ a levels param of 0 raises an exception on HW, but a few years ago we found that it's possible to suppress certain checks (https://github.com/abaire/nxdk_pgraph_tests/blob/7ba5c9e9f9a877758c988cd47332b46d1322d8c9/src/tests/stencil_tests.cpp#L51 ) so it is possible that the game is intentionally clearing the exception before sending an invalid format.
@HadetTheUndying do you happen to remember what bios you were using? I think some bioses that replace the X splash screen (e.g., Cerbios) may leave the texture format registers in a non-standard configuration, leading to this assert failing in titles that don't explicitly initialize the settings of texture units before using them. I've seen this specifically with Tomb Raider Legend.
@HadetTheUndying do you happen to remember what bios you were using? I think some bioses that replace the X splash screen (e.g., Cerbios) may leave the texture format registers in a non-standard configuration, leading to this assert failing in titles that don't explicitly initialize the settings of texture units before using them. I've seen this specifically with Tomb Raider Legend.
Should have been Complex_4627v1.03
That machine is in storage now but I used the same setup on my MacBook, just moved everything over.
Similar issue still occurring on (effectively) v.0.8.71. See above duplicate issue for more info. I build from #1803 source so I can get past menus.
Since I can't submit a compat report from the forked ver, I'll go ahead and leave my would-be report here.
{
"compat_comments": "IF PR 1803 IS NOT MERGED, GOTO ISSUE 2252 TO REPRODUCE\nPLEASE NOTE THIS REPORT USES AN (as of 6/13/25) AN UNMERGED PR\n\nThe game crashes once the intro FMV finishes. Same error three times: pgraph_get_texture_shape: Assertion 'levels > 0' failed. See issue 2252 for more context.\nThe menus ran at 60FPS and menu options worked well with no issues. Visuals that I saw (FMV + menus) looked identical to hardware.",
"compat_rating": "Intro",
"cpu": "AMD Ryzen 7 7800X3D 8-Core Processor ",
"gl_renderer": "AMD Radeon RX 7900 XT (radeonsi, navi31, LLVM 20.1.6, DRM 3.63, 6.15.2-arch1-1)",
"gl_shading_language_version": "4.60",
"gl_vendor": "AMD",
"gl_version": "4.6 (Core Profile) Mesa 25.1.3-arch1.3",
"os_platform": "Linux",
"os_version": "Arch Linux",
"token": "redacted",
"xbe_headers": "WEJFSHgrSuuIyKd6iVjn9OTG9sWRSiMvXLDE1wK3HxJfG8XUQnwky0OnhwI4/snBm25C+7Ix8Kt2wcoJq+WNHYw5dKLiXZKv5T3FHM/mdCNFNm1VdDgEd99I+ubE0LvvUbj1qufPBVn5y843tuh4D5F8tZ76nl6tBsAEHhQywWN1gIU+zpvC0WTWX7fvcboPUZCzqw5IRyqgSXnncGcK6M4V1Ml2yALZn9NX99Kphdo10wP7kxdT0EcZkkSzma+DrUJ/xn5L63Mw402JN5NAZvEDTyz3Jg1+gfzepF6WaPTwEGWyojZOEao7rORGYeZ5crK6v1JFWxehqbgM5PuNFt89PJQAAAEAVBoAAGDsoAB4AQAAhkqZPXgBAQBOAAAAVAMBAAQAAABHLBkAsPkmAAAABAAAABAAABAAAIARAQAAHKQAAAAAAIRKmT1+FwEAkhcBAGQXAQDg0CUAAAAAAAcAAAD0FgEARBcBAPQWAQCgFwEAsgIAANwBAABVMqc9AgBDQ1MAVABFAEUATAAgAEIAQQBUAFQAQQBMAEkATwBOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wABAAAAAwAAAAAAAAABAAAAn95iZGpMmindVT/X267iD0GyTbWLTyBA+5uu0lS7BmBGbFbHGvBt+JxI0SXmi9UxFAOshyO1aEZDj2UMXr5/TFti8ehWKNfVvSEWiEPtfdZvW/tmJxvKftzxMYUwRLkHD3VoZWwWepsHBOnWp13RSgLaNVAzhs2CoeMOLr2Ww7yaOmY3Oj5+CtP+EQ7VONIxHFoyTrtCLGjPUOPrZac2P7QMv7gBzqZ0JSv6gNIjaOlWHZXuI2JhuvjiN08fvNHlrZbAlDsIDX/K7+WqUAczFIQmUOa/sRm/bKS5nplD6ZwQxPsrNcLQo2NKArzTKQnu6FrKD4DUkmzmwHNG9rG5T3bBGLaz8zs/kWFZEhYWm169AFrh6aRORbXhPV6qN0Ds3AEAAAAAAAAAAAAAFgAAAAAgAQDMoR8AACAAAMyhHwDwFAEAAQAAAGQUAQBmFAEAyjoHTqr4FU2ELfffxMIC1Vdl48MHAAAA4MEgADAiAQAA0B8A4O0AAPYUAQABAAAAZhQBAGgUAQCG9faZQWkHgx4sglQb4bHGw3tyvwcAAAAg5CEA3AIAAADAIADcAgAA+hQBAAEAAABoFAEAaBQBAJJAh9b7ZdiI7JUfw6O4Jyh5Y6GWBwAAAADnIQBUHwIAANAgAAQdAgAAFQEAAQAAAGgUAQBqFAEATU7+D8QDrzZA9syUHEeUnz3ldJsmAAAAYAYkAIDUAAAA8CIAgNQAAAcVAQABAAAAahQBAGwUAQBigrCcYxYrED2BmQw4jCLiy8DN8jYAAADg2iQAZRIAAADQIwBkEgAADBUBAAEAAABsFAEAbhQBAAZgKgjYBgSZdWtSN6lDBiaQH/81NgAAAGDtJAB5FQAAAPAjAHgVAAATFQEAAQAAAG4UAQBwFAEAsJ0OwaMpJzSTh12jOVXlJ4Wwclc2AAAA4AIlABwTAAAAECQAHBMAABsVAQABAAAAcBQBAHIUAQDuGHJeDbqU4kaZDtTVA1ABpntH/DYAAAAAFiUAoBUAAAAwJACgFQAAIhUBAAEAAAByFAEAdBQBAKwhtf+zUeCxdNfdkonY0wKPAAx6NgAAAKArJQA0EQAAAFAkADQRAAArFQEAAQAAAHQUAQB2FAEAzQKrZjPO+LX5FIYxPMMz07FH/ZE2AAAA4DwlAKwMAAAAcCQArAwAADQVAQABAAAAdhQBAHgUAQDhQUo458USborXC5mXUaod8xSxZjYAAACgSSUAnAAAAACAJACcAAAAPRUBAAEAAAB4FAEAeBQBAJ9H+qf9LTO9HN81GWCdqsRe17q7NgAAAEBKJQC4AAAAAJAkALgAAABGFQEAAQAAAHgUAQB4FAEAY0s2zmF9Vh3VcXlcN0i1xL0JlzM2AAAAAEslAIgAAAAAoCQAiAAAAE8VAQABAAAAeBQBAHgUAQAuFpHq9L4t7kPVdhpc/QMpiaRi7jYAAACgSyUAMAEAAACwJAAwAQAAWBUBAAEAAAB4FAEAeBQBAF78n+DexV0LOSc/2o6MpAJ/2VgNFgAAAOBMJQBYBQAAAMAkAFgFAABhFQEAAQAAAHgUAQB6FAEAdVDJCnPqFlBOxxMfejcHJwV6awcGAAAAQFIlAPgBAAAA0CQA+AEAAGoVAQABAAAAehQBAHoUAQCo7Gjvr8OXDGDQohec5a2TrCPV0wYAAABAVCUAvAEAAADgJAC8AQAAchUBAAEAAAB6FAEAehQBAHmQ8Wpjl1NfDQeDcVS7uavBDZjUBgAAAABWJQCMBQAAAPAkAIwFAAB7FQEAAQAAAHoUAQB6FAEA1YMld2GTydXLWrzbzkCCabLysswGAAAAoFslAEwBAAAAACUATAEAAIQVAQABAAAAehQBAHoUAQCPwn7+NOCc43KvQXb/beUognlt+gcAAAAAXSUAyHMAAAAQJQDIcwAAjBUBAAEAAAB6FAEAfBQBAOBxhkK2nIaFiLKeISJMjrrkKTZOBgAAAODQJQAg1AEAAJAlABjUAQCQFQEAAQAAAHwUAQB+FAEAJMgDjBFOeCb+b307Nsbun6B8TbcHAAAAAKUnALwzRwAAcCcA+JMIAJcVAQABAAAAfhQBAIAUAQCVjGH8ow5jVpX3REiDB/BwS1jMNwUAAADA2G4ARiAAAADAZABAIAAAnRUBAAAAAACAFAEAghQBAPFNglAk/bKRYiinJ8DGSlQWQBxnBQAAACD5bgDuFgAAAKBkAOgWAACjFQEAAAAAAIIUAQCEFAEAH2ItNKkyWd0PgfuwSWAAoMJxPA4FAAAAIBBvACYVAAAAgGQAIBUAAKkVAQAAAAAAhBQBAIYUAQBqArxuGBuHABJCTmBfm6t/8e9lMQUAAABgJW8AxhQAAABgZADAFAAArxUBAAAAAACGFAEAiBQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAEA6bwAGGAAAAEBkAAAYAAC1FQEAAAAAAIgUAQCKFAEAbxzGZFzEVLq82MPCBKbcmYcxwO0FAAAAYFJvAB4nAAAAEGQAGCcAALsVAQAAAAAAihQBAIwUAQCAsBlDikn3gMImCwGqCX6fKHtUDQUAAACAeW8AxhQAAADwYwDAFAAAwRUBAAAAAACMFAEAjhQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAGCObwDGFAAAANBjAMAUAADHFQEAAAAAAI4UAQCQFAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAAQKNvAMYUAAAAsGMAwBQAAM0VAQAAAAAAkBQBAJIUAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAAAguG8AxhQAAACQYwDAFAAA0xUBAAAAAACSFAEAlBQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAADNbwDGFAAAAHBjAMAUAADZFQEAAAAAAJQUAQCWFAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAA4OFvAMYUAAAAUGMAwBQAAN8VAQAAAAAAlhQBAJgUAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAADA9m8AxhQAAAAwYwDAFAAA5RUBAAAAAACYFAEAmhQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAKALcADGFAAAABBjAMAUAADrFQEAAAAAAJoUAQCcFAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAAgCBwAMYUAAAA8GIAwBQAAPEVAQAAAAAAnBQBAJ4UAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAABgNXAAxhQAAADQYgDAFAAA9xUBAAAAAACeFAEAoBQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAEBKcADGFAAAALBiAMAUAAD9FQEAAAAAAKAUAQCiFAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAAIF9wAMYUAAAAkGIAwBQAAAMWAQAAAAAAohQBAKQUAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAAAAdHAAxhQAAABwYgDAFAAACRYBAAAAAACkFAEAphQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAOCIcADGFAAAAFBiAMAUAAAPFgEAAAAAAKYUAQCoFAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAAwJ1wAMYUAAAAMGIAwBQAABUWAQAAAAAAqBQBAKoUAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAACgsnAAxhQAAAAQYgDAFAAAGxYBAAAAAACqFAEArBQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAAIDHcADGFAAAAPBhAMAUAAAhFgEAAAAAAKwUAQCuFAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAAYNxwAMYUAAAA0GEAwBQAACcWAQAAAAAArhQBALAUAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAABA8XAAxhQAAACwYQDAFAAALRYBAAAAAACwFAEAshQBAIXJdLoQOpXX1Je29uXMdIo0Vsv4BQAAACAGcQDGFAAAAJBhAMAUAAAzFgEAAAAAALIUAQC0FAEAhcl0uhA6ldfUl7b25cx0ijRWy/gFAAAAABtxAMYUAAAAcGEAwBQAADkWAQAAAAAAtBQBALYUAQCFyXS6EDqV19SXtvblzHSKNFbL+AUAAADgL3EAmPkBAABwXwCU+QEAPxYBAAAAAAC2FAEAuBQBABjFDd2Zh/veb2wSzthI6U7HN0blBQAAAIApcwDIxQQAAKBaAMTFBABFFgEAAAAAALgUAQC6FAEASh6xM5QlwL8qr0wOp3srGOYRjhUFAAAAYO93AADEAQAA0FgA/MMBAEsWAQAAAAAAuhQBALwUAQCKI4mTzgToLbNYzUNCrZintt4VfQUAAABgs3kAsKgBAAAgVwCsqAEAURYBAAAAAAC8FAEAvhQBAM9qLEbAWxemGkS54xcFaeJKQEweBQAAACBcewBA5gMAADBTADzmAwBXFgEAAAAAAL4UAQDAFAEAa7byWqMXHzaw1vXXe/Ao5YXIhVsFAAAAYEJ/ALhUAAAA0FIAtFQAAF0WAQAAAAAAwBQBAMIUAQCbGh7tEwZo39Tjwh5s8s6wxCi8iAUAAAAgl38AMGYBAABgUQAsZgEAYxYBAAAAAADCFAEAxBQBAEZgKU5WX+ERUPTEY+7M9VNExj1wBQAAAGD9gABANwAAACBRADw3AABpFgEAAAAAAMQUAQDGFAEAgj6MmYfd0rNQD50chSwq6ApOl4sFAAAAoDSBACA6AAAA4FAAHDoAAG8WAQAAAAAAxhQBAMgUAQAFFWOk7yhYLx1Y6nEVes9WVFbZtAUAAADAboEA6KwEAAAwTADkrAQAdRYBAAAAAADIFAEAyhQBAOmwVHg7S/ifGdwt7F+oQuHhaw7MBQAAAMAbhgAQvwMAAHBIAAy/AwB7FgEAAAAAAMoUAQDMFAEAZM7oqN3u6zdvY4HK0hDgVjMYHQwFAAAA4NqJAMArAAAAQEgAvCsAAIEWAQAAAAAAzBQBAM4UAQAsQktePSW6Cgew7Bo9zRVnIF4vkwUAAACgBooAuI0BAACwRgC0jQEAhxYBAAAAAADOFAEA0BQBACdid/amOAYPiDt2g/WSV6pvHftdBQAAAGCUiwDouQQAAPBBAOS5BACNFgEAAAAAANAUAQDSFAEACBIeQ/o57Kh9DIZ9pKKHCsTk5kgFAAAAYE6QAJDCAQAAIEAAjMIBAJMWAQAAAAAA0hQBANQUAQBUS3HxeNfe9rKP7VOCFjxJ/aM4eQUAAAAAEZIA6C0AAADwPwDkLQAAmRYBAAAAAADUFAEA1hQBANwL7m8Blx1yLv7VD4aubiTqzxv2BQAAAAA/kgAoYQEAAIA+ACRhAQCfFgEAAAAAANYUAQDYFAEAjval1R5mJn9WE6RoOfdY6V7TK+cFAAAAQKCTAIBIAAAAMD4AfEgAAKUWAQAAAAAA2BQBANoUAQAHhe4mIL84EMUTkVjH09ZO9GWPHAUAAADA6JMAyKABAACAPADEoAEAqxYBAAAAAADaFAEA3BQBAKKsKIzcLX8NP4l/xkz5OZSnb4bfBQAAAKCJlQD4qAQAANA3APSoBACxFgEAAAAAANwUAQDeFAEABTnp8wBhLyvK+r4urHaWq/QGhVoFAAAAoDKaAMDDAwAAADQAvMMDALcWAQAAAAAA3hQBAOAUAQC8oqL9nlE7tfviaOKsndb/OW38HQUAAABg9p0A2DEAAADAMwDUMQAAvRYBAAAAAADgFAEA4hQBAPEQ30Emn98B5TBELLlWYs8cy2fPBQAAAEAongBYiAEAADAyAFSIAQDDFgEAAAAAAOIUAQDkFAEADV/7Mzi2DAn1fjwJUQYqnMkNyLAFAAAAoLCfAMiaAAAAkDEAxJoAAMkWAQAAAAAA5BQBAOYUAQAr4Bgc41chIDyTby3gav7IdzAmvAYAAACAS6AAgHEAAAAQMABscQAAzxYBAAEAAADmFAEA6BQBAMjJFC3MvTG9ypotlOCsxHwgSNYVBwAAAAC9oABc9wAAAJAwAFj3AADVFgEAAQAAAOgUAQDqFAEA3Sh+RbbANcZFkeKd8m1O1XLQ1D8oAAAAYLShAAAoAAAA8GQAACgAAN4WAQAAAAAA6hQBAOwUAQBoG9NrHOafw3XZoKRHlSilj88bRjgAAABg3KEAABAAAAAgZQAAEAAA6BYBAAAAAADsFAEA7hQBACfPXcKeWEc916PZXkxL3PTDWg9uAQACAAQAAgACAAIAAgACAAIAAgAKAAoAAgACAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAgABAAAAAAAudGV4dABEM0QAWEdSUEgARFNPVU5EAEJJTksAQklOSzMyAEJJTkszMkEAQklOSzE2AEJJTks0NDQ0AEJJTks1NTUxAEJJTktZVVkyAEJJTktZVVkyAEJJTktZVVkyAEJJTktZVVkyAEJJTksxNk1YAEJJTksxNlgyAEJJTksxNk0AQklOSzMyTVgAQklOSzMyWDIAQklOSzMyTQBYUFAALnJkYXRhAC5kYXRhAHNlZzUwAHNlZzQ5AHNlZzQ4AHNlZzQ3AHNlZzQ2AHNlZzQ1AHNlZzQ0AHNlZzQzAHNlZzQyAHNlZzQxAHNlZzQwAHNlZzM5AHNlZzM4AHNlZzM3AHNlZzM2AHNlZzM1AHNlZzM0AHNlZzMzAHNlZzMyAHNlZzMxAHNlZzMwAHNlZzI5AHNlZzI4AHNlZzI3AHNlZzI2AHNlZzI1AHNlZzI0AHNlZzIzAHNlZzIyAHNlZzIxAHNlZzIwAHNlZzE5AHNlZzE4AHNlZzE3AHNlZzE2AHNlZzE1AHNlZzE0AHNlZzEzAHNlZzEyAHNlZzExAHNlZzEwAHNlZzA5AHNlZzA4AHNlZzA3AHNlZzA2AHNlZzA1AHNlZzA0AHNlZzAzAHNlZzAyAHNlZzAxAHNlZzAwAERPTEJZAEJJTktEQVRBACQkWFRJTUFHRQAkJFhTSU1BR0UAAABYQVBJTElCAAEAAAATEgFARDNEOAAAAAABAAAAExIBQFhHUkFQSEMAAQAAABMSAUBEU09VTkQAAAEAAAATEgFARE1VU0lDAAABAAAAExIBQFhCT1hLUk5MAQAAABMSAUBMSUJDTVQAAAEAAAATEgFAYgByAGEAaQBuAGIAbwB4AC4AZQB4AGUAAABEOlxicmFpbmJveFxSZWxlYXNlXGJyYWluYm94LmV4ZQAABzOtAwdTrQOpA+oAA3OnAzIAs/0DBQP900P56gAD4/kzRzMiAP8DBXP9c3Onc+oAc/fTc+P3Qw8D/wMF/zMuAAN6AANSAPkzA/kDDzP/AwND/xP5EwUDk6P3cwdzp2MjU6MFE6PT93MDBxNz4/fjoxMJA6P345MTBUNT+VNz+bMzAyNjAwWT/0MD4/8z+QMDQ+P9swX50/XTA6P/4wMDcybwEwUj4/9jAzbwEyMzw2MF0/9F/6OT9+MDYybwQwP/c9P5s/lzE/lTE+P3kwMj+ePT+dM28AMjY4NjAwMi8EPj/0PT95Mj+aMDI/ezMzLwEwNT9+ND9+MFo/ejA+P30wXT98MD0/dTA/kTBxMzAwMT+dP3o/fT+RP5Q9P5AwMD+ZP54yMj+XMFA/lj+dNDEwMHc/kjBaP5A/kjA/kDD1P5c/3js/kT+SP5cw/T9+MDA5P5AwUz+RPj/9MDA+P30wej+RP5A0P30yIAo/kj/UPj99ND+UP5Aw0D+VMF+eMHQ/kDA7P/4wP5owfT+VP34wOT95MiAPsD++MD+XOj99ND+QMFAwcj+QMF+aMH0/OTIwkDM9P7I/lDBRP5c7P3kwPj9zMPA/nTA/tDI/kz4/eTQ/kFE/lj+Qf5swVDIvBDBXP5I/lzBaP5E/lDA/kDDzP5cwP54wNT+RP5QxP5c0Pj93Oz97MHk/ljI+P30/mjAwOj+QPT9+Mjc/ljA/kDE/mzow1z+SMD+UMDs/kj+QMD0yLwswP5cwcTJvDjA9Mq8HMDIybwowND+QND+5MN0/kDA/fjBfmjU/kFA+P9swMD+TMJI/9zAwMD4yLwYwdj/eNDBaP3swXT+TMNSwVHEwMDSRNzp5MHA0Ojw6NzEwUTSQMLA1PT8+NzEwkDQ3Oj0/PjcxMLAyNTRwMHSRMHSQMNAAA=",
"xemu_branch": "DeviceEmulation-SteelBattalionController",
"xemu_commit": "1795f0a3ba57b38625c6701b86cd7de816c59799",
"xemu_date": "Fri Jun 13 05:59:27 AM UTC 2025",
"xemu_version": "7.7.5-17990-g1795f0a3ba"
}
@blakeplusplus would it be possible for you to get a PGRAPH trace while reproducing the issue? I'm curious if this is intentional behavior in the game and xemu is just missing support for suppression of an exception or the result of some other bug.
https://xemu.app/docs/dev/debug/guest/#tracing has info on enabling the tracing. If you're building from source you could patch in https://github.com/xemu-project/xemu/compare/master...abaire:xemu:debug/toggle_pgraph_trace_with_f9 to make the trace toggleable with F9.
Using trace-event nv2a_pgraph_* on:
...
nv2a_pgraph_method 0: 0x97 -> 0x1e70 NV097_SET_SHADER_STAGE_PROGRAM[0] 0x41
nv2a_pgraph_method 0: 0x97 -> 0x1b08 NV097_SET_TEXTURE_ADDRESS[0] 0x10303
nv2a_pgraph_method 0: 0x97 -> 0x1b0c NV097_SET_TEXTURE_CONTROL0[0] 0x4003ffc4
nv2a_pgraph_method 0: 0x97 -> 0x1b14 NV097_SET_TEXTURE_FILTER[0] 0x2062000
nv2a_pgraph_method 0: 0x97 -> 0x1b48 NV097_SET_TEXTURE_ADDRESS[64] 0x10404
nv2a_pgraph_method 0: 0x97 -> 0x1b4c NV097_SET_TEXTURE_CONTROL0[64] 0x4003ffc0
nv2a_pgraph_method 0: 0x97 -> 0x1b54 NV097_SET_TEXTURE_FILTER[64] 0x4074000
nv2a_pgraph_method 0: 0x97 -> 0x02a0 NV097_SET_FOG_GEN_MODE[0] 0x0
nv2a_pgraph_method 0: 0x97 -> 0x02a4 NV097_SET_FOG_ENABLE[0] 0x1
nv2a_pgraph_method 0: 0x97 -> 0x029c NV097_SET_FOG_MODE[0] 0x2601
nv2a_pgraph_method 0: 0x97 -> 0x09c0 NV097_SET_FOG_PARAMS[0] 0x3f800000
nv2a_pgraph_method 0: 0x97 -> 0x09c4 NV097_SET_FOG_PARAMS[4] 0x3f800000
nv2a_pgraph_method 0: 0x97 -> 0x09c8 NV097_SET_FOG_PARAMS[8] 0x0
nv2a_pgraph_method 0: 0x97 -> 0x0314 NV097_SET_LIGHTING_ENABLE[0] 0x0
nv2a_pgraph_method 0: 0x97 -> 0x03b8 NV097_SET_SPECULAR_ENABLE[0] 0x1
nv2a_pgraph_method 0: 0x97 -> 0x0294 NV097_SET_LIGHT_CONTROL[0] 0x20001
nv2a_pgraph_method 0: 0x97 -> 0x17c4 ?[0] 0x0
nv2a_pgraph_method_unhandled 0: 0x97 -> 0x17c4 0x0
nv2a_pgraph_method 0: 0x97 -> 0x1760 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[0] 0x1a32
nv2a_pgraph_method 0: 0x97 -> 0x1764 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[4] 0x1a31
nv2a_pgraph_method 0: 0x97 -> 0x1768 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[8] 0x1a40
nv2a_pgraph_method 0: 0x97 -> 0x176c NV097_SET_VERTEX_DATA_ARRAY_FORMAT[12] 0x1a21
nv2a_pgraph_method 0: 0x97 -> 0x1770 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[16] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1774 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[20] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1778 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[24] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x177c NV097_SET_VERTEX_DATA_ARRAY_FORMAT[28] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1780 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[32] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1784 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[36] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1788 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[40] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x178c NV097_SET_VERTEX_DATA_ARRAY_FORMAT[44] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1790 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[48] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1794 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[52] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1798 NV097_SET_VERTEX_DATA_ARRAY_FORMAT[56] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x179c NV097_SET_VERTEX_DATA_ARRAY_FORMAT[60] 0x1a02
nv2a_pgraph_method 0: 0x97 -> 0x1720 NV097_SET_VERTEX_DATA_ARRAY_OFFSET[0] 0x31ad000
nv2a_pgraph_method 0: 0x97 -> 0x1724 NV097_SET_VERTEX_DATA_ARRAY_OFFSET[4] 0x31ad00c
nv2a_pgraph_method 0: 0x97 -> 0x1728 NV097_SET_VERTEX_DATA_ARRAY_OFFSET[8] 0x31ad012
nv2a_pgraph_method 0: 0x97 -> 0x172c NV097_SET_VERTEX_DATA_ARRAY_OFFSET[12] 0x31ad016
nv2a_pgraph_method 0: 0x97 -> 0x17fc NV097_SET_BEGIN_END[0] 0x6
nv2a_pgraph_surface_target Target: [ZETA @ 0x03a04000] (ln) aa:0 clip:x=0,w=512,y=0,h=512
nv2a_pgraph_surface_match_zeta Match: [ZETA @ 0x03a04000 (512x512)] (ln) aa:0 clip:x=0,w=512,y=0,h=512,p=2048
nv2a_pgraph_surface_hit_zeta Hit: [ZETA @ 0x03a04000 (512x512)] (ln) aa:0, clip:x=0,w=512,y=0,h=512,p=2048
xemu: ../hw/xbox/nv2a/pgraph/texture.c:294: pgraph_get_texture_shape: Assertion `levels > 0' failed.
fish: Job 1, './dist/xemu' terminated by signal SIGABRT (Abort)
Let me know if you need anything else.
Thanks!
I need more of the log, that snippet show anything interesting. Specifically I'm curious about NV097_SET_TEXTURE_FORMAT (see my comment further back in history) but ideally starting the trace a second or two before the crash and preserving the entire thing should give me context to better guess at what is happening.
The full log, using trace-event nv2a_pgraph_* on started about 3 seconds before the crash:
testfile2.txt
Excellent, thanks!
That log exposes what I think is the problem:
nv2a_pgraph_method 0: NV20_KELVIN_PRIMITIVE<0x97> -> NV097_SET_TEXTURE_FORMAT[0]<0x1b04> (0xFF000000 {BORDER_SOURCE_TEXTURE, SZ_Y8, MipmapLevels:0, 0D, BaseSizeU:1, BaseSizeV:32768, BaseSizeP:32768})
It's setting the texture format for an SZ_Y8 texture with 0 mipmap levels. When I tried to reproduce this on hardware previously I did so with an RGB32 formatted texture, which led to an assert. We'll need to add a pgraph test to verify exactly what this does on HW (like it just doesn't care about mipmapping for greyscale textures) and then fix xemu (probably by bypassing the assert for this format).
If you want to try a quick hack, replacing the assert(levels > 0) with levels = MAX(levels, 1) might just let things work (or it might crash elsewhere, I don't recall exactly how the mipmap levels are used)
I'm happy to apply a quick patch and test it, but I'm not finding assert(levels > 0) within /hw/xbox/nv2a/pgraph/texture.c. Could you point me to the file you're talking about so I can apply the patch, rebuild, and test?
Maybe you're running some ancient build before Vulkan support?
The line in your build should be in the assertion message. At HEAD it's here: https://github.com/xemu-project/xemu/blob/e02e41ccaaceffcad816cfb554dd1195767e952d/hw/xbox/nv2a/pgraph/texture.c#L294
I'm blind, was in the wrong file I think lol.
Patch applied to /hw/xbox/nv2a/pgraph/texture.c:
...
levels = MIN(levels, MAX(log_width, log_height) + 1);
levels = MAX(levels, 1); /* PATCH */
if (dimensionality == 3) {
/* FIXME: What about 3D mipmaps? */
if (log_width < 2 || log_height < 2) {
/* Base level is smaller than 4x4... */
...
After rebuild, the full log, using trace-event nv2a_pgraph_* on started about 2 seconds before the crash:
testfile3.txt
Crashed at exact same point, but I think it hung for a bit longer.
Ah, too bad, I was hoping the rest of the support was just masked by this unusual mipmap case. Fixing this will require a bit more diagnosis and presumably implementation of missing support for SZ_Y8.
Hopefully it won't be too difficult to fix; with the info you've provided it should be possible to recreate the failure without having the game, then it's just a matter of implementing whatever is needed to match HW behavior.
Thanks for your help in diagnosing!
@blakeplusplus unfortunately my test to reproduce the command that Steel Battalion sends crashes with an exception on HW.
At this point I'm relatively confident that the game is disabling one of the exception checks (we've seen this in games like Spongebob and one or two others). Unfortunately I don't have a copy of this game; would it be possible for you to do a custom build and give me some debug info?
Specifically I'd like to add a printf to https://github.com/xemu-project/xemu/blob/4b4bef8bb91ffc26c7cf5001fcc262b842837f54/hw/xbox/nv2a/pgraph/pgraph.c#L165
if (addr != 0x720) {
printf("Write 0x%X to pgraph reg 0x%X\n", val, addr);
}
This will probably print a bunch of lines sporadically up until the crash. My suspicion is it'll either turn the exception flag off right at the beginning of the game or just before the crash, so if you could capture the entire sequence I think we can quickly find out if my hunch is correct.
You can ping me on the xemu Discord if you run into any trouble (I can also push a branch and have it gen a build, but I think you've successfully set up a dev build of your own already).
Reversed previous test patch.
Patch applied to /hw/xbox/nv2a/pgraph/pgraph.c:
...
default:
pgraph_reg_w(pg, addr, val);
if (addr != 0x720) {
printf("Write 0x%X to pgraph reg 0x%X\n", val, addr);
}
break;
}
...
After rebuild, the full log till crash: testfile-newpatch.txt
Any luck with this. I am willing to send my disc copies of Steel Battalion & Line of Contact to anyone willing to help with this. I do not have time nor enough technical knowledge to assist with this further. I would go so far as to buy someone the controller if we can get this running. Being able to do this, mixed with our ability to print the circuit boards for the controller now could bring this game fully back to life since QuantX recently reimplemented the campaign system for Line of Contact
When I attempted to naively reproduce some of the register writes and set a texture format of 0xFF000000 I was unable to prevent the hardware from throwing an exception, so there must be something more to this issue. It's possible that there is some other way to disable the exception or that some bug in xemu is causing the 0xFF000000 value where it would not be sent on real hardware.
If somebody has access to a modded devkit (or other XBDM-enabled HW) they could use the trace function of xbdm-gdb-bridge to dump a few frames around where xemu crashes so we could see if HW gets the same odd value or not.
I spoke too soon. I must've missed something in my previous testing as setting all of the pgraph registers to match the values provided by @blakeplusplus allows the test to pass.
I traced it down to setting PGRAPH register 0x14C to 0x0 that allows the otherwise invalid texture format to run on HW. It appears to result in nothing at all being rendered, but I'll need to look into it more to try to understand it.
The initial value: DebugStr: thread_id: 56 text: 0x14C was 0x97 now 0x0 - suspiciously 0x97 is the 3D graphics class for pgraph commands. I'd be very interested to see if 0x14C is set to other values by other titles. This could be accomplished by patching pgraph.c similar to the previous comment:
if (addr == 0x14C) {
printf("Write 0x%X to pgraph reg 0x%X\n", val, addr);
}
Happily, it seems that this was already reversed in the nxdk: https://github.com/abaire/nxdk/blob/2aab910b17b648e31403bcee629a54adf74ce501/lib/pbkit/outer.h#L448
Looks like we just need xemu to respect NV_PGRAPH_CTX_SWITCH1_ALL_DISABLE, though I'm not certain if all commands should just be ignored or if some state is still updated while other values are ignored.
EDIT: From some light testing, I think commands sent using a graphics class that is not assigned to any of the contexts are just ignored, so this is probably straightforward to implement in xemu. Currently xemu blindly applies the cached classes when interpreting commands (https://github.com/xemu-project/xemu/blob/7676418520562fd363e26fdff41fa4733f41af38/hw/xbox/nv2a/pgraph/pgraph.c#L657) which leads to a cleared ctx_switch being ignored, diverging from HW behavior. On HW, clearing out the CTX_SWITCH1 does not modify any of the associated CACHE1 entries (all subchannels remain unchanged), so the current implementation is likely incorrect.
I attempted a hacky solution as I don't fully understand why the current code blindly applies the cache context value on every command.
@blakeplusplus or @HadetTheUndying could you try the build from my TRACEONLY_log_pgraph_14C_writes branch: https://github.com/abaire/xemu/actions/runs/16898994701 to see what happens? It special cases the zero'd ctx_switch to require an explicit reset from the title. I'm assuming that SB will do this at some point after where it asserts today, otherwise it may stop updating the guest framebuffer altogether.
Please note that these are debug builds with extra debugging functionality, so they will likely perform poorly and should never be used to report issues. I just want to see if this gets us past the assert.
@blakeplusplus or @HadetTheUndying could you try the build from my
TRACEONLY_log_pgraph_14C_writesbranch: https://github.com/abaire/xemu/actions/runs/16898994701 to see what happens? It special cases the zero'd ctx_switch to require an explicit reset from the title. I'm assuming that SB will do this at some point after where it asserts today, otherwise it may stop updating the guest framebuffer altogether.Please note that these are debug builds with extra debugging functionality, so they will likely perform poorly and should never be used to report issues. I just want to see if this gets us past the assert.
It doesn't look like this includes the changes from https://github.com/xemu-project/xemu/pull/1803. As I don't own a Steel Battalion controller, I cannot get past the menus without that functionality, and thus can't test your fix. If you include the code from that PR along with your code, I'd be happy to test.
It doesn't look like this includes the changes from #1803. As I don't own a Steel Battalion controller, I cannot get past the menus without that functionality, and thus can't test your fix. If you include the code from that PR along with your code, I'd be happy to test.
You can try https://github.com/abaire/xemu/actions/runs/16978389985, the CTX_SWITCH workaround on top of faha223's work.
@abaire Might want to look at Fireblade has an issue where stop rendering guest framebuffer, only game I know of which does this https://github.com/xemu-project/xemu/issues/2199.
Also Tested with the build above and still crash with same assertion
xemu-v-dbg-x86_64.AppImage: ../hw/xbox/nv2a/pgraph/texture.c:294: pgraph_get_texture_shape: Assertion levels > 0' failed.`
@abaire Might want to look at Fireblade has an issue where stop rendering guest framebuffer, only game I know of which does this #2199.
Interesting, I guess it could be the same sort of thing where they disabled the rendering context entirely, but it's also possible that it's just something unimplemented. I'll add some comments there.
I added a pgraph tester case that explicitly sends the same invalid texture format and confirmed that it works with this patched xemu build, so it must be that SB is doing something else that causes xemu to reset the context prior to sending the bad format command.
Could one of you test with this https://github.com/abaire/xemu/actions/runs/17131631207 new build? I expect it'll still fail if the previous workaround build failed, but I've added some more logging to understand what it's doing with the context register. I'll need you to capture stderr / send the xemu.log to get the log messages; you should see something like "NV_PGRAPH_CTX_SWITCH1 write 0x0" and similar messages in the log if it's working.
Weird, the macOS build works for me, at least. Was there any error output? The only thing changed from the previous build is the addition of some log messages, I wouldn't expect that to crash.
Same issue I had with fireblade error. It occurred only Linux first while I was testing coldhex dev build 3 months ago but it was hit or miss where it would boot. It effects all custom build if tried using broke build. This is first time it effected windows. Might want test it yourself on windows as this is new installation. Only effects that build and don't matter what game you use.
Just tried the Windows release artifact on Win11/NVIDIA and it runs for me. Tested w/ Amped 2 and Halo arbitrarily.
@abaire Got it to work this time not sure what that previous bug was about. Here the log.
They happen before boot after boot never resets any time after that.
Cool, I suspect that there's some other place wherethe cache value replaces the switch or the game enables one of the other switches as 0x97. I'll add more logging and ping you when there's a build.
Actually, I think the log already shows what happens; the game clears CTX_SWITCH1 but then invokes NV_SET_OBJECT which resets it to 0x97. There must be some subtlety to how this works on HW where the cache value isn't written through in every case. Simply skipping the write doesn't work as the switch values do not seem to be explicitly set by DirectX in general.