basilisk-devel — Basilisk II development-related discussion

[B2-devel] BasiliskII doesn't like my ROMs

[Carsten N. <de...@sn...>]

Hi all,

I am new to Basilisk II, although I did some (unsuccessful) attempts on i=
t for over one year.
There are several problems with CVS and CVS snapshots.

I use linux kernel 2.4.17, glibc 2.1, gtk 1.2.6, latest BasiliskII snapsh=
ot/checkout.

The minor problem is that autogen.sh fails on the CVS checkouts, this is =
probably partly
an autoconf problem but if one could give me a hint...! ;-)

The macros AC_DEFINE, AC_MSG_WARN, AM_PATH_GTK, AM_PATH_ESD are `possibly=
 undefined'.
After commenting out the code for handling the GTK and ESD stuff in `conf=
igure.ac' the `configure'
script is built but gets stuck (doesn't terminate) on checking if GCC is =
>=3D 2.7 (I use 2.95.3).


The major problem is that I get `Unsupported ROM type' errors on the CVS =
snapshot.
I get these for IIfx and IIci ROM images.
Both are 32 bit clean and I couldn't read anything that they are unsuppor=
ted.
I've enabled debugging in rom_patches.cpp and found that the InitMMU patc=
h failed.
After changing the (ROMSize > 0x80000)-branch of the if statement to the =
same as the
(ROMSize <=3D 0x80000)-branch I get a lot further, but then I fail:

see attachment for the IIfx ROM including ROM info.

It looks like Basilisk II isn't tested with IIfx and IIci ROMs.
Is there anything I can do making it work for these?


Kind regards, thank you,

=09Carsten

--=20
Certify your minority, support spyware!
Soon to come as TCPA and Palladium from Microsoft & Co.

Re: [B2-devel] A few fixes

[Gwenole B. <gbe...@ma...>]

On Thu, 21 Nov 2002, Brian Johnson wrote:

> If these changes look OK, I'd appreciate it someone would check them in.

Done, with slight changes in configure.ac to get rid of -g.

Bye,
Gwenole.

[B2-devel] Re: A few fixes

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

Silly me, I forgot to attach the diff....

						Brian

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

   "Bicycles... make you healthier and don't threaten the health of
    others, unlike all faster forms of transportation."
                                           -- Jim Goodman

[B2-devel] A few fixes

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

Folks,

Here are a few small fixes to BII:
 - Use "-O3 -OPT:Olimit=0 -IPA" instead of "-Ofast" for MIPSPro
   builds.  "-Ofast" breaks floating point emulation, and the new
   optimizer settings produce code that's just as fast.
 - Clean up some build warnings in main_unix.c
 - Try to lock the pthreads mutex in the B2_mutex destructor before
   unlocking it.  It's illegal to unlock a mutex you don't have
   locked, and in fact it causes core dumps with Irix pthreads.

If these changes look OK, I'd appreciate it someone would check them
in.

Thanks,

						Brian J. Johnson

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

  "You have greater impact on others by the way you listen than by the
   way you talk."
                                           -- Unknown

[B2-devel] Re: DIRECT_ADDRESSING does not work on Mac OS 10.2

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

Gwenole asked:
> Are you sure HAVE_MACH_VM is defined to 1 on MacOS X 10.2? Their mmap() 
> implementation may still not work properly.


	configure says:

checking for mmap... yes
checking for mprotect... yes
checking for munmap... yes
checking for vm_allocate... yes
checking for vm_deallocate... yes
checking for vm_protect... yes
checking for mach_task_self... yes
checking for task_self... no
checking for cam_open_btl in -lcam... no
configure: WARNING: Cannot find libcam for SCSI management, disabling SCSI support.
checking whether vm_protect works... no
checking whether mmap supports MAP_ANON... no
checking whether mmap supports MAP_ANONYMOUS... no
checking whether mprotect works... no
checking whether we can map Low Memory area 0x0000-0x2000... no
checking whether signal handlers need to be reinstalled... no
checking whether sigaction handlers need to be reinstalled... no
checking whether your system supports extended signal handlers... no
checking whether we can skip instruction in SIGSEGV handler... no
checking for the addressing mode to use... memory banks
checking for GAS .p2align feature... no
checking for GCC 2.7 or higher... yes
checking for GCC 3.0 or higher... yes

	and config.h contains:

/* Define if your system has a working vm_allocate()-based memory allocator.
    */
#define HAVE_MACH_VM 1

/* Define if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1

/* Define if you have the `mmap' function. */
#define HAVE_MMAP 1

/* Define if <sys/mman.h> defines MAP_ANON and mmap()'ing with MAP_ANON works.
    */
/* #undef HAVE_MMAP_ANON */

/* Define if <sys/mman.h> defines MAP_ANONYMOUS and mmap()'ing with
    MAP_ANONYMOUS works. */
/* #undef HAVE_MMAP_ANONYMOUS */

/* Define if your system has a working mmap()-based memory allocator. */
#define HAVE_MMAP_VM 1

/* Define if you have the `mprotect' function. */
#define HAVE_MPROTECT 1

/* Define if you have the `munmap' function. */
#define HAVE_MUNMAP 1



> Does the screen remain black?

	Yes. I can set a debug mode that draws some random snow
in the screen bitmap each time through the drawing loop, so I
am pretty sure it is nothing wrong with the OS X window stuff.
It just seems like the video device is never opened, although it
attempts to open the CDRom and other such things.

	Very strange.

-- 
| Nigel Pearson, ni...@in...    |    "Things  you  own        |
| Telstra BI&D,  Sydney, Australia         |     end up owning you"      |
|   Office: 8255 4222    Fax:  8255 3153   | "not a beautiful snowflake" |
|   Mobile: 0408 664435  Home: 9792 6998   |     Tyler - Fight Club      |

Re: [B2-devel] DIRECT_ADDRESSING does not work on Mac OS 10.2

[Gwenole B. <gbe...@ma...>]

Hi,

> 	Any ideas?

Are you sure HAVE_MACH_VM is defined to 1 on MacOS X 10.2? Their mmap() 
implementation may still not work properly. Does the screen remain 
black? I once got that when compiling B2 on OS X 10.1 with an X server. 
I didn't know the cure. :-(

Bye,
Gwenole.

[B2-devel] DIRECT_ADDRESSING does not work on Mac OS 10.2

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

	This is a weird problem. Building BasiliskII on 10.2 with
DIRECT_ADDRESSING=1 gives an application that does not write
to its screen. I have tried building with GCC2.95.2 (instead of 3.1)
to no avail.

	GDB indicates that only a few methods in video.cpp are called,
as a result of InitAll() (i.e. VideoInit() and PatchROM() ).


	I suspected that uae_cpu is not doing anything, but adding DEBUG=1
to a few source files reveals a healthy range of EmulOps:

Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
WARNING: Cannot open /dev/fd0 (No such file or directory)
WARNING: Cannot open /dev/fd1 (No such file or directory)
2002-11-01 15:08:45.503 BasiliskII[9140] Got default audio output device
EmulOp 7103
*** RESET ***
EmulOp 7104
Read XPRAM 00->00
EmulOp 7104
Read XPRAM 01->80
EmulOp 7104
Read XPRAM 02->4f
...
Patch BootGlobs
EmulOp 7104
RTC write op 13, d1 00550035 d2 0000003f
EmulOp 7104
RTC write op 12, d1 00000031 d2 0000003f
EmulOp 7104
RTC write op 13, d1 00d50035 d2 0000003f
EmulOp 7104
Read XPRAM 10->a8
EmulOp 7104
...
EmulOp 7128
EmulOp 7129
EmulOp 712b
vCheckLoad DRVR (44525652) ID 4, data 0x1ad33e0, size 26828
EmulOp 710c
SonyOpen
set_dsk_err(0)
EmulOp 7129
EmulOp 712b
vCheckLoad DRVR (44525652) ID 51, data 0x1b4e500, size 2716
EmulOp 710a
InstallDrivers
EmulOp 7110
DiskOpen
  DrvSts at 00003d68
  disk inserted
  20480 blocks
  adding drive 1
EmulOp 7114
EmulOp 7129
EmulOp 7129
EmulOp 7129
ASC registers at 00003dd4
EmulOp 7104
Read XPRAM 80->00
EmulOp 7104
Read XPRAM 81->80
EmulOp 7129
EmulOp 7129
EmulOp 712b
vCheckLoad SERD (53455244) ID 0, data 0x1ad1b90, size 6188
EmulOp 710b
InstallSERD
EmulOp 7129
EmulOp 7129
EmulOp 7123
ADBOp op 00, data 00 00 00
EmulOp 7123
ADBOp op 0f, data 00 00 00
EmulOp 7123
ADBOp op 1f, data 00 00 00
...
EmulOp 7129
EmulOp 712b
vCheckLoad accl (6163636c) ID 2, data 0x1add750, size 110
EmulOp 712b
vCheckLoad accl (6163636c) ID 1, data 0x1add7f0, size 110
EmulOp 712b
vCheckLoad KCHR (4b434852) ID 0, data 0x1ae24c0, size 1434
EmulOp 712b
vCheckLoad KMAP (4b4d4150) ID 0, data 0x1ae2400, size 146
EmulOp 7123
ADBOp op 21, data ff 8f e0
  keyboard reg 3 6205
EmulOp 7129
EmulOp 7129
EmulOp 7129
EmulOp 7129
EmulOp 7129
EmulOp 7129
EmulOp 7129
EmulOp 7129
EmulOp 7104
...
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7128
EmulOp 7111
EmulOp 7112
DiskControl 7
...


	Any ideas?

--
| Nigel Pearson, ni...@in...   | "In this city I confess
| Telstra BI&D, Sydney, Australia         |  god is mammon, more is less
|   Office: 8255 4222    Fax:  8255 3153  |  off like lemmings at the 
gun
|   Mobile: 0408 664435  Home: 9792 6998  |  I know better, still I run"

[B2-devel] vm_alloc.cpp and mach_task_self()

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

	Strange autoconf error. config.log shows:

...
configure:6645: checking for mach_task_self
configure:6682: gcc -o conftest -g -O2   conftest.c  >&5
configure:6685: $? = 0
configure:6688: test -s conftest
configure:6691: $? = 0
configure:6701: result: yes
...
configure:6839: checking whether vm_protect works
configure:6868: g++ -o conftest -g -O2   conftest.cc  >&5
In file included from configure:6863:
../Unix/vm_alloc.cpp: In function `void* vm_acquire(long unsigned int)':
../Unix/vm_alloc.cpp:95: `mach_task_self' undeclared (first use this 
function)
../Unix/vm_alloc.cpp:95: (Each undeclared identifier is reported only 
once for
    each function it appears in.)
