TUHS

tuhs@tuhs.org

27 participants
6496 discussions

[Unix-jun72] UNIX running up to init, I think

by James A. Markevitch

Hey guys. I saw the thread about the assembler doing divide by 2 the wrong way. I took a look at my assembler and it had a similar bug. I fixed my assembler, then ran the code again. It correctly writes the RF11 image (as best as I can tell), then reads /etc/init into the user area and executes it. I left the TC11 disabled on my run and it panics when /etc/init tries to read the tape. To double-check, I ran the warm boot and it successfully gets into the /etc/init user code as well, so I'm pretty confident the image is right. As far as I can tell, the source code I sent out this morning has no problems. Most likely, you guys are fighting assembler and/or other tool issues. I'll cobble together a bootable RF11 image (assuming that there really are no kernel problems) and send out a copy of that. Once everyone has that, they should be able to continue generating tapes and RK03 images of other executables, etc. I can include a copy of the assembler listing file for both warm and cold boots so that everyone can have a reference while they are debugging. I've also got the M792 boot (from the documentation) as well as an untested bos.s. If those work, then the RF11 image I send out will be pretty close to authentic. Otherwise, you will still need to load the kernel into core with the "load" command. James Markevitch

17 years

[Unix-jun72] OCR of PreliminaryUnixImplementationDocument_Jun72.pdf

by James A. Markevitch

I'm sending Brad a copy of a different OCR of the document that he can use to check against the current one. The file also includes various fixes to bugs in the original document. Presumably, he'll incorporate anything differences into the svn. James Markevitch

17 years

[Unix-jun72] Minor errors

by Hellwig Geisse

I just did a 'grep' of some suspicious character combinations and found the following: e00-04:/ initialize i-nodes r1.,...,47. and wr1te the root device, binary, etc., e04-01: bne 3f /Is1t zero now? e08-05: bis $103,r3 / now rbn,for,un1t,1e e04-03:1: / flle just opened e05-04: cmp r1, ii / r1 = i-number of current flle e03-01: jsr r0,rswap / read new process 1nto core e04-04: cmp r1,$12 / is char a l1ne feed e06-02: br ret / it 1n r1; 1f there 1s no problem with reader, it e06-02: inc *u.fofp / increment file offset to point to 'next' char 1n e08-03: br 1f / branch if block already 1n a I/O buffer e08-03: bis $2000,(r5) / set read mu (bu: 100 1n 1/0 buffer) e08-06: bit $173000,(r5) / lock+keep+active+outstand1ng e11-07: cmp 0b,$1nbuf+256. / have we exceeded innut buffer size e06-04: inc *u.fofp / increment f11e offset to point to next available e06-05: mov r2,i.size / yes, increase the f11e size to file offset + e06-06: / be written to the f11e e08-03:tstdeve: / check whether permanent error has occured on special f11e e03-02: / to end of stack gets written out) ~ e08-03: mov u.base,r2 / put users base in r2 ~ e11-01: cdpb B(r5),$'- / was this sh calleZd by init or loginx~ e03-02: cmp r2,$core / is u.break less than Score As you can see, the errors are almost exclusively in the comments. Someone with write access to the svn repository could perhaps take care of that. Hellwig

17 years

[Unix-jun72] warning: 1972_stuff as!

by Tim Newsham

I just noticed that the 1972_stuff "as" program generates: 400 MOV #120000,SP for core = orig+40000 / specifies beginning of user's core ecore = core+20000 / specifies end of user's core (4096 words) [...] . = orig+400 / copy in transfer vectors mov $ecore,sp / put pointer to score in the stack pointer while the V7 assembler is generating the correct: 400: MOV #60000,SP I have no idea why it is doing this. The 1972_stuff "nm" program correctly lists ecore as 60000. Use the 1972_stuff "as" at your own risk! Tim Newsham http://www.thenewsh.com/~newsham/

17 years

[Unix-jun72] cold boot tape

by Tim Newsham

