basilisk-devel — Basilisk II development-related discussion

[B2-devel] Darwin port

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

Hi,

The Darwin port is almost working (to be committed):
<http://gwenole.beauchesne.free.fr/sheepshaver/capture_darwin_port.pdf>

As you can see, video performance is crappy. Probably that using the 
Mach exception filters will help a little instead of going through 
signal handlers with full register state save. Does any Mach expert 
know how to add exception filters for SIGUSR2/SIGILL things too?

BTW, it should really be easy to do a basic port to other PowerPC 
systems like *BSD. Hopefully, the assembler used there is not as dumb 
as Apple's (i.e. claimed support of multiple statements per line with 
';', but ';' is also the comment delimiter for PPC code => bugs).

Bye,
Gwenole.

[B2-devel] Re: New SheepShaver test release

[Toshimitsu T. <t_t...@db...>]

Hi.

On 2004/01/15, at 0:17, Christian Bauer wrote:
> On Wed, Jan 14, 2004 at 11:07:52AM +0100, Gwenole Beauchesne wrote:
>> Christian, I think we are approaching an official 2.2 release. ;-)
>
> This is very cool. :-)

By the way, do you create new official SheepShaver page?
The old official SS page (http://www.sheepshaver.com) cannot be used 
any longer.
---
Toshimitsu Tanaka
t_t...@db...
http://member.nifty.ne.jp/poseidon/index.html

My SheepShaver page:
http://member.nifty.ne.jp/poseidon/emu/sheepshaver1.html
(Sorry,Japanese text only)

[B2-devel] SheepShaver for Windows

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

Hi,

For people willing to get SheepShaver for Windows, there are two options:  
(i) do the work themselves, (ii) find out someone willing to do it.

I think the following should be enough (and required) to get things
working at least under CygWin/X11:

1) Implement native Win32 memory allocation wrappers as specified in
vm_alloc.cpp. The API is simplistic and wraps e.g. mmap() under Unix-like
platforms, and vm_allocate() under Mach/Darwin.

2) Implement native Win32 SIGSEGV handlers in sigsegv.cpp.

3) Make sure you can map the following virtual regions under Windows
(lower bound inclusive, upper bound exclusive):
* 0x00000000 => 0x00003000 : Low Memory globals
* <any base> => + RAM Size : RAM area
* 0x40800000 => 0x40d00000 : ROM area (may be relocatable elsewhere)
* 0x68ffe000 => 0x69000000 : NanoKernel globals
* 0x5fffe000 => 0x60000000 : NanoKernel globals (*alias*, same phys_addr)
* 0x69000000 => 0x69100000 : DR emulator cache (unused for now)

4) For the JIT, you can check if your compiler can generate ELF objects (I
doubt it as it might be configured to generate PE only). Otherwise, there
should be a possibility to grab the generated source files from Linux.  
Alternatively, people could patch dyngen to read PE objects too.

You can have a look at Lauri's port of B2. It should help.

Note: I don't have any Windows handy and don't need it actually. So, I
can't (neither know how to) do that myself.

Bye,
Gwenole.

Re: [B2-devel] New SheepShaver test release

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

Hi,

> New releases of SheepShaver (and B2) are badly needed, though...

It was time to get a PPC emulator out as there are some other well known
companies stepping down. ;-)

> > * Support for copy-paste of text between MacOS and X11 through the clipboard
> 
> What are your plans for graphics clipping? Mac->X11 might get very involved
> with the handling of PICTs.

I was thinking about grabbing the underlying pixels through an offscreen
GWorld (where the PICT scrap would have been rendered). However,
GetGWorld() doesn't return me valid information. I tried several things: a
direct MacOS call, going through a native routine descriptor, or
equivalent 68k code through _QDExtensions. The data was expected to be in
stack but garbage got written in place of the actual GrafPort.

This garbage looked like a CR register copy. So, I decremented the stack
pointer further prior to _QDExtensions but this can't be correct according
to the usual calling conventions. I even tried to add DisableInterrupt()  
and EnableInterrupt() around, in case that was our fault to clash the
stack that way. No apparent change.

The last resort is indeed to interpret the PICT opcodes ourselves. Though
it will be faster than letting MacOS do that through e.g. PPC emulation,
this will be less accurate as it doesn't seem all opcodes are fully
documented.

Handling PICT ourselves is quite a bit of work (even if there is some kind
of support from picttoppm & ImageMagick), so I suspended that for now.
Thinking about it, probably that implementing a CopyBits() replacement
first will be a base for that as it too implies operations similar to some
of the PICT opcodes.

