- test-drb@ccmp.vtda.org - classiccmp.org

by kylevowen＠gmail.com

Can anyone identify these TTY ICs? A friend gave them to me, but doesn't recall what they came from. http://i.imgur.com/AIfiOyY.jpg Thanks, Kyle

11 years, 5 months

5
5
0 0

3Dprint switches

by vrs＠msn.com

From: John Foust: Sunday, February 01, 2015 2:23 PM > At 12:22 PM 2/1/2015, Vincent Slyngstad wrote: >>I've had excellent results ordering from Shapeways. >>The switch handles are not cosmetically pleasing when printed with the usual >>hobby gear, and the improved resolution of Shapeways' sintered nylon printer >>really helps. > > What were your results in trying the usual ABS and PLA of common > plastic printers? The part are generally functional, but there's significant "banding," where the individual extrusion layers are visible in the result. This is made worse by the need to orient the part to maximize the mechanical strength of the result. The color choices are generally quite limited, too. Admittedly, these issues can be mitigated with acetone wash, sanding and filling, and paint. But really, that's a lot more work than I wanted to do, especially for about two dozen small parts. The sintered nylon parts come smooth enough out of the "strong and flexible, polished" process, and are available in acceptable yellow and orange colors. The only issues are their porous nature and their matte finish, both of which are fixed by the urethane floor shine. (If you need PDP-11 or other colors, then you can probably substitute a suitable paint for the floor polish.) They do cost a little over $4 each, but that doesn't really seem that bad. Vince

11 years, 5 months

1
0
0 0

3Dprint switches

by jwest＠classiccmp.org

I don't recall if this was talked about here before, but I just found these via google. PDP8 http://www.thingiverse.com/thing:360853 HP 21MX http://www.thingiverse.com/thing:330821 and http://www.thingiverse.com/thing:331984 Best, J

11 years, 5 months

3
2
0 0

Destructive Imaging of DECTAPE II Media

by nf6x＠nf6x.net

I have a bunch of DECTAPE II cartridges from which I want to try recovering as much data as possible, including the console cartridges for my VAX-11/730, none of which have managed to boot the machine. Inspired by the various floppy disk imagers I have, my thinking has wandered in the direction of building an imaging device using a TU58-XA mechanism and my own drive electronics. I happen to have a few TU58-XA mechanisms sitting about to experiment with. The imagined imager would sample both tracks simultaneously with ADCs so that I could post-process the data repeatedly from a single physical pass past the heads. Maybe I'd even hack in the missing optical end-of-tape sensor rather than relying on the written end-of-tape signals. This scheme might let me recover data from tapes which confuse the normal TU58 drive electronics (say, because of corrupted sector marks). With that in mind, I dug into a box of acquired tapes to select a sacrificial dummy for experimentation, and picked out one labeled "NFG" by the previous owner, figuring I had nothing to lose with that one. Inspection revealed that the drive belt had broken and was stuck to the tape, and as expected, it peeled the oxide right off when I removed it. Is there any way to remove pieces of stuck drive belt from these tapes without harming the underlying oxide? Next, I moved on to trying to replace the drive belt with a Plastiband brand elastic band, as I've previously seen discussed for tape cartridges with this style of mechanism (including the larger QIC cartridges). I used the 2-1/8" size, and found that it seemed to be of suitable diameter to stretch around the required path. However, I have had no luck getting it to stay in place when the tape is moved. It quickly jumps off and gets tangled when I drive the tape, and I suspect that it's because these Plastibands are a bit too narrow to properly ride the crowned drive wheel and idler rollers. Let me interject that I have nothing good to say about this belt-driven cartridge design. I thought it was a bad design the first time I encountered one, and nothing has changed my opinion since then! Now I finally get to the main topic I'd like to discuss: "Destructive" imaging of DECTAPE II media. By eye, the DECTAPE II tape media looks very close to the same width as normal audio cassette tape. What if I built an imaging drive in which I remove the tape from any DECTAPE II cart to be imaged rather than trying to use the original &(#$%*$ belt drive system? I wonder whether there's any prior art for a scheme like this. One idea would be to transplant the tape media into a cassette tape housing, but I'm not yet sure whether that might offer any advantages over building an ad-hoc open reel system, or even a reel-less system since any given tape would only be run past the heads a small number of times in one event, and then might be discarded once any remaining data is extracted. I have doubts that a cassette transport's pinch roller and capstan system would work well for this scheme, since the normal tape speed of a DECTAPE II is over 15x the tape speed of an audio cassette. So, I'd probably need to fashion a different sort of capstan system, possibly negating any advantage of using cassette tape housings. I'm not sure whether it would be better to pull the tape with a capstan and pinch roller drive vs. pulling it with a take-up reel hub and providing a free-spinning capstan with an optical encoder to provide tape speed feedback. Either scheme would allow me to move the tape past the head at constant speed, but I'm not sure if one scheme might be easier to build than the other. Next, the imaginary device would need appropriate heads. I might salvage the head from a TU58-XA, though that could be a bit challenging since the heads are epoxied in place after adjustment. Or, maybe I would get lucky and discover that the heads from an auto-reversing audio tape deck (which I believe have four gaps in order to play stereo tapes in either direction without flipping them) might have gaps in the right places for reading both tracks of DECTAPE II media? Audio cassette tape heads have a few potential advantages, including not being epoxied in place and having a tape alignment guide welded on one side. What do you folks think about this silliness? -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

11 years, 5 months

7
17
0 0

vtserver mod to accommodate 11/34 console emulator

by jacob.ritorto＠gmail.com

Hi, Pardon the crudeness of this approach, but the last time I did a project like this, I never managed to communicate it to others who might've used it. I modified Warren's VTserver to work with older pdp11s, like my 11/34, that have the older console emulator that speaks differently. Warren's original expects a nice new ODT that responds to things like 165200/000004 for depositing values in memory. I modified it to talk to the 11/34-style console emulator that expect something more like L 165200 D 000004 So, my code currently works, but it's really crude with sleep(1) all over the place to mitigate overrunning the console serial. It should be merged in properly to Warren's original and rewritten to have its own command line argument other than -odt , but that said, here's the diff. Use it if you can. I hope to get around to making it nicer someday. 156a157,159 > puts("SENDING BOOT CODE VIA CONSOLE EMULATOR"); > write(portfd, "L 165000\r", strlen("L 165000\r")); > sleep (1); 158c161 < sprintf(bootbuf, "%06o/", loc); --- > sprintf(bootbuf, "L %06o\r", loc); 160c163 < --- > sleep(1); 162,163c165,166 < while (1) { read(portfd, &ch, 1); if (ch==' ') break; } < sprintf(bootbuf, "%06o\r", bootcode[i]); --- > while (1) { read(portfd, &ch, 1); printf("%c",ch); if (ch=='@') break; } > sprintf(bootbuf, "D %06o\r", bootcode[i]); 165c168 < --- > sleep(1); 167c170 < while (1) { read(portfd, &ch, 1); if (ch=='@') break; } --- > while (1) { read(portfd, &ch, 1); printf("%c",ch); if (ch=='@') break; } 169c172,174 < sprintf(bootbuf, "%06oG", BOOTSTART); --- > puts("SENDING CONSOLE EMULATOR START COMMAND"); > sleep(1); > sprintf(bootbuf, "L %06o\r", BOOTSTART); 171c176,179 < while (1) { read(portfd, &ch, 1); if (ch=='G') break; } --- > sleep(1); > sprintf(bootbuf, "S\r", BOOTSTART); > write(portfd, bootbuf, strlen(bootbuf)); > while (1) { read(portfd, &ch, 1); if (ch=='@') break; } 490a499 > printf("havesentbootcode %d\n",havesentbootcode);

11 years, 5 months

1
0
0 0

cctalk Digest, Vol 3, Issue 31

by jonas＠otter.se

