General Category > LisaList2
LisaEm Debugger
D.Finni:
I use LisaEm on a weekly basis, and I often think about tracking down the CPU bug that's preventing Workshop from properly building applications.
It seems to me that adding a debugger to LisaEm would be beneficial both to tracking down this problem, and also in the long-run for dissecting the Lisa OS and applications.
Ray, why not start small by adding a window that shows the full 1 MB RAM dump in hex in one column, and ASCII in the other column?
Then you can add on to it: show the 68000's registers when the LisaEm is stopped/paused.
Then after that, why not add another window or column to the memory dump that is a disassembly of the respective word in memory?
rayarachelian:
That's not a bad idea, I had plans for this and there's a bit of code in there for that, but used it. I've mostly been using the tracelog mechanism.
I'm kinda close to finding "the bug" anyway. Or at least I think so.
It's one of these, I suspect RTE is a false positive. that JMP to a4c00118 is wrong, it should be a0 not a4. Of these DIVU is the most likely culprit.
--- Code: ---66627-3/a02206d2 DIVU.W D1,D0
66649-3/a0c04a7a DIVU.W #$000a,D5
6507-3/002e007c RTE
6550-3/a4c00118 JMP.L {PDIS:a4c03f12}=(PC+#$3dfa) src:a4c03f12 dst:00f80006
6587-3/a0221166 TST.W $e800(A7)
16271-3/0002289c MOVE.W 0(A0+D0.W),0(A1+D0.W)
--- End code ---
The current challenge is that to allow the high byte to work properly...
So two things seem to come up over and over again, DIVU.W has a mismatch in the "N" flag, which is interesting because this is unsigned division, so the N flag should be zeroed, except it does seem that real hardware sets it sometimes, but I'm unsure under what conditions exactly. The other bigger issue is that the high byte of the PC is being set to a0.
To allow for PC=a0xxxxxx, I increased the memory space allowed from 16MB to 4GB, but this is causing the mmu translation cache array to rise to 640MB from 2MB! This is an array of pointers to 512 byte pages that then connect to the MMU translation table and then to Instruction Parameter Caches (i.e. the operands passed to opcodes). Having done this successfully.
I'm looking at another possible way of solving this, by patching just those instructions that support addressing modes off of PC (Pidx + Pdis), which are going to be branch, jmp, jsr, lea, pea, dbra, and possibly a few others. I could alternately find a sparse array C library (can't use C++ here), but it's likely not worth the trouble and the general slowdown for everything else.
DIVU.W is kind of interesting because a few years back when Tom re-released his LisaMandelbrot app, we spent a bunch of time chasing DIVS, which didn't solve anything. Perhaps it was actually DIVU and not DIVS that was broken there... But the main goal of this is to get the LPW linker working properly which currently throws "Bad Intrin patch"...
Another possibility is to give up on libGenerator and switch to another CPU core, but this is a much harder task and requires finding a portable 68000 core that's GPL licensed, and also MMU friendly. This last part shouldn't be too difficult because luckily the 68000 requires memory space for I/O. But the license compatibility is likely an issue. and ofc, switching cores would likely introduce lots of new bugs and incompatibilities.
This: http://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=3023#p35357 seems very interesting, but skimming the code of Nemesis's exodus emulator, it seems to relies on LLVM which would basically shut out PPC as a platform (unless someone has backported it - maybe darwn ports?, I don't know) and certainly the announcement about the micro/nanocode emulation might be for another emulator core entirely. The license likely is also incompatible, though if it's worthwhile I may choose to change licenses.
UAE's core is certainly an option as it's GPL'ed and likely by now pretty accurate and might bring JIT features with it. I think it's also used for minivMac.
rayarachelian:
Hmmm, I think I found something!
--- Code: --- 6897 input regs D 0:00000052 1:ffff0050 2:00006700 3:00000000 4:00000004 5:ffff004a 6:ffff0028 7:00000029 ....... imsk:0
6898 A 0:00f7db36 1:00f7db36 2:000242cc 3:00cc874e 4:00deaaea 5:00f7faca 6:00f78f74 7:00f78f50 SP:00cc0000 PC:0002289c IR:33b0
6899
6900 output regs D 0:00000052 1:ffff0050 2:00006700 3:00000000 4:00000004 5:ffff004a 6:ffff0028 7:00000029 ....z.. imsk:0
6901 A 0:00f7db36 1:00f7db36 2:000242cc 3:00cc874e 4:00deaaea 5:00f7faca 6:00f78f74 7:00f78f50 SP:00cc0000 PC:000228a2 IR:33b0
6902
...
6908 read at 4/00f7db86(00120786 phys).W=00000000
6909 write at 4/00f7db86(00120786 phys).W=00000000 <- why is this copying from the same memory to the same memory?
6910 core cache [-16+16]: 0x0002288c 2007 e340 2206 e341 41ed e06c 43ed e06c 33b0 0000 1000 206d b184 2007 e540 226d | 'c."&cAAm`lCm`l30 0 m1$ 'e."m
6911 3/0002289c MOVE.W 0(A0+D0.W),0(A1+D0.W) <- opcode decode is wrong, 2nd operand should be A1+D1 not A1+D0!
A0=00f7db36+00000052+0 = F7DB88
A1=00f7db36+00000052+0 = F7DB88 <- A1+D1+0=100F6DB86!!!!
*** BINGO *** we found a busted opcode. Meh, the code around this is deep in the bowels of cpu68k.c and possibly tab68k.c - will take me a while to track it down and fix, but it's a find.
from ODA:
.data :0002288c 2007 movel %d7,%d0
.data :0002288e e340 aslw #1,%d0
.data :00022890 2206 movel %d6,%d1
.data :00022892 e341 aslw #1,%d1
.data :00022894 41ede06c lea %a5@(-8084),%a0
.data :00022898 43ede06c lea %a5@(-8084),%a1
.data :0002289c 33b000001000 movew %a0@(0000000000000000,%d0:w),%a1@(0000000000000000,%d1:w) <---- here
.data :000228a2 206db184 moveal %a5@(-20092),%a0
.data :000228a6 2007 movel %d7,%d0
.data :000228a8 e540 aslw #2,%d0
--- End code ---
rayarachelian:
So one thing I'd like to add to a potential debugger window would be an assembler, nothing fancy just a way to type in say 20000 NOP and hit enter and have the opcode written at that address, etc. But generator only has a disassembler. Is there GPL'ed C code out there you're aware of that I might be able to use?
The memory dump and disassembly + step, etc. aren't that hard to implement, once that window frame + scrollbars and associated logic is written.
D.Finni:
--- Quote from: rayarachelian on July 28, 2020, 11:20:40 pm ---Hmmm, I think I found something!
--- End quote ---
Nice detective work!
--- Quote from: rayarachelian on July 29, 2020, 09:42:04 am ---But generator only has a disassembler. Is there GPL'ed C code out there you're aware of that I might be able to use?
--- End quote ---
Not that I know of, but I will look around.
Navigation
[0] Message Index
[#] Next page
Go to full version