If he's going to port, I'd shy away from GTK+ in favour of Qt. WxWidgets is of course always a good solution.

If rendering is just needed and no gui you could use SDL.

I actually tend to prefer a command-line binary based on SDL with a front end using Qt or WxWidgets. On a Mac, you can just drop the binary inside the GUI app even Plus, it means if someone wants to write a system-native GUI, they can.

Just look at MAME for a successful project that operates this way.

I'm looking into writing a small SDL gui for POSIX-y systems, which might exclude windows. I haven't written code on windows in a long time, but I don't remember it having great native POSIX support. Maybe using Cygwin is an option, if that's still around. Most recently I committed a small GLUT-based debugger app which might compile on Linux/*BSD - though I haven't tried to yet - but it's not really meant for public consumption. If anyone's a really dedicated A/UX fan and linux nerd, they can try to compile it. Pro tip: just type "continue\n" and it'll begin executing.

In other news, PRAM is now working! :D The VIA code had to be extensively refactored to make this happen, but I'll try to get this integrated into the GUI and crank out a release soon. Not much progress has been made on 3.0.1 support, but I'll definitely try to get clean not-crashing restart working for v0.0.3.

Shoebill also has a new mascot, with props to http://dirtiran.deviantart.com!

Wow! That's great news about PRAM! Just so you know, that means at this point you know enough about hardware/system interfaces that if you ever wanted to change jobs, you've got a lot of really good companies that would be more than willing to hire you

As for SDL, it compiles on Windows, either natively or under Cygwin or MinGW. MinGW's probably the easiest to get working, without all the dependency headaches you can get with Cygwin.

Might be worth creating a headless target anyway, so that others could set it up using command-line switches only and/or provide their own GUI. Keep the native GUI by default though; I know I sure appreciate it

Dumped a new shoebill release on github! v0.0.3
https://github.com/pruten/Shoebill/releases

• Now supports restart/shutdown without crashing
• Now supports PRAM!
• Now idles when A/UX's scheduler idles
• Has limited support for the real time clock. It usually gets the *day* right, and it usually progresses forward monotonically (working on it)
• Supports full screen mode
• Other little fixes

Still working on getting 3.0.1 to work, and addressing all the weird random freezes and crashes...

Great work you are doing with Shoebill
Are you able to fix the random stuttering?

Thanks I'm actually not even sure where the stuttering comes from. I think the still-not-working VIA timers might be responsible. Another possibility is the fact that the CPU blocks while waiting to read disk image data during SCSI reads, but that doesn't really explain the freezes I'm seeing (but then I've only ever run shoebill from a SSD, so perhaps that really is causing worse stuttering on other people's machines...)

Hi,

Great progress. I experience no stuttering. But I also run from an SSD.
Restart and direct availability of a working mouse really improve the user experience

Best,
Cat_7

Also, there isn't a way for me to cancel the A/UX boot sequence to run fsck, since it goes too fast and I can't click the cancel button.

There needs to be a way to fix the filesystem, either through the emulator GUI or outside the emulator. Any suggestion?

I've considered maybe emulating fsck directly (via emulated syscalls), but in general, I just boot into verbose mode. It'll run fsck automatically.



Also, as of 0.0.3, A/UX filesystems should be severely corrupted less often. This is because A/UX automatically syncs mounted filesystems every 30-60 seconds, and prior to the real time clock working, it couldn't actually count that high. So now you can expect more data to have been sync'd after a crash.

Any chance of adding snapshotting/journalling on the emulation side? This should at least enable reverting to last known good state after corruption.

Yeah, that's something I'd definitely like to do in the future, perhaps as part of a more sophisticated disk image infrastructure. That plus automatically wrapping plain HFS volumes in a partition map so that A/UX can recognize them, and maybe adding .dmg / disk copy support.

Nearer term plans include figuring out why 3.0.1 won't boot, fixing a bunch of bad scsi behaviors, 16/32-bit video, and maybe getting sound working a bit.

Also, I've recently discovered that the System 7 time manager on A/UX doesn't use microsecond VIA timers. Instead, it fakes it by multiplying the 60hz "tick" timer by (1000000/60). The 60hz clock does work, so I'm not sure why there are so many weird timing issues on A/UX 3.0.0...

How do I get my empty disk image to mount? I added an empty disk image, but no format box shows up.

Hi,

On the pages 2/3 of this thread there are diskimages you can download and an explanation of how to create your own.

Best,
Cat_7

ah, okay, thanks for the tip!

What I've been doing is,

And then using Disk Utility.app to create an Apple Partition Map with 1 HFS+ partition. System 7 will recognize the pmap, and give you the option to reformat the partition.

Also, just got "thousands" and "millions" of colors working!

By popular demand, there is now a linux port! It's not complete yet (lacking PRAM, and support for config files), and it can only be built by hacking up the makefiles. Not quite sure how to do cross-platform makefiles... But I'll try release a 0.0.4 binary for linux as well as OS X.

This might help with the makefiles:
http://llvm.org/docs/CMake.html

Of course, that's using CMake; you could use a different makefile generator (there are a number).

If you want to do it all by hand, it'll get trickier, but you'll need to query the BUILD_ENV among other things.

Or you can take a page out of Mini vMac's playbook, and make Shoebill the dev environment, and have it generate the appropriate makefile ;) Not so good for having a non-dev-environment target though.

well the good news is that I got it to compile on windows! ...




The bad news is that it doesn't work.. I don't know offhand why it's computing a checksum of zero.. the file is there, I guess I'll have to dig deeper... And I guess it's related to ntohl in winsock not doing it's job correctly, or the replacemnt I had to use for fseeko...

_________________
don't do today what you can put off until tomorrow.

more progress... Turns out that there is a lot of "fopen" stuff that never specifies BINARY MODE... MinGW defaults to ASCII so yeah.



For some reason the filesystem type is 520 bytes, not 512... so one of the datatypes has a mismatch.

But you know, progress!

_________________
don't do today what you can put off until tomorrow.

Wow! I didn't expect to see it running on windows so soon! I was truly planning to switch the fopen() mode to binary Not sure why you're hitting panics now... "exec = 'startmac'" indicates that the kernel booted and is running the mac virtualization environment. "physaddr = 0x6369a26f" is definitely bogus.



Hmm... presumably the root filesystem should be UFS and not SVFS. Is it possible the root filesystem is mangled from having run with fopen in ASCII-mode?

it's to do with the packed structures.

apparently it's a thing where structures under MinGW are a different size than Linux, and there is a 'simple fix' with the cflag

-mno-ms-bitfields

So it got much further!...



And it was crashing in either memory or video... So like an idiot I tried to mess with the source, and now ... I can't build it. I just purged, and rebuilt and I get a white screen..... It's stuck somewhere in the source.

It's getting late, so I'll zap it and try again tomorrow... but yeah, so close under Windows, it basically boots up, switches video modes, then corrupts the screen, and as soon as the corruption touches the mouse pointer, or an element on the screen it's updating itself and it crashes.

ARGH!!!!

-----edit
so I purged everything, and rebuilt. again and again.. and now it's working!!!!!! turns out that signals on windows just aren't needed.



Binary is here, and source code is here.

Sorry for anyone who wants to download, you have to deal with the idiotic password system

_________________
don't do today what you can put off until tomorrow.

Amazing to see a Windows port. Thank you! Now for the noob question: what's the command line required to run your bootable disk image??? Thanks for any help.

I hard coded it to my liking....

so looking at sdl.c



this is what it will do by default.

full options are



so you can launch it something like this:

_________________
don't do today what you can put off until tomorrow.