basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] SDL target

[Christian B. <Chr...@un...>]

Hi!

On Sat, Jun 05, 2004 at 11:20:25AM +0200, Gwenole Beauchesne wrote:
> - audio: SDL_mixer?

Plain SDL audio functions should be sufficient.

> - floppy: unknown

No.

> - cdrom: SDL?

Only CD audio functions.

> - disk: raw C/C++ streams?

Access to paritions is unfortunately always platform-dependent. Filedisks
should be no problem.

> - scsi: unknown

No.

> - clipboard: unknown, probably ending up to X11/Win32/Mac backends.

Nothing in SDL.

> - serial: completely unknown

No.

> - network: QEMU has a user-space network stack through slirp but I will 
> have to try again to get it working in B2/SS at decent speeds.

The UDP tunnel should work with SDL_net.

> Have I forgot anything?

Mouse/keyboard input: SDL ;-)

We might actually try to do InputSprockets support for devices like
joysticks, too.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Assert(cur_mose != -1) error on start

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

Hi,

>  lr 40b13c20  ctr 203ffec2   cr 80500000  xer 20000000
>  pc 40b13c20 fpscr 00000000
> Error Code: 0

That's near the NanoKernel interrupt routine, but I can't find anything 
else.

Could you turn on the logger in kpx_cpu/sheepshaver_glue.cpp 
(emul_ppc)? Then, when it crashes again, you can type "dump", and it 
writes a ppc.log in the current directory. If you can also tell me what 
ROM it is. The resulting file is big so, please send it to me 
privately, compressed.

Some independent things you could try too:
- In sysdeps.h, turn off PPC_REENTRANT_JIT and rebuild
- In sysdeps.h, turn off DYNGEN_ASM_OPTS and rebuild ppc-dyngen-ops.cpp 
(remove obj/ppc-dyngen-ops.o and make)
- In sysdeps.h, add a "#define DYNGEN_DIRECT_BLOCK_CHAINING 0" (without 
double quotes), and rebuild

Thanks,

Re: [B2-devel] Assert(cur_mose != -1) error on start

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

Gwenole,

I too am having problems with JIT enabled.  SheepShaver boots without JIT
enabled, but as soon as it is enabled, a black window will show up for a
second, then crash back to the shell.  I ran ./SheepShaver; echo "Error
Code: $?" and it returned Error Code: 255.  It returned the same error code
regardless of which video modes were enabled, or whether quickdraw was
enabled, or whether the DR emulator was enabled or not.  However, when I
unchecked "Ignore Illegal Memory Accesses," it sigsev'd, with the message:

bash-2.05b$ ./SheepShaver; echo "Error Code: $?"
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
PowerPC CPU emulator by Gwenole Beauchesne
SIGSEGV
  pc 0x40f5d03e
  ea 0x3c00
 r0 00000000   r1 68ffe000   r2 00000000   r3 68fff400
 r4 00200000   r5 68fff740   r6 68fff100   r7 80800007
 r8 00000001   r9 00000000  r10 40c6e020  r11 0002f072
r12 40c6e020  r13 80500000  r14 00000000  r15 00000000
r16 00000002  r17 203ffeea  r18 200033e0  r19 40862b10
r20 203ffef6  r21 20ffff88  r22 203ffff6  r23 00000000
r24 2001ec32  r25 00000820  r26 fffffffe  r27 00000028
r28 00000000  r29 40cff008  r30 40c60000  r31 68fff000
 f0 0.00000   f1 0.00000   f2 0.00000   f3 0.00000
 f4 0.00000   f5 0.00000   f6 0.00000   f7 0.00000
 f8 0.00000   f9 0.00000  f10 0.00000  f11 0.00000
f12 0.00000  f13 0.00000  f14 0.00000  f15 0.00000
f16 0.00000  f17 0.00000  f18 0.00000  f19 0.00000
f20 0.00000  f21 0.00000  f22 0.00000  f23 0.00000
f24 0.00000  f25 0.00000  f26 0.00000  f27 0.00000
f28 0.00000  f29 0.00000  f30 0.00000  f31 0.00000
 lr 40b13c20  ctr 203ffec2   cr 80500000  xer 20000000
 pc 40b13c20 fpscr 00000000
Error Code: 0

Hope this helps.


~Marc

Re: [B2-devel] Small Bug

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

Hi,

> The text editing cursor for the mouse does not appear, at least on the=20=

> basic
> apple text editing program.

Christian gave an explanation about X11 not handling cursor masks=20
exactly as MacOS. In video_x.cpp, you can disable hw cursor=20
"acceleration", by turning "hw_mac_cursor_accl" constant to false.

Hmm, just got an idea, will try. ;-)

Bye,
Gwenol=E9.=

Re: [B2-devel] Assert(cur_mose != -1) error on start

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

samedi 5 juin 2004, =E0 08:36  pm, Dr. Max a =E9crit :

> That did help! Unfortunately fullscreen still gives me this error:
>
> XF86DGAGetVideo: failed to map video memory (Permission denied)

Your user has to get r/w access to /dev/mem. Either be root (or setuid=20=

root), or make the user in group mem and put /dev/mem for that group=20
too. Either way is not safe, that's why I don't use fullscreen DGA. And=20=

I don't know any safe way to do DGA, btw. Except through fbdev.

A word of caution about DGA: it does not work everywhere. So far, it=20
works with builtin radeon of my PBG4 but miserably fails (the X server=20=

hangs) on e.g. xf86 with a radeon 9700.

> Also in regard to theblackwindow error, this also occurs in 800x600,=20=

> but I
> might have a clue as to its origin as it does not occur if you disable=20=

> the
> JIT compiler.

Can you try again as
./SheepShaver; echo "Error Code: $?"

And report me the Error Code number.

Re: [B2-devel] Assert(cur_mose != -1) error on start

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

samedi 5 juin 2004, =E0 08:46  pm, Dr. Max a =E9crit :

> On Saturday 05 June 2004 12:19 am, Gwenole Beauchesne wrote:
>
> Also congrat's on the video!  You've corrected a number of errors in=20=

> Lords of
> the Realm 2!

Hmm, can I know what they were? I think this wanted 8 bpp support,=20
isn't it?=

[B2-devel] Small Bug

[Dr. M. <cs...@uc...>]

Hi again :)

The text editing cursor for the mouse does not appear, at least on the basic 
apple text editing program.

Max

Re: [B2-devel] Assert(cur_mose != -1) error on start

[Dr. M. <cs...@uc...>]

On Saturday 05 June 2004 12:19 am, Gwenole Beauchesne wrote:

Also congrat's on the video!  You've corrected a number of errors in Lords =
of=20
the Realm 2!

> Hi,
>
> > Regarding the mode selection, this was actually 800x600 resolution
> > windowed
> > mode with no other mode selected.
>
> OK, should be fixed in CVS now.
>
> > Out of curiosity I tried it in 640x480
> > windowed and the program displayed the SheepShaver window for a
> > fracton of a
> > second then closed with no written indication of an error on the
> > console.
>
> I assume this is a black window? Another person reported that but I
> don't know how this happens. :-(
>
> Bye,
> Gwenol=E9.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>
> >From Windows to Linux, servers to mobile, InstallShield X is the one
>
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Assert(cur_mose != -1) error on start

[Dr. M. <cs...@uc...>]

Hi again!

That did help! Unfortunately fullscreen still gives me this error:

XF86DGAGetVideo: failed to map video memory (Permission denied)

Could that be because of my setup?

Also in regard to theblackwindow error, this also occurs in 800x600, but I=
=20
might have a clue as to its origin as it does not occur if you disable the=
=20
JIT compiler.

=2DMax

On Saturday 05 June 2004 12:19 am, Gwenole Beauchesne wrote:
> Hi,
>
> > Regarding the mode selection, this was actually 800x600 resolution
> > windowed
> > mode with no other mode selected.
>
> OK, should be fixed in CVS now.
>
> > Out of curiosity I tried it in 640x480
> > windowed and the program displayed the SheepShaver window for a
> > fracton of a
> > second then closed with no written indication of an error on the
> > console.
>
> I assume this is a black window? Another person reported that but I
> don't know how this happens. :-(
>
> Bye,
> Gwenol=E9.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>
> >From Windows to Linux, servers to mobile, InstallShield X is the one
>
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] SDL target

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

