basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Server moved

[Gwenole B. <gb....@fr...>]

Hi,

> I am in the process of moving my website to another location too.

It should be in a good enough shape by now. If you want to link, please=20=

use:
<http://www.gibix.net/projects/basilisk2/>
<http://www.gibix.net/projects/sheepshaver/>
instead of the DokuWiki page names.

I will make the redirections permanent within the next days if things=20
turn out to be OK.

Thanks,
Gwenol=E9.=

Re: [B2-devel] Server moved

[Gwenole B. <gb....@fr...>]

Hi Christian,

Congratulations for your graduation and your new job!

>  3) The CVS server (also for cxmon) has moved to
>       :pserver:<user>@cvs.cebix.net:/home/cvs/cebix

Though I can indeed use the new CVS server, users reported anoncvs is=20
not working at this time. Could you please have a look?

I am in the process of moving my website to another location too. Doing=20=

so, I switched (at this moment) to DokuWiki for content management.=20
This should allow user-contributed help pages too though, per its=20
nature, I have yet to declare the new site at a French organization due=20=

to our Data Protection Act of 1978.

When it's completed, I would like to announce and maintain "Development=20=

branch" pages of both Basilisk II and SheepShaver at Freshmeat until we=20=

can make much awaited .0 releases. Is that OK with you? I intend to=20
make new snapshots _when_ I resume work on Windows GTK GUIs and=20
integrate Darwin/i386 JIT support to SheepShaver CVS.

Thanks,
Gwenol=E9.

[B2-devel] Server moved

[Christian B. <cb...@ce...>]

Hi!

As I'm no longer working at the university of Mainz, I'm moving all my 
projects to the new cebix.net. This means:

  1) I have a new Email address (see the header of this message).
     Please use this one instead of any uni-mainz.de addresses you
     may have.
  2) The home pages of Basilisk II and SheepShaver are now at
       http://basilisk.cebix.net
       http://sheepshaver.cebix.net
     respectively. There is also
       http://www.sheepshaver.org
     donated by Erik Holzer.
  3) The CVS server (also for cxmon) has moved to
       :pserver:<user>@cvs.cebix.net:/home/cvs/cebix
     and can be browsed at
       http://www.cebix.net/viewcvs/cebix/BasiliskII/
       http://www.cebix.net/viewcvs/cebix/SheepShaver/
       http://www.cebix.net/viewcvs/cebix/mon/
     The old server at down.physik.uni-mainz.de is still reachable but
     switched to read-only mode so you can make diffs of any uncommitted
     patches you may have and check them in using the new server.
     The old server will then be shut down next week.

Happy hacking,
Christian

-- 
   / Physics is an algorithm
\/ www.cebix.net

Re: [B2-devel] Re: OS X B2 1.0

[Gwenole B. <gb....@fr...>]

Hi,

> Which would seem to me to probably _not_ be a semaphore problem?

Then make sure HAVE_PTHREAD_{TEST,}CANCEL are defined, through a=20
configure
AC_CHECK_FUNCS(pthread_cancel pthread_testcancel)

MacOS X 10.2 "supports" both of them, at least they exist for me. Note=20=

pthread_testcancel() is also important there because it doesn't have a=20=

correct implementation of cancellation points. BTW, do you HAVE_POLL ?=20=

If so, it may be necessary to have something like:

#if HAVE_POLL
                 struct pollfd pf =3D {fd, POLLIN, 0};
                 int res =3D poll(&pf, 1, -1);
#ifdef HAVE_PTHREAD_TESTCANCEL
                 pthread_testcancel();
#endif
#else
                 fd_set rfds;

Bye,
Gwenol=E9.=

[B2-devel] Re: OS X B2 1.0

[Nigel P. <ni...@in...>]

>> (I think something in QuitEmulator() is blocking)
>
> I think this was because MacOS X doesn't implement POSIX anonymous
> semaphores


ether_thread is never terminating. i.e. This:

	if (thread_active) {
#ifdef HAVE_PTHREAD_CANCEL
		pthread_cancel(ether_thread);
#endif
puts("Second pthread_join");
		pthread_join(ether_thread, NULL);
puts("Trying sem_destroy");
		sem_destroy(&int_ack);
		thread_active = false;
	}

	outputs
Second pthread_join
	but not
Trying sem_destroy

Which would seem to me to probably _not_ be a semaphore problem?

