Weird freezing with Circle of Blood CD on Linux

[Grieverheart]

On Linux, I mount https://macintoshgarden.org/games/broken-sword-the-shadow-of-the-templarscircle-of-blood as a cdrom. Then copy the installation executable to the desktop, and run the installer on the desktop, after which Basilisk II hangs. This is with the commits of 8th of October. Checked with gdb, and Basilisk II is in an infinite loop running opcode 0x0. Not sure how it gets there. The weird part is that I had a similar issue on Mac. Then I deleted BasiliskII.app and re-downloaded it, and after running it again, it was not hanging anymore...

Note that this is with a Quadra 950 ROM, with a 68040 cpu.

Another issue is that I don't have a physical cdrom on my PC, so /dev/cdrom does not exist. That means I cannot drag and drop a cd rom image because there is no drive already (drives.empty()).

[kanjitalk755]

Then I deleted BasiliskII.app and re-downloaded it, and after running it again, it was not hanging anymore...

Nothing can be done without reproducibility.

Another issue is that I don't have a physical cdrom on my PC, so /dev/cdrom does not exist. That means I cannot drag and drop a cd rom image because there is no drive already (drives.empty()).

Drop mounting is possible even without an optical drive.

[Grieverheart]

Nothing can be done without reproducibility.

Did you try to reproduce on Linux?

Drop mounting is possible even without an optical drive.

It's not working for me. When it reaches this line if (!drives.empty()) { in CDROMDrop, the drives are empty. Why does this fail? It tries to add this PrefsAddString("cdrom", "/dev/cdrom");, but Basilisk fails to open /dev/cdrom.

Maybe worth noting that I'm using Arch Linux.

[Grieverheart]

Possibly related, but on Linux, when I expand something on the desktop with Stuffit, the expanded folder does not appear on the desktop until I restart.

[Grieverheart]

Also, not sure if it helps, but here are all the opcodes it ran before running into the 0x0 opcode. Left column is pc_p, and right column is the opcode.
opcodes.txt

[Grieverheart]

Another update: On windows it worked fine. I installed it and copied the dsk to Linux. On Linux starting game, but freezes nearly immediately.

[kanjitalk755]

Did you try to reproduce on Linux?

I tried it on Debian 12.
Then, I fell into an infinite loop with pc=0xc0,instruction=0x0208.
The UAE CPU core seems to operate differently under Linux, but it's difficult to debug it.

It's not working for me.

Working well under Debian.

[Grieverheart]

The UAE CPU core seems to operate differently under Linux, but it's difficult to debug it.

I see, didn't know Basilisk uses the UAE 68k implementation. So then it is a bug in UAE's implementation?
By the way, I moved the same disk image with the installation to a Mac, and the Mac would also freeze when the game starts. Again, I deleted the BasiliskII.app, unzipped a fresh one and the problem disappeared. The funny thing is, that I also have a BasiliskII in a different location, which I compiled myself, but this fixes both! What could cause such weird behaviour?

Is this something you think you are going to work on?

Working well under Debian.

Do you have a physical cd-rom drive on your PC? I had the same issue under Windows. If no cdrom is already mounted, drop mounting does not work on Windows either.

[kanjitalk755]

So then it is a bug in UAE's implementation?

Certainly, the problem isn't necessarily within the UAE core, but it's also difficult to pinpoint.

What could cause such weird behaviour?

I don't know because I have never encountered such a phenomenon.

Is this something you think you are going to work on?

I might debug if I find any clues.

Do you have a physical cd-rom drive on your PC?

The reason why it was okay even without a CDROM drive was because there was the following line in .basilisk_ii_prefs.

cdrom /dev/poll/cdrom

[ualaa1]

I somehow got the game to work on Basilisk II.
On the Prefs file, add this line cdrom C:\whereever your cd image is located\Broken Sword.iso
I did notice that Basilisk II crashed when I set the iso as a disk drive instead of a cd drive when running the installer, but it seemed to work fine if the iso was set as a cd drive
And I made sure to set the installer at minimum so I don't have to switch disks
My computer also doesn't have a CD drive and it works fine

