Re: DEC MS630/M7609 Question
Thanks, Lyle. I was reading this. I guess its wrong? https://en.wikipedia.org/wiki/MicroVAX The MS630 memory expansion module was used for expanding memory capacity. Four variants of the MS630 existed: the 1 MB MS630-AA, 2 MB MS630-BA, 4 MB MS630-BB and the 16MB MS630-CA. Wouldn't be the first time wikipedia was wrong... Eugene From: Lyle Bickley Sent: Tuesday, July 9, 2019 6:08 PM To: cct...@classiccmp.org Cc: W2HX Subject: Re: DEC MS630/M7609 Question On Tue, 9 Jul 2019 21:11:39 + W2HX via cctech wrote: > Hi there. > > > I just acquired a board with the number M7609. It was advertised as an > M630-CA which my research tells me is supposed to be 16MB. How do I tell on > the board if this is 8MB or 16MB? There does not seem to be a suffix on the > board that I can see. > > > What to look for? M7609-AAMS630-CAQ 8-Mbyte parity 36-bit RAM for KA630 (MicroVAX II) Lyle -- 73 NM6Y Bickley Consulting West Inc. https://bickleywest.com "Black holes are where God is dividing by zero"
Re: DEC MS630/M7609 Question
On Tue, 9 Jul 2019 21:11:39 + W2HX via cctech wrote: > Hi there. > > > I just acquired a board with the number M7609. It was advertised as an > M630-CA which my research tells me is supposed to be 16MB. How do I tell on > the board if this is 8MB or 16MB? There does not seem to be a suffix on the > board that I can see. > > > What to look for? M7609-AAMS630-CAQ 8-Mbyte parity 36-bit RAM for KA630 (MicroVAX II) Lyle -- 73 NM6Y Bickley Consulting West Inc. https://bickleywest.com "Black holes are where God is dividing by zero"
Re: DEC MS630/M7609 Question
On 09/07/2019 22:11, W2HX via cctech wrote: Hi there. I just acquired a board with the number M7609. It was advertised as an M630-CA which my research tells me is supposed to be 16MB. How do I tell on the board if this is 8MB or 16MB? There does not seem to be a suffix on the board that I can see. What to look for? The simple answer is to install it in a uVAX2 system and see what it says :-) IIRC the M7608 comes in (at least) two variants, the MS630-BA, which is 2MB, and the MS630-BB, which is 4MB. I think that if you hold them side by side, it's obvious one has half the memory positions not filled. But the M7609 is an MS630-CA, which is always 8MB. There are various suffixes to the MS7609 board, but they (I think) just tell you the manufacturer of the RAM chips; the board is always 8MB. Antonio -- Antonio Carlini anto...@acarlini.com
Re: DEC MS630/M7609 Question
M7608 == 4MB M7609 == 8MB AFAIK the only DEC 16MB Q-bus board is the MS650 M7622 for the KA640, KA650, KA655, KA660 On Tue, Jul 9, 2019, 2:36 PM W2HX via cctech wrote: > Hi there. > > > I just acquired a board with the number M7609. It was advertised as an > M630-CA which my research tells me is supposed to be 16MB. How do I tell on > the board if this is 8MB or 16MB? There does not seem to be a suffix on the > board that I can see. > > > What to look for? > > 73 Eugene W2HX > > >
DEC MS630/M7609 Question
Hi there. I just acquired a board with the number M7609. It was advertised as an M630-CA which my research tells me is supposed to be 16MB. How do I tell on the board if this is 8MB or 16MB? There does not seem to be a suffix on the board that I can see. What to look for? 73 Eugene W2HX
Re: cctalk Digest, Vol 58, Issue 9
> On Jul 9, 2019, at 10:00 AM,Tomasz Rola wrote: > BTW, you would like a ride to the past? I would like a ride to the > future. Although from what I have seen so far, maybe not... I absolutely believe in the future of 2505 as shown to us by Mike Judge. Please let me stay in this century. Thanks. mcl
Re: Email delivery protocols / methods.
On 7/9/19 9:14 AM, Paul Koning via cctalk wrote: > > >> On Jul 8, 2019, at 11:27 PM, Grant Taylor via cctalk >> wrote: >> >> ... >> On 7/6/19 12:57 PM, Paul Koning via cctalk wrote: >>> There's the MAIL-11 protocol (end to end, no MTAs) and the DECmail protocol >>> which may be some OSI-like thing, I'm not sure anymore. >> >> I guess I don't know enough about MAIL-11 to understand why you say >> end-to-end / no MTA. > > No mail servers. You address mail to node::user and it contacts the mail > protocol listener at that node, which drops the message into the mailbox of > that user on that system. The "protocol listener" as you call it is the mail server. UUCP and SMTP worked the same way until the dawn of networked MUA's that let the mail remain on some system other than the user systems. bill
Re: KL10-A/KL10-B differences
On Tue, Jul 9, 2019 at 4:44 PM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > Could an -A be upgraded to a -B by swapping the I/O backplane? Electrically, yes, but physically it might not be easy. The portions of the chassis that support the backplanes are different, and the power supplies aren't there. When I refer to "I/O backplane", technically that's four separate backplanes. There's one DIA20/DMA20 backplane (not present in all models), one DTE20 backplane, and two separate backplanes that are combined for the RH20s (if present), one backplane for the A through D positions (upper 2/3 of each module slot), and one for E and F. The KL10-A (DECsystem-1080) does not have the RH20 backplanes, and has a variant of the DTE20 backplane that only supports a single DTE20. The KL10-A I/O cabinet has only 7 DC power supplies and associated cabling, vs 13 for the KL10-B, because it only has to power one DTE20 rather than four DTE20s and eight RH20s. Because of that, the KL10-A has only two H742 power supply frame/front-end assemblies rather than three. Useful terminology to know. Do you happen to know what 'PV' stands for - > or is it just a random letter code? > Essentially andom, as far as I know. KL10-PB through KL10-PD are assigned to some kind of subassemblies, but are not the same kind of assembly as the -PA and -PV. Probably a lot of -Px were assigned before they got to needing one that became -PV. On the -PA to -PV upgrade, could the backplane really be done with some > wraps? I ask because I saw in one manual, talking about a KL10-C to -PV > upgrade, it calls for a backplane swap-out. > I'm not entirely sure, so I easily could have been mistaken. I know -PV to -PW just needs some wraps. -PA to -PV may have required more significant backplane changes. Definitely they have different part numbers for the -PA and -PV backplane assemblies. I've also got some open questions on the later things like the KL10-R, AFAIK, -R is functionally and electrically equivalent to -E, but with physical changes needed for FCC compliance. > -PW, > and MCA25, > The MCA25 is the upgrade from -PV to -PW. It's preinstalled on the 1095 and 2065.
Re: KL10-A/KL10-B differences
> Erom: Eric Smith Hey, thanks for taking the time to provide all those details. As you no doubt saw, our emails crossed; I had managed to work out my own what the difference was. I'd been looking at this page: http://corestore.org/DEC2065.htm and saw the two backplanes, and assumed one was the EBox, and one the MBox - wrong! But eventually I got it straight... One some other points you covered: > The 1080 was intended to replace a KA10 or KI10 ... It only needed a > single DTE20 for the internal console PDP-11, and it didn't need an > RH20 because the disk would be attached via an RH10 Got it; makes sense. Could an -A be upgraded to a -B by swapping the I/O backplane? (Yes, the wiring to the I/O connectors would have to be changed too, and that might have been too difficult.) But could the APR handle it (perhaps with one or more board changes)? > The -PA and -PV designations .. are for the "arithmetic processor" > (APR), which is the main CPU portion of the KL10. Useful terminology to know. Do you happen to know what 'PV' stands for - or is it just a random letter code? >> my new theory is that it's the MBox ... that is the >> difference between the KL10-A and the KL10-B. > It's not just the MBOX; there are significant EBOX differences as > well. Various modules from the entire CPU are different, and the > backplane wiring is slightly different. It was possible to upgrade a > -PA to -PV by swapping modules and adding some wraps to the > backplane Do note I said "KL10-A and the KL10-B", not 'Model A and Model B'... I assume the APR's in the -A and -B were identical, it was just the I/O backplane, etc which were different. On the -PA to -PV upgrade, could the backplane really be done with some wraps? I ask because I saw in one manual, talking about a KL10-C to -PV upgrade, it calls for a backplane swap-out. I've also got some open questions on the later things like the KL10-R, -PW, and MCA25, which are not covered well in the documentation avilable in bitsavers; do you know about the later variations? Noel
Re: cctalk Digest, Vol 58, Issue 9
> On Jul 9, 2019, at 10:00 AM,Tomasz Rola wrote: > > BTW, you would like a ride to the past? I would like a ride to the > future. Although from what I have seen so far, maybe not... Spider Robinson did a story about this, entitled “The Time-Traveler.” The method, while as easily-implemented now as it was then, is not pleasant. Adam
Re: Email delivery protocols / methods.
> MMDF MMDF was[*] an MTA, not a protocol. (See also PMDF.) --lyndon * Is anyone still running MMDF? The last production shops I had my fingers in that ran it was circa 1996. That was when SCO was still a thing, and MMDF was its MTA of choice.
Re: Lots of Apple 1 computers @ VCF West
Tor Arntsen via cctalk writes: > On Mon, 8 Jul 2019 at 18:19, Chuck Guzis via cctalk > wrote: > >> What matters to me is [b]documentation[/b], however it's preserved. I'm >> often faced with a bit of old data and I need to know the details upon >> which it was fabricated. That has value to me. Al K has been >> invaluable in this respect. > > I collect all the documentation I can find (including my own old notes > when I can find them). It's really hard to figure out exactly how > something works when documentation is lost and there's nobody around > with the knowledge. This was by far the biggest challenge I had when writing the 3B2/400 simulator for SIMH. Documentation was scarce or nonexistent for almost every aspect of the 3B2 system board internals, and I had to work out a lot of it myself by watching a logic analyzer. Thankfully, as the emulator progressed and word got out, it attracted the attention of some people with very useful documentation who kindly offered it to me. I've been hoarding what I can find and scanning it as fast as possible to get it all archived online in digital form as well as maintaining the original physical copies. But as a result, I'm keenly aware of how much this stuff is ephemeral. There are still lots and lots of AT publications relating to the 3B2 that are (as far as I can tell) lost to history and probably gone forever. -Seth -- Seth Morabito Poulsbo, WA, USA w...@loomcom.com
Re: Email delivery protocols / methods.
> On Jul 8, 2019, at 11:27 PM, Grant Taylor via cctalk > wrote: > > ... > On 7/6/19 12:57 PM, Paul Koning via cctalk wrote: >> There's the MAIL-11 protocol (end to end, no MTAs) and the DECmail protocol >> which may be some OSI-like thing, I'm not sure anymore. > > I guess I don't know enough about MAIL-11 to understand why you say > end-to-end / no MTA. No mail servers. You address mail to node::user and it contacts the mail protocol listener at that node, which drops the message into the mailbox of that user on that system. > Was DECmail the OSI X.400 email implementation that DEC produced (I think) in > the '90s? Yes, in ALL-IN-ONE and the like. An interesting point is that it was not really accepted as the internal mail tool (except by some corporate overhead departments); engineering persisted in using MAIL-11 based email on the internal network. >> For real strangeness there is the PLATO mail protocol, which involves >> writing the mail into files, which are then extracted from PLATO into the OS >> file system by a periodic batch job, then sent to another system via file >> transfer (FTP or a predecessor), then pushed into the PLATO file system, >> then picked up by a mail agent at that end. Ugh. > > $ReadingList++ You're unlikely to find documentation for this, unfortunately. It's part of the "linked systems" capability of PLATO, a loosely connected collection of systems which could exchange email, notes (as in Lotus Notes, which goes back to a very popular PLATO tool) and, in a very limited way, files. It used very strange custom network hardware originally, and eventually moved to TCP/IP under CDCnet. paul
RE: Box of HP 1000 series MUX cards - 12040
Guy wrote... Wow. Way to make everyone interested in restoring HP 1000 systems (me included) hate you. I'm thrilled that he took the time to post them here before they hit the shredder. Thanks Jesse, much appreciated!
Re: Lots of Apple 1 computers @ VCF West
On Tue, 9 Jul 2019 at 06:04, Fred Cisin via cctalk wrote: > > Be careful about taunting a time traveller. > He might read what you write and it might give him ideas. Oh no! Roko's basilisk! You've wok+++ATH NO CARRIER
Re: Lots of Apple 1 computers @ VCF West
On Mon, 8 Jul 2019 at 18:19, Chuck Guzis via cctalk wrote: > What matters to me is [b]documentation[/b], however it's preserved. I'm > often faced with a bit of old data and I need to know the details upon > which it was fabricated. That has value to me. Al K has been > invaluable in this respect. I collect all the documentation I can find (including my own old notes when I can find them). It's really hard to figure out exactly how something works when documentation is lost and there's nobody around with the knowledge. When I visited Ise shrine in Japan some years ago they were in the middle of building a completely new wooden bridge beside the existing one. They were building new temples as well. Turned out that every twenty years they routinely rebuild *everything*, including the items inside the temples and buildings. Then they tear down the old ones (and use the old material at other sites around the country). And still they claimed that the temples. bridges, items etc. had been there since around 1200 AD. I was a bit baffled about this, but when I had lunch in the nearest town a waiter noticed the foreigner and gave me a booklet to read. It was all explained there. It's simple enough: What they feel as important to preserve is the knowledge about how to build these things. The craftmanship and the artistry. 20 years is just about right - it's enough to hand over the craft to another generation, with overlap. And they've been doing this for hundreds of years. So, what is worth preserving is the *howto*, not the actual old things which would just detoriate more and more over time and eventually disappear. That's just "stuff", and immaterial, as it were. And, as I once witnessed a Viking ship replica going under in bad weather due to something not fully correct in the understanding of exactly how to construct a specific part of the bottom of the ship, I can fully appreciate the thinking. Knowledge gained over hundreds of years in wooden ship building can be lost over a generation or two, even if there's still a parallel tradition of building other types of boats. Which turned out not to be enough to understand how it was done. It can be painfully difficult to recreate, figure out, and document something that's lost, even if you have an old original in bad shape to look at. Which is why they've worked for decades at e.g. Roskilde in Denmark to recreate the knowledge. And the last time I visited that site they still couldn't build as well as the old builders, there was a newly built replica of a small boat where they had a beatifully preserved original nearby - the original still looked better. Give them a decade or two more, and it'll improve I'm sure.
Re: Box of HP 1000 series MUX cards - 12040
On 7/8/2019 6:35 PM, Guy Dunphy via cctalk wrote: At 12:18 PM 8/07/2019 +, jesse cypress-tech.com wrote: If anyone wants 87 HP 1000 series mux cards for gold or to play around with, I'm starting to clean house. The ebay link is below. https://www.ebay.com/itm/383039137321 Wow. Way to make everyone interested in restoring HP 1000 systems (me included) hate you. I actually thought $8 per board wasn't a bad price. If these had been PDP-8 boards, I'd have bought them by now! Vince
