General Category > LisaList2

LisaEm 1.2.7-RC4 support bug reports

<< < (10/34) > >>

rayarachelian:

--- Quote from: stepleton on June 12, 2020, 09:26:55 pm ---what's described here sounds like it may be able to use parts from this old project: https://github.com/stepleton-xx/lisabbs.

--- End quote ---

Yeah, looks like you've got a lot, if not all, of the needed pieces in there to build the implant tool. I can do the rest of the stuff on the outside, such as finishing off scriptability in LisaEm and the HLE traps to communicate with it.

rayarachelian:
Looks like there's a bug with screenshots when it builds the list of file filters i.e. *.png, *.jpg, etc. when more than one file type is available to the build. Fixing that now. It will be a part of the next release candidate along with other fixes/features.

rayarachelian:
For the last two weeks I've been vetting the LisaEm CPU core and found a minor issue in the CHK opcode, and a false positive in MOVEFUSP (really MOVE USP,d0) and the STOP opcodes. Fixing the CHK one did not fix the Desktop menu, scrollbars, or LPW linker issue.

This leads me to believe the bug either happens much earlier on in the boot process, or it's part of something outside of the CPU such as IRQ handling, timing, or I/O.

Edit: I've been using ODA as a sanity check to the libGenerator disassembler, it's not perfect, but it works and it's pretty helpful. Here's a sample with the CHK opcode, incase anyone is curious or wants to play with it: https://onlinedisassembler.com/odaweb/G6w3LNQS/0

D.Finni:

--- Quote from: rayarachelian on July 13, 2020, 01:37:38 pm ---For the last two weeks I've been vetting the LisaEm CPU core and found a minor issue in the CHK opcode, and a false positive in MOVEFUSP (really MOVE USP,d0) and the STOP opcodes.

--- End quote ---
Nice work finding those gremlins!

rayarachelian:
Last night found another bug via CPU core testing, so before 1.2.7 betas I found out that I shouldn't be filtering out the MSB of the A regs, but I looks like I had missed some
--- Code: ---regs_pc &=0x00ffffff;
--- End code ---
or similar filter somewhere that strips the MSB of the PC.

(Background the 68000 cannot access 32 bits of address space, so the top byte is filtered out, however, it seems LOS, like early Mac OS stores flags there. This is why the 32-bit enabler was needed for classic macos when the switch to 030 CPUs was introduced, and why machines like IIcx were not 32-bit clean, but the IIci and IIsi were.)

(forgive the weird disassembly output here)

--- Code: ---3/a0220294 JMP.L      {PDIS:00220b26}=(PC+#$0892)

--- End code ---

This results in PC going to 00220b26 rather than a0220b26, however the offending code isn't the JMP opcode, but somewhere else that I haven't yet located, possibly entering/leaving the emulation timing loop. Not sure what this, if anything will fix, but it is an actual bug.

Basically there's a huge JMP table in this address space used by various OS routines or perhaps libraries, and the "a0" is meaningful as this is also an A-Line trap that maps to exactly that address - it's actually a JMP anywhere trampoline. So if you execute opcode a0220b26 it will effectively through some gymnastics wind up being a JMP to the a0220b26 address, which is a relative JMP to the actual routine.

[So this is a compatibility layer that allows the OS or this library to be updated, but to keep the same ABI. A similar thing happens with the boot ROM but to a lesser level and without the A-line trap. The A-line trap also turns on the S flag, so this potentially could be used to gain supervisor access to the OS if you find a way to fool the trap to return without clearing the S-flag]

Navigation

[0] Message Index

[#] Next page

[*] Previous page