basilisk-devel — Basilisk II development-related discussion

[B2-devel] Still same crash/problem

[Hetz B. H. <he...@wi...>]

Ok, tested the new CVS snapshot.

Machine: P4-1.5Ghz, Geforce 2 (with the 2314 binary only drivers), 
XFree-4.1.0 (without the DRI of course), Red Hat 7.2 + all the updates..

Basilisk goes up, gives black box for few seconds, switches to gray, then 
boom:

 Unix]$ BasiliskII
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using /dev/dsp audio output
do_handle_screen_fault: unhandled address 0x42be0380 [IP=0x80a1730]
D0: 00000000 D1: fffcffff D2: fffffffc D3: 0230000f
D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000
A0: 0000003c A1: 00000002 A2: 00006244 A3: 00006650
A4: 00005e38 A5: 026d1380 A6: 00000000 A7: 0118fb5a
USP=00000000 ISP=0118fb5a MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=1 N=1 Z=0 V=0 C=0 IMASK=0
FP0: 0 FP1: 0 FP2: 0 FP3: 0
FP4: 0 FP5: 0 FP6: 0 FP7: 0
N=0 Z=0 I=0 NAN=0
0232e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4
next PC: 0232e8ea

Playing with the .basilisk_ii_prefs file didn't help much, also tried several 
ROMs of Quadra, Performa, different processors emulation - didn't help a 
single bit.

Any suggestions? directions to turn? people to talk to about it? 

The problem appear on version 0.9, current CVS snapshot, and the JIT version. 
It doesn't appear on the 0.8 version.

BTW: the configure script seems to have some problems: trying to disable ESD 
(I'm using KDE) or VSOF (for testing) simply doesn't work.

Thanks,
Hetz

[B2-devel] Still same crash/problem

[Hetz B. H. <he...@kd...>]

Ok, tested the new CVS snapshot.

Machine: P4-1.5Ghz, Geforce 2 (with the 2314 binary only drivers), 
XFree-4.1.0 (without the DRI of course), Red Hat 7.2 + all the updates..

Basilisk goes up, gives black box for few seconds, switches to gray, then 
boom:

 Unix]$ BasiliskII
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using /dev/dsp audio output
do_handle_screen_fault: unhandled address 0x42be0380 [IP=0x80a1730]
D0: 00000000 D1: fffcffff D2: fffffffc D3: 0230000f
D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000
A0: 0000003c A1: 00000002 A2: 00006244 A3: 00006650
A4: 00005e38 A5: 026d1380 A6: 00000000 A7: 0118fb5a
USP=00000000 ISP=0118fb5a MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=1 N=1 Z=0 V=0 C=0 IMASK=0
FP0: 0 FP1: 0 FP2: 0 FP3: 0
FP4: 0 FP5: 0 FP6: 0 FP7: 0
N=0 Z=0 I=0 NAN=0
0232e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4
next PC: 0232e8ea

Playing with the .basilisk_ii_prefs file didn't help much, also tried several 
ROMs of Quadra, Performa, different processors emulation - didn't help a 
single bit.

Any suggestions? directions to turn? people to talk to about it? 

BTW: the configure script seems to have some problems: trying to disable ESD 
(I'm using KDE) or VSOF (for testing) simply doesn't work.

Thanks,
Hetz

Re: [B2-devel] New CVS snapshot of Basilisk II available

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

Hi!

On Tue, Jan 15, 2002 at 05:51:28PM +0100, Gwenole Beauchesne wrote:
> BTW, is the m68k->x86 JIT compiler supposed to be for 1.0 or should we
> stabilize until 2.0 with a ppc->{x86,x86_64,[ia64]} as well? ;-)

If the x86 backend is stable, it would be a nice inclusion for 1.0.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] New CVS snapshot of Basilisk II available

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

> And, yes, it's now Basilisk II V1.0. :-)

BTW, is the m68k->x86 JIT compiler supposed to be for 1.0 or should we
stabilize until 2.0 with a ppc->{x86,x86_64,[ia64]} as well? ;-)

Bye,
Gwenol=E9 in <hopes> mode.

Re: [B2-devel] New CVS snapshot of Basilisk II available

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

Hi!

On Tue, Jan 15, 2002 at 04:33:05PM +0100, Gwenole Beauchesne wrote:
> > I've made a new CVS snapshot of Basilisk II you can get it from:
> 
> <http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_15012002.tar.gz>
> is probably what you meant. ;-)