../Unix/vm_alloc.cpp:95: `vm_allocate' undeclared (first use this 
function)
../Unix/vm_alloc.cpp: In function `int vm_release(void*, long unsigned 
int)':
../Unix/vm_alloc.cpp:165: `vm_deallocate' undeclared (first use this 
function)
configure:6871: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 6859 "configure"
#include "confdefs.h"

       #define CONFIGURE_TEST_VM_MAP
       #define TEST_VM_PROT_NONE_READ
       #include "../Unix/vm_alloc.cpp"




	Now, the mach_task_self() prototype is in a strange file
(/usr/include/mach/mach_init.h), so I can understand the barf,
but why did the first test succeed?

--
| Nigel Pearson, ni...@in...   | "Reality is that which,   |
| Telstra BI&D, Sydney, Australia         |  when you stop believing  |
|   Office: 8255 4222    Fax:  8255 3153  |  in it, doesn't go away." |
|   Mobile: 0408 664435  Home: 9792 6998  |  Philip K. Dick - 'Valis' |

Re: [B2-devel] A few people have asked me abut

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

Hi!

On Wed, Oct 16, 2002 at 08:38:45AM +1000, Nigel Pearson wrote:
> I will go and look at that thread, but is there any good reason not to
> link to my home page:
> 
> http://www.users.bigpond.com/pear_computers
> 
> from the main B2 page?

I wasn't aware of that page until now. I also get lots of inquiries about
the Mac OS X version of B2 and never knew what to tell them except "it's
in the CVS", or "wait for 1.0"...

Bye,
Christian

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

[B2-devel] A few people have asked me abut

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

	Lately, quite a few people have asked me questions about
my MacOS X port, and in particular why it isn't mentioned on
the main B2 home page. e.g.:

> Hi There,
>
> My name is chris peyton, I found out about basilisk because I wanted 
> to play some old games on my (relatively) new mac - which runs osx.
> Thanks for bringing the ability to play old games/use apps to the new 
> os, but myself and others are having a little trouble getting it to 
> work. for further details, please see this thread at www.macnn.com :
>
> http://forums.macnn.com/showthread.php?s=&threadid=126180
>
> Basically the problem is getting system 7 to install. I get so far 
> into the install, then it quits. I would be grateful if you could give 
> any advice how to accomplish the install.
> Also, out of curiosity, is there any reason that this version isn't 
> mentioned on the basilisk home page?
>
>
> Thanks,
>
> Chris


	I will go and look at that thread, but is there any good reason
not to link to my home page:

http://www.users.bigpond.com/pear_computers

from the main B2 page?

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

Re: [B2-devel] some questions and a small patch

[[rSu]G-LiTe <g-...@cl...>]

Christian Bauer wrote:

>Hi!
>
>On Mon, Sep 30, 2002 at 08:52:30PM +0200, [rSu]G-LiTe wrote:
>  
>
>>[Mac <-> Unix text clipboard]
>>The thing is, I have no idea which characters actually differ between
>>the charsets.
>>    
>>
>
>The MacOS "Roman" text encoding is described in
>  http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT
>
>For B2, I substituted some similar looking characters for those not in
>the ISO 8859-1 set. E.g. 0xA0 "dagger" gets translated to a '+'.
>  
>
I'll look into it.

>  
>
>>[...] I can't really turn it around because some mac characters seem to
>>have multiple iso equalevants.
>>    
>>
>
>It's rather that some Mac characters have no ISO equivalents...
>
>The clipboard code in B2 should be completely rewritten some day. It should
>work in both directions, perhaps use Unicode internally for text conversion,
>and clip_unix.cpp still uses the obsolete X cut buffers.
>
>The problem is that I rarely use this stuff (in fact, I don't use it at
>all, I think...), so my motivation is a little low. A perfect 3rd-party
>opportunity. :-)
>
hehe, I'll try that but it'll ofcourse print multiple weird characters 
on the console or any other non-unicode app if it's a special 
character... But I don't think that matters as normally we wouldn't be 
able to print it at all.

>  
>
>>I attached a small audio patch [...]
>>    
>>
>
>Cool. Thanks! :-)
>
np

>Bye,
>Christian
>
>P.S.: Please don't send your mail as HTML-only messages. mutt doesn't
>  display them, and I usually delete them without looking any further
>  because they are spam in >99.9% of all cases.
>
got that, changed mozilla settings, should be okay now :)

>
>  
>

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

[rSu]G-LiTe - ReSpawners United
_g...@cl..._ <mailto:g-...@cl...>

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

Re: [B2-devel] some questions and a small patch

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

Hi!

On Mon, Sep 30, 2002 at 08:52:30PM +0200, [rSu]G-LiTe wrote:
> [Mac <-> Unix text clipboard]
> The thing is, I have no idea which characters actually differ between
> the charsets.

The MacOS "Roman" text encoding is described in
  http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT

For B2, I substituted some similar looking characters for those not in
the ISO 8859-1 set. E.g. 0xA0 "dagger" gets translated to a '+'.

> [...] I can't really turn it around because some mac characters seem to
> have multiple iso equalevants.

It's rather that some Mac characters have no ISO equivalents...

The clipboard code in B2 should be completely rewritten some day. It should
work in both directions, perhaps use Unicode internally for text conversion,
and clip_unix.cpp still uses the obsolete X cut buffers.

The problem is that I rarely use this stuff (in fact, I don't use it at
all, I think...), so my motivation is a little low. A perfect 3rd-party
opportunity. :-)

> I attached a small audio patch [...]

Cool. Thanks! :-)

Bye,
Christian

P.S.: Please don't send your mail as HTML-only messages. mutt doesn't
  display them, and I usually delete them without looking any further
  because they are spam in >99.9% of all cases.

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

Re: [B2-devel] JIT improvements and future directions?

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

Hi!

On Wed, Oct 02, 2002 at 08:46:10PM +0200, Gwenole Beauchesne wrote:
> As a general note, what about a native implementation of the trap 
> dispatcher?

Could be worth a try, but I doubt that this would be a noticable
improvement.

> Just to make sure, traps >= 0xA800 are Toolbox traps thus residing in 
> ROM?

Well, many (the older the ROM and newer the MacOS version, the more) of them
get patched anyway, so they're not really "in ROM"...

> Those pass arguments through stack if I remember correctly.

Yes.

> And those don't actually peek at values in registers but use them as scratch 
> data for whatever operation, thus saving them prior to any use, right? 

This appears to be the case.

> Hmm, some more TODO? :-)

video_beos.cpp. I have the window mode working now, but there's still some
instability somewhere. And it's only tested on PPC (my BeOS/x86 installation
is once again not working, after a graphics card update...).

Bye,
Christian

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

Re: [B2-devel] JIT improvements and future directions?

[Gwenole B. <gbe...@ma...>]

Hi,

>> 001: e9c5     565147 BFEXTU
>
> Interesting that this gets used so much. It's probably just a benchmark 
> thing,
> not worth bothering about.

Yes, I looked again at the generated code for the interpreter and that's 
awful. :-/

>> 018: a873      62307 ILLEGAL
>
> SetPort()...

As a general note, what about a native implementation of the trap 
dispatcher? To me, A-Traps look rather like function call to perform a 
certain operation. That is, we are good at chaining translated blocks or 
even inlining them if no event came in the trace (spcflags), so that 
would be a pity to have to save everything and possibly go the slow 
interpreter way.

Well, I don't know how much time is really spent in the traps dispatcher 
but I believe that a native implementation could be beneficial for 
non-JIT targets as well.

Did MACE people/guy have something in that direction yet?

>> For those, I don't remember whether the OS is supposed to save 
>> registers
>> itself or not.
>
> According to my notes, traps >=A800 save all registers. Traps A000..A7FF
> save at least d3-d7/a3-a6, sometimes more (I don't remember whether 
> there
> are any clear API conventions here; e.g. there is code that expects
> A0BD (vCacheFlush) to save all registers).

Just to make sure, traps >= 0xA800 are Toolbox traps thus residing in 
ROM? Those pass arguments through stack if I remember correctly. And 
those don't actually peek at values in registers but use them as scratch 
data for whatever operation, thus saving them prior to any use, right? 
i.e. that would imply we wouldn't have to bother spilling values in host 
registers back to their home.

Hmm, some more TODO? :-)

Bye,
Gwenole.

Re: [B2-devel] JIT improvements and future directions?

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

Hi!

On Wed, Oct 02, 2002 at 06:36:13PM +0200, Gwenole Beauchesne wrote:
> 001: e9c5     565147 BFEXTU

Interesting that this gets used so much. It's probably just a benchmark thing,
not worth bothering about.

> 011: a829     147549 ILLEGAL

LayerDispatch() (I have no clear idea what this does...)

> 013: a030     134593 ILLEGAL

OSEventAvail() (this was to be expected)

> 014: a0dd     131286 ILLEGAL

PPCDispatch() ("PPC" as in Program-To-Program-Communications)

> 015: abf7     131264 ILLEGAL

SynchIdleTime() (also to be expected)

> 018: a873      62307 ILLEGAL

SetPort()...

> For those, I don't remember whether the OS is supposed to save registers 
> itself or not.

According to my notes, traps >=A800 save all registers. Traps A000..A7FF
save at least d3-d7/a3-a6, sometimes more (I don't remember whether there
are any clear API conventions here; e.g. there is code that expects
A0BD (vCacheFlush) to save all registers).

Bye,
Christian

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

[B2-devel] JIT improvements and future directions?

[Gwenole B. <gbe...@ma...>]

Hi,

I have just implemented sort of block inlining. It does still have to
generate BSR/RET instructions to have correct stack content but that's
easier anyway. However, this doesn't bring as much as expected, if
anything.  That's probably because BSR.L are not translated yet and I have
to check why.

Besides, I decided to have a look at the opcodes that should worth being
translated. After running the mixed-benchmark of Speedometer 4, I come to
the following top ten:

Rank  Opc      Count Name
000: 81fc    1858278 DIVS
001: e9c5     565147 BFEXTU
002: 61ff     470663 BSR
003: 007c     335196 ORSR
004: e9d3     281943 BFEXTU
005: 40c0     267858 MVSR2
006: efc6     248459 BFINS
007: e9c0     245098 BFEXTU
008: 40e7     195290 MVSR2
009: 46df     193867 MV2SR
010: e541     169805 ASL

Needless to say, I will have to self-motivate enough to mess out 
translation of bit-field instructions. DIVS is worth a try too. After 
those 11 most untranslated instructions that had to be run from the cache, 
come a lot of A-Traps. As shows the continued top20:

011: a829     147549 ILLEGAL
012: 46c0     139348 MV2SR
013: a030     134593 ILLEGAL
014: a0dd     131286 ILLEGAL
015: abf7     131264 ILLEGAL
016: e9d0     106180 BFEXTU
017: e9ee      92768 BFEXTU
018: a873      62307 ILLEGAL
019: f200      60323 FPP

For those, I don't remember whether the OS is supposed to save registers 
itself or not. In the former case, translated code could be further 
optimized by not unconditionally spilling 68k registers to their original 
locations.

WDYT?

On the other hand, I would like to stabilize the JIT compiler more. But I
need feedback and problems I can reproduce here. There is a true reason
why I want a B2 1.0 with m68k->x86 JIT out soon. ;-)

Bye,
Gwenole.

Re: [B2-devel] some questions and a small patch --- Forgot to attach it :S

[[rSu]G-LiTe <g-...@cl...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<div class="moz-signature">Stupid, forgot to attach it... here it is. Btw,
I couldn't make an actual patch, deleted the original sources. This should
just overwrite yesterdays cvs snapshot (29 sept).<br>
<hr width="100%" size="2" align="center"><br>
<div align="center"><font color="#999999">[</font><font color="#000099">rSu</font><font
 color="#999999">]</font><font color="#3366ff">G-LiTe</font> <font
 color="#999999">-</font> <font color="#3366ff"><font color="#000099">R</font>e<font
 color="#000099">S</font>pawners <font color="#000099">U</font>nited</font><br>
<a href="mailto:g-...@cl..."><u><font color="#3333ff">g-...@cl...</font></u></a></div>
<br>
<hr width="100%" size="2" align="center"><br>
</div>
</body>
</html>

[B2-devel] some questions and a small patch

[[rSu]G-LiTe <g-...@cl...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Just stuffin' it all in one mail. :B<br>
<br>
Fullscreen works now, nice! :)<br>
<br>
I tried looking at the clipping code to see if I could maybe do the Unix-&gt;B2
thingy. Now I know I'm absolutely not familiar with... almost everything
involving multiple platforms, but I atleast understood what was going on
in the iso to mac charset conversion. So I just tried doing the opposite
of what was done in the PutScrap() function (think that was the name, right?
Can't look it up right now). The thing is, I have no idea which characters
actually differ between the charsets. I can't really turn it around because
some mac characters seem to have multiple iso equalevants. It'd also result
in a rather large and ugly table.<br>
Maybe I'm just too much of a newbie to understand, hope you could point me
to some document that explains this. Just thought I'd do something that's
actually in the todo file. ;)<br>
<br>
I attached a small audio patch which might not be really necessary, actually.
It just allows selecting a different audio/mixer device to use instead of
the hardcoded standards. Added a gtk prefs option too and some devfs compatibility.<br>
<br>
The JIT compiler seems to be segfaulting here, I haven't really looked into
it. It's doing that just before the emulation starts. I'll install mon again
and see if I can get you somewhat more usefull info.<br>
<br>
&nbsp;&nbsp;&nbsp; -- G-Lite<br>
<div class="moz-signature"><br>
<hr width="100%" size="2" align="center"><br>
<div align="center"><font color="#999999">[</font><font color="#000099">rSu</font><font
 color="#999999">]</font><font color="#3366ff">G-LiTe</font> <font
 color="#999999">-</font> <font color="#3366ff"><font color="#000099">R</font>e<font
 color="#000099">S</font>pawners <font color="#000099">U</font>nited</font><br>
<a href="mailto:g-...@cl..."><u><font color="#3333ff">g-...@cl...</font></u></a></div>
<br>
<hr width="100%" size="2" align="center"><br>
</div>
</body>
</html>

Re: [B2-devel] Unix Video problems... still.

[Gwenole B. <gbe...@ma...>]

On Tue, 30 Jul 2002, [RSU]G-Lite wrote:

> Then for something else, when forcing TrueColor (which is my default 
> visual class), colors are scrambled. It might be inverted colors don't 
> know for sure.

That was due to a typo to enable the right portion of code. ;-)

> DirectColor is messed up too, but DirectColor messes up colors in the 
> whole X Server, not just Basilisk II so I can't tell whether it's 
> displaying them right or wrong there. :)

DirectColor in DGA mode should work now since my last commit of today.  
However, when quitting B2, I get

XIO:  fatal IO error 9 (Bad file descriptor) on X server ":0.0"
      after 79 requests (78 known processed) with 0 events remaining.

Any thoughts?

Bye,
Gwenole.

Re: [B2-devel] IEEE FPU build problems

[Gwenole B. <gbe...@ma...>]

On Fri, 20 Sep 2002, Brian Johnson wrote:

> Anyway, it sounds like we should disable long doubles for sgi
> platforms, at least with MIPSPro compilers.

Better, I will completely disable quad doubles for any architecture in 
<fpu/types.h>. i.e. don't handle SIZEOF_LONG_DOUBLE == 16 case.

Thanks for your tests.

Bye,
Gwenole.

Re: [B2-devel] IEEE FPU build problems

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

--- Gwenole Beauchesne <gb...@di...> wrote:
> Done something in CVS. That may still be wrong though. BTW, I read

Didn't seem to help... I got a freeze instead of simple wrong
results.

> at some page that the mips64 compiler can have sizeof(long double)
> == 16 but (i) does not have an IEEE-compliant format, (ii) is
> emulated in a pair of double registers? As such, I am wondering if
> disabling quad doubles isn't the safest solution at this point.

Yes, the CPU itself only does float and double.  The math(3m) man page
describes the issues with long double... basically, the compiler
fabricates them from two doubles.  So using 8-byte doubles is probably
the way to go on MIPS/IRIX.

I'll try configuring with ac_cv_type_long_double=no... that forces
SIZEOF_LONG_DOUBLE to 0...  and it seems to work!  Calculator produces
reasonable answers, and the Speedometer FPU benchmarks also produce
something besides garbage.  That's never worked before on SGI boxes!

There may be some precision or rounding issues... using 68030+fpu
mode, if I enter 1.1 in ClarisWorks spreadsheet, I get 1.099999999 in
the cell.  Using plain 68030 mode, I get 1.1.  (Although even then, I
get rounding errors after some calculations.  Eg. it says 1.1*2 =
2.199999999.)

Anyway, it sounds like we should disable long doubles for sgi
platforms, at least with MIPSPro compilers.

						Brian

Re: [B2-devel] IEEE FPU build problems

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

Hi,

>> However, the runtime FP results don't seem anywhere near right.
>
> That could be because extract_extended() and 
> make_extended_no_normalize() are not implemented yet for quad doubles. 
> i.e. the mantissa is filled in with bits not at the right place. Sorry 
> about that, I will have a look.

Done something in CVS. That may still be wrong though. BTW, I read at 
some page that the mips64 compiler can have sizeof(long double) == 16 
but (i) does not have an IEEE-compliant format, (ii) is emulated in a 
pair of double registers? As such, I am wondering if disabling quad 
doubles isn't the safest solution at this point.

Bye,
Gwenole

Re: [B2-devel] IEEE FPU build problems

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

Hi Brian,

> However, the runtime FP results don't seem anywhere near right.

That could be because extract_extended() and 
make_extended_no_normalize() are not implemented yet for quad doubles. 
i.e. the mantissa is filled in with bits not at the right place. Sorry 
about that, I will have a look.

Bye,
Gwenole.

Re: [B2-devel] IEEE FPU build problems

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

Gwenole,

With your latest checkins (and a cvs update -d, sorry 'bout that), I
can build with the IEEE FPU.  However, the runtime FP results don't
seem anywhere near right.  In 68030+FPU mode, The calculator DA
reports:
 3/2 = not a number
 1.5*3 = 2914.5
 1+1 = 40

In 68040 mode, it says:
 3/2 = -9.25
 1.5*3 = 13685
 1+1 = not a number

The results aren't consistent; if I enter the same calculation several
times in a row, I get different answers.  Eg. on 68040:
 3/2 = -26.75, 117.25, -26.75, not a number, -26.75, -26.75

						Brian

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

   "I love deadlines. I like the whooshing sound they make as they fly by."
                                           -- Douglas Adams

Re: [B2-devel] IEEE FPU build problems

[Gwenole B. <gbe...@ma...>]

On Thu, 19 Sep 2002, Gwenole Beauchesne wrote:

> The PUBLIC/PRIVATE things are residuals from ancient time when I wanted to 
> actually have C++ methods in the fpu class. Well, I will s/PUBLIC 
> inline/static inline/ everywhere. The other bits should not conflict.

Done.

> OK, I will look again on a sparc host but I am not sure they had native 
> sizeof(long double) == 16. I don't have any mips handy. Anyway, I will try 
> to fool locally. Check cvs soon.

Workarounded in CVS now. However, note there are two FIXME's in
fpu_ieee.cpp for USE_QUAD_DOUBLE case. Will have a look tonight but that
won't be tested.

BTW, do you know if MIPS supports native sizeof(long double) == 16 format?  
I believe they usually get emulated in the system C library on other
platforms. Besides, do you have *l() math functions (cosl, asinl, etc.).
Otherwise, I will probably and simply drop support of it and keep only
sizeof(long double) == 12 case which works without troubles, but only 
tested (and available?) on x86.

Thanks,
Gwenole.