basilisk-devel — Basilisk II development-related discussion

[B2-devel] Suggested patch for tap networking in SS/BII on 64 bit windows on emaculation

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

Hi all,

Some time ago a member of the e-maculation forum donated a patch for tap based networking in 64 bit windows.
I tried to compile a SheepShaver version with that patch, but it crashes as soon as started when set to use tap networking.

For anyone interested, the code is here: http://pastebin.com/G85pyNaG
The original post is here: http://www.emaculation.com/forum/viewtopic.php?f=20&t=7099

Best regards,
Howard
 		 	   		  

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Alexei S. <ale...@gm...>]

>
> > On 6/18/12, Jean-Pierre <cho...@fr...> wrote:
> >> I wrote a small patch to exchange text clipboard for the Mac OS X 64bit
> >> version when I worked on the 64bit Mach-O support, but It was never
> >> merged.Not sure if I ever submitted it either...
> >> If you want it let me know.
>
> Here you are.
>
> It's still incomplete, but it could be a good start for sharing pictures
> as well.
>
> Best regards,
>
>  -JP.
>

Thanks!

I've cleaned this up and committed this upstream as clip_macosx64.cpp (with
appropriate autoconf and Xcode changes):

https://github.com/cebix/macemu/commit/99e8914019907ac8d8a60e3341b853f5b9d7f8e2
https://github.com/cebix/macemu/commit/a40257b33aa4ecb3fd208ad9224c228affc2a8bd

-Alexei

Re: [B2-devel] PictViewer works on MacOS 10.6.8 (was: TESyncScrap...)

[Charles S. <bas...@ch...>]

On Jun 19, 2012, at 10:33 PM, Robert Munafo wrote:

> Thank you for saving me the effort of trying to learn all that
> Interface Builder stuff. Your PictViewer works fine. Here is a screen
> shot showing it after having opened a PICT file, which I then saved as
> TIFF, then opened the TIFF in Preview.
> 
> <links to personal webspace snipped>
> 
> I can also view the original PICT file in Preview, but oddly your
> version (and QuickView in the FInder) both procude a nicer,
> anti-aliased version of the label text, whereas Preview 5.0.3 gives
> rougher non-anti-aliased text.
> 
> I think that's because Quartz renders things with anti-aliasing
> (oversampling). There were older versions of Preview in older versions
> of MacOS X that did the anti-aliased rendering too, but for some
> reason Apple kept changing their mind about whether Preview should
> render PICTs with anti-aliasing.
> 
> So anyway, your code works!

Sweet! Hopefully you don’t mind me posting this back onto the list, but I thought it’d be worth letting the general populace know that NSImage is apparently more capable at reading PICTs than the libpaint-based solution, making it possibly worth a small bit of special-case code for OS X-based hosts.

Charles

Re: [B2-devel] Inline Assembly Query

[Alexander v. G. <kal...@un...>]

On 18.06.2012 23:18, Gwenole Beauchesne wrote:
> Hi,
>
> Le 19 juin 2012 à 02:27, Frank Trampe a écrit :
>
>> Given the high level of interest in improving SheepShaver, it seems like 
>> it might be good to get it to the point at which it compiles on newer 
>> versions of Mac O.S., which probably means getting the code to compile in 
>> clang-llvm.
>
> The JIT based on dyngen needs to be built with GCC. You can select the GCC 
> compiler to be used, see DYNGEN_CC
> variable.
>
> Here are the solutions for the PPC emulator, in increasing order of 
> complexity to implement:
>
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes 
> from that, or ship with pre-generated
> .{h,cpp} files that implement the opcodes for the supported target 
> architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will 
> suffer, migrate to a full-blown DBT engine
>
> I'd like to keep the dyngen-based generator for now as it would allow for 
> easy update for AVX1/AVX2 support. At some
> point, I was also working on a mix of dyngen + something similar to what 
> was implemented for QEMU (TCG).

I was actually looking into this for SheepShear... looks like a *big* 
undertaking though. qemu dropped the dyngen stuff
around 4 years ago.

