basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi,

> 2) Check whether VidLocal.desc updated when it ought to be?

OK, browsing through the log file, the following bits came out:

- The previous screen buffer address (now invalid) got loaded from
  CrsrBase low-mem at ROMBaseMac + 2e81e

Unfortunately, I don't have my real Mac handy with Mac'sBug to check which
function that address belongs to

- CrsrBase got overriden from the valid address to the old one at
  ROMBase + 2e546

pc 0202e546
d0 020b700c d1 00000400 d2 02020050 d3 02000001
d4 00000000 d5 00000000 d6 00000000 d7 0004000e
a0 00009540 a1 000094f0 a2 020169aa a3 02016aba
a4 00009d50 a5 0100fd90 a6 00000000 a7 0100fba0
21d8 0898         	move.l	(a0)+,CrsrBase

Relevant bits leading to that instruction (ROMBase is at 02000000):
0202e6aa: 2278 089c         	movea.l	CrsrDevice,a1	[A1=00002120]
0202e6ae: 2251              	movea.l	(a1),a1		[A1=000094f0]
0202e53a: 2069 0016         	movea.l	($0016,a1),a0	[A0=00002110]
0202e53e: 2050              	movea.l	(a0),a0		[A0=00009540]
0202e546: 21d8 0898         	move.l	(a0)+,CrsrBase

Suggested fix:
[[CrsrDevice] + 0x0016] = frame_base in video.cpp/switch_mode() ?

Bye,
Gwenole.

[B2-devel] Flight Recorder for m68k

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

Hi,

Following Christian's idea for the PPC emulator in SheepShaver, there is
now a Flight Recorder for the UAE 68k cpu core too. That should help
debugging those illegal screen faults.

Enjoy!

Gwenole.

Re: [B2-devel] Video switching problem and VOSF/DA

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

On Sat, 16 Mar 2002, Gwenole Beauchesne wrote:

> 1) Should I patch Frame buffer base in SlotROM whenever we call
> set_mac_frame_buffer() with new values?

Hmmm, this is already what you do. :-/

[B2-devel] Video switching problem and VOSF/DA

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

Hi,

Some users have been reporting problems with B2 crashing right at startup.
I never could reproduce it until today. B2 is built with VOSF and direct
addressing enabled. The problem occurs when I remove my
~/.basilisk_ii_xpram. Then I simply launch B2 again and it crashes.

do_handle_screen_fault: unhandled address 0x42877460 [IP=0x80b45cb]
[...]
0202e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4

Toying with video code, I noticed that this address was actually a
previously allocated screen buffer that is no longer valid because of a
mode switch.

Before the switch I had:

the_buffer = 0x42877000, the_buffer_copy = 0x4290e008, the_host_buffer =
0x427e0000, the_buffer_size = 618496
VideoMonitor.mac_frame_base = 021a7000

Then after:

the_buffer = 0x4290e000, the_buffer_copy = 0x820cb18, the_host_buffer =
0x8203470, the_buffer_size = 40960
VideoMonitor.mac_frame_base = 0223e000

1) Notice that MacOS 8 seems to be willing to switch to 1-bit mode

2) It's obvious that the previous screen buffer is gone

3) For some reason, though VideoMonitor.mac_frame_base contains the new
virtual (MacOS address space) frame buffer, MacOS is still using the old
screen buffer after the switch from VideoDriverControl(), hence the crash.

4) In slot_rom.cpp/InstallSlotROM(), VideoMonitor.mac_frame_base is used
only once at ROM patching time.

Solutions:

1) Should I patch Frame buffer base in SlotROM whenever we call
set_mac_frame_buffer() with new values?

2) Check whether VidLocal.desc updated when it ought to be?

Other ideas?

Thanks,
Gwenole.

Re: [B2-devel] Large File support and portability

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

Hi!

On Sat, Mar 16, 2002 at 12:03:32PM +0100, Gwenole Beauchesne wrote:
> Would it be OK for all of you to switch to autoconf-2.5+ ?

Yup.

Bye,
Christian

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

[B2-devel] Large File support and portability

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

Hi all,

I have made the Large File support thing specific to Linux systems since
it broke build on Solaris/SPARC and I could only test this features under
Linux.

IMHO, it would be better to use the AC_SYS_LARGEFILE macro from
autoconf-2.5+. Would it be OK for all of you to switch to autoconf-2.5+ ?

Thanks,
Gwenole.