As for the target image format to propose to the X11 side, XPM & PPM are
the simplest (but biggest) formats that are better known to other clients.  
Some others support "image/png" though.

Bye,
Gwenole.

Re: [B2-devel] New SheepShaver test release

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

Hi!

On Wed, Jan 14, 2004 at 11:07:52AM +0100, Gwenole Beauchesne wrote:
> Christian, I think we are approaching an official 2.2 release. ;-)

This is very cool. :-)

I'm very embarrassed to admit that I didn't have time yet to check out
all the nice stuff you did with B2 and SheepShaver. :-/

New releases of SheepShaver (and B2) are badly needed, though...

> * Support for copy-paste of text between MacOS and X11 through the clipboard

What are your plans for graphics clipping? Mac->X11 might get very involved
with the handling of PICTs.

Bye,
Christian

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

[B2-devel] New SheepShaver test release

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

Hi,

I uploaded sources & binaries from current CVS at:
<http://gwenole.beauchesne.free.fr/sheepshaver/files/>
Files: SheepShaver-2.2-20040114.tar.bz2, RPMs 2.2-8

Note that the -hacks.patch file is required if you compile from sources 
and intend to use MacOS 8.6. Hopefully, there will be a real fix later 
(through a better fake SCSIManager/SIM expert?).

Christian, I think we are approaching an official 2.2 release. ;-)

Notable changes from previous test release include:
* PowerPC ALU emulation is validated over 700K instruction variants
* PowerPC FPU emulation is more accurate (this fixes e.g. the "scrollbar" 
bugs, Graphing Calculator with 3D demos, MacOS help center, etc.)
* Support for 64-bit platforms. More precisely AMD64 with JIT
* Support for copy-paste of text between MacOS and X11 through the clipboard
* Support for the wheel mouse
* Better support for PowerMac PCI ROMs with more generic patches
* Better support for audio output (with pre-G3 PowerMac PCI ROMs)
* On native side, fixes for SheepThreads & semaphores
* Start support (SIGSEGV recovery) for the following platforms: IRIX/mips,
Solaris/sparc, FreeBSD/alpha

Re: [B2-devel] B2/SS clipboard implementation for Unix

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

Hi,

> 2) It seems that GetScrap gets called *several* times when you select 
> an entry to edit, without any 'paste' action. e.g. a folder label. 
> This brings up the problems of getting the native clipboard several 
> times too. That may be costly to handle, especially with images. One 
> solution may be to call XConvertSelection() with a timestamp of the 
> last successful request for GetScrap, but I am still not convinced.

Current implementation with latest commits to SheepShaver CVS now looks 
good. i.e. we can exchange text between MacOS & X11 in both ways. I 
have implemented our own set of X11 display locking primitives and 
placed them at locations I think were best and in fewer occurrences.

Bye,
Gwenole.

[B2-devel] B2/SS clipboard implementation for Unix

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

Hi,

I have spent the day learning about X11 clipboard facilities (the ICCCM 
compliant way) to handle copy/paste between MacOS and X11. However, a 
few things worry me.

1) According to Inside Mac docs, GetScrap & PutScrap are expected to 
return values. However, I am confused with actual semantics of the ROM 
traps we patch. i.e. are they also expected to return values in the 
stack?

2) It seems that GetScrap gets called *several* times when you select 
an entry to edit, without any 'paste' action. e.g. a folder label. This 
brings up the problems of getting the native clipboard several times 
too. That may be costly to handle, especially with images. One solution 
may be to call XConvertSelection() with a timestamp of the last 
successful request for GetScrap, but I am still not convinced.

3) Currently, I am trying to be ICCCM compliant. This means for 
instance that copying text from MacOS won't put it in the PRIMARY 
selection for immediate pasting with the middle mouse button. We could 
change that but the default must comply with ICCCM recommendations so 
that we remain consistent with other programs e.g. KDE applications. I 
plan an extra prefs item for that: "clipprimary" or whatever name 
people feel better. However, I won't implement that now as I would like 
to first play with 'PICT' handling.

Any thoughts?

Thanks,
Gwenole.

[B2-devel] SheepShaver 64-bit fixes & BeOS/PPC

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

Hi,

I am about to commit many fixes to make SheepShaver run on 64-bit 
platforms, especially AMD64. I introduced a new thunking system so that 
code & data could be shared with MacOS. The trick is to also make sure 
SheepShaver globals are 32-bit addressable.

