test-drb September 2015

test-drb@ccmp.vtda.org

198 participants
312 discussions

information about the Bendix G-15 and Rice Research Computer?

by linimon＠lonesome.com

So I have finally been prodded by some people to put together a web page for the G-15 computer. As well, I am going to put up information about the Rice Research Computer (later known as the R1), and its intended succesor, the R2. Right now my web pages are pretty skeletal and mostly consist of some old G-15 documentation scans I did in early 2000. Apparently I have some things that are not on Bitsavers (yet). I have at least one more document that I need to scan, the Technical Manual. I do have some R1 documentation which I intend to scan and then send to either CHM or Rice University Fondren Library. To some of you that I have already contacted off-list, this will be duplicate information. Sorry about that. To the others, please let me know if you have any information about these computers that you would be willing to share publicly. Also, beta-testers of the website would be appreciated; email me off- list for the URLs. I mean, it it _really_ skeletal (e.g. 2 days old.) mcl

9 years, 3 months

Even more PDP-8/A weirdness (was: Re: PDP-8 diagnostics

by charlesmorris800＠centurytel.net

>So, either something is corrupting the bus, or the memory is bad. > >Correct me if I'm wrong, but if I got this right, you wrote the boot >code by hand into memory, single-stepped it, and after a while, you had >bad contents in memory. > >Now, execution here would only be reading from memory, and not writing >to it. Furthermore, this is MOS, so it does not get rewritten on reads. >That would, to me, suggest that the memory board is the problem. >Do you have any other memory board around? > >Johnny I mistyped while doing many things at once. (It appears that the memory does NOT change while single stepping through it by hand. Fortunately.) See my update - reseating the ROMs fixed the boot corruption problem. I am not sure if the 32K SRAM board actually reads and rewrites - it does not do so internally, it's just SRAM and a couple of bus buffers. Whether the 8/A memory cycle does rewrite each time or not, I don't know. Now I've got yet another RL02 (maybe) problem to chase down... -Charles

9 years, 3 months

Even more PDP-8/A weirdness (was: Re: PDP-8 diagnostics SR settings?)

by charlesmorris800＠centurytel.net

Since the computer doesn't mind doing boring, repetitive tasks, I set the 11/23+ to yet again remaking the bootable RL02 pack (3 hrs at 9600 baud while I did other things). Plunked it in (without the programmer's panel connected), hit the boot switch on the limited function panel, and it fired right up to the "." prompt. Did a directory of the free space which printed, set the date to 11 Sep 75, and had a phone call for a while. Back to the console, entered R BUILD (just to do the PR, not save it) and system halts. Reboot - back to the same crap of fault light flashes on the drives, no boot. Sigh. So I hooked up the programmer's panel, flaky though it may be, (just not touching the SR) and discovered that some of the bootstrap routine is being corrupted in zero page! And not the same Bit 4 as before, and not all the time... a 4027 (JMS IO) got changed to 4007, the constant of 0377 changed to 0017, the 6601 RL02 instruction was now a 6401, etc. Still always middle bits though. Now, the secondary bootstrap (from the RL pack) does overwrite the zero page including the running boot code. (The first read from the pack is 200[octal] words, or one page). The boot routine never sets the MA address register so it could be overwriting core starting at 0000. The boot listing comments say execution does not continue in the primary boot (at 0001-0035), from the last IO call at the point when the RLCB function causes the page of data to be read from the disk into core. But the changes I'm seeing aren't right, regardless. The OS/8 boot routine would never use a 6401 (an IOT for a secondary console device, in this case my Omni-USB)... Next I pulled the RL8A out of the backplane and tried manually entering and single-stepping through the boot code, skipping manually over the RLSD instruction in the disk IO subroutine. That didn't seem to corrupt the code. Hit the Boot key (with the RL8A still removed) and those three or four words are wrong again, the same way. Thus verifying that the changes are not coming from the secondary boot on the disk! If I remember correctly, the boot ROMs have to load the boot routine into core at 0001-0035 (done by hardware on one of the three-board set) and then start execution at 0001. I thought this might be bit-rot in the ROMs, so I tried toggling in the bootstrap code to those locations and single-stepping beginning at 0001 after a few loops through showed the code changed again. Remember, the RL8A is not present in the bus. So the fault can't be on that card! I'm thinking something else is loading part of the memory data bus when it should not be, which is either on the CPU or it's a problem with the 32K memory card itself. Now that I think about it, when I discovered the problem on our clone panel a couple of days ago, I also found a couple of core locations that had been corrupted in the restrl program, not in page 0 though. Figured that was also artifact of the buggy panel, but now it's looking like something else. The only things in the backplane now are the 3-board set, the 32k card, and the Omni-USB. Today I have discovered a pattern to the corruption! Addr Orig. Altered 0005 4027 4007 0011 6615 6415 0015 7325 7005 0021 1026 1006 0025 0377 0017 0031 6601 6401 Notice the middle 4 bits are always being set to 0000 which is an open-circuit (on the Omnibus a logic-1 is pulled down to 0 volts). I am not sure of the significance of the repeating address pattern yet. Not only that, those locations *only* are wrong after the BOOT key (or switch) is toggled. Running from loc. 1 by (0001, LA, RUN) does NOT corrupt the bootstrap in core (with the RL8A still removed, so the DMA facility doesn't factor into it). An even more important finding is that if I manually clear the bootstrap code by depositing 0000 in all its locations, when I hit the BOOT key, it deposits the "altered" version into core! No wonder the machine won't boot... still unsure as to why it did the first time yesterday, though. So now I need to look at the boot ROM circuitry which is on Option 2 board M8317. There are not three ROMs, DEC used some weird packing scheme to fit into two 256x4 ROMs. Most likely there is a 4-bit latch or an open-collector buffer chip that is flaky. I'd just yank the board and try booting without it, but the IF and DF registers (for memory extension beyond 4K) are also on that card so OS/8 would crash... And the best news of all so far: I keyed in the boot loader by hand, started it manually at 0001... and OS/8 booted from Drive 0 which confirms that the boot ROM area is the cause! Now to track it down... I sure hope it's not another solder whisker. Meanwhile, I used the system for over half an hour, running PFOCAL, formatting disk packs in Drive 1, checking the handlers loaded with BUILD. All working. -Charles

9 years, 3 months

punchcard svg file available

by gerardcjat＠free.fr

Shall I understand that some of you guys, are looking for blank punch/punched cards ?? I have about a hundred ( here in .... France !! ) Let me know if this can help. These came from ex Soviet Union, and, as far as I can tell, they "fell and taste" like original IBM cards that was used to "play" with some 40 years ago. --- L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast. https://www.avast.com/antivirus

9 years, 3 months

internet blocking problem ?

by hollandia＠ccountry.net

Per your request, I tried the URL: http://members.iinet.net.au/~daveb/simplex/simplex.html I did the search you requested, and tried the following URLs: http://members.iinet.com.au/~stepho/mick.htm http://members.iinet.net.au/~pontipak/redsquare.html http://members.iinet.net.au/~perthdps/convicts/stories.html http://www.iinet.net.au/~rmine/gctrebs.html http://www.iinet.net.au/~worcom http://members.iinet.net.au/~janwyllie/ http://members.iinet.net.au/~tom-hunter/ http://www.iinet.net.au/~gduncan/ http://members.iinet.net.au/~jacob/worldtp.html In every case shown above, the result was the same: The server at members.iinet.net.au is taking too long to respond. Only two of the sites I tried gave a different result. They were: http://members.iinet.net.au/~glrmc/ It gave me a blank page. and http://members.iinet.net.au/~margretr/ It gave the following error message: "XML Parsing Error: unexpected parser state Location: jar:file:///C:/Program%20Files/Mozilla% 20Firefox/browser/omni.ja!/chrome/browser/content/browser/aboutNetError.xhtml Line Number 335, Column 68: <div id="ed_connectionFailure">&connectionFailure.longDesc;</div>" My particulars are: 7:59 PM 9/10/2015 Gateway computer, connected by modem. Windows XP Professional v5.1 Firefox 35.0.1 Computer Country (ccountry.net) Medford, Oregon USA IP address: 12.73.18.147 You're welcome! Kurt > > So, I wonder if I can ask classiccmp members, especially in > the US, to check if they can view this page: > http://members.iinet.net.au/~daveb/simplex/simplex.html > > > If you want to do some more research, just Google > members.iinet and you will see a lot of hits of the form: > http://members.iinet.net.au/~some_name > > Thanks for any help or info you can offer! > > Jon > > >

9 years, 3 months

FS: three PDP-11 boards

by charlesmorris800＠centurytel.net

I was going through my board collection and found three PDP-11 boards I've never used in years and don't see a foreseeable need. No idea of condition, but they're visually clean and neat, stored in antistatic bags. The serial cards came out of (my) working 11/23+ but I've not tested them (since I already have a 16-line card and only 2 terminals). I have (one each): M7957 DZV11-M Quad height 4-line serial card M8053 DMV11 "Microprogram Control" synchronous controller card Dilog CQ1610 16-line serial card. Make any reasonable offers. + shipping from US zip 65775. thanks Charles

9 years, 3 months

Control Data 160

by wmachacek＠q.com

I have a CDC "160 Computer Programming Manual" that I obtained many years ago when I was working with CDC equipment. This manual caught my eye and I squirreled it away since we were using the 160-A computers not the 160s. This manual has a publication number of 023a and a date of 1960. The picture shown inside the manual is pretty much like the one described herein. It shows the dropped side panels. The manual shows the Ferranti paper tape reader and the BRPE paper tape punch as standard equipment. As optional equipment it shows Ampex magnetic tape handlers (FR300 or FR400), an 80 column punched card reader (no maker listed), an 80 column card punch (no maker listed), a line printer (no maker listed), a Soroban-modified IBM electric typewriter, and a digital communications line buffer. This manual has 45 pages and shows a full view of the computer and a close-up of the front panel. I always kept this as a kind of a CDC oddity as I had heard that the 160s were a proto type and never actually went into production. At least that is what I heard back then. I hope this information kind of helps to better identify these computers. Bill

9 years, 3 months

PDP-11 architecture Was: internet blocking problem ?

by jnc＠mercury.lcs.mit.edu

> From: Jon Elson elson > I actually LIKED the PDP-11 architecture quite a LOT, but the limited > memory was a big killer. The good thing about the PDP-11 was the 16-bit word size. (It resulted in what's probably the most elegant architecture, in bang/buck terms, of all time.) The bad thing about the PDP-11 was the 16-bit word size. (For the reason you point out.) Noel

9 years, 3 months

punchcard svg file available

by simski＠dds.nl

Hi All, just to let you know that i've made a vector graphics file for A hollerith punchcard. https://hack42.nl/wiki/Bestand:Punchcard.svg enjoy -- Met vriendelijke Groet, Simon Claessen drukknop.nl

9 years, 3 months

internet blocking problem ?

by jnc＠mercury.lcs.mit.edu

> From: Jon Elson > so MANY others who could not access the members.iinet page were finding > they got stopped at cogentco. ^^^^^^^^^^^^^^^^^^^ Well, to be precise 'Cogentco was the last node on the route which responded'. It's impossible to say whether i) that node tossed packets that tried to go further; ii) it forwarded them to some other node (identity unknown) which did toss them (and didn't allow/handle traceroute), etc. One can't draw any conclusions about whether it's i) from the fact that it's _also_ still responding to traceroute packets sent to that address: one would have to know whether it does the a) 'is this packet to a destination I'm filtering' check before it does the b) 'I decremented the TTL and it's now zero', or the other way around. If b) it could be the node that's dropping the packets. But given that other 'last hops' are also producing similar results, I'm still thinking it's Ii.net which is tossing the packets, not the 'last hop' one can see on traceroutes. Noel

9 years, 3 months

← Newer
1
...
18
19
20
21
22
23
24
...
32
Older →

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 September 2015