General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
rayarachelian:
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: ---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
--- End code ---
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: ---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:
--- End code ---
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.
D.Finni:
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.
rayarachelian:
--- Quote from: D.Finni 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.
--- End quote ---
Nice one! Thanks!
D.Finni:
--- Quote from: rayarachelian on November 10, 2020, 01:31:28 pm ---
--- Quote from: D.Finni 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.
--- End quote ---
Nice one! Thanks!
--- End quote ---
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.
rayarachelian:
--- Quote from: D.Finni on November 10, 2020, 04:46:06 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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version