General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
D.Finni:
I don't know if it's a coincidence, or if they referred to the same code, but the ROM serial drivers for classic Macintosh also default to a 64-byte input buffer. There's a device driver call that allows you to define your own buffer of arbitrary size.
stepleton:
--- Code: ---tom@ostepletron:~$ uname -a
Linux ostepletron 4.15.0-115-generic #116-Ubuntu SMP Wed Aug 26 14:04:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
tom@ostepletron:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic
tom@ostepletron:~$ vi --version | head -n 1
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 18 2020 18:29:15)
--- End code ---
Definitely connected to a Linux system, with TERM set to vt100 and no other special measures taken to disable colour in vim or elsewhere. Looks like I'm using the 3.0 version of the Office System for some reason; not sure why.
In unrelated news but talking of vintage vi, my investigations of the obscure Whitechapel MG-1 workstation led me to learn about its direct ancestor em, the "editor for mortals". It doesn't say so on that page, but apparently people didn't appreciate that the command to edit a file was so close to the command to delete the file.
rayarachelian:
--- Quote from: stepleton on September 18, 2020, 03:53:35 pm ---Definitely connected to a Linux system, with TERM set to vt100 and no other special measures taken to disable colour in vim or elsewhere. Looks like I'm using the 3.0 version of the Office System for some reason; not sure why.
--- End quote ---
Right you were sir, it looks like after (somewhat) fixing the buffering issues, colors don't cause issues. Tested the normal 16 color fore/background colors, 256 colors, and even 24 bit RGB colors, LisaTerm mostly ignores them properly. The only weird side effect was caused by this shade of green, which enabled blinking due to the ;5; inside it:
--- Code: ---printf "\x1b[38;5;106m 256 green\n"
--- End code ---
I used the values in this answer to test: https://stackoverflow.com/questions/4842424/list-of-ansi-color-escape-sequences/33206814#33206814
I also fixed the error 56 in the Boot ROM - this was caused by enabling the pty too early, which sent the bash prompt to the Boot ROM before it's test and it wasn't expecting any data on the port. I added a bit of code that split up the initialization in two passes. On power up it connects the serial ports to nothing, then about ~20 seconds (relative to the 5MHz CPU clock, so if you run at 10MHz, it's 10s, etc.) after power on it connects the real device.
However, now I ran into error 55, so even though there's nothing on serial port A, it fails the tiny test the Boot ROM does on port A. This is likely from my attempts to fix serial port A from locking up the OS/
It seems the LOS/LisaTerm 64 byte buffer can be increased by picking a higher baud rate such as 19.2kbps, however, there is still some limit and my attempts to limit the number of bytes didn't quite work out.
If I now run `seq 100 300` it gets as far as 2nd character of "202", so it's getting a lot further.
Enabling Xon/off handling sort of helped as well, but as I'm buffering internally before it gets to LisaTerm, it's not fast enough to tell bash to stop sending, so there's some more to do. It's likely vim should also work once the buffer cut off bug is fixed. I could watch the LisaTerm send Xon and then stop sending on my side rather than let Xon/off make it to the pty and bash instead.
The downside is that this requires Xon/Xoff to always be set, which is probably ok if the OS happens to be LOS as LisaTerm doesn't do hardware handshaking. (And would require another checkbox added to preferences to select it).
But it's probably better to get the timing just right.
It's possible that LOS is using the VIA timers or the actual clock instead of CPU cycles, I haven't explored that and have been limiting based on CPU clock cycles, so that's a possible route as well. Likely I'll try this next and use the wall clock rather than the CPU clock to rate limit the bytes.
The next remaining issue seems to be cursor keys don't work right. Control-A, Control-E bash editing works right, cursor left/right don't work at all. Cursor up/down send - and , respectively. These likely will turn out to be a keyboard translation issue and not a LisaTerm issue.
rayarachelian:
Trying to boot Xenix on LisaEm 1.2.7-RC3a setup as a 2/10 w/10MB internal widget (profile really) results in it trying to write to block 16456 and then read from the same block. After this it displays "Xenix pfcmd bad state 0306" and hangs.
Not quite sure why yet, been tracing the accesses to the profile code. I've also taken a RAM dump and captured the CPU addresses where the profile is being accessed so should be able to find and disassemble the profile driver. So either I'll find where that error comes from, or I'll find the entry points into the driver state machine and be able to intercept them,
--- Code: ---33846686:src/storage/profile.c:do_profile_write:394:ProFile write request block #16456 0x00004048 deinterleaved:16456 0x00004048
34126893:src/storage/profile.c:ProfileLoop:1025:step6: Reading block#16456,0x004048 - buffer: 00.00.00.00(00 )[00 40 48]:0a:04 00 00 00 00 00 00| 19:34:09.2 15462333758
--- End code ---
Looks like it's timing out at some of the states, and so it drops out of the state machine. (This isn't a complete protocol analysis, it's only showing the state transitions, not the data transfered back and forth but shows where we drop out, so I can go and look at those state transition points and look at the disassembly there.)
--- Code: ---31336384:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367045
31336402:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367045
31336415:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367073
31336433:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367073
31336446:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367097
31336478:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367135
31336526:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367187
31336545:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:1 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367187
31336566:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000012| 19:33:59.4 15455367219
31336602:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:33:59.4 15455367265
31336638:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:33:59.4 15455367305
31336663:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:33:59.4 15455367331
31336681:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:33:59.4 15455367331
....
31690210:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1 - BSY is now 1| 19:34:00.7 15455866919
31690250:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1 - BSY is now 1| 19:34:00.7 15455866977
31690290:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1 - BSY is now 1| 19:34:00.7 15455867035
31690330:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1 - BSY is now 1| 19:34:00.7 15455867093
31690370:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1 - BSY is now 1| 19:34:00.7 15455867151
looks like we've timed out here waiting for 55 and lost!
31690449:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455867267
31690523:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455867357
31690541:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455867357
31694581:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455877698
...
33825423:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:08.2 15461543969
33832481:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:08.2 15461563787
33832500:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:1 && P->last_cmd:1 if non zero, should see state transition.| 19:34:08.2 15461563787
33832516:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000016| 19:34:08.2 15461563815
33832536:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000016| 19:34:08.2 15461563815
33832588:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:34:08.2 15461563903
33832710:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:34:08.2 15461564105
33832739:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:34:08.2 15461564137
33832757:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0 - BSY is now 1| 19:34:08.2 15461564137
33832779:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1 - BSY is now 1| 19:34:08.2 15461564181
33832790:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1 - BSY is now 1| 19:34:08.2 15461564197
33832809:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1 - BSY is now 1| 19:34:08.2 15461564197
33832858:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564279
33833025:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564541
33833052:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564587
33833077:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564633
33833102:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564679
and we miss the command here, so we start over
34125776:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:1 && P->last_cmd:1 if non zero, should see state transition.| 19:34:09.2 15462332018
34125798:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000032| 19:34:09.2 15462332018
34126030:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1 - BSY is now 1| 19:34:09.2 15462332400
34126049:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1 - BSY is now 1| 19:34:09.2 15462332400
--- End code ---
rayarachelian:
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.png
I 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version