Re: [B2-devel] Mac OS X fullscreen

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

Hi!

Sorry for the delay, but I never seem to have the ShapeShifter source
at hand when I need it...

On Thu, Mar 07, 2002 at 01:01:25PM +1100, Nigel Pearson wrote:
> 2) If we ever augment B2 to support more than one monitor,
>     the monitor_desc structure would need to have a list
>     of video_modes supported by that monitor.

Now would be a good time to do that augmentation. Here's a draft:

- struct video_mode remains as it is now
- the global VideoModes vector is removed
- struct monitor_desc gets transformed into an abstract base class:

    class monitor_desc {
    public:
      monitor_desc()
      {
        slot_id = next_slot_id++;
      }
      virtual ~monitor_desc() {}

      // Get Mac frame buffer base address
      uint32 get_mac_frame_base(void) const {return mac_frame_base;}

      // Get bytes-per-row value for specified resolution/depth
      uint32 get_bytes_per_row(video_depth depth, uint32 id) const;

      // Get Mac slot ID number
      uint8 get_slot_id(void) const {return slot_id;}

      // Get current video mode
      const video_mode &current_mode(void) const {return *current_mode;}

      // Check whether a mode with the specified depth exists on this display
      bool has_depth(video_depth depth) const;

      // Switch video mode on this display
      virtual void switch_to_mode(const video_mode &mode) = 0;

      // Set palette or gamma table
      virtual void set_palette(uint8 *pal, int num) = 0;

      // List of supported video modes
      vector<video_mode> modes;

      // Maybe some utility routines from video.cpp should be moved here as
      // well, such as get_size_of_resolution(). Practically anything that
      // used the VideoModes vector.
      ...

    protected:
      // Pointer (iterator?) to currently active mode
      video_mode *current_mode;

      // Mac frame buffer base
      uint32 mac_frame_base;

      // Mac slot ID number
      uint8 slot_id;

      // Next available slot ID
      static uint8 next_slot_id = 0x80;
    };

- platform-specific code subclasses monitor_desc (e.g. X11_monitor_desc,
  or even X11_DGA_monitor_desc; this could replace the driver_base class in
  video_x.cpp), implementing the virtual functions
- the global VideoMonitor variable gets replaced by a vector<monitor_desc *>
  which is filled in by VideoInit()
- I'm not sure whether the apple_mode_for_depth[] array needs to be global
  or local to each monitor (my guess is local). This array and associated
  functions (video_init_depth_list(), DepthToAppleMode()) would then have
  to be moved to monitor_desc as well.
- for UAE banked addressing, we need multiple MacFrameBaseHost/MacFrameSize
  variables
- slot.cpp needs to create one slot resource for each monitor, using the
  slot_id in the monitor_desc
- the Mac video driver code can determine the monitor_desc its associated
  with by looking at its dCtlSlotId and scanning the monitor_desc vector
  (or maybe it would be better to have a map<uint8, monitor_desc *>?)

Any comments/ideas?

Bye,
Christian

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

[B2-devel] Basilisk II, Mac OS X port, fullscreen

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

	Version 9 of my ported code, which supports fast full screen =
mode,
is now available here: http://homepage.mac.com/~nigelpearson
as both pre-compiled application, and MacOSX source tree.

	It should be quite reliable and usable.

	Note that there is no special key combination to exit full =
screen,
but if something goes wrong, Apple-Option-Escape instantly and safely
terminates the program.

	Hopefully this weekend I will have a go at CVS committing it.

--
|Nigel Pearson, ni...@in...  |=93Now the world has gone to =
bed,|
|Telstra iDevelopments, Sydney Australia| Darkness won=92t engulf my =
head,|
|  Office: 9206 3468    Fax:  9212 6329 | I can see by infrared,        =
|
|  Mobile: 0408 664435  Home: 9792 6998 | How I hate the night.=94 =
-Marvin|

[B2-devel] Problem with DGA and DirectColor visuals

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

Hi,

Back to my DGA problems. As a reminder: each time I start B2 (JIT or
normal CVS) in fullscreen DGA mode, I get a BadMatch from X_CreateWindow
[*].  It turns out that it's because B2 picked up a DirectColor visual and
then fails for some reason. If, however, I prefer a TrueColor visual over
a DirectColor visual (video_x.cpp/find_visual_for_depth), things work
modulo colors being swapped or whatever.

System info: XFree86 4.2.0 or even 4.1.0 running in 16,24,32 bpp mode.

