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.

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.

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

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

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

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 :)

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.

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

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.

neozeed wrote:

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

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?

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!!!!

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