On 2015-01-31 19:00, cctalk-request at classiccmp.org wrote: > On 01/30/2015 11:23 AM, js at cimmeri.com wrote: >> It's not a pond.. it's an ocean. Why do some people insist on >> calling it a >> pond? Because a pond is rather smaller than an ocean. The same logic as when I was at school and milk was known as "bull", because milk comes from a cow, which is the opposite sex to a bull.

11 years, 5 months

1
0
0 0

SIMH DG Nova and real serial port

by shadoooo＠gmail.com

Hello, I'm developing a system similar to VTserver for PDP11, but for DG Nova machines. The system uses a serial console connection and a Python back-end on the PC. Now I need to debug the binary code developed for the Nova, but I have to do it on an emulated machine on a PC. In other words, I would need to use SIMH connected to a real serial port: is it possible? Thanks Andrea

11 years, 5 months

5
4
0 0

Old ACM publications available for free (CACM, Surveys, TOCS, SIGOPS O.S. Review)

by paul＠mcjones.org

I am offering (for free) ACM publications I?ve accumulated over 40+ years as a subscriber: CACM (Communications of the ACM) 1967-2013 ACM Computing Surveys 1972-1997 SIGOPS Operating System Review 1972-2011 TOCS (ACM Transactions on Computer Systems) 1983-1991 In all, they fill about 7 file boxes. There are some gaps because I?ve already donated batches to ACM and the Computer History Museum to fill gaps in their archives. I live in Mountain View, California, and it would be best if you could pick them up. If you?re willing to pay for postage and packaging, I could mail them media mail rate within the US. Paul McJones

11 years, 5 months

1
0
0 0

Destructive Imaging of DECTAPE II Media

by shadoooo＠gmail.com

Hello, I also have an 11/730, but not working yet and it needs to be restored. The TU58 are all rusty, so probably should be replaced. I tried to find a complete TU58 system (mechanics + board) to read the cassettes, modify firmware to format DC100, and in the end to replace the bad one in the 730, but no luck so far (anybody has a suggestion on how to find one?) I have a bunch of cassettes of original software, including console tape, but they all suffer from sticky belt problem. I always avoided to move the tape to avoid the hole spot problem, and stored all of them in vacuum packaging together with silica-gel, waiting for a good restoring procedure and suitable hardware. In these days I read all these posts about reading the tape in different way, that gave me an idea: I have a TASCAM 4-tracks recorder that was using normal audio tapes. As the tape width is the same, and also track position is similar, I could try to move the tape from a TU58 cassette to an audio cassette, then read it on the 4-tracks. The machine has a knob to adjust head position slightly, so it could help. I don' t remember if the speed of the tape could be adjusted too (maybe normal / double). Sampling the audio with a good sound card could give some good data to be elaborated to extract data, of course a filtering/recovery algorithm has to be developed (using Matlab/Octave)? If the procedure would prove to be working, I could offer my help to image tapes, specially for 730 as they would be very useful also to restore my machine (I really would like to have diagnostic tapes). This procedure could work? Andrea

11 years, 5 months

2
1
0 0

Tape Drive Capstans

by jnc＠mercury.lcs.mit.edu

> From: Al Kossow > I just bought a big selection of difference sizes of Norprene tubing > from US Plastics to see how they work on various QIC drives. The first > ones I'm trying are the HP 9145 and TU58. If/when we get our wiki up, the outcome of your work would be a great thing to record there. (If you're too busy, I would be more than happy to scribe for you!) I, for instance, have a TU58 I'd like to get running some day, but given that I have about 173 higher-priority things on the list in front of it, I'm sure that by the time I get to it, I'll have some dim memory that it was talked about here, but short of good luck with Google, or a voluminous search through the archives, I won't be able to find what I need - and I'll have to ask... :-( Had we all that kind of stuff in a wiki, on the other hand... :-) Yes, not everyone will be diligent enough to check the wiki before they ask, but hey, if they don't, you all can enjoy yourself flaming them for not being willing to exert themselves to learn how to fish, before asking to just be given some.. :-) Noel

11 years, 5 months

5
4
0 0

OT Re: Pair of HP 1000 E-Series minicomputers on eBay

by kspt.tor＠gmail.com

On 30 January 2015 at 23:43, js at cimmeri.com <js at cimmeri.com> wrote: > > > On 1/30/2015 5:35 PM, Jules Richardson wrote: >> >>> And "whilst" I'm at it, why do some insist on using "blinkenlights" in re >>> CPU front panels instead of correct English -- blinking lights? >> >> >> Because it's mildly amusing. > > > Maybe the first time it was... :) It's not only that. It's because 'blinking lights' is generic, it could mean anything. But 'blinkenlights'.. you'll *know* what it means.

11 years, 5 months

1
0
0 0

Pair of HP 1000 E-Series minicomputers on eBay

by jnc＠mercury.lcs.mit.edu

Here: http://www.ebay.com/itm/141300893919 The seller has them listed at 'Buy-It-Now' for $1,800, but the listing does say 'make an offer', so you might be able to get it down a ways, to something more reasonable. They seem like they have an interesting (non-identical) set of peripheral cards. However, I know nothing of HP's, so take this all with a large grain of salt! Noel

11 years, 5 months

9
9
0 0

strange number corruption on pdp11/34

by ak6dn＠mindspring.com

-----Original Message----- >From: Noel Chiappa <jnc at mercury.lcs.mit.edu> >Sent: Jan 30, 2015 5:19 AM >To: cctalk at classiccmp.org >Cc: jnc at mercury.lcs.mit.edu >Subject: Re: strange number corruption on pdp11/34 > > > From: Don North > > > So here is the octal print routine in the M9312 console boot prom for > > the '34: > >I'm curious, is that the 'original' source, or is this dis-assembled from the >PROM contents? Is the complete program available somewhere? Disassembled and re-commented source. Available here: http://ak6dn.dyndns.org/PDP-11/M9312/ along with most all of the other M9312 boot and device PROMS. > > > So I would speculate either 'rol' or 'rolb' are always rotating in a 0 > > bit instead of the c-bit, or possibly the c-bit is stuck at zero. > >Yup, good suggestion. And that would likely explain why things boot; I can't >see too many OS's using 'ROLB'! > > Noel

11 years, 5 months

1
0
0 0

Pair of HP 1000 E-Series minicomputers on eBay

by marc.verdiell＠gmail.com

>ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN. This is hilarious (particularly if you know German)! I didn't know about it, thanks for posting! I'll hang it above my collection! Marc ------------------ Because the Faux German Blinkenlights is so much cooler to say. It?s a corruption of Blinenlichten from an old joke: ACHTUNG! ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS! DAS KOMPUTERMASCHINE IST NICHT F?R DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN. IST NICHT F?R GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN H?NDER IN DAS POCKETS MUSS. ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN. which dates to the 1950?s? See also the insistence on the plural of VAX being VAXEN. Warner -----------------

11 years, 5 months

1
0
0 0

Warren's 'VTserver'

by jacob.ritorto＠gmail.com

Has anyone used this software ftp://minnie.tuhs.org/pub/PDP-11/Vtserver/README against a real pdp11? I'm trying to use it to install a disk image on my 11/34, now, and after keying in the initial code, it appears to happily upload the first file (standalone 'copy') quite successfully, but then hangs. Since Warren has no real pdp11s, I'm wondering if the emulators he used whilst authoring this VTserver do something different than a real '11 that keeps the program >from proceeding. thx jake

11 years, 5 months

7
11
0 0

PDP-8/E EAE MUY Instruction

by kylevowen＠gmail.com