[*] Sample error log
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  1 (X_CreateWindow)
  Serial number of failed request:  29
  Current serial number in output stream:  35

Any ideas?

Thanks,
Gwenole

[B2-devel] Mac OS X fullscreen

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

	OK. I have a full screen mode mostly working:

* It is a hell of a lot faster than windowed mode
   (because we are drawing straight to VRAM. No refresh task. Yay!)

* It supports 32, 16 and 8bit modes,
   the latter with colour palette switching
   (both Colour and Greys in the Monitors CP)


	There are still some mouse pointer issues, so I am not quite =
ready
to release it yet (maybe tomorrow). There is a B2 code problem, though,
that I would like to discuss.

1) At the moment, there is one instance of a monitor_desc structure,
    so there is only one monitor in the emulation environment. Fair=20
enough.

    There is also an list(vector) of video_mode structures so that we
    can support multiple resolutions and depths on that one monitor.
    Also OK.

    My problem is porting this onto a multiple-monitor capable machine.
    Unless I always assume that B2 will use the main monitor, I need to
    store both a display_id and a hardware mode for those video_modes.

2) If we ever augment B2 to support more than one monitor,
    the monitor_desc structure would need to have a list
    of video_modes supported by that monitor.


	Now, I could create an auxilliary structure in video_macosx.mm,
just for linking each video_mode with a display and hardware mode,
but it would be easier if this stuff was stored in video_mode,
or video_mode and monitor_desc.

	What do we think of:

// Description of a video mode
struct video_mode {
     uint32 x;               // X size of screen (pixels)
     uint32 y;               // Y size of screen (pixels)
     uint32 resolution_id;   // Resolution ID (should be >=3D 0x80 and=20=

uniquely
                             // identify the sets of modes with the same=20=

X/Y size)
     uint32 mode_id;         // Graphics hardware mode for this =
X/Y/Depth
     uint32 display_id;      // For machines that support more than one=20=

display
     uint32 bytes_per_row;   // Bytes per row of frame buffer
     video_depth depth;      // Color depth (see definitions above)
};

--
|Nigel Pearson, ni...@in...  |=93Now the world has gone to =
bed,|
|Telstra iDevelopments, Sydney Australia| Darkness won=92t engulf my =
head,|
|  Office: 9206 3468    Fax:  9212 6329 | I can see by infrared,        =
|
|  Mobile: 0408 664435  Home: 9792 6998 | How I hate the night.=94 =
-Marvin|

[B2-devel] Native OS X version 1.0, screen buffer questions

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

Gwenole asked:
> Knowing nothing to CoreGraphics, I have a
> question: how are screen updates managed? I mean is the_buffer
> automatically blitted to the screen by MacOS X?

	Automatically? Well, not really. I have a task that calls
a routine that draws the image in the window. It uses the most
efficient calls there are, but there is something causing a
huge slowdown. I will eventually try using QuartzDebug to see
if there are any obvious problems, but thus far the magical
fix has eluded me.

	I am hoping that a more experienced programmer will be able
to check out the code and work out what I am doing wrong. So far,
no-one had replied to my messages on the macosx-dev mailing list.

	I will also eventually add OpenGL and CGDirectGraphics code.
The latter may be able to do the "automatic blitting" thing.


> Don't you use a back buffer?

	A window has the option of buffered, retained or non-retained.
The latter two are actually slightly slower than buffered, and they
have problems keeping all the other window gadgets drawn, so I am
still using the buffered option.


	Anyone interested in playing with this can edit the compiled
program's interface (using /Developer/Applications/Interface Builder on
the file BasiliskII.app/Contents/Resources/English.lproj/MainMenu.nib).
It should also be possible to add a button to call the benchmark method
( [EmulatorView benchMark] )

--
|Nigel Pearson, ni...@in...  |=93Now the world has gone to =
bed,|
|Telstra iDevelopments, Sydney Australia| Darkness won=92t engulf my =
head,|
|  Office: 9206 3468    Fax:  9212 6329 | I can see by infrared,        =
|
|  Mobile: 0408 664435  Home: 9792 6998 | How I hate the night.=94 =
-Marvin|

Re: [B2-devel] Native OS X version 1.0 ready

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

Hi Nigel,

> 	Sadly, there are still the same display issues:
> * Performance is still woefull (about 15fps at 512x342x32 on a 400MHz 
> G4)

