* 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).