Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[famicomaster2]

Hello! I'm new here, and I joined because I'd rather not run OS X on my iMac G3 Grape. I was wandering around the internet looking for homebrew updates that I figured would have come out.

One of the biggest projects I've seen (and the one I was personally most interested in) was the pinned 9.3 thread. I'd love to see something like this come to fruition one day, but it doesn't look like the thread has seen a post in a long time now.
Rather than bump a very old thread, I figured I'd just make a new one and ask what happened.

I'd love to provide any help I can if the project is still going, I'm more of a Windows programmer myself, but I'm getting into OS9 lately. I've got my aforementioned iMac G3 Grape with 9.2.2 and two PowerMac G4s lying around, one with 9.0.4 and the other with 10.4.11. If G5 support ever comes as mentioned in the thread, I have a dual G5 machine with 10.4.11 that's sitting around doing nothing. I plan on getting a PowerBook G3 of some kind soon because I'd like to be portable and avoid emulators.

I think new, community driven updates to an aging OS are a great way to keep users and onlookers interested and can help provide a better experience for everybody! Think Whited00r and Grayd00r (iOS 3, 5 patches to update them).

All that being said, I also wanted to point out some things I feel would really improve the quality of life of OS 9 in the modern world:
-Fix the clock for 2040
-Maybe 2GB patch? Seems like one heck of a rabbit hole but could prove useful
-H264 for QuickTime
-Classilla rendering updates, maybe HTML5?
-USB 2.0
-Support for wireless outside of AirPort
and personally removing the last of the 68k from the system would probably be a great help as well.

Again, I'd love to be a part of this project if it's still going on! I've got no clue where I would even start writing an update like this, but once I gain some momentum in a project I have trouble stopping.

[Daniel]

The project is still active, but is rather quiet.

We are mostly trying to build various core components from source. We have made significant progress with that, but haven't been working all that much on objectives actually noticable to other people. I think our last major success was getting the Mac mini to boot 9.2.2.

If you want to help out, great! Most of the important stuff ican be found at https://github.com/elliotnunn/cdg5. The mailing list is important enough for me to link to separately: https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5.

No particular Mac system knowledge is needed. I knew basically nothing when I joined.

[famicomaster2]

That's still news to me, I'll definitely sign up for the newsletter and keep an eye out for future updates.

If anything is needed of me, you know where to find me, always willing to help on such an interesting project!

Like I said, I have several older Macs (mostly PowerPC) that I wouldn't mind messing around with a bit to get some results.

Is there a Discord or an IRC I need to join to be involved, besides the mailing list?

[IIO]

the last thing i remember was that one of you wanted to build a forth decompiler in order to completly disassemble and understand the macos 7 nanokernel.

sounds like a lifework. well, you have yours and i have mine.

[ELN]

We have made some large reverse engineering efforts. You can wear down any system if you stare at it hard enough for long enough. NanoKernel, ROM, bootloader, some Open Firmware (Daniel knows most the about that last one). Even, lately, System 7.1 itself.

But right now I’m working on a relatively easy-to-use toolkit for the casual experimenter to edit all kinds of Mac ROM files. It should let you make meaningful changes to the very deepest parts (and they are deep) using a hex editor, text editor or a library of known-good patches. After all, who is a more formidable hacker than a member with a weekend and an OS 9 install disc?

[MacTron]

After all, who is a more formidable hacker than a member with a weekend and an OS 9 install disc?

[famicomaster2]

We have made some large reverse engineering efforts. You can wear down any system if you stare at it hard enough for long enough. NanoKernel, ROM, bootloader, some Open Firmware (Daniel knows most the about that last one). Even, lately, System 7.1 itself.

But right now I’m working on a relatively easy-to-use toolkit for the casual experimenter to edit all kinds of Mac ROM files. It should let you make meaningful changes to the very deepest parts (and they are deep) using a hex editor, text editor or a library of known-good patches. After all, who is a more formidable hacker than a member with a weekend and an OS 9 install disc?

That's pretty great to hear, actually. I'd love to give it a try whenever it's ready!

[OS923]

-Fix the clock for 2040

This one has been solved.
http://www.macos9lives.com/smforum/index.php/topic,2862.0.html

[famicomaster2]

Maybe it's just me, but the current "Resurrection" 2040 fix seems a bit... Rough around the edges. I feel like if anybody were to actually go through the process of making a full update, it could work around the problem in a more elegant way, though I don't expect either to actually happen.

[OS923]

Pardon me for not being more elegant, but it worked on my computer as I have demonstrated and illustrated.

[IIO]

it is still 20 years ahead and many things can happen until then.

[ELN]

One tricky problem that might not have been solved yet is of time comparisons. Much but not all old Mac software has a signed-compare bug that makes 1904-1970 seem later than 1970-2038 (hence the pre-1970 warning at startup if your battery is bad). Any offset applied to the interpretation of the system time will move this frontier forward and cause (for example) sorting to come out wrong.

Perhaps we could map the final few ticks of the system time scale to an exponentially increasing sequence of real time. That way, disk storage would be forward and backward compatible. We would then introduce a new 64-bit low-memory variable to provide high-resolution times to the user-facing APIs.