trap 494 is trap_520(1,1,0x1EFA94,0x1EF890->0x190); <works ok>

trap 495 is trap_140(0x1ef894,0x1efa94,7c,3); writes 0x7c bytes to 1ef894. <works ok>

trap 496 is trap_130(0x2348, 0x10); returns 0; puts 16 bytes to 0x2348: 2cb40ca4 65236776 0454806a 0eca1b92

trap 497 is trap_140(0x1ef924,0x1ef924,0x20,3); writes 0x20 bytes to 1ef924. <works ok>

trap 498 is trap_120(0, 0x5514, 0x2348, 0x10, 0); returns 0; writes 40 bytes to 5514:

4aa6ef81 dc4cf6b7 0237eaff e7d14a93
cfdc52e2 74811e16 2f770cfb ee11ce92
2a4e9fc4 beab67bd

trap 499 is trap_520(1, 1, 0x1ef794, 0x1ef794); <works ok>

PC goes out of sync between trap 499 and trap 500 due to nondeterministic behaviour.
Snaphot contents is ok though for at least the next 500 traps:

trap 500 is trap_110(0x5b430,0x5b430,?,?); returns 0; this case is not handled yet...

trap 501 is trap_520(1, 2, 0x1efcc8, 0x1efcc4); <works ok>

trap 502 is trap_520(1, 1, 0x1efe08, 0x1efcc4); <works ok>

trap 503 is trap_420(0x1efb14,0); returns 0. reads 256? bytes to 0xx1efb14.

trap 504 is trap_420(0x1efb14,1); returns 0. reads 256? bytes to 0xx1efb14.

trap 505 is trap_420(0x1efb14,2); returns 0; reads 256? bytes to 0xx1efb14.

the following 495 traps all read slots (there are 511 accessible slots, first 498 of them are read here).
Only the first slot contains data, the rest filled with 256? times 0x00.