--
Nigel Pearson, ni...@in...|  "Let's see how Spike is going"
Telstra BI&D, Sydney, Australia      |              ...
Office: 8255 4222    Fax:  8255 3153 |"I'd like to keep Spike as my 
pet."
Mobile: 0408 664435  Home: 9792 6998 |        Illyria - Angel

[B2-devel] Re: OS X B2 1.0

[Nigel P. <ni...@in...>]

> From: Gwenole Beauchesne <gb....@fr...>
>
>> 	I have not succeeded in actually testing the networking.
>> In 7.6, the TCP/IP control panel never shows that it
>> gets a DHCP address
>
> I don't know about original MacOS requirements to get DHCP working.
> I only tested it with 8.0+. You might need a TCP/IP stack
> recent enough?

	I am testing with a 7.6 image. The TCP/IP control panel
does list DHCP as an option, so I assume it is supported :-)
But I will try different MacOSs just to be sure.

> IIRC, you could you static IPs provided you use the same subnet
> (10.0.2.x).
>
>> and there are now problems at shutdown time in the emulation.
>> (I think something in QuitEmulator() is blocking)
>
> I think this was because MacOS X doesn't implement POSIX anonymous
> semaphores, see semaphore.h and make sure it's included in your builds.

	I have copied ether_unix.cpp and semaphore into the MacOSX dir.,
to make sure it is not using one of the ones from /usr/include.
Sadly, no change in the behaviour. Debug for outgoing packets
during boot only.


> BTW, you once said about a black screen when using direct addressing.
> My bet would be I got the same problem in Darwin 8.0.1 for x86 and 
> it's now fixed in CVS so that to force ROM space to be above RAM.

	Indeed it now is. Thank you, thankyou thankyou!!!!

--
Nigel Pearson, ni...@in...|"Beware - I am a carrier
Telstra BI&D, Sydney, Australia      |          of surrealism"
Office: 8255 4222    Fax:  8255 3153 |  D  A
Mobile: 0408 664435  Home: 9792 6998 |  L  I

Re: [B2-devel] OS X B2 1.0

[Gwenole B. <gb....@fr...>]

Le mardi, 26 jul 2005, =E0 10:40 Europe/Paris, Nigel Pearson a =E9crit :

> 	I have not succeeded in actually testing the networking.
> In 7.6, the TCP/IP control panel never shows that it
> gets a DHCP address

I don't know about original MacOS requirements to get DHCP working. I=20
only tested it with 8.0+. You might need a TCP/IP stack recent enough?=20=

IIRC, you could you static IPs provided you use the same subnet=20
(10.0.2.x).

> and there are now problems at shutdown time in the emulation.
> (I think something in QuitEmulator() is blocking)

I think this was because MacOS X doesn't implement POSIX anonymous=20
semaphores, see semaphore.h and make sure it's included in your builds.=20=

Reminder, an SDL build within the Unix/ directory can have slirp=20
networking OK with no blocking at shutdown. So, I think it's just a=20
matter of using the Mach semaphores instead. And BTW, the ethernet code=20=

uses a semaphore too, so that may work after all with this change.

BTW, you once said about a black screen when using direct addressing.=20
My bet would be I got the same problem in Darwin 8.0.1 for x86 and it's=20=

now fixed in CVS so that to force ROM space to be above RAM.

Bye,
Gwenol=E9.=

[B2-devel] OS X B2 1.0

[Nigel P. <ni...@in...>]

> Mac OS X:
> - I can't rebuild in 10.2.8. Nigel, can you test builds with 
> HAVE_SLIRP=20=
> enabled for network support?


	I haven't got successful builds under 10.2 yet
(have setup a Mac for X11 builds, but configure keeps
  complaining about gcc not being able to generate code).
However, I did get a HAVE_SLIRP build of my Cocoa app.


	I have not succeeded in actually testing the networking.
In 7.6, the TCP/IP control panel never shows that it
gets a DHCP address, and there are now problems at
shutdown time in the emulation.
(I think something in QuitEmulator() is blocking)

	Enabling DEBUG in ether_unix.cpp source shows some initial
ethernet write calls during boot, but nothing received back.

	Enabling DEBUG in SLIRP does nothing:
% cat /tmp/slirp.log
Debugging Started level 7.
%


	Any suggestions?