Indeed as major slow-down comes from Video ouput, IMHO. :-(

Some comments after a quick test:

1) Prefs Editor forgetting a few items. The prefs editor doesn't save 
the following configs:
- RAM size
- Model ID
- FPU state. Note however that in 68040 mode, the FPU is always enabled

2) Initially, config.h.in does not exist. You symlinked it to the one 
inside ../Unix, but even that one doesn't exist after a clean CVS 
checkout. However, you can copy from there acconfig.h and config.h.in 
then running autoheader within the MacOSX directory will be OK.

3) Sadly, AC_TYPE_SOCKLEN_T is not recognized by MacOS X 10.1 autoconf. 
In configure.in, I think you could use AC_CHECK_TYPE(socklen_t) to 
workaround that problem.

4) Concerning VOSF. This appears to be the only remaining to be 
implemented. I will have a look this weekend. Direct addressing may then 
work because vm_alloc.cpp now contains enough to use the Mach VM 
functions instead of mmap() and the like. Besides, sigsegv.cpp contains 
the necessary magic to retrieve the faultive address in a SIGSEGV 
handler, although suboptimally.

5) Still concerning VOSF, is it possible to blit only parts of the 
buffer to the screen? I mean something equivalent to XShmPutImage(...)?

Bye,
Gwenole.

Re: [B2-devel] Native OS X version 1.0 ready

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

At 10:37 Uhr +0100 15.02.2002, Gwenole Beauchesne wrote:
>Hi,
>
>>  * It now compiles against the 1.0 snapshot,
>>    and also supports resolution changing
>
>This is great, thank you. Knowing nothing to CoreGraphics, I have a
>question: how are screen updates managed? I mean is the_buffer
>automatically blitted to the screen by MacOS X? Don't you use a back
>buffer?

Normally, all windows have a back buffer managed by the CoreGraphics 
engine. You can turn this feature off, but this was buggy in older 
System revision (i.e. pre-10.1; I am not sure if it is exactly bug 
free in the current system version, though :)

In many cases, you want the system to handle the back buffer, since 
it is quite well optimized and automates screen updates for you, but 
for games and emulators, this is not always desirable.


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

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

Re: [B2-devel] Native OS X version 1.0 ready

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

Hi,

> * It now compiles against the 1.0 snapshot,
>   and also supports resolution changing

This is great, thank you. Knowing nothing to CoreGraphics, I have a
question: how are screen updates managed? I mean is the_buffer
automatically blitted to the screen by MacOS X? Don't you use a back
buffer?

Bye,
Gwenole

[B2-devel] Native OS X version 1.0 ready

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

	Version 8 of the binary and source are available here:

http://homepage.mac.com/~nigelpearson/FileSharing1.html


* It now compiles against the 1.0 snapshot,
  and also supports resolution changing

* The Objective-C -> C++ glue stuff is now gone
  (it now uses Objective-C++)

* Command-line and IDE building, and testing is supported by the Makefile
  (e.g. make, make ide, make test)

* The filenames have changed from video_MacOSX.cpp to video_macosx.mm
  (I remember someone thought that would be
   more consistant with the rest of the source)

* All files have the latest copyright, and configure.in and Makefile.in
  have incorporated recent changes to their Unix bretherin



	Sadly, there are still the same display issues:

* Performance is still woefull (about 15fps at 512x342x32 on a 400MHz G4)

* Only 32bit graphics modes are supported



	I will eventually implement full-screen and OpenGL graphics,
but in the meantime I would like to get it committed to the CVS tree.
(I realised that I have been playing with this source for 14 months!)
As far as I know, the only issues preventing commit are:

1) The Icon.
   Solution: Just don't commit these files

2) The lack of copyright in NNThread.h and NNThread.m
   It has a "Public Domain" header. Is that OK?

3) The extfs_macosx.mm file really should go into Unix
   (i.e. become Unix/Darwin/extfs_darwin.cpp),
   but until some X-windows users start to play with it,
   it can stay where it is.


	Can someone please commit this? Pretty please?

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

Re: [B2-devel] SheepShaver sources in CVS

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

Hi!

On Sat, Feb 09, 2002 at 11:41:58AM +0100, Gwenole Beauchesne wrote:
> But is there a NewWorld ROM of 4 MB in size?

Uncompressed they are 4MB.

> Could it be possible to use the UAE m68k emulator?

Probably, with some modifications. It would require reverse-engineering
the opcodes added by Apple.

Bye,
Christian

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