I also updated BeOS/PPC bits but I have no such system to test, so please 
someone with it check. <hint> ;-)

I tried to keep changes minimal, so I introduced new objects to deal with
shared data with MacOS. The storage is stack-like and are meant to be used
as temp local data. Basically:

- SheepVar: reserve a certain amount of memory
- SheepVar32: an uint32 value in big endian format
- SheepString: a copy of the string to 32-bit addressable data
- SheepArray<>: an array with size specified from template arg
The latter is purely for optimization purposes on 32-bit arches

Bye,
Gwenole.

[B2-devel] Altivec test programs

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

Hi,

I would like to know if you have any pointer to real-world MacOS (or 
Linux/ppc) programs that use VMX instructions.

Thanks,
Gwenole.

[B2-devel] SheepShaver test release 2

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

On Tue, 25 Nov 2003, Gwenole Beauchesne wrote:

> I uploaded sources & binaries from current CVS at:
> <http://gwenole.beauchesne.free.fr/sheepshaver/files/>

There is now a new test release with JIT fixed and enabled by default.  
Code is also committed to CVS.

I would like to get your feelings. e.g. is it visibly faster? Is there any
regression from previous release with pure interpreter? Comparing B2/JIT
(m68k) vs. SheepShaver/JIT (ppc) yields mixed results.

Thanks,
Gwenole.

[B2-devel] SheepShaver test release

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

Hi,

I uploaded sources & binaries from current CVS at:
<http://gwenole.beauchesne.free.fr/sheepshaver/files/>

This should enlarge the testing audience as I am still not convinced
SheepShaver is fully little endian aware. e.g. The ethernet stuff needs
some reworking.

BTW, I have committed the current JIT compiler but I probably messed the
integration because it became unstable at some point during the boot. The
good news is the "JIT1" engine is reasonably portable. So far, it works
for AMD64, IA-32 and PPC.

nbench tests (linux/ppc binaries) ran under Kheperix show an average
increase of 4x on ia32 but only 2x on ppc. Some simple optimizations are
still possible like deferred CR evaluation, block chaining, host-specific
asm optimizations.

Bye,
Gwenole.

Re: [B2-devel] SheepShaver for x86

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

Hi,

> However, there is another bug lurking around but you can still boot 
> without extensions

Actually, sounds like the same problem I had back in B2 days with real 
addressing mode. i.e. seems that someone is trying to read data from 
"address" located in [ROM85]. I had workarounded that in B2 (the 
AppleShare thing) but I now think probably one rsrc patch is being 
applied wrong in both B2 & SheepShaver on little endian systems.

In MacOS PPC, I haven't found the 'DRVR' 41 resource containg the 
faultive code. Should be an ndrv equivalent or whatever but range 
probing lead to nothing useful.

> You will also need the following patch until a real fix appears.

[video_x.cpp patch]

Fixed in current CVS.

Bye,
Gwenole

Re: [B2-devel] Re: SheepShaver for x86

[Toshimitsu T. <t_t...@db...>]

Hi.

On 2003/11/13, at 19:36, Gwenole Beauchesne wrote:
> Which system did you tried? Was it a CD boot? Concerning the black 
> screen,
> this sometimes happens when the XPRAM/NVRAM is corrupted somehow.

CD boot was not successful yet.

I tried some Disk Tools images.

Disk Tools for Power Mac 8500/7500(System 7.5.2) is OK.
Mac OS 8.5 Disk Tools is OK,too.

Disk Tools PPC(8.1) does not boot.

System 7.5.3 Disk Tools 2 is NG.

# SheepShaver V2.2 by Christian Bauar and Mar"c" hellwig
Reading ROM file...
Illegal instruction at 2008c664, opcode=00000000

---
Toshimitsu Tanaka
t_t...@db...
http://member.nifty.ne.jp/poseidon/index.html

Re: [B2-devel] Re: SheepShaver for x86

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

On Wed, 12 Nov 2003, Toshimitsu Tanaka wrote:

> I used the ROM file of Gossamer g3
> SheepShaver started,but it only displays a black screen...

Which system did you tried? Was it a CD boot? Concerning the black screen, 
this sometimes happens when the XPRAM/NVRAM is corrupted somehow.

[B2-devel] Re: SheepShaver for x86

[Toshimitsu T. <t_t...@db...>]

Hi.

I succeeded in boot of SheepShaver for x86.