I've been working on a software emulation of the Extended Arithmetic Element for the PDP-8/E. I've been struggling a little with the multiply (MUY) instruction in particular. I don't have an actual EAE to test this all with, but I'd appreciate anyone with one to test out a bit of code to confirm. In any event, both SimH and the OS X PDP-8/E Simulator exhibit the same symptoms, which seem to multiply (PC + 1) by MQ and add AC, placing that result into AC, MQ. Expected behavior, best I can tell from the Maintenance Manual Volume 2, would be (PC + 1) * MQ -> AC, MQ, without the addition of the previous AC prior to executing MUY. If this is the case, then clearing AC would be essentially required, unless you want to add that value after the multiply (which could be a useful mathematical operation in some circumstances). There is a little code found on bitsavers that seems to emulate these EAE instructions: http://bitsavers.trailing-edge.com/bits/DEC/pdp8/From_Vince_Slyngstad/digit… You'll note that there is no DCA at the top of the MUY subroutine to save AC in order to add it to MQ (and complete the carry) afterward. I've been writing a comparison tool after finding that one program changed to support the software EAE failed to function correctly, hence attempting to track down some differences. If you're interested in trying on real hardware (which would be appreciated), here's what I'm running: MUY=7405 DVI=7407 NMI=7411 SHL=7413 ASR=7415 LSR=7417 MQL=7421 SCL=7403 SCA=7441 MQA=7501 CAM=CLA MQL *200 CLA CLL TAD MQVAL MQL TAD ACVAL HLT MUY 7777 HLT MQVAL, 7777 ACVAL, 7777 $ After the first halt, AC=MQ=7777, as expected. After continuing, AC=7777, MQ=0000. This would be equivalent to 7777*7777+7777=77770000, rather than the expected value of 7777*7777=77760001. Any help would greatly ease my concerns! Kyle

11 years, 5 months

2
2
0 0

UNIBUS PDP-11 memory expander card

by jnc＠mercury.lcs.mit.edu

> From: jws > I sent a bit of this thread along to Ken Omohundro who founded Able .. > If he sends anything else along, I'll get it to somewhere people can > find out about it. Neat! Thanks! > I probably have data sheets archived and I will scan them as a PDF file Those would be great - I hope they include enough detail to explain how the ENABLE hooked up the various busses, cache, etc! I live in hope that someone finds a manual, because that may be the only way these questions get answered. Also, I wonder if the product called the "ENABLE/34" (per various brochures, Muuss' email, etc) and the "ENABLE" we ran in the 11/45 were actually the same thing, and they had just changed the name, perhaps because people might have assumed, from the "ENABLE/34" name, that it was only for /34's, when in fact it could run in any UNIBUS machine? The name change may have opened up a bigger market for them. Anyway, another mystery about these things! Noel

11 years, 5 months

2
1
0 0

11/34 up! (sort of)

by jacob.ritorto＠gmail.com

Woohoo, I finally, after over a decade of being somewhat out of the pdp11 hobby, have managed to bring back to life one of my pdp11/34s! It's a plain 11/34 with dl11-w, ky11-lb, ms11-L, rl11 and a M9312 terminator/boot rom board. I have an emulex controller and some fuji 160s I'll tack on later so I can run 2.9BSD once I get the basic build confirmed safe. It's not in great shape at the moment, apparently, as these xxdp 2.5 diags are crashing left and right. But it at least boots the os and tries. I initially had, but mysteriously lost the console emulator/ODT functionality, seems it's starting at 165000 instead of 165200 at poweron. Maybe a 9312 switch mis-set... So I'm booting from the panel by calling the address of the ODT or the rl02 boot rom, which does the trick. Would anyone care to recommend some xxdp diags I should be running or next steps to isolate what's wrong / right with it? thx jake P.S. I tried to boot rsx11m v4.1, but got a strange crash with all zeroes in the stack and registers. What might that indicate? @DL0 DEVICE DD000: NOT IN CONFIGURATION DEVICE DD100: NOT IN CONFIGURATION DEVICE DY002: NOT IN CONFIGURATION DEVICE DY102: NOT IN CONFIGURATION MEVICE NI002: NOT IN CONFIGURATION RSX-11M V4.1 BL35 124.K MAPPED SYSTEM CRASH AT LOCATION 000000 REGISTERS R0=000000 R1=000000 R2=000000 R3=000000 R4=000000 R5=000000 SP=000000 PS=000000 SYSTEM STACK DUMP LOCATION CONTENTS 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 CRASH -- CONT WITH SCRATCH MEDIA ON DY0

11 years, 5 months

2
3
0 0

XXDP generic memory test

by roeapeterson＠gmail.com

I just can't seem to figure out the right XXDP file to run for a straight memory test. I've got a new (for me) pdp11/23+ with M8044 memory boards, and I'd like to run memory tests, but I'm damned if I can figure out what, exactly, to run. This is XXDP 2.5 Thanks for any advice.

11 years, 5 months

6
8
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Don North > So here is the octal print routine in the M9312 console boot prom for > the '34: I'm curious, is that the 'original' source, or is this dis-assembled from the PROM contents? Is the complete program available somewhere? > So I would speculate either 'rol' or 'rolb' are always rotating in a 0 > bit instead of the c-bit, or possibly the c-bit is stuck at zero. Yup, good suggestion. And that would likely explain why things boot; I can't see too many OS's using 'ROLB'! Noel

11 years, 5 months

1
0
0 0

VCF East keynote change

by evan＠snarc.net

There's a change to the keynote plans for VCF East. Ted Nelson is unable to attend due to a family issue. He sends his regrets, and said he'll try to make it up to us another time. Wes Clark will take Ted's place on Saturday morning at the show. We are looking for other speakers and/or entertainment for the Saturday dinner (when Wes was scheduled to speak). Details are frequently updated at http://www.vintage.org/2015/east. - Evan

11 years, 5 months

1
0
0 0

strange number corruption on pdp11/34

by ak6dn＠mindspring.com

