[TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)?

[segaloco via TUHS]

Hmm, Briam, might I ask what your process was?  I'm finding quite a few
discrepancies, for instance, when I put this copy of as(I) through a
PDP-11 disassembler, I get an entry something like (syscalls filled in):

000020: 000167 016316       	jmp	16342			; w.N.
;
000024: 004767 000632       	jsr	r7,662			; w...
000030: 116700 011562       	movb	11616,r0		; @.r.
000034: 104404              	sys	write; $52614; 1000
000042: 116700 011550       	movb	11616,r0		; @.h.
000046: 104406              	sys	close			; ..
000050: 116700 011545       	movb	11621,r0		; @.e.
000054: 104406              	sys	close			; ..
000056: 105767 005466       	tstb	5550			; w.6.
000062: 001041              	bne	166			; !.
000064: 004567 000230       	jsr	r5,320			; w...

But this same chunk of your as.s you sent:

/ start of program
start:
	jmp	main

/ error handling
error:
	jsr	pc,pass1
	movb	errflg,r0
	sys	creat; tmpf1; 1000
	movb	errflg,r0
	sys	creat; tmpf2; 0
	movb	passno,r0
	tstb	dotflg
	bne	1f
	jsr	r5,errstr
		<-e\n\0>; .even

I'm really confused where those creat's came from, whats going on there
is quite different than what you sent me.  The former, what I got out of
my own disassembly of the file, matches as11.s in both V2 and V5.  I
have my doubts this entrypoint changed that much between V2 and V5 only
to wind up the same again in V5.

Are we working from two different sets of binaries?  I just want to make
sure before I put much more time into aligning these with known V2 and
V5 sources.  My goal for the v2src repository is that it should diff
appropriately with known, real sources, that's one of my quality gates
I'm applying here.

- Matt G.

On Friday, January 16th, 2026 at 14:11, Briam Rodriguez via TUHS <tuhs at tuhs.org> wrote:

> Hi Matt,
> 
> Saw your post about the v2src restoration project. I took a crack at
> disassembling the remaining binaries from the s2-bits tape -
> specifically the bin/ directory utilities.
> 
> I've got 26 commands disassembled and formatted to match your existing
> style conventions:
> 
> as, bas, cc, db, dc, ds, du, ed, fc, find, form, ld, maki, mv, nm, od,
> pr, roff, size, sort, stat, tap, tm, un, wc, who
> 
> They're ready as a patch file. Please find it attached. I tried creating
> a PR on gitlab but it wouldn't let me due to auth issues.
> 
> Happy to help with more disassembly work if there are other artifacts
> worth looking at.
> 
> -- Briam R.
> 
> On 1/16/26 5:06 PM, segaloco via TUHS wrote:
> 
> > Hello everyone, I've been picking back up on some of my V2/V3 era
> > reverse engineering efforts, picking through stuff from the Dennis_Tapes
> > archive, and I came across something I don't think I've seen discussed.
> > 
> > On the s1 tape, which we've yoinked a lot of V3 userland sources from,
> > there are files cunix and wunix. Upon some disassembly and inspection,
> > I believe these may be assembly UNIX kernels, although I haven't dug
> > around too much to see what version they match most closely. Here are
> > some findings that support my suspicions:
> > 
> > - Both files begin with a 407 magic number, making them V2 a.out
> > binaries.
> > - Both begin with a branch that jumps over a few things then calls a
> > subroutine. That subroutine matches "copyz" from u3.s in the scanned
> > V1 kernel description from BTL. Indeed this jump in that kernel is also
> > to copyz.
> > 
> > Of course, this is only the first few bits executed, but I would be
> > surprised to find such a close match elsewhere in the system. I do this
> > sort of analysis on old video game code all the time, so I feel pretty
> > confident in identifying these as possible assembly-era kernels.
> > 
> > Anyone dug around in these before? These should be PDP-11/20 kernels as
> > I'm finding plenty of EAE references, just like the s2-bits V2 binaries.
> > What I'm hoping to find here are bits that might indicate KS11 support,
> > what with the recent chit chat about KS11 in the V2 kernel.
> > 
> > - Matt G.