linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Linux-mac68k project account maintenance (fwd)
       [not found] <alpine.LNX.2.22.394.2006151113030.17@nippy.intranet>
@ 2020-06-15  3:29 ` Josh Juran
  2020-06-15  4:21   ` penguin (was Re: Linux-mac68k project account maintenance) Finn Thain
  0 siblings, 1 reply; 5+ messages in thread
From: Josh Juran @ 2020-06-15  3:29 UTC (permalink / raw)
  To: Finn Thain; +Cc: linux-m68k

On Jun 14, 2020, at 9:15 PM, Finn Thain <fthain@telegraphics.com.au> wrote:

> When I send email to <jax@users.sourceforge.net> it bounces...

I haven't tried to log into SourceForge in a long time, and I have no idea what still works.  Please use jjuran@gmail.com for future emails.

> jax is still listed as a project admin.

As my most recent participation was co-developing Penguin, I probably don't need to be an admin. :-)

Let me know if there's any other information or action you need from me.  I'd also be interested in any hearing about efforts to virtualize Mac OS or Mac applications on Linux/m68k, as I might be able to assist with those.

Thanks for reaching out!

Josh


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: penguin (was Re: Linux-mac68k project account maintenance)
  2020-06-15  3:29 ` Linux-mac68k project account maintenance (fwd) Josh Juran
@ 2020-06-15  4:21   ` Finn Thain
  2020-06-18  7:11     ` Josh Juran
  0 siblings, 1 reply; 5+ messages in thread
From: Finn Thain @ 2020-06-15  4:21 UTC (permalink / raw)
  To: Josh Juran; +Cc: linux-m68k

On Sun, 14 Jun 2020, Josh Juran wrote:

> 
> As my most recent participation was co-developing Penguin, I probably 
> don't need to be an admin. :-)
> 

If your sourceforge account is still a going concern I'll leave the commit 
bit as-is -- I'd hate to discourage possible future contributions!

> Let me know if there's any other information or action you need from me.  
> I'd also be interested in any hearing about efforts to virtualize Mac OS 
> or Mac applications on Linux/m68k, as I might be able to assist with 
> those.
> 

I don't know of any MacOS virtualization efforts (kvm for linux-m68k?)

Personally, I'd love to see EMILE ported to MacRelix, as a replacement for 
Penguin. Reason being, there are several Penguin bugs that result in boot 
crashes and some other bugs besides. Almost all have workarounds, but you 
have to read the docs to find out about them (and go out of your way to 
apply them).

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: penguin (was Re: Linux-mac68k project account maintenance)
  2020-06-15  4:21   ` penguin (was Re: Linux-mac68k project account maintenance) Finn Thain
@ 2020-06-18  7:11     ` Josh Juran
  2020-06-19  1:39       ` Finn Thain
  0 siblings, 1 reply; 5+ messages in thread
From: Josh Juran @ 2020-06-18  7:11 UTC (permalink / raw)
  To: Finn Thain; +Cc: linux-m68k

On Jun 15, 2020, at 12:21 AM, Finn Thain <fthain@telegraphics.com.au> wrote:

> On Sun, 14 Jun 2020, Josh Juran wrote:
> 
>> As my most recent participation was co-developing Penguin, I probably 
>> don't need to be an admin. :-)
> 
> If your sourceforge account is still a going concern I'll leave the commit 
> bit as-is -- I'd hate to discourage possible future contributions!

Very well, I just changed the password and replaced the SSH keys.  I didn't enable external email, though.

>> I'd also be interested in any hearing about efforts to virtualize Mac OS 
>> or Mac applications on Linux/m68k, as I might be able to assist with 
>> those.
> 
> I don't know of any MacOS virtualization efforts (kvm for linux-m68k?)

I've made a small first step -- my emulator runs Mac applications in User mode.

> Personally, I'd love to see EMILE ported to MacRelix, as a replacement for 
> Penguin.

Okay, /that/ I wasn't expecting. :-)

Though now that I think about it, I can see the appeal.  The booter itself becomes a command-line-only program, whose resource fork can be empty.  You even get a rudimentary shell, a couple of scripting languages, and some filesystem-bound GUI primitives.

And while MacRelix may be bloated by 1990 standards, you're not trying to boot Linux on a 4 MiB machine.[1]  (Plus, whatever RAM it uses you get back after booting Linux.)

> Reason being, there are several Penguin bugs that result in boot 
> crashes and some other bugs besides.

I got my start here fixing general Mac programming bugs in Penguin, and if any have crept back in I can certainly take a look.  I've also got a solid background in 68K machine-level programming now.

> Almost all have workarounds, but you 
> have to read the docs to find out about them (and go out of your way to 
> apply them).

Is Penguin still built with a non-free compiler in a non-free OS?  A port to Retro68 might help make it more maintainable.

Josh

