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

[Briam Rodriguez via TUHS]

Matt,

Sorry about that! I made errors in my syscall identification process - 
the structure looked roughly correct but the actual trap numbers were 
wrong. Your disassembly showing sys write and sys close are correct; 
mine had sys creat which doesn't match the opcodes at all.

Please disregard that patch, seems I was a bit too hasty to contribute!

I've since built out a proper validation workflow: assemble with the 
actual V2 toolchain via Apout, then byte-compare against the original 
binary. If it's not identical, it's not done.

As proof of concept - while validating this process against your 
existing sources, I found a 1-byte discrepancy in strip.s at offset 
0xF4. The bne 1b branch target was wrong because the 1: label was placed 
before the size calculation rather than before the cmp r2,r3. The 
original binary's inner loop only re-checks the comparison. I can send 
you the fix if you'd like - it now assembles to byte-identical output.

I'll send properly-validated reconstructions once I've worked through 
the kinks!

-- Briam

On 1/16/26 7:59 PM, segaloco via TUHS wrote:
> 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.