Re: [B2-devel] SheepShaver sources in CVS

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

Hi,

> > 1) Pardon my ignorance but browsing through the sources, it appears SS
> > supports NewWorld ROMs
>
> Yes, but not all flavours of them.

But is there a NewWorld ROM of 4 MB in size? I mean main_unix.cpp contains
a check to "abort" if the specified ROM in not recognized (TNT, NewWorld,
etc.) but then further checks its size.

Or is a 4 MB ROM from a PowerMac PCI needed then the one found on the
system disk overrides it when booting?

> > 2) It appears that SS currently relies on real addressing mode. How many
> > memory regions could be relocated "together"?
>
> The ROM and RAM - maybe (I don't know whether it would work with a relocated
> ROM). The nanokernel and 68k emulator data areas are fixed at 0x5fffe000 and
> 0x68ffe000.

Could it be possible to use the UAE m68k emulator? Though there are
apparently some issues in doing so: how m68k exceptions are
triggered, handled and interacted with MacOS?

Bye,
Gwenole.

Re: [B2-devel] SheepShaver sources in CVS

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

Hi!

On Thu, Feb 07, 2002 at 11:46:06PM +0100, Gwenole Beauchesne wrote:
> 1) Pardon my ignorance but browsing through the sources, it appears SS 
> supports NewWorld ROMs

Yes, but not all flavours of them.

> 2) It appears that SS currently relies on real addressing mode. How many 
> memory regions could be relocated "together"?

The ROM and RAM - maybe (I don't know whether it would work with a relocated
ROM). The nanokernel and 68k emulator data areas are fixed at 0x5fffe000 and
0x68ffe000.

Bye,
Christian

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

Re: [B2-devel] patch: clean up thread attributes

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

Hi!

On Thu, Feb 07, 2002 at 04:31:23PM -0600, Brian Johnson wrote:
> Would it work to check the return value of
> pthread_attr_setschedpolicy() and redo the attributes if it fails,

No, that always returns 0.

Bye,
Christian

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

Re: [B2-devel] SheepShaver sources in CVS

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

Hi,

> The "emul_ppc" directory contains a partially implemented PPC opcode
> interpreter but it can't boot MacOS yet, so this only works if you have
> a PowerPC machine with BeOS or Linux on it.

1) Pardon my ignorance but browsing through the sources, it appears SS 
supports NewWorld ROMs, however a 4 MB PowerMac PCI ROM is needed. 
Wasn't NewWorld ROMs (MacOS 8.6+) supposed to be sufficient?

2) It appears that SS currently relies on real addressing mode. How many 
memory regions could be relocated "together"? I am thinking here about 
direct addressing for a ppc emulator in case other arches don't support 
fix mmaping to the requested regions. Sure, fallbacking to the old 
banked memory addressing could be a solution too.

Bye,
Gwenole.

Re: [B2-devel] patch: clean up thread attributes

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

--- Christian Bauer <cb...@th...> wrote:
> On Fri, Feb 01, 2002 at 03:51:08PM -0600, Brian Johnson wrote:
> > Here's a patch which reworks BII's pthread attributes a bit, and
> > results in much smoother performance, at least under Irix.
>
> Thanks. I had to make some changes to make this work under Linux:
> ...
>  - messing with pthread_attr_setschedpolicy() if you're not the
>    superuser is not a no-op but causes pthread_create() to fail, so
>    I've put back the "if (geteuid() == 0)"

That's unfortunate, since geteuid()==0 is not required on Irix:  Irix
has a more fine-grained permissions system, so all you really need is
"CAP_SCHED_MGT capability", not full root privileges.  It's possible
to query for CAP_SCHED_MGT directly, but that doesn't sound very
portable, and would require yet another layer of autoconf goo.

Would it work to check the return value of
pthread_attr_setschedpolicy() and redo the attributes if it fails,
kind of like we do with pthread_attr_setscope()?  Or I suppose you
could just put the "if (geteuid() == 0)" under "#ifndef sgi", if
there's no better way.

> > Which brings up the question of thread priorities:  in stock BII,
> > all the threads run at the same, "average" priority, except the
> > ethernet thread runs at average+1 and the serial thread runs at
> > average+2.  Is there a specific reason for this priority scheme
> > (eg. MacOS interrupt priorities)?
>
> I thought it might improve responsivity for interactive networking
> applications. There's no deeper meaning to it.

Hmmm.  I'll have to try some experiments.  (Don't hold your breath,
though -- I'm about to get ridiculously busy at work.)

						Brian

