LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: 1 ... 4 5 [6] 7 8 ... 12   Go Down

Author Topic: LisaEm 1.2.7-RC4 support bug reports  (Read 53904 times)

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

D.Finni

  • Sr. Member
  • ****
  • Karma: +37/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-RC3 support bug reports
« Reply #76 on: August 23, 2020, 05:14:43 pm »

Here's another crash for you. This happens on 10.12.6.

ROMless Boot -> Choose ProFile Hard Drive -> click OK
Hard Drive Size? -> Click Cancel -> crash

This sequence however does not cause a crash when using a Lisa ROM file.

 Text file attached below.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3 support bug reports
« Reply #77 on: August 23, 2020, 07:09:52 pm »

Here's another crash for you. This happens on 10.12.6.

ROMless Boot -> Choose ProFile Hard Drive -> click OK
Hard Drive Size? -> Click Cancel -> crash

This sequence however does not cause a crash when using a Lisa ROM file.

 Text file attached below.

Great, thanks for finding this, thank you!
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #79 on: September 17, 2020, 08:12:00 am »

So been having fun implementing pty support for the serial ports. Some weird things:

0. Serial port A hangs LOS. I haven't been able to figure out exactly why, but regression testing shows this has been the case since at least LOS 1.0 beta. I've also found a bug in the fliflo (fifo+lifo library) that broke some serial access which I've fixed.

1. LisaTerm (or perhaps the OS itself) will chop off output after X characters of input, that is it will accept the first ~64 chars of input, and then discard the rest until it stops coming in and then accept more later. I haven't worked out the exact timing of these, so working on a bit of code, where if LOS is the active OS (I don't yet have a way to detect just LisaTerminal), it will slow the input down. I don't know how Xenix/UniPlus will behave, will revisit that once those OS's boot.

I tested this by running seq 100 200 - the output stops at "112" right before outputting the "2" character. Why 100-200 instead of 1 1000? Because this way, the output is exactly 5 bytes per line. The 3 number chars + cr+ new line. So this adds up to roughly 60 chars.

On another attempt I tried to output a string of text that was around 80 chars via echo and it stopped exactly at the 64th one. So that seems to be the size of the buffer. Changing the baud rate up doesn't affect this at all.

But wait! It gets worse!

2. ANSI color codes confuse it. Modern linux/macos  implementations insist on sending color, so setting TERM=vt100 is not enough. I can limit colors for things like ls and grep upto a point by setting environment variables before the execve bash, but not for everything.

As an example, ls -l itself will bold the output of some filenames right after the date/size, and LisaTerm discards the output immediately before the file name. Ditto for colorized grep.

3. Forget about using vi, it's horribly broken, the vt100 implementation in LisaTerm doesn't allow it to work properly. It can sort of work, but not quite. ed, or jed, haven't tried emacs, are your best bet.

4. I'm considering writing a small ANSI/xterm/vt100 escape sequence filter command line tool to remove color sequences and potentially any other things that break LisaTerminal by causing it to abort outputting text. It would have to do it's own fork/exec pty allocation. This way it can sit outside of LisaEm and be invoked by the user via preferences when pty is used.

I can build this into to LisaEm, but perhaps it might be more useful as a standalone unix cli filter tool.

I suppose this is analogous to ancient web browsers not understanding SSL, or modern HTML 1.x and requiring a filtering proxy in the form of a Raspberry Pi that connects to the outside world over wifi, and then presents TCP/IP traffic over SLIP/PPP for things like the MacPlus/SE or even MacWorks. :)

5. Using the default cooked output causes the pty to freeze, so the fix is to switch to raw before doing the execve, but then, the terminal is all messed up and I have to run stty sane to get echoing and other things to behave.

I'm adding back some of the options one by one of cooked/sane mode to the code to figure out which tcsetattr option is the culprit, but there's dozens of them.

I also seemed to have broken a couple of things in this effort:

1. BOOT ROM now throws an I/O error, so some of the z8530 behavior got messed up, and I'll need to fix that.

2. Mouse behavior in LOS, but not the BOOT ROM behaves as if everything is dragging, it's as if the mouse up event isn't being received even though it's sent and accepted by LOS, not sure what's going on there.

3. Still have XproFile/BLU/dc42 work to complete before RC4's release.


I think after I'm done with LisaEm 2.0, I'll work on a replacement LisaTerm program... one with XModem as well.




« Last Edit: September 17, 2020, 08:35:07 am by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #80 on: September 17, 2020, 02:39:48 pm »

Thanks for the hard work as usual. I'm tempted to connect my own 2/10's serial port to my laptop and see what happens if I run getty. I may report back if I do...

Can you elaborate on "LOS 1.0 beta"? Do you mean a LisaEm beta, or do you have an unreleased LOS kicking around?  :)

I know that LisaTerminal wasn't available until Lisa Office System 1.2, so it's not surprising to hear that serial stuff is a bit strange in Office System <=1.0...
Logged

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #81 on: September 17, 2020, 04:58:16 pm »

Things seem to work OK for me on real hardware. The only caveat is that you have to enable XOn/XOff software handshaking under "Computer Compatibility..." or else the computer can't even keep up with 2400 bps.

With that on, though, 19200 works all right. I've set $TERM to vt100 and `ls -l` will boldface certain files, but no usage issues. vi works fine as well, although it helps to resize the LisaTerminal window just a bit. See attached photo...
« Last Edit: September 17, 2020, 08:02:19 pm by stepleton »
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #82 on: September 18, 2020, 10:02:28 am »

Things seem to work OK for me on real hardware. The only caveat is that you have to enable XOn/XOff software handshaking under "Computer Compatibility..." or else the computer can't even keep up with 2400 bps.

Thanks for trying on real hardware, Tom.
Unfortunately, even with software handshaking on in LisaTerm, it still trims after 64 chars. I'm sending a lot quicker from the pty than real hardware ever could, so now it has to be slowed down to the point where LOS/LisaTerm doesn't discard the buffer, and I haven't yet found that exact threshhold.

I suppose the rationale for 64 bytes is that since the Lisa was so slow that it can't even do 2400bps as you've noticed, that 64 bytes were enough, and this is an issue caused by running LOS on too modern a system under emulation.

With that on, though, 19200 works all right. I've set $TERM to vt100 and `ls -l` will boldface certain files, but no usage issues. vi works fine as well, although it helps to resize the LisaTerminal window just a bit. See attached photo...

Oh I see, I'm guessing you weren't connected to a linux system in that photo or had already disabled color in vi itself.
It seems that in Linux, vt100's termcap is considered color vs BSD's termcap which correctly sets vt100 as mono. see this thread: https://unix.stackexchange.com/questions/58982/disable-colours-on-terminal-and-ssh#comment81353_58992, and the screenshot below, as well as about grep and ls not honoring even xterm-nocolor further in down this reply.

There's some details on disabling color in various CLI tools, here as well as a proposed new variable to disable color, which various tools might|not honor: https://no-color.org/

I've fixed the "stty sane" issue, now that I'm setting these termios after cfmakeraw. That fixed a lot of the issues, including the hanging on startup when cfmakeraw isn't invoked:

Code: [Select]
  new_term_settings.c_iflag |= ICRNL | IXON;
  new_term_settings.c_oflag |= OPOST;
  new_term_settings.c_lflag |= ECHO | ECHOCTL  | ECHOE | ECHOK | ECHOKE |ICANON | ISIG;
...
    setenv("TERM","vt100",1); // LisaTerm, Xenix, UniPlus aren't going to understand modern xterm-color256 here.
    setenv("NO_COLOR","nocolor",1);
    setenv("LS_COLORS","none",1); // color output breaks LisaTerm.
    setenv("GREP_OPTIONS","--color=never",1);
    setenv("LC_ALL","C",1);

I guess it depends on which vi, you're using. There's, vim, nvi, elvis, and ofc the original BSD vi written by Bill Joy (which is exceedingly rare now). Default on ubuntu is vim. Telling vim to not use color is a setting that has to be done via vimrc or command line before your launch it - So, I can't set it via a var, nor can I set aliases before doing a fork - at least I'm not aware of a way.
It's also likely that vim would work, but because it might be sending more than 64 chars on startup in a single burst, it's causing LisaTerm to discard the rest and leaving the terminal display in a bad state. I'll still have to fix that pacing issue before I'll know for sure.