So here is the octal print routine in the M9312 console boot prom for the '34: ; print an octal number followed by one <SP> ; ; R0 = register value to print ; R1 = return address ; R2 = temp char ; R3 = temp addr prtoct: mov #<'0/bit1>,r2 ; ascii 0 right 1b sec ; shift a 1 into R0 lsb as done bit 1$: rol r0 ; msb out of R0 rolb r2 ; into lsb of R2 mov pc,r3 ; ret addr br txchar ; print char in R2 mov #<BL*bit8>+200+<'0/bit3>,r2 ; ascii SP upper, ascii 0 right 3b lower 2$: asl r0 ; msb out of R0 beq 3$ ; when R0 has gone to zero we are done rolb r2 ; into lsb of R2 bcs 2$ ; loop once more if flagbit was set br 1$ ; go get last bit and print char 3$: swab r2 ; move the SP from upper byte to lower mov pc,r3 ; ret addr br txchar ; print the space char in R2 retR1: cmp (r1)+,(r1)+ ; bump return address ptr R1 by +4 jmp -2(r1) ; return to (R1)-2 So I would speculate either 'rol' or 'rolb' are always rotating in a 0 bit instead of the c-bit, or possibly the c-bit is stuck at zero. -----Original Message----- >From: Jacob Ritorto <jacob.ritorto at gmail.com> >Sent: Jan 29, 2015 7:08 PM >To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> >Subject: Re: strange number corruption on pdp11/34 > >So, pardon the large post, but here's the real comparison between my >'mysterious zero bug' KD11E-A cpu board M8266, and my good one: First is >the bad. Note that even at power on, I have to halt and restart the >console emulator at 165200. Look at the registers, all blanked to zeroes >and missing digits, too. It did manage to boot xxdp, but when I tried to >enter the correct address and vector to ZRLG??, it actually told me I was >wrong and couldn't even run the test on the device that way. Then I just >accepted the default (which was presented as zeroes) and it did run. Two >passes. Blinking lights and audible head movement. I let it run for two >passes, but it presented even that as zero passes and spit a bunch of >zeroes in the results. Just for kicks, I then booted (and very promptly >crashed) RSX. It crash-dumped, giving a whole lot of zeroes. Next post >will be same test with the good KD11E-A; stay tuned.. > >thx >jake > > >?@ >000000 000 00000 000000 >@ >0 000 00000 00000 >@ >0 000 00000 00000 >@ >0 000 00000 00000 >@ >0 000 00000 00000 >@ >0 000 00000 00000 >@DL? > > >BOOTING UP XXDP-XM EXTENDED MONITOR > > >XXDP-XM EXTENDED MONITOR - XXDP V2.5 >REVISION: F0 >BOOTED FROM DL0 >124KW OF MEMORY >UNIBUS SYSTEM > >RESTART ADDRESS: 152000 >TYPE "H" FOR HELP ! > >.R ?RLG?? >NRLGA0.BIC > >DRSSM-G2 >CNRLG-A-0 >CNRLG TESTS CONTROLLER FUNCTIONS, INTERFACE LOGIC, REGISTER OPERATION >UNIT IS RL01,RL02 >RSTRT ADR 000000 >DR>START > >CHANGE HW (L) ? Y > ># UNITS (D) ? 1 > >UNIT 0 >RL11=1, RLV11=2, RLV12=3 (O) 0 ? 1 >BUS ADDRESS (O) 0 ? 174400 > ># TOO LARGE >BUS ADDRESS (O) 0 ? 174400 > ># TOO LARGE >BUS ADDRESS (O) 0 ? >VECTOR (O) 0 ? 160 > ># TOO LARGE >VECTOR (O) 0 ? > >TOO MANY VALUES INPUT >VECTOR (O) 0 ? >DRIVE (O) 0 ? >DRIVE TYPE = RL01 (L) Y ? N >BR LEVEL (O) 0 ? 5 > >CHANGE SW (L) ? N > >NXT TST MAY ZERO LD UNIT. DOIT ANYWAY?Y > > > ILL INTER 000 > PC 000000 PS 000000 >DR>START > >CHANGE HW (L) ? Y > ># UNITS (D) ? > >NO DEFAULT ># UNITS (D) ? 1 > >UNIT 0 >RL11=1, RLV11=2, RLV12=3 (O) 0 ? 1 >BUS ADDRESS (O) 0 ? >VECTOR (O) 0 ? >DRIVE (O) 0 ? >DRIVE TYPE = RL01 (L) Y ? N >BR LEVEL (O) 0 ? > >CHANGE SW (L) ? N > >NXT TST MAY ZERO LD UNIT. DOIT ANYWAY?Y > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG EOP 0 > 0 TOTAL ERRS > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 >BAD SEEK-TEST OF DIFFENCE WORD >CONTROLLER: 000000 DRIVE: 0 >BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000 >TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000? >LAST: 000000 PRES: 000000 EXP'D: 000000 > >CNRLG EOP 0 > 0 TOTAL ERRS >^C >DR>^C^C >DR> >XIT^U >EXIT >?@ >000000 000 00000 000000 >@ >0 000 00000 00000 >@ >0 000 00000 00000 >@ >0 000 00000 00000 >@DL? > DEVICE DD000: NOT IN CONFIGURATION >DEVICE DD100: NOT IN CONFIGURATION >DEVICE DY002: NOT IN CONFIGURATION >DEVICE DY102: NOT IN CONFIGURATION >DEVICE NI002: NOT IN CONFIGURATION > > RSX-11M V4.1 BL35 124.K MAPPED > >SYSTEM CRASH AT LOCATION 000000 > >REGISTERS > > R0=000000 R1=000000 R2=000000 R3=000000 > > R4=000000 R5=000000 SP=000000 PS=000000 > >SYSTEM STACK DUMP > > LOCATION CONTENTS > > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > 000000 000000 > > >CRASH -- CONT WITH SCRATCH MEDIA ON DY0 > >On Thu, Jan 29, 2015 at 9:30 PM, Jacob Ritorto <jacob.ritorto at gmail.com> >wrote: > >> ok, now with my 'good' 11/34 board set (not the set with the mysterious >> zero bug) installed, I re-ran xxdp against the rl02. I'm getting proper >> prompts with the address and vectors supplied with non-zero numbers as >> defaults. I just hit return like I had been doing with the 'zero-bug' cpu >> boards and this time, the tests run, the drive blinks wildly like before, >> and I get real results with real numbers filled in. I think this pretty >> conclusively proves that there's something really weird (mysterious zero >> bug) going on with my other board set. >> >> On Thu, Jan 29, 2015 at 7:15 PM, Johnny Billquist <bqt at update.uu.se> >> wrote: >> >>> On 2015-01-29 20:14, Pete Turnbull wrote: >>> >>>> On 29/01/2015 18:32, Jacob Ritorto wrote: >>>> >>>>> Johnny, you're insisting that I put in the real numbers for address >>>>> and csr >>>>> for testing the drive (for instance). I'm going to do that next, here. >>>>> But are you understanding that some of us think that the reason it >>>>> prompts >>>>> a zero default is that it's a manifestation of the zero bug and that the >>>>> real value *is* actually safe but hidden in memory? Did you see the >>>>> RSX-11M crash dump I posted in the other thread? >>>>> >>>> >>>> I didn't see a crash dump, but did you see what I posted yesterday? >>>> >>> >>> I haven't seen any crash dumps either. >>> >>> The default in XXDP for CSRs is very often zero, and I'm pretty sure it >>>> is so in the RL02 diagnostics (I've ont checked the listing for that >>>> particular one, but I did look at some others that were more readily to >>>> hand). So when it asked you for input and you just hit "return", you >>>> really did tell it zero. Applying the principle of Occam's Razor, and >>>> assuming the simplest solution is the correct one, you got a lot of >>>> zeros back because it was accessing memory instead of the controller you >>>> wanted. >>>> >>>> It's hard to believe you have a CPU fault that consistently prints >>>> numbers as zeros yet happily boots three different OSs. Still, I'll >>>> change the tune if you re-run XXDP with sensible inputs. >>>> >>> >>> Totally agree with that one. >>> >>> >>> Johnny >>> >>> -- >>> Johnny Billquist || "I'm on a bus >>> || on a psychedelic trip >>> email: bqt at softjar.se || Reading murder books >>> pdp is alive! || tryin' to stay hip" - B. Idol >>> >> >>

11 years, 5 months

1
0
0 0

UNIBUS PDP-11 memory expander card

by jnc＠mercury.lcs.mit.edu

So, I'm in the process of trying to read those old MIT V6 Unix dump tapes (with a really big hand from Chuck, who did all the ugly work of actually reading the bits off the tapes, for which he has my undying gratitude!), and although I'm still trying to figure out what the format is, I did manage to retrieve, more or less, a copy of the assembler startup/support file (m47.s; a hacked version of m45.s), and it reveals that we were using an Able ENABLE card to take our 11/45 out to more than 256KB. I found a copy of brochure which very briefly describes/shows it here: http://archive.org/stream/bitsavers_ablebrochuuctSummary_2920347/Able_Compu… and although the picture didn't ring any bells for me, that must be it. It looks like it has a UNIBUS connector (which I take it is 'UNIBUS out'), and also some kind of 'over-the-back' connector which I assume is the bus to the memory, which sounds (from a brief mention I found somewhere else) like it was standard Extended UNIBUS memory in a separate backplane. (Although I could be wrong; maybe the ENABLE plugged into the EUB backplane, and the UNIBUS connector is 'UNIBUS in' from the CPU?) I was unable to locate any real documentation for it online (maybe my Google-fu just isn't strong enough), but if someone has any, or can point me at any, I'd be grateful. Any if anyone actually has one, in the flesh, that would be Really Cool! Noel

11 years, 5 months

9
12
0 0

strange number corruption on pdp11/34

by rick＠rickmurphy.net

At 07:34 PM 1/27/2015, Jacob Ritorto wrote: >Johnny, I just took the defaults, >BUS ADDRESS (O) 0 ? What Johnny said. The prompt says "(O)", not "(0)" - the letter O for Octal. The zero after that isn't a default, it simply means that the value hasn't been set. There is no default. Or at least no sane one. Zero in this case means that it's writing to memory address zero for CSR. The diagnostic should reject that, but diagnostics are notoriously user unfriendly. -Rick

11 years, 5 months

5
13
0 0

Spacewar!

by lbickley＠bickleywest.com

