Quake on NeXTSTEP 3.3

Posted on by

I’m one third of the way there…..

At least the video is kind of working… Right now I’m still using the cannibalized stuff from the UAE project’s port to NeXTSTEP. This is what I used for Frontier, although I’d like to think I’m getting a slightly better handle on it. Right now I just have to figure out why my keyDown & keyUP handlers are not working…. And implement the timer so it doesn’t run at warp speed. With the timer in place it should be able to do network play.

I suspect this would be FAR too slow to play on the m68k,Sparc or HPPA hardware but then who knows… My monitor for my m68k is broken so I can’t run it to find out…

Quake for NeXTSTEP

Quake for NeXTSTEP

This runs VERY fast on Qemu 0.90 I may have to rewire some stuff to run in on my whitebox, but I have a feeling I’m going to have to re-install… I forget where I left off on my NeXTSTEP setup on the old P4.

Anyways that’s what I have for the last few hours….

12 thoughts on “Quake on NeXTSTEP 3.3”

  2. It wont load, lots of problems with the PIC, the interrupt controllers, the PS/2 mouse.. and the new bios just sucks for legacy stuff…

    Sadly the qemu people aren't interested in the -M isa stuff either…

    This version of 0.90 is 'hacked' to add busmouse support to get around the busted ps/2 mouse..

    nextstep was VERY picky on real hardware, let alone virtual setups..

  3. Did you report the -M isa regressions? Maybe the people are just not aware of the problems there?
    Is 0.90 really the last good one?

    What BIOS is the new one? I thought qemu still comes packaged with few ones for x86 arch. Which bios didn't suck?

  4. I know that after 0.90 there was a whole change in the way things work, as gcc 4.0 doesn't support the method they were using in gcc 3.0 for doing the dynamic translation…

    The new 'seabios' just hangs in the -M isa, and worse you can't use the old bios images….

    I haven't bothered as support for things like NeXTSTEP, Xenix & Netware just isn't a priority to the qemu people.. 😐

      • Cool, I’ll check out that. I’ll paste the full config when I get home if interested. But basically I set up an SS-5 with 256MB RAM, using the default TCX framebuffer. I’m using a dump of a real SS-5 PROM. I haven’t tried yet with the default firmware to see if that works.

        NS 3.3 needs the framebuffer to be in 8bit mode (default) as it kernel panics in 24bit mode. I also suspect NS may need devices on specific unit IDs so for simplicity I created a disk image and attached it as unit 3 and the CDROM iso was attached as unit 6 and booted with ‘boot cdrom’ from the OBP.

        There does seem to be race condition of some-sort when doing disk I/O which hangs NS but forcing single CPU affinity seems to prevent this. I’m using Linux so I ran qemu-system-sparc prefixed with taskset –cpu-list 1. There might be a better way of doing it via the qemu accelerator.

        After the initial miniroot install, you can boot from the disk with ‘boot disk3’ from the OBP. It appears to hang on boot up, but a CTRL-C kicks it into gear. It seems to be doing DHCP here – it may time out if left long enough. My DHCP server could see the requests and was sending ACKs but for some reason NS still keeps sending requests.

        After the initial config, /etc/fstab doesn’t seem to get set up correctly (dunno why yet) so it drops into single user mode but remounting / as rw and fixing /etc/fstab makes the system boot up correctly. Assigning a static IP works and the guest is pingable and it actually seems quite stable.

        Oh and this was Qemu 2.9.1

  6. taskset –cpu-list 1 qemu-system-sparc -M SS-5 \
    -bios sparcstation5-170.rom \
    -m size=256M \
    -drive if=scsi,media=disk,bus=0,unit=3,file=nextstep33-sparc.qcow2 \
    -drive if=scsi,media=cdrom,bus=0,unit=6,file=nextstep33_sparc_parisc.iso \
    -net nic,macaddr=00:16:3e:00:00:02 \
    -net tap,ifname=tap-nextstep33-sparc,script=./ifup-nextstep33-sparc,downscript=no \
    -name “NeXTstep 3.3 – SPARC” -g 1024x768x8

    The network script basically looks like this

    ifconfig tap-nextstep33-sparc 0.0.0.0 promisc up
    brctl addif bridge0 tap-nextstep33-sparc

    I already have bridge0 bridging several physical ethernet interfaces so I didn’t need to do anything special for that

    • I tried it,. Granted I’m using the Linux subsystem on Windows 10, compiled qemu sparc just fine but I get hangs when it’s copying files… I think you have the only working copy

      • Interesting. Does taskset work in the Linux subsystem under Windows 10? Setting the CPU affinity seems to be key for me. If I don’t do that, then it hangs all the time on disk I/O, basically making it useless. You can set CPU affinity on a running task in Windows 10. If you’re using Windows 10 it would be interesting to see if that works on the windows version. The good news is it also seems to work perfectly fine with OpenBIOS 1.1, although I haven’t tried the install process under OB.

        Quake works by the way and seems quite playable. It complains that Quake.app is invalid but if I run it from the command line (ie cd into the Quake.app dir) and run the binary it, works. The colours look inverted though. Not sure if that’s a side effect of the 8bit screen mode or a colourmap / endian issue.

        • it has the affinity tags, but hangs… I’ll have to launch from a real Linux I guess….

          Im not surprised about colour issues at all though, but more so surprised it works at all.

Leave a Reply