From elliotnunn at fastmail.com Mon Apr 1 11:18:03 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Mon, 1 Apr 2019 11:18:03 +0800 Subject: [CDG5] Musings on v2 NanoKernel In-Reply-To: <2913A51C-04E6-4D0D-9A91-9D3A2210B8DF@mac.com> References: <4EFBC7DD-00A9-4D2C-AFCE-E62209381257@fastmail.com> <2913A51C-04E6-4D0D-9A91-9D3A2210B8DF@mac.com> Message-ID: <9D14A1D3-B6FC-42CC-9DC1-18B9D532257E@fastmail.com> My take is that microkernels came with some theoretical baggage that caused more trouble than it was worth. Systems that situate a microkernel under an existing OS personality have been quite successful, for example Mach underneath BSD, the NanoKernel underneath System 7/8/9, and indeed Mach underneath BlueBox. But systems that were designed to rely heavily on asynchronous message passing, such as NuKernel/Copland and the Hurd, have proven to be unmaintainable messes plagued by emergent behaviour that nobody can understand. That being said, I think that being able to take occasional advantage of Mach IPC would be very cool! Maybe I should step up the BlueBox hacking... > On 30 Mar 2019, at 4:47 pm, Fredrik Andersson wrote: > > Hi, > > Just to answer the first question- never seen a working Copland installation in person (although I attempted get numerous ?leaks? properly installed none actually successfully booted- believe all of them booted into Mac OS 7.x but all crashed quickly when attempting the Copland boot using caps lock or whatever key required to be held down was depressed) > > However to add to the discussion, regarding microkernels- keep in mind that Copland was only one of several attempts Apple had to modernize Mac OS and as for microkernels they were a hot topic in the 80s, nukernel was clearly inspired by mach 3 and ironically an mach 3 derative is what powers macOS today :) > >> 30 mars 2019 kl. 04:34 skrev Elliot Nunn : >> >> I think that Apple's "microkernel phase" might have started even >> earlier. The ERS appendix in that patent application seems to have a >> revision history dating back to 1992, and it discusses NuKernel on 68k >> as well as PowerPC. >> >> By the way, has anyone on our list ever *seen* a working NuKernel >> system? Either Copland, or something more exotic like the early BlueBox. >> >> Calling MPFindVictimPage with (r3 | r4) != 0 zeroes >> KDP.VMMaxVirtualPages. This enables an alternative page fault resolution >> code path in NKInterrupts.s, and enables the alternative VM call table. >> (These refer to the powermac-rom tree, which I *still* intend to replace >> with an improved NanoKernel tree.) >> >> To me toddp.com seems to be up still. But fear not, the SuperMario >> sources are ineradicable. >> >>> On 29 Mar 2019, at 8:47 pm, Max Poliakovski wrote: >>> >>> Hi Elliot, >>> >>> I already suspected that Nanokernel v2 could include ideas/pieces from the abandoned NuKernel. It's interesting that the first modernization ideas for the OS/kernel date back to 1994, just right after the official release of the first Power Macs (6100, 7100 and 8100). Another interesting point is that NuKernel working group doesn't include Gary Davidian that wrote the NK v1. >>> >>> What is this "alternate" Virtual Memory API? Anything that goes though "sc" and not through the 68k-ish _VMDispatch (0xFE0A)? >>> >>> BTW: the server http://toddp.com/ that hosted the leaked "System 7.1" source code (that's actually the ROM source for the pre-TNT machines) is down. I hope you've managed to save its content... >>> >>> Cheers >>> Max >>> >>> Am Do., 28. M?rz 2019 um 05:54 Uhr schrieb Elliot Nunn : >>> When we get back to reversing the "alternate" Virtual Memory API exposed >>> by the v2 NanoKernel, this might be informative: >>> >>> https://patents.google.com/patent/US5590334 >>> >>> The entire External Reference Specification for NuKernel (c 1993) is >>> included as an appendix. It seems that the later additions to the >>> kernel, which were under-utilised by Mac OS 9, were an increasingly >>> faithful replication of NuKernel mechanisms. >>> _______________________________________________ >>> cdg5 mailing list >>> cdg5 at ucc.asn.au >>> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 >>> _______________________________________________ >>> cdg5 mailing list >>> cdg5 at ucc.asn.au >>> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 >> >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Mon Apr 1 11:56:57 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Mon, 1 Apr 2019 11:56:57 +0800 Subject: [CDG5] Little cheat sheet on 68k unsigned branches Message-ID: <99C80A2C-BCE8-48D2-836B-BA09AC68BCB0@fastmail.com> Just in case, like me, you struggle with these. BLO (BCS) like blt, branch if lower BLS like ble, branch if lower or same BHS (BCC) like bge, branch if higher or same BHI like bgt, branch if higher From maximumspatium at googlemail.com Tue Apr 2 07:25:56 2019 From: maximumspatium at googlemail.com (Max Poliakovski) Date: Tue, 2 Apr 2019 01:25:56 +0200 Subject: [CDG5] MemRetry's objective Message-ID: Fellow hackers, I wonder what purpose Nanokernel's sophisticated retry code was designed for? Until now, I only stepped through this code using MAME's integrated debugger. While running in an emulator, I mostly get DSI exceptions causing the retry code to fail and to drop into the secondary exception handler that is capable of handling of "hardcore" VM exceptions like hash table misses, access violation etc. So, from the emulator's POV, the retry code seems to be quite useless. Is there any real hardware circumstances causing the retry code to succeed and thus be useful? Cheers Max -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190402/766d5a5c/attachment.htm From elliotnunn at fastmail.com Tue Apr 2 07:30:26 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 2 Apr 2019 07:30:26 +0800 Subject: [CDG5] MemRetry's objective In-Reply-To: References: Message-ID: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> Mainly misaligned accesses. An emulator might not complain about these, but I would expect MAME to be pretty accurate! Does MacOS for PowerPC boot in MAME? > On 2 Apr 2019, at 7:25 am, Max Poliakovski wrote: > > Fellow hackers, > > I wonder what purpose Nanokernel's sophisticated retry code was designed for? > > Until now, I only stepped through this code using MAME's integrated debugger. While running in an emulator, I mostly get DSI exceptions causing the retry code to fail and to drop into the secondary exception handler that is capable of handling of "hardcore" VM exceptions like hash table misses, access violation etc. > > So, from the emulator's POV, the retry code seems to be quite useless. > > Is there any real hardware circumstances causing the retry code to succeed and thus be useful? > > Cheers > Max > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From maximumspatium at googlemail.com Tue Apr 2 07:51:52 2019 From: maximumspatium at googlemail.com (Max Poliakovski) Date: Tue, 2 Apr 2019 01:51:52 +0200 Subject: [CDG5] MemRetry's objective In-Reply-To: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> Message-ID: Wow! I call it a "real quick" reply :) Mainly misaligned accesses. An emulator might not complain about these, but > I would expect MAME to be pretty accurate! So PPC load/store instructions will cause DSI on misaligned access and memretry will magically fix that? That sounds cool :) I don't actually know how the emulated CPU in MAME handles misaligned accesses. Tomorrow I'll try to enforce it to see what happens... > Does MacOS for PowerPC boot in MAME? > Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... Cheers Max -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190402/908070e3/attachment.htm From elliotnunn at fastmail.com Tue Apr 2 08:13:02 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 2 Apr 2019 08:13:02 +0800 Subject: [CDG5] MemRetry's objective In-Reply-To: References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> Message-ID: <8FED514F-748A-4223-AB8F-B5DE0DA3422D@fastmail.com> Wow! It would be brilliant to have an accurate OldWorld Power Mac emulator. Once I (finally) get Cube-E building, I hope to develop/RE a minimal patch to get it running on RISC. Slight twist (and apologies for being off topic): I just found that the linked patches (lpch resources etc) hardly changed from System 7.1 to Mac OS 8.1 (after which I think they disappeared). This is probably explained by Apple using SuperMario, with its ROM vectorisation mechanism, for all late-Quadra and Power Mac ROMs, and thus obsoleting the linked patch mechanism. As they stand, then, the linked patches are a powerful and modular instruction book for "modernising" or "System 7-ising" any Mac ROM as far back as the first "128K" Plus ROM. Neat! > On 2 Apr 2019, at 7:51 am, Max Poliakovski wrote: > > Wow! I call it a "real quick" reply :) > > Mainly misaligned accesses. An emulator might not complain about these, but I would expect MAME to be pretty accurate! > > So PPC load/store instructions will cause DSI on misaligned access and memretry will magically fix that? That sounds cool :) > I don't actually know how the emulated CPU in MAME handles misaligned accesses. Tomorrow I'll try to enforce it to see what happens... > > Does MacOS for PowerPC boot in MAME? > > Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... > > Cheers > Max > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From danielbj314 at verizon.net Tue Apr 2 08:13:20 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Mon, 1 Apr 2019 20:13:20 -0400 Subject: [CDG5] MemRetry's objective In-Reply-To: References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> Message-ID: <1730EFC6-DC99-4EFE-8126-1BAAD633ECC0@verizon.net> > Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... I wonder how much work it would be to fill in custom ProductInfo tables instead of perfectly emulating lots of hardware. Interrupts get set up however you want (ProductInfo specifies code to handle them) and io can be done with fake NuBus cards. Device Tree nodes with custom drivers can be provided if some code insists on them. Much of the craziness can probably be bypassed if everything is virtual anyways. From danielbj314 at verizon.net Tue Apr 2 08:21:03 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Mon, 1 Apr 2019 20:21:03 -0400 Subject: [CDG5] MemRetry's objective In-Reply-To: <8FED514F-748A-4223-AB8F-B5DE0DA3422D@fastmail.com> References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> <8FED514F-748A-4223-AB8F-B5DE0DA3422D@fastmail.com> Message-ID: <7AE232E9-E04B-4C84-BE0C-F3F463FEAFF7@verizon.net> Do we know enough to make custom linked patches or ROM vector updates? It just seems too cool to not learn how to use. > On Apr 1, 2019, at 8:13 PM, Elliot Nunn wrote: > > Wow! It would be brilliant to have an accurate OldWorld Power Mac > emulator. Once I (finally) get Cube-E building, I hope to develop/RE a > minimal patch to get it running on RISC. > > Slight twist (and apologies for being off topic): I just found that the > linked patches (lpch resources etc) hardly changed from System 7.1 to > Mac OS 8.1 (after which I think they disappeared). This is probably > explained by Apple using SuperMario, with its ROM vectorisation > mechanism, for all late-Quadra and Power Mac ROMs, and thus obsoleting > the linked patch mechanism. As they stand, then, the linked patches are > a powerful and modular instruction book for "modernising" or "System > 7-ising" any Mac ROM as far back as the first "128K" Plus ROM. Neat! > >> On 2 Apr 2019, at 7:51 am, Max Poliakovski wrote: >> >> Wow! I call it a "real quick" reply :) >> >> Mainly misaligned accesses. An emulator might not complain about these, but I would expect MAME to be pretty accurate! >> >> So PPC load/store instructions will cause DSI on misaligned access and memretry will magically fix that? That sounds cool :) >> I don't actually know how the emulated CPU in MAME handles misaligned accesses. Tomorrow I'll try to enforce it to see what happens... >> >> Does MacOS for PowerPC boot in MAME? >> >> Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... >> >> Cheers >> Max >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Tue Apr 2 09:54:23 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 2 Apr 2019 09:54:23 +0800 Subject: [CDG5] MemRetry's objective In-Reply-To: <7AE232E9-E04B-4C84-BE0C-F3F463FEAFF7@verizon.net> References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> <8FED514F-748A-4223-AB8F-B5DE0DA3422D@fastmail.com> <7AE232E9-E04B-4C84-BE0C-F3F463FEAFF7@verizon.net> Message-ID: <83D6CED6-DBD8-438A-8A66-8C386ECF309D@fastmail.com> Very doable. But we?d need a bug to fix XD. > On 2 Apr 2019, at 8:21 am, Daniel B-J wrote: > > Do we know enough to make custom linked patches or ROM vector updates? It just seems too cool to not learn how to use. >> On Apr 1, 2019, at 8:13 PM, Elliot Nunn wrote: >> >> Wow! It would be brilliant to have an accurate OldWorld Power Mac >> emulator. Once I (finally) get Cube-E building, I hope to develop/RE a >> minimal patch to get it running on RISC. >> >> Slight twist (and apologies for being off topic): I just found that the >> linked patches (lpch resources etc) hardly changed from System 7.1 to >> Mac OS 8.1 (after which I think they disappeared). This is probably >> explained by Apple using SuperMario, with its ROM vectorisation >> mechanism, for all late-Quadra and Power Mac ROMs, and thus obsoleting >> the linked patch mechanism. As they stand, then, the linked patches are >> a powerful and modular instruction book for "modernising" or "System >> 7-ising" any Mac ROM as far back as the first "128K" Plus ROM. Neat! >> >>> On 2 Apr 2019, at 7:51 am, Max Poliakovski wrote: >>> >>> Wow! I call it a "real quick" reply :) >>> >>> Mainly misaligned accesses. An emulator might not complain about these, but I would expect MAME to be pretty accurate! >>> >>> So PPC load/store instructions will cause DSI on misaligned access and memretry will magically fix that? That sounds cool :) >>> I don't actually know how the emulated CPU in MAME handles misaligned accesses. Tomorrow I'll try to enforce it to see what happens... >>> >>> Does MacOS for PowerPC boot in MAME? >>> >>> Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... >>> >>> Cheers >>> Max >>> _______________________________________________ >>> cdg5 mailing list >>> cdg5 at ucc.asn.au >>> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 >> >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Tue Apr 2 10:15:20 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 2 Apr 2019 10:15:20 +0800 Subject: [CDG5] MemRetry's objective In-Reply-To: <1730EFC6-DC99-4EFE-8126-1BAAD633ECC0@verizon.net> References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> <1730EFC6-DC99-4EFE-8126-1BAAD633ECC0@verizon.net> Message-ID: <783A48B4-83AE-4D3F-BAD4-D0E99DE00D55@fastmail.com> I sympathise with both the perfect-emulation and the runtime-environment approaches. Sometimes I muse about what my own "Platonically ideal" MacOS would look like. These are some thoughts... - built from source - runs on any CHRP machine - no requirement for a disk-based disk driver (yuck) - much of the "crud" in the System file factored out as extensions - a good API to make trusted calls out of the emulation layer - able to take advantage of a theoretical dual 68k/PowerPC emulator runtime Who's next? > On 2 Apr 2019, at 8:13 am, Daniel B-J wrote: > >> Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... > > I wonder how much work it would be to fill in custom ProductInfo tables instead of perfectly emulating lots of hardware. Interrupts get set up however you want (ProductInfo specifies code to handle them) and io can be done with fake NuBus cards. Device Tree nodes with custom drivers can be provided if some code insists on them. > > Much of the craziness can probably be bypassed if everything is virtual anyways. > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From danielbj314 at verizon.net Tue Apr 2 10:41:13 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Mon, 1 Apr 2019 22:41:13 -0400 Subject: [CDG5] MemRetry's objective In-Reply-To: <783A48B4-83AE-4D3F-BAD4-D0E99DE00D55@fastmail.com> References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> <1730EFC6-DC99-4EFE-8126-1BAAD633ECC0@verizon.net> <783A48B4-83AE-4D3F-BAD4-D0E99DE00D55@fastmail.com> Message-ID: I would like quite a few things. - An instance of the NK API written in C, so it is easy to understand and virtualize. Coherent documentation for just about everything would be nice. - ease of porting to other systems, both real and virtual. Maybe an extension of MixedMode to another architecture? - A "use OF" mode, which keeps OF running and makes a thin layer of virtualization around everything. Make device accesses OF driver calls? - The ability to recursively virtualize itself. Want to test something crazy? Boot an instance of 9.2.4 inside of 9.2.4 - An instance of Linux running alongside 9 in a protected mem region(with 9 in control of course. Classic in reverse). Want to use Github? Interface via MPW or something. - Ability to use FireWire DMA to debug connected systems (there is a primitive version of this out there, but it apparently needs support from the target computer). - Ease of writing proper applications. Currently rather hard. > On Apr 1, 2019, at 10:15 PM, Elliot Nunn wrote: > > I sympathise with both the perfect-emulation and the runtime-environment > approaches. Sometimes I muse about what my own "Platonically ideal" > MacOS would look like. These are some thoughts... > > - built from source > - runs on any CHRP machine > - no requirement for a disk-based disk driver (yuck) > - much of the "crud" in the System file factored out as extensions > - a good API to make trusted calls out of the emulation layer > - able to take advantage of a theoretical dual 68k/PowerPC emulator > runtime > > Who's next? > >> On 2 Apr 2019, at 8:13 am, Daniel B-J wrote: >> >>> Currently it doesn't because MAME's emulation is still incomplete. Two years ago, I sent them several patches fixing CPU emulation so their model of a PowerMac 6100 almost reaches the gray screen. A hardware emulation issue related to CUDA/NVRAM is currently preventing it from booting - it seems that external interrupts won't be routed as expected. That causes the Netboot driver to hang forever. I think I'll be actually able to fix it... >> >> I wonder how much work it would be to fill in custom ProductInfo tables instead of perfectly emulating lots of hardware. Interrupts get set up however you want (ProductInfo specifies code to handle them) and io can be done with fake NuBus cards. Device Tree nodes with custom drivers can be provided if some code insists on them. >> >> Much of the craziness can probably be bypassed if everything is virtual anyways. >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Wed Apr 3 02:04:16 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Wed, 3 Apr 2019 02:04:16 +0800 Subject: [CDG5] Git abuse Message-ID: Since working on the 68k NewWorld ROM, I have used Git's commit tree to track three things at once: my changes to make the code buildable, my reconstruction of Apple's changes over time, and my desired changes to the code. Making these patchsets play nicely together has been difficult. Now, I am having difficulties reverting SuperMario to Cube-E that make me think that the Git-tree approach is not entirely workable. For example, it would be nice to show off a work in progress withoutfollowing up with "but I will rebase it to oblivion in 20 minutes". Splitting and lumping code changes meaningfully has also been a struggle. My proposed solution is to store patchsets in a public repository. Currently I am experimenting with the best `diff` settings to make these readable to a casual browser. I envision a collection of named and documented patchsets that can be manipulated by "applying" them into a separate Git repository. All the while the canonical version lives in the main public repository. Patchsets can be chained and scripts can be inserted to allow us to express our increasingly sophisticated understanding of the history of the code *and* its future potential. Thoughts? From danielbj314 at verizon.net Wed Apr 3 04:56:59 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Tue, 2 Apr 2019 16:56:59 -0400 Subject: [CDG5] Git abuse In-Reply-To: References: Message-ID: Sounds cool. So the diffs show all the branches and releases and the commit history shows improvements to the diffs? I suggest having a tool automatically format the diff order graph into a .md file with links to all the diffs. If you were to take this to its logical conclusion, I expect the result would be similar to adding meta-commits (commits that alter arbitrary parts of the commit tree) to git. A pity we don't have that already. > On Apr 2, 2019, at 2:04 PM, Elliot Nunn wrote: > > Since working on the 68k NewWorld ROM, I have used Git's commit tree to > track three things at once: my changes to make the code buildable, my > reconstruction of Apple's changes over time, and my desired changes to > the code. Making these patchsets play nicely together has been > difficult. Now, I am having difficulties reverting SuperMario to Cube-E > that make me think that the Git-tree approach is not entirely workable. > For example, it would be nice to show off a work in progress > withoutfollowing up with "but I will rebase it to oblivion in 20 > minutes". Splitting and lumping code changes meaningfully has also been > a struggle. > > My proposed solution is to store patchsets in a public repository. > Currently I am experimenting with the best `diff` settings to make these > readable to a casual browser. I envision a collection of named and > documented patchsets that can be manipulated by "applying" them into a > separate Git repository. All the while the canonical version lives in > the main public repository. Patchsets can be chained and scripts can be > inserted to allow us to express our increasingly sophisticated > understanding of the history of the code *and* its future potential. > > Thoughts? > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From maximumspatium at googlemail.com Wed Apr 3 07:29:11 2019 From: maximumspatium at googlemail.com (Max Poliakovski) Date: Wed, 3 Apr 2019 01:29:11 +0200 Subject: [CDG5] MemRetry's objective In-Reply-To: <783A48B4-83AE-4D3F-BAD4-D0E99DE00D55@fastmail.com> References: <45F9FBDF-FE0B-4DF5-9152-57DF3B07D16E@fastmail.com> <1730EFC6-DC99-4EFE-8126-1BAAD633ECC0@verizon.net> <783A48B4-83AE-4D3F-BAD4-D0E99DE00D55@fastmail.com> Message-ID: > > > I wonder how much work it would be to fill in custom ProductInfo tables > instead of perfectly emulating lots of hardware. Interrupts get set up > however you want (ProductInfo specifies code to handle them) and io can be > done with fake NuBus cards. Device Tree nodes with custom drivers can be > provided if some code insists on them. > > > > Much of the craziness can probably be bypassed if everything is virtual > anyways. > Yes, I agree with everything said here. But... there are several Macintosh emulators having different approaches and a different degree of success. Let us discuss the important ones: 1) SheepShaver patches to disable anything MMU-related so it comes close to your approach of bypassing hardware emulation. Sadly, it doesn't emulate anything pre-TNT and post-System7 because it doesn't support MMU. 2) QEMU works quite well for mac99. Other configurations are possible but poorly supported. QEMU is famous for its speed. 3) MAME is a programmatic documentation project. That said, MAME's main goal is to recreate vintage hardware in software and to document it as good as possible. This may sound silly but it's actually a clear goal to achieve. I don't want to do something that goes against the spirit of the project. As of today, what do we know about PowerMacs manufactured between 1990 and 1999? Nothing especially valuable. Considering PowerMac 6100, let's look at this chipset: 1) everything in PDM is controlled by AMIC - Apple Memory Mapped I/O Controller. Apple's docs say smth like this: "AMIC is a 256-pin IC managing all system interrupts". Sorry, but it's just ridiculous. No-one in the world will be able to recreate hardware from this kind of specification. The same is true for GrandCentral - just another custom interrupt controller resided on TNT boards (first PCI generation)... 2) PDM sound chip is called AWAC. Any further details? No avail because Apple doesn't share this kind of information. We found out that the sound chip was manufactured by Crystal Semiconductors. Specification is not available. Pinout: unknown. 3) SCSI and Serial port are serviced by another custom IC called Curio. Everything we know about it is that was manufactured by AMD. This should be a kind of a custom part AMD made for Apple. It's considered to be a hybrid chip. 4) More ASICs? Then look at the SWIM3 floppy controller... 5) all PowerPC machines use the so-called CUDA ASIC. Well, strictly speaking, it's not an ASIC at all but a Motorola MCU running custom Apple firmware. MAME team has managed to download this firmware. I started to analyze it and to document it, see https://github.com/maximumspatium/CudaFirmware Someday we will be probably able to replace vintage Motorola chips with something more powerful like AVR (a RISC MCU allowing to assign custom functionality to almost any pin). Details can be found here: https://68kmla.org/forums/index.php?/topic/54481-cuda-egret-hc6805-hacking/ I believe that we need both hardware documentation and its precise emulation. Cheers Max -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190403/aed8617d/attachment.htm From elliotnunn at fastmail.com Wed Apr 3 13:38:57 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Wed, 3 Apr 2019 13:38:57 +0800 Subject: [CDG5] Git abuse In-Reply-To: References: Message-ID: <8CD753B1-89DF-44F7-B849-DFB1401D71B4@fastmail.com> Yeah, pretty much orthogonal commits. The trick, I think, will be to Keep It Simple Silly. Interesting formatting idea! I?ll chew it over. Of course, now that I?m using Git again properly, you can just submit a PR. ;) > On 3 Apr 2019, at 4:56 am, Daniel B-J wrote: > > Sounds cool. > > So the diffs show all the branches and releases and the commit history shows improvements to the diffs? > > I suggest having a tool automatically format the diff order graph into a .md file with links to all the diffs. > > If you were to take this to its logical conclusion, I expect the result would be similar to adding meta-commits (commits that alter arbitrary parts of the commit tree) to git. A pity we don't have that already. >> On Apr 2, 2019, at 2:04 PM, Elliot Nunn wrote: >> >> Since working on the 68k NewWorld ROM, I have used Git's commit tree to >> track three things at once: my changes to make the code buildable, my >> reconstruction of Apple's changes over time, and my desired changes to >> the code. Making these patchsets play nicely together has been >> difficult. Now, I am having difficulties reverting SuperMario to Cube-E >> that make me think that the Git-tree approach is not entirely workable. >> For example, it would be nice to show off a work in progress >> withoutfollowing up with "but I will rebase it to oblivion in 20 >> minutes". Splitting and lumping code changes meaningfully has also been >> a struggle. >> >> My proposed solution is to store patchsets in a public repository. >> Currently I am experimenting with the best `diff` settings to make these >> readable to a casual browser. I envision a collection of named and >> documented patchsets that can be manipulated by "applying" them into a >> separate Git repository. All the while the canonical version lives in >> the main public repository. Patchsets can be chained and scripts can be >> inserted to allow us to express our increasingly sophisticated >> understanding of the history of the code *and* its future potential. >> >> Thoughts? >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Thu Apr 4 23:24:13 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Thu, 4 Apr 2019 23:24:13 +0800 Subject: [CDG5] Git abuse In-Reply-To: References: Message-ID: <366450F0-D593-4818-8FDB-5A4BDF4751AC@fastmail.com> https://github.com/elliotnunn/supermario > On 3 Apr 2019, at 4:56 am, Daniel B-J wrote: > > Sounds cool. > > So the diffs show all the branches and releases and the commit history shows improvements to the diffs? > > I suggest having a tool automatically format the diff order graph into a .md file with links to all the diffs. > > If you were to take this to its logical conclusion, I expect the result would be similar to adding meta-commits (commits that alter arbitrary parts of the commit tree) to git. A pity we don't have that already. >> On Apr 2, 2019, at 2:04 PM, Elliot Nunn wrote: >> >> Since working on the 68k NewWorld ROM, I have used Git's commit tree to >> track three things at once: my changes to make the code buildable, my >> reconstruction of Apple's changes over time, and my desired changes to >> the code. Making these patchsets play nicely together has been >> difficult. Now, I am having difficulties reverting SuperMario to Cube-E >> that make me think that the Git-tree approach is not entirely workable. >> For example, it would be nice to show off a work in progress >> withoutfollowing up with "but I will rebase it to oblivion in 20 >> minutes". Splitting and lumping code changes meaningfully has also been >> a struggle. >> >> My proposed solution is to store patchsets in a public repository. >> Currently I am experimenting with the best `diff` settings to make these >> readable to a casual browser. I envision a collection of named and >> documented patchsets that can be manipulated by "applying" them into a >> separate Git repository. All the while the canonical version lives in >> the main public repository. Patchsets can be chained and scripts can be >> inserted to allow us to express our increasingly sophisticated >> understanding of the history of the code *and* its future potential. >> >> Thoughts? >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From danielbj314 at verizon.net Thu Apr 4 23:31:18 2019 From: danielbj314 at verizon.net (Daniel B-J) Date: Thu, 4 Apr 2019 11:31:18 -0400 Subject: [CDG5] Git abuse In-Reply-To: <366450F0-D593-4818-8FDB-5A4BDF4751AC@fastmail.com> References: <366450F0-D593-4818-8FDB-5A4BDF4751AC@fastmail.com> Message-ID: > On Apr 4, 2019, at 11:24 AM, Elliot Nunn wrote: > > https://github.com/elliotnunn/supermario Looks awesome. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/cdg5/attachments/20190404/af1fe6c3/attachment.htm From elliotnunn at fastmail.com Sat Apr 6 15:31:36 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Sat, 6 Apr 2019 15:31:36 +0800 Subject: [CDG5] Git abuse In-Reply-To: References: <366450F0-D593-4818-8FDB-5A4BDF4751AC@fastmail.com> Message-ID: Glad you think so ;) Everything builds. Custer is perfect-except-dates. Cube-E still needs more work than I thought, so I could use some help if anyone is keen! And I'd appreciate any feedback on the workflow. > On 4 Apr 2019, at 11:31 pm, Daniel B-J wrote: > > >> On Apr 4, 2019, at 11:24 AM, Elliot Nunn wrote: >> >> https://github.com/elliotnunn/supermario > > Looks awesome. > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Mon Apr 15 23:25:48 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Mon, 15 Apr 2019 23:25:48 +0800 Subject: [CDG5] System 7.1 hacking Message-ID: Hi friends, Just a silly but cool little thing I'm working on... https://www.dropbox.com/s/vqttrspcv634gdf/Screen%20Shot%202019-04-15%20at%2011.19.05%20pm.png?dl=0 (Spoiler for posterity: that's a System 7.1 splash screen in qemu atop a NanoKernel log.) The 7.1 reversal is going well. Apart from linked patches (probably a whole project on their own), I am down to about 22 relatively unimportant resources that don't quite build right. From danielbj314 at verizon.net Tue Apr 16 01:08:09 2019 From: danielbj314 at verizon.net (daniel B-J) Date: Mon, 15 Apr 2019 13:08:09 -0400 Subject: [CDG5] System 7.1 hacking In-Reply-To: References: Message-ID: <2754C923-9928-4C0E-B476-D6A39DEF3067@verizon.net> Is that the NKv2 on system 7? And doesn?t qemu only emulate NewWorld architectures? And system 7 doesn?t (normally) support NewWorld? This feels fun and confusing and impossible :) > On Apr 15, 2019, at 11:25 AM, Elliot Nunn wrote: > > Hi friends, > > Just a silly but cool little thing I'm working on... > > https://www.dropbox.com/s/vqttrspcv634gdf/Screen%20Shot%202019-04-15%20at%2011.19.05%20pm.png?dl=0 > > (Spoiler for posterity: that's a System 7.1 splash screen in qemu atop a > NanoKernel log.) > > The 7.1 reversal is going well. Apart from linked patches (probably a > whole project on their own), I am down to about 22 relatively > unimportant resources that don't quite build right. > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Tue Apr 16 08:36:19 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 16 Apr 2019 08:36:19 +0800 Subject: [CDG5] System 7.1 hacking In-Reply-To: <2754C923-9928-4C0E-B476-D6A39DEF3067@verizon.net> References: <2754C923-9928-4C0E-B476-D6A39DEF3067@verizon.net> Message-ID: <6D1D2A8C-D0B6-4235-B01F-5E7F0B0BCAB0@fastmail.com> Yes to all. I just inserted the output of my Cube-E build (plus some fixed-up resources) into a 9.2.2 System Folder. Then I started hacking the Cube-E source to spam the NK log via an F-trap, and kept disabling things till it got to the Process Manager. Then I got stuck because the Process Manager was calling the ROM InitWindows, which was trying to call the RAM Help Manager (Balloon Help), which wasn?t properly installed because I?d tanked the Linked Patches. > On 16 Apr 2019, at 1:08 am, daniel B-J wrote: > > Is that the NKv2 on system 7? > > And doesn?t qemu only emulate NewWorld architectures? > > And system 7 doesn?t (normally) support NewWorld? > > This feels fun and confusing and impossible :) >> On Apr 15, 2019, at 11:25 AM, Elliot Nunn wrote: >> >> Hi friends, >> >> Just a silly but cool little thing I'm working on... >> >> https://www.dropbox.com/s/vqttrspcv634gdf/Screen%20Shot%202019-04-15%20at%2011.19.05%20pm.png?dl=0 >> >> (Spoiler for posterity: that's a System 7.1 splash screen in qemu atop a >> NanoKernel log.) >> >> The 7.1 reversal is going well. Apart from linked patches (probably a >> whole project on their own), I am down to about 22 relatively >> unimportant resources that don't quite build right. >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 From elliotnunn at fastmail.com Tue Apr 16 11:33:54 2019 From: elliotnunn at fastmail.com (Elliot Nunn) Date: Tue, 16 Apr 2019 11:33:54 +0800 Subject: [CDG5] System 7.1 hacking In-Reply-To: <2754C923-9928-4C0E-B476-D6A39DEF3067@verizon.net> References: <2754C923-9928-4C0E-B476-D6A39DEF3067@verizon.net> Message-ID: <328527F8-9D94-48C0-B2F7-8BA3D5FD0473@fastmail.com> I've given it up for now, but it was a cool proof of concept! https://github.com/elliotnunn/supermario/tree/master/patchset/NewWorld-Cube-E > On 16 Apr 2019, at 1:08 am, daniel B-J wrote: > > Is that the NKv2 on system 7? > > And doesn?t qemu only emulate NewWorld architectures? > > And system 7 doesn?t (normally) support NewWorld? > > This feels fun and confusing and impossible :) >> On Apr 15, 2019, at 11:25 AM, Elliot Nunn wrote: >> >> Hi friends, >> >> Just a silly but cool little thing I'm working on... >> >> https://www.dropbox.com/s/vqttrspcv634gdf/Screen%20Shot%202019-04-15%20at%2011.19.05%20pm.png?dl=0 >> >> (Spoiler for posterity: that's a System 7.1 splash screen in qemu atop a >> NanoKernel log.) >> >> The 7.1 reversal is going well. Apart from linked patches (probably a >> whole project on their own), I am down to about 22 relatively >> unimportant resources that don't quite build right. >> _______________________________________________ >> cdg5 mailing list >> cdg5 at ucc.asn.au >> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5 > > _______________________________________________ > cdg5 mailing list > cdg5 at ucc.asn.au > https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5