In terms of disabling color, it's actually a big mess.
Setting TERM=xterm-nocolor doesn't work for everything either, for example, neither grep nor ls honor that if their default options were set to do color.
ls doesn't remove colors unless LS_COLORS is unset. and
Code: [Select]
alias grep='grep --color=auto' being the default setting for modern linux.

The bolding done by ls and grep inplace of color, when color is turned off doesn't seem to be an issue for LisaTerm. So at least that's good.

It seems the solution is to build a .bashrc/.bashprofile specific for use with LisaTerm with aliases for things like vim, grep, etc. and have the user use that with LisaEm.
Also, while GREP_OPTIONS apparently work to disable color, but grep now throws a warning saying it's deprecated  >:( , so I'll have to remove that one:
Code: [Select]
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ export GREP_OPTIONS="--color=never"
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ alias grep
alias grep='grep --color=auto'
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ unalias grep
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ grep lisa pty.log                 
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
src/lisa/io_board/z8530-pty.c:init_child:126 port:-25024 slave_orig_term_settings: c_iflag: 00000500
Perhaps the thinking, if there was any, is that it's 2020, and you're unlikely to be using a monochrome terminal, and if you are these tools will rely on your terminal ignoring color codes rather than behaving badly...

I suppose I could implement the "authentic" thing and see what baud rate is being set and pace it to that limit, that might be a good option.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

blusnowkitty

  • Sr. Member
  • ****
  • Karma: +69/-0
  • Offline Offline
  • Posts: 244
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #83 on: September 18, 2020, 12:06:59 pm »

For what it's worth, I watched a video by curiousmarc not too long ago where they interfaced an antique Baudot TTY to a modern Linux PC with the help of an Arduino to do the vt100 to Baudot conversion, and also to act as a buffer so they wouldn't overwhelm the TTY. There was probably also stuff in there to strip modern-day colour and control codes too. Maybe that could be an option for LisaEm - buffer modern input and strip colour before it gets to the Lisa?
« Last Edit: September 18, 2020, 12:09:54 pm by blusnowkitty »
Logged
You haven't lived until you've heard the sound of a Sony 400k drive.

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #84 on: September 18, 2020, 02:23:10 pm »

For what it's worth, I watched a video by curiousmarc not too long ago where they interfaced an antique Baudot TTY to a modern Linux PC with the help of an Arduino to do the vt100 to Baudot conversion, and also to act as a buffer so they wouldn't overwhelm the TTY. There was probably also stuff in there to strip modern-day colour and control codes too. Maybe that could be an option for LisaEm - buffer modern input and strip colour before it gets to the Lisa?

That's exactly the plan. It might just be the modern 256/24 bit color xterm stuff that confuses LisaTerm, but right now the biggest issue is pacing. If color is still an issue after I slow things down and find an acceptable rate to avoid tripping that 64 char limit, I'll write a small filter program to strip out color codes as well. I might also build the color stripping into LisaEm itself as that'll likely be more efficient than having to allocate a second pty, and/or provide an external program to do that also - in that thread there seems to be interest in such a tool and it might be useful for other projects too.

Maybe I'll add a checkbox to the Serial Ports to honor guest bps rate, if that's checked it should slow down I/O to whatever LisaTerm sets, but if it's not it should only slow it down whenever LOS is running, and only to whatever the maximum is before it drops characters.

So more experimentation to do to figure out what works and what's possible.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

D.Finni

  • Sr. Member
  • ****
  • Karma: +37/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #85 on: September 18, 2020, 02:40:23 pm »

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.
Logged

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #86 on: September 18, 2020, 03:53:35 pm »

Code: [Select]
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)

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.
« Last Edit: September 18, 2020, 03:59:39 pm by stepleton »
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #87 on: September 23, 2020, 08:53:25 am »

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.

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: [Select]
printf "\x1b[38;5;106m 256 green\n"

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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #88 on: October 18, 2020, 10:54:55 am »

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: [Select]
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

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: [Select]
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
« Last Edit: October 31, 2020, 05:15:30 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #89 on: October 31, 2020, 05:15:57 pm »

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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code
Pages: 1 ... 4 5 [6] 7 8 ... 12   Go Up