basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] RE: Initial Basilisk II for Windows

[AZEnigma <aze...@ya...>]

Using windib did not make any noticible difference on my PC, but changing the frame skip to 0 did help a lot, although the mouse is still a little jumpy.  Is the cdrom or networking working yet?  I tried a few things but could not get a cdrom loaded.
 
It is so nice to have on the fly resolution and color depth changes!! no more exiting the emu everytime I want to play a older game.
 
Thanks!!!

Gwenole Beauchesne <gb...@di...> wrote:
Hi,

> In windowed mode, the video is very choppy and compared to the old 
> Windows version.

If you are using the SDL version, try something like 
SDL_VIDEODRIVER=windib ./BasiliskII.exe to compare against the default 
directx output (if you have the SDL.dll). You can also arrange your 
frameskip. I have set it to 0 and it looks better with the raw gdi 
driver through VMware.



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
basilisk-devel mailing list
bas...@li...
https://lists.sourceforge.net/lists/listinfo/basilisk-devel

		
---------------------------------
Do you Yahoo!?
 Meet the all-new My Yahoo! – Try it today! 

Re: [B2-devel] RE: Initial Basilisk II for Windows

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

Hi,

> In windowed mode, the video is very choppy and compared to the old 
> Windows version.

If you are using the SDL version, try something like 
SDL_VIDEODRIVER=windib ./BasiliskII.exe to compare against the default 
directx output (if you have the SDL.dll). You can also arrange your 
frameskip. I have set it to 0 and it looks better with the raw gdi 
driver through VMware.

[B2-devel] RE: Initial Basilisk II for Windows

[Duane S. <aze...@ya...>]

I have the new version up and running on a WinXP laptop.  The audio works although there is a bit of a lag.  Is there anyway to switch to full screen?  In windowed mode, the video is very choppy and compared to the old Windows version.
 
Thanks

			
---------------------------------
Do you Yahoo!?
 The all-new My Yahoo! – Get yours free!    

Re: [B2-devel] Hardware cursor acceleration in B2

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

Hi,

> I never bothered trying to figure this out. ShapeShifter uses the =
Amiga
> mouse pointer in windowed mode, but its shape doesn't follow the Mac=20=

> cursor.
> It just replaces SetCursor with a "move.w #-16,$8d0" to make the Mac=20=

> cursor
> disappear.

OK, it's a complete trap replacement then, and not a usual chained=20
patch. Though we can get the cursor image from there, what about color=20=

cursors? I believe SheepShaver has the same restriction anyway. A=20
solution for Basilisk II would be to patch _SetCCursor to disable the=20
native cursor. I suppose CrsrState will be reset by _SetCCursor itself.

Bye,
Gwenol=E9.=

Re: [B2-devel] Initial Basilisk II for Windows

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

mardi 16 novembre 2004, =E0 09:31  am, howard spoelstra a =E9crit :

> Could you give us a small walk-through the compilation process? and=20
> define which packages should be installed on cygwin?

Simply basic install + a compiler + a manual build of SDL (see=20
www.libsdl.org for instructions).
then, ./configure --enable-jit-compiler --enable-sdl-video=20
--enable-sdl-audio.

I don't have a sound card, someone else will have to test audio himself.=

Re: [B2-devel] Hardware cursor acceleration in B2

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

Hi!

On Tue, Nov 16, 2004 at 12:51:54AM +0100, Gwenole Beauchesne wrote:
> Does someone know how we could handle hardware accelerated cursors in 
> Basilisk II?

I never bothered trying to figure this out. ShapeShifter uses the Amiga
mouse pointer in windowed mode, but its shape doesn't follow the Mac cursor.
It just replaces SetCursor with a "move.w #-16,$8d0" to make the Mac cursor
disappear.

Bye,
Christian

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

RE: [B2-devel] Initial Basilisk II for Windows

[howard s. <how...@ho...>]

Hello Gwenole,

Could you give us a small walk-through the compilation process? and define 
which packages should be installed on cygwin?

Or maybe even place the .exe on your website?

Best wishes

Howard