At the moment i'm re-factoring all of the flat source files into classes (It 
should make moving to another emulation
core easier.)

https://github.com/kallisti5/sheepshear/commit/042f10a201a2dc3a17f52b3fa6144e03130552e2
https://github.com/kallisti5/sheepshear/blob/master/src/include/adb.h

https://github.com/kallisti5/sheepshear/commit/7af077b21e243b6f2ebc3b700d73e1b2c3af9674
https://github.com/kallisti5/sheepshear/blob/master/src/include/audio.h
https://github.com/kallisti5/sheepshear/blob/master/src/include/platform/Unix/platform_audio.h


  -- Alex

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Alexei S. <ale...@gm...>]

On Mon, Jun 18, 2012 at 3:50 PM, Jean-Pierre <cho...@fr...> wrote:

> Here you are.
>
> It's still incomplete, but it could be a good start for sharing pictures
> as well.
>
> Best regards,
>

Hey,

Nice work!

Would you be willing to clean up the patch a little and re-send it (on a
separate thread or via GitHub) for inclusion upstream?

Here are some of my thoughts on a couple of things that could be cleaned up:

  - indentation is inconsistent throughout
  - _CARBON_BUILD_ stuff: I understand that the purpose is to have separate
the two codepaths - but my question is: Is there anything preventing
switching completely to the new path that you've implemented? If it has
feature parity with the old code, we don't need to keep the old code around.

I'm looking forward to landing these changes upstream.

Thanks!

-Alexei

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Josh J. <jj...@gm...>]

On Jun 18, 2012, at 8:30 PM, Alexei Svitkine wrote:

> On Mon, Jun 18, 2012 at 9:06 PM, Josh Juran <jj...@gm...> wrote:
>
>> On Jun 18, 2012, at 3:51 PM, Alexei Svitkine wrote:
>>
>>> Assuming there's no good open source library to handle arbitrary
>>> PICT data,
>>> the solution here would be to add some functionality to TESyncScrap
>>> or a
>>> similar extension that would intercept clipboard data on the guest
>>> OS side
>>> and when it's a PICT, rasterize it into PICT bitmap-only data,
>>> putting that
>>> back on the guest clipboard.
>>
>> This would be a separate extension which patches PutScrap().
>>
>>> Then, when SheepShaver gets that data, the PICTs will be guaranteed
>>> to only
>>> have bitmap data, which could be handled by paintlib (or possibly
>>> even some
>>> simpler code we can just write for SheepShaver) which would then be
>>> easily
>>> convertible to the host OS clipboard format.
>>
>> I don't think replacing the PICT data is a good idea, since the pre-
>> rasterized picture would no longer be available to other Mac
>> applications.  But adding it as, say, 'Pict' or 'Bits' should work.
>
> I think that would be useful. If you store them in a separate data  
> type,
> then it doesn't have to be a PICT at all - maybe something even  
> simpler so
> we could process it from the SheepShaver side without needing any  
> library.

Something like

struct header
{
	uint16_t height;
	uint16_t width;
	uint16_t rowBytes;
	uint16_t format;
};

followed by raw pixel data?

> By the way, maybe the sources for these extensions should live in the
> SheepShaver repository? What do you think?

I think that depends on who's going to build them.[1]  Currently,  
they require Metrowerks CodeWarrior to build, since the C++ usage is  
beyond what MPW compilers can handle.[2]  If you don't want to rely  
on Metrowerks C++, I can rewrite in straight C for use with MPW's SC  
compiler, but MPW is no longer offered for download from Apple, so  
it's no more easily legally acquired than CodeWarrior is.

If you want something from which you can produce a binary using only  
free software, I can provide machine code in hex, annotated with the  
corresponding assembler instructions or even C code.  Converting that  
to a binary is quite simple, at least provided you can get it into a  
resource (which is easy in MacRelix: `cat code.68k > TESyncScrap/r/ 
0000.INIT`).

A third alternative is get GCC to build Mac code resources.  There's  
been at least two ports of GCC to MPW, so we might be able to reuse  
that effort.