http://www006.upp.so-net.ne.jp/t_tanaka/images/ssx86.jpg

I tried SS on RedHat Linux 8  with  Gossamer ROM
and Disk Tools(for Power Mac 8500/7500).

Thanks,Gwenol.
---
Toshimitsu Tanaka
t_t...@db...
http://member.nifty.ne.jp/poseidon/index.html

[B2-devel] Re: SheepShaver for x86

[Toshimitsu T. <t_t...@db...>]

Hi.

On 2003/11/11, at 3:26, Gwenole Beauchesne wrote:
>
>> * There is stil at least one little endian bug preventing SheepShaver 
>> from running on x86 at this time.
>
> Fixed in current CVS.
>
> However, there is another bug lurking around but you can still boot 
> without extensions and run applications (tested MacOS 8.1). On a P4 @ 
> 1.8 GHz, Speedometer 4.x reports speeds around 1.7x of a real Quadra 
> 605 (approx. 50% slower than B2 without JIT). Now next step is 
> abviously to write the JIT. ;-)
>
> You will also need the following patch until a real fix appears.
>
> --- src/Unix/video_x.cpp	26 Oct 2003 07:54:02 -0000	1.4
> +++ src/Unix/video_x.cpp	10 Nov 2003 17:59:33 -0000

I got source code of SheepShaver from CVS,and edited  
src/Unix/video_x,cpp.
Make on Fedora Core 1 was successful.

I used the ROM file of Gossamer g3
SheepShaver started,but it only displays a black screen...

Any ideas ?
---
Toshimitau Tanaka
t_t...@db...
http://member.nifty.ne.jp/poseidon/index.html

[B2-devel] Re: SheepShaver for x86

[Toshimitsu T. <t_t...@db...>]

Hi.
 
>> * There is stil at least one little endian bug preventing SheepShaver
>> from running on x86 at this time.
> 
> Fixed in current CVS.
> 
> However, there is another bug lurking around but you can still boot
> without extensions and run applications (tested MacOS 8.1).

Great!

For a test, can I get a binary or a complete source code?
---
Toshimitsu Tanaka
t_t...@db...
http://member.nifty.ne.jp/poseidon/index.html

[B2-devel] SheepShaver for x86

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

Hi,

> * There is stil at least one little endian bug preventing SheepShaver 
> from running on x86 at this time.

Fixed in current CVS.

However, there is another bug lurking around but you can still boot 
without extensions and run applications (tested MacOS 8.1). On a P4 @ 
1.8 GHz, Speedometer 4.x reports speeds around 1.7x of a real Quadra 
605 (approx. 50% slower than B2 without JIT). Now next step is 
abviously to write the JIT. ;-)

You will also need the following patch until a real fix appears.

--- src/Unix/video_x.cpp	26 Oct 2003 07:54:02 -0000	1.4
+++ src/Unix/video_x.cpp	10 Nov 2003 17:59:33 -0000
@@ -199,7 +199,7 @@

  	// Try to create and attach SHM image
  	have_shm = false;
-	if (local_X11 && depth != 1 && XShmQueryExtension(x_display)) {
+	if (0 && local_X11 && depth != 1 && XShmQueryExtension(x_display)) {

  		// Create SHM image ("height + 2" for safety)
  		img = XShmCreateImage(x_display, vis, depth, depth == 1 ? XYBitmap : 
ZPixmap, 0, &shminfo, width, height);

Re: [B2-devel] Sheepshaver news (week 43)

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

Hi,

> * There is still a generic bug preventing SheepShaver from booting 
> with extensions on in emulated mode. i.e. it either hangs around 
> 'CD00'  resource with MacOS 8.1 or 'CD17' resource with MacOS 8.6.

Fixed in current CVS. Basically, some MacOS routine relies on the 
TimeBase register. The current workaround is to implement mftb as a 
call to clock(). A better solution would be to patch UpTime from 
DriverServicesLib & friends, and try to increment TBR every N 
instructions where N has yet to be defined.

Bye,
Gwenole.

[B2-devel] Sheepshaver news (week 43)

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

Hi,

* The PowerPC emulator can now use the predecode cache. Performance 
improved only by 75% on average. I will probably merge in new code that 
can work with lazy PC updating. However, this would slow down 
performance by 4% on average but this is necessary for upcoming native 
code translation so that we don't generate two sets of handlers when 
resorting to fallbacks.

* There is stil at least one little endian bug preventing SheepShaver 
from running on x86 at this time.

* There is still a generic bug preventing SheepShaver from booting with 
extensions on in emulated mode. i.e. it either hangs around 'CD00'  
resource with MacOS 8.1 or 'CD17' resource with MacOS 8.6.

Yes, development is slow because weekends are too short. ;-)

Bye,
Gwenole.

[B2-devel] SheepShaver news

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

Hi,

1) I think I fixed the very last PPC alu emulation bug. Sadly, a 
copy-paste error propagated to ADDZE & ADDME decoders and wronly marked 
them to get RA_or_0 operand format. This brings a total of around 22K 
instruction variants that are now tested on typical values triggering 
various CR states.

