Mac68k Forums

Home


Welcome, Guest
Guest Settings
Help

Mac68k Forums » Development » Software Hacking

Thread: Graybox FDisasm


Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 3 - Pages: 1 - Last Post: Apr 4, 2013 3:30 PM Last Post By: bbraun Threads: [ Previous | Next ]
bbraun


Posts: 493
Registered: 7/25/12
Graybox FDisasm
Posted: Sep 15, 2012 1:12 PM
Click to report abuse...   Click to reply to this thread Reply
I was introduced to Graybox recently, which appears to be abandoned lately.
Graybox takes minivmac and bridges various A-traps to PPC Carbon, resulting in a more or less "native" OSX experience for the app. Filesystem access is of the host system, not within the minivmac instance, and there's no "root" window, app windows are drawn side by side with host OS windows.

Graybox really is a full minivmac instance, it includes a Mac Plus ROM, and a System 6.0.7 System file. The app you want to run gets called "Finder", which MacOS will of course launch on boot.

landonf helped me get this loaded into an Xcode project, and it's now building in Xcode 3.2 on Mac OS X 10.6.

I've been living & breathing fdisasm lately with all the IIsi ROM disassembly, so I figured I'd try getting Graybox running it:
FDisasmG 1.1.3.zip
This only works on Mac OS X 10.6, FWIW.

There were a couple changes I needed to make to get FDisasm working in it (in addition to the conversion from a CodeWarrior project to Xcode):
1) MacOS calls to HGetVol to get the current working directory would return App.app/Contents/Resources/System Folder, since that's where the "app"/Finder is running from within the emulator. This isn't terribly useful, since the whole point is to present a single native app, rather than expose an emulated filesystem. So I modified the GetVol implementation to return the directory the app bundle lives. I also had to fix some bugs in the GetVol implementation, not all of the HGetVol information was being returned through to the emulated app.
2) Implement SetFPos. Graybox didn't support this trap. Now it does.

That's more or less all it took to get things working. We've got an svn repo for the source at https://mac68k.info/repo/graybox Again, forum members should have access.
bbraun


Posts: 493
Registered: 7/25/12
Re: Graybox FDisasm
Posted: Sep 18, 2012 11:27 AM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
FWIW, I removed the 10.6 requirement (it was naive use of 10.6 only CF) in the svn repo.
superpete

Posts: 18
Registered: 4/4/13
Re: Graybox FDisasm
Posted: Apr 4, 2013 6:51 AM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
By any chance does moving to X Code allow for an Intel version, or is there too many endianness issues to resolve?

Also just discovered this forum, I'm in awe!
bbraun


Posts: 493
Registered: 7/25/12
Re: Graybox FDisasm
Posted: Apr 4, 2013 3:30 PM   in response to: superpete in response to: superpete
Click to report abuse...   Click to reply to this thread Reply
graybox is just passing the data straight through to Carbon, so no endian swapping. Which means no x86 without going through and frobbing all the structs. That's entirely possible, although tedious. But at the end, you've got a 32bit x86 binary that requires Carbon, which doesn't really buy you much. Which is why I've kind of dead-ended on this particular project. A better approach would be to use executor. I took a look at hacking on it, but it looks like a pretty steep learning curve to understand the executor way of doing things. That and my TODO list overflows as it is. :)

Point your RSS reader here for a feed of the latest messages in all forums