An additional point to consider is that the system extensions I've  
written share a common library that non-trivially uses templates.   
Other developers might find a single source file of non-general code  
easier to maintain.

Let me know what you think.

Josh

[1] Actually, I don't think they should live in SheepShaver's repo in  
any case, since TESyncScrap at least is useful with any emulator (or  
none at all), and rather they might get repos of their own, which  
cebix is free to clone -- but this point is orthogonal to the more  
important issue of building from source.

[2] And that's not saying much.

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 11:18 PM, Gwenole Beauchesne wrote:

> The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.

Unfortunately, the latest version of the dev tools no longer includes GCC. It does have LLVM-GCC, which is the GCC interface on the LLVM back-end, and this chokes on the global registers, same as Clang.

I’ve managed to get SheepShaver to compile using GCC 4.7 from MacPorts, but it’s currently quitting on launch — the shmat call at main_unix.cpp line 1172 is failing with ENOMEM.

Charles

Re: [B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

On Mon, Jun 18, 2012 at 11:18 PM, Gwenole Beauchesne <gb....@fr...>wrote:

> Hi,
>
> Le 19 juin 2012 à 02:27, Frank Trampe a écrit :
>
> > Given the high level of interest in improving SheepShaver, it seems like
> it might be good to get it to the point at which it compiles on newer
> versions of Mac O.S., which probably means getting the code to compile in
> clang-llvm.
>
> The JIT based on dyngen needs to be built with GCC. You can select the GCC
> compiler to be used, see DYNGEN_CC variable.
>
> Okay. For curiousity's sake, though, what is the meaning of the $__op_
prefix in the asm syntax?


> Here are the solutions for the PPC emulator, in increasing order of
> complexity to implement:
>
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes
> from that, or ship with pre-generated .{h,cpp} files that implement the
> opcodes for the supported target architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will
> suffer, migrate to a full-blown DBT engine
>
> I'd like to keep the dyngen-based generator for now as it would allow for
> easy update for AVX1/AVX2 support. At some point, I was also working on a
> mix of dyngen + something similar to what was implemented for QEMU (TCG).
>
> Regards,
> Gwenole.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Inline Assembly Query

[Alexei S. <ale...@gm...>]

>
> Here are the solutions for the PPC emulator, in increasing order of
> complexity to implement:
>
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes
> from that, or ship with pre-generated .{h,cpp} files that implement the
> opcodes for the supported target architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will
> suffer, migrate to a full-blown DBT engine
>

4. Make clang/llvm support global registers ;)

-Alexei

Re: [B2-devel] Inline Assembly Query

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

Hi,

Le 19 juin 2012 à 02:27, Frank Trampe a écrit :

> Given the high level of interest in improving SheepShaver, it seems like it might be good to get it to the point at which it compiles on newer versions of Mac O.S., which probably means getting the code to compile in clang-llvm.

The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.

Here are the solutions for the PPC emulator, in increasing order of complexity to implement:

1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes from that, or ship with pre-generated .{h,cpp} files that implement the opcodes for the supported target architectures (x86, x86_64, etc.)
3. Rework the JIT: migrate to TCG but VMX emulation performance will suffer, migrate to a full-blown DBT engine

I'd like to keep the dyngen-based generator for now as it would allow for easy update for AVX1/AVX2 support. At some point, I was also working on a mix of dyngen + something similar to what was implemented for QEMU (TCG).

Regards,
Gwenole.

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Alexei S. <ale...@gm...>]

On Mon, Jun 18, 2012 at 9:06 PM, Josh Juran <jj...@gm...> wrote:

> On Jun 18, 2012, at 3:51 PM, Alexei Svitkine wrote:
>
> > On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...>
> > wrote:
> >
> >> In my scientific apps, written by me and running within SheepShaver,
> >> the clipboard PICT data includes a label with important
> >> information as
> >> text strings (DrawString). These label text strings need to survive
> >> the transfer to the host OS in order for cut/paste to be useful.
> >
> > Assuming there's no good open source library to handle arbitrary
> > PICT data,
> > the solution here would be to add some functionality to TESyncScrap
> > or a
> > similar extension that would intercept clipboard data on the guest
> > OS side
> > and when it's a PICT, rasterize it into PICT bitmap-only data,
> > putting that
> > back on the guest clipboard.
>
> This would be a separate extension which patches PutScrap().
>
> > Then, when SheepShaver gets that data, the PICTs will be guaranteed
> > to only
> > have bitmap data, which could be handled by paintlib (or possibly
> > even some
> > simpler code we can just write for SheepShaver) which would then be
> > easily
> > convertible to the host OS clipboard format.
>
> I don't think replacing the PICT data is a good idea, since the pre-
> rasterized picture would no longer be available to other Mac
> applications.  But adding it as, say, 'Pict' or 'Bits' should work.
>
> > This solution would then work cross-platform, instead of being tied
> > to Mac
> > OS X as the host.
>
> Shall I do this?
>

I think that would be useful. If you store them in a separate data type,
then it doesn't have to be a PICT at all - maybe something even simpler so
we could process it from the SheepShaver side without needing any library.

By the way, maybe the sources for these extensions should live in the
SheepShaver repository? What do you think?

-Alexei

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 7:39 PM, Charles Srstka wrote:

> On Jun 18, 2012, at 7:36 PM, Frank Trampe wrote:
> 
>> Standard MacPorts gcc failed last time I tried, although I cannot remember why.
> 
> The configure script fails when trying to figure out how to generate preprocessed output with GCC.

... Never mind, the preprocessor failure was due to me being a moron.  The real problem here is that abi::__cxa_demangle() seems to be always failing with error -2 when attempting to demangle the symbol names in cxxdemangle.c. Not sure why that’s happening just yet.

Charles

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Josh J. <jj...@gm...>]

On Jun 18, 2012, at 3:51 PM, Alexei Svitkine wrote:

> On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...>  
> wrote:
>
>> In my scientific apps, written by me and running within SheepShaver,
>> the clipboard PICT data includes a label with important  
>> information as
>> text strings (DrawString). These label text strings need to survive
>> the transfer to the host OS in order for cut/paste to be useful.
>
> Assuming there's no good open source library to handle arbitrary  
> PICT data,
> the solution here would be to add some functionality to TESyncScrap  
> or a
> similar extension that would intercept clipboard data on the guest  
> OS side
> and when it's a PICT, rasterize it into PICT bitmap-only data,  
> putting that
> back on the guest clipboard.

This would be a separate extension which patches PutScrap().

> Then, when SheepShaver gets that data, the PICTs will be guaranteed  
> to only
> have bitmap data, which could be handled by paintlib (or possibly  
> even some
> simpler code we can just write for SheepShaver) which would then be  
> easily
> convertible to the host OS clipboard format.

I don't think replacing the PICT data is a good idea, since the pre- 
rasterized picture would no longer be available to other Mac  
applications.  But adding it as, say, 'Pict' or 'Bits' should work.

> This solution would then work cross-platform, instead of being tied  
> to Mac
> OS X as the host.

Shall I do this?

Josh

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 7:36 PM, Frank Trampe wrote:

> Standard MacPorts gcc failed last time I tried, although I cannot remember why.

The configure script fails when trying to figure out how to generate preprocessed output with GCC.

Charles