For those of you who are Spacewar! buffs and you haven't seen Norbert Landsteiner's work, you are missing something big. Norbert has what I believe to be the best simulation of original PDP-1 Spacewar! code running on a Model 30 display. And he doesn't just have one version Spacewar! - but several original versions. In addition, Norbert analyzed the original Spacewar! code line-by-line and created an incredible set of writeups on Spacewar! internals. As Norbert created his writeups, he sent them to me. I read them over, and forwarded them to the entire PDP-1 Team at the Computer History Museum. That Team includes Steve Russell (principal author of Spacewar!) and Peter Samson (Spacewar! star field, etc.). Additionally, I met with both Steve and Peter and we reviewed several of Norbert's writeups together in some detail - and found only a few minor corrections/comments to pass back to Norbert. Here are links to Norbert's work: Simulation ---------- http://www.masswerk.at/spacewar/ Writeups (Inside Spacewar!) --------------------------- http://www.masswerk.at/spacewar/inside/ Cheers, Lyle -- Bickley Consulting West Inc. http://bickleywest.com "Black holes are where God is dividing by zero"

11 years, 5 months

1
0
0 0

XXDP generic memory test

by jnc＠mercury.lcs.mit.edu

> From: Roe Peterson > How is it that googling > XXDP manual > XXDP documentation > XXDP memory test > Doesn't point at this? Because Googling, useful as it is, is inferior to humans^H^H^H intelligences actually sorting things out, and organizing them in a structured manner. (The way Yahoo worked when it very first started...) Now, if we had a wiki.... :-) Noel

11 years, 5 months

3
2
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I just need quite a lot of hand holding because I'm still way too green > with this stuff. Hey, that's what this list is for, right? ;-) > put in the real numbers for address and csr for testing the drive ... > I'm going to do that next, here. ... the reason it prompts a zero > default is that it's a manifestation of the zero bug and that the real > value *is* actually safe but hidden in memory? One other thing you could do that would be interesting: re-run the exact same test, but with the good cards in the machine, and see if you still get 0's printed, or if this time the correct numbers show up. Of course, that won't definitely prove that the right numbers are actually being used inside (in the case where it prints 0's), but it would certainly be suggestive. Noel

11 years, 5 months

2
1
0 0

Destructive Imaging of DECTAPE II Media

by jhfinedp3k＠compsys.to

>Alexandre Souza wrote: > ----- Original Message ----- From: "Mark J. Blair" <nf6x at nf6x.net> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Sent: Tuesday, January 27, 2015 3:04 PM > Subject: Destructive Imaging of DECTAPE II Media > > [Snip] > > What do you folks think about this silliness? It has been over 2 years since I last used my TU58 tape drive, but it was still working then with (of course USABLE) TU58 tapes, although a good percentage were no longer in that category. If it seems reasonable, I can try to see if the TU58 tape drive will still function correctly. If the TU58 tapes which need to be recovered can still be read by a TU58 drive, then I could undertake to recover those ones. Note that I am in Toronto, so postage would be MUCH more than within the US. Unfortunately, there is no visual difference between tapes which can still be read and those which have errors that can't be recovered. But if the tape can't even be moved or the drive belt is broken, either of those problems would prevent a standard DEC TU58 drive from being able to recover any data from the tape. Jerome Fine

11 years, 5 months

5
6
0 0

UNIBUS PDP-11 memory expander card

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > I searched around a bit more today. > I did find a couple of brochures on bitsavers that mentions it. Err, you didn't need Google for that - the first post in this thread mentioned it... :-) >> Standard Extended UNIBUS (a la 11/24 and 11/44), I think. > "Standard" is a strong word here. :-) Well, 'standard' in the sense that more than one DEC machine used it, and one could buy third-party memory cards that conformed to it. > The Megabox .. As far as I know, it is not a Unibus at all. And it > still could not be a Unibus, for the same reason I mentioned above. I _suspect_ that internally it has a backplane which supported EUB, and the memory plugged into that; whether that was a custom backplane, or what, I don't know. (I'd have to check the wire-lists on, say, a DD11-D to see if those pins are bussed together - I have this vague memory that they are.) And yes, _iff_ the cable to it is a standard UNIBUS cable (I don't know what kind of cable they used), that would only support the 18-bit address space - which would imply that the ENABLE card was in the Megabox. >> (And I can show you the code... :-) The original MMU was retained; the >> ENABLE included only a second set of PARS (full 16-bit wide), which >> were the ones normally used while the system was running; the PDRs in >> the CPU continued to be used as the _only_ PDRs in the system. > That would imply you could not address more than 256K from the CPU. Not > likely... Dude, I PERSONALLY WROTE THE CODE TO USE THE ENABLE. And I have the source, here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/conf/m47.s You are correct, the CPU cannot _directly_ address more than 256KB. However, the ENABLE board _can_; mapping registers in the ENABLE (32 of them, each handling an 8KB section of incoming UNIBUS address space, from the CPU) allow that UNIBUS address space to be mapped, in 8KB blocks, anywhere in the 22-bit memory space. You will find it all laid out most ably in this old post by Mike Muuss (peace, Mike): http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.12_u… It looks like I used a slightly different layout of the address space on the UNIBUS from the CPU to the ENABLE from the one he describes (the code in m47.s seems to use: KI0-7 KD0-6 UI0-7 UD0-7 KD7 I/O page with the KI underneath the KD, unlike his; KD7 has to be at the top so that the CPU can get to the registers in the ENABLE), but other than that the details are identical. (Note that they only differ in how the registers were _used_, not in terms of what the hardware's capabilities were.) >> The style of usage was to, using the CPU's PARs, statically map Kernel >> D space to one quadrant of UNIBUS address space, Kernel I to a second, >> User D to a third, and User I to the fourth. > The 11/34 do not have D-space... I was talking about on the /45. >> The PARs on the ENABLE card (which controlled which part of real >> memory various addresses on the first UNIBUS got mapped to) were the >> ones the operating system adjusted as the system was running. > Sorry, this is simply not how it worked. Repeat previous comment about how I personally wrote the code to use it. Just for you, I have groveled around in the dump I'm working on retrieving, and found seg.h, which is the header file which contains the #defines for the mapping registers in Unix V6. Here it is: http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/h/seg.h If you look at it, you will see that UISA[0] has been modified to be "0163736". That's how we did the ENABLE - we just changed those definitions, and recompiled all the system modules that touched the mapping registers, so that that code now talked to the 16-bit PARs on the ENABLE, and not the 12-bit ones in the KT (which were set once at system startup time to provide the static mapping - see m47.s - and then never changed again). > Like I said, I actually used an 11/34 with the ENable/34 and the > separate memory box for a few years. It really looked and behaved > identically to an 11/24. Ie, full 16-bit PARs, still no split I/D space. Yes, no split I/D because it was totally external to the CPU, it could only take the UNIBUS addresses the CPU generated and map them around. >> I'm kind of hazy on exactly how this was all wired up: there are the >> fingers on the card (which I think _might_ be the EUB used for the >> memory bus), the UNIBUS edge connector on the ENABLE card, and that >> over-the-back connector on the ENABLE card. > An 11/34 do not have any EUB slots. I was assuming that the ENABLE used an EUB to talk to its memory. (See diagram further up the original post.) > (You should see Updates storage rooms...) Even better would be being allowed to poke around in there... :-) > I was running RSX-11M and RSX-11M-PLUS on our 11/34, and no > modifications to the kernel was needed. There must have been some changes somewhere, since as you can see from the code above, the ENABLE had PARs in non-standard locations (0163700-0163776). Anyway, if you could find the documentation that would be super-wonderful, because I am _really_ curious to know exactly how the thing interfaced to the incoming UNIBUS, outgoing UNIBUS, memory, and cache. Noel

11 years, 5 months

2
1
0 0

Sugru (moldable rubber) for ???

by lproven＠gmail.com

On 25 January 2015 at 00:04, John Foust <jfoust at threedee.com> wrote: > I haven't ever played with official Sugru, but how does it differ > from ordinary relatively inexpensive Shoe Goo? Is Sugru like > slightly dried-out Shoe Goo? I find that a tube of Shoe Goo > dries out a bit after a few years and becomes a more easily worked > substance. I've never heard of this Shoe Goo stuff before, so I can't comment on a direct comparison. I've used a differently-branded Sugru alternative, though. It's not an adhesive and it's not sticky. It's like Plasticine or other modelling clay -- a smooth, non-tacky, very viscous colloidal gel, which can be moulded and shaped. It only adheres to things by virtue of being moulded onto and around them; if you need to, say, stick it to a flat surface, you'd have to glue it on. But when it sets, it goes hard - like a hard rubber. You can make a small mark with a fingernail but this will eventually smooth out. It's no more pliable than a piece of truck tyre when cured. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

11 years, 5 months

10
27
0 0

UNIBUS PDP-11 memory expander card

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > However, the was one board that went into the CPU box, and then there > was a cable or two out from that to a separate memory box that held the > memory. So the memory cards themself was not in the CPU box Right, that's a product called the Megabox; details I can find online about it are thin, but it seems to include the Extended UNIBUS backplane the memory sits on, and the memory cards. (Google 'ABLE Enable Megabox' and it'll pop up a short Computerworld blurb about it.) > The machines that had more than 256K of memory, and were Unibus based, > and had the memory on the "unibus" actually had a special backplane for > the memory cards, where otherwise unused signals were used to do the > extra addressing bits. Standard Extended UNIBUS (a la 11/24 and 11/44), I think. > Which also means that all the memory cards had to sit in the same > backplane as the CPU. They could not be put in any other Unibus > backplane. Anyway, no, the memory did not have to be in the same backplane as the CPU; see the Megabox, where the memory was in that box. However, a caveat: there is some possibility there was more than one version of the ENABLE, in which case two seemingly contradictory statements about 'the' ENABLE might in fact both be correct. But until that's shown, let's assume there's only one kind... :-) The thing that I think did have to be on (in, actually - see below) the main UNIBUS was the ENABLE card. I think the logical configuration was like this (diagram semi-ripped off from Mike Muuss' email): Processor ---------- ENABLE ------------------------ Term. UNIBUS | | UNIBUS | EUB | | | |_ 11/44 style | memory |_ Devices (both DMA and non-DMA) I think all the devices - well, you could have put non-DMA devices on the section between the CPU and the ENABLE - all DMA devices at least, had to be on the second UNIBUS, because the ENABLE included a UNIBUS map, which was separate from the PARs used for CPU accesses, so I think that's pretty conclusive that the CPU and DMA devices did not share a UNIBUS. > and you'll get a new MMU which implements all the bits in the PAR > registers. .. > So, it also implies that the original MMU have to be removed. No. (And I can show you the code... :-) The original MMU was retained; the ENABLE included only a second set of PARS (full 16-bit wide), which were the ones normally used while the system was running; the PDRs in the CPU continued to be used as the _only_ PDRs in the system. The style of usage was to, using the CPU's PARs, statically map Kernel D space to one quadrant of UNIBUS address space, Kernel I to a second, User D to a third, and User I to the fourth. (You wanted to use Supervisor mode too? Thhhppptttt!) Those mappings would be on the segment between the CPU and ENABLE; once initially set up, those mappings (i.e. CPU PAR contents) were never changed. The PARs on the ENABLE card (which controlled which part of real memory various addresses on the first UNIBUS got mapped to) were the ones the operating system adjusted as the system was running. > And that is where you put the new card in. I don't think so. I'm kind of hazy on exactly how this was all wired up: there are the fingers on the card (which I think _might_ be the EUB used for the memory bus), the UNIBUS edge connector on the ENABLE card, and that over-the-back connector on the ENABLE card. Then there were 4 things that had to be connected up: the CPU UNIBUS, the memory EUB, the device UNIBUS, and an optional cache memory card ... but we have only three connectors. So whether the cache somehow hung off the EUB, or directly from the ENABLE via a custom backplane, or what, I'm not sure. > I don't know anything about the 11/45 extension this way. Like I said, > I only played with an 11/34 that had this. Anything you could do on the /34 could of course also be done on the /45 (since the ENABLE did not involve any mods to the CPU, it just interfaced to the UNIBUS). Although I have this bit set that perhaps it - or, one variant of the ENABLE (see comment above about more than one) - somehow used the fast memory slots in the 11/45 backplane (originally designed for special high-speed solid state memory) and that's how you got full advantage of the cache. (I have this distinct memory of running 'mips' on our /45 after it was upgraded and the result was '3'...) But probably something in my memory is flaky - it was a long time ago. > I probably should try to find the documentation for exact details here > then. I might be able to track down the machine, but I haven't seen it > in almost 20 years. If you could track down the documentation, that would be really good. The programming of the thing we can work out (in addition to my code for V6 Unix, there is code online for other versions of Unix which support it, e.g. BSD2.9). It's the physical installation details which are murky... Noel

