Back

But depending on my `fdconfig.sys` I either get it in a boot-loop (IDK if from b.com or 9dos) or a kernel-panic from 9dos ("double fault"... at least it's getting out of b.com!).

Anyone have troubleshooting resources for adjusting #FreeDOS `fdconfig.sys` or #Qemu flags (or other emulators) for circa-1992 software?

I'm too young to remember config.sys, and my #RetroComputing hasn't involved much #DOS yet.

It was known to work on the "AT&T Safari", "AT&T 6386", and "Gateway 486". That probably means MS-DOS 3.2 or 4.01.

In the long-run, the easiest way to run #Plan9 1e (esp on non-PC platforms) will probably be to write a simple #GNULinux server program that serves BOOTP (pre-DHCP!) + TFTP for PXE boot, and #9P of the archive tarball. But 1e uses a much too old dialect of 9P for any existing software except for 1e itself to be able to serve it. And I don't want to try to write a server for it if I don't have a client to test with.

So getting `/sys/lib/pcdisk` to boot from FreeDOS is in the bootstrapping path.

Actually, #Plan9 4e has a program for serving the old 2e/3e protocol (9P1). And so maybe 2e has a program for serving the old 1e protocol (which I call 9P0)?

So if I can't get the 1e stand-alone PC version working, maybe I get 4e serving PXE+9P1 to boot 2e, and then I get that serving 9P0 to boot 1e?

Keeping the boot quirks of multiple versions of Plan9 straight in my head at once doesn't seem fun tho.

Actually, I think u9fs can serve both 9P2000 and 9P1. So I guess I could cut 4e out of that chain.

WAIT! 1e had /sys/src/cmd/unix/u9fs/ too! That'll serve 9P0! It'll probably take some minor modification to get it to build on a modern system, but that is another potential path.

... and it's after the scheduler has started :(

I was really expecting it to be in early initialization. That would have made debugging it a lot easier.

And I'm evidently confused about how the memory map is set up. I seem to have (most of?) the code in the right place in ghidra, but global variables are clearly wack.

"return 0 if OK, -1 if bullshit"

So I figured out yesterday that `BOOT` is not defined (as in `#ifdef BOOT`). But I still had some assumptions about the memory map in my head that were based on assuming that #ifdef BOOT

Besides the fact that I've mostly been dealing with ARM for the last few months:

Any hope of keeping x86 asm operand order straight has been annihilated by dealing with 3 different assembly syntaxes: whatever it is that GDB shows me (AT&T syntax), whatever it is that Ghidra shows me (Intel syntax), and Plan 9 assembler (which--despite being out of AT&T--superficially looks more like Intel syntax but with AT&T order).

Why is #ghidra's memory map editor so difficult to use?

Like if I can see what it is, and I know what it should be, why is the UI for getting from point A to point B so clunky?

So from the kernel's initialization, I have figured out exactly which region it considers to be BSS. And there's conspicuously a gap between data and BSS in the memory map.

I have data right after text. But looking back at the bootloader, isn't read into `text_addr+text_size`, it's read into `PGROUND(text_addr+text_size)`, so fingers crossed that moving that forward a bit makes things start making sense!

The memory map now indeed makes sense in ghidra! And the gap between data and BSS went away.

And I got to the login screen!

...

by trying to single-step to find the crash. I guess it's timing related where the kernel couldn't handle the CPU going that fast?

But now it's hanging at "fs..."

in the kernel:

char Egreg[] = "it's a thermal problem";

in userspace:

[Egreg] "it's all greg's fault",

(Egreg is returned for all kinds of miscellaneous errors)

Who is Greg? #Plan9 #RetroComputing

@lukeshu I’d really like to make a set of downloadable, runnable qemu images for the different editions.

@a I'm working on it less actively than I was over the holidays.

I'm more interested in scripts to build images, being a fan of "show your work" :) As far as the "Qemu" part of it, 1e's docs have a very specific list of SPARCs that it can run on, all of which are too old for Qemu, but looks doable with MAME or TME. Similarly, the MIPS port needs a MIPS Magnum 3000, but Qemu only goes down to the 4000, but looks doable with MAME. The NeXTstation port looks doable with https://sourceforge.net/projects/previous/ .

@a And I haven't looked into the emulator situation for SGI, because 1e's SGI port is CPU-server-only; non-graphical.

I'm not sure what edition it changed in, but 1e's file-server OS was a totally separate OS from the "normal" CPU-server/terminal OS. A rather hacked-up copy of the normal kernel.