Re: [B2-devel] Can't run BasiliskII on Fedora Core 3 x86

[Matthias S. <th...@sp...>]

Gwenole Beauchesne wrote :

> jeudi 16 d=E9cembre 2004, =E0 04:29  pm, Matthias Saou a =E9crit :
>=20
> > Hmmm, I've got a stupid question, then. When I looked at SheepShaver, I
> > understood that it was only relevant on ppc machines. Was I wrong?=20
> > Here's
> > the first paragraph of the doc/index.html file in the SheepShaver CVS=20
> > tree
> > :
>=20
> Unfortunately, the documention in the CVS tree is somewhat old vs.=20
> Christian's site:
> <http://www.uni-mainz.de/~bauec002/SheepShaver.html>
>=20
> > Does SheepShaver run on x86 and x86-64?
>=20
> Yes, and it runs up to MacOS 9.0.4.
>=20
> > How does it position itself compared to BasiliskII, pretty much like=20
> > VMWare (-> BasiliskII) and Wine
> > (-> SheepShaver)?
>=20
> SheepShaver has almost the same foundations as Basilisk II thus sharing=20
> a lot of code. Both run-time patch MacOS with driver hooks to native=20
> code and high level replacements. i.e. they don't emulate real=20
> hardware, but a virtual hardware good enough run those OSes.
>=20
> > This "black screen" seems to be what I'm getting
> > with older BasiliskII releases, so if anyone has more info on that
> > particular problem and how to work around it, I'd really appreciate it.
>=20
> Sometimes, people reported they got it fixed by nuking/zap their XPRAM=20
> file (~/.basilisk_ii_xpram).

Not for me. Even after that, I either get the grey Mac screen if I check
the "Ignore Illegal Memory Accesses" or I get this same error if I don't :

Caught SIGSEGV at address 0x15b10380 [IP=3D0x80a2dc4]
D0: 00000000 D1: fffcffff D2: fffffffc D3: 0000000f
D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000
A0: 0000003c A1: 00000002 A2: 00006114 A3: 00006528
A4: 00005d08 A5: 05b10380 A6: 00000000 A7: 02d009ae
USP=3D00000000 ISP=3D02d009ae MSP=3D00000000 VBR=3D00000000
T=3D00 S=3D1 M=3D0 X=3D1 N=3D1 Z=3D0 V=3D0 C=3D0 IMASK=3D0
FP0: nan FP1: nan FP2: nan FP3: nan
FP4: nan FP5: nan FP6: nan FP7: nan
N=3D0 Z=3D0 I=3D0 NAN=3D0
05a2e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4
next PC: 05a2e8ea

Isn't this chunk of output useful in any way? With older Basilisk builds,
I'd get a segfault, but the threaded design seems to prevent me from
getting any useful info when gdb is attached to the initial process I run,
but if anyone gives me quick steps to get more useful backtraces, I'd be
more than willing to help provide some.

Matthias

--=20
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.9-1.681_FC3.r300
Load : 2.16 1.97 1.41