11 years, 5 months

2
1
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > but now that the problem has been isolated and removed, I'm inclined to > just enjoy the pdp11 :) I'd really recommend fixing at least one more board set - otherwise, when the next failure happens, you'll have _no_ working board sets... Noel

11 years, 5 months

1
0
0 0

VCF East exhibits update

by evan＠snarc.net

We're up to 25 exhibitors for VCF East so far: http://www.vintage.org/2015/east/exhibit.php We'll definitely exceed 30, as we did last year for East 9.1 (33). How high will it go? 35? 37? Will we somehow squeeze in 40, which would be the most of any VCF ever? If you're thinking about exhibiting, then do not wait. Register now while there is space.

11 years, 5 months

4
4
0 0

thread on tools

by useddec＠gmail.com

I can't seem to find the thread on precision screwdrivers and other tools. I might have mistakenly deleted it. I planned on reviewing it to buy some new tools and now I'm stuck. Can someone please get me in the send me a copy of it? Thanks, Paul

11 years, 5 months

1
1
0 0

Seeking an ECL monitor (preferably for a dimple-top Sun base) and Sun 3 Keyboard and Mouse

by ian.finder＠gmail.com

> Trying to get my 3/50 restored... If anyone has these available I would like to purchase them from you. > > Understand it might be a long shot. > > I'm in Seattle, WA > > Thanks, > > - Ian > > -- > Ian Finder > (206) 395-MIPS > ian.finder at gmail.com

11 years, 5 months

8
11
0 0

new-old-tech news

by hilpert＠cs.ubc.ca

Not my thing really, but of interest to some here I expect (pardon if I missed it and it's already been mentioned on the list): "Remodelled ZX Spectrum production set to begin" http://www.bbc.com/news/uk-england-nottinghamshire-30810148 Also, not especially computers, but: "Why can't we let go of our old tech?" http://www.bbc.com/news/technology-30879638

11 years, 5 months

2
1
0 0

UNIBUS PDP-11 memory expander card

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I just happen to have one in my hand as we speak. I'll photograph it... Hmm. That photo (here: http://ana-3.lcs.mit.edu/~jnc/jpg/PDP11s/AbleENABLE.jpg if anyone wants to see it) shows a very different card than the one in the brochure. That one's a hex card, with an over-the-back connector: this one's quad, no OTB connector. This looks more like a QNIVERTER? Does it say 'ENABLE' on it anywhere? (Which would imply there was more than one variant... which would be interesting, because I have this bit set that the one we had at MIT was not like the one described here: http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.09_u… because I'm pretty sure that on ours, the DMA devices were on the far side of the ENABLE - which makes sense, because ours had separate PARs and UNIBUS map registers, which make no sense in that configuration - unless Mike [blessings, wherever you are] made a mistake in drawing that up.) Noel

11 years, 5 months