Uhm, yes. :-)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] New CVS snapshot of Basilisk II available

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

Hi Christian,

> I've made a new CVS snapshot of Basilisk II you can get it from:
>   http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_31052001.tar.=
gz

<http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_15012002.tar.gz>
is probably what you meant. ;-)

Bye,
Gwenol=E9.

[B2-devel] New CVS snapshot of Basilisk II available

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

Hi!

I've made a new CVS snapshot of Basilisk II you can get it from:
  http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_31052001.tar.gz

The changes from the last snapshot are quite significant, with run-time
video and audio mode switching being the most useful one. A more complete
changelog is here:
  http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII/ChangeLog_snapshot

And, yes, it's now Basilisk II V1.0. :-)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] [PATCH] Large file support

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

Hi!

On Thu, Dec 27, 2001 at 02:18:01PM +0100, Gwenole Beauchesne wrote:
> OK to commit?

Yep.

> Note: I unconditionnaly define _USE_LARGEFILE_SUPPORT and
> _FILE_OFFSET_BITS whatever the underlying OS is.

This probably won't do any harm.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] [PATCH] Large file support

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

On Thu, 27 Dec 2001, Gwenole Beauchesne wrote:

> OK to commit? Tested on IA-32 with a 3 GB hard disk file.

Huh, is MacOS actually supposed to support it? My test consisted in
formatting the 3 GB disk image then copy some folder (Applications ->
ClarisWorks et al) then run some of them. It worked. I haven't tried to
completely fill the disk though.

Bye,
Gwenol=E9.

PS: Merry Christmas!

[B2-devel] [PATCH] Large file support

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

Hi,

Following feature request #496122, here is a patch:
<http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D496122&group_=
id=3D2123&atid=3D352123>

OK to commit? Tested on IA-32 with a 3 GB hard disk file.

Note: I unconditionnaly define _USE_LARGEFILE_SUPPORT and
_FILE_OFFSET_BITS whatever the underlying OS is. This is a glibc
specificity, I believe.

For gcc3/Fortran, some people defined _XOPEN_SOURCE to 500 instead of
_USE_LARGEFILE_SOURCE. So is _XOPEN_SOURCE_EXTENDED for Irix 6.2 because
struct timeval would not be declared otherwise.

--- BasiliskII/src/Unix/configure.in.LFS=09Sun Sep  2 15:50:05 2001
+++ BasiliskII/src/Unix/configure.in=09Thu Dec 27 14:06:24 2001
@@ -5,6 +5,10 @@
 AC_PREREQ(2.12)
 AC_CONFIG_HEADER(config.h)

+dnl These defines are necessary to get 64-bit file size support.
+AC_DEFINE(_USE_LARGEFILE_SOURCE, 1, [Get more functions for correct
standard I/O])
+AC_DEFINE(_FILE_OFFSET_BITS, 64, [Get 64-bit file size support])
+
 dnl Options.
 AC_ARG_ENABLE(xf86-dga,      [  --enable-xf86-dga       use the XFree86
DGA extension [default=3Dyes]], [WANT_XF86_DGA=3D$enableval],
[WANT_XF86_DGA=3Dyes])
 AC_ARG_ENABLE(xf86-vidmode,  [  --enable-xf86-vidmode   use the XFree86
VidMode extension [default=3Dyes]], [WANT_XF86_VIDMODE=3D$enableval],
[WANT_XF86_VIDMODE=3Dyes])

Bye,
Gwenol=E9.

Re: [B2-devel] Re: OS X

[Max H. <ma...@qu...>]

At 23:26 Uhr +0100 25.11.2001, Gwenole Beauchesne wrote:
>[Repost on the list]
>
>Hi,
>
>>        OK. I will try and grab the relevant files (main_unix.cpp ?)
>>  and try a test build too.
>
>Also check vm_alloc*
>
>>  > - Put in a new icon ;-)
>>
>>        Not done - I still like my current Icon!
>
>Personnaly, I opted for a raw green apple for the Mandrake Linux menu
>structure. The JIT version also has a 'J' inside the Apple. The fact is
>we shouldn't use Apple's icons.
>
>>        He worked out how to get the command keys and double clicks
>>  passed correctly through to the emulator, but the speed is still an
>>  issue.
>
>Usual tricks (VOSF, Direct Addressing) for the Unix port will be ported
>to MacOS X later. Those two hacks are sufficient to bring up to 2x
>performance improvement. Should it be enough ?

