test-drb April 2012

test-drb@ccmp.vtda.org

195 participants
233 discussions

by djg＠pdp8online.com

A company has made some replica 8/E handles and has excess they are willing to sell at $1.50 per handle. I think they have around 25 of each color left. Due to the company not wanting to deal with a bunch of small orders I may need to be an intermediary. Pictures of the switch handles next to my 8/E handles and two 8/M handles sitting on top at URL below. It also has a picture of the panel they made. They said ok to share the picture but I can't say why they made them. http://www.pdp8online.com/ftp/misc/switches/ The color of one matches my 8/E pretty well but the other doesn't. You can also see for one of the colors my 8/E doesn't match my 8/M that well either. If interested email me with how many you are wanting of which color.

12 years, 3 months

BRU Tapes on Unix?

by holm＠freibergnet.de

Hi, Friends of mine have an old, not that much DEC compatible PDP11 like machine that they (and me) would get working again. The machine is located at the German Chemical Museum in Merseburg. http://www.robotrontechnik.de/index.htm?/html/computer/k1600.htm Scroll down to the K1630. The Machine was rescued from the old power plant in Thierbach before. It is an PDP11 build out of some east german 8 Bit Bitslice CPU's and has 248K Ram. They used an unusual BUS, an Z80 Sio for The console (this is really ugly) und Bus communication controllers on each peripheral board that must be configured before the first use of that board, this means the IO Adress, DMA Registers, Modes and Vector addresses are set in Software before the Processor can talk to them like in a PDP11, so every DEC-OS must be patched to work on this thing. It is a slow machine too :-) We now have some CPTP Dumps of BRU Backup Tapes of the Operating System OMOS for this machine (old version of RSX11) I have a copy here http://www.tiffe.de/Robotron/K1630 There are 2 Versions omos-sys.tape.gz is the original type file in CPTP Format, omossys.tap.gz is the same thing converted with taput to simh tape format. Same with the dok tape, the docs are in german... My friend Oleg told me that the tape files are broken, may be this is the fault of taput (http://www.mrynet.com/hp2000/taput/index.html). My question is if somebody can verify what is going on with the files and if an opensource utility exists that can read BRU files on unix (like my FreeBSD here).... I think the OMOS-SYS Tape is the only real chance to boot this thing sometime again.. Kind Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

12 years, 3 months

Pertec interface

by elson＠pico-systems.com

Message: 20 Date: Sun, 01 Apr 2012 00:29:09 -0700 From: Jeff Woolsey <jlw at jlw.com> To: cctech at classiccmp.org Subject: Re: Pertec interface Message-ID: <4F7803C5.1050404 at jlw.com> Content-Type: text/plain; charset=ISO-8859-1 SimH also describes bad blocks, which have the high-bit set in the length but otherwise look normal. Except that most tape drives, without heroics, will not give you any data for an unrecoverable read error (both that and a tapemark read as 0-length blocks; some gymnastics are needed to tell them apart), except that such a block cannot be empty. So what to put in it, if we're noting them at all? I'm playing with ANSI-style labels for this. Some history is at: http://neil.franklin.ch/Usenet/alt.folklore.computers/20001209_New_Tape_Con… , though in there it is asserted that tape blocks cannot be longer than 64K, implying that only two bytes are required for the length. However, I have a tape someone else wrote (HDR2 even says so) with 65536-byte blocks (not every O/S today can handle that--16-bit signed comparisons). To represent that along with 0-byte tapemarks requires 17 bits. Elsewhere someone asserted that a tape block can be as long as the entire tape, which seems unlikely and wouldn't always fit in three bytes. I think most Pertec formatted drives will not give you the bad block, but I could be wrong. Of course if it is really bad, even the block length can't be determined. Most PDP-11 and VAX tape controllers, both DEC and third-party could handle 65536 byte blocks. Of course, on a PDP-11, that could be the entire memory in a single tape block! So, it really only made sense on Q-22 systems. Tapes with insanely long blocks are not a good idea, even on hardware that can handle it. I'm guessing 1401 and similar machines could do crazy stuff like that due to their stream of digits architecture. But, having an entire tape with only one LRCC and CRC byte would lead to undetected errors and difficult to recover files. The greatest feature of GCR is that the redundancy data is added periodically within the block, making the likelihood of recovering small dropouts much better. Jon

12 years, 3 months

For sale: warehouse of IBM, WANG, DIGITAL, NCR in Maine

by tosteve＠yahoo.com

Attention! For sale: Looks like a warehouse of IBM, WANG, DIGITAL, NCR in Bangor, Maine. See pics here: http://66.147.242.85/~oldcompu/maine/ Also some TRS-80, Apple, Compaq, etc. I have no connection, just passing on the info. Contact Penny at: peifen196 at yahoo.com Enjoy!

12 years, 3 months

What's that TeK Box?

by holm＠freibergnet.de

http://www.tiffe.de/images/Unbenannt.JPG This is one of the things in Dortmund, anyone know what this could be? Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

12 years, 3 months

PIXAR Image Computer Panel Museum Display on Ebay

by michael.99.thompson＠gmail.com

>Dave McGuire mcguire at neurotica.com >On 03/25/2012 02:50 PM, James Gessling wrote: >> Isn't this just a piece of plastic with a logo embossed in it? And >> why does anyone think Red's Dream is so great anyway? I'm not >> bidding. > > The whole computer would've been much more interesting. If the >starting price weren't so high, I'd have placed a bid just out of >sympathy for someone with such a wife. > > -Dave I thought that the RICM had one of these. It turns out that we have two PII-9 systems that they were made after the Viacom Systems buyout so it doesn't say Pixar on the die-cast front cover. I will add more pictures and details shortly. http://www.ricomputermuseum.org/Home/equipment/pixar-image-computer -- Michael Thompson

12 years, 3 months

Pertec interface

by elson＠pico-systems.com

Well, I did the bit reversal TWICE, so of course the end result was wrong! Fixed that, fixed up a little bug in resetting the file mark detection flag in the wrong place, and I now have a rough program that maps the files structure of a tape. here's a snip of what I got. VOL1RT1101 DD%% 1 HDR1SAMBR .CTL RT110100010001000100 00000 00000 000000RT11 file 0 had 2 blocks 0 errors 0 timeouts blocksize was 512 HDR1SAMBR .BAK RT110100010001000100 00000 00000 000000RT11 file 1 had 2 blocks 0 errors 0 timeouts blocksize was 512 HDR1SAMBR .FOR RT110100010001000100 00000 00000 000000RT11 file 2 had 4 blocks 0 errors 0 timeouts blocksize was 512 and so on. (Note the RT11 header labels above. I sort of thought this tape would have been >from RSX-11M, but it must have been made before we switched. Whew, that's going BACK a ways, about 1976 or 77 when we went to RSX. The actual tape I'm reading was a 6250 BPI copy of the original tape (probably 1600 BPI) from back then. This copy was probably made 15 years ago, though.) I'm now working on a program to move the entire tape to a single disk file with pretty much verbatim bytes from the tape. It will have a 32-bit header for each record of file mark, showing the record size or file mark. Then I can write programs at my leisure to extract files without having to listen to the wail of the Gast vane pump in the keystone tape drive. Oh, the performance seems to be pretty good. it was streaming fairly well at either 25 or 75 IPS in 6250, I suspect it will certainly stream at 75 IPS with a 1600 BPI tape. Jon

12 years, 3 months

PRIME NUMBERS

by jgessling＠yahoo.com

In fact those guys at the LHC Were going to do just that. By directing the beam at a block of chrystilan silicon ( nice square latice) and then Stepping the beam deflection in integer increments. A physical Erathones sieve can be created for large numbers. Essentially blasting away nonprimes. Detecting the remaining primes is then A radiation problem similar to that used in Genetic screening. Regards, Jim

12 years, 3 months

PDP-8 questions

by jgessling＠yahoo.com

Please don't use real rosewood for the side panels.?? Forests around the world are being destroyed for this increasingly rare commodity. Thanks, Jim

12 years, 3 months

Arcturus Minicomputer

by jon.griver＠gmail.com

*Dear Rod,* ** *Feeling nostaligic, I googled 'Arcturus Minicomputer', and your letter below was the only reference I found. I know the letter is from 2007. I hope the email address is still in use.* ** *I programmed an Arcturus minicomputer at the Atkinson Morley Hospital in Wimbledon from 1973 to 1976. It was used to do image processing on pictures >from the first CT scanner in the world, which was located in that hospital.* ** *All the programming I did on the machine was in assembler. The computer did not have a disk operating system. Every action involved first loading the program you need from paper tape, then the data, etc.* ** *The first thing I did was to write a very rudimentary disk operating system. It took 6 weeks, but it worked.* ** *I knew that Arcturus had installed the monitor system in Gatwick.* ** *Best Wishes,* ** ** *Jon Griver* ** ** ** *Fri Mar 30 02:45:49 CDT 2007* - Previous message: On topic? Looking for old computer book <http://www.classiccmp.org/pipermail/cctech/2007-March/037565.html> - Next message: NeXTstep: cloning a drive <http://www.classiccmp.org/pipermail/cctech/2007-March/037495.html> - *Messages sorted by:* [ date ]<http://www.classiccmp.org/pipermail/cctech/2007-March/date.html#37488> [ thread ]<http://www.classiccmp.org/pipermail/cctech/2007-March/thread.html#37488> [ subject ]<http://www.classiccmp.org/pipermail/cctech/2007-March/subject.html#37488> [ author ]<http://www.classiccmp.org/pipermail/cctech/2007-March/author.html#37488> ------------------------------ Hi All Whilst sitting on the plane on the way back from Newcastle yesterday. It reminded me of a system I saw at Gatwick airport in the early 1970's. I'm pretty sure it was run by a mini computer called an 'Arcturus'. I can clearly remember the grey rack mounted box with its row of toggle switches and lamps. I was there to install a VDU (sometimes referred to as a glass teletype). The big teletype they drove it from made the whole place shake and the VDU I fitted of course did not. It drove the departure / arrival TV monitors. The way it generated the characters was curious to say the least. It had a large number of circuits which generated parts of characters. One did a vertical bar, another produced a whole circle whilst others output parts of a circle, forty-five degree bars and so on. For each character cell the component parts of the required character were selected summed and added to a TV raster. Does anybody remember the Arcturus? Rod Smallwood

12 years, 3 months

Jump to page:

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 April 2012