Infocom overwrote the PSEUDO-OBJECT’s “hardware name” in the object table to reflect the noun that matched it:
3 Likes
So… I guess the takeaway here is that very few games use a @jump instruction in the small integer operand form given that Yazmin didn’t implement it correctly and yet runs dozens of existing games just fine.
(I did see there were several other issues of bizarre behavior in the GitHub issues tracker, it’s possible some or all of them have the same root cause I just fixed)
The other takeaway is @get_parent 0 and @get_prop 0 should both just return zero by default unless you opt into strict behavior.
-Dave
I’m curious what 8-bit platform you’re working on? I had the idea of shadowing the globals into separate arrays of low and high bytes so I could index all 240 of them easily. On routine entry, I could copy all locals into slots 1-15 of that array (also split) so that the variable operand type could be handled with very few branches (only TOS might need special handling).
-Dave
Just realized if you do shadow globals for efficiency you need to put them back in their original location before you save.
Dave
Yep. I remember bringing up something about hoisting anything out of dynmem means you need to handle writing it back before saving. I don’t recall the specifics though. You theoretically also need to deal with direct memory writes invalidating your separate cached data, but practically you can probably get away with it, mostly.