Re: [B2-devel] Status of Mac OS X port?

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

Applied the MACH timer patch as well.

-Alexei

On Sat, Mar 5, 2011 at 10:40 AM, Joseph Oswald <jos...@gm...> wrote:
> On Mar 4, 2011, ast 9:07 PM, Charles Srstka wrote:
>> On Mar 4, 2011, at 11:50 AM, Joseph Oswald wrote:
>>
>> > 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible with the struct timeval chosen for tm_time_t. I can fix that, by converting tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be altered to pick struct timespec? Should I special case timer_unix.cpp to separate Mac OS X from other Mach targets?
>>
>> The tm_time_t should be a mach_timespec_t when __MACH__ is true. However, if you can improve the timer, go to town. That precise timer code has never worked as well as hoped, to the point where a lot of people have just been #ifdefing it out.
>>
>
> I don't know enough to tell whether the code works or not, but the
> attached patch to MacOSX/sysdeps.h allows it to use the
> mach_timespec_t
>
>> I don’t believe there are any other Mach targets other than Mac OS X currently in use.
>>
>> Charles
>
>>
>> Message: 7
>> Date: Fri, 4 Mar 2011 12:50:08 -0500
>> From: Joseph Oswald <jos...@gm...>
>> Subject: [B2-devel] Status of Mac OS X port?
>> To: bas...@li...
>> Message-ID:
>>        <AANLkTi=oYJ...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I have become interested in using Basilisk II to emulate a 68k macintosh on
>> my Intel MacBookPro, running 10.6.6.
>>
>> I have found a few binaries of various ages, from Gwenol? Beauchesne (via
>> archive.org) and from emaculation.net. However, I can't seem to replicate
>> these from source.
>>
>> 1) The src/MacOSX/configure script generated by autoconf is broken (it has
>> bad syntax after the egrep test). Applying a fix from the src/Unix fixes
>> this. (patch attached) FYI, this also is broken in the MacPorts
>> distribution, which I initially tried to use.
>>
>>  (minor quibble: my understanding of autoconf is for developers to run
>> autoconf, and for source distributions to include the resulting configure
>> scripts, which are portable. This avoids recipients from needing up-to-date
>> autoconf installations. autoupdate in autoconf 2.88 wanted to tweak a few
>> obsolete constructs in the MacOSX/configure.in)
>>
>> 2) nowrite.icns is required by PrefsEditor.mm, but is apparently not
>> included or generated by CVS head.
>>
>> 3) The target "make ide" described by the configure output seems not to
>> exist.
>>
>> 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible
>> with the struct timeval chosen for tm_time_t. I can fix that, by converting
>> tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other
>> Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be
>> altered to pick struct timespec? Should I special case timer_unix.cpp to
>> separate Mac OS X from other Mach targets?
>>
>> 5) Unix sshpty.c seems to have typos in the definition and use of the
>> fatal() macro. (Patch attached)
>>
>> 6) After fixing the fatal macro, I seem to need to force #define
>> HAVE_OPENPTY 1 to compile. I'm not sure what the correct solution is.
>>
>> 7) main_macosx.mm complains that the -psn_XXX command-line flag (with the
>> process ID) is not recognized. An attached patch skips this argument (I
>> don't know what it would be used for).
>>
>> Even after all of this, I get a hang with a black screen at startup. (I
>> initially started with a IIfx ROM, but switched to a Performa ROM based on
>> it working better with the binaries I downloaded.)
>>
>> Any comments? Does anyone maintain or build the Mac OS X port?
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>