>From: Gwenole Beauchesne <gb...@di...>
>Reply-To: bas...@li...
>To: bas...@li...
>Subject: [B2-devel] Initial Basilisk II for Windows
>Date: Tue, 16 Nov 2004 00:56:32 +0100
>
>Hi,
>
>It is now possible to fully build a version of Basilisk II for Windows 
>through Cygwin. It's not complete yet (misses bits from Lauri's) but it can 
>work through SDL graphics. And, most importantly, JIT is the newest one and 
>run-time resolution & depth switching work.
>
>It's important to get a decent Windows version first to be revived prior to 
>switching on to SheepShaver as the latter shares a lot of code from B2.
>
>BTW, I am still not a Windows prorammer so don't expect much either. ;-)
>
>Bye,
>Gwenolé.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>basilisk-devel mailing list
>bas...@li...
>https://lists.sourceforge.net/lists/listinfo/basilisk-devel

_________________________________________________________________
MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl

[B2-devel] Initial Basilisk II for Windows

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

Hi,

It is now possible to fully build a version of Basilisk II for Windows=20=

through Cygwin. It's not complete yet (misses bits from Lauri's) but it=20=

can work through SDL graphics. And, most importantly, JIT is the newest=20=

one and run-time resolution & depth switching work.

It's important to get a decent Windows version first to be revived=20
prior to switching on to SheepShaver as the latter shares a lot of code=20=

from B2.

BTW, I am still not a Windows prorammer so don't expect much either. ;-)

Bye,
Gwenol=E9.=

[B2-devel] Hardware cursor acceleration in B2

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

Hi,

Does someone know how we could handle hardware accelerated cursors in=20
Basilisk II? SheepShaver uses a feature from MacOS >=3D 7.5.3 with PCI=20=

video drivers interface, but I have not found anything similar for=20
MacOS 68k. At some point, I wondered about patching the _SetCursor=20
trap, but would could color cursors and direct TheCrsr low-mem globals=20=

changes be handled?

Thanks,
Gwenol=E9.=

[B2-devel] Clipboard handling

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

Hi,

I have backported code to handle copy-paste of 'TEXT' data from=20
SheepShaver. So, if you want to implement your arch-dependent code for=20=

GetScrap() too, you are welcome. In the meantime, I have implemented=20
that as a no-op on BeOS and AmigaOS targets.

BTW, since I don't have a Mac Classic ROM, could someone please lookup=20=

where is located the _GetScrap A-Trap handler? Or would a=20
find_rom_trap(0xa9fd) do the trick in Classic mode too?

Thanks,
Gwenol=E9.=

[B2-devel] test

[Morgan R. <ms...@pl...>]

test - & appologies for this and the previous help...
M
-- 
Morgan Read
<mailto:mstuffATplDOTnet>

[B2-devel] -help

[Morgan R. <ms...@pl...>]

-help

[B2-devel] Windows vs. Low Memory globals

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

Hi,

In case there are Windows developers around that could answer:
- Is it possible to map the first segment? i.e. at 0x00000000 for low=20
memory globals?
- What are the mappable regions? It seems this can start at 0x30000000=20=

only.

Anyhow, in the mean time, I did some vast changes to implement "Direct=20=

Addressing" mode the same way it works in Basilisk II. It's not=20
complete yet but enough to do some benchmarks within MacOS 9.=20
Performance decrease vs. real addressing mode is typically around 5%.

Bye,
Gwenol=E9.=

Re: [B2-devel] SheepShaver on x86_64 continued

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

mercredi 10 novembre 2004, =E0 07:51  pm, Tomek Jerzykowski a =E9crit :

> In SheepShaver/src/cpu/kpx_cpu/src/cpu/ppc/ppc-dyngen.cpp I commented
> out the following lines (starting frrom line 67):

Yes, but you will get lower AltiVec performance since you wouldn't use=20=

MMX/SSE in that case.

I have fixed it in CVS. The cpuid test was from GCC and got fixed later=20=

too.

Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

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

Hi,

> A cleaner patch will have to be developed, but the following
> modification works for me:

I have just committed the right fix. Note a long is enough and GAS 
knows about push without suffix. i.e. no need to #ifdef part of the 
code.

Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

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