--
Nigel Pearson, ni...@in... | "Gentlemen,
Telstra BI&D, Sydney, Australia       |  you can't fight in here
Office: 8255 4222    Fax:  8255 3153  |  - this is the war room!"
Mobile: 0408 664435  Home: 9792 6998  |      Dr Strangelove

[B2-devel] Large Volume support

[Gwenole B. <gb....@fr...>]

Hi,

FYI, someone reported on emaculation.com forums that hardfiles larger=20
than 4 GB failed to initialize. It's now fixed in CVS and I traced the=20=

typo to be there from the begining of Basilisk II in CVS. ;-) Lightly=20
tested with a 4.2 GB image and a few transfers without problems.

Bye,
Gwenol=E9.=

Re: [B2-devel] SheepShaver Linux broken?

[Gwenole B. <gb....@fr...>]

Hi,

> Any thoughts?

Thanks for noticing, it's now fixed in CVS. Next time, please don't=20
forget to report the compiler version you are using. ;-) FYI, I have=20
just verified it works with gcc 3.3.4/3.3.6/3.4.3/4.0.1 on either x86=20
or x86_64. I could reproduce your problem with 3.3.4 on x86 only.

Bye,
Gwenol=E9.

[B2-devel] SheepShaver Linux broken?

[Marc P. <clo...@ho...>]

Hi all!

I've recently switched back to running linux full time on my main computer, 
and tried to compile SheepShaver from CVS.  The compilation failed with:

g++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. 
-I../slirp -DHAVE_CONFIG_H -D_REENTRANT 
-DDATADIR=\"/usr/local/share/SheepShaver\" -g -O2 -I../../../mon/src 
-I../../../mon/src/disass  -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API 
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/freetype2/config -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include    -fomit-frame-pointer 
-mpreferred-stack-boundary=2 -falign-functions=0 -finline-limit=10000 
-fno-exceptions -g0 -fno-reorder-blocks -fno-optimize-sibling-calls -c 
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:39: warning: register used for two
   global register variables
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:40: warning: register used for two
   global register variables
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:41: warning: register used for two
   global register variables
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:42: warning: register used for two
   global register variables
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vcmpequb()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1618: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vcmpequh()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1619: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vcmpequw()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1620: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vcmpgtsb()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1621: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vcmpgtsh()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1622: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vcmpgtsw()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1623: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vaddubm()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1624: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vadduhm()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1625: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vadduwm()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1626: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsububm()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1627: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsubuhm()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1628: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsubuwm()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1629: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vand()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1630: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vandc()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1631: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_sse2_vor()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1632: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vxor()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1633: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vavgub()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1634: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vavguh()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1635: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_1()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1657: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_2()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1658: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_3()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1659: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_4()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1660: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_5()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1661: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_6()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1662: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_7()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1663: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_8()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1664: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse2_vsldoi_9()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1665: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
   op_sse2_vsldoi_10()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1666: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
   op_sse2_vsldoi_11()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1667: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
   op_sse2_vsldoi_12()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1668: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
   op_sse2_vsldoi_13()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1669: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
   op_sse2_vsldoi_14()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1670: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
   op_sse2_vsldoi_15()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1671: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vcmpeqfp()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1686: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vcmpgefp()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1687: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vcmpgtfp()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1688: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vaddfp()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1689: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vsubfp()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1690: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vmaxfp()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1691: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vminfp()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1692: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_sse_vand()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1693: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vandc()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1694: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_sse_vor()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1695: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_sse_vxor()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1696: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vminub()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1697: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vmaxub()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1698: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vminsh()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1699: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vmaxsh()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1700: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vmaddfp()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1711: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_vnmsubfp()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1723: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_mov_VD_V0()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1735: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_mov_VD_V1()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1736: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_sse_mov_VD_V2()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1737: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vcmpequb()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1760: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vcmpequh()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1761: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vcmpequw()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1762: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vcmpgtsb()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1763: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vcmpgtsh()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1764: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vcmpgtsw()
   ':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1765: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vaddubm()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1766: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vadduhm()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1767: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vadduwm()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1768: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vsububm()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1769: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vsubuhm()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1770: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vsubuwm()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1771: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_mmx_vand()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1772: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vandc()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1773: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_mmx_vor()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1774: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_mmx_vxor()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1775: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vmaxub()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1776: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vminub()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1777: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vmaxsh()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1778: error: parse error before 
`)'
   token
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void 
op_mmx_vminsh()':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1779: error: parse error before 
`)'
   token