1
0
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: John Wilson > The *ability* to accept the FPP (and/or cache -- M8268 I think?) Yup, M8268. > And you need the right over-the-top connector (hazy memory says H882 or > H8822 for either or both option but I may have made those up). There are two: if one has only an FPP (M8268) _or_ a cache (M8268) one needs a single OTB connector, H8821 (they both go in the same slot, if one has only one of the two). If one has _both_ the FPP _and_ cache, one needs a double OTB connector, H8822. > Better to reduce the variables and leave the FPP off for now. Indeed! > From: Jacob Ritorto > I ended up ... mix-and-matching 8265 and 8266 boards from the old and > new sets to make a system that doesn't bus error and doesn't print > weird zeroes. Let me make sure I get this. You have two M8265's, A and B, and two M8266's, C and D. You're saying that _only_ the combination AC works; that AD, BC and BD all fail? In other words, only A and C work, and both B and D are bad? > thank you all again for the insights and interest! Hey, that's what we're here for! > If anyone is really interested in debugging these "bus error / > zero-inducing" cpu boards to find out what on earth was causing the > problem, I'd be happy to loan them out. Nah, I've got enough of my own stuff to work on... :-) But if you decide you have no use for dead cards, and want to sell/trade, please let me know! > Heck, I might even try to do what we were talking about initially and > write up some little math tests if you're really curious. Well, I'm mildly curious, but _iff_ you want to repair them, you need to do some of that, to try and figure out what the bug(s) are. (And of course there's that busted M7265/M7266 set, too!) Since you have 3 sets, and only one works, you might want to get a second set working before that set dies on you, too... :-) Noel

11 years, 5 months

1
0
0 0

strange number corruption on pdp11/34

by jacob.ritorto＠gmail.com

Hi, I'm getting all zeroes nearly any time there's supposed to be a large number output to my terminal. Does this sound familiar to anyone? This happened last night on rsx and is also happening today on xxdp. example xxdp testing rl02: DRSSM-G2 CZRLK-B-0 CZRLK PERFORMS RANDOM OPERATIONS OF GET STATUS, SEEK, READ, AND WRITE UNIT IS RL01,RL02 RSTRT ADR 000000 DR>START CHANGE HW (L) ? Y # UNITS (D) ? 1 UNIT 0 RL11 (L) Y ? Y BUS ADDRESS (O) 0 ? VECTOR (O) 0 ? DRIVE (O) 0 ? DRIVE TYPE = RL01 (L) Y ? N BR LEVEL (O) 0 ? CHANGE SW (L) ? N NXT TST MAY ZERO LD UNIT. DOIT ANYWAY?Y TESTING STARTED CZRLK HRD ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 DR ERR TIME: 00:00:00 RLCS: 000000 DRIVE: 0 DRIVE TYPE = RL00 >> FUNCTION: WRITE BEFORE ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 AT ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 DR ERR ADDR = CYL: 000. SUR: 0 SECT: 00. STATUS WAS: 000000 LST POS: 000000 DR ERR - RECOVERED CZRLK HRD ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 DR ERR TIME: 00:00:00 RLCS: 000000 DRIVE: 0 DRIVE TYPE = RL00 >> FUNCTION: WRITE BEFORE ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 AT ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 DR ERR ADDR = CYL: 000. SUR: 0 SECT: 00. STATUS WAS: 000000 LST POS: 000000 DR ERR - RECOVERED CZRLK HRD ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 GARBLED DATA - CAN'T CHECK IT TIME: 00:00:00 RLCS: 000000 DRIVE: 0 DRIVE TYPE = RL00 >> FUNCTION: READ BEFORE ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 AT ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 DR ERR ADDR = CYL: 000. SUR: 0 SECT: 00. XFER SIZE = 00000. WORDS 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000

11 years, 5 months

3
2
0 0

new-old-tech news

by kspt.tor＠gmail.com

On 28 January 2015 at 13:05, Brent Hilpert <hilpert at cs.ubc.ca> wrote: > Not my thing really, but of interest to some here I expect (pardon if I missed it and it's already been mentioned on the list): > "Remodelled ZX Spectrum production set to begin" > http://www.bbc.com/news/uk-england-nottinghamshire-30810148 It'll be interesting to see if that works at all. > Also, not especially computers, but: > "Why can't we let go of our old tech?" > http://www.bbc.com/news/technology-30879638 Aah, old arcade games.. and pinball machines. There's something about that mechanical/physical aspect I think. The point in time when I lost interest in pinball machines was when they changed the number displays >from mechanical to electronical. Suddenly the pinball machines lost their appeal for me. Some important part of the experience was gone. -Tor

11 years, 5 months

1
0
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > If it comes as far as booting RSX as well as XXDP, there can't be > anything seriously wrong with the CPU... Yeah, I see your point, but why all the zeros, then? That's what I could't work out. Anyway, it should be really easy to make sure e.g. ASH, MUL and DIV are working; it's vaguely plausible that one of them is broken. (Unix V6, I think, might even boot even if MUL was broken. I know the bootstrap uses DIV, to calculate the cylinder in the disk driver.) If not, cross that off the list, and try the next thing... Which is? Noel

11 years, 5 months

4
6
0 0

Destructive Imaging of DECTAPE II Media

by nf6x＠nf6x.net

Responding on-list to an off-list message, with permission... On Jan 27, 2015, at 09:30 , Lou Ernst <louis.ernst at verizon.net> wrote: > This is not silly. I think it can work. I had a similar idea about TU60 decassettes. My task was easier there though since the TU60 uses standard Philips compact cassette shells. The TU60 however has no capstan and uses the spindle motors to maintain tape temsion. It was designed by the same guy who designed dectape (TU55/56). Using the spindle motors to maintain tape tension seems like a better scheme than that danged drive belt in my opinion. I recall reading somewhere online about the heroic measures that some engineers (at HP? Or was it 3M?) had to go to to get a DC-100A-like cartridge design working, involving lots of hard work in the areas of lubricants, surface finish, and how to make that drive belt by stretching out a small disc of plastic. My interpretation is that they had to apply heroic efforts to make a crappy design barely work. ;) > Long story short, I was able to play TU60 cassettes in a good audio cassette deck and digitize the audio on a PC. I manipulated the audio file in Audacity. I was able to cut single data blocks and dump the blocks to a long .CSV file. I opened these in Excel and created intelligence in the spreadsheet to digest the audio samples back into the block data, even properly decoding the header and checking the checksum. The hardest work in the spreadsheet was tracking the bit boundaries due to the temporally varying bit-rate (no capstan in the real TU60). Cool! > At last I did not have to use this means of recovering data from TU60 cassettes. My real TU60/TA11 worked well enough to recover the data on the cassettes I was provided to recover. I developed that tape deck/digitizing method in case there were dropouts unrecoverable by the real TU60. At least the real TU60 isn't hobbled by that dreadful cartridge design. > Perhaps you can build a sort of open frame reel-to-reel deck to play and digitize the tu58 tapes. That's what I'm thinking. While I could repeatedly use one or two good cartridge/belt assemblies with the guts of multiple tapes in order to image them in a TU58-XA transport, I don't relish the thought of repeatedly tinkering with the danged belt if I can come up with a better solution. I found a specification that includes the magnetic track dimensions of the DECTAPE II on Al's site: http://bitsavers.trailing-edge.com/pdf/dec/dectape/tu58/TU58_Engineering_Sp… Also, I found a diagram showing track dimensions for various audio cassette formats here: http://richardhess.com/notes/formats/magnetic-media/magnetic-tapes/analog-a… in particular: http://www.richardhess.com/tape/cass_trk_lrg.gif Both the DECTAPE II media and standard audio cassette media are 0.15" (3.81mm) wide. DECTAPE II has two .057" (1.448mm) wide tracks, centered 0.046" (1.168mm) apart. Data density is 800 BPI, with 2400 flux reversals per inch. At standard read speed of 30 ips, that turns into bits in 41.7us increments and flux changes in 13.9us increments. The reels inside the cartridge will spin at around 380 to 800 RPM depending on how much tape is on them, if I still know how to do math. Or twice that at the scanning speed of 60 ips. Just based on track geometry, it seems to me that it may be quite possible to read DECTAPE II media with the inner two tracks of a 4-track recorder head or auto-reversing stereo audio deck head. Or even with both tracks of a 2-track 2-channel head as shown in the diagram I found, though I don't know how common those are. 4-track recorders and auto-reversing stereo decks are pretty common, though. Running the tape at a stable speed near 30 ips instead of 1-7/8 ips would be the hardest part, I think. My gut feeling is that a normal audio cassette capstan and pinch roller assembly may not work well at 16x normal speed, and I haven't seen references to any audio cassette tape applications that run the tape at controlled speeds that fast (rewind and fast-forward speeds may be that fast or faster, but those run the tape at unregulated speeds with the pinch roller disengaged). I don't know if audio tape heads are electrically suitable for this application, but I think they might be since the flux change period is in the same ballpark as the AC bias frequency used in cassette recorders, so the head coils ought to respond ok at those higher frequencies (?). I'm curious about what folks with deeper magnetic media experience than I have might think about this. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