Then it would be still slow, but at least usable. The current 
"native" version is completly unusable. CVS is not working at all for 
me but one of the last point release was, and run faster, despite 
outputing via X11. The reason of this might be the double buffereing 
OS X performs.

>Is there anyway to do sort of DGA (Direct Graphic Access) ? Eventually,
>someone may want to check SDL sources out.

We are not really doing anything fancy in windowed mode of SDL at the 
moment, really. a simple NSQuickDrawView, that is all. We plan to 
improve this in the future, when we have time.

Direct screen output is a bit tricky when in windowed mode, to say 
the least. You essentially can only do it properly if no window is 
covering your, and that include drop shadows from other windows. Of 
course, this is not so surprising, but ne has to do some hacking to 
determine whether this is the case or not etc.

There was an article on this somewhere (or maybe I read on a mailing 
list), if I can find it I'll make sure to let you know.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [B2-devel] BasiliskII on SGI freeware page

[<gb...@di...>]

[Repost on the list]

Hi,

> If we can't have a full dynamically recompiling emulator for MIPS, it
> would be nice to at least get a portable emulator which does some basic
> liveness analysis of register and condition flag values, so it can avoid
> calculating useless values (isn't this what one of the commercial Mac
> emulators (Executor?) does?)

That's exactly what I once experimented in the past. i.e. dynamically
blocks of pointers to instruction handlers computing or not the
condition codes. Improvement was null at this time because I made silly
things such as computing block checksums before *each* use, the lookup
hash table was dumb too, dynamically allocating blocks. And I believe
this was before I implement direct addressing which removes most of the
bottlenecks due to memory accesses.

I may revive this project but I don't expect to gain more than 20%. We
may get more with what I would call Poor Man's Jitter (PMJ) and Gcc. The
latter trick implies "inlining" instruction handlers right into the
translation cache instead of having arrays of pointers to instruction
handlers, this requires gcc. Native registers will be used for Program
Counter, Pointer to Registers struct and probably MEMBaseOffset on
load/store arches (mips, sparc).

To summary, general improvements to the cpu core will be:
- Removal of useless condition codes computing
- Dynamic patching of the call site [BSR/JSR]
- PMJ support with *one* big translation cache (8 MB?)

But frankly, that's something I'd love for a ppc emulator instead. ;-)

As for caching m68k registers, we should get some profile about register
usage first. Then, statically decide at compile time which m68k
registers we choose to cache in native registers. Beware of code size
increase due to the number of new variants. Most likely cacheable
registers are A7, D0, and A0. Yet, only caching A7 is the easiest way to
take provided the current implementation of gencpu...

Bye,
Gwenol=E9.

Re: [B2-devel] Re: OS X

[<gb...@di...>]

[Repost on the list]

Hi,

>       OK. I will try and grab the relevant files (main_unix.cpp ?)
> and try a test build too.

Also check vm_alloc*

> > - Put in a new icon ;-)
>=20
>       Not done - I still like my current Icon!

Personnaly, I opted for a raw green apple for the Mandrake Linux menu
structure. The JIT version also has a 'J' inside the Apple. The fact is
we shouldn't use Apple's icons.

>       He worked out how to get the command keys and double clicks
> passed correctly through to the emulator, but the speed is still an
> issue.

Usual tricks (VOSF, Direct Addressing) for the Unix port will be ported
to MacOS X later. Those two hacks are sufficient to bring up to 2x
performance improvement. Should it be enough ?

Is there anyway to do sort of DGA (Direct Graphic Access) ? Eventually,
someone may want to check SDL sources out.

Bye,
Gwenol=E9.

[B2-devel] I'm away

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

Hi!

I'll be in Japan for the next 3 weeks. I hope nothing happens to the CVS
server. If it appears to be broken for >24 hours you may try e-mailing me
directly, but I may not be able to fix it remotely...

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] BasiliskII on SGI freeware page

[Brian J. J. <bjj...@ya...>]

(Sorry this is from the wrong mail account. I'm away from my usual
Internet access.)

--- Gwenole Beauchesne <gb...@di...> wrote:
> On Tue, 13 Nov 2001, Brian Johnson wrote:
> 
> > I've made BasiliskII 0.9-1 (31052001), built and packaged for
> IRIX,
> > available from the SGI freeware page:
> >
> >   http://freeware.sgi.com/index-by-alpha.html#basiliskii
> 
> Cool. ;-)
> 
> You might probably want to add the following as well, just in
> case...
> 
> However, you still need a copy of MacOS and a Macintosh ROM image
> to use
> Basilisk II (of course MacOS and Mac ROM are not included in this
> package).

