TUHS

tuhs@tuhs.org

29 participants
6557 discussions

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

by jnc＠mercury.lcs.mit.edu

> From: Ronald Natalie > The V6 file system was limited to 2^24 blocks No, 2^16; from filsys.h: int s_fsize; /* size in blocks of entire volume */ and of course on an -11 an int is 16 bits. Maybe you're thinking of the file size, which was 2^24 bytes (max). Noel

5 years, 2 months

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> when you're working below the reliable stream level, you can't just do a > blocking 'read' for a packet; it pretty much has to be asynchronous Oh, you should look at the early BBN TCP for V6 Unix - they would have faced the same issue, with their TCP process. They did have the capac() call (which kind of alleviates the need for non-blocking I/O), but that may have only been available for ports/pipes; I'm not sure if the ARPANET device supported it. (With the NCP as well, that did some amount of demultiplexing in the kernel, and probably had buffering there, so, if so, in theory capac() could have been done there. Of course, with the ARPANET link being only 100Kbit/sec maximum - although only to a host on the same IMP - the overhead of copying buffered data made kernel buffering more 'affordable'.) Noel

5 years, 2 months

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > This time looking into non-blocking file access. (... right now my > scope is 'communication files' (tty's, pipes, network connections). > ... > First appearance of non-blocking behaviour seems to have been with > Chesson's multiplexed files ... in 1979. At around that point in time (I don't have the very _earliest_ code, to get an exact date, but the oldest traces I see [in mapalloc(), below] are from September '78), the CSR group at MIT-LCS (which were the people in LCS doing networking) was doing a lot with asynchronous I/O (when you're working below the reliable stream level, you can't just do a blocking 'read' for a packet; it pretty much has to be asynchronous). I was working in Unix V6 - we were building an experimental 1Mbit/second ring - and there was work in Multics as well. I don't think the wider Unix community heard about the Unix work, but our group regularly filed updates on our work for the 'Internet Monthly Reports', which was distributed to the whole TCP/IP experimental community. If you can find an archive of early issues (I'm too lazy to go look for one), we should be in there (although our report will alsocover the Multics TCP/IP work, and maybe some other stuff too). There were two main generations of code; I don't recall the second one well, and I'm too lazy to go look, but I can tell you off the top of my head a bit about how the first one worked. Open/read/write all looked standard to the user in the process (the latter two were oriented to packets, a bit like raw disks being blocks); multiple operations could be queued in each direction. (There was only one user allowed at a time for the network device; no input demultiplexing.) Whenever an I/O operation completed, the process was sent a signal. Since the read/write call had long since returned, it had to do a getty() to get info about that operation - the size of the packet, error indications, etc. One complication was that for a variety of reasons (we wanted to avoid having to copy data, and the interface did not have packet buffers) we did DMA directly to/from the user's memory; this meant the process has to be locked in place while I/O was pending. (I didn't realize it at the time, but we dodged a bullet there; a comment in xalloc(), which I only absorbed recently, explains the problem. More here: https://gunkies.org/wiki/UNIX_V6_internals#exec()_and_pure-text_images if anyone wants the gory details.) That all (the queing, signals for I/O completion, locking the process to a fixed location in memory while it continued to run) etc all worked well, as I recall (although I guess it couldn't do an sbrk() while locked), but one complication was the UNIBUS map on the -11/70. The DSSR/RTS group at LCS wanted to have a ring interface, but their machine was a /70 (ours, the one the driver was initially done on/for, was a /40), so with DMA we had to use the UNIBUS map. The stock V6 code had mapalloc(), (and mapfree(), both called on all DMA operations), but... it allocated the whole map to whatever I/O operation asked for the map. Clearly, if you're about to start a network input operation, and wait a packet to show up, you don't want the disk controller to have to sit and wait for for a packet to show up so _it_ can have the map. Luckily, mapalloc() was called with a pointer to the buffer header (which had all the info about the xfer), so I added a 'ubmap' array, and called the existing malloc() on it, to allocate only a big enough chunk of the UNIBUS map for the I/O operation defined by the header. Since there was 248KB of map space, and the largest single DMA transfer possible in V6 was about 64KB (maybe a little more, for a max-sized process with its 'user' block), there was never a problem with contention for the map, and we didn't have to touch any of the other drivers at all. That was dandy, and only a couple of lines of extra code, but I somehow made a math error in my changes, and as I recall I had to debug it with a printf() in mapalloc(). I was not popular that day! Luckily, the error was quickly obvious, a fix was applied, and we were on our way. Noel

5 years, 2 months

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Ruizendaal

> Team Unix, Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree? Paul *Paul Riley* It seems you are asking for two tools in the BK-UNIX toolbox, fsutil and dskutil https://github.com/sergev/bkunix/tree/master/fsutil https://github.com/sergev/bkunix/tree/master/diskutil The first generates a Unix 6th edition file system from a local directory tree. The result is a binary file with the 512 byte disk blocks stored in sequence. Maybe this is what SIMH needs, I’m not into the details of SIMH. The second appears to be a tool to take the a file generated by the fsutil tool and split that into sectors and tracks. I’m not familiar with this tool, but it looks like you might need something similar (I assume that you have some way to hook up a 8” drive to your PC?). Sector interleaving may be an issue to look out for. When preparing a LSX system disk, you will need to think carefully about the layout: Presumably the disk works with 128 byte sectors and 4 sectors are grouped together to create a 512 byte unix block. Check out the disk driver code for details: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/decfd.c Block 0 contains bootstrap code which is loaded/called from the monitor rom (or from a short code sequence keyed in on a “blinkenpanel” console). The filesystem itself starts at block 1 and runs up to a block N (you need to tell fsutil how big the filesystem needs to be). After block N up to the end of the disk is space to contain 2 swapped out programs plus 1 block for the return code of the third (default LSX has a maximum of 3 processes). You have to figure out how many 512 blocks are on your floppy and subtract out the swap space to arrive at a figure for N. In the LSX source code ’N’ is known as the define SWPLO, see param.h for details: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/param.h In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h Be careful with size units in the source code. Often sizes are expressed in words (2 bytes). Where memory is concerned it is often expressed in ‘clicks’, 64 bytes.

5 years, 2 months

LSX on the PDP-11/03 (LSI-11)

by Paul Riley

I've managed to acquire a PDP-11/03 with twin floppy drives (Sykes Datatronics RX01 or RX02 equivalents, not sure yet which). I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat. I have some interest in Forth, but I don't like the block system of early forths such as FigForth, and I plan to create a new Forth based on FigForth, but supporting external source files. Anyway, I've tried compiling Hello World on LSX, and I get "1: External definition syntax" error. Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself? void main () { printf("Hello World!"); } It seems that the 7th Edition was the beginning of the standard library in C, and that this is missing in LSX. I'm not sure if printf is an intrinsic function in (6th Edition) C, or if it's from a library. My questions are a bit random, but looking to converse with others with LSX experience. Paul *Paul Riley* Email: paul(a)rileyriot.com

5 years, 2 months

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Ruizendaal

> > In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h Oops: 77 tracks by 26 sectors of 128 bytes, makes 250.25KB, so it should work as configured.

5 years, 2 months

fmt(1): history, POSIX, -t, -c

by markus schnalke

Hoi, personally I use fmt(1) a lot for email formatting and such. Typically I only use the `-w' parameter. Now someone asked me about `-t' and `-c' of *GNU* fmt(1). I wasn't able to find good documentation on them. The manpage only tells that they have to do with different indentation for the first or first two lines. But what are the use cases? How would source text for these parameters look like? A look into the description and rationale sections of POSIX, which often provides helpful information, was not possible because fmt(1) is not part of POSIX (only fold(1) is). Why's that? Is it because fmt(1) differs so much between Unix implementations? On BSD `-c' centers text and `-t' sets tab widths. Plan 9 has none of these options. But still, `-w' could have been standardized. Or was the line filling algorithm different as well? How does fold(1) fit into the picture? Maybe you can answer some of these questions or give hints on where I could find answers myself. meillo

5 years, 2 months

LSX on the PDP-11/03 (LSI-11)

by Paul Ruizendaal

> I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat. I think you will experience a sizeable learning curve. You will be working with Unix and C as it stood around 1975 and that is substantially different from what it was in the 80’s. That said, I know from personal experience that it is an intriguing journey and certainly not impossible to do. > Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself? Many on this list are familiar with 6th edition. The best way to learn the internals of 6th edition is the “Lions’ book”: https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137 Coming from today’s perspective (or a 1980’s one), you will find the following key challenges: - The version of C used for 6th edition is different from the 1980’s. Amongst other things the syntax of the assignment operators changed (not += but =+), the syntax for initialisation changed (not 'int a = 3', but 'int a 3’), the ‘long’ datatype (32 bit on a PDP-11) did not exist, the ‘void’ keyword did not exist, structs could not be assigned, passed or returned (only pointers to structs), etc. - The stdio library did not exist yet, in its place there was the ‘portable i/o library’. This may be the hardest part to get used to. - The file system was 16-bit based throughout. This has implications for stat(), lseek() did not exist (its precursor seek() used additional whence values to move the file pointer in 512 byte increments), etc. When it comes to LSX, there are a few people who have experience with it on the this list (that I know of - there may be many more). First of all, Heinz Lycklama, the original creator of LSX, appears to read this list from time to time. Second, Leonid Broukhis and Serge Vakulenko (who managed to recover the LSX sources 20 years ago) might be reading the list. They took the trouble to port LSX to the Soviet BK-0010 computer, an LSI-11 type system some 15 years ago: https://github.com/sergev/bkunix You can stand on their shoulders, as they already took the trouble to convert the kernel source from 1975 C to 1980’s C and to create a stdio compatible library for it; they are using the 2.11BSD C compiler, which generates tighter code than the 1975 compiler — hence they could squeeze a bit more functionality in. Third, I found the BK-0010 port some 5 years ago and used that as base to create a version that would run on a small TI990 clone: http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm This work later evolved into a stock 6th edition kernel and is now a curious mix of stuff dating from 1975 to 1985. Your main challenge will be that neither the BK-0010 work nor my work will run on your hardware as-is. I think you have two possible paths forward. The first is to learn C and the library as it stood in 1975, the second is to take the BK-0010 code and to make it run on a stock LSI-11 again.

5 years, 2 months

Re: [TUHS] fmt(1): history, POSIX, -t, -c

by Doug McIlroy

The title of the fmt man page in v9 was "ultra-simple text formatter". Gnu dropped the "ultra" in favor of AI. Sometimes it does a pretty job. Sometimes it messes up my typing style. Always it produces a an apparently wavering right margin, as it assigns a separate "optimal" line length to each paragraph. It's hard to imagine how this command could stray from classic Unix simplicity and intelligibility, but Gnu pulled it off. Doug

5 years, 2 months

Sad Times - hopefully this is just temporary

by Clem Cole

https://www.livingcomputers.org/Closure.aspx

5 years, 2 months

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