[1] ... I hope. :-)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: penguin (was Re: Linux-mac68k project account maintenance)
  2020-06-18  7:11     ` Josh Juran
@ 2020-06-19  1:39       ` Finn Thain
  2020-06-19  6:33         ` Brad Boyer
  0 siblings, 1 reply; 5+ messages in thread
From: Finn Thain @ 2020-06-19  1:39 UTC (permalink / raw)
  To: Josh Juran; +Cc: linux-m68k

On Thu, 18 Jun 2020, Josh Juran wrote:

> On Jun 15, 2020, at 12:21 AM, Finn Thain <fthain@telegraphics.com.au> 
> wrote:
> 
> >> I'd also be interested in any hearing about efforts to virtualize Mac 
> >> OS or Mac applications on Linux/m68k, as I might be able to assist 
> >> with those.
> > 
> > I don't know of any MacOS virtualization efforts (kvm for linux-m68k?)
> 
> I've made a small first step -- my emulator runs Mac applications in 
> User mode.
> 

MAME/MESS can boot MacOS. There is work under way to boot MacOS in 
qemu-system-m68k.

But outside of A/UX, I don't know of any way to get hardware assisted 
virtualization for 68k MacOS applications.

> > Personally, I'd love to see EMILE ported to MacRelix, as a replacement 
> > for Penguin.
> 
> Okay, /that/ I wasn't expecting. :-)
> 
> Though now that I think about it, I can see the appeal.  The booter 
> itself becomes a command-line-only program, whose resource fork can be 
> empty.  You even get a rudimentary shell, a couple of scripting 
> languages, and some filesystem-bound GUI primitives.
> 

Yes, there would be an improvement in functionality. Presently I can't 
manage EMILE boot blocks from MacOS e.g. for rescue purposes. But there 
would also be an improvement in maintainability (compared to the existing 
Penguin codebase).

Certain code is needed anywhere that you unpack a kernel binary and launch 
it. Penguin and EMILE duplicate this functionality. EMILE has fewer bugs 
in this area and is more maintainable. A common codebase would be a win.

Penguin is more capable only inasmuch as it knows how to take over from 
MacOS (its drivers and its memory mappings). But this code may not be 
needed if a hypothetical "MacEMILE" could just setup the boot blocks, 
configure the boot device in PRAM and then restart. (That would be more 
like XPostFacto than Penguin, I suppose.)

So it's not necessary to port all of EMILE. The parts of EMILE that run in 
the ROM environment are presently built under Linux and would never need 
to be built in a different environment.

> And while MacRelix may be bloated by 1990 standards, you're not trying 
> to boot Linux on a 4 MiB machine.[1] (Plus, whatever RAM it uses you get 
> back after booting Linux.)
> 

In my experience, you need 12 MB RAM to boot the kernel (with a small 
initramfs), if you use MacOS and Penguin to do so.

> > Reason being, there are several Penguin bugs that result in boot 
> > crashes and some other bugs besides.
> 
> I got my start here fixing general Mac programming bugs in Penguin, and 
> if any have crept back in I can certainly take a look.  I've also got a 
> solid background in 68K machine-level programming now.
> 

I don't think the bugs "crept back in" -- AFAIK these aren't regressions. 
MacOS 7.5.3 with Penguin 19 did work on every machine I tested it on 
(almost all supported models). But you need various workarounds [2].

These are the bugs that I've come across:

  - Penguin fails to stop SONIC chip directly or close the MacOS driver.
    Network traffic can crash Linux with an unhandled interrupt. (This may 
    be true for NuBus NICs too, on machines that can't mask slot 
    interrupts.)

  - Penguin will hang after "slot_int_set: ..." when unpacking certain
    compressed kernel binaries.

  - To avoid kernel memory corruption, Penguin must not pre-configure
    serial ports on AV Macs. Probably have to close the .SerialDMA driver?

  - Part of the kernel command line gets erased somehow, making it hard to
    edit.

  - Log window is excruciatingly slow.

This isn't an exhaustive list. I think there are limits to what can be 
accomplished in a runtime environment provided by MacOS plus third-party 
drivers and extensions. (Though I suppose EMILE too must contend with 
random drivers executed from NuBus ROMs and Apple_Driver partitions.)

> > Almost all have workarounds, but you have to read the docs to find out 
> > about them (and go out of your way to apply them).
> 
> Is Penguin still built with a non-free compiler in a non-free OS? 

Back in 2008, Tony Mantler said that building Penguin 19 requires MPW.

> A port to Retro68 might help make it more maintainable.
> 

That's awesome. [3]
Can it be used to build MacRelix applications?

> Josh
> 
> [1] ... I hope. :-)
> 

[2] http://mac.linux-m68k.org/docs/penguin.php

[3] https://github.com/autc04/Retro68


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: penguin (was Re: Linux-mac68k project account maintenance)
  2020-06-19  1:39       ` Finn Thain
@ 2020-06-19  6:33         ` Brad Boyer
  0 siblings, 0 replies; 5+ messages in thread
From: Brad Boyer @ 2020-06-19  6:33 UTC (permalink / raw)
  To: Finn Thain; +Cc: Josh Juran, linux-m68k

On Fri, Jun 19, 2020 at 11:39:49AM +1000, Finn Thain wrote:
> MAME/MESS can boot MacOS. There is work under way to boot MacOS in 
> qemu-system-m68k.
> 
> But outside of A/UX, I don't know of any way to get hardware assisted 
> virtualization for 68k MacOS applications.

It didn't work on Linux last I checked, but Basilisk II has support for
running directly on the CPU in NetBSD while only emulating the
supervisor instructions (it used a signal handler to detect and handle
anything that would cause an exception). I looked at the code, and it
appeared to be possible to do the same on Linux with some tweaks to
the signal handler (Linux passes the extra context differently).

However, Basilisk II can only boot MacOS because it doesn't actually
emulate all the hardware. In a few cases, it emulates synthetic
devices and inserts its own drivers with fake expansion ROMs. This
means you can't run Linux, NetBSD, or A/UX.

	Brad Boyer
	flar@allandria.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-06-19  6:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <alpine.LNX.2.22.394.2006151113030.17@nippy.intranet>
2020-06-15  3:29 ` Linux-mac68k project account maintenance (fwd) Josh Juran
2020-06-15  4:21   ` penguin (was Re: Linux-mac68k project account maintenance) Finn Thain
2020-06-18  7:11     ` Josh Juran
2020-06-19  1:39       ` Finn Thain
2020-06-19  6:33         ` Brad Boyer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).