--------------------------------------------------------------------

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

Re: [B2-devel] patch: clean up thread attributes

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

Hi!

On Fri, Feb 01, 2002 at 03:51:08PM -0600, Brian Johnson wrote:
> Here's a patch which reworks BII's pthread attributes a bit, and
> results in much smoother performance, at least under Irix.

Thanks. I had to make some changes to make this work under Linux:

 - there's no pthread_mutexattr_setprotocol()
 - pthread_mutexattr_settype() requires defining _XOPEN_SOURCE=500, but then
   gethostname() disappears... I've decided to #ifdef out
   pthread_mutexattr_settyp() instead (although the configure script says
   it's there...)
 - messing with pthread_attr_setschedpolicy() if you're not the superuser
   is not a no-op but causes pthread_create() to fail, so I've put back
   the "if (geteuid() == 0)"

> Which brings up the question of thread priorities:  in stock BII, all
> the threads run at the same, "average" priority, except the ethernet
> thread runs at average+1 and the serial thread runs at average+2.  Is
> there a specific reason for this priority scheme (eg. MacOS interrupt
> priorities)?

I thought it might improve responsivity for interactive networking
applications. There's no deeper meaning to it.

Bye,
Christian

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

Re: [B2-devel] SheepShaver sources in CVS

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

> The "emul_ppc" directory contains a partially implemented PPC opcode
> interpreter but it can't boot MacOS yet, so this only works if you have
> a PowerPC machine with BeOS or Linux on it.

Is there any PowerPC emulator available? even our commercial competitors 
(Emulators, Inc - creator of SoftMac) doesn't have a PowerPC chip emulation. 
Anyone did this before?

Hetz

[B2-devel] SheepShaver sources in CVS

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

Hi!

For those of you who want to play with PowerMac emulation, I've imported
the sources of SheepShaver to the CVS server (it can be accessed under the
module name "SheepShaver"). This is not a finished release yet, the docs
have to be updated and I have to check whether this still compiles on BeOS.

SheepShaver uses a lot of source files from Basilisk II and you need a
checked out CVS tree of Basilisk II to compile it:

  $ cvs checkout BasiliskII
  $ cvs checkout SheepShaver
  $ cd SheepShaver
  $ make links
  $ cd src/Unix
  $ ./autogen.sh
  $ make

"make links" will create the necessary links to the B2 sources (I haven't
figured out how to share source files between projects in CVS).

The "emul_ppc" directory contains a partially implemented PPC opcode
interpreter but it can't boot MacOS yet, so this only works if you have
a PowerPC machine with BeOS or Linux on it.

Bye,
Christian

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

[B2-devel] patch: clean up thread attributes

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

Here's a patch which reworks BII's pthread attributes a bit, and
results in much smoother performance, at least under Irix.  Basically,
BasiliskII (like any real-time application) runs best when its threads
are scheduled at system scope:  the kernel scheduler has full insight
into what's going on on the machine, and can schedule events like the
60hz interrupt reliably.

Linux pthreads uses system scope by default.  Irix pthreads uses
process scope by default (i.e. the pthread library does all its own
scheduling within the process, whenever the kernel happens to let it
run) and system scope requires root (actually CAP_SCHED_MGT)
privileges, since a high-priority realtime application can starve out
all other processes on the machine.  As a non-privileged approximation
to system scope, Irix provides "bound scope", which exposes pthread
scheduling to the kernel, without allowing actual realtime priority.

Anyway, I've modified BII to request system scope, and fall back to
bound scope if it's available and system scope isn't.  I also changed
the mutexes to request priority inheritance, to ensure that a
high-priority thread gets to run soon even when a lower priority
thread has locked a mutex it wants.  BII runs much more smoothly as a
result, especially when playing audio.

Which brings up the question of thread priorities:  in stock BII, all
the threads run at the same, "average" priority, except the ethernet
thread runs at average+1 and the serial thread runs at average+2.  Is
there a specific reason for this priority scheme (eg. MacOS interrupt
priorities)?  I'd think that the tick thread should have the highest
priorities so MacOS can maintain accurate timing, followed by the
audio and video threads.  It's not like the host OS will drop
characters at the serial ports if we don't read them fast enough....

						Brian

--------------------------------------------------------------------

  Q: How do you get down from an elephant?
  A: You don't, silly.  You get down from a goose!
                                           -- A Prairie Home Companion