Hi,

Tomasz brought up an interesting project to think about: getting more=20
portable through SDL. Lauri no longer can maintain the Windows port and=20=

we don't know about other Windows developer willing to take over, so=20
having an SDL version can do the trick for B2 1.0 (we need to get it=20
out some day ;-), and SheepShaver afterwards.

Let's brainstorm about our needs and possible solutions (trying to keep=20=

in mind Windows too).
- threads: SDL does it, and there is a pthreads-win32 port too.
- graphics: SDL does it. VOSF stuff can still be kept to track dirty=20
framebuffer pages
- audio: SDL_mixer?
- floppy: unknown
- cdrom: SDL?
- disk: raw C/C++ streams?
- scsi: unknown
- clipboard: unknown, probably ending up to X11/Win32/Mac backends.
- serial: completely unknown
- network: QEMU has a user-space network stack through slirp but I will=20=

have to try again to get it working in B2/SS at decent speeds.
- timers: SDL
- gui: stick to gtk?
- build environment: stick to autoconf/makefiles?
- memory allocation: standard C, but for fixed addressing, we need to=20
enhance vm_alloc.cpp wrappers to Windows.
- SIGSEGV handling: we need to merge win32 support from Bruno Haible's=20=

libsigsegv library.

Have I forgot anything?

Bye,
Gwenol=E9.=

Re: [B2-devel] Assert(cur_mose != -1) error on start

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

Hi,

> Regarding the mode selection, this was actually 800x600 resolution=20
> windowed
> mode with no other mode selected.

OK, should be fixed in CVS now.

> Out of curiosity I tried it in 640x480
> windowed and the program displayed the SheepShaver window for a=20
> fracton of a
> second then closed with no written indication of an error on the=20
> console.

I assume this is a black window? Another person reported that but I=20
don't know how this happens. :-(

Bye,
Gwenol=E9.

Re: [B2-devel] Assert(cur_mose != -1) error on start

[Dr. M. <cs...@uc...>]

Regarding the mode selection, this was actually 800x600 resolution windowed=
=20
mode with no other mode selected.  Out of curiosity I tried it in 640x480=20
windowed and the program displayed the SheepShaver window for a fracton of =
a=20
second then closed with no written indication of an error on the console. i=
n=20
regard to debug data, this is what I get for available modes:

Available video modes:
 640x480 (ID 82), 2 colors
 640x480 (ID 82), 4 colors
 640x480 (ID 82), 16 colors
 640x480 (ID 82), 256 colors
 640x480 (ID 82), 65536 colors
open_display()
have_visual_for_depth(16)
 minimum required X depth is 15, maximum supported X depth is 16
 trying to find visual for depth 1
 trying to find visual for depth 4
 trying to find visual for depth 8
 trying to find visual for depth 15
 trying to find visual for depth 16
 found visual ID 0x2b, depth 16, class DirectColor
 shm image created
 shm image attached
the_buffer =3D 0x10000000, the_buffer_copy =3D 0x41598008, the_host_buffer =
=3D=20
0x41501000
Redraw thread installed (1105398704)


and this is what the detection process looks like...

have_visual_for_depth(1)
 found visual ID 0x23, depth 16
have_visual_for_depth(2)
 minimum required X depth is 8, maximum supported X depth is 32
 trying to find visual for depth 1
 trying to find visual for depth 4
 trying to find visual for depth 8
 trying to find visual for depth 15
 trying to find visual for depth 16
 found visual ID 0x2b, depth 16, class DirectColor
=20

it does this several times with a different argument put in=20
have_visual_for_depth()

However when I try to run in fullscreen mode I get this error:

XF86DGAGetVideo: failed to map video memory (Permission denied)

And lastly the VidMode and --disable-vosf extensions compiled, they just di=
d=20
not solve the assert() problem.