I wrote a utility for building a cold boot tape and included it in the tools directory. Its not yet tested so its possible I got the format wrong... its based on my reading of init at the end of u0.s. It seems like the permissions in the s2.tar.gz file from the 1972_stuff reflect the original 1ed permission bits (at least the low order bits do) so this makes restoring the original permissions fairly easy. Unfortunately the tar doesn't preserve the original uids. The included "Readme" does have the original uids, so its possible to recreate the proper uids by hand. If you do so, my mktape utility should write out the proper uid and mode values. The use is straightforward: cd /your/s2/directory /path/to/mktape.py bin/* etc/* and you'll get a "tape" file out. I believe you just need the stuf in bin and etc. The stuff from usr should probably go on the rk03 disk after cold boot. Tim Newsham http://www.thenewsh.com/~newsham/

17 years

[Unix-jun72] mkfs src

by Warren Toomey

OK, I've got it to the point where is makes _a_ filesystem, and now I'm off to bed. The image looks fine to me, but I thought I'd pass the source code around in case someone spots an incorrect assumption that I've made, or a bug. I have created an RK03 image using the V1 binaries off the s2 tape. I then ran V1 check on the image; here is what it said: # check rk.img 0 files 0 large 0 indirect 0 used 3420 free Not exactly fantastic, but much better than when I gave check a random file to digest :) Good night! Warren P.S cc -o mkfs -Wall mkfs.c

17 years

Re: [Unix-jun72] more corrections

by Brad Parker

Tim Newsham wrote: > >How can I get the modified simh? Here's a diff against v36 and a tar of my working directory: http://www.unlambda.com/download/pdp11/unix-jun72/KE.diff http://www.unlambda.com/download/pdp11/unix-jun72/simhv36-1-ke.tar.gz >Also what configuration are you using? I have this so far: > > set tc enabled > att tc tape.dt > set rk3 enabled > att rk3 rk0.dsk > set rf enabled > att rf rf0.dsk > set cpu 11/20 > set cpu 32K I'm using this: set cpu 11/20 set hk disabled set rha disabled set tm disabled set rx disabled set rl disabled set tq disabled set rk3 enabled att rk3 rk3.dsk set tc enabled set rf enabled set ke enabled set cpu 32K load loadfile d pc 400 set cpu history=1000 attach rf rf0.dsk I forgot to include my a.out->loadfile conversion program. I'll check it in to svn. >Have you gotten far enough that it writes out the full primitive >root on rf0 so that you can reboot and get init going? No - it writes a bunch of blocks to rf0 but no directories. The 'zero i list' appears to work, and the code to init i-node 41-47 runs but nothing gets written. Or if it does the wrong thing gets written. not sure why. To debug I sprinkle "halt"'s in the code and then do "show cpu history" to see what happened. As a sanity check I also do 'e 0-40' and 'e 400-440' to make sure location 34 (iot vector) is filled in and the code at 400 is correct (it loads the sp with 60000). I might turn on some RF debug to see exactly what gets written when. -brad

17 years

[Unix-jun72] Anyone working on V1 mkfs?

by Warren Toomey

We're going to need a filesystem. Is anybody working on tools to make one? If not, I might start work on a mkfs for V1. Warren

17 years

Query on PDP-11 assembly

by Warren Toomey

All, I'm trying to write a PDP-11 disassembler for a.out files. I'm having trouble dealing with jsrs. Take, for example, the code here: http://minnie.tuhs.org/UnixTree/1972_stuff/s1/frag19.html I can happily deal with the jsr pc,do type of jsr, but the ones involving r5 have me stumped, e.g.: jsr r5,questf; < nonexistent\n\0>; .even It appears that data is being inserted into the executable directly after the jsr instruction. How does the rts which returns from the jsr know how much data to skip, and what is the involvement of r5 here? Thanks, Warren

17 years

Re: [Unix-jun72] more corrections

by Brad Parker

Tim Newsham wrote: >> I wonder... hmmm. if the V1 a.out header where 12 bytes long, then >> everything would just automagically work. > >The 1ed man pages are online. I looked at them and it said that the >header consists of 6 words, but that the text length included the >header size. However, I had to skip the first 16 bytes of the >text segment (including header) to line up the various labels in >u0.s (.=orig+100, .=orig+200, etc..) yes, I think 0405 and 0407 a.out's are different. I believe the V7 headers are 16 bytes and the text section starts at zero. (heh, memory management) The v1 headers are 12 bytes and the text section starts at 014 (i.e. the header is part of the text section and *it* begins at zero, not the code) So, if we assemble with the v7 as we need to adjust things a bit. -brad

17 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS