General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
rayarachelian:
--- Quote from: D.Finni on November 06, 2020, 07:59:56 pm ---Yeah, I think we were all suspecting that would be the case, but didn't want to spoil the mood. :-P
But don't worry: the cause of all bugs is down to a single 68000 instruction. You only need to find which particular instruction is at fault, take correction, and move on to the next bug! :-)
--- End quote ---
Eh, not likely to be a CPU issue, most likely something to do with the VIA or IRQ code. If there's one bug there, there's likely others.
rayarachelian:
While testing the changes to the via, I thought I'd give UniPlus another try. I noticed it was trying to execute an illegal opcode, so rather than stopping the emulator, I modified it to allow for illegal opcodes and allow it to follow the ILLEGAL trap. Not sure if it's supposed to execute an illegal instruction or not, but thought I'd give it a shot and was rewarded with the double panic in the screenshot below.
So not much progress, but some progress is still progress. Minor win, yeay!
D.Finni:
--- Quote from: rayarachelian on November 06, 2020, 10:00:00 pm ---I noticed it was trying to execute an illegal opcode, so rather than stopping the emulator, I modified it to allow for illegal opcodes and allow it to follow the ILLEGAL trap. Not sure if it's supposed to execute an illegal instruction or not, but thought I'd give it a shot and was rewarded with the double panic in the screenshot below.
--- End quote ---
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.
rayarachelian:
--- Quote from: D.Finni on November 07, 2020, 12:27:49 pm ---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.
--- End quote ---
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.
rayarachelian:
Looking at the tracelog for UniPlus, looks it did run away and hit an F-Line opcode by accident, that's one of the two exceptions mentioned.
Somehow it started executing from address 0 which ofc is where the exception vectors live.
This happened immediately after an RTS opcode which means that it pulled a 00000000 off the stack and set PC to it.
Wheeee!
Hmmm, unfortunately I don't see a set of 8-10 EOR opcodes in a row, too bad, I used this to find the cursor routines in both Xenix and LPW.
I do see it set the video latch to 3b which maps video RAM to physical address 001d8000 which helps a bit, but will take more work to locate as the MMU will change this address to some other one.
I don't see a push followed by a JSR where the push contains a single character to print to the display as in Xenix, so too bad there as I have a nice grep expression to find that and could have spotted the text that's printed to the console that way.
However I did find an ADDA.W #$005a,A5 where #$5a is 90, which is the number of bytes per video row, so that code is likely involved in writing to the display and that code is in a DBRA loop which is another strong indicator. I also see that the DBRA loop has 7 iterations, which would fit 8 lines by 8 pixels across which strongly indicates a font character being copied from a font table to the video memory. And that 7 is hardcoded via a MOVE.
--- Code: --- 268944
268945 1/0006338a (0 0/0/0) : 7a07 : z. : 1064 : MOVE.L #7,D5 SRC:clk:00000000c31b9bb5 +12 clks
268946 D 0:00000298 1:0000001b 2:000fffff 3:0000000b 4:0000ffff 5:00000007 6:0000001b 7:0000000b .S..... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
268947 A 0:00062296 1:0006566a 2:0006d600 3:00064410 4:00064de0 5:0015a2e9 6:00068a48 7:00068a34 SP:00000000 PC:0006338c SRC:
268948
268949
268950
268951 1/0006338c (0 0/0/0) : 4ab9 0006 48b4 : J...H. : 714 : TST.L $000648b4 SRC:clk:00000000c31b9bc1 +20 clks
268952 src/lisa/cpu_board/memory.c:dmem68k_fetch_long:458::::::READ LONG 00000000 ' ' from @1/000648b4 (@000648b4) using 17-ram| 11:50:03.0 3273366465
268953 D 0:00000298 1:0000001b 2:000fffff 3:0000000b 4:0000ffff 5:00000007 6:0000001b 7:0000000b .Sz.... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
268954 A 0:00062296 1:0006566a 2:0006d600 3:00064410 4:00064de0 5:0015a2e9 6:00068a48 7:00068a34 SP:00000000 PC:00063392 SRC:
268955
268956 1/00063392 (0 0/0/0) : 6710 : g. : 1054 : BEQ.B $000633a4 SRC:clk:00000000c31b9bd5 +8 clks
268957 D 0:00000298 1:0000001b 2:000fffff 3:0000000b 4:0000ffff 5:00000007 6:0000001b 7:0000000b .Sz.... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
268958 A 0:00062296 1:0006566a 2:0006d600 3:00064410 4:00064de0 5:0015a2e9 6:00068a48 7:00068a34 SP:00000000 PC:000633a4 SRC:
268959
268960
268961
268962 1/000633a4 (0 0/0/0) : 1a9c : .. : 248 : MOVE.B (A4)+,(A5) SRC:clk:00000000c31b9bdf +12 clks
268963 src/lisa/cpu_board/memory.c:dmem68k_fetch_byte:406::::::READ BYTE 00 ' ' from @1/00064de0 (@00064de0) using 17-ram| 11:50:03.0 3273366495
268964 src/lisa/cpu_board/memory.c:dmem68k_store_byte:484::::::WRITE BYTE 00 ' ' to @1/0015a2e9 using 17-ram| 11:50:03.0 3273366495
268965 D 0:00000298 1:0000001b 2:000fffff 3:0000000b 4:0000ffff 5:00000007 6:0000001b 7:0000000b .Sz.... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
268966 A 0:00062296 1:0006566a 2:0006d600 3:00064410 4:00064de1 5:0015a2e9 6:00068a48 7:00068a34 SP:00000000 PC:000633a6 SRC:
268967
268968 cpu68k.c:cpu68k_ipc:612:dt_ImmW @ 000633a8 target:0000005a opcode:dafc| 11:50:03.0 3273366507
268969 1/000633a6 (0 0/0/0) : dafc 005a : ...Z : 1466 : ADDA.W #$005a,A5 SRC:clk:00000000c31b9beb +12 clks
268970 D 0:00000298 1:0000001b 2:000fffff 3:0000000b 4:0000ffff 5:00000007 6:0000001b 7:0000000b .Sz.... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
268971 A 0:00062296 1:0006566a 2:0006d600 3:00064410 4:00064de1 5:0015a343 6:00068a48 7:00068a34 SP:00000000 PC:000633aa SRC:
268972
268973 cpu68k.c:cpu68k_ipc:491:i_DBcc/DBRA @ 000633aa target:000633a4 opcode:51cd| 11:50:03.0 3273366519
268974 1/000633aa (0 0/0/0) : 51cd fff8 : Q... : 1031 : DBRA.W #$633a4,D5 SRC:clk:00000000c31b9bf7 +10 clks
268975 D 0:00000298 1:0000001b 2:000fffff 3:0000000b 4:0000ffff 5:00000006 6:0000001b 7:0000000b .Sz.... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
268976 A 0:00062296 1:0006566a 2:0006d600 3:00064410 4:00064de1 5:0015a343 6:00068a48 7:00068a34 SP:00000000 PC:000633a4 SRC:
268977
--- End code ---
So there we go, that's part of the drawing code. Now I'll have to scroll up to see how this routine was entered and what was passed to it - the entry point should contain some ASCII character value at some point, and depending on how it was coded, might be a TRAP or a LINEA or just a JSR.
Once I have that, I can write a bit of grep-fu to locate this call and its parameters and map out what's printing at what line in the log. This can help me figure out what error messages are printed where and thus, get a hint of what the code is before those messages are.
Indeed, there's a few wrapper functions that strip off chars less than 32 and above 127 etc. before it looks up the font bytes, but eventually I find out that.... yup, it is just a JSR after all as you can tell by the values passed:
--- Code: ---$ grep -n --before-context=4 'JSR.L $00062d0c' lisaem-output.001-00062140.00000000c3117f1b.txt | grep 'WRITE'
259291-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000000d ' N' to @1/00068aec using 17-ram| 11:50:03.0 3273344773
260232-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000000a ' K' to @1/00068aec using 17-ram| 11:50:03.0 3273346615
266728-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000073 ' s' to @1/00068a6c using 17-ram| 11:50:03.0 3273361637
267751-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000006e ' n' to @1/00068a6c using 17-ram| 11:50:03.0 3273363769
268705-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000073 ' s' to @1/00068a6c using 17-ram| 11:50:03.0 3273365901
269681-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000074 ' t' to @1/00068a6c using 17-ram| 11:50:03.0 3273368033
270704-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000072 ' r' to @1/00068a6c using 17-ram| 11:50:03.0 3273370165
271658-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000061 ' a' to @1/00068a6c using 17-ram| 11:50:03.0 3273372297
272612-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000074 ' t' to @1/00068a6c using 17-ram| 11:50:03.0 3273374429
273650-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000065 ' e' to @1/00068a6c using 17-ram| 11:50:03.0 3273376561
274604-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000067 ' g' to @1/00068a6c using 17-ram| 11:50:03.0 3273378693
275558-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000079 ' y' to @1/00068a6c using 17-ram| 11:50:03.0 3273380825
276581-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000003a ' :' to @1/00068a6c using 17-ram| 11:50:03.0 3273382957
277535-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000020 ' ' to @1/00068a6c using 17-ram| 11:50:03.0 3273385089
278489-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000062 ' b' to @1/00068a6c using 17-ram| 11:50:03.0 3273387221
279512-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000006e ' n' to @1/00068a6c using 17-ram| 11:50:03.0 3273389353
280466-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000003d ' =' to @1/00068a6c using 17-ram| 11:50:03.0 3273391485
282342-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000032 ' 2' to @1/00068a0c using 17-ram| 11:50:03.0 3273396789
283414-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000035 ' 5' to @1/00068a24 using 17-ram| 11:50:03.0 3273399461
284554-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000030 ' 0' to @1/00068a3c using 17-ram| 11:50:03.0 3273402133
285625-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000032 ' 2' to @1/00068a54 using 17-ram| 11:50:03.0 3273404805
286615-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000020 ' ' to @1/00068a6c using 17-ram| 11:50:03.0 3273407017
287653-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000072 ' r' to @1/00068a6c using 17-ram| 11:50:03.0 3273409149
288607-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000065 ' e' to @1/00068a6c using 17-ram| 11:50:03.0 3273411281
289561-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000073 ' s' to @1/00068a6c using 17-ram| 11:50:03.0 3273413413
290584-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000069 ' i' to @1/00068a6c using 17-ram| 11:50:03.0 3273415545
291538-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000064 ' d' to @1/00068a6c using 17-ram| 11:50:03.0 3273417677
292492-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0000003d ' =' to @1/00068a6c using 17-ram| 11:50:03.0 3273419809
294243-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000035 ' 5' to @1/00068a24 using 17-ram| 11:50:03.0 3273424475
295448-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000031 ' 1' to @1/00068a3c using 17-ram| 11:50:03.0 3273427147
296584-src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00000032 ' 2' to @1/00068a54 using 17-ram| 11:50:03.0 3273429819
...
--- End code ---
So yeah, 'JSR.L $00062d0c' is PUTCHAR, but only in the boot loader. I'll have to continue this until I find out where the equivalent code is in the kernel.
But yeah, and that's how this kind of sausage is made. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version