Cheers! :)

=2DMax

On Friday 04 June 2004 03:12 pm, Gwenole Beauchesne wrote:
> Hi,
>
> > Something has changed regarding the video on CVS from SheepShaver
> > 2.2.10,
>
> Yes, it supports run-time depth switching. ;-)
>
> > SheepShaver: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode
> > !=3D -1'
> > failed.
>
> Indeed, Tomasz already reported that but I have not looked at it yet.
> Can you also please #define DEBUG to 1 at top, and try again? You will
> get "Available video modes:". windowmodes and screenmodes prefs items
> from ~/.sheepshaver_prefs are helpful in addition + depth you currently
> have.
>
> I think you disabled all windowed modes but kept only full screen modes
> but your current resolution doesn't match (is greater than) any older
> Apple's one, right? I probably messed up the Apple mode lookup logic
> again. Anyhow, I still want windowed 640x480 mode to be the default if
> any other one failed.
>
> > I tried comiling it with and without VidMode support as well as with
> > the
> > --disable-vosf extension, neither of them seem to work.
>
> Do you mean it doesn't help, i.e. same assert() triggered? Or, you
> can't compile it when configured that way?
>
> Bye,
> Gwenol=E9.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>
> >From Windows to Linux, servers to mobile, InstallShield X is the one
>
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Assert(cur_mose != -1) error on start

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

Hi,

> Something has changed regarding the video on CVS from SheepShaver=20
> 2.2.10,

Yes, it supports run-time depth switching. ;-)

> SheepShaver: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode=20=

> !=3D -1'
> failed.

Indeed, Tomasz already reported that but I have not looked at it yet.=20
Can you also please #define DEBUG to 1 at top, and try again? You will=20=

get "Available video modes:". windowmodes and screenmodes prefs items=20
from ~/.sheepshaver_prefs are helpful in addition + depth you currently=20=

have.

I think you disabled all windowed modes but kept only full screen modes=20=

but your current resolution doesn't match (is greater than) any older=20
Apple's one, right? I probably messed up the Apple mode lookup logic=20
again. Anyhow, I still want windowed 640x480 mode to be the default if=20=

any other one failed.

> I tried comiling it with and without VidMode support as well as with=20=

> the
> --disable-vosf extension, neither of them seem to work.

Do you mean it doesn't help, i.e. same assert() triggered? Or, you=20
can't compile it when configured that way?

Bye,
Gwenol=E9.=

[B2-devel] Use of hardware G4 processor on PCI-X bus.

[Terra B. <ter...@ho...>]

Hi,

This might be a little off topic, but i was wondering if it would be 
feasable to mount a G4 and a high speed xilinx FPGA (for address <-> pin / 
speed buffering) on a 16 wide PCI-X bus and have Sheepshaver write all G4 
processor intensive instruction code directly to that port and emulate video 
/ sound / peripheral devices in x86 memoryspace?

Most of the problems i see in sheepshaver are due to opcode translations and 
the way Macos likes to use the processor intimately (which if emulated would 
seriously effect speed). Its like apple and motorola were in a deep 
conspiracy to make sure they have the bleeding edge in the market.

Its just a thought, but i would like the communities feedback on that 
concept.

Thanks.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

[B2-devel] Assert(cur_mose != -1) error on start

[Dr. M. <cs...@uc...>]

Something has changed regarding the video on CVS from SheepShaver 2.2.10, I 
compile it and try to run the program and get to the setup UI, but when I  
try to start the emulator itself I get this message:

SheepShaver: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode != -1' 
failed.

I looked at the sourcecode aroun d this area, but don't have near enough 
knowledge of what's going on to know what's going wrong for me.  I tried 
comiling it with and without VidMode support as well as with the 
--disable-vosf extension, neither of them seem to work.

Any insight as to the problem? I'm running Mandrake Linux 10.0 on the KDE 
desktop in an x86 box.

Thank you very much for your time and sorry if this is an improper place to 
post this :)

-Max

[B2-devel] SheepShaver and PRECISE_TIMING

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

Hi,