make: *** [obj/ppc-dyngen-ops.o] Error 1


I found an older CVS tree of SheepShaver on my hard drive, dated July 12, 
2004, and I replaced ppc-dyngen-ops.cpp, ppc-dyngen.cpp, ppc-dyngen.hpp, and 
ppc-translate.cpp in the new tree with the versions from the old tree, and 
it compiled and ran fine.  I also tried compiling on my secondary box (which 
has run linux for over 3 years now, and historically has compiled 
SheepShaver without any problem), and compilation stops with the same 
message.

Any thoughts?

Marc Polansky

[B2-devel] Re: Planning for Basilisk II 1.0

[Nigel P. <ni...@in...>]

> I think we can really release 1.0 this year. ;-)
...
> Mac OS X:
> - I can't rebuild in 10.2.8. Nigel, can you test builds with HAVE_SLIRP
> enabled for network support?

	Hi Gwenole. I haven't had a lot of time for B2 for the last
few years. Sort of lost interest after I spent many months trying
to work around the "black screen" bug.

	I will try to do some test builds this week, but MythTV
is taking all my free time at the moment.


* r.e...@du... sent me some EtherTAP patches
   that work for him, but I haven't even tried to install EtherTAP.

* I also have sound support code from va...@us...

--
Nigel Pearson, ni...@in... | "Now the world has gone to bed,
Telstra BI&D, Sydney, Australia       |  Darkness won't engulf my head,
Office: 8255 4222    Fax:  8255 3153  |  I can see by infrared,
Mobile: 0408 664435  Home: 9792 6998  |  How I hate the night." -Marvin

Re: [B2-devel] Tiger Display Problems

[Gwenole B. <gb....@fr...>]

Le mercredi, 6 jul 2005, =E0 15:25 Europe/Paris, Michael Dickison a =
=E9crit=20
:

> Here it is (sorry, I missed this in the last email):
>
> 192:~ michaeldickison$ ioreg=A0 -c IOPlatformDevice | egrep=20
> "(cpu-version|clock-frequency|bus-frequency|timebase-frequency)"
> =A0 =A0 | | |=A0=A0 "cpu-version" =3D <80030102>

OK, I had added this one this morning + PPC970FX & MPC 7448 CPUs.

> Actually I have a new problem now -- it tells me: "ERROR: Cannot=20
> create SHM segment for Kernel Data: No space left on device." when I=20=

> run SheepShaver (even 2.2, the March snapshot), so I know it's a=20
> runtime problem, nothing to do with configure options etc (I tried=20
> both X11 and SDL -- same problem).

Either reboot or ipcrm some obsolete segments created by SheepShaver=20
that crashed without cleanup those (ipcs to get a list).

Re: [B2-devel] Tiger Display Problems

[Michael D. <mic...@gm...>]

>>> WARNING: Unknown CPU type
>>>
>>
>> Probably unrelated but what's the output of:
>> ioreg  -c IOPlatformDevice | egrep "(cpu-version|clock-frequency| 
>> bus-frequency|timebase-frequency)"
>> ?
>>
>
> Could be related in fact. I tried a dummy PVR and it crashed during  
> boot. So, please send me the output of this command.

Here it is (sorry, I missed this in the last email):

192:~ michaeldickison$ ioreg  -c IOPlatformDevice | egrep "(cpu- 
version|clock-frequency|bus-frequency|timebase-frequency)"
     | | |   "timebase-frequency" = <01193ea0>
     | | |   "clock-frequency" = <4f790d52>
     | | |   "rounded-clock-frequency" = <4f64b500>
     | | |   "bus-frequency" = <07f010eb>
     | | |   "config-bus-frequency" = <07e8fe70>
     | | |   "recalced-clock-frequency" = <4f60a92e>
     | | |   "cpu-version" = <80030102>
     | | |   "clock-frequency" = <03f940aa>
     | | |   "clock-frequency" = <01fca055>
     | | |   "clock-frequency" = <03f940aa>

I've tried compiling with X11, I have to pass the parameter -- 
display :0 (so I can't make it an Application Bundle unless you can  
pass parameters there, actually it tells me: "Unrecognized option '- 
psn_0_9043969'" when I try to run as App bundle) and it crashes as  
it's loading (I would give you the error message but I'm getting  
something new now... see below).