2) After spending some time reading tons of logs, I determined that 
Execute68k() was not preserving the condition register under emulation 
whereas native implementations did. As a consequence, MacOS 8.6 finally 
works. ;-)

There are still a lot of ideas to implement and more importantly is to 
finish the little edian tidy up. Then, make it faster. As you can see 
on the 3rd capture I uploaded, ppc emulation (SheepShaver) vs. m68k 
emulation (Basilisk II) on the same machine (still a PBG4) yields non 
uniform & unexpected results. For example, FPU emulation seems to be 
fast. This is probably because I don't emulate the FPSR yet fully. ;-)

BTW, I still have to boot extensions off so that SheepShaver doesn't 
hang during some 'CDXX' resource installation. I have not determined 
the cause of this problem yet.

Bye,
Gwenole.

[B2-devel] Basilisk II for Darwin/X11

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

Hi,

Thanks to Michael Sliczniak, Basilisk II is fully building and working 
out-of-the-box under Darwin/X11 in real addressing mode. Code is now 
merged into CVS. Verified on Jaguar with Apple X11 server.

His interrogations remain: nanosleep() & semaphores stuff. I will try 
to have a look later.

Bye,
Gwenole.

Re: [B2-devel] PATCH: Darwin real mode

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

Hi,

> The patch for Darwin real mode under X is ready and attached. Please
> expand and untar the file under your BasiliskII directory. Then run
> the included patchall.sh script.

Thanks, I have started integration.

> In traditional Mach you do not get the GPR's and faulting PC on the 
> exception.
> It takes more work to get this info but it is not needed for the VOSF 
> code. I
> changed the VOSF handler to take the faulting address as it sole 
> parameter.
> This makes the common case, VOSF handling, faster under Mach.

It doesn't seem to be much faster on my system. Basically, I have 
disabled SIGSEGV_FAULT_INSTRUCTION for MacOS X to see the difference. I 
will see if I can come up with a decent solution for on-demand 
extraction of the fault instruction address. This may be needed for 
SheepShaver for example.

> At one point I noticed that if you had seriala or serialb in your
> .basilisk_ii_prefs file the emulator would hang.

Indeed, I noticed that too. However, the device files do exist, at 
least in the /dev/ system. Likewise for floppy stuff. I don't know why 
either. I will probably roll back to some timeout or one can come with 
an effective test so that default entries for those are not added and 
wrongly used.

Bye,
Gwenole.

Re: [B2-devel] MacOS 8.1/ppc boots ;-)

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

is this on a PPC native machine or X86 machine?

Thanks,
Hetz

On Sunday 28 September 2003 19:43, Gwenole Beauchesne wrote:
> Hi,
>
> I have just nuked two silly bugs in the interpreter and MacOS 8.1
> completely boots. I can even make some tests on my PBG4:
> <http://gwenole.beauchesne.free.fr/sheepshaver/> ;-)
>
> Yes, that's slow as I enabled only the interpreter and all sort of
> runtime checks in order to know who the hell did nuke the stack
> pointer. That turned out to be the interrupt handler. It sometimes
> happened that we were just lwz r1,XLM_IRQ_NEST and triggered an
> interrupt, henceforth generating and saving sp - 64 => something like
> 0xffffffc0.
>
> The current solution is probably slow but I put back the usual spcflags
> checking and introduced two new NativeOp so that XLM_IRQ_NEST is handed
> atomically, at least as seen in emulated ppc world.
>
> Concerning MacOS 8.6, it now tells me a system error occured.
> Unfortunately, it does not crash thus making more difficult to track
> down why we got there.
>
> Oh BTW, MacOS 8.1 is silly and tries to lmw on unaligned EA. This also
> happens in native mode. So, I don't know if MacOS 8.1 is the real
> problem or it is something introduced from SheepShaver.
>
> Bye,
> Gwenole.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel