test-drb

test-drb@ccmp.vtda.org

101090 discussions

by jnc＠mercury.lcs.mit.edu

> From: Dennis Boone > The sources for the V6 versions of the tmrk et al programs seem to be > here: Yes, I have those, thanks; those are the 1-block programs I mentioned to Warren: >> The only V6 boot mechanisms are 1-block programs that go into block 0 >> of device 0 and which boot Unix directly from that file-system Well, to be technical, also there are the programs to copy the disk images >from tape to disk - mcopy.s does that - etc. In case anyone looks at mcopy.s and wonders how R5 (which contains a pointer to the console print/input routines) gets set up, mboot.s, which will have run previously (to load the appropriate disk-controller-specific version of mcopy off the tape) does that. One can't actually boot V6 Unix directly from a V6 distribution tape, all one can do is copy the disk images from the tape to the disk; one then boots from the disk. (Although now that I look, there is tpboot.s, which claims to boot >from a file on a 'tp' format tape. But I don't think V6 was ever distributed in that form - and in any case, it would still need a disk with a Unix file system, with appropriate files - init, sh, etc - already on it, to be able to boot Unix that way.) Noel

9 years, 6 months

MFM floppy and HD emulator DREM

by emu＠e-bbes.com

Hi all, anybody has any experience with that: http://www.drem.info/ ?

9 years, 6 months

VTServer/etc for V6 Unix

by jnc＠mercury.lcs.mit.edu

> Here are some notes I made a while back, when I looked at it: > ... > Block 2-xx - gubbish, apparently inodes, code, etc? So I just realized something's incomplete here. There's an intermediate stage (loading 'xxyy', where 'xx' is "tm" or "ht", and 'yy' is "rk", "rp" or "hp"). Those must be in stored in that block "2-xx" area, but I'm not up for grokking the assembler ("tpboot.s") that loads them to see how it works (it takes a file-name, 'xxyy' as above, entered at the console). And I got the tape files slightly wrong: mcopy.s is indeed the tape copier program (assembled with either tm.s or ht.s, and one of rk.s, rp.s and hp.s), to produce the 'xxyy' files above. However, the first stage booter is "tpboot.s", not "mboot.s" (didn't look closely enough); again, assembled with either tm.s or ht.s - that produces the first-stage bootstrap that goes in blocks 0 and 1 of the tape. Noel

9 years, 6 months

VTServer/etc for V6 Unix

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > This doc: .. describes a way to install from tape, but it seems like it > does a block copy of a tape image to the disk. Yup, that's the standard V6 install from tape. It uses the two programs I mentioned in the last message; first mboot (which produces the '=' prompt), and then mcopy (assembled with the appropriate disk and tape drivers), which is used to copy disk images to the disk. > Also .. there is a v6.tape.gz file. Unfortunately, I have no > documentation on this. It could be raw blocks, or it could be a TAP > file, who knows. I looked into this previously. The other three files: root.v6.tar.gz doc.v6.tar.gz usr.v6.tar.gz are just TAR dumps of the 3 disk images on the V6 distribution tape: the root (includes kernel source, and most of the binaries), usr (source for all commands), and documentation. The v6.tape seems to be an image of V6 distribution tape. Here are some notes I made a while back, when I looked at it: The first 100 512-byte tape blocks contain the tape bootstrap stuff. Blocks 100 - 4099 are the RK05 root image, blocks 4100 - 8099 are the /usr RK05 image, and the blocks 8100 - 12099 are the /doc RK05 image. .. The most recent timestamp on any file in /usr and /doc is July 19th 1975, as with Dennis' copy. However, the most recent file timestamp on root is October 11th, 1975 Block 0 on tape - mboot (tm tape booter) Block 1 on tape - hboot (ht tape booter) Block 2-xx - gubbish, apparently inodes, code, etc? Block 98 on tape - hpuboot Block 99 on tape - rpuboot Block 100 on tape - rkuboot HTH. Noel

9 years, 6 months

VTServer/etc for V6 Unix

by wkt＠tuhs.org

Hah, the file http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/v7_standalone.tar.gz has the source code for the standalone tools including boot and vtboot.pdp. So, given a working V7 environment, you should be able to rebuild these and possibly make them work in a V6 environment. Alternatively, if you have a working V6 environment (e.g. a simulator), you could bring in the vtclient.c code and integrate it into the V6 boot binary. Cheers, Warren

9 years, 6 months

Are DEC TK50/TK70 tapes worth hanging onto?

by tdk.knight＠gmail.com

Don't store ur tapes in a damp basement will help with sticky shed syndrom... Keep em dry a food dehydrator helps... On Oct 18, 2016 7:46 PM, "Al Kossow" <aek at bitsavers.org> wrote: On 10/18/16 5:37 PM, Steven M Jones wrote: > I think they're useful to folks who have drives that can use them, and > they aren't nearly as fragile as QIC or helical scan drives (4mm, 8mm) > of a similar age. > The drives, maybe, but the tape sheds like nuts.

9 years, 6 months

2020 Power consumption

by RichA＠LivingComputerMuseum.org

From: Mike Ross Sent: Wednesday, October 19, 2016 2:39 AM > On Wed, Oct 19, 2016 at 7:44 PM, Pontus Pihlgren <pontus at update.uu.se> wrote: >> Somewhat related, how much power does a 2020 draw on average? > Bye some enormous coincidence I was just looking through some DEC > pdp-10 brochures I have. > DEC advertised the 2020 as drawing no more power that a hairdryer; the > quoted figure was 1400w as I recall. Umm, are you sure about that? That was how we advertised the Toad-1 System in the 1990s, but the Mighty Mite power supply in the 2020 draws a lot more than that. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

9 years, 6 months

MASSBUS disk emulator (Was: Unibus controller for MFM disks)

by jnc＠mercury.lcs.mit.edu

> From: Ian S. King >> Does anyone know anything about the status of the plans to open-source >> it? > I've made some inquries, stay tuned.... OK, thanks! >> Can you briefly describe what it was? I'm still curious about what it was: was it a stand-alone board with a separate power supply, or did it plug into some sort of backplane? Did it use something like SD cards for storage? And what was the MASSBUS connection like: a set of 3 Berg headers into which one plugged the flat cables, or was there some oddball connector that wound up connected to a standard MASSBUS connector? Noel

9 years, 6 months

VCFed, the BBS!

by couryhouse＠aol.com

I could care less about telnet... I want to make the teletype ?clack! ? Ed# Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: Rod Smallwood <rodsmallwood52 at btinternet.com> Date: 10/16/16 18:39 (GMT-07:00) To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Subject: Re: VCFed, the BBS! On 16/10/2016 14:10, william degnan wrote: > On Oct 16, 2016 5:52 AM, "Evan Koblentz" <cctalk at snarc.net> wrote: >>> I mean? please add 110? Baud? Evan! >> >> I was giving examples, not carved-in-stone specifications. > If the system is simple it'll be easier to support, 110b is not, given the > number of persons coming in from the other end so slowly.? No one barely > has a phone line anymore as it is, most (95%) of the external traffic will > be telnet.? If the bbs allows those few of us with phone lines to connect > at 300 to 1200b to get to a handshake and resolve to a simple welcome > screen for hardware testing purposes, that would be a good start. Get that > running see what kind of traffic results, and plan phase ii from there. > > I imagine it will be best once this system is up and running that people > call in on Sunday afternoon so visitors to the museum hear the inbound > calls in real time like a sys op would running a bbs from his basement. > Bill Speaking as a former Sysop from the 1980's. What would be nice is a couple of DEC Rainbows running FidoBBS and connected via a phone line simulator. Enter your mail message on one and see it get transferred to the other where it can be read. Rod Smallwood -- *PDP-8/e PDP-8/f PDP-8/m PDP-8/i Front Panels ex Stock - Order Now*

9 years, 6 months

MASSBUS disk emulator (Was: Unibus controller for MFM disks)

by jnc＠mercury.lcs.mit.edu

> From: Rich Alderson > Yes, the d/r card is strictly level conversion, and the microcode in > the Xilinx does all the Massbus protocol. So if you don't mind continuing to indulge my curiousity (thanks for all the indulgence so far :-), is the D/R card a daughtercard that mounts on the Mesa (my guess)? Noel

9 years, 6 months

Jump to page:

2026

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

test-drb