mercredi 10 novembre 2004, =E0 09:37  am, Bob Deblier a =E9crit :

> The lines in question are:
> #APP
>         push %eax; popf; bsf %esi,%esi; pushf; pop %eax
> #NO_APP

Oh, I see. I hadn't merged this bit from the very old prototype system.=20=

;-)

> Splitting the assembler over multiple lines shows that it's the push %
> eax and pop %eax; tried fixing it with pushl and popl but that didn't=20=

> do
> the trick. Can 64-bit mode only push 64-bit quantities onto the stack?

Yes.

Besides, 64-bit mode doesn't handle sahf/lahf, thus yielding a typical=20=

15% performance decrease when you have to use the pushf/pop variants to=20=

get native flags (noticed on a Pentium 4). Fortunately, upcoming AMD64=20=

processors will now bring sahf/lahf back to 64-bit mode too. But it=20
seems Intel doesn't plan to implement them. i.e. there will be another=20=

bit in some cpuid level to report this support.=

[B2-devel] SheepShaver on x86_64 continued

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

I know what is causing the following errors:

I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include -
fpermissive -c ../kpx_cpu/src/cpu/ppc/ppc-dyngen.cpp -o obj/ppc-dyngen.=
o
/tmp/ccP0F64j.s: Assembler messages:
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `push'
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `push'
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `pop'
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `pop'
make: *** [obj/ppc-dyngen.o] B=C5=82=C4=85d 1


In SheepShaver/src/cpu/kpx_cpu/src/cpu/ppc/ppc-dyngen.cpp I commented
out the following lines (starting frrom line 67):

/*=20
	__asm__ ("push %%ecx ; push %%ebx ; cpuid ; pop %%ebx ; pop %%ecx"
			 : "=3Da" (fl1) : "0" (0) : "edx", "cc");
	if (fl1 =3D=3D 0)
*/

Now it compiles fine.

Jerzu

Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

[Bob D. <bob...@te...>]

A cleaner patch will have to be developed, but the following
modification works for me:

diff -u -r1.24 codegen_x86.cpp
--- codegen_x86.cpp     8 Nov 2004 21:10:46 -0000       1.24
+++ codegen_x86.cpp     10 Nov 2004 09:30:16 -0000
@@ -3834,9 +3834,9 @@
        for (int g_OF = 0; g_OF <= 1; g_OF++) {
        for (int g_SF = 0; g_SF <= 1; g_SF++) {
                for (int value = -1; value <= 1; value++) {
-                       int flags = (g_SF << 7) | (g_OF << 11) | (g_ZF
<< 6) | g_CF;
+                       long long int flags = (g_SF << 7) | (g_OF << 11)
| (g_ZF << 6) | g_CF;
                        int tmp = value;
-                       __asm__ __volatile__ ("push %0; popf; bsf %1,%1;
pushf; pop %0"
+                       __asm__ __volatile__ ("pushq %0; popfq; bsf %1,%
1; pushfq; popq %0"
                                                                  :
"+r" (flags), "+r" (tmp) : : "cc");
                        int OF = (flags >> 11) & 1;
                        int SF = (flags >>  7) & 1;

There'll just have to be an #if #else #endif wrapped around this.

Bob

RE: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

[Bob D. <bob...@te...>]

On Wed, 2004-11-10 at 10:04 +0100, Tomek Jerzykowski wrote:
> > The lines in question are:
> > #APP
> >         push %eax; popf; bsf %esi,%esi; pushf; pop %eax #NO_APP
> > 
> > Splitting the assembler over multiple lines shows that it's 
> > the push % eax and pop %eax; tried fixing it with pushl and 
> > popl but that didn't do the trick. Can 64-bit mode only push 
> > 64-bit quantities onto the stack?
> > 
> > Sincerely,
> > 
> > Bob
> 
> Take a look at this:
> http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2004-10/msg00349.ht
> ml
> 
> They mention something about limitations with regard to register usage on
> x86_64. 
> 
> Jerzu

That page only seems to mention that there are limitations with the 8
new registers (r8 through r15). I'll have to dive into the
documentation.

Bob

RE: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

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

 

> -----Original Message-----
> From: bas...@li... 
> [mailto:bas...@li...] On Behalf 
> Of Bob Deblier
> Sent: Wednesday, November 10, 2004 9:37 AM
> To: bas...@li...
> Subject: Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09
> 
> On Wed, 2004-11-10 at 08:38 +0100, Gwenole Beauchesne wrote:
> > Could you copy this line (without -o obj/compemu_support.o and 
> > s/-c/-S) so that you cuold actually read the 
> compemu_support.s generated file?
> > 
> > Then, if this is inline assembly code, it may be surrounded by 
> > something like "#NO_APP". Otherwise, it's compiler generated code.
> 
> The lines in question are:
> #APP
>         push %eax; popf; bsf %esi,%esi; pushf; pop %eax #NO_APP
> 
> Splitting the assembler over multiple lines shows that it's 
> the push % eax and pop %eax; tried fixing it with pushl and 
> popl but that didn't do the trick. Can 64-bit mode only push 
> 64-bit quantities onto the stack?
> 
> Sincerely,
> 
> Bob

Take a look at this:
http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2004-10/msg00349.ht
ml

They mention something about limitations with regard to register usage on
x86_64. 

Jerzu

RE: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

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

> -----Original Message-----
> From: bas...@li...=20
> [mailto:bas...@li...] On Behalf=20
> Of Gwenole Beauchesne
> Sent: Wednesday, November 10, 2004 8:38 AM
> To: bas...@li...
> Subject: Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09
>=20
> mercredi 10 novembre 2004, =E0 07:48  am, Bob Deblier a =E9crit :
>=20
> >  Seems this header on its own doesn't know type 'struct sockaddr',=20
> > hence it should include <sys/socket.h> in its test
>=20
> Thanks, fixed in CVS.
>=20
> > Trying to compile after ./configure --with-jit-compiler results in a
> > problem:
>=20
> Could you copy this line (without -o obj/compemu_support.o=20
> and s/-c/-S) so that you cuold actually read the=20
> compemu_support.s generated file?
>=20
> Then, if this is inline assembly code, it may be surrounded=20
> by something like "#NO_APP". Otherwise, it's compiler generated code.
>=20
> > g++ -I../include -I. -I../uae_cpu -DHAVE_CONFIG_H  -DOS_linux -
> > DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -=20
> > DOPTIMIZED_FLAGS -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -D_REENTRANT -=20
> > DDATADIR=3D\"/usr/local/share/BasiliskII\" -O2 -I/usr/X11R6/include =
-
> > I/usr/include/gtk-1.2 -I/usr/include/glib-1.2=20
> > -I/usr/lib64/glib/include -I/usr/X11R6/include -fno-merge-constants=20
> > -fno-gcse-sm - c ../uae_cpu/compiler/compemu_support.cpp -o=20
> > obj/compemu_support.o
>=20
> > /tmp/ccmQvYdd.s: Assembler messages:
> > /tmp/ccmQvYdd.s:40547: Error: suffix or operands invalid for `push'
> > /tmp/ccmQvYdd.s:40547: Error: suffix or operands invalid for `pop'
> > make: *** [obj/compemu_support.o] Error 1
>=20
> I don't know where it is coming from either. I have no=20
> explicit reference to pushl or pushq as inline assembly.
>=20

When compiling Sheepshaver on x86_64 I'm experiencing similar errors
on FC3 test3 as well. There must be some wierdness here.
A bit of googling reveals that Sheepshaver is not the only one program
that suffers from this. It seems to happen only on x86_64 with the
newest GCC versions. I will investigate more later.

Jerzu

http://www.google.pl/search?q=3D%22Error:+suffix+or+operands+invalid+for+=
%60pu
sh%27%22&hl=3Dpl&lr=3D&start=3D0&sa=3DN

Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

[Bob D. <bob...@te...>]

On Wed, 2004-11-10 at 08:38 +0100, Gwenole Beauchesne wrote:
> Could you copy this line (without -o obj/compemu_support.o and s/-c/-S) 
> so that you cuold actually read the compemu_support.s generated file?
> 
> Then, if this is inline assembly code, it may be surrounded by 
> something like "#NO_APP". Otherwise, it's compiler generated code.

The lines in question are:
#APP
        push %eax; popf; bsf %esi,%esi; pushf; pop %eax
#NO_APP

Splitting the assembler over multiple lines shows that it's the push %
eax and pop %eax; tried fixing it with pushl and popl but that didn't do
the trick. Can 64-bit mode only push 64-bit quantities onto the stack?

Sincerely,

Bob

Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

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

mercredi 10 novembre 2004, =E0 07:48  am, Bob Deblier a =E9crit :

>  Seems this header on its own doesn't know type 'struct sockaddr',=20
> hence
> it should include <sys/socket.h> in its test

Thanks, fixed in CVS.

> Trying to compile after ./configure --with-jit-compiler results in a
> problem:

Could you copy this line (without -o obj/compemu_support.o and s/-c/-S)=20=

so that you cuold actually read the compemu_support.s generated file?

Then, if this is inline assembly code, it may be surrounded by=20
something like "#NO_APP". Otherwise, it's compiler generated code.

> g++ -I../include -I. -I../uae_cpu -DHAVE_CONFIG_H  -DOS_linux -
> DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -
> DOPTIMIZED_FLAGS -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -D_REENTRANT -
> DDATADIR=3D\"/usr/local/share/BasiliskII\" -O2 -I/usr/X11R6/include -
> I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 =
-I/usr/lib64/glib/include
> -I/usr/X11R6/include -fno-merge-constants -fno-gcse-sm -
> c ../uae_cpu/compiler/compemu_support.cpp -o obj/compemu_support.o

> /tmp/ccmQvYdd.s: Assembler messages:
> /tmp/ccmQvYdd.s:40547: Error: suffix or operands invalid for `push'
> /tmp/ccmQvYdd.s:40547: Error: suffix or operands invalid for `pop'
> make: *** [obj/compemu_support.o] Error 1

I don't know where it is coming from either. I have no explicit=20
reference to pushl or pushq as inline assembly.

Re: [B2-devel] SheepShaver/JIT for x86_64

[Bob D. <bob...@te...>]

On Wed, 2004-11-10 at 07:58 +0100, Gwenole Beauchesne wrote:
> You can't boot MacOS < 8.6 with a NewWorld ROM yet. It was probably=20
> possible in the past but I never could get it working yet. Here is a=20
> map table of currently working combinations:
>=20
> MacOS < 8.6	PowerMac PCI 4 MB ROMs
> MacOS >=3D 8.6	+ NewWorld ROMs <=3D v1.6
>=20
> Bye,
> Gwenol=C3=A9.

I've gotten hold of a 9.0.4 CD and it runs like a charm with NewWorld
ROM (v. 1.0p).

Thanks,

Bob

Re: [B2-devel] SheepShaver/JIT for x86_64

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

Hi,

> SheepShaver - sorry I got confused; it's one mailing list for both
> emulators.

I have now built SheepShaver on x86_64 with gcc 3.4.1. Fixes committed=20=

to CVS, please update your tree. Note, don't care about the following=20
warnings:
../kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:43: warning: register used=20=

for two global register variables

They will be obsoleted with the new JIT anyway.

> BasiliskII compiles without any problems, and runs fine; faster than=20=

> any
> 68K Mac I've ever owned...

Even on a K6-2/300, B2/JIT was already faster than my Quadra 630, which=20=

was the goal. Now that I have an x86-64 system, the new reference Mac=20
is my Powerbook G4/400 vs. SheepShaver. This goal is achieved too. ;-)

> Test results without JIT: crash (SIGSEGV)
>
> Installing drivers...
> SIGSEGV
>   pc 0x46929c
>   ea 0x40461008
[...]
>  pc 40df1200 fpscr 00000000

You can't boot MacOS < 8.6 with a NewWorld ROM yet. It was probably=20
possible in the past but I never could get it working yet. Here is a=20
map table of currently working combinations:

MacOS < 8.6	PowerMac PCI 4 MB ROMs
MacOS >=3D 8.6	+ NewWorld ROMs <=3D v1.6

Bye,
Gwenol=E9.=