Actually, it already does:  click on the package name, and you'll get
an excerpt from the README file (I think that's where it's from)
listing BII's features and some IRIX-specific caveats, along with the
stadard "you need a copy of MacOS and a ROM image" message.

> This makes me reminder that I still have to check the FPU emulation
> issues
> for Mips and Itanium processors... Talking about the Itanium, we
> use it
> with 16K pages so the video update code is probably now suboptimal
> on that
> kind of configuration. How big are pages under Irix in "standard" ?

4K on the smaller desktop machines (Indy, O2), 16K on the bigger
machines.  I've done most of my testing on the "bigger" machines, and
my development box falls in that category.

> Do you have decent screen update performance ?

Yes, it's quite good.  Using XShm, the video performance reported by
Speedometer is on par with the CPU performance, and it "feels" quite
snappy as well.  I'd say that the basic CPU emulation performance is
the probably the bottleneck on IRIX.  If we can't have a full
dynamically recompiling emulator for MIPS, it would be nice to at
least get a portable emulator which does some basic liveness analysis
of register and condition flag values, so it can avoid calculating
useless values (isn't this what one of the commercial Mac emulators
(Executor?) does?)

(Now, if I were really helpful, I'd point you at a GPLed emulator
which does that already....  Unfortunately, I don't know of one.  Oh
well.)


=====
Brian J. Johnson

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

[B2-devel] Re: OS X

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

[mmap() discussion deleted]

> OK that's still not fixed for 10.1 then. However, CVS has code to use
> vm_allocate/vm_deallocate functions under OS X.

	OK. I will try and grab the relevant files (main_unix.cpp ?)
and try a test build too.

..
> BTW, concerning the native/Aqua OS X port, the plan I had was:
> - Make it fully compile at the command line

	Done. (pbxbuild in the makefile)

> - Put in a new icon ;-)

	Not done - I still like my current Icon!

	I was going to investigate whether it was possible to use a
command-line utility to construct my current icon, but I haven't yet.

> - Commit in CVS

	I have sent a tarball to Christian which has the latest src,
and appropriate copyright in all source except NNThread.*

	Hopefully, all of that (except maybe the icon) can be committed.


...
> I believe you progressed really well now with Max, how far is it now?

	He worked out how to get the command keys and double clicks
passed correctly through to the emulator, but the speed is still an
issue.

-- 
| Nigel Pearson, ni...@in...    |  "Things  you  own     |
| Telstra iDevelopments, Sydney, Australia |   end up owning you"   |
|   Office: 9206 3468    Fax:  9212 6329   | "Ah. Flashback humour" |
|   Mobile: 0408 664435  Home: 9792 6998   |   Tyler - Fight Club   |

Re: [B2-devel] OS X

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

On Wed, 24 Oct 2001 ni...@in... wrote:

> Gwenole asked:
> > Do you mean that the CVS version in Direct Addressing mode now works ?
> > If so, they finally corrected mmap() and some other functions in 10.1.
>
> 	I just did a test build with #define DIRECT_ADDRESSING 1.
> RAMBaseHost = (uint8 *)mmap(0,...) still fails with ENOTSUP.

OK that's still not fixed for 10.1 then. However, CVS has code to use
vm_allocate/vm_deallocate functions under OS X. Unfortunately, last time I
tried the Xdarwin build under 10.0.3, the screen would remain black or B2
would crash. Will try again when I find time to cleanly reinstall
MacOS X 10.1 and Linux.

BTW, concerning the native/Aqua OS X port, the plan I had was:
- Make it fully compile at the command line
- Put in a new icon ;-)
- Commit in CVS
- Check Direct Addressing and VOSF support.

I believe you progressed really well now with Max, how far is it now?

Re: [B2-devel] BasiliskII on SGI freeware page

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

On Tue, 13 Nov 2001, Brian Johnson wrote:

> I've made BasiliskII 0.9-1 (31052001), built and packaged for IRIX,
> available from the SGI freeware page:
>
>   http://freeware.sgi.com/index-by-alpha.html#basiliskii

Cool. ;-)

You might probably want to add the following as well, just in case...

However, you still need a copy of MacOS and a Macintosh ROM image to use
Basilisk II (of course MacOS and Mac ROM are not included in this
package).