What PRECISE_TIMING stuff is supposed to do on BeOS/PPC? I mean, I do=20
understand it uses the native TimeBase registers for timers but how=20
does this translate into real world? i.e. what are the visible=20
effects/tests I could do in case I wanted the same for Unixish systems?=20=

Is that only to get nanosecond-resolution timers?

BTW, I think that's the only feature left on BeOS without counterpart=20
in Unix land. ;-) Besides, SheepShaver now even appears to have more=20
features than Basilisk II, and other Mac emulators by the way.

Thanks,
Gwenol=E9.=

Re: [B2-devel] SheepShaver and SDL

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

[About slow windows repainting and general graphics performance.]

> I hoped NQD acceleration would help, but it didn't.

What's more, the Unix graphics subsystem for SheepShaver is almost the 
same as in Basilisk II. Noticeable difference is design 
(object-oriented in B2), and an extra ppc routine that is called 60 
times per second. I hoped that recent JIT rentrancy + little 
optimizations  would improve it but it didn't either.

That's why I definitely think it's not related to stuff in 
Unix/video_x.cpp. But I can be wrong. ;-)

Really, latest features and optimizations (NQD, reentrant JIT, use of 
DR emulator, etc.) were meant to attempt to speed up the problem you 
mention. Finder is also slow on my PBG4 in emulated mode, though 
graphics performance as reported by benchmarks looks good.

Re: [B2-devel] SheepShaver and SDL

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

Hi,

> Even though SheepShaver results were noticeably higher
> in most tests, including QuickDraw ones, SheepShaver's graphics feels=20=

> a lot
> slower than Basilisk's - repainting of Finder windows is visible, =
menus
> don't appear instantly and stuff like this.

I did notice that too but I don't think it's caused by the graphics=20
subsystem. e.g. I ran extra MacBench 5.0 graphics test CopyBits=20
(srcCopy) and performance was really good. Last time I tried to=20
investigate that, reasons why Finder windows repainting it slow might=20
be:
- a non neglectable portion is 68k code
- the code uses a lot of branches that are not translated effeciently=20
yet
- cache is invalidated a lot of times. I noticed that when pulling down=20=

a single menu, at least 3 cache invalidation occur for specific regions.

I hoped NQD acceleration would help, but it didn't.

> The difference increased when I
> installed Kaleidoscope theming applet and Aqua-like themes on both=20
> systems.

Is Kaleidoscope native PPC nowadays? If not, we really must find a=20
decent way to translate 68k code to native code too. Problem is Apple's=20=

special opcodes, and checkpoints for interrupt handling. That can be=20
workarounded but not effeciently. Well, I will try to look at it again.

Bye,
Gwenol=E9.=

RE: [B2-devel] SheepShaver and SDL

[Tomasz J. <to...@je...>]

> -----Original Message-----
> From: bas...@li... 
> [mailto:bas...@li...] On Behalf 
> Of Gwenole Beauchesne
> Sent: Friday, June 04, 2004 4:15 PM
> To: bas...@li...
> Subject: Re: [B2-devel] SheepShaver and SDL
> 
> Hi,
> 
> > Just a wild thought... Wouldn't be useful if SheepShaver were using 
> > SDL as graphics subsystem? Recently PearPC guys employed 
> that library 
> > in their project and users were pretty happy with it 
> (performance wise).
> 
> Performance wise, our graphics subsystem is performing quite 
> well already [*]. Though plain x86 could benefit from 
> SDL/Hermes/x86 blitters. In my opinion, at 30 Hz, it doesn't 
> seem that slow.
> 
> [*] If it seems slow to you, can you make sure you are 
> running local so that Xshm can be used too? Besides, could 
> you try a build configured with --disable-vosf. If this 
> causes faster graphics on Linux/x86 (at the same frameskip 
> level), then there is a problem.
> 