Actually I have a new problem now -- it tells me: "ERROR: Cannot  
create SHM segment for Kernel Data: No space left on device." when I  
run SheepShaver (even 2.2, the March snapshot), so I know it's a  
runtime problem, nothing to do with configure options etc (I tried  
both X11 and SDL -- same problem). I tried copying a new Mac OS ROM  
from the 8.6 System Folder again, but that's not the problem,  
apparently. I also tried deleting .sheepshaver_nvram but that did not  
fix it either. The hard drive still has space so I'm not sure what  
the error is trying to tell me.

Re: [B2-devel] Tiger Display Problems

[Gwenole B. <gb....@fr...>]

Le lundi, 4 jul 2005, =E0 19:58 Europe/Paris, Gwenole Beauchesne a =E9crit=
 :

>> WARNING: Unknown CPU type
>
> Probably unrelated but what's the output of:
> ioreg  -c IOPlatformDevice | egrep=20
> "(cpu-version|clock-frequency|bus-frequency|timebase-frequency)"
> ?

Could be related in fact. I tried a dummy PVR and it crashed during=20
boot. So, please send me the output of this command.

Re: [B2-devel] Tiger Display Problems

[Gwenole B. <gb....@fr...>]

Le lundi, 4 jul 2005, =E0 18:14 Europe/Paris, Michael Dickison a =E9crit =
:

> ### No appropriate blitter found
> =A0 =A0 R/G/B mask values=A0 : 0x007c00, 0x0003e0, 0x00001f (depth =3D =
16)
> =A0 =A0 R/G/B shift values : 10/5/0

Just to understand does this cause the crash or is it the garbled=20
screen output? Or maybe both?

An alternative would be to try X11 output (--disable-sdl-video). I=20
think Apple still provides it for Tiger. Then, if the output is not=20
messed up, is could be a miscalculation of the scan line.

> WARNING: Unknown CPU type

Probably unrelated but what's the output of:
ioreg  -c IOPlatformDevice | egrep=20
"(cpu-version|clock-frequency|bus-frequency|timebase-frequency)"
?

Re: [B2-devel] Tiger Display Problems

[Gwenole B. <gb....@fr...>]

Le lundi, 4 jul 2005, =E0 18:10 Europe/Paris, Michael Dickison a =E9crit =
:

> /usr/bin/ld: multiple definitions of symbol _sigusr2_handler
> obj/main_unix.o definition of _sigusr2_handler in section=20
> (__TEXT,__text)
> obj/paranoia.o definition of _sigusr2_handler in section=20
> (__TEXT,__text)
> collect2: ld returned 1 exit status
> make: *** [SheepShaver] Error 1

Hmm, yes, sorry, it's fixed now.

Re: [B2-devel] Tiger Display Problems

[Michael D. <mic...@gm...>]

>> Max screen dimensions: 1024x768
>> Current screen depth:  32 bpp
>> SDL supports 1024x768x32 with a HWSURFACE (windowed)
>> SDL supports 1024x768x32 with a HWSURFACE (fullscreen)
>>
>
> And your screen depth is really set to Thousands and not Millions?  
> Because looking at the image, I'd thought something like 24/32 bpp  
> offset.
>

My screen is set to Millions. I tried opening SheepShaver at  
Thousands and 256 and there was no difference.

>> do_test() returned 0
>>
>> Hope some of this helps!
>>
>
> Unfortunately not, unless CrashReporter appeared? ;-) It should not  
> in any case. Probably something broke in our Mach exception handler  
> for Tiger.

I don't think CrashReporter came up. I'll send the entire console  
message for when I run SheepShaver (it might help to see where it  
crashes?) it's after paranoia checks and setting up the display (and  
this is when I tried it with Thousands of colors):

SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Paranoia checks...
[tick_thread] waiting for emul thread to initialize
[emul_thread] waiting for tick thread to initialize
[emul_thread] filling in registers and waiting for interrupt
[tick_thread] trigger interrupt
SIGUSR2 caught
...passed
Reading ROM file...
Available video modes:
640x480 (ID 81), 2 colors
800x600 (ID 83), 2 colors
640x480 (ID 81), 4 colors
800x600 (ID 83), 4 colors
640x480 (ID 81), 16 colors
800x600 (ID 83), 16 colors
640x480 (ID 81), 256 colors
800x600 (ID 83), 256 colors
640x480 (ID 81), 32768 colors
800x600 (ID 83), 32768 colors
video_open()
Current video mode:
640x480 (ID 81), 16 bpp
the_buffer = 0x4710000, the_buffer_copy = 0x465b000
### No appropriate blitter found
     R/G/B mask values  : 0x007c00, 0x0003e0, 0x00001f (depth = 16)
     R/G/B shift values : 10/5/0
monitor.mac_frame_base = 04710000
WARNING: Unknown CPU type
Jul  4 11:07:09 michael-dickisons-ibook-g4 crashdump[332]:  
SheepShaver crashed
Jul  4 11:07:10 michael-dickisons-ibook-g4 crashdump[332]: crash  
report written to: /Users/michaeldickison/Library/Logs/CrashReporter/ 
SheepShaver.crash.log

Re: [B2-devel] Tiger Display Problems

[Michael D. <mic...@gm...>]

> Can you check current CVS? I have committed the new paranoia  
> checks. Please, cvs update -d in both BasiliskII and SheepShaver  
> directories. Then, in the SheepShaver/ directory,
> find . -type l | xargs rm -f    (remove all symlinks in the  
> SheepShaver tree).
> make links            (recreate the symlinks)

I just deleted the SheepShaver and BasiliskII folders and started  
completely fresh and I got the following linking error (I'm probably  
just doing something stupid because I remember being able to get  
around some of these before):

g++ -o SheepShaver -pagezero_size 0x3000        obj/main.o obj/ 
main_unix.o obj/prefs.o obj/prefs_items.o obj/prefs_unix.o obj/ 
sys_unix.o obj/rom_patches.o obj/rsrc_patches.o obj/emul_op.o obj/ 
name_registry.o obj/macos_util.o obj/timer.o obj/timer_unix.o obj/ 
xpram.o obj/xpram_unix.o obj/adb.o obj/sony.o obj/disk.o obj/cdrom.o  
obj/scsi.o obj/gfxaccel.o obj/video.o obj/video_blit.o obj/audio.o  
obj/ether.o obj/thunks.o obj/serial.o obj/extfs.o obj/ 
about_window_unix.o obj/user_strings.o obj/user_strings_unix.o obj/ 
vm_alloc.o obj/sigsegv.o obj/sshpty.o obj/strlcpy.o obj/video_sdl.o  
obj/extfs_macosx.o obj/serial_unix.o obj/ether_unix.o obj/ 
scsi_dummy.o obj/audio_sdl.o obj/prefs_editor_dummy.o obj/paranoia.o  
obj/ppc_asm.o obj/sys_darwin.o obj/clip_macosx.o obj/bootp.o obj/ 
ip_output.o obj/tcp_input.o obj/cksum.o obj/mbuf.o obj/tcp_output.o  
obj/debug.o obj/misc.o obj/tcp_subr.o obj/if.o obj/sbuf.o obj/ 
tcp_timer.o obj/ip_icmp.o obj/slirp.o obj/tftp.o obj/ip_input.o obj/ 
socket.o obj/udp.o -lpthread  -L/sw/lib -lSDLmain -lSDL -framework  
Cocoa -framework OpenGL -framework Carbon -framework IOKit
/usr/bin/ld: multiple definitions of symbol _sigusr2_handler
obj/main_unix.o definition of _sigusr2_handler in section  
(__TEXT,__text)
obj/paranoia.o definition of _sigusr2_handler in section (__TEXT,__text)
collect2: ld returned 1 exit status
make: *** [SheepShaver] Error 1

> The reason is some files moved around and were added, namely for  
> slirp support in SheepShaver. aka. user-mode network emulation,  
> even under MacOS X. ;-)
>

Great!!! Thanks for all your work!

-Michael

Re: [B2-devel] Planning for SheepShaver 2.3

[<jea...@pa...>]

The missing AltiVec instruction was already implemented in CVS for some 
time. As for Adobe problems, I don't know. I have just tried Acrobat 
Reader 5.0.5 (the latest for MacOS 9.x) without any problem.


I know that maybe I'm asking to much right now, but would you please cons=
ider to compile a windows-binary (.exe), with the missing altivec instruc=
tion implemented, as I'm not using linux nor cygwin, and from the moment =
on I can use framemaker in SS, it becomes usefull for me even though it i=
sn't that stable yet.

Sincerely hope I do not push it to far with asking this favor, because if=
 you can not spare the time to do so, I would fully understand.

Thx in advance anyway for alle your efforts.


>----- Oorspronkelijk bericht -----
>Van: Gwenole Beauchesne [mailto:gb....@fr...]
>Verzonden: zaterdag, juli 2, 2005 01:22 AM
>Aan: bas...@li...
>Onderwerp: Re: [B2-devel] Planning for SheepShaver 2.3
>
>Le vendredi, 1 jul 2005, =E0 14:59 Europe/Paris, 
>jea...@pa... a =E9crit :
>
>> Would in the 2.3 release of SS for windows also the adobe-altivec 
>> problem be solved ?
>
>The missing AltiVec instruction was already implemented in CVS for some =

>time. As for Adobe problems, I don't know. I have just tried Acrobat 
>Reader 5.0.5 (the latest for MacOS 9.x) without any problem.
>
>> And if so, is a public download to be expected soon ?
>
>I don't know. People will know when it's released, I don't give release =

>dates that may break. ;-)
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id 492&opclick
>_______________________________________________
>basilisk-devel mailing list
>bas...@li...
>https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] SheepShaver Ethernet driver

[Gwenole B. <gb....@fr...>]

Hi,

I have rebuilt a new Ethernet NDRV with CodeWarrior for MacOS =20
(EthernetDriverFull.i). It basically now uses the ether.cpp as a whole =20=

instead of minimal/direct stubs to native code. This helps for =20
DIRECT_ADDRESSING platforms (Windows) as converting ether.cpp to a =20
non-real-addressing-clean state would be tedious.

It should be possible to always default to that new driver (10 KB) but =20=

I'd prefer keeping the old one for REAL_ADDRESSING as it permits =20
debugging more easily, and it can gather some statistics.

I have placed the sources + project files here:
<http://gwenole.beauchesne.free.fr/sheepshaver/files/SheepShaver-=20
Ethernet.tar.bz2>
note that it's intended to be extracted into an extfs enabled directory =20=

in order to get the resources intact. ;-)

BTW, I also integrated the slirp code from Basilisk II. So we now have =20=

ethernet working without any privileges on at least Linux and MacOS X. =20=

Platforms where it worked for Basilisk II should work for SheepShaver =20=

too.

Bye,
Gwenol=E9.=

Re: [B2-devel] Tiger Display Problems

[Gwenole B. <gb....@fr...>]

Le vendredi, 1 jul 2005, =E0 15:46 Europe/Paris, Michael Dickison a =
=E9crit=20
:

> Max screen dimensions: 1024x768
> Current screen depth:=A0 32 bpp
> SDL supports 1024x768x32 with a HWSURFACE (windowed)
> SDL supports 1024x768x32 with a HWSURFACE (fullscreen)

And your screen depth is really set to Thousands and not Millions?=20
Because looking at the image, I'd thought something like 24/32 bpp=20
offset.

> do_test() returned 0
>
> Hope some of this helps!

Unfortunately not, unless CrashReporter appeared? ;-) It should not in=20=

any case. Probably something broke in our Mach exception handler for=20
Tiger.

Re: [B2-devel] Tiger Display Problems

[Gwenole B. <gb....@fr...>]

Le vendredi, 1 jul 2005, =E0 00:00 Europe/Paris, Michael Dickison a =
=E9crit=20
:

>>> Hi, I got SheepShaver to compile and run on Tiger (thanks for the=20
>>> new paranoia.cpp!)
>>>
>>
>> So it works? Nice, thanks, I will commit along with the Linux version=20=

>> I was using.
>
> Yup, paranoia works! But I tried compiling the CVS today and I get the=20=

> following error:

Can you check current CVS? I have committed the new paranoia checks.=20
Please, cvs update -d in both BasiliskII and SheepShaver directories.=20
Then, in the SheepShaver/ directory,
find . -type l | xargs rm -f	(remove all symlinks in the SheepShaver=20=

tree).
make links			(recreate the symlinks)

The reason is some files moved around and were added, namely for slirp=20=

support in SheepShaver. aka. user-mode network emulation, even under=20
MacOS X. ;-)=

Re: [B2-devel] Planning for SheepShaver 2.3

[Gwenole B. <gb....@fr...>]

Le vendredi, 1 jul 2005, =E0 14:59 Europe/Paris,=20
jea...@pa... a =E9crit :

> Would in the 2.3 release of SS for windows also the adobe-altivec=20
> problem be solved ?

