Re: Anyone know who does 'decmuseum.org', PDP-5 pictures
Thanks, everyone! Got it. Noel
Re: Which Dec Emulation is the MOST useful and Versatile?
> From: Jon Elson > I'm not sure the original DEC PDP-10 (KA-10) used microcode No, it didn't; in part because it pre-dated fast, cheap ROMs (the development of which was a considerable task in the /360 project - the wonderful "IBM's 360 and Early 370 Systems" covers this is some detail). The KA10 is built out of FLIP CHIPs which carried individual transistors. Another fun KA10 fact: it used 'hardware subroutines' - i.e. a clock pulse would get to a certain point, and get conditionally diverted through some other circuitry, later to come back and continue where it left off. Whee! Noel
Re: H7861 PSU issues
> From: Aaron Jackson > Picked up a few 555s and sockets and now it works! Congratulations! It's odd that a 555 failed, but sometimes there's no rhyme or reason to what fails. E.g. I was fixing some broken M7859's (KY11-LB Programmer's Console), and on one of them a 7493 (4-bit counter) had died. That's not one of the 'problem' 74xx chips, like ISTR the 7474 being? Noel
Re: H7861 PSU issues
> From: Rob Jarratt > when I replaced it and powered on there was a big bang What went 'bang'? (I assume if there was a loud noise, it mus have left visible damage somewhere.) Noel
Re: PDP-8 chassis on eBay
So if someone's building an earlier -8 from bits and pieces, here: https://www.ebay.com/itm/192350321318 is something they might find useful - an empty chassis. (I'm not associated with the seller, although I've bought stuff from them before. They have some other PDP-8 stuff listed, too.) Noel
PDP-8 chassis on eBay
So if someone's building an earlier -8 from bits and pieces, here: https://www.ebay.com/itm/192350321318 is something they might find useful - an empty chassis. (I'm not associated with the seller, although I've bought stuff from them before. They have some other PDP-8 stuff listed, too.) Noel
Re: "Left a home full of computers" Craigslist ad
> From: Peter Cetinski >> I was left a home with all of its contents tons of electronics and >> computers, call if you want me to send pics > FWIW, I received some pics of these items. So, what else was there (that you don't mind telling us about because you're not grabbing them... :-)? Noel
Re: PDP-8 chassis on eBay
> From: Dave > I managed to snag the chassis and what I hope is the matching cover. No, that cover is for a paper-tape reader. Noel
Re: Computing Pioneer Dies
> From: Dave Wade > ENIAC had been configured in stored program mode earlier in the year > and had run a program stored in the function switches, e.g. ROM > ... > Despite the fact that when running stored programs ENIAC's parallel > processing features were not available, it was exclusively in this mode > from 1948 onwards. This may have been mentioned here already, but if not, there's a good new book out which covers this phase of ENIAC's existence in considerable detail: Thomas Haigh, Mark Priestley, and Crispin Rope, "ENIAC In Action: Making and Remaking the Modern Computer", MIT Press, Cambridge, 2016 It's a very interesting and well-done book; I highly recommend it. > From: Brent Hilpert > The best that can be said for your position is that you (and the > ENIAC/Mauchlyite crowd) have a particular opinion and definition > regarding 'stored-program computer'. I'm harly a member of the "ENIAC/Mauchlyite crowd" (in fact, I used to not have a good impression of them at all), but I thought Haigh et al made a pretty good case. Noel
Re: RL02 Spinup fails
> From: Aaron Jackson > The RL02 technical manual says to figure out why a drive error > occurred, I can execute a get status command (?) and then perform an > MPR read (?). So while I don't know how to do that, RLV 12 User Guide, section 5.2. Noel
Details about IBM's early 'scientific' computers
So, I was trying to find info about the early IBM 709/7090/7094 computers, but when I went to what is supposedly the authoritative work on these computers (among others): Charles J. Bashe, Lyle R. Johnson, John H. Palmer, Emerson W. Pugh, "IBM's Early Computers", MIT Press, Cambridge, 1986 I discovered there was very little technical detail about these machines there. Is there any other printed thing (yes, I know a few Web pages have some content) that anyone knows of that covers them in more detail? (I have a 709/7090/7094 programming thing coming, but that won't cover the internal engineering.) Yes, I know, I could look at the engineering manuals, but I was hoping for something in between them and Bashe et al. Noel
Re: Computing Pioneer Dies
> From: Brent Hilpert
> What about that little issue of writeable program storage?
Just to clarify my understanding of your position, is a system with a CPU
chip (say one of the 68K models) with only ROM not a 'stored program machine'?
Noel
PS: You really should look at the book ("ENIAC In Action"), and not rely on
the articles; it's later, more coherent (not being split across a handful of
papers), and much more detailed (e.g. it includes the instruction set for the
'programmed' version of the ENIAC).
Re: Computing Pioneer Dies
> From: Evan Koblentz > That's the dumbest thing I read today. And that helped... how? Noel
Re: Details about IBM's early 'scientific' computers
Please, everyone, I do actually know of BitSavers; you don't need to point me at it. When I said: >> I could look at the engineering manuals, but I was hoping for something >> in between them and Bashe et al. I assumed everyone would understand that by "engineering manuals", I was meaning the kind of things one finds in BitSavers. Noel
Re: Details about IBM's early 'scientific' computers
> From: Ben Franchuk > Multics never really made it out of the lab. This 'bogo-meme' (to use a word I coined) is, well, totally flat wrong. Multics was a reasonably successful product for Honeywell from the end of 1972 (when the H6180 was introduced) to around 1987 (when they stopped selling the DPS8/M, which had been introduced at the end of 1982). At its peak, in 1985, there were almost 100 Multics sites. MIT ceased to be involved in Multics development in 1977. Multics died not because it was a failure (indeed, many systems kept running for years, because the users liked it so much - the last one only shut down in 2000), but because of Honeywell's incompetence at the computer business. (That incompetence eventually resulted in a decision - probably correct from the _business_ point of view, given said incompetence - to get out of the computer business.) More here: http://multicians.org/myths.html and http://multicians.org/hill-mgt.html (which discusses the high-level corporate politics behind the decision to can Multics). Noel
Re: Ideas for a simple, but somewhat extendable computer bus
> From: Allison > simple 16 data, 24 address likely 6 lines for basic control plus others > your up to 50+ lines I would seriously consider shared data/address lines, like on the QBUS. It doesn't add _that_ much complexity to share the lines (I did a slave device using only 74xxx parts, and it was dead simple - probably a goal of the designers), and it will really drop the pin count. The speed impact is not too bad - on reads, where the address and data naturally happen at different times, it can be none. Noel
Re: Slightly OT: Computer internals book recommendations
> From: Sophie Haskins > earlier editions of "Computer Systems: A Programmers Perspective" had a > bunch of discussions of buses etc .. but the edition I have explicitly > calls out that they felt like it wasn't important to have chapters on > anymore :( Well, that might not be the wrong call, _iff_ keeping them in would have increase the cost of the text-book for (poor) student... And for the rest of us, there's ABE for the earlier editions! :-) Which edition do you have, may I ask? Thanks! Noel
Re: Ideas for a simple, but somewhat extendable computer bus
> From: Allison >> I would seriously consider shared data/address lines, like on the QBUS. > QBUS is wrapped around a subset of PDP11 and the unique processors made > to fit it. I did say "like ... the QBUS", not "the QBUS"! I was just trying to make the point that the original sketch assumed separate address and data lines, and that's an assumption worth looking at. > The bottom line is for every bus you have to get on and off with > devices to buffer ... The more you use the less card there is for other > things Yes, but that cuts both ways: multiplexed address and data also saves you a lot of bus transceivers. Noel
Re: Ideas for a simple, but somewhat extendable computer bus
> From: Charles Anthony > a hybrid PDP-11 (16 bits) / PDP-15 (18 bits) on a shared bus (UNIBUS?) That's a UNICHANNEL-15: it allowed devices on the -11 to do DMA directly into the PDP-15's memory through the MX15-B Memory Multiplexer. Odd factoid: this UNIBUS could run in 18-bit mode (!!), where the UNIBUS' two parity lines were recycled into 2 extra data lines. Some DMA interfaces (e.g. the RK11) could support this; in this particular case, it allowed the PDP-15 to use RK05 drives. Noel
Re: LA30 parts and question
> From: Fritz Mueller > Overall, I have been pretty amazed by the sheer number of machined > parts, castings, high quality bearings, etc. within this beast. Lots of > stainless steel throughout. Sure wouldn't find anything built this way > these days! What a tank. That's DEC for you - quality engineering (mostly :-). Reminds me of this Porsche/Lotus story: http://www.chiappa.net/~jnc/nontech/chapman.html Alas, that kind of engineering turned into a liability when DEC tried to compete in the 'new world' of personal computers... :-( Noel
DEC indicator panel 'light shield'
So Dave Bridgham and I are continuing to make (slow) progress with the QSIC and indicator panel project; the latest step was to find some LEDs which look much more like the original lights: http://pdp10.froghouse.org/qsic/new-led.jpg So now I'm trying to make up a prototype 'light shield' (the flat board with all the holes drilled in it); the parts list in the drawings (RF11 engineering drawings, pg. 187) just calls it a 'Benelex', which is the name for the material it was made of (sort of like MDF), but 'light shield' is what I've taken to calling it. Anyway, the drawings there do not, alas, give any dimensions. Can one of the people who has an original please measure it for me? Just WxLxD is all I need; I have a good photo, and can get all the other measurements I need from that, once I know the 'scale'. (Well, not the depth, which I can't see in the image, which is why I need that to.) Thanks! Noel
Re: DR-DOS
> From: Liam Proven > TCP/IP basically postdates the MS-DOS era, in PC terms, and it's Bloaty > McBloatface. This must be a uSloth TCP/IP you are speaking of. There's the one from FTP software which was based on the one done at MIT which was freeware. That one was definitely DOS-era - it ran on DOS 1 and DOS 2. I think I have the MIT version somewhere if you have a use for it. > But only someone who thinks that Emacs or Vi are usable editors could > think this was an appealing virtualisation solution. Epsilon! Even on Windows 95, it was a not-so-humungous 261KB. If Lugaru can't cough up a DOS version, I'm pretty sure I still have my DOS Epsilon distro disks somewhere. Of course, I would have to get a 5" floppy drive working... :-) Noel
Re: Slightly OT: Computer internals book recommendations
> From: Eric Christopherson > I have an inside scoop that a certain library is about to get rid of > their 2003 printing (which is apparently 1st edition) ABE seems to have copies for around US$10: https://www.abebooks.com/servlet/SearchResults?bi=0&bx=on&cm_sp=SearchF-_-Advtab1-_-Results&ds=30&recentlyadded=all&sortby=17&sts=t&tn=Computer+Systems%3A+A+Programmers+Perspective Noel
Microassembler, etc, available
So, as part of the work on getting our QSIC card to support SD cards for
storage, Dave and I have produced some tools that people might find useful.
Dave's original concept was to do SD support with a state machine. However,
the SD protocol turned out to be a little too complex for that, so we decided
to create a bespoke micro-engine (hereinafter 'uengine' - I use 'u' in place
of the lower-case 'mu' all the time) to handle it.
This turned out to be a good call; Dave cranked out a uengine in Verilog
(which was incredibly quick to produce), and I whipped up (literally - the
first version was done overnight) a uassembler. The latter has since been
much improved; the current version reads the entire definition of the uengine
from a configuration file, and thus should be usable on any umachine.
So, if you need a uassembler for some project, here's one. (And if you need
something it can't do, let me know, and I can add stuff; e.g. it doesn't
currently support the '+' operator in literals, only '|', but it would be
fairly simple to add '+' if anyone had a use for it.)
The source is here:
http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/tools/uas.c
(and no, I don't have the energy to learn how to use sourceforge or github to
distribute it, so don't bug me about it). I wrote it under Cygwin on Windows,
but Dave compiled and runs it on Linux as-is, so it's pretty portable.
The current output format is hex that Dave massages into 'ROM' contents on
the FPGA in some fashion I don't know the details of, but if anyone needs
something different, again, I'd be happy to add whatever's needed.
The source syntax supported is documented in comments at the start of the
uassembler source; it's pretty simple, here's a brief synopsis (see the file
for more detail). ucode is a collection of lines, one per micro-instruction.
The syntax for individual lines is:
{:} {, }... {}
can be either: (symbolic) or = (where
fvalue can be symbolic or numeric); specific symbolic values are assigned by
the configuration file (where they are defined) to specific fields.
is {|}... where is symbolic (a label, or a
value) or numeric. Forward references to labels are supported. Numeric items
(everywhere) are either octal, decimal or hex. Whitespace (either space(s) or
tab(s)) can be used in most places. Comments start with a ';' or '/', and the
rest of the line is ignored.
A sample umachine configuration file (for the QSIC uengine) is here:
http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/tools/ueng
and the (simple) format of the config file is documented in the comments at
the start.
A sample source file for uas for that uengine is here:
http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/sd.asm
if you want to see what source looks like.
Dave has a github site where all his stuff is available; the latest version
of the ucode is here:
https://github.com/dabridgham/QSIC/blob/master/verilog/sd.asm
and the whole thing is here:
https://github.com/dabridgham/QSIC
including the Verilog for the uengine. Dave reports that it should be easy to
adapt his uengine design to other uses, it should run in pretty much any
FPGA. So if you want to build a PDP-15 (or a Multics! :-) in an FPGA, there
you go. Dave indicates he'd be happy to help anyone who needs to tweak the
uengine design for their particular application.
Hopefully someone will find this useful!
Noel
Re: Microassembler, etc, available
On 11/28/17 13:27, emanuel stiebler via cctalk wrote: > Dave has a KV10 already in verilog, so why not port it to the uengine? Well, the uengine would have to be considerably modified before it could be used for a PDP-10 (e.g. wider data-paths); this version is very specialized to the SD application (e.g. hardware CRC support, etc). Noel
FTGH: Old ham radio headset
FTGH: http://ana-3.lcs.mit.edu/~jnc/jpg/tmp/HeadSet.jpg Noel
Re: RX02 Difficulties
> From: Aaron Jackson > Most of the tests now look something like this: > ... > SECTOR ADDRESS ERROR > EXPECTED SECTOR=18. > TARGET SECTOR=17. I wonder if there's a problem with the floppy you are using? Remember, the RX0x drives can't hard reformat the floppies (as in, write the sector headers), so if the floopy has a problem, you can't fix it with the RX02. Noel
Revive 11/34
> From: John Welch > Any suggestions as to what to try first? I would _definitely_ start by pulling _all_ the cards you can, to get down to the simplest possible configuration. Once that works, start adding things back in, one at a time. If that configuration doesn't work, first try the obvious things (clean and re-seat, check voltages, etc). If that doesn't get it running, it's time for a oscilloscope or logic analyzer. (We can help you through that.) So I'd start with the CPU (M8266/M8265), front-terminator/bootstrap ROM (M9312), the front console card (M7859), and rear-terminator (M9302) (which you need for grant turnaround, see next paragraph). That's it. IIRC, the /34 will complain if the bus grant chain is not complete (I really need to look at the prints/ucode to understand why this is so - other -11's will run basic functionality fine with an interrupted grant chain), so plug in grant jumpers in every unused slot. Also, check the backplane, to see which slots have had their NPG jumpers pulled, and either i) use a G7273 jumper (the dual boards which contain an NPG jumper as well as the BR jumpers) in those slots, or replace the jumpers. I _think_ the machine will be OK without any memory, but I don't have a running 11/34 to test that on. (Only my /04 is running at the moment.) I can plug my /34 cards in and try it, if that will help. But maybe someone else knows. So maybe you'd have to add a memory card, but that would _definitely_ be the biggest configuration I'd try until the basic machine is working. You can examine the MMU registers in the CPU to check that the bus/console etc are working - first read, then write. And IIRC the CPU general registers are accessible from the bus too - I know they are in the -11/04 (which uses the same front console). Noel
Re; Revive 11/34
> From: Henk Gooijen A few comments to you about Henk's points: > Standing in front of the 11/34 processor box (looking at the console), > slot number 1 is at the right side. That's for the 10-1/2" box; the 5-1/4" is different. Which is this? > Each slot has 6 positions. Position A is at the rear side, followed by > B thru F. Position F is thus at the front side. I prefer to say that connector A is at the right, when facing the component side of a hex-wide card which has the handles at the top, and the contact fingers at the bottom. (Make doubly sure you never plug a card in backwards! It will almost certainly kill the card. In theory they are keyed so you can't, but idiots like me have been known to do it! :-) > The 4 copper "jumper" traces should be facing the next higher-numbered > slot. I.e. on the so-called 'solder' side of the card, not the 'component' side. (All the cards face the same way.) > When you power up the system, the display should show 6 octal numbers. > If only one digit shows a number (7 or 5 or whatever), there is an > issue with the console itself, or the M7859. The M7859's are, for some reason, particularly prone to failures. About half the ones I've seen weren't working at first. There's no one chip that seems to be the usual suspect, I've seen several different failure modes. > From: Jerry Weiss And the same for Jerry... > It won't seat evenly if reversed. At least that is what my scraped > knuckles remember. Nope, they go in quite fine the wrong way around; I just checked. Make sure they are in the right connector (D) and the right way around; I haven't checked to see if damage is likely to result on an error - does anyone know offhand? > Check the cable orientation. Note that one DEC manual (the KY11-LB Maintenance Manual) shows the wrong orientation! See here: http://gunkies.org/wiki/KY11-LB_Programmer%27s_Console at "Cable Connection and Documentation Error" for more. > I believe the cabling for the M7859 is a little different between the two The /34 has two narrow 'maintainence' cables, the /04 only one. But you can ignore these if you're not using the maintenance mode on the front console, and only plug in the wide cable. Noel
Re: Revive 11/34
> From: John Welch > Can you give me a refresher on how to tell which slots are cut? I > remember having to turn the chassis over and looking for a particular > wire Yeah; you can use the G7273 as a 'crib', since it has the NPG jumper on it. That jumper goes from CA1 to CB1: component side, third connector (counting from the A connector), first and second pins (again counting from the A connector end). A lot of the slots will still have their jumpers in, which is how you can confirm you're looking at the right pins; look for slots without them. > I also have an 11/04 that I went and drug out. Yeah, the M7263 is the KD11-D CPU, the M7847's are MS11-E's (one of them will be useful as a first-stage debug for the 11/34, once you've verified, in the -11/04, that they work - the M7891 MS11-L is rare and valuable, I'd rather not use that until everything up to that point in the -11/34 is known working - you could try pulling the two M7847's from the -11/04 and try plugging in the M7891, to verify that it's sort of OK). > I am thinking I could put a M9203/M7856 into slot 9, and find a M9312 > for slot 3 and maybe this would fire up. Any suggestions? As always, first pull all the boards and check the power supply (if it's been a long time since it was last powered on, re-form the electrolytics in the power supply first, before powering it on), then put in the _minimal_ set of boards and get those working. > I added an M9302 in Slot9-AB and then moved the M7856 from the 11/34 to > Slot9-CDEF of the 11/04. I put a random M9312 in Slot3-AB I turned on > the 11/04. > I have six '0' digits. I push ctrl+hlt and the display shows 173066. > Looks like things are moving. Yup, that's working. Now you have a working machine, you can board-swap in from the -11/34 to check other boards out. Major, major help!! The first thing I'd try would be the M7859, KY11-LB, from the -11/34 over here. If it doesn't work in the -11/04 (with only that board changed), i) you've isolated the problem, and ii) you can probably use the one from the -11/04 to get the -11/34 working (unless there's something _else_ broken in the -11/34 as well). NOTE: Don't plug the good one from the -11/04 into the -11/34 - or do anything else with the -11/34 - until you've checked the voltages in the -11/34!!! If the M7859, KY11-LB from the -11/34 _does_ work in the -11/04, time to keep looking. The console itself is so dumb it's unlikely to be the problem, but you never know; might we worth swapping. I'm having a hard time seeing what problems in the /34 CPU, etc could cause the symptoms you're seeing - are they still there with only the absolute minimal board set? Noel
Re: RX02 Difficulties
> Aaron Jackson > if I try to dump using vtserver using a floppy which passed the > diagnostics, it fails. My copy of of the V7 standalone stuff (which I got from the VTServer directory) didn't include an RX driver. Where'd you manage to find one? (I need one for my own use, plus I want to look at the source, to help with this.) Noel
Re: Revive 11/34
> From: Henk Gooijen > the M7859 is sort of a UNIBUS device. The (front panel) console only > communicates with the M7859. Not quite; it does _mostly_ 'do its thing' over the UNIBUS, but there are also two special lines carried across the DD11-P backplane to the CPU, 'Halt Request' and 'Halt Grant' (which is why it has to be in the same backplane as the CPU); more here: http://gunkies.org/wiki/KY11-LB_Programmer%27s_Console > I cannot remember whether a demux for the displays is on the console > PCB, or on the M7859. I'm not sure exactly what you mean by 'demux', but... the interface between the board and console is i) 3 bits of digit, and ii) 6 individual select lines. Code in the micro on the M7859 sends one digit at a time down the 3 'digit' lines, along with the appropriate 'select' line. > If you get 00 on the dsipaly and when halted it shows 173066 I > presume it is looping. Well, I haven't looked at the M9312 ROM code, but if it's anything like the M9301 code (which I have dumped and disassembled), looping in the ROM at 173066 is not necessarily bad. There is a listing of some of the ROM code on BitSavers: http://bitsavers.trailing-edge.com/pdf/dec/unibus/K-SP-M9312-0-5_Aug78.pdf but it doesn't seem to cover the stuff at 173000 (which is where the CPU starts running on power-on) - or maybe I just didn't study the listings carefully enough. > If it loops, it will repeatedly read from a device address which is > most likely the CSR of the boot device. Depends on the switch settings on the M9312. If it's set to boot, if the device is there, yes; otherwise it would get a NXM fault. If it's set to go into the console mode, it's probably trying to read characters (commands) from the console. Noel
Re: RX02 Difficulties
> From: Aaron Jackson >> My copy of of the V7 standalone stuff (which I got from the VTServer >> directory) didn't include an RX driver. Where'd you manage to find one? > I am using the version from here: https://github.com/sethm/vtserver/ After offline discussion with Aaron, we clarified that that site only has the binary for the standalone tools. The copy on the TUHS archive: http://www.tuhs.org/Archive/Tools/Tapes/Vtserver/v7_standalone.tar.gz although it has the source, doesn't include the RX driver. Does anyone know the whereabouts for the source for the (later) version of the standalone stuff, which includes the RX driver? Thanks! Noel
Re: Dec-10 Day announcement from Living Computers: Museum + Labs
> From: Ethan Dicks > I look forward to taking a stab at this. I suspect there are a number of people who'd be interested in MASSBUS storage devices (e.g. me - suddenly all those RH11's I've got are no longer boat- anchors :-). We should try and organize an group build, to share the load. Anyone else interested? Oh, one detail I didn't look at: what's the physical interface this uses? Hopefully three of the Berg/DuPont connectors (i.e. what's on the RHxx boards, with flat cables going to the adapter to the standard MASSBUS connector, a device rejoicing in the name 'Receptacle Housing Assembly'); the original MASSBUS cables (along with the 'Receptacle Housing Assembly' are now rare as hen's teeth). And there's also the MASSBUS termination... Noel
Re: 11/04 Project
> From: John Welch > Any thoughts? Concur 100% with Henk's comments. There is a manual online for the M9312: http://bitsavers.org/pdf/dec/unibus/M9312_TechRef.pdf which will tell you what the other start options are (Appendix C), but see page 3-1, too. Note especially the bit about how the primary dianostics are run before it starts the console emulator; I forget what it does if the primary fails, possibly it halts? Noel
Re: 11/04 Project
> From: John Welch > Anyway, 'a' comes over as 000141 and 'A' comes over as 000101. Good, the console is working. > CLR > LAD > DEP OK, that loads a '0' (halt) in 0. > CNTRL+INIT > CNTRL+START -> reads 02 OK, so it reads the HALT at 0 and stops. > CNTRL+BOOT -> Run light is on, SR Disp light is on > CNTRL+HLT reads 173150 Sounds like it may be looping in the high bank of ROM? That's not necessarily wrong. I finally figured out what the ROMs in the M9312 do; the ROMs at 765000 are the first-level diagnostic, and the console. The bootstrap code for the various devices is at 773000. > 773024 LAD, 773000 DEP, BUS ERR light comes on. That makes sense; you can't write to the ROM. > Any suggestions? i) Check the ROM contents; there are two kinds of M9312 console ROMs, one for most CPUs, and one for the 11/60 and 11/70, see the tech manual for the M9312. So read out the first couple of words: CLR 765000 LAD EXAM EXAM etc and let's see what they read. ii) Try starting the console code directly: CLR 765020 LAD CNTRL+START > I have other M9312s I could try. Can't hurt. Noel
Re: 11/04 Project
> From: John Welch > CLR > 765000 > LAD > EXAM > 'Bus Err' light comes on. Oooh, that's very interesting, and illuminative. The ROM isn't working (so there's no way for the software console to work - its code is in that ROM). So look at Section 1.5 of the Technical Manual http://bitsavers.org/pdf/dec/unibus/M9312_TechRef.pdf and make sure all the jumpers on the M9312 are as required. In particular, jumper W-8 should be _out_. If it's not, that would explain why the ROM at 765000 isn't resonding. If it's in, that M9312 board probably has a problem. Also, while we're at it, it's probably worth making sure the CPU will run. Do this: CLR LAD 777 (This is a 'branch .' instruction) DEP EXAM (Should display '777') CLR (I think you can dispense with these LAD two, but just to be safe...) CTRL-START 'Run' light should come on CTRL-HALT 'Run' light should go out, should display '0' (or maybe '2', I forget) > Do you know which color wire (red, clear, black) goes to which festoon > connector (TP1, TP2, TP3, TP4)? I would leave them all disconnected for the moment; you don't need them. One is the 'boot' switch on the console, and its ground. The other is the 'boot on power on enable' (a duplicate of S1-2), and its ground. Since we're trying to manually start the ROM console from the front console, they aren't needed for that. I don't recall offhand which one connects to which - I will have to check. > Don't want to blow anything up. Not sure it will harm anything if you connect things wrongly, but that's not tested. Noel
Re: 11/04 Project
> From: William Degnan > 1) the console rom does not go in any of the 4 bootstrap slots, these > should be empty for now. There is a special console rom slot. Just to clarify, by "slot", you don't mean 'backplane slot', you mean 'socket (on the card)', right? Also, note that the console/diagnostic ROM is a different size (bit-wise; I'm not sure about the physical package) from the bootstrap ROMs. > 6) possibly the only switch to worry about now is the power on auto > jump to console switch. I'd leave that, too, until we get the software console to run when started manually - at the moment, the ROM's not working, so that switch is irrelevant. Noel
Re: eBay: MEMOREX 3693-2 & 3690-2 Disc Drive Mainframe IBM 3370-2 VINTAGE
> From: Steven Malikoff > they mention it will be scrapped if no takers. Don't be misled by the .au URL; the units are in Sacramento, CA. Anyone in the Bay area up for saving these? Noel
Re: RX02 Difficulties
> From: Aaron Jackson > It was the disks after all. Well, I'm glad you got it working. Where'd you get a good floppy? Noel
Re: eBay: MEMOREX 3693-2 & 3690-2 Disc Drive Mainframe IBM 3370-2 VINTAGE
> From: Guy Sotomayor Jr > I *really* want them and I'm within an hour (usually) of where they > are. The problem is that right now I'm on a business trip until the end > of the month and he needs this gone prior to 12/31. Why don't you reach out to the person and tell them you _really_ want them, maybe they'll be able to let it go until you get back? Or is there someone in the Sacramanto area who can pick them up and hold them until Guy can get them? I would offer to, but I'm on the wrong coast :-( Noel
Re: RX02 Difficulties
> My copy of of the V7 standalone stuff (which I got from the VTServer > directory) didn't include an RX driver. Where'd you manage to find one? So, thanks to a tip (thanks, Jerry! :-), the source has been found: https://github.com/chapmajs/vtserver/tree/master/pdpvtstand http://www.shiresoft.com/pdp-11/software/ For some reason, the TUHS Archive doesn't contain the later versions of VTServer: http://www.tuhs.org/Archive/Tools/Tapes/Vtserver/ and in those (unlike the earlier versions), the standalone source is in the same archive file as VTServer itself. Noel
Re: RL02 to PC image
> From: Jonathan (Systems Glitch) > the vtserver `rx` driver has a bug in it anyway where it continues > reading past the end of the media I'll be working with the RX driver for the standalone stuff soon on a project of my own, I'll look into this then. BTW, 'VTserver' refers to three pieces of software: - The actual server, which runs under Unix on the 'server' machine - A small bootstrap which downloads the main standalone program from the server - A driver for the standalone software which adds a device which can talk to the server over a serial line, as one of the devices for the standalone The standalone software is V7 code that existed before VTServer did, more on it here: http://gunkies.org/wiki/Installing_UNIX_Seventh_Edition and the RX driver is actually for that. Noel
DEC indicator panel mounting details
So, Dave and I are getting to the point where we're about to start mounting up our indicator panels, but we're not sure what some of the mechanical details (below) are. Could someone who has one please take a look and let us know (or, even better, send us photos)? It appears that the bezel and inlay mount to the rack with the same kind of 'ball on post' (BoP) mounting things used for blank panels. What we can't quite make out is how the Belenex light shield, and the circuit board with the bulbs on it, mount to the rack. I suspect it's totally independent from the mounting of the BoP mounting devices for the bezel/inlay, but The one mechanical drawing we have (RF11 engineering drawings, pg. 186) does have cross-sections, which confirm the board is mounted to the Benelex on stand-offs, and that the Benelex is somehow thrust up into the bezel, but exactly how the Benelex is mounted is not clear to me. The mention of a "Mtg Bkt Benelex" suggests that's mounted to the rack with brackets, but... Help!? Thanks (hopefully :-)! Noel
Re: DEC indicator panel mounting details
> From: Josh Dersch > See the pictures at the below link: ... > Hope this is the right assembly for you Yes, those are _exactly_ what we're looking for. Thanks very much for taking the time to take those! Noel
Re: DEC indicator panel mounting details
> From: Josh Dersch > the plastic "ball on post" brackets PS: Apparently the 'official' DEC name for the 'ball on post' plastic brackets is "latch molding". Not very descriptive/apt, alas. Noel
Re: DEC indicator panel mounting details
> From: Adrian Stoness > theres a 3d model for printing those brakets over on this site > http://so-much-stuff.com/pdp8/cad/3d.php http://www.classiccmp.org/pipermail/cctalk/2017-December/036544.html Noel
Re: Miss categorized DEC box on ebay
> From: Bill Gunshannon > At best, it's a third part QBUS box. I assume that was 'third party'? No, that's a real DEC front panel. They could have put that on an off-brand chassis, but I would _guess_ not. (The outer housing I can see looks like the slide-in ones DEC used to hold the BA11-N/BA11-S, but I don't recall what the housing for the BA11-M's looked like.) For some reason the BA11-M's seem to have been going for more than the BA11-N's. Dunno why, maybe the original LSI-11's have some sort of appeal? Noel
Font for DEC indicator panels
So, anyone happen to know the font used in DEC's indicator panels: http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html or, at least, a very close match? For mockups we're doing, Dave B is using 'DejaVu Sans', but that's not a really close match: the vertical bars are wider than in the DEC font, where the verticals and horizontals are the same width. It would be nice to have a closer match when we go to turn out replicas. (We're just about settled on the format for the QSIC RKV11-F/RPV11-D panels.) Noel
Re: Font for DEC indicator panels
> We're just about settled on the format for the QSIC RKV11-F/RPV11-D > panels. PS: Here's the latest rev of our thinking: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/inlay-rk11-f3.pdf if anyone has any comments. (Since the format is entirely set by the FPGA, it's 'easy' to tweak it, if there's a desirable improvement.) It's not the same as the old DEC RK11-B/RK11-C or RP11-C inlays, in part because we want to be able to show the address, and on a QBUS machine, that's 22 bits. Also, many of the fields don't apply to the QSIC (e.g. internal drive signals, 36-bit data buffer on the RP11, etc); we figured it would be better to recycle those lights for something useful (e.g. the address and word count). Noel
Re: Font for DEC indicator panels
> From: Jason T > According to my notes, for the VCFMW8 shirts ... I used DIN Next Pro > Rounded Medium for the panel text, although the font I had in my work > directory is "DIN 1451 Fette Breitschrift 1936". That is probably the > font next to the knob on the right and the bit numbers above the > switches. Yeah, that latter is the one we're looking for (mostly). (I tried downloading a couple of copies, but for some reason I don't understand the font viewer on my Windoze box wouldn't show them; from what I could see online, it looked close.) The DEC font uses a zero with a slash, but it's otherwise close. > There is no reason to think these are the original DEC panel fonts, just > what I found to be "close enough" at the time. Understood. Thanks! Noel
Re: Font for DEC indicator panels
> From: Toby Thain > To get closer I'd need better images of the panels. Hi, I borrowed a DEC inlay from someone (a KA10 CPU bay) and scanned a chunk of it (as much as I could fit into my A4 scanner :-) at 200 dpi: http://ana-3.lcs.mit.edu/~jnc/tech/jpg/KACPUPanel.jpg I have a TC08 inlay, but it's currently being used in my QSIC display (until we can get the RKV11-F/RPV11-D inlay done :-), and I didn't want to yank it out. As far as I can tell, it's the same font on the two of them. > the closest I know of off the top of my head is Akzidenz Grotesk. The Akzidenz Grotesk Medium is indeed very, very close (other than the zero). Do you happen to know if that font available for use in non-commercial settings? Thanks! Noel
Re: Font for DEC indicator panels
> From: Paul Koning >> The DEC font uses a zero with a slash > For that, a capital O with a slash would probably serve. Actually, it turns out that only earlier panels (e.g. KA10, TC08, etc) use the slashed zero; later ones (KI10, RP11, etc) use the ordinary ones. Since our panel is intended for use with the RPV11-D, the unslashed is OK. Thanks to all for all the help with the font; did anyone have any comments on the _layout_ of the inlay (here: http://www.classiccmp.org/pipermail/cctalk/2018-November/043285.html for those who missed it among all the other messages). Noel
cctalk/cctech
I thought cctalk was supposed to be a complete superset of cctech, but looking at the cctech archives, I see a lot of posts that didn't make it to cctalk. Does one need to do both to see everything? Noel
Re: Working Ardent Titan on Youtube
> From: Camiel Vanderhoeven > I have a fully working Ardent Titan with some interesting software on > it - the bundled version of MATLAB, and BIOGRAF, a molecular modeling > application Neat! Excellent! Do you have the source for any/all of the software on it? Noel
BA11-C and BA11-E mounting boxes
For some actual content about classic computers (instead of flaming about various ideas for improving existing systems), I think I've worked out why the BA11-C and BA11-E mounting boxes have out of sequence variant codes. It's obvious the variants were not assigned in creation order (the /44 and /24 use the -A variant box), but the -C and -E (the earliest variants, it seems) apparently come from the fact that the first is used to hold the CPU and console (for the /20), and the latter is an Expansion box. And speaking of the -C/-E, somewhat to my surprise, I've discovered that their H720 Power Supply is actually a switching supply. Ironically, its manual gives a _far_ better explanation of the EI conversion concept than the later H742 one (which we discussed here at some length, after it confused me no end). Speak of BA11 variants, I've seen mention a BA11-B on Web sites, but only a single ref in a DEC manual (the DH11 Maint Man); does anyone have a pointer to a location where it's dicussed at more length? If so, thanks! Noel
Re: eBay search fail
> On a whim, I tried searching for '"pdp-11" "pdp-11"' (i.e. just > repeated the keyword), and this time it _did_ turn it up! Very odd. > I wonder why that made a difference? So I have a new theory about this. Searching for 'pdp-11' causes eBay to automagically limit the search to the 'Vintage Computing' category. They must have a keyword->category database. Anyway, if I manually then select 'All' categories, I get the same results for searches for both 'pdp-11' and 'pdp-11 pdp-11'. So my theory is that 'pdp-11 pdp-11' _doesn't_ hit their database, and so it goes to 'All' - thereby producing different results. So I just have to hit 'All' every time I do a search... Noel
Re: Opening RL02 disk pack
> From>: Christian Corti > I thought that the DEC packs would be similar but no, DEC had to invent > something different... Huh? I thought RL0x drives use an IBM 5440 type pack (as used on the IBM System/3 - I used one of those at my first computer job, they'd just gotten it in); DEC may have used their own format (and servo track stuff), I don't know much about the 5440. Noel
Re: Opening RL02 disk pack
> From: Paul Birkel >> I thought RL0x drives use an IBM 5440 type pack (as used on the IBM >> System/3 DEC may have used their own format (and servo track >> stuff), I don't know much about the 5440. > Sounds to me like it was different, but in a good way? I took a look, and found a manual for a 5440: http://bitsavers.org/pdf/ibm/system3/GA33-3002-0_5444_5440_ComponentsDescr_Aug70.pdf and the details (format, etc) are indeed different. The packs are physically compatible, but that's as far as it goes. Noel
Re: PDP-8/e
> From: Jay Jaeger > That code would not run in Windows of course, but it wouldn't be all > that difficult for someone with a C programming background to move it > to Windows under gnucc, or even Microsoft C++ or C#. I highly recommend CygWin (which comes with 'gnucc) for doing C stuff under Windoze: https://www.cygwin.com/ Most Unix/Linux code just compiles and runs under it; modulo stuff that uses things that are so Unix/Linux specific that there's no Windows equivalent, but that's not much - fork() is even there. If you already know Unix/Linux, it makes for a very low-learning-curve transition. Noel
Re: IBM SMS Data Capture - IBM 1410 update
> From: Jay Jaeger > I have finished the 3rd phase of my IBM 1410 SMS computer > reverse-engineering project. ... The ALDs comprise 752 pages from 9 of > the 11 total volumes of system schematics/engineering drawings ... It > took me roughly 375 hours of time (probably more like 450 - not all time > was captured) to capture the data into a database Wow. I am super impressed. My hat is off... Fantastic job! Noel
Re: AMD Am8177 Datasheet
> From: Kyle Owen > Gah...just found it. We've all been there... :-) Noel
Re: Core memory emulator using non volatile ram.
> From: Paul Koning > For that matter, core memory details such as destructive read weren't > visible to the CPU Umm, not quite. If you'd said 'core memory details such as destructive read weren't visible to the _program_', you'd have been 100% correct. But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in QBUS) where possible precisely for the benefit of core memory with its destructive readout. (And there's some hair for interlocking the multiple CPU's on the -11/74 which I don't recall off the top of my head.) And I have a vague memory of something similar on other early DEC machines; probably some -8 models. Noel
Re: Core memory emulator using non volatile ram.
> From: Paul Koning >>> core memory details such as destructive read weren't visible to the >>> CPU > DATAIP/DATAO on the Unibus doesn't depend on the destructive read > property. Yes, the CPU can't tell what the memory is doing. > The reason it existed is that it allows core memory to optimize the > timing In other words, it's only there to allow the CPU to act in a way that works well with core memory. Whether that means that the way core operates is "visible" to the CPU is a debate about definitions. Put it another way - do any modern CPU's do 'read-modify-write' cycles (other than for interlocks in a multi-CPU system)? Noel
Re: Want/Available list
> From: Chris Hanson > Do you mean you would prefer to visit a web page to read the latest > posts on cctalk rather than have them delivered to you via email? Hey, that's how I read CCTalk: http://www.classiccmp.org/pipermail/cctalk/ I don't want all this cruft clogging up my inbox. Noel
Re: Which DEC machine made use of th pre Flip-Chip board?
> From: Mattis Lind > I cannot figure out which early machine it comes from. They're called 'System Modules': http://gunkies.org/wiki/System_Module and they were used from the PDP-1 through (I think) the PDP-7; at least, this PDP-7 internals image: https://www.soemtron.org/images/jpgs/decimages/sn113robertjohnson85680004.jpg seems to show System Modules at the top, and FLIP CHIPs at the bottom. (I'm pretty sure even the first PDP-8 - the 'straight 8' - uses only early FLIP CHIPs - transistorized ones.) The DEC brochure for it (P5141) is a little puzzling; it says (p. 2) that "INTEGRATED CIRCUITS are basic elements of the low cost, newly designed silicon FLIP CHIP modules used throughout PDP-7", but AFAIK, the first FLIP CHIPs (R-series, B-series, etc) were all transistors; the later M-series were the first ones to have ICs. Maybe this is some old meaning of "integrated circuits"? Noel
Re: Which DEC machine made use of th pre Flip-Chip board?
> through (I think) the PDP-7; at least, this PDP-7 internals image > .. seems to show System Modules at the top, and FLIP CHIPs at the > bottom. After groveling through the 'PDP-7 Maintainence Manual' (F-77A), this seems to be accurate. In "Module Identification" (pg. 6-5), it refers to both types; the example on the next page uses a 4303, a 4000-Series System Module. What's interesting is the physical layout; all System Modules at the top of that image, and FLIP CHIPs at the bottom. No doubt this is partially for mechanical reasons (the two used different backplanes), but I wonder about the division into sub-systems; were the two types interspersed among each other in individual sub-systems (rewquiring running wires from the top to the bottom), or were sub-systems exclusively one or the other (so that the top of the bay is one sub-system, and the bottom another)? No doubt I could answer this by studying the prints, but time is short; perhaps someone who worked on the one at the LCM and already knows the answer can enlighten us! Noel
Origin of 'Straight 8' name
Does anyone know where the 'Straight 8' name for the first PDP-8 model came from? Obviously, it's probably a play on the car engine configuration name, but how did the connection get made? Thanks - I hope! Noel
Re: Which DEC machine made use of th pre Flip-Chip board?
> From: Allison > IC as in digital logic were in production in the early 60s Yes, but if you look at the picture/manual (I found a "Module location for I/O" chart on pg. 335 of the PDP-7 Maint Manual - alas, not the whole machine, just the FLIP CHIP part), the PDP-7 is all B-series and R-series FLIP CHIPs, which are all discrete transistors. AFAIK, the first ICs (in the modern sense) on FLIP CHIPS were on M-series. Noel
Re: Origin of 'Straight 8' name
> From: Al Kossow > "Straight-8" seems to be a fairly modern name coming from collectors My _guess_ is that that probably happened because there is no formal 'model' for that first one (unlike the first -11, which got re-named the -11/20 BITD), and people recently picked that to disambiguate them from all the other -8's. But what I _don't_ know is _why_ that particular name? I was hoping some -8 collector knew... Noel
Re: Origin of 'Straight 8' name
>> people recently picked that to disambiguate them from all the other >> -8's. So my assumption (that it was recent) seems to be incorrect; I heard that it was in use in the 60's to differentiate it (e.g. for knowing what spares to take). Alas, with the origin that far back in time, we'll probably never find out what the connection was. > From: Bill Degnan > The original PDP 11 was sold in two model options, although the numbers > did not appear on the faceplace, very clearly the model options were > called PDP 11/10 and PDP 11/20. ... The fact that the name does not > appear on the front panel has caused every DEC historian to miss this > factoid. Yeah, it tripped me to. Although after I sent that email, I went back and looked, and it's called '-11/20' on all the documents I can find, including the prints. I'll check in the DEC archives (available on BitSavers), but I suspect the "PDP-11" on the front panel was the result of something getting dropped in the process of doing the panel, not the reasult of a name change by DEC. Noel
Re: Original PDP-11/10 [was: Re: Origin of 'Straight 8' name]
> From: Bill Degnan > It's pretty well researched at this point to be true to state that the > first two PDP 11 models were the 11/10 and 11/20. It just takes a while > for this to work its way through academia. Some places got the message a while ago: http://gunkies.org/w/index.php?title=PDP-11&diff=11528&oldid=11525 Note the date. I was reading the 1970 "pdp11 handbook" (note the title - all the pictures show machines labelled "pdp11") and read about it there. > From: Paul Koning > I'm curious about that 1 kW read-only memory. What technology is that > memory? At that size and that date I suspect core rope, but that would > be pretty expensive (due to the labor involved). I think that's what it must be. It's the MR11-A, about which I can find very little - it's in the 1970 "pdp11 handbook", p. 46, but I can't find anything else. It says there "2-piece core with wire braid, 256 wires, 64 cores". Reading between the lines, it sounds like the customer could 'configure' the contents (perhaps using the "2-piece core), DEC didn't do it. If anyone knows anything about this memory, that would be really good. Noel
PDP-11/45 RSTS/E boot problem
> From: Paul Koning
>> On Dec 31, 2018, at 6:32 PM, Henk Gooijen via cctalk wrote:
>> ...
>> There are one or two bits in a register of the RK11 that have a
>> different meaning/function, depending on the controller being a -C or
>> -D.
> If someone can point me to the description of the differences I should
> be able to say what RSTS will do with them.
AFAIK, the only difference (in programming terms) between the -C and -D is
that the -D has dropped the maintainance register.
Although I cheerfully admit I haven't sat down with -C and -D manuals and
done a bit-by-bit compare. I just did that (I used the "RK11-C Moving Head
Disk Drive Controller Manual", DEC-11-HRKA-D, and the 1976 "Peripherals
Handbook"), and found in the following:
In the RKDS: bit 7 has changed the definition slightly ("Drive Ready" to
"R/W/S Ready"), but seems to be basically the same. In the RKCS, bit 9 is
"Read/Write All" in the -C, and unused in the -D; bit 12 is "Maint" in the
-C, unused in the -D.
In other words, a -D driver should work just fine with a -C, IMO.
Noel
Re: wanted back issues IEEE ANNALS OF THE HISTORY OF COMPUTING bound or unbound... dtop us a line off list please.
> From: Al Kossow > I do not archive any paper myself. There are quite a few silver-dish lovers; you might be able to raise some funds by listing stuff on eBait (although I can easily see that maybe it would be more hassle than it's worth). > Currently, I am being asked to reduce my backlog inside of Shustek and > am making some hard choices. Can you say anything about this (it sounds troubling)? Can we help in any way? (And the "inside of Shustek" is puzzling - I thought Shustek was a person?) Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Paul Koning
>> I haven't sat down with -C and -D manuals and done a bit-by-bit
>> compare. I just did that (I used the "RK11-C Moving Head Disk Drive
>> Controller Manual", DEC-11-HRKA-D, and the 1976 "Peripherals Handbook"),
>> and found in the following:
>> In the RKDS: bit 7 has changed the definition slightly ("Drive Ready"
>> to "R/W/S Ready"), but seems to be basically the same.
> You mean bit 6? Bit 7 is "drive ready" in both.
@*#$@*$%@&*! My silverfishionado nature screwed me! I didn't have an
RK11-D manual in paper, so I relied on the "Peripherals Handbook" - and it's
got an error!
In both the 1975 and 1976 edition, the _diagram_ for the RKDS shows bit 7 as
"R/W/S Ready", and bit 6 as "Access ready", but the _table_ shows bit 7 as
"Drive Ready", and bit 6 as "R/W/S Ready"! OK, so let me ditch that, since
it's self-contradictory, and thefore necessarily erroneous.
I'll switch to the RK11-D User's Manual, EK-RK11D-OP-001. It gives bit 7 as
"Drive Ready", and bit 6 as "R/W/S Ready". (The RK11-C manual gave bit 7 as
"Drive Ready", and bit 6 as "Access Ready".)
> Bit 6 has a different name in the two descriptions but the meaning
> appears to be the same.
Yup.
Thanks for catching that for me!
Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller > All the CPU, FPU, KT11, KW11, and RK11 MAINDECS are passing just fine. Don't forget Vonada Maxim #12: "Diagnostics are highly efficient in finding solved problems." :-) Noel
KD11-E/EA microcode flow diagrams
The copy of the KD11-EA engineering drawings (in the 11/34A Field Maintenance Print Set, MP-00190) on Bitsavers is missing most of the pages that hold the microcode flow diagrams. I have a set of the KD11-EA FMPS (MP-00192), which does have all the missing pages, which I can eventually scan. However, in the interim, the 11/34 Field Maintenance Print Set Vol. 2 (MP-00082) on Bitsavers has a complete set of microcode flow diagrams for the KD11-E (pp. 15-40 of the PDF), and they are almost identical to the KD11-EA diagrams. The only difference I can see (I compared page by page, to see if each page had the same microinstructions on it) is that on sheet 17; the last microinstruction for RTI/RTT has been moved from 002 -> 744. (The actual microinstruction contents seem to be the same.) I don't know whyo the changed address; I originally thought that perhaps they had to re-do the IR Decode ROMs when they added floating point, and they needed the original location to handle the start of the floating point microcode, but that doesn't seem to be the case. Noel
Re: off topic - capatob - saratov2 computer Russsian pdp8? HELP
> From: Grant Taylor > Is "byte" the correct term for 6-bits? I thought a "byte" had always > been 8-bits. I don't claim wide familiary with architectural jargon from the early days, but the PDP-10 at least (I don't know about other prominent 36-bit machines such as the IBM 7094/etc, and the GE 635/645) supported 'bytes' of any size, with 'byte pointers' used in a couple of instructions which could extract and deposit 'bytes' from a word; the pointers specified the starting bit, and the width of the 'byte'. These were used for both SIXBIT (an early character encoding), and ASCII (7-bit bytes, 5 per word, with one bit left over). > I would have blindly substituted "word" in place of "byte" except for > the fact that you subsequently say "12-bit words". I don't know if > "words" is parallel on purpose, as in representing a quantity of two > 6-bit word. I think 'word' was usually used to describe the instruction size (although some machines also supported 'half-word' instructions), and also the machine's 'ordinary' length - e.g. for the accumulator(s), the quantum of data transfer to/from memory, etc. Not necessarily memory addresses, mind - on the PDP-10, those were 18 bits (i.e. half-word) - although the smallest thing _named_ by a memory addresses was usually a word. Noel
Re: off topic - capatob - saratov2 computer Russsian pdp8? HELP
> From: Guy Sotomayor Jr > I think it's also telling that the IETF uses the term octet in all of > the specifications to refer to 8-bit sized data. Yes; at the time the TCP/IP specs were done, PDP-10's were still probably the most numerous machines on the 'net, so we were careful to use 'octet'. Although the writing was clearly on the wall, which is why it's all in octets, with no support for other-length words (unlike the ARPANET, which sort of supported word lengths which were not a multiple of 8 or 16 - which was actually use to transfer binary data between 36-bit machines). > It *may* have been the IBM 360 that started the trend of Byte = > 8-bits Yup. And then the PDP-11 put the nail in that coffin (and in 1980, there were more PDP-11's, world-wide, than any other kind of computer). Noel
Re: off topic - capatob - saratov2 computer Russsian pdp8? HELP
> From: William Donzelli >> in 1980, there were more PDP-11's, world-wide, than any other kind of >> computer. > I bet the guys at Zilog might have something to talk to you about. I was quoting my memory of a DEC ad in the WSJ, which now that I go check, says the -11 was "the best-selling computer in the world" (the ad was in 1980). There are a number of possible explanations as to why it makes this claim: - some marketing person made it up - they were only counting things that were general-purpose (i.e. came with mass storage and compilers) - they didn't consider micros as "computers" (many were used in things like printers, etc, and were not usable as general-purpose computers) Etc, etc. Noel
Re: off topic - capatob - saratov2 computer Russsian pdp8
> From: Dave Wade > The only machine I know where a "byte" is not eight bits is the > Honeywell L6000 and its siblings I'm not sure why I bother to post to this list, since apparently people don't bother to read my messages. >From the "pdp10 reference handbook", 1970, section 2.3, "Byte Manipulation", page 2-15: "This set of five instructions allows the programmer to pack or unpack bytes of any length from anywhere within a word. ... The byte manipulation instructions have the standard memory reference format, but the effective address E is used to retrieve a pointer, which is used in turn to locate the byte ... The pointer has the format 0 5 6 11 12 13 14 17 18 35 P S I X Y where S is the size of the byte as a number of bits, and P as its position as the number of bits remaining at the right of the byte in the word ... To facilitate processing a series of bytes, several of the byte instructions increment the pointer, ie modify it so that it points to the next byte position in a set of memory locations. Bytes are processed from left to right in a word, so incrementing merely replaces the current value of P by P-S, unless there is insufficient space in the present location [i.e. 'word' - JNC] for another byte of the specified size (P-S < 0). In this case Y is increased by one to point at the next consecutive location, and P is set to 36 - S to point to the first byte at the left in the new location." Now imagine implementing all that in FLIP CHIPs which held transistors (this is before ICs)! Anyway, like I said, at least ITS (of the PDP-10 OS's) used this to store ASCII in words which contain five 7-bit _bytes_. I don't know if TENEX did. > I also feel the use of the term Octet was more marketing to distance > ones machines from IBM. Huh? Which machine used the term 'octet'? Like I said, we adapted and used the term 'octet' in TCP/IP documentation (and that's definite - go check out historical documents, e.g. RFC-675 from 1974) because 'byte' was at the time ambiguous - the majority of machines on the ARPANET at that point were PDP-10's (see above). Interestingly, I see it's not defined in that document (or in the earlier RFC-635), so it must have already been in use for an 8-bit quantity? Doing a little research, there is a claim that Bob Bemer independently invented the term in 1965/66. Perhaps someone subconciously remembered his proposal, and that's the ultimate source? The term is also long used in chemistry and music, of course, so perhaps that's where it came from. Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller > Oh, one last thing: if anybody else out there has a real working '11/45 > + RK05 and wants to try this RSTS image, let me know, and I'll send you > a copy (all 2.5MB of it, hah). It'd be interesting to see if this a > really just limited to my machine? Good idea. Two more along the same lines: Try running your RSTS image on Ersatz-11, see if it's a simulator issue. And try bringing up Unix V6 on your machine; if it's a hardware issue with your machine, it might show with that, too. (I can help with fault analysis on V6, if _anything_ doesn't work properly.) It will need a single RK pack, I can help with providing the image, if needed. Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller > I've thought about that; Unix V6 is actually next on my list of OS's to > try. I think I have seen a fairly detailed set of instructions on > building an image from this from the commonly available distribution > tape. Yeah, one comes with the V6 distribution: http://gunkies.org/wiki/Setting_up_UNIX_-_Sixth_Edition (That's just a 'do this and then do that' list - if you want to know what it's actually _doing_, this: http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition gives the technical details.) Alas, the instructions don't have a lot of detail on how to create the /45 version (it's quite simple - basically one just includes m45.s instead of m40.s in the linker command line :-); I guess I'll do up a cheat sheet. > But if you have an RK05 image already ready to go, go ahead and send it > over and I'll give it a try! Well, there are single-RK05 images up already: http://www.tuhs.org/Archive/PDP-11/Distributions/research/Ken_Wellsch_v6/ but they only include binary for /40's (which will run on a /45 of course; they distributed only the lowest-common-denominator binary, to make their life simple; people have to build their own binary - system and commands - if they want to upgrade). But if you'd like me to make up an RK05 image with a /45 system on it too (one gets to specify what one wants to load at boot time); let me know, and I can whip it up - but really, it's drop-dead simple to build a /45 version if you have the /40 version running. Note: the pack images on the distribution tape _do not_ include the bootstrap in block 0; use the one I linked to above. > It wasn't clear to me last time I looked that I could build V6 to run > off a single pack without having a second RK05 drive and pack available > for swap? No, the image above is for a single RK drive machine; it will run that way, albeit things are a bit cramped. What it does is put a file system in blocks 1-4000, and it uses blocks 4000 and up as the swap area (I forget which one block 4000 itself goes with :-). > Day gig starts back up today after winter break, so less bandwidth for > PDP-11 hacking now unfortunately! :-( Well, at least you have something to go back to; the spousal unit works for NASA, and they're all getting an enforced extended break (much to her annoyance). Noel
Re: PDP-11/45 RSTS/E boot problem
> I guess I'll do up a cheat sheet. OK, first crack here: http://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition If there are any improvement I can/should make, please let me know. Thanks! Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller > Thanks, Noel -- I'll give that a try! Sure - always glad to help with anything V6 related - that's my chief technical amusement, now that I'm retired! :-) Any questions/issues, let me know, and I'll try and get right back. When booting UNIX, remember make sure the switches on your /45 are set to 0173030, so it comes up single-user! (Might we worth checking to see if all the bits in the SR are working, but you've probably already done that as part of bringing the machine up? I wonder if a failure there could cause the RSTS issue? It's so cool that you have a working /45! I have yet to start on mine...) And do icheck/dcheck every time you bring it up, and make sure to 'sync' before halting... These old systems are not as robust in terms of the file system! And when it gets to putting together a /45 version of the OS, that new page I just did should help. Noel
Re: KD11-E/EA microcode flow diagrams
> From: Fritz Mueller >> the last microinstruction for RTI/RTT has been moved from 002 -> 744. > So what's at 002 now? Maybe something new was required there by micro > branch/fork logic, so the original contents had to be moved? Well, it turns out I've been transcribing the ucode flow diagrams from the 34, as part of a deeper look at the 34. (Dave B and I need a PDP-11 in the FPGA on the QSIC, to run the USB protocol on; rather than using a microcontroller, we decided the hack value of putting an -11 in there was too much to resist. It's also practical, though - we're already very familiar with it, have a good toolchain for it, etc. One option for that - we know about the existing FPGA -11's - was cloning the /34.) So according to that table: http://gunkies.org/wiki/KD11-E/EA_microcode there is no uinst at 002 now! So I have no idea why they moved it. (The place they moved it to, 0744, seems like it was the first empty location.) There is a dump of the 34A microcode here: http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt and for 002 it gives Called by. = IR or BUT only NEXT MPC.. = 015 but 015 doesn't seem like a useful place to branch to? Maybe location 002 was just abandoned (I have no idea why), and that's some leftover trash? BTW, the engineering drawings contain three errors (fixed in the table above; see the notes there), so I suspect they were drawn up by looking at a set of the listings. I wonder if the actual source has survived? Probably not, alas... Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller >> http://www.tuhs.org/Archive/PDP-11/Distributions/research/Ken_Wellsch_v6/ > Hmm, this link didn't work for me Arggh, sorry. I simply copied the link from my page: http://www.chiappa.net/~jnc/tech/V6Unix.html and didn't check it. :-( I'm a bit suprised that Warren broke everyone's deep links by re-organizing... > I found I think equivalent mirrored at: >https://www.tuhs.org/Archive/Distributions/Research/Ken_Wellsch_v6/ > ...which directory contains several file system images and one tape > image, "v6.tape". Argh. I thought there _used_ to be disk images there - maybe they got removed? Anyway, the one you want is now here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/V6Root Just decant all the bits onto a RK pack, starting at block 0, and you should be able to boot that pack. (I'll fix my page a little later, burned out after the microcode transcription!) > Is that tape image maybe not compatible with SIMH's tape format? It's just a plain copy of the contents of a V6 distribution tape. IIRC, SIMH wants 'tape' files with meta-data such as the length of each tape record, file marks, etc. Noel
Re: KD11-E/EA microcode flow diagrams
> From: Fritz Mueller > I should go read up on QSIC. There's not much on the Web, alas. We have two working prototypes (a wirewrap QBUS mother-board with bus transceivers, level converters, etc, connected to an FPGA prototyp ung card by flat cables), and working FPGA code to emulate an RK11, using a uSD card for actual storage. It's good enough that the /23 can boot and run V6. We also have working indicator panels: http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html but the inlay we've done: http://pdp10.froghouse.org/qsic/indicator-panel-printed.jpg is not a straight copy of an existing panel (those all have lots of lights that only make sense with a real drive, and leave out others that would be really useful, e.g. the address). Here: http://pdp10.froghouse.org/qsic/manual.pdf is the firat crack at the manual for the production version (the RP11 is not done yet). > I could really use a "USIC"... :-) That's next, after the QSIC is out. It will include Able ENABLE: http://gunkies.org/wiki/Able_ENABLE functionality, so UNIBUS machines can have more than 256KB of main memory. > Probably the best thing would be to pop a ROM out of a working /34 and > read it out? Is that how you've gotten your authoritative version? I didn't get it, I found it on BitSavers - I assume that was what whoever provided it did. But it's actually stored in 12 4-bit wide PROMs, U95-U118 (roughly). Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller > Kernel boots on my actual hardware, but an "ls" in single-user mode > generates a "Memory error -- core dumped". Oh, yeah, your hardware definitely has issues, then. > So evidence is mounting that I really do have some sort of issue with > my MS11-L. If so, I'm rather suprised that the DEC diagnostics didn't pick it up. > Tried a multi-user boot for kicks You're stu^H^H^Hbrave! > I'm actually able to "ls" under that. Yeah, probably your process wound up at a different place in physical memory (although there are a zillion other ways one could get that effect, depending on exactly what the issue is - e.g. maybe a bad bit in the memory word where the process table happened to wind up). > I could work to extract the core file The 'ls' one, please (shorter/simpler); I can poke around in that, and see if I can find any clues as to the cause. > probably the best application of effort would be to do develop/run more > diagnostics on the MS11-L OK. I also have a little memory diag that I wrote myself that you could try. Let me know if you'd like it; it's currently for the /23+/73 (and it would probably work on the /70, I'd have to check) so I'd have to tweak a few things to get it to run on a /45. Best way to get it to you would be to send you the Unix assembler source, if you can get that onto the disk, then you could: as memptst.s mv a.out /memptst and just boot it. Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller PS: > I could work to extract the core file Can PDP11GUI save output from the -11's console? If so, just say 'od core', and send me the output. Noel
Re: PDP-11/45 RSTS/E boot problem
> From: Fritz Mueller PPS: > I could work to extract the core file I just checked, and the binary for the 'ls' command is what's called 'pure code'; i.e. the instructions are in a separate (potentially shared) block of memory from the process' data (un-shared). I don't recall off the top of my head whether the location of that shared block of memory is in the per-process swappable kernel data (which is included in the process core dump). I'll check tomorrow, when I'm not sick as a dog (pretty miserable right at the moment). It would be east to mod the OS to print all that info when that illegal instruction trap happens - but that will change the size of the OS, so will probably change the location the process is at; so that might cause the symptoms to change. Ditto for recompilling 'ls' to make it a unified blob. > Assuming that doesn't create another core file... :-) :-) Don't worry, we'll nail it! Noel
Re: PDP-11/45 RSTS/E boot problem
> I don't recall off the top of my head whether the location of that
> shared block of memory is in the per-process swappable kernel data
> (which is included in the process core dump).
So I checked, and the swappable per-process kernel data does in fact include
pre-computed contents for all the memory management registers, so we'll be
able to see (from the process core dump) where the code and data segments
were.
On another front, that error message ("Memory error") is produced when a
process gets a 'memory management trap' (trap to 0250). This could be caused
by any number of things (it's a pity we don't know the contents of SR0 when
the trap happened, that would tell us exactly what the cause was).
With working hardware+OS, it's usually the result of a bad pointer in the
program. In a tested program like 'ls', I don't think that's the case. It's
most likely caused by faulty memory, but it's also faintly possible that the
MMU has an issue.
I'll look at the process dump a little later today, and see if I see anything
of significance.
Noel
Re: PDP-11/45 RSTS/E boot problem
> the swappable per-process kernel data does in fact include pre-computed > contents for all the memory management registers, so we'll be able to > see (from the process core dump) where the code and data segments were. Uh, no. The copies there are 'prototypes', later modified for actual use by adding in the actual address in main memory. Still trying to understand how that works - the code (in sureg() in main.c) is kind of obscure. Noel
Re: Vintage-computing relevant IOBCC entry
> From: Bill Degnan > I attempted to port the same version of unix to an rl02 disk pack and > to run on an actual 11/40. I was able to get ir to boot up to the # > prompt but my system does not have a working EIS card to proceed any > further. I"m incredibly surprised that you got to the prompt! First, the V6 RL bootstrap uses ASH, part of EIS. And then the C compiler makes extensive use of EIS instructions, so anything in C (the OS, 'init', 'sh', etc) may have EIS instructions in it. Noel
Re: PDP-11 Memory
> From: Bill Gunshannon > I have a number of different memory modules. Mostly DEC but a couple > zthird party. Here's the problem. None of them are reflected in any of > the documentation I have been able to find so I can't configure them > away from their defaults! ... > Anybody got any pointers to help me configure some of this stuff? > M7551-AC - All the docs I can find seem to refer to > AA or AB and jumpers and switches are not > in the same locations. You've looked in EK-MSV1Q-UG-002, right? That seems to cover a couple of different revisions. > M8067-LB > M8067-LF > M8067-LJ - Same problem. I can find no documentation for any -L > boards and these don't even resemble the pictures I find. The M8067-L variants are all MSV11-PL (512-Kbyte QBUS MOS memory). The last letter usually indicates the vendor of the MOS chips used. > And then I have two non-DEC module that are unlikely to > have any documentation still floating around for. > Camintonn CMV-1000 I too couldn't find any documentatin for this; there is the 'SMS 1000 Microcomputer System OEM Manual', which says how to configure one for a base configuration. I started to work out what the configuration switches do, by experiment, but I got distracted before I finished. I have found my notes from this exercise, and can send them to you if they are of any use. Noel
Re: warped RK05 pack -- lost cause?
> From: Fritz Mueller fritzm at fritzm.org > I'm assuming that if I had to release the media from the hub in order > to true it, its value as an alignment cartridge would be lost anyway. Yes and no The RK05 alignment pack is mostly to make sure that the fine lateral track adjustment is correct (i.e. that when the head thinks it's over track 0, it's _really_ over track 0). However, there's also rotational alignment (i.e. start of sector), which is done with the slits in the ring on the pack (so yes, releasing the media from the hub in an ordinary pack will make that pack unreadable - at least until it's reformatted). There is an index/sector timing adjustment procedure, and it uses the alignment pack too, but this rarely needs to be done. Still, if the platter is on wrong, the whole thing's useless anyway. So as long as the platter goes back exactly concentric (and I'm unsure of how the mechanical alignment works, there may be something to assure there's no runout), it should still be usable for the head alignment. (To use it for sector alignment, you'd have to ensure that the drive is aligned for this before-hand, then use it to align the pack.) But check the RK05 Maintenance Manual (EK-RK5JF-MM-001), and see if there's anything I missed. There's also an 'RK05 Subsystem Maintence Course' document (EY-D2055-WB-001) which might contain some useful info. Off to look at the V6 MMU setup code! ;-) Noel
Large group of later DEC board on eBay
Not my thing (I'm into earlier stuff): https://www.ebay.com/itm/392212420626? but I thought I'd post it since it's filed in an unusual place. Noel
Re: IBM in TX
> From: Fritz Mueller > I think I see an H960 with a couple DEC half panels stuck on it peeking > out of the very back there... Two H960's, actually - it looks like there's another one in front of that one. If the half panels are for sale, I'll take them! :-) Noel
Re: PDP-11 Memory
> From: Allison Parent > Most Probable cause is interrupt grant is broken. The only -11 that complains if the grant chain is broken that I know of is the /34 (maybe the /04 too). I certainly have a QBUS chassis right next to my workstation here that i) has a bunch of empty slots, and ii) works fine, as long as there are no empty slots between the CPU and the devices. Also, IIRC he said it works with 3 cards plugged in, but not 4; how can plugging a card _in_ cause grant problems? > For most microspheres backplanes the first three slots are different > than remaining. That might be worth checking into. I'm not familiar with the second box he's using, so can't help there. Noel
Re: IBM in TX
> From: Fritz Mueller > They'd nicely compliment or house those new QSIC indicator panels > you've been working up, huh? :-) Complement. I already have a large stack of empty bezels, acquired to hold the indicator panels... :-) Although Dave Bridgham has been playing with the CNC mill at his local makespace (he's already turned out a bunch of light shields for me), and he now has a prototype of a thing which combines the bezel and light shield. So maybe the empty bezels will instead get paired with blank sheets to make a stack of 1/2-width blank panels. Someone still makes that 'pebbled' sheet like what DEC used in blank panels, but we haven't acquired any yet to see just how close a match it is. (Anyone happen to know?) Noel
