LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

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

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

D.Finni

  • Sr. Member
  • ****
  • Karma: +37/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #90 on: November 01, 2020, 05:46:59 pm »

I vote continue with Xenix-- you're clearly on a roll! :-)
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 #91 on: November 04, 2020, 11:23:38 pm »

Yeah, so it looks like after the write happens VIA #2, timer 1 gets fired, it causes an IRQ, and then it prints the bad state message when it sees that it's last request is completed. So either T1 shouldn't have been fired, or perhaps the emulated profile is way too fast. I'll have to write some more debug code to log where T1 is being set and for how long and what mode T1 is in and figure out whether or not it's supposed to actually fire or not.

I can't tell if it's supposed to fire or not yet, only that right before it goes into the code that checks the profile state, it looked at whether or not the Profile disk enabled line is on, and then it looked at the IFR for VIA2 saw that IFR bit 7 was on, and that the T1 fired bit was also on, and right after that it prints pfcmd bad state: 0306 via the printf call.

A quick hack might be to disable T1 after the last status byte is read (but reading from the port should have cleared the IRQ anyway, so that too might be the bug here.)

So not sure if it's set T1 what mode it set it in, and whether or not it should have fired, or if in Xenix it should have fired first to allow it to read the status rather than wait for BSY to flip.

(fixing this won't mean that Xenix will boot, there might be onion layers worth of bugs, or it might just be this one. Will find out soon enough.)
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 #92 on: November 06, 2020, 08:16:22 am »

Far as I can tell, VIA #2 Timer 1 is NEVER set anywhere in the tracelog - all the regs stay at zero - which means it should be disabled, and the cpu clock expiration for it is -1, so it should never be fired, however the counters for it say it was fired multiple times, so there's a bug somewhere in the code that calculates timing of when this was fired, and worse, the IFR flag for it isn't cleared on read.

So for sure this is a bug in the VIA 2 timer handling code, or in irq.c

Code: [Select]
1497875:via2 T1 Control: 00 Timed IRQ each time T1 Loaded, PB7 Disabled
1497904:via2 reg[4]=00 T1CL     
1497905:via2 reg[5]=00 T1CH     
1497906:via2 reg[6]=00 T1LL     
1497907:via2 reg[7]=00 T1LH     
1497931:via2 T1 cpu_68k clk expiration:ffffffffffffffff cpu68k_clocks:0000000058b2bb0b t1_fired:8 times
...
5536358:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5536421:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5538925:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5538982:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5539051:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5541541:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5541598:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5541661:VIA2 IFR: (fired IRQ's): CA1 TIMER1
5544185:VIA2 IFR: (fired IRQ's): CA1 TIMER1
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 #93 on: November 06, 2020, 07:45:23 pm »

Yup, Xenix will be an onion of bugs, not a single layer, I fixed the IFR issue that was incorrectly tagging TIMER1 when TIMER1 was actually off, however, now it just sits at the "Entering System Maintenance" text, no shell is shown, no menu is shown, I don't think it gets far enough to run init.
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 #94 on: November 06, 2020, 07:59:56 pm »

Yup, Xenix will be an onion of bugs, not a single layer
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! :-)
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 #95 on: November 06, 2020, 09:44: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! :-)

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.
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 #96 on: November 06, 2020, 10:00:00 pm »

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!
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 #97 on: November 07, 2020, 12:27:49 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.
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.
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 #98 on: November 07, 2020, 03:55:57 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.

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.
« Last Edit: November 07, 2020, 03:58:45 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 #99 on: November 07, 2020, 05:45:48 pm »

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

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

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. :)
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 #100 on: November 08, 2020, 11:20:13 am »

So I'm glad I went down this rabbit hole. There's either a bug in UniPlus or in LisaEm, or a much earlier bug related to setting the MMU incorrectly.

There's this code here (the line numbers, which come from vim, won't match since this is a new run:

Code: [Select]
43162051
43162052 1/00010986 (0 0/0/0) : 4eb9 0002 452c             : N...E.   :  756 : JSR.L      $0002452c  SRC:clk:000000006bc6bc8c +20 clks
43162053 src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 0001098c ' BJM' to @1/00fa07b4  using 17-ram| 20:00:06.2 1808186508
43162054 D 0:0003c000 1:00000009 2:000fffff 3:0000000b 4:0000ffff 5:00000073 6:00000010 7:000001dd .S..... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
43162055 A 0:0003be00 1:00065669 2:0006d600 3:0000017c 4:00157e00 5:0003c000 6:00fa07c0 7:00fa07b4 SP:00000000 PC:0002452c SRC:
43162056

This JSR pushes the next PC to return from (0001098c) to the stack at address 1/00fa07b4. When this routine is called, it zeroes out memory. This is important because there's no write to 1/00fa07b4 during that routine at all. However, when we get to the RTS, we get:

Code: [Select]
43162412 1/000245a2 (0 0/0/0) : 4e75                       : Nu       :  749 : RTS          SRC:clk:000000006bc6be1a +20 clks
43162413 src/lisa/cpu_board/memory.c:dmem68k_fetch_long:458::::::READ LONG 00000000 '    ' from @1/00fa07b4 (@00fa07b4) using 17-ram| 20:00:06.2 1808186906
43162414 reg68k.c:reg68k_external_execute:1768:pc=0 LastPC24=00011284 pc24=00000000 abort_opcode:0| 20:00:06.2 1808186926
43162415 D 0:00000000 1:00000000 2:00000000 3:00000000 4:00000000 5:00000000 6:00000000 7:00000000 .Szx... imsk:7 pnd:2 (0/0/normal cx:1)SRC:
43162416 A 0:0003c100 1:00000000 2:00000000 3:00000000 4:00000000 5:00000000 6:00000000 7:00fa07b8 SP:00000000 PC:00000000 SRC:

So here, a zero is read from @1/00fa07b4 - and yet, nothing in the tracelog shows a write to that address which clobbered the return address and replaced it with a zero. Either something has clobbered LisaEm's Lisa RAM array, or there's some MMU segment that points to the back end physical RAM that got overwritten by the zero fill routine. I'll have to compile in some extra one-off code in LisaEm to track this down.

But I suspect this is a legitimate bug somewhere in my code that hasn't been exposed before, possibly related to the way the stack is handled in the MMU.

Edit: Yup confirmed, one of the zero out writes has a physical address that overlaps with the physical address of the stack space.
« Last Edit: November 08, 2020, 12:57:00 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

D.Finni

  • Sr. Member
  • ****
  • Karma: +37/-0
  • Offline Offline
  • Posts: 135
Contrast bug report
« Reply #101 on: November 10, 2020, 11:26:50 am »

New bug report: high end settings of screen contrast will turn the screen yellow. This is in the Lisa Monitor system settings. I think it allows a greater range than the Workshop's contrast.

This yellow is from increase.
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 #102 on: November 10, 2020, 01:31:28 pm »

New bug report: high end settings of screen contrast will turn the screen yellow. This is in the Lisa Monitor system settings. I think it allows a greater range than the Workshop's contrast.

This yellow is from increase.

Nice one! Thanks!
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 #103 on: November 10, 2020, 04:46:06 pm »

New bug report: high end settings of screen contrast will turn the screen yellow. This is in the Lisa Monitor system settings. I think it allows a greater range than the Workshop's contrast.

This yellow is from increase.

Nice one! Thanks!
Yeah, that didn't seem like correct behavior to me, so I thought I ought to report it.  :P

Also I have a feature request:

If there is a DC42 image that is longer than the DC42 header says it should be, LisaEm throws an error about this case. Could you modify DC42 to ignore the extra data, and work within the DC42 header length instead? Maybe just show a warning, like you do for a checksum mismatch, but allow the user to continue using the disk.

For example, disk images made with BLU often have $1A padding at the end because no one stripped it off before uploading to Bitsavers.
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 #104 on: November 10, 2020, 05:52:37 pm »

Yeah, that didn't seem like correct behavior to me, so I thought I ought to report it.  :P

Also I have a feature request:

If there is a DC42 image that is longer than the DC42 header says it should be, LisaEm throws an error about this case. Could you modify DC42 to ignore the extra data, and work within the DC42 header length instead? Maybe just show a warning, like you do for a checksum mismatch, but allow the user to continue using the disk.

For example, disk images made with BLU often have $1A padding at the end because no one stripped it off before uploading to Bitsavers.

Sure, thanks for the reports, those are appreciated I'll fix these.

I suspect something over/underflowed from the contrast over the color values.

Yeah, the size detection change will have to be in libdc42 ofc as you've noted. I had to add a workaround for short images a year or two ago as a few images were shorter than 400k, so I guess it should be less strict the other way too.

Edit: I've made changes to libdc42 for this, hopefully it will take care of the issue, this will need testing.
working on fixing stack MMU segments now, will revisit the monitor issue after that - tried monitor last night and it immediately crashed so either the MMU changes broke it, or it's a broken image. Will retest this again when I've got the MMU working again.
« Last Edit: November 11, 2020, 02:20:16 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
Pages: 1 ... 5 6 [7] 8 9 ... 12   Go Up