This makes me reminder that I still have to check the FPU emulation issues
for Mips and Itanium processors... Talking about the Itanium, we use it
with 16K pages so the video update code is probably now suboptimal on that
kind of configuration. How big are pages under Irix in "standard" ? Do you
have decent screen update performance ?

Bye,
Gwenole.

[B2-devel] BasiliskII on SGI freeware page

[Brian J. <bjj...@us...>]

I've made BasiliskII 0.9-1 (31052001), built and packaged for IRIX,
available from the SGI freeware page:

  http://freeware.sgi.com/index-by-alpha.html#basiliskii

For direct download:

  http://freeware.sgi.com/Dist/fw_BasiliskII-31052001.tardist

It will be on the November 2001 SGI freeware CD set as well.

						Brian J. Johnson

--------------------------------------------------------------------
  Email:   bjo...@sg...       U.S. Mail: SGI
  Office:  (651) 683-3621                    655F Lone Oak Drive
  Cellular:(651) DREAM-ON  :)                Mailstop F20
  Fax:     (651) 683-5599                    Eagan, MN  55121

   "You miss 100% of the shots you don't take."
                                           -- Wayne Gretzky's Coach

Re: [B2-devel] (no subject)

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

Hi!

On Mon, Oct 29, 2001 at 06:54:31PM +0100, Max Horn wrote:
> At least in my old copy of the "Macintosh Atlas", I only find this entry:
> ...
> $0BB3 = 2995 [Byte]      $FF to turn off device defined StyleExtra
> $0BB4 = 2996 [12 bytes]  Reserved for future use
> $0BC0 = 3008 [Word]      Supposed to represent FlEvtMask
> ...

Mine is longer: :-)

FDevDisable     BB3  $FF to disable device-defined style extra
CommToolboxGlob BB4  Pointer to CommToolbox globals
ShutDwnQHdr     BBC  List of installed shutdown procedures
NewUnused       BC0  Used to be FlEvtMask   

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] (no subject)

[Max H. <ma...@qu...>]

At 15:41 Uhr +0100 29.10.2001, Christian Bauer wrote:
>Hi!
>
>On Sat, Oct 27, 2001 at 06:12:12PM +0200, J=FCrgen Lachmann wrote:
>>  Does anybody know what that variable at $bb8 is about and why it isn't
>>  initialized properly ???
>
>This one is missing from my list. I have no idea what it does. From your
>description it sound like one of those "global data area" pointers.

At least in my old copy of the "Macintosh Atlas", I only find this entry:

=2E..
$0BB3 =3D 2995 [Byte]      $FF to turn off device defined StyleExtra
$0BB4 =3D 2996 [12 bytes]  Reserved for future use
$0BC0 =3D 3008 [Word]      Supposed to represent FlEvtMask
=2E..

So unless it was changed after that Mac II ROM (the last covered in 
that book), it seems this area is unused.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [B2-devel] (no subject)

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

Hi!

On Sat, Oct 27, 2001 at 06:12:12PM +0200, J=FCrgen Lachmann wrote:
> Does anybody know what that variable at $bb8 is about and why it isn't
> initialized properly ???

This one is missing from my list. I have no idea what it does. From your
description it sound like one of those "global data area" pointers.

Bye,
Christian

--=20
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] (no subject)

[L. <jue...@t-...>]

=?iso-8859-2?Q?From?=
Date: Sat, 27 Oct 2001 18:11:45 +0200
Message-ID: <yam...@sm...>
X-Mailer: YAM 2.3 [060] AmigaOS E-Mail Client (c) 1995-2000 by Marcel Beck  http://www.yam.ch/
Subject: MacsBug startup problem
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit

Hi everybody,

I am working on an interesting startup problem with OS8.1 and Macsbug installed.

About every second time I have my machine turned on, MacOS won't start, instead I get a "unimplemented Trap" error.

So far I have been able to trace the problem back to a global variable at $bb8 about which I cannot find any further information. That variable seems to get initialized by ROM to $ffffffff. 
Somewhere later in the boot process, that variable is set to a valid address.

MacsBug checks some bits in a byte ($bb8) + $42 and, if non-zero, calls FSMgr trap, leading to the error described above.
As a workaround, I patched MacsBug to always return zero at the $bb8 check, and so far everything seems to work.

Does anybody know what that variable at $bb8 is about and why it isn't initialized properly ???