Re: [B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

Standard MacPorts gcc failed last time I tried, although I cannot remember
why.

On Mon, Jun 18, 2012 at 7:34 PM, Charles Srstka <
bas...@ch...> wrote:

> On Jun 18, 2012, at 7:27 PM, Frank Trampe wrote:
>
> __op_PARAM1 is defined as a static or external and possibly signed integer
> (depending upon platform) in dyngen-exec.h. The operation is apparently
> (judging from the 32-bit branch) designed to stuff the value of __op_PARAM1
> (which is normally 32 bits but could be shorter or longer) into A0 (which
> is 64-bit on x86-64). I am not familiar with the __op_ token in asm and
> cannot find any information on it. Does anybody know what is happening
> here? Would it be unreasonable to allow the simple assignment if a long on
> the platform in question is the same size as the target register?
>
>
> I think the problem might actually be the global register variables A0,
> A1, A2, T0, T1, T2. LLVM doesn’t like those. This is what clang complains
> about if you try to compile with it instead of LLVM-GCC, at least.
>
> The easiest, if not the most satisfying, way to get BII/SS compiling on
> newer systems might be to get them to work with the various gcc ports
> available via MacPorts. I’ve been playing with that today, and getting
> sanity check errors in the configure script. Trying to figure out what’s
> going on there right now.
>
> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 7:27 PM, Frank Trampe wrote:

> __op_PARAM1 is defined as a static or external and possibly signed integer (depending upon platform) in dyngen-exec.h. The operation is apparently (judging from the 32-bit branch) designed to stuff the value of __op_PARAM1 (which is normally 32 bits but could be shorter or longer) into A0 (which is 64-bit on x86-64). I am not familiar with the __op_ token in asm and cannot find any information on it. Does anybody know what is happening here? Would it be unreasonable to allow the simple assignment if a long on the platform in question is the same size as the target register?

I think the problem might actually be the global register variables A0, A1, A2, T0, T1, T2. LLVM doesn’t like those. This is what clang complains about if you try to compile with it instead of LLVM-GCC, at least.

The easiest, if not the most satisfying, way to get BII/SS compiling on newer systems might be to get them to work with the various gcc ports available via MacPorts. I’ve been playing with that today, and getting sanity check errors in the configure script. Trying to figure out what’s going on there right now.

Charles

[B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

Given the high level of interest in improving SheepShaver, it seems like it
might be good to get it to the point at which it compiles on newer versions
of Mac O.S., which probably means getting the code to compile in clang-llvm.

The code (or at least the first bit of it) that breaks llvm is on line 79
of SheepShaver/src/kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp. It calls a
number of macros from that file and from other files, which I have
consolidated here: {
#define OPPROTO

#if SIZEOF_VOID_P == 4
typedef uint32 uintptr;
typedef int32 intptr;
#elif SIZEOF_VOID_P == 8
typedef uint64 uintptr;
typedef int64 intptr;
#else
#error "Unsupported size of pointer"
#endif

#if defined(__APPLE__) && defined(__MACH__)
static int __op_PARAM1, __op_PARAM2, __op_PARAM3;
#else
extern int __op_PARAM1, __op_PARAM2, __op_PARAM3;
#endif
#define PARAM1 ((long)(&__op_PARAM1))
#define PARAM2 ((long)(&__op_PARAM2))
#define PARAM3 ((long)(&__op_PARAM3))

#define REG_CPU            AREG0
#define REG_CPU_ID        AREG0_ID
#define REG_T0            AREG1
#define REG_T0_ID        AREG1_ID
#define REG_T1            AREG2
#define REG_T1_ID        AREG2_ID
#define REG_T2            AREG3
#define REG_T2_ID        AREG3_ID
#ifdef  AREG4
#define REG_T3            AREG4
#define REG_T3_ID        AREG4_ID

// This is what gives us A0 and A1 and A2.
#define DYNGEN_DEFINE_GLOBAL_REGISTER(REG) \
register uintptr A##REG asm(REG_T##REG); \
register uint32  T##REG asm(REG_T##REG)
DYNGEN_DEFINE_GLOBAL_REGISTER(0);
DYNGEN_DEFINE_GLOBAL_REGISTER(1);
DYNGEN_DEFINE_GLOBAL_REGISTER(2);

#if defined __x86_64__
#define MOV_AD_REG(PARAM, REG) asm volatile ("movabsq $__op_" #PARAM ",%0"
: "=r" (REG))
#else
#define MOV_AD_REG(PARAM, REG) REG = PARAM
#endif

#define DEFINE_OP(REG)                            \
void OPPROTO op_mov_ad_##REG##_im(void)            \
{                                                \
    MOV_AD_REG(PARAM1, REG);                    \
}
}.

The problematic line is {
DEFINE_OP(A0);
} and seems to expand to {
void op_mov_ad_A0_im(void) {
asm volatile ("movabsq $__op_" ((long)(&__op_PARAM1)) ",%0" : "=r" (A0)) ;
}
}.

__op_PARAM1 is defined as a static or external and possibly signed integer
(depending upon platform) in dyngen-exec.h. The operation is apparently
(judging from the 32-bit branch) designed to stuff the value of __op_PARAM1
(which is normally 32 bits but could be shorter or longer) into A0 (which
is 64-bit on x86-64). I am not familiar with the __op_ token in asm and
cannot find any information on it. Does anybody know what is happening
here? Would it be unreasonable to allow the simple assignment if a long on
the platform in question is the same size as the target register?

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On 19/06/2012, at 4:27 AM, Frank Trampe wrote:
> 
> If you complained about the sharp-edged aluminum casings that scratch themselves and other things at the slightest provocation

I actually like the sharp edges on my MB Air -
often rub a finger along it in-between typing!

There is a slight ding on one edge,
but it can easily be filed or sanded off,
and you get used to disposability on portable computers.




I do wish a lot of things in the OS were
still like they were in 10.3.9 days, though.

--
Nigel Pearson           |"Now the world has gone to bed.|
ni...@in...  | Darkness won't engulf my head.|
Telstra Sydney Australia| I can see by infrared.        |
8576 5449, fax 9298 9033| How I hate the night." -Marvin|

Re: [B2-devel] BasiliskII compilation issues

[Alexei S. <ale...@gm...>]

Excellent!

On Mon, Jun 18, 2012 at 7:32 PM, Giulio Paci <giu...@gm...> wrote:

> Il 16/06/2012 20:36, Alexei Svitkine ha scritto:
> >
> >
> > On Sat, Jun 16, 2012 at 2:34 PM, Giulio Paci <giu...@gm...
> > <mailto:giu...@gm...>> wrote:
> >
> >     Il 16/06/2012 08:36, Robert Munafo ha scritto:
> >     > What we need is someone who has a computer with this problem, and
> who
> >     > is also able to figure out how to get it to build (and run!), who
> can
> >     > tell us how the configure.ac <http://configure.ac> needs to change
> >     so that it will work
> >     > properly without any manual temporary patch.
> >
> >     Yes, unfortunately this is my first time with a Debian with freebsd
> >     kernel, so I am still not able to run Xorg on my virtual machine.
> >     If anybody is interested I can share the VM anyway: I have no private
> >     data there, just the Basilisk requirements.
> >
> >
> > Can you let me know whether my changes fixed the compilation error?
>
> Just checked and they did.
> I was also able to start BasiliskII and it seems to work.
>
> Thank you very much for your work.
> Giulio.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Fix crashes with SDL on linux

[Alexei S. <ale...@gm...>]

Thanks!

Committed upstream:

https://github.com/cebix/macemu/commit/be28a8e5d40e3db69e446da69de3f9f004340932

-Alexei

On Mon, Jun 18, 2012 at 5:07 AM, Amadeusz Sławiński <am...@as...>wrote:

> When I do ./configure --enable-sdl-video --enable-sdl-audio SheepShaver
> crashes sooner or later after being started (usually before even ending
> booting). I narrowed it down to be caused by changing cursors.
>
> Some example of crashes:
>
> SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
> Reading ROM file...
> Using SDL/alsa audio output
> Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
> PowerPC CPU emulator by Gwenole Beauchesne
> WARNING: Unknown DiskStatus(6)
> WARNING: Unknown DiskStatus(6)
> SheepShaver: Fatal IO error 11 (Resource temporarily unavailable) on X
> server :0.
> Illegal instruction at 00002400, opcode = 000108c4
> zsh: abort      ./SheepShaver
>
>
> SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
> Reading ROM file...
> Using SDL/alsa audio output
> Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
> PowerPC CPU emulator by Gwenole Beauchesne
> WARNING: Unknown DiskStatus(6)
> WARNING: Unknown DiskStatus(6)
> SheepShaver: Fatal IO error 11 (Resource temporarily unavailable) on X
> server :0.
> SIGSEGV
>  pc 0x45fc36
>  ea 0x3dbc
>  r0 03e00000   r1 01bffe00   r2 00000000   r3 00000000
>  r4 41a67ab6   r5 00000000   r6 00000028   r7 000000b8
>  r8 00000020   r9 00000000  r10 00000000  r11 00000001
> r12 0000e38e  r13 0000ffff  r14 00000000  r15 499a0000
> r16 419c54ea  r17 4d997082  r18 4d997082  r19 41ab9cbc
> r20 4d997028  r21 4d9a2190  r22 41ab9cac  r23 00000000
> r24 41a67ab6  r25 00000000  r26 fffffffe  r27 000021ee
> r28 41b3df34  r29 51ed1170  r30 51e60000  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 51e6d6e0  ctr 00000000   cr 40000088  xer 00000000
>  pc 00003dbc fpscr 00000000
>  0x    3d9c:  zsh: segmentation fault  ./SheepShaver
>
> Configured with is a bit more informative
> ./configure --enable-sdl-video --enable-sdl-audio --disable-vosf
>
> SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
> Reading ROM file...
> Using SDL/alsa audio output
> Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
> PowerPC CPU emulator by Gwenole Beauchesne
> WARNING: Unknown DiskStatus(6)
> WARNING: Unknown DiskStatus(6)
> WARNING: Unknown DiskStatus(6)
> WARNING: Unknown DiskStatus(6)
> [xcb] Unknown request in queue while dequeuing
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not
> been called
> [xcb] Aborting, sorry about that.
> SheepShaver:
> /var/tmp/portage/x11-libs/libX11-1.5.0/work/libX11-1.5.0/src/xcb_io.c:178:
> dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
> zsh: abort      ./SheepShaver
>
> So with attached patch it works fine, I tested it only on 64bit linux.
>
> Amadeusz
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Il 16/06/2012 20:36, Alexei Svitkine ha scritto:
> 
> 
> On Sat, Jun 16, 2012 at 2:34 PM, Giulio Paci <giu...@gm...
> <mailto:giu...@gm...>> wrote:
> 
>     Il 16/06/2012 08:36, Robert Munafo ha scritto:
>     > What we need is someone who has a computer with this problem, and who
>     > is also able to figure out how to get it to build (and run!), who can
>     > tell us how the configure.ac <http://configure.ac> needs to change
>     so that it will work
>     > properly without any manual temporary patch.
> 
>     Yes, unfortunately this is my first time with a Debian with freebsd
>     kernel, so I am still not able to run Xorg on my virtual machine.
>     If anybody is interested I can share the VM anyway: I have no private
>     data there, just the Basilisk requirements.
> 
> 
> Can you let me know whether my changes fixed the compilation error?

Just checked and they did.
I was also able to start BasiliskII and it seems to work.

Thank you very much for your work.
Giulio.

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[C.W. B. <mad...@gm...>]

Actually, it's probably happening in the pasteboard server. The Cocoa pasteboard can have multiple types of data in it, and some formats can be converted natively under Cocoa. In fact, the gimp-macclipboard did this to convert TIFFs to PICTs.
On Jun 18, 2012, at 1:05 PM, Robert Munafo wrote:

> On 6/18/12, Charles Srstka <bas...@ch...> wrote:
>> Are there any OS X / Windows apps that currently accept pasteboard data in
>> PICT format though?
> 
> No, that's why SheepShaver converts it. Here are the steps, to make it clear:
> 
> 1. I start SheepShaver, and start my old app within SheepShaver.
> 2. Copy to clipboard.
> 3. Switch to Snow Leopard's TextEdit, hit Paste.
> 4. I get my image, with the original bitmap image and the label text
> nicely rendered below it.
> 
> Somewhere in the process (SheepShaver and/or TextEdit) it has turned
> the PICT, including the label text, into a TIFF image.
> 
> The text is there because something in the Carbon libraries is making
> it happen. But it we use that stand-alone PICT conversion library
> instead of Carbon, the text label would be missing.
> 
> -- 
>  Robert Munafo  --  mrob.com
>  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 

Re: [B2-devel] git!

[Alexei S. <ale...@gm...>]

Seems to work, thanks!

On Mon, Jun 18, 2012 at 2:39 PM, Christian Bauer <cb...@ce...> wrote:

> Hi!
>
> On 06/16/2012 07:38 PM, Alexei Svitkine wrote:
> > Can you create a new GitHub repo containing both SS and BasiliskII
> > sources from the CVS TOT and add me as a collaborator?
>
> Let me know whether this works for you:
> https://github.com/cebix/macemu
>
> Bye,
> Christian
>
> --
>   / Physics is an algorithm
> \/ www.cebix.net
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[C.W. B. <com...@ho...>]

Just to clarify, you can run 32-bit apps under a 64-bit kernel under OS X. For instance, I have Skype running on my 64-bit kernel Lion installation and that is only 32-bit right now. You can't run 32-bit Kernel Extensions on a 64-bit kernel, though. The reverse is also true: You can run 64-bit apps on a 32-bit Mac kernel (If you have a 64-bit processor). My server, a 2007 Mac mini is unable to boot into 64-bit kernel mode but still runs 64-bit programs just fine.
On Jun 18, 2012, at 12:05 PM, Robert Munafo wrote:

> Wow, Frank, this is cool! I love being wrong this way.
> 
> (I feel like if I keep saying things that I hate about Apple, you'll
> keep telling me I'm wrong :-)
> 
> I found some examples of people booting Lion in 32-bit mode:
> 
>  https://discussions.apple.com/thread/3225388?start=0&tstart=0
>  https://discussions.apple.com/thread/3943837?start=0&tstart=0
> 
> So does that mean we can boot Lion in 32-bit mode and run 32-bit
> SheepShaver and get a working copy and paste?
> 
> I hope so... then maybe I'll actually try out that copy of Lion I
> bought last winter for $30. PICT files and SheepShaver cut/paste were
> holding me back. (Also the lack of Save and Revert commands in the
> standard suite, what were they thinking? Oops, I'm complaining again.
> Please tell me I'm wrong.)
> 
> On 6/18/12, Frank Trampe <fra...@gm...> wrote:
>> Not exactly. Certain kernel-related things must run in 64-bit mode, but
>> there is still i386 support.
>> 
>> {
>> cambridge:~ admin$ uname -v
>> Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012;
>> root:xnu-1699.26.8~1/RELEASE_X86_64
>> cambridge:~ admin$ file /mach_kernel
>> /mach_kernel: Mach-O universal binary with 2 architectures
>> /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
>> /mach_kernel (for architecture i386): Mach-O executable i386
>> }
> 
> -- 
>  Robert Munafo  --  mrob.com
>  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 5:51 PM, Alexei Svitkine wrote:

> On Mon, Jun 18, 2012 at 2:38 PM, Robert Munafo <mr...@gm...> wrote:
> In my scientific apps, written by me and running within SheepShaver,
> the clipboard PICT data includes a label with important information as
> text strings (DrawString). These label text strings need to survive
> the transfer to the host OS in order for cut/paste to be useful.
> 
> Assuming there's no good open source library to handle arbitrary PICT data, the solution here would be to add some functionality to TESyncScrap or a similar extension that would intercept clipboard data on the guest OS side and when it's a PICT, rasterize it into PICT bitmap-only data, putting that back on the guest clipboard.
> 
> Then, when SheepShaver gets that data, the PICTs will be guaranteed to only have bitmap data, which could be handled by paintlib (or possibly even some simpler code we can just write for SheepShaver) which would then be easily convertible to the host OS clipboard format.
> 
> This solution would then work cross-platform, instead of being tied to Mac OS X as the host.


Alternatively, depending on how well the NSImage-based functionality turns out to work for Robert’s specialized PICT files, we could use the host OS functionality on OS X, and use the libpaint/other library/homespun code for the other targets, which would result in one less library requirement for the OS X port, which is nice.

Charles