As anyone who's tried to run NeXTSTEP or OPENSTEP on qemu-system-sparc knows, it's so close but has so many rough edges.
I'm currently chewing away at the edges of those problems. When I have a ready fork, I'll post it here. I currently have it working, enough to boot and run, but graphics are limited to 8-bit, sound doesn't work and booting is... janky.
Attached is a MacOS/aarch64 binary to try out - you'll have to install the rest of qemu and make sure the data files are in place, but if you want to experiment, feel free. Something more polished will be here when it's ready.
The Git repo for my fork is here: https://github.com/jadenekotenshi/qemu (https://github.com/jadenekotenshi/qemu)
What I've fixed/kluged:
TCX now supports 1152x900 modes
SCSI hang is fixed, allowing NS/OS install
Lance self-test is fixed, allowing network boot
NVRAM can now be made persistent
Sound now works for the SPARCstation 5. We are the SPARCs who say "Ni!"
Stub parallel port implemented, enough to prevent NetBSD from crashing.
Several small bugs (keyboard detection on NetBSD, scary-sounding SCSI faults on OPENSTEP) have been patched.
See the attached shell script for an example config.
More fixes:
A number of bugs that jam up the official SPARCstation 20 ROM have been fixed
The CG14/SX framebuffer is partially implemented; NetBSD can run X on it but OPENSTEP is still having some issues, which should be fixed shortly.
SPARCstation 10/20 DBRI still unimplemented.
CG14 now mostly works, enough to boot to a desktop in NetBSD and OPENSTEP, though Solaris is still having issues.
Sound is... partially implemented but broken. The driver will load in OPENSTEP, but don't try to use it.
Derp!
You're looking for the "sparcstep" branch in my fork.
I'm still working on getting Solaris working correctly on SPARCstation 20, but right now both the CG14/SX framebuffer and DBRI sound chip work correctly under NetBSD and OPENSTEP.
CG14 now supports 1024x768, 1280x1024 and 1600x1280. 1920x1080 support should exist but currently doesn't - it's coming soon.
1920x1080x8 support now works. 8MB of VRAM isn't *quite* enough to do 1920x1080x24, but 1600x1280x24 is possible.
1920*1080=2,073,600 (so isn't that must 2MB at 8bits per?). So wouldn't 24bits only be around 6MB? Maybe there is other overhead. Might 16bits work?
Regardless, KUDOS for getting that to work!
24-bit color is internally represented as 32-bit with 8 bits of padding, so it takes a bit more than 8MB. 16 bit color would work, but the driver doesn't support it, only 8 or 24 (kind of a Solaris-ism).
The issues with Solaris should be solved. Additionally, you can now add an HME fast ethernet device to your SPARCstations. I'm working on an HME driver for OPENSTEP (I have one that mostly works - repo coming soon.)
The PR2 release of OPENSTEP 4.0 had SPARC support. Here it is in action thanks to Jade's QEMU fork, emulating a SS20 with a CG14 framebuffer and the max 448MB RAM.
PR1 had HPPA support but no SPARC while PR2 had SPARC but no HPPA.
os40pr2_sparc_desktop-1.png
Quote from: Protocol 7 on Oct 07, 2026, 10:05 PMPR1 had HPPA support but no SPARC while PR2 had SPARC but no HPPA.
That is an amazing fact and a gorgeous PR2 screenshot. Absolutely something for the wall of fame. :)
If you've been using my fork, do yourself a favor and pull the latest; SPARCstation 10SX support should work now, as should HME.
Quote from: Rhetorica on Oct 08, 2026, 06:00 PMQuote from: Protocol 7 on Oct 07, 2026, 10:05 PMPR1 had HPPA support but no SPARC while PR2 had SPARC but no HPPA.
That is an amazing fact and a gorgeous PR2 screenshot. Absolutely something for the wall of fame. :)
To add to that, PR1's kernel is quad-FAT but there's no /usr/standalone/sparc folder and most of the apps lack SPARC support. For example, the Upgrader app supports SPARC but Workspace doesn't.
Quote from: Protocol 7 on Oct 09, 2026, 09:56 AMTo add to that, PR1's kernel is quad-FAT but there's no /usr/standalone/sparc folder and most of the apps lack SPARC support. For example, the Upgrader app supports SPARC but Workspace doesn't.
I think that may actually be the
only case of a quadfat kernel in all of history, for any platform, ever.
3.3.47 was mastered 1995/02/15 (RISC, SPARC+HPPA)
4.0 PR1 was mastered 1995/09/02
4.0 PR2 was mastered 1996/02/07
I suspect there's a
lot of development history that can be uncovered by reading file dates...