I was bored yesterday and made a little comparison between BasiliskII/Win
(no JIT version, MacOS 8.1, 68x) and SheepShaver (MacOS 8.6). The benchmark
was Speedometer 4.0. Even though SheepShaver results were noticeably higher
in most tests, including QuickDraw ones, SheepShaver's graphics feels a lot
slower than Basilisk's - repainting of Finder windows is visible, menus
don't appear instantly and stuff like this. The difference increased when I
installed Kaleidoscope theming applet and Aqua-like themes on both systems.
That's why I've drawn a conclusion that there might be something wrong with
SheepShaver graphics performance.

I'm aware that my benchmark is not very good (different host OS's, different
architectures emulated, different OS's emulated).

Jerzu

Re: [B2-devel] SheepShaver and SDL

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

Hi,

> Just a wild thought... Wouldn't be useful if SheepShaver were using SDL as
> graphics subsystem? Recently PearPC guys employed that library in their
> project and users were pretty happy with it (performance wise).

Performance wise, our graphics subsystem is performing quite well already
[*]. Though plain x86 could benefit from SDL/Hermes/x86 blitters. In my
opinion, at 30 Hz, it doesn't seem that slow.

[*] If it seems slow to you, can you make sure you are running local so
that Xshm can be used too? Besides, could you try a build configured with
--disable-vosf. If this causes faster graphics on Linux/x86 (at the same
frameskip level), then there is a problem.

> It would also make SheepShaver a little bit more portable (eg. to
> Windows - if anyone wanted to perform such a noble task).

Indeed, SDL for portability can be interesting. And as for a Windows port, 
I still don't have any suitable system to host that either.

> How difficult would be implementing of SDL then? I'm wondering if I would be
> able to help somehow (5 year experience in Windows/C++ programming, modest
> experience in Linux programming, no clue about Mac programming). If so, what
> source files should I look at first?
> 
> Jerzu
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 

Re: [B2-devel] SheepShaver and SDL

[Christian B. <Chr...@un...>]

Hi!

On Fri, Jun 04, 2004 at 01:12:01PM +0200, Tomasz Jerzykowski wrote:
> If so, what source files should I look at first?

Graphics and user input are in src/Unix/video_x.cpp (though you might get a
heart attack from looking at it...), audio in src/Unix/audio_oss_esd.cpp,
and CD-ROM stuff in src/Unix/sys_unix.cpp.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] SheepShaver and SDL

[Tomasz J. <to...@je...>]

Hello.

Just a wild thought... Wouldn't be useful if SheepShaver were using SDL as
graphics subsystem? Recently PearPC guys employed that library in their
project and users were pretty happy with it (performance wise). It would
also make SheepShaver a little bit more portable (eg. to Windows - if anyone
wanted to perform such a noble task).

How difficult would be implementing of SDL then? I'm wondering if I would be
able to help somehow (5 year experience in Windows/C++ programming, modest
experience in Linux programming, no clue about Mac programming). If so, what
source files should I look at first?

Jerzu

Re: [B2-devel] Native QuickDraw acceleration

[Christian B. <Chr...@un...>]

Hi!

On Thu, Jun 03, 2004 at 06:34:53PM +0200, Gwenole Beauchesne wrote:
> BTW, how usable was powerrom_cpu on BeOS/ppc?

It was like a dream come true (about four times faster than the UAE 68k
emulator, if I remember correctly). :-)

Off-hand, I don't remember any particular problems with it.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Native QuickDraw acceleration

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

On Thu, 3 Jun 2004, Christian Bauer wrote:

> I have attached the guesswork. Maybe you want to give it a try? :)
> 
> AccelQuickDraw is called once when the disk driver does its first accRun.
> Everything else should be more or less self-explanatory...

Hehe, I indeed can't see anywhere specified such LowMem globals. ;-)

BTW, how usable was powerrom_cpu on BeOS/ppc?

Re: [B2-devel] Native QuickDraw acceleration

[Christian B. <Chr...@un...>]

Hi!

On Thu, Jun 03, 2004 at 12:45:24AM +0200, Gwenole Beauchesne wrote:
> Would it be possible to get that guesswork into B2 too?

I have attached the guesswork. Maybe you want to give it a try? :)

AccelQuickDraw is called once when the disk driver does its first accRun.
Everything else should be more or less self-explanatory...

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/