The missing AltiVec instruction was already implemented in CVS for some=20=

time. As for Adobe problems, I don't know. I have just tried Acrobat=20
Reader 5.0.5 (the latest for MacOS 9.x) without any problem.

> And if so, is a public download to be expected soon ?

I don't know. People will know when it's released, I don't give release=20=

dates that may break. ;-)

Re: [B2-devel] Tiger Display Problems

[Michael D. <mic...@gm...>]

> You generally need to update the Basilisk II tree as well. ;-)

aah, of course :)

>> Current video mode:
>> 640x480 (ID 81), 32 bpp
>> the_buffer = 0x47c5000, the_buffer_copy = 0x465b000
>> ### No appropriate blitter found
>>     R/G/B mask values  : 0xff0000, 0x00ff00, 0x0000ff (depth = 32)
>>     R/G/B shift values : 16/8/0
>> monitor.mac_frame_base = 047c5000
>>
>
> Seems like SDL guessed a best mode with depth greater than what's  
> is available on your system, or I need some other heuristics to  
> determine the current screen depth.
>
> Please try:
> <http://gwenole.beauchesne.free.fr/sheepshaver/sdl_video_info.c>
>
> bash-2.05a$ gcc sdl_video_info.c $(sdl-config --cflags --libs)
> bash-2.05a$ ./a.out
> Max screen dimensions: 1152x768
> Current screen depth:  16 bpp
> SDL supports 1152x768x16 with a HWSURFACE (windowed)
> SDL supports 1152x768x16 with a HWSURFACE (fullscreen)

This is the result I get:

Max screen dimensions: 1024x768
Current screen depth:  32 bpp
SDL supports 1024x768x32 with a HWSURFACE (windowed)
SDL supports 1024x768x32 with a HWSURFACE (fullscreen)

> write into the ROM... The weird thing is that we normally catch  
> those kind of errors exactly. Is CrashReporter overriding our Mach  
> exception handler? Let's see with:
> <http://gwenole.beauchesne.free.fr/sheepshaver/sigsegv_standalone.cpp>
>
> 1) In default mode with: g++ sigsegv_standalone.cpp, you must have  
> this file in the BasiliskII/src/Unix/ directory
> 2) With SDL: g++ sigsegv_standalone.cpp  -DUSE_SDL $(sdl-config -- 
> cflags --libs)
>
> If CrashReporter appears in SDL mode, try to uncomment the  
> SDL_INIT_NOPARACHUTE part. You normally should get on the console  
> something like:

I get:

sigsegv_test_handler(0x807b, 0x3cbc)
expected fault at 0x807b
expected instruction address range: 0x3ca8-0x3d10
sigsegv_insn_handler(0x8001, 0x3eac)
00003eac: byte read access r0 (rd = 0)
sigsegv_insn_handler(0x8002, 0x3f1c)
00003f1c: word read access r0 (rd = 0)
sigsegv_insn_handler(0x8004, 0x3f8c)
00003f8c: long read access r0 (rd = 0)
sigsegv_insn_handler(0x8004, 0x3ff8)
00003ff8: long read access r0 (rd = 0)
sigsegv_insn_handler(0x8001, 0x4064)
00004064: byte read access r0 (rd = 0)
sigsegv_insn_handler(0x8002, 0x40d4)
000040d4: word read access r0 (rd = 0)
sigsegv_insn_handler(0x8004, 0x4144)
00004144: long read access r0 (rd = 0)
sigsegv_insn_handler(0x8004, 0x41b0)
000041b0: long read access r0 (rd = 0)
do_test() returned 0

and

Checking with SDL
sigsegv_test_handler(0x2fb07b, 0x4d3c)
expected fault at 0x2fb07b
expected instruction address range: 0x4d28-0x4d90
sigsegv_insn_handler(0x2fb001, 0x4f2c)
00004f2c: byte read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb002, 0x4f9c)
00004f9c: word read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb004, 0x500c)
0000500c: long read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb004, 0x5078)
00005078: long read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb001, 0x50e4)
000050e4: byte read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb002, 0x5154)
00005154: word read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb004, 0x51c4)
000051c4: long read access r0 (rd = 0)
sigsegv_insn_handler(0x2fb004, 0x5230)
00005230: long read access r0 (rd = 0)
do_test() returned 0

Hope some of this helps!

--Michael