This shows that there's a strong "anything goes" attitude, and you should expect the 3rd party operating systems to use different mechanisms/exception vectors/etc that Apple did not use, and hence may not (yet) be fully emulated in LisaEm.
Too early to say until I go through the whole 4GB tracelog, but I'm leaning towards agreeing with you here.
I don't see any TRAP calls, nor A-Line calls, but it's too early to tell, I'll know more once it gets outside of the kernel and starts executing processes. (This is true of Xenix as well, though I know TRAP #0 is used there.)
This could be some sort of obfuscation to deter disassembly, I've seen that kind of thing before with GEOS 1.3 on the C64 - well actually there it was self modifying code. (There I was able to freeze it at the right time on a C128 and use the monitor mode it had to capture all memory and then fix the self-modifying code to be able to get it to restart again after the copy protection. I wasn't able to do that with GEOS 2.0, but that's not relevant.)
This could also be (maybe more likely) some loading bug that bad data is loaded and that's not supposed to be an illegal opcode, but by accident invoking the ILLEGAL trap it is and going around whatever lockup and it causes it to at least turn the screen black and print the kernel banner. Then again, I did see the full set of bytes including this illegal opcode on the disk using lisafsh-tool, and have confirmed using ODA that is is infact not a valid 68000 opcode, so perhaps it is an intentional thing.
I did notice the boot loader complain (with tracelog on because it flashes by too quickly otherwise) that it couldn't find the superblock and that there were profile state errors.
So next step here is for me to map out the print calls and the profile calls. There's some source code for the kernel and drivers up on bitsavers so that will help a bit as we don't have that for Xenix.
I've seen Xenix do some really weird things. Now both UniPlus and Xenix are based on Bell Labs code, but different versions and different compilers, and I'm sure there was plenty of customization too. Perhaps they follow some ABI standard, that would be nice if binaries on one are compatible with the other, but it's doubtful.
Xenix does some weird things early at startup like doing a lot of 32 bit multiplies for some reason that I've not figured out why. Could be some kind of checksum or perhaps the rotor machine, but it doesn't look like a rotor cypher kind of thing, so I'm unsure what the purpose of that is - especially since James MacPhail was able to make modifications of the profile driver inside Xenix to make it compatible with the X/ProFile, and there was no mention of a checksum correction.
Between the two, Xenix has a lot more software available for it (Lyrics, Multiplan, Informix, Cobol) - it's possible these exist for UniPlus but haven't been rescued yet, I don't know, but UniPlus has some source code available and I think it's a newer OS - System V vs System 7, not sure. And at least UniPlus doesn't have the retarded way of locking the size of the profile down by the I/O ROM version as Xenix does...
But overall I'm not going to spend too much more time on this. I'll go through this 4GB log once or twice and see if I can suss out the putchar routine and maybe printf and maybe a bit of the profile handling code and see if I can map it out to the source code and take lots of notes like I did for Xenix.
After that, I'd like to fix up the open bugs in the serial code and wrap up 1.2.7 and cut a full release rather than an RC. I can revisit Xenix and UniPlus after that as I plan to revisit the widget code so that can be done together with the widgety multi-block transfer protocol it uses.
I want to get 1.2.7 out the door so I can start on the much bigger 2.0 features before the year ends. I might backport features to a 1.2.8 release while I work on 2.0, or maybe phase features from 2.0 to the 1.2.x as I work my way through the list, but there are going to be some pretty huge changes there.
I've mentioned the widget code already, but the biggest will be using shmem for all the storage including RAM, floppy, profiles and state so we can pause and save and resume states, another huge one would be resurrecting the 1.3.0 CPU core and porting all the fixes from 1.2.7 to it, and another would be separating the UI from the backend. There'll be some smaller things like adding a Daisywheel Printer emulation too. But running out of runway for 2020 and there's plenty of bugs to fix.
