Print

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

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)

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

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       


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

Hmmm, I think I found something!

Nice detective work!

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?

Not that I know of, but I will look around.

[stepleton]

This is exciting!

I haven't looked at the code, but what's the reason not to kludge in your EASy68k assembler core? Are you looking for something different?

[rayarachelian]

Hmmm, I think I found something!

Nice detective work!

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?

Not that I know of, but I will look around.

Thanks. But there might be lots more, or this might be it. Too early to tell. and I need to revert the 32bit stuff as well, while re-merging all the new changes. So that smells painful.

This is exciting!

I haven't looked at the code, but what's the reason not to kludge in your EASy68k assembler core? Are you looking for something different?

Was looking for something... um, smaller and simpler. I guess I could strip a lot of it off. don't know if I have the patience to retrofit it, there's a lot of other stuff I'd rather spend cycles on.

It's weird, almost every 68k debugger has a disassembler, from macsbug to resedit, but almost none (except resourcerer, if I recall) have a mini-assembler.
I vaguely recall some DCMD existed to add an assembler to macsbug.

I recall the good old days of the commodore 128 which had a built in monitor (power on + hit run/stop) which had an assembler too and it was very useful.
Wanting something like that.

[D.Finni]

Could you use the portable GNU 68K assembler? I presume it's GPL licensed... 

m68k-linux-gnu-as

Or what about the A68K assembler?

[rayarachelian]

These might both be interesting. I'm looking for their source code now. I'd have to strip all the symbol handling and any listing output, S-records output and all the bells and whistles, etc. just want a plain parser that reads in a single line and produces 2-16 bytes of binary.

The EAS assembly might do, but too many source files and too much features to turn off. Might be the same with gas and a68k, but at least now I have some choices.

We can add Lisa related symbols from symbols.c which has some stuff from the ROM as well as the I/O devices and other stuff. Might be able to scan running code for symbols as well. But basically I only need it to do something like:

Code: [Select]

A 1/0012300 MOVE.L D0,D1


[D.Finni]

Could you open a pipe to the GNU assembler (or whichever binary is available) and pass it a couple lines, then get back its output?

[rayarachelian]

Could you open a pipe to the GNU assembler (or whichever binary is available) and pass it a couple lines, then get back its output?

Meh, I'd rather not, I'd rather compile it in. I think Generator has a lot of the stuff needed for an assembler built in, at least the decode side is there, so I'd need to write some code to recognize the various address modes and what opcode is used and then form the binary. Not as easy as that since there's a lot to do, but it would be doable eventually. I'd need to invert some of the tables it has or build an opcode tree that's searchable and returns patterns and masks, or something like that.

I looked over gas and a68 and they're more complex than I'm looking for sadly. Of the three, yeah, EASy68k is the simplest after all.

I think for a first pass, I'd skip the assembler bit.

So priority right now is:

1. "The opcode bug(s)"
2. reverting the 32 bit mode code + adapting the opcodes that need them - if it turns out that it doesn't need the high byte in the A regs, I may skip this altogether depending on whether fixing 1 is sufficient.
3. next RC release
4. blu+xprofile support+tools
5. pty support for the z8530
6. access to the host serial ports from z8530 (possibly pty is sufficient to launch cu or minicom, so maybe 3 isn't needed)
7. some other features I'd rather not disclose yet as i'm unsure about due to timing and feasibility.
8. rewriting the documentation
9. cleanup + prod release 1.2.7
10. debugger for 1.2.8
11 any other left over features that didn't make it in 1.2.7 before resurrecting the 1.3.0 cpu core and backporting all the fixes to it for 2.0

[rayarachelian]

So back to the debugger, I think I want to have a memory display pane with 4-5 buttons above it for contexts 0-4 (0=SIO space), and the last one for physical untranslated memory. I might either add the disassembler to the side of that as a separate frame, or perhaps as 6th button for the same window.

Then at the bottom would be a frame with the registers and some more info about the emulator, then below that another frame where you can type in commands.

I need to figure out how to make the memory window clickable/editable. Need something to find the size of the font and where the click is, etc.

Would this work for you? Is there any specific command or feature you'd like?

[D.Finni]

Is there any specific command or feature you'd like?

Yeah, that sounds good. I think that a memory dump with hex and ASCII would be good enough for now. I think it's better to get the absolute basics coded first, then start adding the fancy features next.

Just think: if you spent 4 months building a symbolic debugger that could parse heap zones, etc., you could probably reverse engineer and document the Lisa OS in the next 1 month.

[stepleton]

It's taking me about that long to do just the 2K of expansion card boot ROM on the AppleNet card 

[rayarachelian]

It's taking me about that long to do just the 2K of expansion card boot ROM on the AppleNet card 

Hint hint: I hear very good things about https://ghidra-sre.org/ - it does support the 68000.