Print

[rayarachelian]

what's described here sounds like it may be able to use parts from this old project: https://github.com/stepleton-xx/lisabbs.

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]

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.

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

regs_pc &=0x00ffffff; 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: [Select]

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

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]

[rayarachelian]

Another thing I've noticed is that inside the OS, I do see it using the CLR opcode. I remember recently reading some workshop docs that says that the assembler will internally replace CLR opcodes with MOVEQ 0, but I do see CLR used while I test, and as usual it does do the read before the write, which is inefficient.

So either this portion of code was created outside of that, or was form a much earlier assembler/code generator, or the pascal compiler doesn't do that.

And yeah, the PC here should be a02206ac as mentioned above

Code: [Select]

read at 1/00f7d912(0011b512 phys).L=dce800f7
write at 1/00f7d912(0011b512 phys).L=00000000
core cache [-16+16]: 0x0022069c:6704 5340 4219 3200 e448 6700 000a 5340 4299 51c8 fffc 0801 0001 6702 4259 0801  | g$S.B92 dHg  *S.B9QH.|(! !g"BY(!
0/002206ac CLR.L      (A1)+


[D.Finni]

Another thing I've noticed is that inside the OS, I do see it using the CLR opcode. I remember recently reading some workshop docs that says that the assembler will internally replace CLR opcodes with MOVEQ 0, but I do see CLR used while I test, and as usual it does do the read before the write, which is inefficient.

By coincidence, I was reading those Workshop docs an hour ago, and they say the opposite: MOVEQ #0 is replaced by CLR. This optimization causes some problems when accessing hardware because CLR causes two memory accesses.

[rayarachelian]

By coincidence, I was reading those Workshop docs an hour ago, and they say the opposite: MOVEQ #0 is replaced by CLR. This optimization causes some problems when accessing hardware because CLR causes two memory accesses.
[/quote]

Hmm, I possibly misread/misremembered it then.

[rayarachelian]

So it's worse than I though, this entire addressing mode is messed up, but now I've narrowed down its location.

Code: [Select]

                lisa_ww_ram(0x20000,0x33b0); lisa_ww_ram(0x20002,0x0002); lisa_ww_ram(0x20004,0x1004); test_an_opcode_a(0x30000, 0x400000,d0,d1,k);
                lisa_ww_ram(0x20000,0x47F1); lisa_ww_ram(0x20002,0x1004); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F1 1004   lea  4(A1,D1.W),A3
                lisa_ww_ram(0x20000,0x47F0); lisa_ww_ram(0x20002,0x1002); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F0 1002   lea  2(A0,D1.W),A3
                lisa_ww_ram(0x20000,0x47F1); lisa_ww_ram(0x20002,0x0008); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F1 0008   lea  8(A1,D0.W),A3
                lisa_ww_ram(0x20000,0x47F0); lisa_ww_ram(0x20002,0x000A); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F0 000A   lea  10(A0,D0.W),A3

All of these replace the D1 register with D0. It properly picks the A register as A0 or A1, but the D register is always D0.
I'd guess if I chose D7 or D2, it would show up as D0 anyway, and the disassembly is wrong too. In the 2nd code block below it should be D1 not D0

Code: [Select]


       regs D 0:00000004  1:000000cc  2:deadbeef  3:deadbeef  4:deadbeef  5:deadbeef  6:deadbeef  7:deadbeef  .S..z.. imsk:3
            A 0:00030000  1:00400000  2:deadbeef  3:0040000c  4:deadbeef  5:deadbeef  6:deadbeef  7:00040000  SP:00040000  PC:00020004  IR:47f1

 read at 1/00020012(000a0012 phys).W=00004efa
core cache [-16+16]: 0x0001fff0:ffff ffff ffff ffff ffff ffff ffff ffff 47f1 0008 1004 4e71 4e71 4e71 4e71 4e71  | ................Gq (0$NqNqNqNqNq
0/00020000 LEA.L      8(A1+D0.W),A3

ipc-opcode:47f1 used/set:00/00 wordlen:2 src:dst: 00000008 00000000 reg:0000
iib: mask/bits:f1f8/41f0 len:2 size:3 s/dtype:6/1 s/dbitpos:0 immvalue:00000009/0 cc:0
iib: priv:0 endblk:0 notzero:0 used:0 set:0, fn:0^^------------------------------------------------------------------------------------------------------------vv

Actually, yeah, if I change the opcode to use D7, it still shows up as D0. That's the bug, it's not decoding the data register portion in this address mode properly.
It's dt_Aidx in the code.

[rayarachelian]

bug has been fixed, linker works now, scrollbars and desktop menu are good.
Will take me a few days to rollback the pc24->pc32 changes and test if it breaks anything, the will push to github + push another RC, etc.

[jamesdenton]

Fantastic work! Congrats!

[stepleton]

Congratulations!! This will be huge for people who want to try making Lisa software. It's going to be a lot easier to experiment with the ToolKit now.

[rayarachelian]

Thanks guys. I'll clean up the source after work and start rolling back the 32 bit to 24 bit tonight, if it still works fine in 24 bit mode, I won't pursue fixing the high byte of PC anymore, though it might turn out that uniplus or xenix might be using that, I think macworks should be since it's not 32 bit clean, but the unix ones don't work due to profile/floppy emulation anyway, so I won't mess with that until after 1.2.7 production is released (likely mid-end of this month the way things are going.)

After that, going to take a break before starting on 2.0 as I've got a huge backlog of physical Lisa projects such as power supply recapping and fixing NiCAD damaged boards, etc.

But yeah, will see about picking up things to make it easier to automate using LPW without directly interacting with it as one of the early features. Some of those will likely make it into a 1.2.8 before I start bringing back the libGen core from 1.3.0 and rerunning the CPU tests against it.

Took a month to get through this batch of CPU tests, but I'm glad it worked out, and now I can reuse them on the 1.3.0 core which will add a lot more features for debugging as well, which might be useful in reversing LOS - unless ofc, AEK releases the sources before I finish that off, etc. But yeah, I think the odds are that AEK will be able to use 1.2.7 for his efforts before 2.0 gets shipped since there are a lot of features there, like splitting up the emulator proper from the GUI.
This should also open up other fun avenues like a maybe a QT or native macos versions or a wasm version of lisaem eventually.

Did you guys see these - they're desktop emus made from emscripten recompiles of Basillisk II (not sure about the windows one), but talk about coming full circle, from desktop emu in C to web emu and back to desktop app.

* https://github.com/felixrieseberg/macintosh.js
* https://github.com/felixrieseberg/windows95/releases

[D.Finni]

Really fantastic news! And this opens up a lot of opportunities for the future, as you well know. 

[rayarachelian]

So I was curious to see if fixing "The Bug" would help MacWorks, and it did, somewhat.

It Macworks started to work for a bit, I tried 3.0 and 4.5, they now both format the hard drive and install on it, *however* trying to boot from the hard drive causes a sad mac with f0004 or something like that, so there is some improvement, but not enough to get it working again. I'll revisit this later.

Booting from the boot disk after the hard drive is installed also causes the same sadmac.

Also trying to format a disk larger than 10MB causes it to run a very long time and estimate 0mins and 0 seconds so perhaps earlier versions of MacWorks don't work too well with larger drives, but that's less of a concern.