So been playing with trying to get Xenix to boot this week, I think I've discovered a routine that does the disk access, it seems to pass some variable along with the sector number, but what I don't see is a pointer to memory where the data is either written to the drive from, or read from the drive into RAM, so I'm unsure about what this actually does, likely it's some kind of queue mechanism.
I think I also see the Interrupt Service Routine (IRQ handler) checking various function pointers, and if not-null executes them, so that was pretty interesting to see the inner workings of that.
I did find the routine that prints a single character to the Lisa's CRT as well as the routine that draws the cursor by highlighting it - similar to the LPW routine, it uses EOR #$ff to highlight a character, but the font size is different and also the console size in Xenix seems to be different. It's something like 88 chars x 33 lines. And I've also found a printf equivalent (kprintf I suppose) that calls the single char output routine. So this along with a keyboard interface can be used to turn the Xenix console into a text one and control it via telnet or pty, etc. so automation will be possible.
I'm not seeing the same timeouts, last night I tried again and manually walked through something like 4GB of tracelogs and see a successful write of the same block # above followed by a state 0306 error followed by a successful read of the same block #. So not sure where this is actually breaking. I've played with extending the various timings for the states, but that didn't seem to do anything to the pfcmd state 0306 error.
There is some interesting code that merges in a bunch of status stuff or state steps into what the 0306 is, figuring that out might help.
At some point it might be worth disassembling the full xenix kernel and playing around with it. The tracelogs provide some good info as how these functions are being called/used. Mapping the executed opcode patterns to the "/xenix" file would be a good start to figuring out the addresses of these, when disassembling, and then the values passed and what the code does when I/O happens will help map which code does what... A fully disassembled kernel might be useful for projects such as adding ppp/slip/ethernet and TCP/IP (I think UniPlus might have some support for some of that stuff, but not sure if Xenix does.) Unixen of this age usually had a monolithic kernel without separate drivers - they were compiled into the kernel.
Looking at Dr. Patrick's traces of the ProFile (been using that since I wrote the original profile.c code), which can be found here:
*
http://john.ccac.rwth-aachen.de:8000/patrick/idefile.htm*
http://john.ccac.rwth-aachen.de:8000/patrick/data/profile_write_cycle.png*
http://john.ccac.rwth-aachen.de:8000/patrick/data/profile_read_cycle.pngI see all the state machine steps are being met, so this might turn out to be a VIA issue or timing, or something like that. Or perhaps going back to state zero something's not quite right or not generating the right IFR flags, not sure yet. It's hard to say because of the disconnect between the various events
No error is returned to Xenix in the status bytes, the Xenix state machine does each step as expected.
* Even though Xenix doesn't write the full command bytes, once CMD is flipped and the handshake acknowledges the command (read/write) as correct, the buffer pointer is correct, I though perhaps there was some indexing issue, but doesn't appear to be the case. The right number of bytes are written at the right places in the profile buffer despite Xenix skipping the last byte (spare count) or so for some operations.
I've also tried the patched boot disk meant for the X/ProFile, however that threw a lot more errors than the normal one. Perhaps that's worth spending time on as it throws a lot more error messages, so it likely exposes more issues, but ideally I'd like to support Xenix without having to rely on a patched OS.
Alternatively if I can suss out the full exact details for read/write sector calls, and find their buffers (I need read/write command, device, and buffer space), I can then switch to HLE and just intercept those calls instead, but that's a quick last resort. It would run much faster, but would be less authentic. (I already do this kind of thing for the floppy controller, so it's not that big a deal.) The only tricky piece would be signalling the operation is done, so would also need to patch the ISR (Interrupt Service Routine) to make it work.
I'll keep playing around with this, but if I don't make more progress in a few days, it'll go on the backburner, and revist it when I rework the widget code later, as it's delaying the 1.2.7 RC4 release. (I still need to fix the serial port pty issues and work on a few more features I want to include in 1.2.7.) If I can get Xenix booting, that would be a huge bonus, but I don't want to stretch this out too long, want to release 1.2.7 this year.
If you guys are more interested in getting Xenix working on LisaEm, than getting the serial port connectivity finished off, please let me know and I'll keep going on it. I'll continue on this through the weekend and then after Monday if I don't figure out a solution, I'll decide if I go back to other tasks or continue on this.
