basilisk-devel — Basilisk II development-related discussion

[B2-devel] Video in 24-bit addressing mode

[Simon F. <sg...@ar...>]

Hi.

I'm trying to use Basilisk II to emulate a Mac Classic - I want to emulate
a Mac running in 24-bit mode. My attempts to make it work using unpatched
source didn't work. I'm not sure how it's intended to work, but I saw:

const uint32 MacFrameBaseMac = 0xa0000000;

in cpu_emulation.h. In 24-bit mode this aliases with 0x000000, and on the
Classic the framebuffer is expected to live at 0x3fa700.

Given this, I'm not sure how the display is expected to work in Basilisk II
for a Classic or other 24-bit mode Macs. I've created a patch to make the
Classic framebuffer work (and it boots up 6.0.8 ok). However, I wanted to
check if I've missed something silly, and if there's just a flag I should
be specifying to make it work. If not, what's the appropriate way to
suggest a patch?

Thanks,
Simon.

Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

[Ricky Z. <zha...@gm...>]

I'm reading Basilisk II memory addressing code.

I found that the configure script determine that modern Mac OS X didn't
support segfault handler. Therefore it disable VOSF.

So I wonder if BII uses SDL without VOSF, how can BII move Video screen
data from guest OS to host by SDL?

TIA
Ricky

Re: [B2-devel] Rudimentary port to SDL2

[Ricky Z. <zha...@gm...>]

That sounds a good plan. I will update this in your git repo #10 issue.

thanks,
Ricky


> On Aug 13, 2017, at 2:10 PM, David Ludwig <dl...@po...> wrote:
> 
> What about using, or just allowing, a combination of the following, for high-res monitors?:
> 
> 1. use aspect-correct scaling, with the displayed size being the same ratio as the emulated screen's size. If the native screen was a different aspect ratio, then employ solid-color bars on the appropriate sides.  I.e. use letter-boxing where appropriate.
> 
> 2. have an option to only scale up/down in non-fractional amounts.  When doing so, be sure to disable anti-aliasing (*).  This should, in theory, allow for non-blurred pixels.
> 
> * - nowadays, SDL pretty much always uses either OpenGL or D3D, behind-the-scenes.
> 
> On Sun, Aug 13, 2017 at 1:39 PM, Ricky Zhang <zha...@gm...> wrote:
> Regarding to the preference part in UI or in ~/.basilisk_ii_prefs, it is a piece of cake. I can help you for this.
> 
> But I’m not sure we are on the same page regarding to up scaling.
> 
> In current implementation i.e SDL v1, I can make BII in full screen mode in Mac OS X under 1920x1080 resolution. IMO, stretching always don’t look great in full screen mode. I have 21:9 screen. I feel the pain when playing low-res vintage game in full screen mode. If it is stretched ,it get distorted. If it is not, it is way too small to see.
> 
> So I wonder what need to be done to up scale the guest OS properly either in windows mode or in full screen mode under hi-res monitor. I’m 30 something now. I can image that if I grow older and have far sighted issue, I will have trouble to see the text or play game even under hi-res monitor. 
> 
> I believe up-scaling is applying some sort of filter on the original frame. It may not need SDL v2 to do the trick though if acceleration is not needed.
> 
> I’m glad that you start an initiative to port SDL2 to BII. But in order to convince the folks to upgrade, we’d better have a killing features.
> 
> 
>> On Aug 13, 2017, at 12:18 PM, David Ludwig <dl...@po...> wrote:
>> 
>> Side note to point #1, regarding aspect ratio: the scaling only works, at present, in fullscreen mode.  A means to scale in windowed mode might be nice, although, I suspect it could require either a new setting, or a modification to the "screen" setting's syntax.
>> 
>> On Sun, Aug 13, 2017 at 12:16 PM, David Ludwig <dl...@po...> wrote:
>> The SDL2 port should, in theory, already be scaling the guest OS' resolution up to the host OS', albeit only in fullscreen mode.  What it doesn't do, however, is:
>> 
>> 1. maintain aspect ratio.  It'll stretch the guest OS' display to match the host OS'.  SDL2 does have functionality to help with this, though.
>> 
>> 2. use anti-aliasing when either of the scaling ratios have fractional components.  This seems like an easy enough add, though.
>> 
>> I'll record TODOs/issues for both of these, at my port's repo (at https://github.com/davidludwig/macemu).
>> 
>> 
>> On Sat, Aug 12, 2017 at 8:25 AM, Ricky Zhang <zha...@gm...> wrote:
>> Thanks for sharing this! This will be a superb work to renovate BII.
>> 
>> I don’t mean to hijack your thread. But since you touch SDL2 topic, I wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor nowadays, I think the font size and game screen is way too small.
>> 
>> I know that mini Mac has zoom 2X feature. My educated guess is that the zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then zoom 2 X is to draw a 2X2 matrix:
>> 
>> [x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
>> [x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]
>> 
>> I can imagine in some cases it won’t looks good. Thus, we need to smooth it with anti-aliasing. But this is beyond my expertise.
>> 
>> If anyone has insight to solve this problem in hi-res, please let me know.
>> 
>> thanks,
>> Ricky
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Rudimentary port to SDL2

[Ricky Z. <zha...@gm...>]

That sounds a good plan. I will update this in your git repo #10 issue.

thanks,
Ricky


> On Aug 13, 2017, at 2:10 PM, David Ludwig <dl...@po...> wrote:
> 
> What about using, or just allowing, a combination of the following, for high-res monitors?:
> 
> 1. use aspect-correct scaling, with the displayed size being the same ratio as the emulated screen's size. If the native screen was a different aspect ratio, then employ solid-color bars on the appropriate sides.  I.e. use letter-boxing where appropriate.
> 
> 2. have an option to only scale up/down in non-fractional amounts.  When doing so, be sure to disable anti-aliasing (*).  This should, in theory, allow for non-blurred pixels.
> 
> * - nowadays, SDL pretty much always uses either OpenGL or D3D, behind-the-scenes.
> 
> On Sun, Aug 13, 2017 at 1:39 PM, Ricky Zhang <zha...@gm...> wrote:
> Regarding to the preference part in UI or in ~/.basilisk_ii_prefs, it is a piece of cake. I can help you for this.
> 
> But I’m not sure we are on the same page regarding to up scaling.
> 
> In current implementation i.e SDL v1, I can make BII in full screen mode in Mac OS X under 1920x1080 resolution. IMO, stretching always don’t look great in full screen mode. I have 21:9 screen. I feel the pain when playing low-res vintage game in full screen mode. If it is stretched ,it get distorted. If it is not, it is way too small to see.
> 
> So I wonder what need to be done to up scale the guest OS properly either in windows mode or in full screen mode under hi-res monitor. I’m 30 something now. I can image that if I grow older and have far sighted issue, I will have trouble to see the text or play game even under hi-res monitor. 
> 
> I believe up-scaling is applying some sort of filter on the original frame. It may not need SDL v2 to do the trick though if acceleration is not needed.
> 
> I’m glad that you start an initiative to port SDL2 to BII. But in order to convince the folks to upgrade, we’d better have a killing features.
> 
> 
>> On Aug 13, 2017, at 12:18 PM, David Ludwig <dl...@po...> wrote:
>> 
>> Side note to point #1, regarding aspect ratio: the scaling only works, at present, in fullscreen mode.  A means to scale in windowed mode might be nice, although, I suspect it could require either a new setting, or a modification to the "screen" setting's syntax.
>> 
>> On Sun, Aug 13, 2017 at 12:16 PM, David Ludwig <dl...@po...> wrote:
>> The SDL2 port should, in theory, already be scaling the guest OS' resolution up to the host OS', albeit only in fullscreen mode.  What it doesn't do, however, is:
>> 
>> 1. maintain aspect ratio.  It'll stretch the guest OS' display to match the host OS'.  SDL2 does have functionality to help with this, though.
>> 
>> 2. use anti-aliasing when either of the scaling ratios have fractional components.  This seems like an easy enough add, though.
>> 
>> I'll record TODOs/issues for both of these, at my port's repo (at https://github.com/davidludwig/macemu).
>> 
>> 
>> On Sat, Aug 12, 2017 at 8:25 AM, Ricky Zhang <zha...@gm...> wrote:
>> Thanks for sharing this! This will be a superb work to renovate BII.
>> 
>> I don’t mean to hijack your thread. But since you touch SDL2 topic, I wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor nowadays, I think the font size and game screen is way too small.
>> 
>> I know that mini Mac has zoom 2X feature. My educated guess is that the zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then zoom 2 X is to draw a 2X2 matrix:
>> 
>> [x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
>> [x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]
>> 
>> I can imagine in some cases it won’t looks good. Thus, we need to smooth it with anti-aliasing. But this is beyond my expertise.
>> 
>> If anyone has insight to solve this problem in hi-res, please let me know.
>> 
>> thanks,
>> Ricky
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Rudimentary port to SDL2

[David L. <dl...@po...>]

What about using, or just allowing, a combination of the following, for
high-res monitors?:

1. use aspect-correct scaling, with the displayed size being the same ratio
as the emulated screen's size. If the native screen was a different aspect
ratio, then employ solid-color bars on the appropriate sides.  I.e. use
letter-boxing where appropriate.

2. have an option to only scale up/down in non-fractional amounts.  When
doing so, be sure to disable anti-aliasing (*).  This should, in theory,
allow for non-blurred pixels.

* - nowadays, SDL pretty much always uses either OpenGL or D3D,
behind-the-scenes.

On Sun, Aug 13, 2017 at 1:39 PM, Ricky Zhang <zha...@gm...>
wrote:

> Regarding to the preference part in UI or in ~/.basilisk_ii_prefs, it is a
> piece of cake. I can help you for this.
>
> But I’m not sure we are on the same page regarding to up scaling.
>
> In current implementation i.e SDL v1, I can make BII in full screen mode
> in Mac OS X under 1920x1080 resolution. IMO, stretching always don’t look
> great in full screen mode. I have 21:9 screen. I feel the pain when playing
> low-res vintage game in full screen mode. If it is stretched ,it get
> distorted. If it is not, it is way too small to see.
>
> So I wonder what need to be done to up scale the guest OS properly either
> in windows mode or in full screen mode under hi-res monitor. I’m 30
> something now. I can image that if I grow older and have far sighted issue,
> I will have trouble to see the text or play game even under hi-res monitor.
>
> I believe up-scaling is applying some sort of filter on the original
> frame. It may not need SDL v2 to do the trick though if acceleration is not
> needed.
>
> I’m glad that you start an initiative to port SDL2 to BII. But in order to
> convince the folks to upgrade, we’d better have a killing features.
>
>
> On Aug 13, 2017, at 12:18 PM, David Ludwig <dl...@po...> wrote:
>
> Side note to point #1, regarding aspect ratio: the scaling only works, at
> present, in fullscreen mode.  A means to scale in windowed mode might be
> nice, although, I suspect it could require either a new setting, or a
> modification to the "screen" setting's syntax.
>
> On Sun, Aug 13, 2017 at 12:16 PM, David Ludwig <dl...@po...> wrote:
>
>> The SDL2 port should, in theory, already be scaling the guest OS'
>> resolution up to the host OS', albeit only in fullscreen mode.  What it
>> doesn't do, however, is:
>>
>> 1. maintain aspect ratio.  It'll stretch the guest OS' display to match
>> the host OS'.  SDL2 does have functionality to help with this, though.
>>
>> 2. use anti-aliasing when either of the scaling ratios have fractional
>> components.  This seems like an easy enough add, though.
>>
>> I'll record TODOs/issues for both of these, at my port's repo (at
>> https://github.com/davidludwig/macemu).
>>
>>
>> On Sat, Aug 12, 2017 at 8:25 AM, Ricky Zhang <zha...@gm...>
>> wrote:
>>
>>> Thanks for sharing this! This will be a superb work to renovate BII.
>>>
>>> I don’t mean to hijack your thread. But since you touch SDL2 topic, I
>>> wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor
>>> nowadays, I think the font size and game screen is way too small.
>>>
>>> I know that mini Mac has zoom 2X feature. My educated guess is that the
>>> zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then
>>> zoom 2 X is to draw a 2X2 matrix:
>>>
>>> [x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
>>> [x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]
>>>
>>> I can imagine in some cases it won’t looks good. Thus, we need to smooth
>>> it with anti-aliasing. But this is beyond my expertise.
>>>
>>> If anyone has insight to solve this problem in hi-res, please let me
>>> know.
>>>
>>> thanks,
>>> Ricky
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>
>>
>>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Rudimentary port to SDL2

[Ricky Z. <zha...@gm...>]

Regarding to the preference part in UI or in ~/.basilisk_ii_prefs, it is a piece of cake. I can help you for this.

But I’m not sure we are on the same page regarding to up scaling.

In current implementation i.e SDL v1, I can make BII in full screen mode in Mac OS X under 1920x1080 resolution. IMO, stretching always don’t look great in full screen mode. I have 21:9 screen. I feel the pain when playing low-res vintage game in full screen mode. If it is stretched ,it get distorted. If it is not, it is way too small to see.

So I wonder what need to be done to up scale the guest OS properly either in windows mode or in full screen mode under hi-res monitor. I’m 30 something now. I can image that if I grow older and have far sighted issue, I will have trouble to see the text or play game even under hi-res monitor. 

I believe up-scaling is applying some sort of filter on the original frame. It may not need SDL v2 to do the trick though if acceleration is not needed.

I’m glad that you start an initiative to port SDL2 to BII. But in order to convince the folks to upgrade, we’d better have a killing features.


> On Aug 13, 2017, at 12:18 PM, David Ludwig <dl...@po...> wrote:
> 
> Side note to point #1, regarding aspect ratio: the scaling only works, at present, in fullscreen mode.  A means to scale in windowed mode might be nice, although, I suspect it could require either a new setting, or a modification to the "screen" setting's syntax.
> 
> On Sun, Aug 13, 2017 at 12:16 PM, David Ludwig <dl...@po... <mailto:dl...@po...>> wrote:
> The SDL2 port should, in theory, already be scaling the guest OS' resolution up to the host OS', albeit only in fullscreen mode.  What it doesn't do, however, is:
> 
> 1. maintain aspect ratio.  It'll stretch the guest OS' display to match the host OS'.  SDL2 does have functionality to help with this, though.
> 
> 2. use anti-aliasing when either of the scaling ratios have fractional components.  This seems like an easy enough add, though.
> 
> I'll record TODOs/issues for both of these, at my port's repo (at https://github.com/davidludwig/macemu <https://github.com/davidludwig/macemu>).
> 
> 
> On Sat, Aug 12, 2017 at 8:25 AM, Ricky Zhang <zha...@gm... <mailto:zha...@gm...>> wrote:
> Thanks for sharing this! This will be a superb work to renovate BII.
> 
> I don’t mean to hijack your thread. But since you touch SDL2 topic, I wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor nowadays, I think the font size and game screen is way too small.
> 
> I know that mini Mac has zoom 2X feature. My educated guess is that the zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then zoom 2 X is to draw a 2X2 matrix:
> 
> [x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
> [x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]
> 
> I can imagine in some cases it won’t looks good. Thus, we need to smooth it with anti-aliasing. But this is beyond my expertise.
> 
> If anyone has insight to solve this problem in hi-res, please let me know.
> 
> thanks,
> Ricky
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> _______________________________________________
> basilisk-devel mailing list
> bas...@li... <mailto:bas...@li...>
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel <https://lists.sourceforge.net/lists/listinfo/basilisk-devel>
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Rudimentary port to SDL2

[David L. <dl...@po...>]

Side note to point #1, regarding aspect ratio: the scaling only works, at
present, in fullscreen mode.  A means to scale in windowed mode might be
nice, although, I suspect it could require either a new setting, or a
modification to the "screen" setting's syntax.

On Sun, Aug 13, 2017 at 12:16 PM, David Ludwig <dl...@po...> wrote:

> The SDL2 port should, in theory, already be scaling the guest OS'
> resolution up to the host OS', albeit only in fullscreen mode.  What it
> doesn't do, however, is:
>
> 1. maintain aspect ratio.  It'll stretch the guest OS' display to match
> the host OS'.  SDL2 does have functionality to help with this, though.
>
> 2. use anti-aliasing when either of the scaling ratios have fractional
> components.  This seems like an easy enough add, though.
>
> I'll record TODOs/issues for both of these, at my port's repo (at
> https://github.com/davidludwig/macemu).
>
>
> On Sat, Aug 12, 2017 at 8:25 AM, Ricky Zhang <zha...@gm...>
> wrote:
>
>> Thanks for sharing this! This will be a superb work to renovate BII.
>>
>> I don’t mean to hijack your thread. But since you touch SDL2 topic, I
>> wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor
>> nowadays, I think the font size and game screen is way too small.
>>
>> I know that mini Mac has zoom 2X feature. My educated guess is that the
>> zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then
>> zoom 2 X is to draw a 2X2 matrix:
>>
>> [x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
>> [x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]
>>
>> I can imagine in some cases it won’t looks good. Thus, we need to smooth
>> it with anti-aliasing. But this is beyond my expertise.
>>
>> If anyone has insight to solve this problem in hi-res, please let me know.
>>
>> thanks,
>> Ricky
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>

Re: [B2-devel] Rudimentary port to SDL2

[David L. <dl...@po...>]

The SDL2 port should, in theory, already be scaling the guest OS'
resolution up to the host OS', albeit only in fullscreen mode.  What it
doesn't do, however, is:

1. maintain aspect ratio.  It'll stretch the guest OS' display to match the
host OS'.  SDL2 does have functionality to help with this, though.

2. use anti-aliasing when either of the scaling ratios have fractional
components.  This seems like an easy enough add, though.

I'll record TODOs/issues for both of these, at my port's repo (at
https://github.com/davidludwig/macemu).


On Sat, Aug 12, 2017 at 8:25 AM, Ricky Zhang <zha...@gm...>
wrote:

> Thanks for sharing this! This will be a superb work to renovate BII.
>
> I don’t mean to hijack your thread. But since you touch SDL2 topic, I
> wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor
> nowadays, I think the font size and game screen is way too small.
>
> I know that mini Mac has zoom 2X feature. My educated guess is that the
> zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then
> zoom 2 X is to draw a 2X2 matrix:
>
> [x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
> [x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]
>
> I can imagine in some cases it won’t looks good. Thus, we need to smooth
> it with anti-aliasing. But this is beyond my expertise.
>
> If anyone has insight to solve this problem in hi-res, please let me know.
>
> thanks,
> Ricky
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

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

On Jul 24, 2017, at 2:27 PM, Brian J. Johnson via basilisk-devel <bas...@li...> wrote:

> That's a fairly good description of VOSF.

Thanks!  

> IIRC, BII keeps the emulated framebuffer RAM read-only

Ah, in that case taking a screenshot by reading framebuffer memory shouldn’t be a problem.

> That tends to be faster than comparing the entire framebuffer with a copy of the previous one, and than copying the entire framebuffer on each frame.

I’m working on a Mac OS emulator, Advanced Mac Substitute: <https://www.v68k.org/ams/>  The emulator memory-maps a disk file for a framebuffer to draw into, and actually displaying it is done by another program in a separate process.  The mmapped file contains an interprocess condition variable which is used for synchronization, allowing the display program to remain idle until the framebuffer is modified.

At the moment, there’s no optimization to exclude untouched screen regions during update.  The big performance win is batching multiple screen writes into a single update.  AMS doesn’t run Apple’s Mac OS, but a reimplementation of it, which knows how to call the emulator’s runtime library to lock the screen temporarily.  Not only does a primitive like FrameRect() draw atomically, but so does MoveWindow().

> Writing framebuffer memory to the screen is a somewhat expensive operation, due to the unusual framebuffer formats used by MacOS, and the desire to emulate low-color (1 to 8 bit) video modes on modern 24-bit display hardware.

AMS only supports monochrome graphics at the moment, so I can’t test the performance of different depths and configurations yet.  But I suspect transcoding a bitmap is a minuscule cost compared to getting it into a window on OS X.  On a Raspberry Pi, the display process transcodes and draws to the Linux framebuffer using a small fraction of the CPU used by the emulator, whereas on OS X the display system tends to use more CPU than the emulator (for relatively simple operations like byte-aligned CopyBits()).

> But it's been a *long* time since I messed with this code....  The performance tradeoffs may have changed in the interim.

If I were going to address macemu performance, I’d start with filesystem I/O, as that’s a major bottleneck for compiling.  Though first I’d fix the bug that makes extfs incompatible with MPW (since extfs is about an order of magnitude faster than using a disk image).

Josh

Re: [B2-devel] Rudimentary port to SDL2

[Ricky Z. <zha...@gm...>]

Thanks for sharing this! This will be a superb work to renovate BII.

I don’t mean to hijack your thread. But since you touch SDL2 topic, I wonder how to make it looks nicer in hi-res monitor. Even in 2K monitor nowadays, I think the font size and game screen is way too small.

I know that mini Mac has zoom 2X feature. My educated guess is that the zoom implement this way — If there is a pixel like [x, y, RGB(r,g,b)], then zoom 2 X is to draw a 2X2 matrix:

[x, y, RGB(r,g,b)],     [x+1, y, RGB(r,g,b)]
[x, y+1, RGB(r,g,b)], [x+1, y+1, RGB(r,g,b)]

I can imagine in some cases it won’t looks good. Thus, we need to smooth it with anti-aliasing. But this is beyond my expertise. 

If anyone has insight to solve this problem in hi-res, please let me know.

thanks,
Ricky

[B2-devel] developer guide initiative

[Ricky Z. <zha...@gm...>]

Hi all,

Basilisk II and SheepShaver doesn’t have decent developer guide, while they have a good user guide provided by emaculation.

I planned to read emulation core of BII last year and tried to see if I can contribute something. I built the XLR website at home but it ends up nowhere.

This year I start an initiative to document developer guide in macemu github upstream repo (https://github.com/cebix/macemu/wiki/Developer-Guide <https://github.com/cebix/macemu/wiki/Developer-Guide>). I hope I can write down something when exploring emulation. 

People want to contribute something new to BII and SS. But the major obstacle is to understand how they works first. Providing a centralized place like emaculation should be a good starting point. 

If you know a thing or two on development side, please don’t shy to contribute. Every bit of information or knowledge you have may help others a lot.

thanks,
Ricky

Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

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

That's a fairly good description of VOSF.  IIRC, BII keeps the emulated framebuffer RAM read-only, until it gets a SEGV due to the emulated CPU writing into it.  Then it unlocks that particular page, makes a record of it, and resumes execution.  When it's time to do a screen update, BII knows that only the pages it has unlocked could have changed from the previous frame, so it only needs to write those pages to the screen.  That tends to be faster than comparing the entire framebuffer with a copy of the previous one, and than copying the entire framebuffer on each frame.  After updating the screen, BII locks the emulated framebuffer RAM again, so new writes will be caught.

Writing framebuffer memory to the screen is a somewhat expensive operation, due to the unusual framebuffer formats used by MacOS, and the desire to emulate low-color (1 to 8 bit) video modes on modern 24-bit display hardware.
But it's been a *long* time since I messed with this code....  The performance tradeoffs may have changed in the interim.

Brian J. Johnson


On Saturday, July 22, 2017, 3:46:21 PM CDT, Josh Juran <jj...@gm...> wrote:

On Jul 22, 2017, at 3:14 PM, David Ludwig <dl...@po...> wrote:

> I've been doing some work within the Basilisk II code, on Mac OS 10.12 + Xcode 8.x.

This is great news.  I have a build that’s stable, but apparently only runs on 10.4 (unlike my SheepShaver build).

> I've been able to get it compiling, and almost limping along, but have found some parts of the code to be a bit confusing.  In particular, I was wondering if there is a reason, or a need, for the app to try to capture SIGSEGV?
> 
> On a similar note, I also noticed some "VOSF" code, which appears to deal with display code, on/after a segfault.  Might anyone has an idea what this is, or was for?

VOSF is Video On Segmentation Fault.  My guess is that, rather than mapping the virtual screen into virtual RAM and copying it to the real screen on a timer (which is a waste of CPU and battery if nothing is happening), the emulator marks the virtual screen as inaccessible, so writes to it elicit SIGSEGV, and the signal handler implements the write and schedules a screen update.  The tradeoff is that this is more expensive when it does happen.  (Consider this all speculation on my part.)

In practice, SheepShaver in VOSF mode will use noticeably less CPU if the insertion point isn’t blinking and the menu bar clock doesn’t display seconds, but CPU usage never drops below 4%.  Also, I notice that taking a screenshot (by reading the screen buffer from within Mac OS 9) is pretty slow.  Maybe non-VOSF is better at this, but I don’t have such a build to compare against at the moment.

Josh


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
basilisk-devel mailing list
bas...@li...
https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] Rudimentary port to SDL2

[David L. <dl...@po...>]

Hello!

I've been spending the better part of my afternoon trying to cobble
together a port of Basilisk II to SDL2.  I've been able to put together a
somewhat functional port, although there are some bugs.

If anyone is interested in it, I've posted a pre-built Mac OS X binary at
https://github.com/DavidLudwig/macemu/releases

Code for this port is up at https://github.com/DavidLudwig/macemu

Feature-wise, the main thing is probably the support of Mac OS X's "Spaces"
feature.  If and when Basilisk II is launched in full-screen mode, it'll
attempt to work with OS X's desktop manager, to create a separate desktop
for Basilisk II. On devices with multi-touch enabled trackpads (MacBooks,
etc.), this allows one to do a multi-finger swipe from an OS X desktop, to
a Basilisk II desktop.

There are new bugs, some of which I am aware of, many of which I probably
am not.  I'll see if I can get some of the known ones fixed, when I next
have a free weekend for computer work.  I'll attempt to list a few of the
known ones on Github.

Cheers!
-- David Ludwig

Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

[David L. <dl...@po...>]

An update: I've ​moved my branch over to SDL2.  The port (to SDL2) is
pretty rudimentary at this point, and has a few input bugs (Command + Q
doesn't work right, on Mac; performance could probably use a bit of work),
but it otherwise seems to work.

If anyone is interested, a copy is up at
https://github.com/davidludwig/macemu.

Cheers!
-- David L.

Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

[David L. <dl...@po...>]

On Sat, Jul 22, 2017 at 4:46 PM, Josh Juran <jj...@gm...> wrote:

> On Jul 22, 2017, at 3:14 PM, David Ludwig <dl...@po...> wrote:
>
> > I've been doing some work within the Basilisk II code, on Mac OS 10.12 +
> Xcode 8.x.
>
> This is great news.  I have a build that’s stable, but apparently only
> runs on 10.4 (unlike my SheepShaver build).
>

With a bit of work, and a bit of hacking, I was able to get Basilisk II
running, and booting System 7.5.x, in a 640x480 window.  The end result
does have some known bugs, and probably some unknown ones, but it does
build and run.

My work is up at https://github.com/davidludwig/macemu, if you, or anyone
else is interested.  The end result seems to run fine, on macOS Sierra, and
with Basilisk compiled as a 64-bit app.  Be sure to put a pre-compiled copy
of SDL.framework (aka. SDL 1.2.x) inside /Library/Frameworks/.  A copy can
be downloaded from https://libsdl.org/download-1.2.php (grab the Mac OS X
runtime library download, which includes SDL.framework, which includes
Header files and the like).


>
> > I've been able to get it compiling, and almost limping along, but have
> found some parts of the code to be a bit confusing.  In particular, I was
> wondering if there is a reason, or a need, for the app to try to capture
> SIGSEGV?
> >
> > On a similar note, I also noticed some "VOSF" code, which appears to
> deal with display code, on/after a segfault.  Might anyone has an idea what
> this is, or was for?
>
> VOSF is Video On Segmentation Fault.  My guess is that, rather than
> mapping the virtual screen into virtual RAM and copying it to the real
> screen on a timer (which is a waste of CPU and battery if nothing is
> happening), the emulator marks the virtual screen as inaccessible, so
> writes to it elicit SIGSEGV, and the signal handler implements the write
> and schedules a screen update.  The tradeoff is that this is more expensive
> when it does happen.  (Consider this all speculation on my part.)
>
> In practice, SheepShaver in VOSF mode will use noticeably less CPU if the
> insertion point isn’t blinking and the menu bar clock doesn’t display
> seconds, but CPU usage never drops below 4%.  Also, I notice that taking a
> screenshot (by reading the screen buffer from within Mac OS 9) is pretty
> slow.  Maybe non-VOSF is better at this, but I don’t have such a build to
> compare against at the moment.
>

I ended up ignoring+disabling VOSF, in my current work.

If the max CPU-use isn't much more or less than 4% without VOSF, I'd be a
bit inclined to consider removing that code.  It's implementation seems a
bit messy to me, possibly moreso than is worth it (I am unsure), but then
again, I am new to the Basilisk II code.

Cheers!
-- David L.

On Sat, Jul 22, 2017 at 4:46 PM, Josh Juran <jj...@gm...> wrote:

> On Jul 22, 2017, at 3:14 PM, David Ludwig <dl...@po...> wrote:
>
> > I've been doing some work within the Basilisk II code, on Mac OS 10.12 +
> Xcode 8.x.
>
> This is great news.  I have a build that’s stable, but apparently only
> runs on 10.4 (unlike my SheepShaver build).
>
> > I've been able to get it compiling, and almost limping along, but have
> found some parts of the code to be a bit confusing.  In particular, I was
> wondering if there is a reason, or a need, for the app to try to capture
> SIGSEGV?
> >
> > On a similar note, I also noticed some "VOSF" code, which appears to
> deal with display code, on/after a segfault.  Might anyone has an idea what
> this is, or was for?
>
> VOSF is Video On Segmentation Fault.  My guess is that, rather than
> mapping the virtual screen into virtual RAM and copying it to the real
> screen on a timer (which is a waste of CPU and battery if nothing is
> happening), the emulator marks the virtual screen as inaccessible, so
> writes to it elicit SIGSEGV, and the signal handler implements the write
> and schedules a screen update.  The tradeoff is that this is more expensive
> when it does happen.  (Consider this all speculation on my part.)
>
> In practice, SheepShaver in VOSF mode will use noticeably less CPU if the
> insertion point isn’t blinking and the menu bar clock doesn’t display
> seconds, but CPU usage never drops below 4%.  Also, I notice that taking a
> screenshot (by reading the screen buffer from within Mac OS 9) is pretty
> slow.  Maybe non-VOSF is better at this, but I don’t have such a build to
> compare against at the moment.
>
> Josh
>
>

Re: [B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

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

On Jul 22, 2017, at 3:14 PM, David Ludwig <dl...@po...> wrote:

> I've been doing some work within the Basilisk II code, on Mac OS 10.12 + Xcode 8.x.

This is great news.  I have a build that’s stable, but apparently only runs on 10.4 (unlike my SheepShaver build).

> I've been able to get it compiling, and almost limping along, but have found some parts of the code to be a bit confusing.  In particular, I was wondering if there is a reason, or a need, for the app to try to capture SIGSEGV?
> 
> On a similar note, I also noticed some "VOSF" code, which appears to deal with display code, on/after a segfault.  Might anyone has an idea what this is, or was for?

VOSF is Video On Segmentation Fault.  My guess is that, rather than mapping the virtual screen into virtual RAM and copying it to the real screen on a timer (which is a waste of CPU and battery if nothing is happening), the emulator marks the virtual screen as inaccessible, so writes to it elicit SIGSEGV, and the signal handler implements the write and schedules a screen update.  The tradeoff is that this is more expensive when it does happen.  (Consider this all speculation on my part.)

In practice, SheepShaver in VOSF mode will use noticeably less CPU if the insertion point isn’t blinking and the menu bar clock doesn’t display seconds, but CPU usage never drops below 4%.  Also, I notice that taking a screenshot (by reading the screen buffer from within Mac OS 9) is pretty slow.  Maybe non-VOSF is better at this, but I don’t have such a build to compare against at the moment.

Josh

[B2-devel] Reason(s) for capturing SIGSEGV? Also, VOSF?

[David L. <dl...@po...>]

Hello all,

I've been doing some work within the Basilisk II code, on Mac OS 10.12 +
Xcode 8.x.  I've been able to get it compiling, and almost limping along,
but have found some parts of the code to be a bit confusing.  In
particular, I was wondering if there is a reason, or a need, for the app to
try to capture SIGSEGV?  My guess on this has been that it is related to
emulation (to note, I am using the UAE virtual-CPU), but am not entirely
sure on this.

On a similar note, I also noticed some "VOSF" code, which appears to deal
with display code, on/after a segfault.  Might anyone has an idea what this
is, or was for?

I've tried digging through Basilisk's code, and its ChangeLog for clues,
but am still a bit hazy on these.  I'm wondering if they are necessary.

Cheers!
-- David Ludwig

[B2-devel] plan for discussion

[Ricky Z. <zha...@gm...>]

Recently, I'm working on fixing several issues in BII Linux and Mac host.

I found something I'd like to work on to make BII work in modern Mac/Linux
OS:


1. Warnings from clang. Some are bugs like undefined behavior and sequence
points in modern compilers. Some are 64bit compatible issues. Those are
easy to fix.


2. Plan for slirp.

  a. Leave it as it is? Recommend to use tun/tap in Mac and Linux? I think
tun/tap is more favorable than other.

  b. Migrate to a complete new slirp from QEMU.

  c. Just fix 64 bit issue in current code base.


Personally I prefer choice a. Just because of less work. But there may be
some configuration hassle in Mac to setup tup/tap.


3. JIT. It doesn't quite work well with recent GCC, Clang and even 32bit
ARM platform. I haven't read into details how it works. So I don't have any
proposed plan yet. But I did see QEMU have been using new TCG to handle
instruction emulation. Is JIT in BII a port from QEMU old dynamic
translator technique? Any document except TECH manual to guide me?

TIA

Re: [B2-devel] sheep_net in latest kernel

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

Thanks for all your work getting to the bottom of this! Woot!

On Thu, Aug 18, 2016 at 12:47 PM, Ricky Zhang <zha...@gm...>
wrote:

> I wrote a Python script to convert communication packet between Guest OS
> and sheep_net into hex dump for wireshark.
>
> I found two bugs in sheep_net module. I have fixed it. Another Basilisk II
> user in France also confirmed that my fix works for his Linux host in PPC.
>
> I will send a pull request later.
>
> On Thu, Aug 11, 2016 at 7:26 PM, Ricky <zha...@gm...> wrote:
>
>> I'm interested in making it sheep_net and TCP/IP ethernet works again on
>> Mac 7.5 under Linux host. But I found that TCP is not quite working. Here
>> is my settings:
>>
>>    - Fedora 24, 4.5.7-300.fc24.x86_64
>>    - Mac 7.6 with TCP/IP stack
>>    - sheep_net modules (I fixed new sk_alloc function call after 4.2
>>    kernel. I haven't sent pull request yet since it doesn't work anyway)
>>
>> I debugged it by capturing ethernet packet between Basilisk II(B) and
>> remote host (R). I found that during TCP 3 way handshakes,
>> 1. B->R (SYN)
>> 2. B<-R (SYN+ACK)
>> 3. no more response from B and B keeps on retransmit step 1 again and
>> again.
>>
>> It seems like packet in step 2 didn't get received by Mac. I enabled
>> debug in BasiliskII/src/Unix/ether_unix.cpp and did find that the exact
>> packet in step 2 was received from /dev/sheep_net by B. But it seems that
>> Mac didn't get it.
>>
>> I have zero experiences in debugging 68K emulation part. I wonder:
>>
>>    - if anyone can suggest me an easy way to debug networking inside Mac
>>    7.5, ie after interrupt finish
>>    - the last settings that your sheep_net modules works
>>
>> I patched sheep_net for 3.15 kernel before. I remembers I could ftp and
>> ping from the same Mac 7.5 image. But I can't http.
>> TIA
>>
>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] sheep_net in latest kernel

[Ricky Z. <zha...@gm...>]

I wrote a Python script to convert communication packet between Guest OS
and sheep_net into hex dump for wireshark.

I found two bugs in sheep_net module. I have fixed it. Another Basilisk II
user in France also confirmed that my fix works for his Linux host in PPC.

I will send a pull request later.

On Thu, Aug 11, 2016 at 7:26 PM, Ricky <zha...@gm...> wrote:

> I'm interested in making it sheep_net and TCP/IP ethernet works again on
> Mac 7.5 under Linux host. But I found that TCP is not quite working. Here
> is my settings:
>
>    - Fedora 24, 4.5.7-300.fc24.x86_64
>    - Mac 7.6 with TCP/IP stack
>    - sheep_net modules (I fixed new sk_alloc function call after 4.2
>    kernel. I haven't sent pull request yet since it doesn't work anyway)
>
> I debugged it by capturing ethernet packet between Basilisk II(B) and
> remote host (R). I found that during TCP 3 way handshakes,
> 1. B->R (SYN)
> 2. B<-R (SYN+ACK)
> 3. no more response from B and B keeps on retransmit step 1 again and
> again.
>
> It seems like packet in step 2 didn't get received by Mac. I enabled debug
> in BasiliskII/src/Unix/ether_unix.cpp and did find that the exact packet
> in step 2 was received from /dev/sheep_net by B. But it seems that Mac
> didn't get it.
>
> I have zero experiences in debugging 68K emulation part. I wonder:
>
>    - if anyone can suggest me an easy way to debug networking inside Mac
>    7.5, ie after interrupt finish
>    - the last settings that your sheep_net modules works
>
> I patched sheep_net for 3.15 kernel before. I remembers I could ftp and
> ping from the same Mac 7.5 image. But I can't http.
> TIA
>

[B2-devel] sheep_net in latest kernel

[Ricky <zha...@gm...>]

I'm interested in making it sheep_net and TCP/IP ethernet works again on Mac 7.5 under Linux host. But I found that TCP is not quite working. Here is my settings: 

Fedora 24, 4.5.7-300.fc24.x86_64
Mac 7.6 with TCP/IP stack
sheep_net modules (I fixed new sk_alloc function call after 4.2 kernel. I haven't sent pull request yet since it doesn't work anyway)
I debugged it by capturing ethernet packet between Basilisk II(B) and remote host (R). I found that during TCP 3 way handshakes, 
1. B->R (SYN)
2. B<-R (SYN+ACK)
3. no more response from B and B keeps on retransmit step 1 again and again. 

It seems like packet in step 2 didn't get received by Mac. I enabled debug in BasiliskII/src/Unix/ether_unix.cpp and did find that the exact packet in step 2 was received from /dev/sheep_net by B. But it seems that Mac didn't get it.

I have zero experiences in debugging 68K emulation part. I wonder:

if anyone can suggest me an easy way to debug networking inside Mac 7.5, ie after interrupt finish
the last settings that your sheep_net modules works
I patched sheep_net for 3.15 kernel before. I remembers I could ftp and ping from the same Mac 7.5 image. But I can't http.

TIA

Re: [B2-devel] Broken links in sheep_net source

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

Did you run autogen.sh?

On Jul 14, 2016 4:30 AM, "Peter Veltmans" <pet...@sk...> wrote:

> Hi,
>
> I am trying to compile (on Ubuntu 14.04) the sheep_net driver for
> SheepShaver and BasiliskII (from the downloaded zip-file). I tried the
> binary first, which didn't give me succes.
>
> It doesn't 'work'. So I looked at the source files and came up with this:
>
> Under macemu-master/BasiliskII/src/Unix/Linux/NetDriver there is a broken
> symbolic link with the name 'config.h'.
> Under macemu-master/SheepShaver/src/Unix/Linux/NetDriver there is likewise
> a broken symbolic link with the same name.
>
> Both links refer to the file macemu-master/SheepShaver/src/Unix/config.h
>
> However: that file... does not exist.
>
> I checked the code that I cloned from git (files in cebix-macemu-b58a926).
> It is the same there.
>
> I then went into macemu-master/SheepShaver and gave the command 'make
> links' (as instructed by the main page of the website). I did the same in
> cebix-macemu-b58a926/SheepShaver.
>
> Then I checked again. Same thing on both accounts: broken link.
>
> Could this be fixed somehow?
>
> TIA,
>
> Peter
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] Broken links in sheep_net source

[Peter V. <pet...@sk...>]

Hi,

I am trying to compile (on Ubuntu 14.04) the sheep_net driver for 
SheepShaver and BasiliskII (from the downloaded zip-file). I tried the 
binary first, which didn't give me succes.

It doesn't 'work'. So I looked at the source files and came up with this:

Under macemu-master/BasiliskII/src/Unix/Linux/NetDriver there is a 
broken symbolic link with the name 'config.h'.
Under macemu-master/SheepShaver/src/Unix/Linux/NetDriver there is 
likewise a broken symbolic link with the same name.

Both links refer to the file macemu-master/SheepShaver/src/Unix/config.h

However: that file... does not exist.

I checked the code that I cloned from git (files in 
cebix-macemu-b58a926). It is the same there.

I then went into macemu-master/SheepShaver and gave the command 'make 
links' (as instructed by the main page of the website). I did the same 
in cebix-macemu-b58a926/SheepShaver.

Then I checked again. Same thing on both accounts: broken link.

Could this be fixed somehow?

TIA,

Peter

Re: [B2-devel] Tutorials?

[Helen B. <he...@ac...>]

Ty:

I am not sure how we got on your email list. We don’t have anything to do with Sheepshaver. We did supply the BasiliskII emulator for PC users of our software, but we’ve been native on Windows for several years now and no longer support it.

Sincerely,
Helen

Watch a Speed Test of Bible Software.

*********************************
Dr. Helen A. Brown
Vice President and General Manager
Accordance/OakTree Software, Inc.
http://www.accordancebible.com/
*********************************

On Feb 14, 2016, at 4:15 AM, ty armour <aa...@ci...> wrote:

> I need tutorials on developing SheepShaver. On basically every last line of code in sheepshaver. ALso, I need QEMU development tutorials. like how to develop the backend of qemu as well as how to develop qemu applications
> 
> Although my plan is to write a custom bios for computers that acts like a patch bay, and then I have the ability to patch my computer to use mac windows or linux or bsd or haiku and whatever other OSes i decide to write in.
> 
> you guys have a start, and I could emulate mac hardware, or you could write operating systems based on mac 0.0-10.10
> 
> the more tutorials you give on developing sheepshaver the better
> 
> just post tutorials on everything and I will figure out in the meantime how to exactly implement what I want to do.
> 
> Ill figure it out, just post tutorials if you want. 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] Tutorials?

[ty a. <aa...@ci...>]

I need tutorials on developing SheepShaver. On basically every last line of
code in sheepshaver. ALso, I need QEMU development tutorials. like how to
develop the backend of qemu as well as how to develop qemu applications

Although my plan is to write a custom bios for computers that acts like a
patch bay, and then I have the ability to patch my computer to use mac
windows or linux or bsd or haiku and whatever other OSes i decide to write
in.

you guys have a start, and I could emulate mac hardware, or you could write
operating systems based on mac 0.0-10.10

the more tutorials you give on developing sheepshaver the better

just post tutorials on everything and I will figure out in the meantime how
to exactly implement what I want to do.

Ill figure it out, just post tutorials if you want.