11 years, 5 months

4
11
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > Is noone paying attention to the fact (and my previous comment) about > using 0 for CSR and vector??? Err, no. :-) But seriously, I'm a bit boggled that a diagnostic program would _not_ have as default the 'standard' vector/address. So I'm kind of assuming that the 0's are somehow bug results. > From: Jacob Ritorto > I grabbed a set of pdp11/34a boards ... Can I plug them straight into > this blackplane that's currently housing my misbehaving 11/34? Yes, if the backplane is some flavour of DD11-P (I don't know of any backplane that supports the 11/34 but not the 11/34A, but I only have direct confirmatory documentation on the DD11-P, and it supports both). My vague recollection is that one can use _either_ the M7265/M7266 (but as paired set) _or_ the M8265/M8266 set, but you can't mix and match them. But don't depend on that (I'm too tired to dig into this tonight, I'll do so tomorrow). > Backplane markings are very faded but seem to say dd11-pk. Yeah, that's the 11/34 backplane (actually, the DD11-P part - the -PK is the version with the wire harness to work in a BA11-L or BA11-K; the -PF is for the BA11-F or BA11-P). Noel

11 years, 5 months

4
7
0 0

strange number corruption on pdp11/34

by ak6dn＠mindspring.com

Could be something wrong with MUL, DIV, ASH, ASHC that may be used in the print routine, but would not be used during basic OS operation. XXDP in particular is designed to run on a very basic CPU so it does not normally use any optional instructions. I'd start with running the 11/34 CPU tests. Don -----Original Message----- >From: Johnny Billquist <bqt at update.uu.se> >Sent: Jan 27, 2015 2:42 PM >To: cctalk at classiccmp.org >Subject: Re: strange number corruption on pdp11/34 > >On 2015-01-27 21:24, Noel Chiappa wrote: >> > From: Jacob Ritorto >> >> > I'm getting all zeroes nearly any time there's supposed to be a large >> > number output to my terminal. >> >> It sounds like the CPU may be too broken to run diagnostics. Why don't you >> try writing some small programs to test various bits and pieces of the CPU >> (e.g. add instructions, etc), and toggle them in, and try and find what's >> busted that way? (Although for 'add', if the thing's that broken, I'm amazed >> it even boots.) >> >> Here's an example: >> >> http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tests/print.s >> >> It's probably too long to toggle in, but you could steal pieces from it >> and try them. >> >> I'd probably try out the shift and multiply instruction to start with; trying >> to figure out what's probably not used during booting, but could be used >> during number printing, those are two good bets. >> >> Anyway, there's no point to running diagnostics until you get that first >> problem fixed. > >If it comes as far as booting RSX as well as XXDP, there can't be >anything seriously wrong with the CPU... > > Johnny > >-- >Johnny Billquist || "I'm on a bus > || on a psychedelic trip >email: bqt at softjar.se || Reading murder books >pdp is alive! || tryin' to stay hip" - B. Idol

11 years, 5 months

2
1
0 0

Hp 9836a on ebay

by hp-fix＠xs4all.nl

201273924178 Hp 9836A ot Hp 9000/236 Not mine, don't know the seller. But it looks good and starts cheap. -Rik

11 years, 5 months

2
1
0 0

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I'm getting all zeroes nearly any time there's supposed to be a large > number output to my terminal. It sounds like the CPU may be too broken to run diagnostics. Why don't you try writing some small programs to test various bits and pieces of the CPU (e.g. add instructions, etc), and toggle them in, and try and find what's busted that way? (Although for 'add', if the thing's that broken, I'm amazed it even boots.) Here's an example: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tests/print.s It's probably too long to toggle in, but you could steal pieces from it and try them. I'd probably try out the shift and multiply instruction to start with; trying to figure out what's probably not used during booting, but could be used during number printing, those are two good bets. Anyway, there's no point to running diagnostics until you get that first problem fixed. Noel

11 years, 5 months

2
1
0 0

ROM Dump Intellec/8 for 8008

by billdeg＠buzz1.com

> From: Al Kossow > > http://vintagecomputer.net/browse_thread.cfm?id=595 > > > > > the link is bad > > http://vintagecomputer.net/intel/imm_6-26/MON80_3800-%3Cbr%3E3FFF.zip > it should be > vintagecomputer.net/intel/imm_6-26/MON80_3800-3FFF.zip Thanks, fixed the page. Bill

11 years, 5 months

1
0
0 0

RA81 available for pickup in Germany/Weimar

by holm＠freibergnet.de

Hi huys, a friend of mine informed me that he has an DEC RA81 drive available for picup in Germany Weimar. Sorry picup onbly, the weight is 67 Kilograms. The price is to be negotiated with my friend. Mail me if you are interested, I'll forward mails to him. Regard,s 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

11 years, 5 months

1
0
0 0

Equipment Available (WAS VAX 8600 + stuff)

by jwest＠classiccmp.org

Much to my chagrin, after passing the original deal (that ostensibly included a VAX 8600) to a listmember - the owner emailed me to say that he had incorrectly stated the exact equipment available in his original email to me. There is no VAX 8600. Not wanting to miss-step again, I talked to him at some length to make SURE that the following is a correct statement of the equipment that he is trying to get rid of. I don't think he stated the equipment incorrectly on purpose, I believe he just wasn't sure what he had. This stuff is in Houston, TX. If someone wants to take over spearheading this deal (I do not wish to) please email me off-list. Here it is.. List of Equipment: MicroVAX 3400 (details below) 6250 tape drive DEC PC AXP 150 Alpha Station 200 8mm SCSI tape drive ??? 8mm SCSI tape drive EXB-8500 (10 GB) 4mm SCSI tape drive Sony SDT-5000 (8 GB) Tape drives are in external SCSI enclosures. ============================= MicroVAX 3400 DETAILS =========================================== MS650-AA Category: VAX Memory Description: 8MB MEMORY BOARD FOR MV3300-MV3900/VAX 4200 BA213 Enclosure Dimensions:27" H x 21" W x 17.8" D. Has castors Bus details: Q-bus - 12 slots, All slots are Q/CD Drive bays: Four full height 5.25 bays. One with front access. Power supply: Dual 230W power supply w/ Line conditioning Used in: MicroVAX 3400, VAXserver 3400, MicroVAX 3800 VAXserver 3800, factoryVAX-II Last updated: 2000-02-01 Notes:Industrial box. Commonly referred to as a "skunk box", expansion version is B213F and has slave power control input. KA640-BA MicroVax 3400, used with single user software M7624-DA VAX3400 CPU BD M7624-DL CXY08-M The CXY08 (M3119) is a Q-bus 8-port asynchronous serial adapter with full modem control. M3119-YA Qbus DEC VAX M3119-YA Multiplexer Card, (Tape drive)

11 years, 5 months

1
0
0 0

ROM Dump Intellec/8 for 8008

by billdeg＠buzz1.com

I just dumped and posted on my web site an 8008 (inverted) monitor ROM for the Intellec/8. It starts at 3800H and came from 8 1702A's on an Intel IMM 6-26 Prom card. I don't think it's for the 8080 even though this PROM card was used on both 8080 and 8008 Intellec's. I will post updates to this thread, after I invert the code and check the actual instructions. Anyone interested to check or use it before I do, be my guest - http://vintagecomputer.net/browse_thread.cfm?id=595 Bill

11 years, 5 months

2
1
0 0

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