Regards,
Jürgen
-- 
Jürgen Lachmann jue...@t-... Blaubeuren Germany

Re: [B2-devel] OS X

[Max H. <ma...@qu...>]

At 17:46 Uhr +1000 24.10.2001, ni...@in... wrote:

[...]

Sorry for not voicing anything for some time, but I am heads over 
busy with studies which started again, and some other things, and can 
only spend a little bit of time on Basilisk :(


>  > Next, the Build Styles are being abused: setting -O3 in the
>>  development build style, but no optimizations (e.g. default) in the
>>  deployment style is not very logical.
>
>	I have not been able to work out how to set different levels
>for the Development and Deployment variants of the target. Whenever
>I pull up the Target -> Build Settings pane, the 'Code Generation'
>'Optimization level' setting seems to be tied to the Target, not to
>the 'Build Style'.
>
>(i.e. Either -O3 applies to both, or 'None' applies to both)
>
>	Have you had any success with this?

Yes, it works well for me. Make sure that in the "Compiler Settings", 
you set the optimization level to "Default", then it will take the 
values from the build style.



>
>...
>>  it now runs, but the speed is very disappointing, both with and
>>  without -O3.
>
>	Interesting that you should say this. I got my copy of 10.1,
>and have run some tests. The time to boot my 32MB disk image
>(MacOS 7.6) definitely decreased:
>
>OS 10.0.4:	Over 30 seconds
>OS 10.1,:	22 seconds
>
>This was good, so I decided to clean and rebuild the project.
>The 'time to boot' test dropped to 19 seconds.


Well, I haven't measured the boot time, but if I compare 
responsiveness, redraw speed etc. of the emulated machine between 
Basilisk 0.9 / OS X and the X-Window version, the X-Win version 
clearly wins.

>
>
>
>Gwenole asked:
>>  Do you mean that the CVS version in Direct Addressing mode now works ?
>>  If so, they finally corrected mmap() and some other functions in 10.1.
>
>	I just did a test build with #define DIRECT_ADDRESSING 1.
>RAMBaseHost = (uint8 *)mmap(0,...) still fails with ENOTSUP.

yes, shared memory done in SysV style is not really supported, and 
according to Apple sources will not be in the foreseeable future, if 
ever. This also causes a problem with MIT-Shm in X-Window.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] OS X

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

	Max wrote:

> This code is baaaaad:
> 
> 	bitmap = [NSBitmapImageRep alloc];
> 	[bitmap initWith....
> 
> You should *NEVER* do this!!! always do it like this:
> 
> 	bitmap = [NSBitmapImageRep alloc];
> 	bitmap = [bitmap initWith....

	Have fixed.
...
> This is especially "interesting" if one considers the commment
> in the same line:
> 
> // If NULL, allocate own data

	Comment was actually referring to the fullBitmap argument.

...
> Next, the Build Styles are being abused: setting -O3 in the 
> development build style, but no optimizations (e.g. default) in the 
> deployment style is not very logical.

	I have not been able to work out how to set different levels
for the Development and Deployment variants of the target. Whenever
I pull up the Target -> Build Settings pane, the 'Code Generation'
'Optimization level' setting seems to be tied to the Target, not to
the 'Build Style'.

(i.e. Either -O3 applies to both, or 'None' applies to both)

	Have you had any success with this?


...
> it now runs, but the speed is very disappointing, both with and 
> without -O3.

	Interesting that you should say this. I got my copy of 10.1,
and have run some tests. The time to boot my 32MB disk image
(MacOS 7.6) definitely decreased:

OS 10.0.4:	Over 30 seconds
OS 10.1,:	22 seconds

This was good, so I decided to clean and rebuild the project.
The 'time to boot' test dropped to 19 seconds.



Gwenole asked:
> Do you mean that the CVS version in Direct Addressing mode now works ?
> If so, they finally corrected mmap() and some other functions in 10.1.

	I just did a test build with #define DIRECT_ADDRESSING 1.
RAMBaseHost = (uint8 *)mmap(0,...) still fails with ENOTSUP.

-- 
| Nigel Pearson, ni...@in...    | "Reality is that which,   |
| Telstra iDevelopments, Sydney, Australia |  when you stop believing  |
|   Office: 9206 3468    Fax:  9212 6329   |  in it, doesn't go away." |
|   Mobile: 0408 664435  Home: 9792 6998   |  Philip K. Dick - 'Valis' |