[rakslice]

Just the whole vibe of this port of the game is weird, like why did they make a CD installer that would not run from read only storage? Why does it throw up a window using Metrowerks I/O stub thing to tell you this like a hello world example? Curious.

[rakslice]

I've never managed to get the 68k version of the installer to work in Basilisk II on Linux, even making my settings as close as possible to the Mac OS X build where it sometimes works and ignoring illegal memory accesses which I don't usually do. It ends up at an illegal instruction or sometimes a hang.

You can work around this by doing by hand what the installer does for a minimal install.
Create a folder for the game. Inside it:
Copy from CD 1:

• 68k (this is the 68k version of the main program which the installer renames to Circle of Blood)
• 68k.inf
• sword.vol
• the folder Clusters but only the 6 files other than the paris ones

Then:

• create an empty folder SmacksLO
• create an empty folder SmacksHI

In the main program 68k version there is also a crash on first launch with the same illegal instruction as the installer.

However you can work around it:

• Create a folder Saves
• Create an empty text file inside called savegame.inf

This makes the game bring up a menu on launch like when there is an existing save, which avoids the crash; you can still choose Start from that menu to start a new game from the opening cinematic like you would get on first launch.
Once the actual gameplay starts you may need to go to the Esc menu and then Volume to fix the audio levels if they're zeroed.

Anyway, all of that is to say I wonder if this is literally some kind of file-not-found error state that the game code handles incorrectly that is resulting in invalid jumps because of some emulation difference and hits some fortuitous nop sled to a safe place on a real machine.

For comparison, this problem doesn't affect the PPC version in SheepShaver.

[rakslice]

The thing in common for the installer failure case between Mac OS X and Linux is execution is getting into the zeros in the same way: The a-trap vector (at 0x28) is getting stomped to 0x360000, and then on the next trap (which when the installer is failing to launch is InitGraf) we go there and start executing zeroes.

However in Basilisk II on Linux it happens every time you run the installer, and in Basilisk II on Mac OS X it only happens some of the time (with no pattern to the successes and failures or correlation of them to anything I can think to check).

The code fragment doing the stomping looks like:

0f97b02c : 4252                CLR.W    (A2)
0f97b02e : 204a                MOVEA.L  A2,A0
0f97b030 : 41e8 0036      LEA      +54(A0),A0
0f97b034 : 2548 000c      MOVE.L   A0,+12(A2) 
0f97b038 : 204a                MOVEA.L  A2,A0
0f97b03a : 41e8 0036      LEA      +54(A0),A0
0f97b03e : 2548 0010      MOVE.L   A0,+16(A2) 
0f97b042 : 204a                MOVEA.L  A2,A0
0f97b044 : 41e8 0036      LEA      +54(A0),A0
0f97b048 : 2548 0026      MOVE.L   A0,+38(A2)  // changes a-trap vector to 0x003699b0
0f97b04c : 204a                MOVEA.L  A2,A0
0f97b04e : 41e8 0036      LEA      +54(A0),A0
0f97b052 : 2548 0014      MOVE.L   A0,+20(A2) 
0f97b056 : 204a                MOVEA.L  A2,A0
0f97b058 : 41e8 0036      LEA      +54(A0),A0
0f97b05c : 2548 002a      MOVE.L   A0,+42(A2)  // changes a-trap vector to 0x00360000
0f97b060 : 204a                MOVEA.L  A2,A0

...

On the successful runs a similar code sequence executes from a similar address on the way out of the installer, at which time it does not touch the a-trap vector. So perhaps it is a knock-on effect of whatever is going wrong in the installer rather than the cause.

As an aside:

0000 isn't an invalid 68k opcode; just straight 00000000 is valid 68k machine code:

0000 0000      ORI.B    #$00,D0

And it's not a jump so it's not an infinite loop on its own.

But obviously if you jump into some random block of zeroed address space an arbitrary distance from anything you might be there executing in a straight line for a long time.

So when it comes to opcode logging you probably need to get a few consecutive 0 opcodes in before it's of interest, because you're going to see some in the normal system boot-up.