Re: I hate the new mail system
"Alfred M. Szmidt" wrote: > > And for what it is worth, continued bounces. > Alfred, Two of the four ipv4 nameservers for gnu.org are broken. By those odds, I would expect anything up to 50% of any mail you receive via ipv4 to bounce. I gave you some hints in this direction the last time you mentioned you were getting bounces but maybe you didn't see my posting due to your problem with your nameservers? Regards, Peter Coghlan.
Re: Tektronix Terminal Emulation
I can't run DecWindows on a MicroVax II with 11MB of memory, so I loaded the basic support files for DecWindows. Are you sure? I can run the old XUI DecWindows on VMS 5.5-2 (the newest VMS that will support XUI) in monochrome on a VaxStation 2000 with just 6MB. It's not very fast but it works. As far as I recall, it worked in colour when it had a GPX card installed. Regards, Peter Coghlan
Re: Tektronix Terminal Emulation
I'm trying to return to the computing days of yesteryear when people hooked graphics terminals to VAXes. I don't have a Tektronix graphics terminal but I do have a MicroVax II and a laptop running Debian Linux. Up to now I've been using the laptop as a console device and connecting to the Vax using minicom. I thought that the laptop would be a natural as a Tektronix type terminal. I would suggest using a terminal port other than the console port on the VAX to display graphics (and especially for file transfer). I'm not sure about the MicroVax II but on some other VAX and Alpha machines, the console port may be less capable than ordinary terminal ports in the way of buffering, flow control, 8 bit support and so on. Regards, Peter Coghlan.
Re: Pair of Twiggys
> > The whole idea of an "operating system" seems to have morphed into the > notion of a user interface. > > To my way of thinking,t he various flavors of Linux are really a user > interface build on a single operating system. > Has anybody else noticed that the meaning of "portable code" seems to have morphed into "can be built on two or three different flavours of Linux"? > > One thing you can depend upon in this field is the inconstancy of > definitions. > Agreed. Regards, Peter Coghlan
Re: CF cards as storage - wear leveling
I don't think anybody is actually using real CF cards anymore, they are about a decade out of date. Jon Jon, This is the list where we discuss using stuff that's a decade and more out of date. (I've got a large box of real 16MB CF cards that I got for nothing on freecycle that I keep meaning to dream up a use for...) Regards, Peter Coghlan.
RE: Any faithful VT100 Emulators?
> > > From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Warren Toomey via > cctalk [cctalk@classiccmp.org] > Sent: Tuesday, March 21, 2017 9:02 PM > To: cctalk@classiccmp.org > Subject: Any faithful VT100 Emulators? > > OK, so I don't have a real VT100, so I'm accessing an old 4.3BSD system > with xterm and LXTerminal terminal emulators on Linux. Last night, for a > laugh, I ran vttest from the 1980s and the terminal emulators performed > woefully. > > Which raises the question, are there any _good_ VT100 terminal > emulators, especially for Linux? For any other platforms? > > Cheers, Warren > > __ > > I've never formally tested it but people say Putty is very good. I have even > heard VMS users say it works with LSE. ANd then, if you have MSDOS > laying around somewhere there is MSKermit which had to be the best I > ever saw. > > bill I've used Putty to connect to a VMS system to run TPU (which I think LSE is a thinly disguised variant of) and I have regularly come across an irritating bug which messes up full screen editing when the on-screen cursor seems to get out of step with the text that is actually getting changed, or something like that anyway. Scrolling down the file and scrolling back up to the point where changes were made reveals that the changes actually made were not what it looked like was changed on the screen. Having said that Putty is way better than any of the Microsoft telnet or Hyperterminal offerings which are completely unusable with TPU or anything else that attempts to make use of a scrolling region (vi maybe? - I don't know). I haven't used MSKermit for donkeys years but as far as I recall, the emulation was very good with the exception of stuff like double height characters and smooth scroll not being implemented which did not affect functionality in the way that the Putty bug does. I haven't used it but I think there were very good reports about the terminal emulation in Kermit 95. I can't recall noticing any problems with the terminal emulation when using whatever telnet client comes with relatively current Apple Mac and Linux systems in whatever terminal environment they provide (xterm maybe?), nor the Multinet telnet client on VMS when running it in a DECterm or a real VT terminal. I also agree with John Wilson's take on VTTEST being well off the mark. Regards, Peter Coghlan.
Re: Scrounging - was Floating point routines for the 6809
> > Or the time an English co-worker related the story surrounding her > initial job interval in the US. She described the stunned look on the > face of the desk clerk at the local Holiday Inn when she asked to be > knocked up at 7:30 the next morning. > This reminds me of the rather surprised look on my Australian colleague's face when I said I was going to have a root in the cupboard for a missing manual. Regards, Peter Coghlan
Re: Reviving VT220?
> Hi all, > > A colleague and I are trying to get a VT220 working again as it recently > died on us. We are hoping to set up a few items for the mid-80s > (including this terminal) to show the graduands what it would have been > like if they were doing their CompSci degree 30 years ago. > > It looks to me like the flyback is dead. There is a lot of soot and > there looks like there is some damage to the top of the transformer, > better seen in the second image. > > http://www.cs.nott.ac.uk/~psxasj/sparse/flyback1.jpg > http://www.cs.nott.ac.uk/~psxasj/sparse/flyback2.jpg > I think the soot is fairly typical of what accumulates on high voltage components in a city environment. I'm not sure this indicates any damage to it but it may well be faulty without showing any signs of damage. > > The terminal powers on and does the usual beeping but nothing is > displayed on the screen. Does anyone have any advice about what to do > here? Are there any sources of compatible flyback transformers? > I have a VT220 which also appears to have a faulty flyback. This results in it drawing too much current from the power supply. I am not certain the flyback is faulty but I have eliminated most of the other components which are likely to be responsible. I have looked for replacement flybacks or equivelants but I have never found any. Someone mentioned that they might have VT220 parts available on the list some time ago but I didn't get anywhere in following that up. > > We have a second VT220 which exhibits the same behaviour, hopefully for > a different reason so we can try and cobble two into one. > I have a second VT220 which works and I have used it to compare readings with my faulty one. I also tried swapping some of the suspect components but this failed to take suspicion off the flyback. I am reluctant to try swapping the flybacks over in case I cause damage to the working VT220. While the two flybacks appear likely to be electrically similar, I am not certain of this and they are physically different - one is PCB mounted and the other is chassis mounted with flying leads to the PCB as far as I recall. They have different part numbers, 16-21181-01 and 16-26299-01. > > Any thoughts / advice would be greatly appreciated. > Sorry, I haven't been able to provide much help or hope. Regards, Peter Coghlan > > Thanks, > > Aaron. > > > > -- > Aaron Jackson > PhD Student, Computer Vision Laboratory > http://cs.nott.ac.uk/~psxasj
Re: Reviving VT220?
> > Thanks for the information, Peter. It makes me want to try and test a > few of the components around the flyback. > It would also be good to check the stuff like voltages on the base of the CRT and that the CRT heater is glowing. You could have a problem that is nothing to do with the flyback. (I'm assuming the brightness control is turned up). > > Thanks again, > You're welcome. Regards, Peter Coghlan. > > Aaron. >
Re: xv and VMS
> > Is anyone out there using X11 on VMS and the xv image viewer? > Yes. Why do you ask? > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > Still a great sig! Regards, Peter Coghlan
Re: xv and VMS
> > I ask because I've been scraping together patches for xv and collecting > them into a Github repo[1]. I've finished adding all the patches > collected by Greg Roelofs, patches from OpenBSD, and now I'm working on > eliminating unsafe calls like strcpy() and sprintf(). Could I get some of > you VMS people to check out my work and submit any necessary changes? > Great. Thanks for asking. I'll take a look. > > My overall goal here is to clean up assorted bitrot and somehow convince > John Bradley to loosen the license. I believe that I have the most > up-to-date codebase of xv available at the moment. > What's not to like about the license? I've been using using XV for free for over 20 years within the terms of the license. I liked it so much I decided to register and pay up anyway a few years ago even though the license said I could continue to use it for free. > > [1] https://github.com/DavidGriffith/xv > > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > Regards, Peter Coghlan.
Re: DEC terminals and classic server computing
> > The DEC PS/2 keyboards that you could use with the VT510, VT520, VT525 > include the LK450, LK460, and LK461. > My VT510 has an LK411. I don't know if this is what it came with originally but I suspect it is. It works fine with it anyway. Regards, Peter Coghlan.
RE: Line printer art: (was Re: tape baking)
> > > > > If anyone's running Hercules or some other uses-EBCDIC emulator, here's > > the link to the .tap image file. > > > > https://app.box.com/s/8rxbihjjnw5zdkesym4cjwqswekufagh > > > > --Chuck > > Sadly I don't think that's much use on Hercules as it needs an AWS or HET > file. Is there a format converter any where? > I think I recall managing to do that sort of conversion with VTAPECP which is part of something called VTAPEUTILS. It looks like I used version 0.2. Regards, Peter Coghlan.
Re: Ibm rs6000 7025-f50
> > I have a CD still in the original shrink wrap of 5765-393 AIX 4.1.4 > for Clients, LCD4-0114-00. Can't be that hard to find. I have no use > for it myself anymore, got rid of my RS/6000 systems a few years back. > I have a CD which has "5765-393 AIX 4.1.4 for Server for D5 Processors" and "LCD4-0115-00" on the label. I'm not sure where I got it. I think it was in a CD drive that I rescued from a skip (dumpster). There are some light scratches on it but it looks like it should be ok. Is this of any use to anyone? Regards, Peter Coghlan.
RE: DECstation 220. Another Impasse
> > I have looked at this problem a little more. I have two motherboards, > neither of which work, but one at least produces a corrupted video pattern. > The one that works best appears not to be writing to the video memory. When > I look at the EMEM pin on the Paradise PVGA1A chip I can see a signal but > the scope shows a trace that is very faint. When I look at the same pin on > the other motherboard, I get a nice clear bright trace on the scope, using > all the same settings on the scope. This pin is driven by a non-inverting > buffer (74LS126). The input side of the buffer is tied to 0V, the enable > signal comes from a custom gate array. Comparing the buffer's enable signal > on the two boards I see the same dimming effect on the board with the > corrupted video pattern, and no dimming on the other board. > A dim trace suggests that the trace is changing too rapidly to see it properly. Try increasing the scope brightness and sweep rate and adjusting the various triggering options to see if you can get a better trace that reveals what is really happening at that pin. It might be useful to try triggering the scope from whatever clock is used locally as the signal might be synchronised to that. Once you can see the trace properly, it should be easier to figure out where it is coming from. > > I have checked the other pins on both the buffer and the gate array and I > don't see anything suspicious. > It may be worth looking very closely at the power supply pins for difficult to see spikes that might be caused by decoupling failures. It would also be good to make sure ground is really ground at the chips in question. > > I am thinking of speculatively replacing the 74LS126 because I can go and > buy replacement parts for it, I can't replace the gate array (although I > could conceivably swap the part on the two boards). > If the 74LS126 has some fault at it's input which is affecting the signal coming from the gate array, it seems to me that it would be more likely to load it down or up rather than cause it to change rapidly (if that is in fact what it is doing), unless it has somehow managed to turn itself into an oscillator. On the other hand, if the gate array output is open collector, it could be relying on the 74LS126 to provide a collector load and not getting it if the 74LS126 is faulty. This seems unlikely though. I suppose another possibility is that the gate array output could be tristate and not enabled leading to noise pickup from nearby traces and components and perhaps across the PCB surface, given there was a battery leak at some point. Getting back to the oscillator theory, I wonder if it is possible that the non-inverting buffer could be oscillating at a much higher frequency than normally found on the board due to feedback from it's output to it's input as result of the battery leakage? I don't normally like suggesting cutting tracks but if the board already has damaged and repaired tracks, you might feel ok about cutting the track between the gate array and the 74LS126 to determine which of them (or both together) is responsible for the unusual signal there. I would be very wary of replacing the unobtainable gate array with your only replacement until all other possiblities are eliminated in case the gate array was damaged by a fault elsewhere. Looks like I've provided more questions than answers :-( Regards, Peter Coghlan.
Re: Plotter + Tape drive
> > It is SCSI. > Hi Andy, In that case, I am interested too. I am on the East coast of Ireland. I don't suppose you make regular trips to North Wales or anything like that :-) Regards, Peter Coghlan.
Re: HP Draftmaster I, Power Supply repair
> > I think that I'm responsible for the dead, as the plotter stood in an attic > for 20 years, meanwhile power was raised from 220 to 230v (+-10%) in Europe. > The distribution voltage had previously been specified as 220V in some European countries and 240V in others but the specification was then changed to 230V in all the countries involved, with a wider tolerance applied. This allows new equipment to be designed to a common standard which will work in any of the countries. As far as I understand it, there has been no deliberate change in the actual distribution voltage in any individual European country and the power companies continue to do what they did before the 230V standard came in. Regards, Peter Coghlan.
RE: BitNET (Was: RE: RIP Jerry Pournelle - Firsts)
Hi Bill and Dave, I have fond memories of BITNET in a university environment in the early 1990s on VM/CMS and on VAX/VMS. Some years ago, I went searching on the web for information about it and found almost nothing. It was as if it had been erased from history. I did find a single website which contained lots of BITNET user nostalgia but it has since disappeared. I managed to pull some parts of it from archive.org with a view to putting it back together eventually. I have had no success contacting the owner. After a lot of digging, I managed to locate someone who once worked in EARN (the European arm of BITNET) who had a long forgotten backup of the BITNET/EARN network definition files which he was willing to share with me. I haven't quite figured out how to share these with the rest of the world yet as they are full of email addresses, some of which may still be valid. While the original BITNET was NJE over bisync lines, the second generation of BITNET also allowed the use of NJE over TCP/IP while maintaining compatibility with NJE over bisync. The Hercules bi-sync over IP implementation is not suitable for sending over the internet as it produces vast amounts of traffic when idle and cannot cope with latency of more than a couple of seconds nor interruptions of any kind. Neither is it compatible with the NJE over TCP/IP used for BITNET-II. I have written a patch for Hercules which allows it to present what looks like a bisync line on the inside and to speak BITNET-II compatible NJE over TCP/IP on the outside. I have also patched the RSCS that comes with the publically available VM/370 to be able to speak NJE. Like most of my projects, these are very close to completion but hung up on some minor snag near the end. At the moment, this setup is able to communicate over the internet with RSCS on VM/ESA running on a P/390 machine and should be capable of talking to anything else that could have connected to BITNET-II. Software such as MAILER and MAILBOOK still exists in much updated form but will not run on VM/370. I have asked the current maintainers to see if they can dig up very old versions which would be easier to press into service on VM/370 but they have not been successful. The chances of someone finding an old backup are probably diminishing rapidly. The software most commonly used for BITNET on VAX and Alpha VMS is called JNET. A few years ago, I approached the then owner to see if they would license it for hobbyist use in a manner similar to the VMS hobbyist license. Unfortunately they would not. There is some relatively freely available software for NJE on VMS and unix called HUJI-NJE. It is not as capable or polished as JNET but it is workable. I have made some tweaks to this to make it work on modern versions of VAX and Alpha VMS but see note above on completion of projects. HUJI-NJE also inspired a unix-only enhanced version possibly called FUNET-NJE which was used to great effect on EARN/BITNET in Finland. As far as I know, this version is freely available. As far as I recall, there is some confusion over names and versions. Back in the day, I remember BITNET for unix software called UREP. I have no direct experience of it but I recall that interaction with it from other BITNET nodes was pretty awful. I have not managed to find any trace of it in recent years - I think it was probably not free software. It is not necessary for SIMH to support synchronous connections in order to allow NJE over TCP/IP in and out. Regards, Peter Coghlan. Hi Bill, That's a complex topic. Basically, a BitNet connection was an IBM RSCS link..., At the low levels that's BiSync. Real BiSync hardware is rare(ish) but the Hercules Mainframe emulator does support bi-sync over IP so physically its possible. At the networking level, whilst the original RSCS code is available its an early version and its missing key features needed for Bitnet. Also the freely available versions of VM/CMS on which RSCS runs don't have the E-Mail software used to send messages. Later versions that would work are still licenced materials of IBM. I think the same goes for the VAX software. As it could possibly still be used commercially to connect to current mainframes it does not appear to be freely available. I am also not sure how you would connect it to a mainframe, as I don't believe SIMH supports synchronous connections. Dave > -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Bill > Gunshannon via cctalk > Sent: 16 September 2017 01:16 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: BitNET (Was: RE: RIP Jerry Pournelle - Firsts) > > > > > While all this talk of the ARPANet is cool and brings back some fine > memories, what about BitNET? Anyone here remember it? > Any chance someone has a copy of the source for a BitNET Node? > I have seen UUCPNet and DECNet revived. It might be f
Re: H7878 Fails Under Even Moderate Load
> > Can anyone explain the behaviour? > It's hard to know what to do from a distance but here's what I think I'd look at if I was faced with this problem. I think failing under moderate load could be explained by one or more of the following possibilities and probably others I haven't thought of: - The power supply is not capable of producing sufficient current. Check how the voltage across the main input smoothing capacitors which have been replaced varies while the load is applied. If it dips severely, check input components such as filters, surge limiting devices, connectors and so on for breaking down under load. If you can measure the ripple here while changing the load, an increase may indicate that one side of a fullwave rectifier is going high impedance or open circuit under load. Also check for damage that might have occurred in the struggle to remove the capacitors. - Overcurrent sensing is kicking in too soon. Look for low value, moderate to high power resistors in the output current paths and check their values and how the voltage across them varies with applied load. If they seem good, check associated small components. - Regulation is not working correctly. Try to figure out how the regulation is supposed to work and take measurements to see how it is behaving in reality. Easy to say but may be difficult to do in practice. If the PSU uses a chip to provide regulation and drive to a chopper device, the data sheet for the chip may provide some guidance on how it is supposed to work. Be careful taking measurements as accidentally shorting something out could lead to big bangs. - The PSU may be looking for feedback from other parts of the machine in the form of remote voltage sensing or remote current sensing or inputs which cause particular supply lines to be switched on or off or come up in a particular order. If this is the case, the fault may be elsewhere in the machine or may be as result of operating the power supply without it being connected to the rest of the machine. Hope this helps. Regards, Peter Coghlan.
Re: DECstation 5000/240 Thickwire Connector
> > The thickwire connector on my DECstation 5000/240 does not have the sliding > lock on it, instead it has standoffs with threaded screw holes (like any > normal serial/parallel connector). This means that the thickwire adapters I > have won't connect properly because their locking studs are blocked by the > standoffs on the main board connector. I can remove the standoffs I suppose, > but I was just wondering if anyone has ever come across this before? > This is also the case on the VAXStation/MicroVAX 2000 and on the (E?)ISA ethernet card in my Alphaserver 2100. Look for an AUI cable such as the BNE4E-02 which has screws on the right angle male end and a sliding lock on the straight through female end. (I suspect the 02 could mean 2m long.) Regards Peter Coghlan.
RE: The origin of the phrases ATA and IDE [WAS:RE: formatting MFM drives on a IBM PC]
> > That concurs with my observation that SCSI was initially an Apple > > convention. > > I can recall conversations about SASI vs. Apple SCSI. > > And like Fred, I don't believe that it does any such thing. > >Rich Me too. Given how Apple mangled the 50pin SCSI connector into a 25pin one, it is hard to see how they could have been responsible for coming up with it. Regards, Peter Coghlan.
Re: The origin of SCSI [WAS:RE: The origin of the phrases ATA and IDE ]
The biggest problem you had was the requirement to assert ATN when selected properly. Later the tag queuing caused huge headaches as manufacturers implemented that feature. It eventually was made mandatory for the most part by linux, and perhaps Windows requiring the tag queuing drilled own to the lowest level of the system's use of the disk. The capability to do that, or fake it is required to allow the kernel to queue commands to run, and have the OS continue to run till command completion. I recall VMS having issues with SCSI disks which claimed to do tag queueing (and bad block replacement) but didn't do it right, before I'd even heard of linux. Customers complained that VMS refused to work with commodity SCSI disks and thought that it was a conspiracy to get them to buy expensive DEC branded disks. DEC claimed that only the disks with their firmware did tag queueing and bad block replacement correctly. The VMS SCSI driver supposedly had (has?) a list of specific disks known to mess up which it would refuse to bring online. I wasn't well up on Sun but I expect the same issue existed there too. Regards, Peter Coghlan.
Re: Aaron Nabil & pdp-8.org
Jim Stephens wrote: On 10/5/2017 11:28 PM, Vincent Slyngstad via cctalk wrote: From: "Zane Healy via cctalk" Sent: Thursday, October 05, 2017 9:09 PM I'm not sure if Aaron's website was offline prior to the last couple days or not, as I honestly don't remember the last time that I visited, but it's offline now. Aaron once upon a time, used to work for what was a really great ISP, aracnet.com, and that's apparently where his website was still being hosted. Aracnet has vanished under rather suspicious circumstances, and with it, both Aaron's website, and my DEC emulation pages website. I'm not sure what's going on, but Aaron's website seems to be working for me this evening. Vince Not even slightly working for me. pdp8.org entered in a browser times out. There are bits and pieces on archive.org. I tried on a remote system in case there was a problem with the domain local to my house. If the website is something other than the above, that would be my problem. ( I also tried pdp-8.org, times out as well). pdp8.org is registered to Aaron. Time: 12:30am 10/6/2017 PDT thanks jim Same here. I get a "server failed" DNS error when trying to look up pdp8.org. However, one of my ISP's nameservers still has the ip address cached for pdp8.org as 216.99.193.149. The pdp8.org webserver is still active on that ip address, however I cannot display the site in a browser because there are multiple websites on that ip address and the default one is some art gallery rather than pdp8.org. It looks to me that if the domain name hosting is moved elsewhere, the problem should be sorted out. If there is a danger of the webserver going away, putting 216.99.193.149 into a hosts file for pdp8.org (and maybe www.pdp8.org) might allow a browser to find the site. Regards, Peter Coghlan.
Re: DEC Alpha 3000 and OpenVMS 8.4
Douglas Taylor wrote: I'm trying to bring up an Alpha machine, a 3000-300, the hardware is working fine, but I have some questions- The system disk is an RZ26 (1.06GB) and I installed the OS and one layered product and the disk is full. How much disk space is needed for 8.4? I have several of those disks, some in Storageworks bricks. Back in the VMS V7 era, I thought they would be just right for installing a system on and not much else. On more than one occasion, just after I had everything set up on it just the way I wanted it, the disk started clocking errors and shortly after that, it died in clunk-clunk-clunk mode :-( I'd suggest looking for another disk that isn't an RZ26. I also have at least one 4GB disk (RZ28 or RZ29? I can't remember) which works fine once it gets going but needs a tap or a quick twist to get it going when it is trying to spin up. Not too practical for installing in a machine with the cover on though. Regards, Peter Coghlan
Re: tandem computers cartridge tapes
Camiel Vanderhoeven wrote: > >On 10/14/17, 7:55 PM, "cctalk on behalf of steve shumaker via cctalk" > wrote: > > >>On 10/14/2017 10:42 AM, Camiel Vanderhoeven wrote: >>> On 10/14/17, 7:22 PM, "cctalk on behalf of steve shumaker via cctalk" >>> >>>wrote: >>> >>> found as part of the stack saved from an engineers estate: Tandem Computers cartridge tapes and docs Cartridges are appox 4x4x1 and the tape appears to be half inch. Some are in boxes marked "Cartridge Tape CT-130" All have labels indicated they are Tandem Computers "Site Update Tapes" with 1988, 89, and 90 dates. Cursory google produced nothing. Secondary label on one cartridge would seem to indicate they are used for software distribution. >>> Sounds like DLT tapes. >>> >>> >>> >>Similar shape and overall size but the shutter and leader hook are >>different > >The only other format I know of that era that comes close is IBM 3480, but >that¹s less square, more like 5² x 4². Do you have pictures online >somewhere? > I have an autoloader SCSI tape drive and two sample tapes which I am told came from a Tandem system. The label on one of the tapes says: "3M Royal Guard tm 1/2" tape cartridge 3480 compatible" Regards, Peter Coghlan.
Re: First Internet message and ...
Rich wrote: Chuck, I don't know anything about this system. I don't consider Minis and MainFrames to be Personal Computers. It must fit in a small room, run on a 120VAC 5Amp service, and not require 3 tons of AC to keep it cool to fit in to the Personal Computer definition. GOD Bless and Thanks, rich! Well, I don't regard it as a Personal Computer if I have to lug around a 2:1ish voltage stepdown transformer along with it in order to power it. Regards, Peter Coghlan.
Re: P112
On 2019/11/30 23:32:55 -0800, jim stephens via cctalk wrote: On 11/30/2019 9:45 PM, Eric Dittman via cctalk wrote: On 11/30/2019 8:34 PM, jim stephens via cctalk wrote: [snip] Links.txt [snip] http://www.classiccmp.org/dunfield/img/index.htm Daves Old Computers - Disk/Software Images. Boot disks for lots of different vintage computers are here. It's not nearly the size of Don Maslin's lost archive, but it's a start. I don't keep up with CP/M etc but I thought I recall it being announced that Don Maslin's lost archive had been recovered? Regards, Peter Coghlan.
Re: Tap, tap, tap, is this working???
Allison wrote: > > I believe there is a someone or something that is subscribed to the list > and scrape it for active > names. and emails. I have no idea what the specific how it is done but it > is a trivial coding > task to extract emails for sale as known active. It was not coming though > the list but from > bots most likely and used list members names to obscure being > spam/uce//malware. > IT would nto take much to create a subscription and have that go to some > automation > to capture information. The question is how many listen only members are > there that > have never ever posted a comment? > That is bizarre. I've used the address used to post this message only for this mailing list for donkeys years now and it has received very close to zero spam. The most recent spam I received arrived on 24th May 2019. Regards, Peter Coghlan
Re: Tap, tap, tap, is this working???
Allison wrote: > > It may be that my address got into the local address book of a contaminated > system but stopping this net for several weeks brought > the spam and trash mail from 25-80 a day to zero near instantly (less than > 12 hours.).I've bailed from the list in the past for periods > for the same reason. I cannot filter the spam due to multiple reasons. > > Its not bizarre as people do want valid addresses for scams and > legit offers for crap I do not want. > What is bizarre is that one email address that posts to the list is getting lots of spam and another email address that also posts to the list is not. What is also bizarre is that your spam stops when you unsubscribe from the list (if that is what you mean by "stopping this net" and "bailed from the list" above). In my experience, once a spammer finds an email address, they don't bother to check whether the address is still active any time they want to send spam to it. They just keep on sending irregardless. > > It is my belief that we have a user that is farming the list and getting > though spam filters. > I think you are jumping to conclusions here. In my experience, spammers are very lazy people and they are just not willing to put in that sort of effort. Unless the spams you are getting are very specifically designed for you, I would discount this theory. > > If you do not. then great. I've been active here for a very long time > (since I was on WSTD.COM). > I'm a mere blow in that hasn't been here more than 25 years. I worked for an email provider for 15 years and for the first 5 years of that, email spam didn't really exist (unless you count the "call for papers" type of academic spam). After that, I put a lot of work into understanding spam and preventing it from getting to or from our customers. > > It has been a persistent problem that always starts small and grows quickly > and then I start filtering > till I'm killing good mail. > It is really really difficult to come up with a useful filtering system that can recognise and stop spam without stopping good mail too. The only ones I use are DNS based lists of ip addresses which are known sources of spam, such as those operated by Spamhaus. I also use my own homegrown ip lists. This approach works for me because I have my own mail server. If you are stuck with using a commercial email provider, you are stuck with what they are using. Many commercial providers won't even reveal what they are using. As for the free email providers, forget it. The ip address based filtering I use stopped just one spam going to my cctalk mailbox since April 2019 (there was a spate of it in April). Filtering is never a complete solution. The best way to avoid spam is to avoid having email addresses harvested but this is not always possible when people we correspond with unwittingly get their machines compromised. Another thing I believe makes a difference is to complain about every single spam received to the ip provider of the spammer or the compromised machine used to send the spam. Nobody else I know is willing to put the effort into doing this though. However, nobody else I know has as good a legitimate mail to spam mail ratio as I do either. (Obviously this approach can not help when already getting too much spam to cope with.) Regards, Peter Coghlan.
Re: Tap, tap, tap, is this working???
Allison wrote: > > I wonder of all the subscriber how many have posted something or anything > in > the last 6 month, year, ever? I suspect the never cases. > I've made about thirty postings to this list so far this year from this mailbox. If your theory is correct, I should be getting a whole bunch of spam now. I've received two spams (I found one that I missed earlier) and had one other spam filtered going to this mailbox since April 2019. Do you believe a non-posting subscriber could be targetting your email address with spam and not mine? > > Short term solution is use Gmail then run for a while and then kill it or > leave it to > as a bit bucket and replace with new Gmail. > Google sends legitimate mails (I don't send any other kind) from another email addresses of mine directly to the junk folders of (as far as I can tell, all) gmail recipients. These are people who have emailed me from their gmail addresses that I am replying to, people I have had correspondance with previously and people who have specified to Google that they want emails from me. I have asked such people to let me know why Google regards emails from the email address in question as spam so that I can address the problem in the event that it is at my end. Nobody so far has been able to extract this information from Google. I tell them that I don't understand why anyone uses an email service that systematically blocks them from receiving emails from particular email addresses and refuses to explain to them why they do it. I also keep telling them that gmail is worth every penny they pay for it but they just don't get it. At one time Google used to publish recommendations to avoid having emails inadvertently stopped by their antispam systems. At that time, I made sure that my mail server complied with all their recommendations. I've since tried to contact Google to ask them about this but I've had no success. Why should they talk to me if I'm not their customer? Especially when they won't even tell their actual customers why they are trapping emails for them? Google is not the solution, it's part of the problem. Regards, Peter Coghlan.
Re: Two dead LK201 keyboards
Paul Koning wrote: > > Gentlepeople, > > I'm doing some work with my Pro 380 over the holidays, but have run into a > snag because both my LK201 keyboards are dead. They fail poweron self test > -- LEDs stay on and no response to any keypresses. > > The odd thing is that the circuit board itself seems ok; I had a spare board > that tests fine by itself, so I installed it as a replacement control board > on one of those keyboards and now it fails. So that suggests there's > something wrong with the key array that breaks selftest. > > I don't understand that because the documentation says a stuck key would > produce a selftest pass along with an indication reporting stuck key. And > while I know LK201 keyboards don't like spilled liquids, one of those > keyboards definitely hasn't been abused that way and I don't see signs the > other one has, either. So having both fail the same way is puzzling. > > Any ideas? > I wonder what happens if several keys are stuck/shorted? It might also be good to check if the microprocessor (8051?) is running. (I've got at least two or three LK201 keyboards that are all acting erratically :-( I'm not sure I have any good ones left.) > > I'm considering building a PC keyboard LK201 emulation, should be a fairly > simple bit of Arduino code. > Supplies of good non-USB PC keyboards are probably beginning to get harder to find now too... Regards, Peter Coghlan.
Re: IBM BSC CRC?
Mattis Lind wrote: > > Hello IBM BSC Experts! > > I am trying to figure out the CRC algorithm used by IBM BSC. I have tried a > lot of different settings in crcreveng but not getting a match. > I'm definately not an IBM BSC Expert and I don't even play one on TV. I have tweaked some BSC emulation code written by someone else so I have some vague idea about this stuff, however, the emulation did not include CRCs so I'm not sure how much help I can be. > > I am pretty convinced that the CRC-16 used by IBM was > 16 15 2 > x + x + x + 1 > In the file bcb_crc.c supplied with the funetnje and HUJI-NJE packages, it says the following (which may or may not relate to CRCs in the BSC world): | The generating polynomial is X^16+X^15+X^2+1 (CRC-16). When computing the | CRC, DLE's are not computed (except from a second DLE in a sequence of | 2 DLE's). Furthermore, the first DLE+ETB which starts a text block is | not computed also. There is also some code for checking CRCs, however, it is not clear to me if this code is for use with BSC lines or with DECnet lines. > > This would give the polynomial 8005. > Anyone against this statement? > > But what was the initial value? > > I have two actual messages from equipment employing IBM BSC: > 32016CD90240404070032688 > and > 32016CD90240C84050030D28 > These appear to be something like: SYN SOH '%' 'R' STX SP SP SP ACK0 ETX followed by CRC-16 and SYN SOH '%' 'R' STX SP 'H' SP '&' ETX followed by CRC-16 > From this document ( > http://bitsavers.trailing-edge.com/pdf/ibm/datacomm/GA27-3004-2_General_Information_Binary_Synchronous_Communications_Oct70.pdf > ) > I get that the CRC calculation is reset on SOH (01h) or STX (02h) and > accumulates until and including the ETX (03h). (excluding any SYN (32h) > characters). > On page 17, it seems to suggest that the CRC calculation is not reset by STX when the STX follows SOH, which it does in the above cases. > > I have tried crcreveng back and forth and I am not getting the CRC bytes > right. > I think I have tried most things, different bit order, different initial > values. But nothing. > > I also tried the mode in crcreveng where it searches for matches but it > always says "no models found". Maybe I am doing something wrong when using > crcreveng? > > Any clues? Surely there are someone out there that has been around for some > time and knows this, right? > On page 8, it says: "SOH% is presently used to identify request-for-test or station-dependent control messages." - could this be significant? What produced the the two sequences you quoted above and do you know what those messages mean? Is it possible that the CRC included with them is deliberately wrong? Regards, Peter Coghlan.
Re: IBM BSC CRC?
Mattis Lind wrote: > > Hello Peter! > > Thanks for the effort to help! > > I maybe should elaborate a bit on what I am doing and what equipment is > involved. The sending equipment is a Alfaskop CPR4101 communication > processor. Basically IBM 3274 model C BSC compatible. There is some > description on how it communicates using BSC from page 89 and onwards in > this pdf: > http://storage.datormuseum.se/u/96935524/Datormusuem/Alfaskop/Alfaskop_System_41_Reference_Manual_IBM3270_Emulation.pdf > > Essentially what is written there is very similar to what IBM has written > in > http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/3274/GA23-0061-1_3274_Control_Unit_Description_and_Programmers_Guide_Jan84.pdf > on > page 159 and onwards. > I was hoping it was an RJE or NJE implementation rather than a terminal as I am more familiar with that side of things and I would have a good chance of being able to recognise valid data from invalid data. [snip] > > > > In the file bcb_crc.c supplied with the funetnje and HUJI-NJE packages, it > > says the following (which may or may not relate to CRCs in the BSC world): > > > > > Thanks! Interesting. Checked this CRC generator and it creates exactly the > same CRC bytes compared to the other CRC implementations I have found > around on the net. But not matching the bytes received. > > > > | The generating polynomial is X^16+X^15+X^2+1 (CRC-16). When computing > > the > > | CRC, DLE's are not computed (except from a second DLE in a sequence of > > | 2 DLE's). Furthermore, the first DLE+ETB which starts a text block is > > | not computed also. > > > > There is also some code for checking CRCs, however, it is not clear to me > > if this code is for use with BSC lines or with DECnet lines. > > > > > Cannot really understand what bcb is and what has to do with it. Is the > protocol some kind of BSC derivative with extra features. Don't really > understand it when glancing quickly through the code. > Ignore the bcb stuff - this is part of RJE/NJE protocol. (It is a bit strange that it is included in the same file as the crc code despite belonging to a quite different protocol layer.) > > > > > > > I have two actual messages from equipment employing IBM BSC: > > > 32016CD90240404070032688 > > > and > > > 32016CD90240C84050030D28 > > > > > > > These appear to be something like: > > > > SYN SOH '%' 'R' STX SP SP SP ACK0 ETX followed by CRC-16 > > > > and > > > > SYN SOH '%' 'R' STX SP 'H' SP '&' ETX followed by CRC-16 > > > Absolutely right! > I'm a bit puzzled by the ACK0 appearing inside an (apparantly non-transparant) text block and not having a DLE ahead of it but I am not really sure if this would be a problem. Most of the rest of the data looks very plausable with SYN, SOH, STX and ETX appearing in the expected places. However, if there could be a subtle error in the hardware being used to read the data, getting just one bit wrong would throw the crc right off. Maybe the terminal manual contains enough information to confirm or deny whether the poll responses are exactly as expected or not? [snip] > > One of my concerns is my complete inability to get the same CRC digits from > crc reveng compared with the three C crc algorithms I found on the > internet. I just have to do something wrong when fiddling with the options. > But what? I think I have tried bit order, inverting the bits etc. But still > nothing. > > Are there any crc reveng experts out there?? > Hopefully someone else can help with this. Regards, Peter Coghlan.
Re: IBM BSC CRC?
Mattis Lind wrote:
>
> > > I have two actual messages from equipment employing IBM BSC:
> > > 32016CD90240404070032688
> > > and
> > > 32016CD90240C84050030D28
>�> >
>
How about this code:
#include
int crc16(unsigned char *ptr, int count)
{
unsigned int crc;
char i;
crc = 0x;
while (--count >= 0)
{
crc = crc ^ (unsigned int) *ptr++;
i = 8;
do
{
if (crc & 0x0001)
crc = (crc >> 1) ^ 0xA001; /* 0x8005 bit reversed */
else
crc = (crc >> 1);
} while(--i);
}
return (crc);
}
void main()
{
/* 32 01 6C D9 02 40 40 40 70 03 26 88 */
unsigned char data1[] = {0x6c, 0xd9, 0x02, 0x40, 0x40, 0x40, 0x50, 0x03};
/* 32 01 6C D9 02 40 C8 40 50 03 0D 28 */
unsigned char data2[] = {0x6c, 0xd9, 0x02, 0x40, 0xc8, 0x40, 0x50, 0x03};
printf("crc sent: 8826 computed: %4.4x\n", crc16(data1, sizeof(data1)));
printf("crc sent: 280d computed: %4.4x\n", crc16(data2, sizeof(data2)));
return;
}
Please note that I had to cheat to get this to work. It worked initially
for the second case but it only worked for the first case when I tweaked
70 to 50, ie I substituted the corresponding value from the second case.
Regards,
Peter Coghlan.
H7821 power supply in MicroVAX 3100, SCSI disk enclosures and others
The recent discussion on BSC protocol prompted me to dig out my Microvax 3100 with DSH32 synchronous serial interface. It had been idle in storage for several years and it wouldn't power up, only giving a brief flash on the diagnostic LEDs and a quick twitch of the fans. There was a slight smell, like the stale air that comes out of a deflating tyre. I took out the H7821 power supply and found that five identical brown 1800uF 25V electrolytic capacitors on the output side had leaked. The SCSI disk enclosure where the machine's system disk lives required several power cycles to get it to run at all and it died as soon as the disk tried to spin up. It turned out to also contain a H7821 power supply which had a similar issue with the same five brown capacitors, although not as extensive as in the main unit. I found a second disk enclosure which had seen little use and grabbed the power supply out of that to put in the MicroVAX. It worked well enough to test with but there was a ring of goo around the bottom of one of the brown capacitors which was worst affected in the other units. Time to order a batch of replacement capacitors and figure out what else has been damaged. While it is not the worst I have seen, access to these power supplies for repairs is quite difficult and it is really difficult to debug them safely while they are running with the cover off :-( If anyone has anything with H7821 power supplies in them, I suggest checking on these capacitors. If anything with these power supplies is in storage, I suggest ensuring it is stored the normal way up as this should limit the ability of the goo to escape and spread around the power supply. And there I was thought I was being safe enough by removing the nicad battery packs some years ago... Regards, Peter Coghlan.
Re: Opening a MicroVAX 2000
Antonio Carlini wrote: > [snip] > > One more screw and a few further connectors later and I can slide the > memory board (?) sideways enough to unclip the battery. > > > It has started to leak but it seems to only have affected the nearby > metalwork: a bit of cleaning with vinegar should clear that up. I have > to check more carefully, but so far it looks like I've been quite lucky. > Beware electrolyte wicking along the battery leads and reaching the board that way. I have had damage done to some of the tiny tracks in the area of the serial ports which may have been caused by this. Check carefully around the area where the battery connector plugs into the board. > > So, once I've cleaned it up, I need to test it the PSU before I hook it > up to the rest of the system. Any ideas on that front? > VAXStation/MicroVAX 2000 machines which do not have a disk have instead a little load board with several resistors mounted on it which the power connector for the disk is plugged into. I think I came across a similar load board in a TK50 drive or something like that. If you can find one of these boards, it makes a great dummy load for testing the PSU. If not, how about a 6V and a 12V headlight bulb? Regards, Peter Coghlan. > > Thanks again, > > > Antonio > > > -- > Antonio Carlini > anto...@acarlini.com >
Re: Split Ceramic Disk Capacitor
> > Since I am forced to stay at home more than I would like I though I would > check some more PSUs. One I wanted to check was the H7109-C from one of my > VAXstation 4000 VLC machines. I found a leaked capacitor and some other high > ESR ones, so I will replace those. However, I also noticed a ceramic disk > capacitor that appears to be split all around the edge. Is that a known > failure mode? > Is it definately a capacitor? I've had some damaged surge arrestors / MOVs / VDRs that look very similar to ceramic disc capacitors. Regards, Peter Coghlan.
Re: Weird Behaviour of VAXstation 4000 Model 60 Power Switch
> > This machine acts oddly. After powering it off, you usually can't power it > back on again for about 30 seconds or so, it just seems to ignore the power > switch. Similarly, if it has been switched off at the front power switch, it > will switch itself on after maybe a minute of two of being switched off. In > all other respects the machine seems fine. I have not opened up the PSU at > all, just wondering if anyone has ever seen this and might know what the > problem is? > Not quite the same thing but I have noticed that many DEC power supplies will sulk for a while if their overload trip is triggered. Switching them off and on again straight away is not enough to reset them even though the overload is cleared. The H7821 seems to need to be switched off for around 16 seconds minimum before it will contemplate coming to life again. I have come across similar behaviour with the power supplies in various other small VAX and Alpha machines but I have not measured the exact time period involved in any other cases. Regards, Peter Coghlan.
Re: VAXmate PSU fixed, but no video
> > Some of you may recall seeing me post about the VAXmate PSU failure. Thanks > to members of this list I found the failed part in the PSU and the PSU is > now working again. However, it looks like the PSU failed because of a > failure on the monitor board. There is a burning smell coming from it, > possibly the flyback transformer, but I am not 100% sure. I don't see > physical damage, but of course that doesn't mean there isn't a problem. When > I took the monitor board out again after this, I wasn't sure if the EHT lead > was making good contact with the CRT anode. The monitor board is described > in section 4.4 of this document: > http://bitsavers.org/pdf/dec/vaxmate/EK-PC500-TD_VAXmate_Technical_Descripti > on_1987.pdf > Congratulations on getting your PSU failure sorted out. I suppose you realise this means there will be a line of people wanting you to look at our PSU problems the next time we meet up :-) > > I need some advice on diagnosing the problem, I have a few questions: > > 1.If the EHT lead was not properly connected to the CRT anode, could > that cause problems? > Possibly. I have VT220 terminal which was making a smell of ozone when it was running which I should have done something about but never got around to. This could have been due to corona discharge around the CRT anode connection or around the flyback transformer but I never found out. Eventually, it stopped working, drawing excess current from the 12V power supply. The flyback transformer appears to have been damaged. > > 2.Is there anything I can safely do with a bench power supply to > isolate the problem? > 3.Any other suggestions for diagnosing the problem? > One approach to testing flyback transformers seems to be to use a circuit that causes them to ring and observing whether the ringing is damped by shorted turns. I've never got around to trying this myself. > > 4.There is an outline spec of the flyback transformer in the section > 4.4.3.2 of the VAXmate technical description, what chance of finding a > "modern" replacement? > I wish you good luck with this. I never had any luck locating one for my VT220 :-( Regards, Peter Coghlan. > > I have posted about the PSU repair here: > > > > https://robs-old-computers.com/2020/04/18/vaxmate-h7270-psu-fixed-but-no-video/ > > > > Thanks > > > > Rob > >
Re: Another Unrelated PSU Question
> > I have another PSU I have been meaning to look at for a long time. This one > has fairly high output ripple and some of the voltages do not appear to be > where they should be. I have checked all the capacitors for ESR and they > appear to be OK, with the exception of the two big smoothing capacitors on > the primary side. One of them appears to be slightly bulging, but has > low-ish ESR, the other has a much higher ESR. Is it possible that these > capacitors could be the cause of the out-of-spec outputs? > In my experience, the next step after bulging is either leaking and a sticky mess on whatever is underneath or a big bang and sticky mess everywhere. I'd get rid of the bulging one even if it seems otherwise good, epecially if leaving it powered for anything other than very short periods. It will probably heat up over time and build more pressure. The high ESR capacitor can't really be contributing much to smoothing so I think it needs to be replaced before any further investigating can be done. With any luck, that might sort out all the issues but even if it doesn't, it would have to have been eliminated anyway. Regards, Peter Coghlan > > Thanks > > > > Rob >
Re: VAXmate PSU fixed, but no video
> > There were two VT220 designs (I think), using either an onboard or > offboard flyback. The part number of the onboard flyback is 16-26299-01, > and there are some available on eBay if you are feeling rich. > I don't want to hijack Rob's thread too much :-) I actually have one of each design and the one with the offboard transformer (I think) works. The board layouts are different but the components seem to be the same. It is hard to be sure whether the only differences between the transformers relate to their mounting arrangements. I tried swapped some of the HV components back and forth between them to eliminate them from suspicion. I didn't dare try swapping the transformers in case they are not electrically identical and because I didn't want a fault elsewhere in the bad terminal damaging what is probably my only good transformer. I have the part number for the other type of transformer somewhere but I can't locate it right now... Regards, Peter Coghlan > > Cheers, > Aaron >
Re: Replacing Power LED on MicroVAX 3100/95 Power Supply
Rob Jarratt wrote: > > In fixing my PSU I managed to break the leads to the LED on the front of the > PSU, probably through metal fatigue. > > > > I seem to remember people saying it is quite difficult to replace these, > mainly because you can't get them out without breaking the holder. Is that > right? Has anyone done this successfully and have any tips? > > Is this the green LED in a H7821 PSU? I managed to get one out of the holder with a bit of difficulty before I realised I could have left it in place and the board can just about get past it when the plug at the far end of the leads feeding it is plugged out from the board. As far as I recall, the holder is in two parts and I think the two parts have to be separated before the LED will come out of the holder or the holder will come out of the hole it is mounted in. > > Are there any recommendations for a replacement? If I remember correctly the > LEDs used in those days were not as bright as modern ones and a modern one > would end up being much brighter because of the higher voltage maybe? > > Maybe it would be possible to tack blobs of solder onto what's left of the leads on the original and use them to attach fine leads, digging out a small amount of the LED casing around the leads if necessary? Regards, Peter Coghlan. > > Thanks > > > > Rob >
Re: LK201 emulation
Paul Koning wrote: > > Gentlepeople, > > I've been having problems with broken LK201s, so as a workaround I created > an adapter that connects to a standard PC USB keyboard and makes it look > like an LK201. It's based on an Arduino (specifically, Adafruit Trinket M0, > an amazingly tiny yet powerful small microprocessor). > > It's working at this point, though it needs a few small software tweaks to > make it complete. I'm going to turn my breadboard into something slightly > more polished. > > Question to the list: is this something that would be of interest to others? > If yes, I can make the design available. Perhaps the PCB layout and parts > list. I don't think I want to get into building units for others, though. > I also find myself with several flakey LK201s. To be honest, I wouldn't be interested in replacing them with PC keyboards. I'd prefer to get my LK201s back in action. If the issues are in the keyswitches or the flexi-print stuff connecting them to the electronics, it looks like it will be nearly impossible to do anything with them. However, if it turns out that the issues are in the electronics part of the keyboard and they are not easily repairable for one reason or another, I may be interested in a drop in replacement for the original electronics. I've opened up one of mine just now and extracted the PCB. There are eight 10 microfarad axial electrolytic capacitors on it. Each of them has some green salty corrosion deposits on one or both of their leads while the leads on the other components are bright and shiney. If I had spares available, I would try replacing these components and see if it makes a difference. I unsoldered them anyway in case they cause damage to the PCB. Most of them measured ok on the capacitance range on my multimeter but one of them reads only 3.5 microfarads. Regards, Peter Coghlan. > paul >
Re: LK201 emulation
Paul Koning wrote: >> On May 18, 2020, at 9:09 AM, Peter Coghlan via cctalk >> wrote: >> >> ... >> I also find myself with several flakey LK201s. >> >> To be honest, I wouldn't be interested in replacing them with PC keyboards. >> I'd prefer to get my LK201s back in action. >> >> If the issues are in the keyswitches or the flexi-print stuff connecting them >> to the electronics, it looks like it will be nearly impossible to do anything >> with them. > > Yes, and that is the case with mine. I know from years past that those > switches are vulnerable to contamination. > I fear it may be the same with mine. Most of mine seem to behave as if keys are intermittently stuck down but no amount of tapping, shaking etc seems to help. > >> However, if it turns out that the issues are in the electronics part of the >> keyboard and they are not easily repairable for one reason or another, I may >> be interested in a drop in replacement for the original electronics. > > Since that wasn't my scenario I haven't tried to do that. It seems easy > enough. The main issue is that you need a controller with enough I/O lines > to run the scan. A BeagleBone would be ample; an Arduino might not be. > Fair enough. Sorry for the digression. Regards, Peter Coghlan. > paul >
Re: history is hard
On Sun, 24 May 2020 at 13:20:41 -0600, Warner Losh wrote: > On Sun, May 24, 2020, 11:04 AM Toby Thain via cctalk > wrote: > >> On 2020-05-24 11:17 AM, Bill Gunshannon via cctalk wrote: >> > ... IBM was doing >> > Virtualization in the 70's. >> >> 1968 and probably before.[1] >> >> Most operating systems concepts[2] are much older than people think. >> > > The topic for my talk next week. Unix had virtualization in 74. The second > Unix port ran under OS/360's VM in 78. > What do you mean by "Unix had virtualization"? Come to think of it, what do you mean by "OS/360's VM"? Regards, Peter Coghlan > > Warner > > > --T >> >> [1] https://en.wikipedia.org/wiki/History_of_CP/CMS >> [2] e.g. ref: Per Brinch Hansen, Classic Operating Systems >> >> > >> > bill >> > >> >>
Re: history is hard
On Sun, 24 May 2020 at 15:18:34 -0600, Warner Losh wrote: >> >> > >> > The topic for my talk next week. Unix had virtualization in 74. The >> second >> > Unix port ran under OS/360's VM in 78. >> > >> >> What do you mean by "Unix had virtualization"? >> > > I mean that 4th edition UNIX ran under a hypervisor in MERT in 74 as a > process in that real-time executive. > Oh. I thought maybe you meant Unix was able to do virtualization. What's special about being able to run under a hypervisor? If the hypervisor does it's job right, whatever is running under it should not be aware that it is not running directly on hardware. > >> Come to think of it, what do you mean by "OS/360's VM"? >> > > IBM's standard VM/360. Sorry for the confusion. > CP/67 or something like that maybe? I don't think there was a VM/360 either. Regards, Peter Coghlan. > > That will teach me to reply on my phone... > > Warner > > >> Regards, >> Peter Coghlan >>
Re: history is hard
On Sun, 24 May 2020 at 19:24:31 -0400, Bill Gunshannon wrote: On 5/24/20 5:30 PM, Peter Coghlan via cctalk wrote: CP/67 or something like that maybe? I don't think there was a VM/360 either. There was VM/370 in 1980. I worked under it from May to August. Hosted on a 4331 at Ft. Ben Harrison, IN. The launch of the Mainframe and COBOL facet of my career and life. A variant of VM/370 Release 6 is running here in front of me under Hercules running on VMS on a DEC Alphaserver 800 from 20+ years ago. I used to think that was a bit special but now one of the other guys whose system is on an NJE network with mine is running VM/370 under Hercules on a mobile phone. Many of the source file dates in VM/370 Release 6 are in 1978. Some might say that Release 6 was the "last" VM/370 but that word is just as difficult to pin down as "first" and the devil is in the detail. Release 6 seems to be the last freely available release of VM/370 though. There were one or two more updates for VM/370 but I think those were charged-for software and just after that the name was changed. If I have the sequence right, it went through a succession, of being called VM/SP, VM/XA, VM/ESA and is known today as z/VM. Under the covers though, it's all the same stuff as VM/370 and it looks like VM/370 wasn't even the original name for it. Regards, Peter Coghlan. bill
RE: history is hard
On Mon, 25 May 2020 at 09:49:08 +0100, Dave Wade wrote: > > In these systems the end user operating system, CMS, would also IPL (load) > on bare hardware. > I wouldn't regard CMS as being the definitive end user operating system. Often, the reason for having VM is not to support multiple instances of CMS. The end user operating system can be anything that can be ipled in a virtual machine which is pretty much anything that can be ipled on the real hardware (except for CMS of course which can be an end user operating system without complying with this rule). > > I would disagree with Peter over the "same under the covers". > Yes, that was the wrong way to put it. I was trying to say that these variously named entities produced over many decades all do pretty much the same thing and have a common ancestry. Perhaps something like they "deliver the same functionality" would have been better? > > > Regards, > > Peter Coghlan. > > > > Dave > Regards, Peter Coghlan. > > > > > > bill > > >
Re: Duplicate messages
> Hi! > > Anyone else getting duplicate messages from this list? I get 2 copies of > most (but not all) messages, with the second copy often arriving > significantly later. > > Julf > In my experience, the only way to avoid duplicates under the current setup is to subscribe to the cctalk view of the list and to have everyone post only to cctalk. I think many others have worked this out too because very few of us post to cctech now. Regards, Peter Coghlan.
RE: Future of cctalk/cctech
ED SHARPE wrote: > Use modern email program that sees expanded char. Sets and graphics it > is a brand new world ! I love old hardware to look at but if > communicating I like the ability to see graphical things... and I > think tell majority of people like images of things.. Ed# > Let me get this straight. If I stop using VMS MAIL for this list and use one of these new fangled things instead, I too will be able to make high quality postings to the list, just like this one??? Regards, Peter Coghlan > > On Wednesday, June 17, 2020 Fred Cisin via cctalk cctalk@classiccmp.org> wrote: > On Wed, 17 Jun 2020, ED SHARPE @ AOHell.com via cctalk wrote: > > These 2 have my vote as well > > I do not know, anyone using a text only mail reader anymore! > > > >> The one thing I would change here is removal of the restriction on > >> attachments. > >> Well, two things.. Getting rid of the cctalk/cctech split as well. > > I read this list on PINE, on a shell account at my ISP. > > In this group, I doubt that I am the only one. > > > Can we restrict to TEXT emails? > > -- > Grumpy Ol' Fred ci...@xenosoft.com >
Re: Future of cctalk/cctech - text encoding
Christian Corti wrote: On Wed, 17 Jun 2020, ben wrote: > Does this mailing list have people using EBCDIC for example? Yes, if for example I use Kermit on the IBM 5110 and connect to a UNIX host. ;-) But in this case, my Kermit is doing the translation between ASCII and EBCDIC. Does anyone use ASCII anymore? Most of the emails I get now are marked as utf-8 with the occasional iso-8859-1. Regards, Peter Coghlan. Christian
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Dave Wade wrote: > > > -Original Message- > > From: cctalk On Behalf Of Peter Coghlan > > via cctalk > > Sent: 18 June 2020 08:22 > > To: General Discussion: On-Topic and Off-Topic Posts > > > > Subject: RE: Future of cctalk/cctech > > > > ED SHARPE wrote: > > > Use modern email program that sees expanded char. Sets and > > > graphics it is a brand new world !I love old hardware to look > > > at but if communicating I like the ability to see graphical > > > things... and I think tell majority of people like images of > > > things.. Ed# > > > > > > > Just beware. Some environments, especially old EBCDIC ones put different > currency symbols on the same code points > So:- > > I wrote this as one dollar => $1.00 > This as one pound => $1 > And this as one euro => €1 > Lastly one cent => ¢1 > > I expect you all get that as sent except for perhaps the Euro which didn't > exist when Peters VAX was built > ... but on an old UK EBCDIC mainframe Dollar becomes Pound and Cent becomes > dollar. This was a real pain as a UK user of Bitnet. Well, Peter reads cctalk using VMS MAIL on his alphas and this has it's own problems. Around VMS 8.something, someone had the bright idea that VMS MAIL should replace certain "unusual" characters (such as the tilde for example) with (you guessed it) a dollar sign rather than present them directly to the reader for some unknown reason... However, Peter uses PMDF MAIL to post to the list because it has been pointed out to him that VMS MAIL doesn't do References: and In-Reply-To: headers correctly. On that note, has anyone heard from Mouse? I haven't seen anything posted by him in a very long time now. To get somewhere near back on topic, I am trying to set up a synchronous serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) interfaces. One of the options I have is a BC19D cable and a BC19V cable which seem to be identical or nearly identical. Each plugs into a DSH32 at one end and has a V.24 DB25 connector at the other end. I don't seem to have anything available in the way of a pair of suitably similar modems or a modem eliminator to put between the two V.24 connectors. Can anyone suggest some kind of a quick hardware hack that I could use to fill the gap? Is a pair of DB25 sockets with crossed over wiring betweeen them sufficient or do I need something that generates clock signals too? Regards, Peter Coghlan. > Dave
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Antonio Carlini wrote: On 18/06/2020 10:06, Peter Coghlan via cctalk wrote: > > To get somewhere near back on topic, I am trying to set up a synchronous > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > interfaces. One of the options I have is a BC19D cable and a BC19V cable > which seem to be identical or nearly identical. Each plugs into a DSH32 > at one end and has a V.24 DB25 connector at the other end. I don't seem > to have anything available in the way of a pair of suitably similar modems > or a modem eliminator to put between the two V.24 connectors. Can anyone > suggest some kind of a quick hardware hack that I could use to fill the > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > sufficient or do I need something that generates clock signals too? > I can't find my DHS32/DST32 docs right now but it's probably a simple re-spin of the DSH32. I think that the DST32 was the uVAX2000 option and the DSH32 was for the uVAX 3100 series. My notes say that my MicroVAX 2000 has a DST32 (54-17230) but the preliminary version of EK-283AA-AD-001 is for the DSH32 and that talks about the MicroVAX 2000! Thanks for your reply Antonio. I have found the whole thing very confusing too. My suspicion was also that they were pretty much the same thing but the DST32 had exernal connectors suitable for mounting in a MicroVAX 2000 while the DST32 had external connectors that could be mounted in a MicroVAX 3100. That is, until I also came across the preliminary version of EK-283AA-AD-001 which threw cold water on that theory. Unless it was originally called the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something... The console code in one of my MicroVAX 3100 machines shows this: test 50 KA41-D V1.0 [snip] DSH32-A 00FF.0001 V1.0 DSH32-S .0001 V3.0 NI .0001 Yet in VAX/VMS 7.3, I see this: $ ANALYZE /SYSTEM OpenVMS (TM) VAX System analyzer SDA> show dev zsa0 I/O data structures --- ZSA0ZS_DST32 UCB address: 814EAA40 [snip] I think that in the lab at DEC I used a modem eliminator (I used to support all of the synch devices supported by VAX WANDD). I may even have some of those modem eliminators in the garage. I was hoping to use VAX WANDD but I ended up having to install DECnet OSI on VMS 7.3. Perhaps if I dig up an earlier VMS version, I can avoid using DECnet OSI? Just to double check ... you definitely have synch boards and not (for example) 8-way asynch lines? There were a whole bunch of designators that were so very close: DST32, DHT32, DSH32, DHW41, DSW41! I have two boards in two MicroVAX 3100 machines. Each board has one Synchronous serial port (50 pin D connector) and eight asynchronous terminal lines (36 pin Centronics connector). To add further confusion, I have a third MicroVAX 3100 which has the 50 pin and 36 pin external connectors on the back but no actual DSH32/DHT32 board inside! I also have the following cables: 1 BC19C Rev B1 50 pin D (female) to 13/15 pin D (male) X.21 1 BC19D Rev B 50 pin D (female) to 16/25 pin D (male) V.24 1 BC19F Rev B 50 pin D (female) to 17/34 pin "square" thing (male) V.35 1 BC19V 50 pin D (female) to 16/25 pin D (male) V.24 and I also have two Nokia DS 60100 baseband modems, one with a V.35 interface card and one with an X.21 interface card. When I hook up the former with the BC19F cable, I can get the lights on the modem to react when I try to access ZSA0: on the MicroVAX. However, I can't get any reaction when I use the BC19C cable with the latter even when I jumper the modem to take account of the fewer signals available in X.21. It may be that the BC19C is meant for something other than the DSH/T32... Anyway, this whole line of attack is fairly academic as the modems can only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be 19200bps. Regards, Peter Coghlan. Antonio
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Paul Berger wrote: On 2020-06-18 6:06 a.m., Peter Coghlan via cctalk wrote: > > > To get somewhere near back on topic, I am trying to set up a synchronous > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > interfaces. One of the options I have is a BC19D cable and a BC19V cable > which seem to be identical or nearly identical. Each plugs into a DSH32 > at one end and has a V.24 DB25 connector at the other end. I don't seem > to have anything available in the way of a pair of suitably similar modems > or a modem eliminator to put between the two V.24 connectors. Can anyone > suggest some kind of a quick hardware hack that I could use to fill the > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > sufficient or do I need something that generates clock signals too? > > Regards, > Peter Coghlan. > > While I have no experience with MicroVAX, I do recall that on the machine I was involved with synchronous communications on, IBM terminals and systems, there was an option for the interface to provide clocking and I suppose it might be possible to set one side to provide the transmit and receive clocks and cross them over to the other interface, but I have never tried that. When I worked in a development center with a room full of S/38 and S/36 we had a modem rack with a large number of Gandalf modem eliminators that provided clocking to the interface. In the field the most common setup was to have the modem provide the clocks as the common carrier could synchronize them over a long distance. Thanks for your reply Paul. My eventual goal is to be able to use the synchronous serial interface on a MicroVAX to connect to IBM machines that only support bisync lines. However, I don't have access to any such IBM kit at the moment so I have to make do with trying to get the MicroVAX to talk to another instance of itself for now. As I mentioned in another reply, I have a pair of baseband synchronous modems and were it not for a speed incompatibility between them and the MicroVAX synchronous serial interfaces I have access to, plus another probably minor snag, it looks very much like they would do the job when suitably jumpered. There is even a card in the bottom of each modem case giving details of all the jumper settings! Regards, Peter. Paul.
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Paul Koning wrote: > > > On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk > > > ... > > As I mentioned in another reply, I have a pair of baseband synchronous mode > > and were it not for a speed incompatibility between them and the MicroVAX > > synchronous serial interfaces I have access to, ... > > I'm curious about that. Synchronous modems supply the bit clock to the > interface. So a synchronous interface works at whatever speed the modem > delivers, so long as it's not too fast for the interface. What are the > Microvax sync interfaces you have? DMV? DUV? A DMV will work at up to > 56 kbps. > There is conflicting information about what exactly the interface I have which is fitted in a MicroVAX 3100 is called. It looks most likely to be a DSH32 or a DSH32-B which may amount to the same thing but it could also be a DST32 which may also amount to the same thing... Documentation suggests that the synchronous interface part of a DSH32 (which for added confusion is referred to as DSH32-S) is DSV11 compatible but limited to a maximum of 19200 bps. The modems I have (which were intended for use with 64 kbps lines attached to Cisco routers) don't have jumpers for clock speeds lower than 48 kbps. Regards, Peter. > paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Ethan Dicks wrote: > On Thu, Jun 18, 2020 at 5:53 AM Peter Coghlan via cctalk > wrote: > > To get somewhere near back on topic, I am trying to set up a synchronous > > serial link between two MicroVAX 3100 machines with DSH32 (or DST32 maybe) > > interfaces. One of the options I have is a BC19D cable and a BC19V cable > > which seem to be identical or nearly identical. Each plugs into a DSH32 > > at one end and has a V.24 DB25 connector at the other end. I don't seem > > to have anything available in the way of a pair of suitably similar modems > > or a modem eliminator to put between the two V.24 connectors. Can anyone > > suggest some kind of a quick hardware hack that I could use to fill the > > gap? Is a pair of DB25 sockets with crossed over wiring betweeen them > > sufficient or do I need something that generates clock signals too? > > If both ends don't care about delays in the handshake lines that would > be natural with a modem or high-end modem eliminator, you can just > match up the signals between the two devices as you would for a null > modem. > > As for the clocking, yes, a modem or modem eliminator provides the > baud rate clocking on pins 15 and 17. You could use any one of a > number of baud rate generators, from the COM 8116 (one that we used at > work in the early 80s for a simple modem eliminator) to a modern > microcontroller thumping out pulses at the right frequency. You'll > need to drive both sides of the connection at RS-232 levels, so a > level shifter (1488 if you have +/-12V handy, or MAX232 if you do > not). AFAIK, you can drive both ends from one line driver, but the > safer course would be to drive each clock pin independently. > Hi Ethan, Thanks for your reply. I can rustle up +/-12V with a bench supply or two but I don't have a 1488 handy. I should be able to borrow a MAX232 from something though. I don't have any baud rate generators lying around either. How about a 555 generating square waves round about 10kHz for something approximating 9600 bps? Does it have to be spot on a "valid" rate or will anything "close" do as long as it is the same at both ends? To be absolutely clear, do I have to drive pins 15 and 17 going to both interfaces ie four loads on the driver in total? Regards, Peter. > -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Ethan Dicks wrote: > On Thu, Jun 18, 2020 at 2:42 PM Peter Coghlan via cctalk > wrote: > > Thanks for your reply Paul. My eventual goal is to be able to use the > > synchronous serial interface on a MicroVAX to connect to IBM machines that > > only support bisync lines. > > I'm curious which software package you are using. In the 80s and 90s, > I worked for Software Results Corp, and we sold hundreds (small > thousands?) of Unibus, Qbus, and VAXBI interfaces and software suites > under the name COMBOARD for Bisync and SNA comms from DEC-to-IBM > (RSTS, RSX-11, VMS, and UNIX). In my experience, people paid us > $10K-$25K per line because they had problems with whatever other > solution they were looking at that cost less. I don't know any > specific details on where the gaps were, but just that people did > experience bugs or missing features that made them come to us. I'd > like to hear about what you are encountering once you get to the point > of passing bytes. > I am using a very old package called HUJI-NJE which implements NJE links on VAX/VMS and UNIX. This was later developed into "funetnje" which added some enhancements but broke the VMS functionality. I backported some of the funetnje enhancements into HUJI-NJE in order to use them on VMS. NJE over TCP/IP is implemented on both platforms but on VAX/VMS, there is also supposed to be support for using synchronous serial interfaces in the form of a DMF32, DMB32 or DSV32 (is that like a DSV11 I wonder?). If this all works out, it may be possible to use it to get NJE links into IBM mainframe hardware that only has support for bisync lines. It might also have applications in talking to 3270 terminals connected via bisync lines. HUJI-NJE is not great for debugging the hardware with so I am also using a pair of of example programs I found in AA�PHEPB�TE DECnet/OSI for VMS VAX WANDD Programming. > > > However, I don't have access to any such IBM kit > > at the moment so I have to make do with trying to get the MicroVAX to talk > > to another instance of itself for now. > > For bisync (3780/HASP) that should be just fine. There's a simple > difference in the protocol so that each end can tell who is the > master, and AFAIK, any implementation you encounter should be able to > be set in the appropriate mode, but you _do_ have to tell each end > what their role is or they will chatter endlessly if they both think > they are the master. > NJE is supposed to be able to use hardware features of devices such as the 2703 to be able to decide which end gets to be primary and which end gets to be secondary. Sounds like it will be fun to implement... I think endless chatter whether idle or not seems to be a feature of bisync. > > Apologies if you already know this. It's been a long time and I'm not > sure who remembers what details about obscure comms from 30-40 years > ago. I myself haven't even set up a bisync connection in 25 years. I > used to do this stuff every day, then by the mid-90s, it entirely > evaporated. > I am fairly well up on NJE but only over TCP/IP until now. All this synchronous serial stuff is completely new to me so I am grateful for any and all information I can get about it. Regards, Peter. > -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Antonio Carlini wrote: On 18/06/2020 14:06, Peter Coghlan via cctalk wrote: > > I have found the whole thing very confusing too. My suspicion was also > that they were pretty much the same thing but the DST32 had exernal > connectors suitable for mounting in a MicroVAX 2000 while the DST32 had > external connectors that could be mounted in a MicroVAX 3100. That is, > until I also came across the preliminary version of EK-283AA-AD-001 > which threw cold water on that theory. Unless it was originally called > the DSH32 and then renamed to DST32 for the MicroVAX 2000 or something... I expect that the uVAX 2000 interface was around well before the uVAX 3100 one. I suspect that the docs was wrong or that something got renamed at some stage. If I ever frind my notebooks from the time I can take a look. I'd be very interested to know what the story was if you manage to locate those notebooks. > > I was hoping to use VAX WANDD but I ended up having to install DECnet OSI > on VMS 7.3. Perhaps if I dig up an earlier VMS version, I can avoid > using > DECnet OSI? If you further along it got renamed to DECnet-Plus ... would that help :-) I don't know when Phase IV support stopped for WANDD. DECnet-VAX Extensions went out in the V5.4-3 timeframe IIRC. Certainly for a while you have a choice and were not required to run DECnet/OSI. In fact the only reason that DECnet-VAX Extensions shipped was (iirc) that PSI/WANDD was ready and DECnet/OSI wasn't. Anyway, pre VMS V6.0 I'm sure you can just pull the latest contemporary WANDD kit off a VMS CD and you'll be fine. I already tried extracting ZSDRIVER.EXE from the DECnet/OSI kit for VAX/VMS 7.3 and placing it in SYS$LOADABLE_IMAGES but ZSA0: remained stubbornly offline until I installed the rest of DECnet/OSI and the LES$ACP_V30 process started. I think I have an old CD containing a WANDD kit somewhere but I can't seem to put a hand on it right now. I probably put it in a "safe place" :-( I was pleased to find that I have a grey DEC folder containing AA-LN26B-TE VAX WAN Device Drivers Installation Guide, Specifications and Programmer's Guide for VAX/VMS 5.0 Software Version: VAX Wide Area Network Device Drivers V1.1 First Printing July 1988 Revised, January 1989. I'd forgotten I had these! These manuals mention the DSV11 and DST32 but there is no reference to the DSH32 anywhere. The installation guide says the device driver for the DST32 is ZSDRIVER.EXE so this seems to suggest that the DST32 and DSH32 are the same thing or at least very similar. Maybe there was a difference of opinion between the hardware people and the software people as to what it should be called :-) The specifications manual says: "The DST32 is a single line interface for single board VAX systems. It provides RS-232-C, RS-442-A and RS-423-A connections to dial-up or leased synchronous communications lines and operates in both character-oriented and bit-stuffing mode. On the synch side the idea was to get away from having a set of (often different) cables for each interface. Instead everything had the same 50-pin connector and then you picked the appropriate cable for V.25 or X.21 or whatever you needed. My DST32 has such a connector, as does your DSH32. I expect that the DSV-11 also is the same. DECnis certainly is. > > and I also have two Nokia DS 60100 baseband modems, one with a V.35 > interface card and one with an X.21 interface card. When I hook up the > former with the BC19F cable, I can get the lights on the modem to react > when I try to access ZSA0: on the MicroVAX. However, I can't get any > reaction when I use the BC19C cable with the latter even when I jumper > the modem to take account of the fewer signals available in X.21. It > may be that the BC19C is meant for something other than the DSH/T32... I don't remember the cable part numbers (although they will be in the manuals) but if it plugs into the 50-pin connector then it should work. I found details about many of the interface cables, including wiring diagrams in EK-DRT90-OM DEC WANrouter 90 Owner's Manual on the web and more stuff in EK-A0497-IN DEC WANserver 150 Installation/Owner's Guide. > Anyway, this whole line of attack is fairly academic as the modems can > only do 48kbps - 160kbps and the maximum for the DSH/T32 seems to be > 19200bps. > I'd be surprised if they don't work at up to 56k at least. Maybe not 64k (I remember the DSV11 firmware engineer telling my that some extra work had to be done to get one of the DSV11 modes to work properly at 64k even in pathological cases, so maybe other, lower-end interfaces didn't get the same love). Above 64k would not have been a normal use case back in the day - I don't have any data handy to check what should work though. The specificatio
RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
Dave Wade wrote: > > -Original Message- > > From: Ethan Dicks > > Sent: 19 June 2020 15:44 > > To: Dave Wade ; General Discussion: On-Topic > > and Off-Topic Posts > > Subject: Re: Synchronous serial Re: E-Mail Formats RE: Future of > > cctalk/cctech > > > > On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk > > wrote: > > > Its been ages since I did this but looking here > > >DPV11 > > > https://www.aggsoft.com/rs232-pinout-cable/RS232.htm > > > > > > I see we have a transmit clock output on pin 24, transmit clock input on > > > 15 > > and RX clock input on 17. > > > So if on checking with a scope I have clocks on 24, I would try linking > > > 24 and > > 15 on one side to 17 on the other side. > > > If you have only one clock running then that goes to 15 and 17 on both > > ends > > > > None of the devices I worked with in the 80s and 90s had clock available on > > pin 24. I'm not saying none exist, but they weren't around in the era I was > > doing this. > > > > Ethan, > Well some do, some don't. In general we avoided using it because we probably > wanted to set other signals, > However the first card for which I could find documents, the QBUS DPV11 has > a configurable clock on pin 24 > > http://www.bitsavers.org/pdf/dec/qbus/EK-DPV11-UM-001_Aug80.pdf > > page 2-5 and 2-7. Its called "null modem" but you can see its connected back > to the clocks so you can test the interface. > I took a look at pin 24 on my setup and it has a steady negative voltage so it is getting driven at least. It looks very likely that it can be configured to generate a clock signal for loopback tests. Before figuring out how to do that, I had a go at making a clock from a 555. The random bunch of components I grabbed produced a roughly 600Hz output according to the frequency range on my multimeter and it is probably far from square. I decided to live dangerously, skip the MAX232 and connect the output of the 555 directly to the clock signal inputs. Along with a birds nest of crossover connections, this allowed the example programs to successfully write and read some data over the line! Next, I tried starting up HUJI-NJE. Initially, the link failed to connect because one end wasn't listening when the other end was sending. However, I found that if I started both ends at more or less the same time, the link managed to connect successfully. It looks like I need to tweak the handshaking crossovers so that this works more reliably. I suspect the meaning of the lack of support for "BISYNC" in the DST32 may be that I don't get the ability to generate the bisync CRCs in the hardware. By coincidence, I was involved in a thread on generating CRCs for bisync links on another mailing list recently so I am now fairly well versed in how to do this in software. Many thanks to everyone for your help with this project, especially Antonio, Ethan, Paul and Dave. Regards, Peter Coghlan. > Dave
Re: Future of cctalk/cctech - text encoding
Someone whose name might be Marc might have written: Peter Coghlan wrote: Does anyone use ASCII anymore? >>> >>> I read and write my email with Emacs running in a terminal emulator. >>> I rarely need anything beoynd codepoint 126. >> >> I vote we move the list to an Exchange server behind a SSL VPN and mandate >> the use of Outlook, then force all messages to be in quoted-printable >> encoding. This way nobody “wins” and everyone is equally miserable. >> It’s only fair. > C'mon, quoted-printable is usually fairly readable. How about base-64? Or if this is regarded as too modern or too universal, how about uuencoding? > > +1 on the Exchange server. You might even be able to have more than 2 people > connected to it at the same time without crashing, if you put enough admins > on the problem. > You can't use an Exchange server. I believe Exchange servers silently discard messages whose message-id it has previously seen. This would solve (actually hide) the duplicated messages problem and we can't have that! > > But I would strongly suggest that we limit it to using characters from the > Baudot set. If not they don’t print right on my 1930 Teletype. > > Also Darwin recently wrote a paper about us, and revoked his theory of > evolution. > > Unlike the God-awfull Yahoo Groups, Groups.io works OK for the other lists > I follow. Meaning it’s functional and tolerable, and only moderately > infuriating. But it is certainly not as clean and efficient as this list > by a good margin. It would be good if we could preserve this. > > Maybe evolve to the use of pictures or attachments, just to prove Darwin > wrong? Limited to ASCII art only pictures, of course. > Hang on, what about those who prefer their art in upper case EBCDIC only? Regards, Peter Coghlan > > Marc
Re: About to dump a bunch of Compaq SCSI disk caddies (and disks)
Johan Helsingius wrote: > On 06-07-2020 23:54, Grant Taylor via cctalk wrote: > > > /Which/ caddie are they? Can we see a picture of them? Both the front > visible from outside of the system and the connector(s). > > Pictures at https://imgur.com/a/iJU6YBH > I have a shoe box full of similar Compaq caddies, blanks and one or two slightly different caddies. I am interested in swapping what I have for SCA disk carrier plates which fit in the slots in the front of my DEC Alphaserver 800. These are a much simpler device consisting of a steel base with a honeycomb of ventilation holes, no top, clear plastic runners on the sides and a flexible clear plastic pull handle at the front. See figure 10-10 on page 240 of: http://vaxhaven.com/images/5/55/EK-ASV80-UG.B01.pdf I don't have any disks to include unless someone wants a couple of failed 18GB examples. (I also have an unidentified 4 slot SCA disk cage which I have no caddies/ carriers for and I have no idea what to look for except that they seem to be slightly larger (wider) than either the Compaq type or the Alphaserver 800 type.) I am in Dublin, Ireland. Regards, Peter Coghlan.
Fan problem with DEC H7822 power supply in MicroVAX 3100
I have a MicroVAX 3100 which has a H7822 power supply. The power supply and the machine itself mostly work (there is a problem with the SCSI interfaces but that's another story) except that the two fans in the power supply don't run. If left on for a long time, the machine gets too hot and a thermal trip operates, shutting it down. The fans are DC 12V 0.2A and if I connect them to +5V or +12V, they work fine and don't draw excessive current so there would seem to be a problem with the section of the power supply which drives the fans. Unfortunately, it's operation is not obvious and the power supply is a pig to work on. It consists of two double sided PCBs connected by short leads and having live parts on both boards making it difficult to get access to both sides of the board where the fan circuit is when the power is on. I don't have an identical working power supply to compare the faulty one to but the fan circuit looks superficially similar to the one in the H7821 which I do have working examples of so that may be a way to proceed. Does anyone have a service manual for the H7822 or H7821 or know how the fan circuit is supposed to work in these power supplies? Regards, Peter Coghlan.
Re: Fan problem with DEC H7822 power supply in MicroVAX 3100
Jon Elson wrote: On 07/20/2020 07:00 AM, Peter Coghlan via cctalk wrote: > I have a MicroVAX 3100 which has a H7822 power supply. The power supply > and the machine itself mostly work (there is a problem with the SCSI > interfaces but that's another story) except that the two fans in the > power supply don't run. If left on for a long time, the machine gets > too hot and a thermal trip operates, shutting it down. > > The fans are DC 12V 0.2A and if I connect them to +5V or +12V, they > work fine and don't draw excessive current so there would seem to be > a problem with the section of the power supply which drives the fans. > Unfortunately, it's operation is not obvious and the power supply is > a pig to work on. Yes, it probably has a temperature sensor and a fan speed controller. If you don't care about noise, you could probably just rewire the fans to 12 V directly. I was thinking about wiring them to 5V because it was only marginally overheating after running for a long time. However, I started poking around with the multimeter and discovered a low resistance across one of the connectors for the fans. This led me to a 1N759A 12V 400mW zener diode which read about 20 Ohms in both directions. Looking at the H7821, there was a 1N4742 12V 1W zener diode in a similar position. It had much more plausable readings so I borrowed it and fitted it to the H7822 in place of the dud 1N759A. The fans are spinning nicely now with about 7.5 to 8V across each one. This was a lot easier than I was expecting :-) Jon
Re: Fan problem with DEC H7822 power supply in MicroVAX 3100
On 07/20/2020 10:55 AM, Peter Coghlan via cctalk wrote: > > I was thinking about wiring them to 5V because it was only > marginally > overheating after running for a long time. However, I > started > poking around with the multimeter and discovered a low > resistance > across one of the connectors for the fans. This led me to a > 1N759A 12V 400mW zener diode which read about 20 Ohms in both > directions. Looking at the H7821, there was a 1N4742 12V > 1W zener > diode in a similar position. It had much more plausable > readings > so I borrowed it and fitted it to the H7822 in place of > the dud > 1N759A. The fans are spinning nicely now with about 7.5 > to 8V > across each one. This was a lot easier than I was > expecting :-) > Wow, lucky it didn't smoke anything. there must be a series resistor somewhere that probably got pretty hot. It looks like the zener is connected between the adjust terminal of a heatsink mounted LM337T adjustable negative voltage regulator and the positive connection to one of the fans. Also connected to the adjust terminal is what looks like a thermistor mounted on the heatsink of a MBR3045, presumably a switching transistor. Perhaps the zener didn't end up carrying much current, however if that is the case, it is a bit strange that it failed. Regards, Peter Coghlan. Jon
Re: DEC VR260 service docs / common failure modes?
Josh Dersch via cctalk wrote: > Hi all -- > > Picked up a non-functional but otherwise nice looking DEC VR260 (19" b&w > monitor) on the cheap, hoping to use it with my VAXstation 2000. From what > I've read, these were never the most reliable displays. Curious if anyone > has any information on common failure modes, or has service docs squirreled > away somewhere. I've at least found schematics, so I have something to go > on, but it's not exactly the most straightforward design I've poked at. > > Right now when powered up I hear a repeated low hum from the transformer > followed by a soft ticking noise so I'm guessing I've got power supply > issues at the very least. Unsure what I should expect the monitor to do if > it's not being fed a valid video signal (I haven't yet tried to hook the > VS2000 up to it) -- whether it'll go into free-running mode or do mostly > nothing until it has something to sync to... > Is a VR260 anything like a VR262? I have a pair of the latter and could probably do some measurements for comparison if that would be useful, assuming mine still work... Regards, Peter Coghlan. > > Thanks as always, > Josh >
Re: 2 2010 macbook pro's --- vast performance differences....
How many here think that 2010 Macbook Pros running Windows are "CLASSIC"? I think everything is on-topic for "cctalk", isn't it? Unfortunately, the "cctech" moderated view of the list hasn't worked properly since the list server was rebuilt after a crash several years ago so we are all effectively stuck with the "cctalk" view of the list whether we like it or not. This is not so bad though as there has been next to no truly off-topic stuff on "cctalk" for a very long time now. (I hope I haven't jinxed it by saying it out loud though...) Certainly sympathize with the problems, but if 4MHz processor and bumping the RAM up to 64K doesn't work, then perhaps a "CURRENT MODEL Macintosh" group (there might be some on Facebook) might be a more productive venue for the search? I agree it might be a bit borderline for "cctech" but I think it's fine for "cctalk" by definition. Regards, Peter Coghlan.
Spam
Anybody else on cctech/cctalk receive a blatant spam today from an outfit called "SparkPost" with "OptIn Live" in the subject? Regards, Peter Coghlan.
Re: Spam
Paul Koning wrote: > > On Aug 31, 2020, at 6:55 PM, Peter Coghlan via cctalk > > wrote: > > > > Anybody else on cctech/cctalk receive a blatant spam today from an outfit > > called "SparkPost" with "OptIn Live" in the subject? > > > > Regards, > > Peter Coghlan. > > Nope. > > Keep in mind that criminals often forge source addresses. So while it may > say it came from cctalk, it doesn't mean it actually did. Looking at the > full headers will often tell you, if you care to go to the trouble. > The spam I got did not come from cctalk. I didn't say it came from cctalk, I said it came from an outfit called "SparkPost". I asked if anyone else on cctalk received the same spam because I am attempting to figure out how SparkPost obtained the email address that I use only for cctalk. >From the responses received, it appears that other cctalk list members did not receive the same spam which reduces the likelyhood that someone (ie SparkPost) had subscribed to cctalk specifically to harvest the email addresses of the list members, a possibility which was advanced on this list a while back. > > For example, I get spam every few weeks claiming to be from one specific > person on the list here, but it never actually is from that address. > Same here except that it is in regard of the freecycle mailing list rather than cctalk. Regards, Peter Coghlan. > paul >
Re: Spam
Paul Koning wrote: > > On Aug 31, 2020, at 6:55 PM, Peter Coghlan via cctalk > > wrote: > > > > Anybody else on cctech/cctalk receive a blatant spam today from an outfit > > called "SparkPost" with "OptIn Live" in the subject? > > > > Regards, > > Peter Coghlan. > > Nope. > > Keep in mind that criminals often forge source addresses. So while it may > say it came from cctalk, it doesn't mean it actually did. Looking at the > full headers will often tell you, if you care to go to the trouble. > The spam I got did not come from cctalk. I didn't say it came from cctalk, I said it came from an outfit called "SparkPost". I asked if anyone else on cctalk received the same spam because I am attempting to figure out how SparkPost obtained the email address that I use only for cctalk. >From the responses received, it appears that other cctalk list members did not receive the same spam. This reduces the likelyhood that someone has subscribed to cctalk specifically to harvest the email addresses of the list members, a possibility which was advanced on this list a while back. > > For example, I get spam every few weeks claiming to be from one specific > person on the list here, but it never actually is from that address. > Same here except that it is in regard of the freecycle mailing list rather than cctalk. Regards, Peter Coghlan. > paul >
Re: Clicking SCSI disks
Antonio Carlini wrote: So I thought I'd tap the wisdom of the list. Is there any way that people have used to successfully recover data from RZ28, RZ29 disks (which all worked in 2003 :-))? Has anyone tried freezing a double bagged drive? Was it successful? If so, how long did you freeze it for? These disks are in StorageWorks containers ... should I remove them before freezing? I have some RZ28 (2GB?) disks but I don't recall having any difficulties with them. I do have some RZ29B (4.3GB) disks that fail to spin up when requested to unless they are given some physical encouragement in the form of a sharp twist or some vigourous tapping. They can be heard to make a very faint and short purr when trying and failing to spin up but no clicking noises and no data issues. I have more than one RZ26L (1.05GB) disk which I reinitialised and installed a new system on which then failed horribly with nasty clicking noises after working nicely for a very short time. I haven't found any way to fix this condition and I don't know if almost completely rewriting them is what triggered it to happen or maybe it was because of sudden activity after years of idleness. I didn't try freezing them. I also have one Compaq 9GB SCA disk which made heart-stoppingly loud clunks and clicks at irregular intervals but continued to function normally in this condition for several years. I had copied it's contents to a new disk but left it in place to see how it would fail. It didn't. I eventually took it out and examined it, found nothing obvious wrong, put it back in and decided to make an audio recording of the noises it had been making. Of course, it then refused to make any more noises after being disturbed and continues to work normally without any data issues whatsoever. Regards, Peter Coghlan.
Re: cc:Mail
Back in the 1990s, a company I used to work for offered email services to people running cc:Mail, Lotus Notes, MSMAIL, Pegasus Mail and various other oddball mail servers (X.400 even) using PMDF on VMS. PMDF is still a commercial product but a hobbyist license is available. PMDF is also available to run on UNIX (and Windows) but I don't know whether the same gateways to esoteric systems and hobbyist license are available on those platforms. I recall one of the problems with cc:Mail (and Lotus Notes) was that it did not not have any concept of "envelope addresses". This meant that it was nearly impossible to avoid message loops in the case of undeliverable messages, especially when mailing lists were involved. Regards, Peter Coghlan. > Hi, > > Yes, this sounds plausible. You don't happen to remember if it was > a Lotus/cc:Mail or a third party product? > > I managed something like this for MS mail at one point. > > /Tomas > > > > On Wed, 07 Oct 2020 17:22:27 +0200, Gavin Scott wrote: > > These may all be dead short-circuited neurons, but IIRC there was a > > cc:Mail Gateway or Internet Gateway special product you needed to buy > > that would run on a dedicated PC box (under DOS?) and would talk in > > turn to your cc:Mail post office server and the 'net to exchange email > > messages in and out. It had the semi-annoying habit of retaining > > plaintext copies of all incoming or outgoing messages (one or the > > other, I forget which). There was also some non-trivial configuration > > setup required on both the Gateway and cc:Mail servers to explain all > > this to cc:Mail. I think there was some sort of route name or gateway > > name specified with email addresses, possibly with a comma after the > > internet address, but like I said those brain cells are almost gone. >
Re: Remote job submission from PDP-11
> Hi folks, > > I am looking for the following software products for a PDP-11, ideally to > be run on RSX-11M. > > RJE/HASP > > 2780/3780 Protocol Emulator > > My aim is to be able to submit a remote job from a simulated PDP-11 on simh > to a simulated IBM/370 on Hercules. The products that I mentioned seem the > obvious way to do this, but anything that works would be helpful. > I suspect the products you mention above are designed to interface to a real synchronous serial line? In my experience with Hercules, simulating a generalised synchronous serial line effectively in software is pretty fraught. I don't know if simh attempts to do this or if it allows the simulated system access to real synchronous serial hardware in the host system. If the latter, this doesn't get you any closer to a connection to Hercules because Hercules does not have code to drive a real synchronous serial line. However, I know of at least two projects which implement bisync line to TCP/IP gateways to interface to IBM terminals using additional hardware. Perhaps it might be possible to adapt one or both to do RJE? Here is one of them: http://www.9track.net/hercules/dlsw/ I can't quite put a hand on a url for the other one right now but the author posts here regularly so hopefully he will chime in. Or, it might be possible to use an intermediate gateway such as a MicroVAX with a synchronous serial interface. The protocol used for 2703 over TCP/IP emulation in Hercules is not really up to doing much more than trivial RJE transfers. It can't really manage NJE either. (NJE is mostly just RJE with another layer added on.) Back in the 1980s, a requirement arose to be able to transport NJE across the internet for the BITNET network. A protocol was devised to enable this to be done effectively: http://www.nic.funet.fi/pub/netinfo/CREN/brfc0002.text I have implemented this protocol in Hercules here: https://github.com/rbowler/spinhawk/ Unfortunately, this protocol is specific to NJE, it does not work for RJE. In order to get RJE in and out of Hercules with any degree of reliability and efficiency, it would be necessary to come up with an equally suitable protocol or tweak the NJE protocol appropriately. If you can come up with a way of getting NJE over TCP/IP out of your simulated PDP-11 on simh, you can trivially connect that to my code in Hercules in order to end up with NJE connections to either VM/370 RSCS or MVS (both with suitable tweaks). Not so useful if what you really want is RJE though. Regards, Peter Coghlan. > Cheers > > Peter Allan
Re: Remote job submission from PDP-11
Ethan Dicks wrote: > > There are no implementations of sync serial devices in Simh. That > would have to be written in any case. The DU11 and DUV11 are very > simple PIO serial lines with, IIRC, a COM5025 USART. It would not be > a huge undertaking to write up a module to emulate one and attach it > to the virtual bus and have it also just open up a TCP socket. > > One could use 'netcat' or something similar to open up and talk to > both the PDP-11 socket and the Hercules socket to make the connection. > This is (more or less, not exactly) what the orginal 2703/bisync emulation in Hercules does but it is not really sufficient for RJE, for a number of reasons. The bisync/RJE protocol is a great fit for being generated by hardware and being sent over a dedicated line. It is a poor fit for being generated by software and being sent over a shared TCP/IP network. There is lots of bandwidth wasting chatter and lots of CPU is consumed in mostly achieving nothing useful. The bisync/RJE protocol needs a close to real-time response and is not a good fit for a network which can produce variable delays. Buffers in applications tend to be organised on a just-in-time basis. The flow control needs to be able to tell the far end to stop sending data immediately and dribble in shortly as network buffers get cleared or unexpectedly delayed packets arrive. One end also expects that once data is successfully sent out, it is practically sure to arrive almost immediately at the far end, not get piled into buffers and suffer random delays. (I have tried assuming that if sufficient TCP/IP network bandwidth is provided, the flow control will not get triggered. This didn't work. In practice, if one end has data to send, it will keep blasting it out until the far end tells it to stop and then it expects it to stop near instantly.) Applications tend to be coded with fixed, short timeout values. Interesting stuff happens if the TCP/IP socket is not connected when attempts are made to send data. Applications tend to assume that any errors are fatal and they just give up. The link I included describes how to avoid these difficulties for NJE by using a very different protocol which is specifically designed for sending NJE over TCP/IP networks. I believe a similar approach is needed to do RJE successfully, especially if it is to end up working across the internet rather than just across a lab under ideal conditions. Regards, Peter Coghlan.
Re: Microvax 3100 VMS 7.3 password reset
Bill Gunshannon wrote: On 11/12/20 12:45 PM, Zane Healy wrote: On Nov 12, 2020, at 7:42 AM, Bill Gunshannon via cctalk mailto:cctalk@classiccmp.org>> wrote: Hopefully with the move to x86, we’ll see more people interested in OpenVMS. Personally, I doubt that. There's something icky about VMS running on x86. I can't see the prospect being attractive to either the VMS people or the x86 people. As another aside, it is rather interesting how many hits for VAX and VMS I got that have nothing to do with what we think of as VAX and VMS. Vacuum cleaners and virtual machines? And Virtual Messaging Systems and Volunteer Management System and Vendor Management System and Video Management Software, etc. etc. etc. How could you forget to mention the Voluntary Milking System? Regards, Peter Coghlan. bill
Re: Microvax 3100 VMS 7.3 password reset
Zane Healy wrote: >> On Nov 12, 2020, at 10:39 AM, Peter Coghlan via cctalk >> wrote: >> >> There's something icky about VMS running on x86. I can't see the prospect >> being attractive to either the VMS people or the x86 people. > > Do you have any valid data to base that statement on? > None whatsoever, only my own observations and opinions. > > Quite a few people on the x86 side that I’ve talked to are interested > by the prospect, and from what I’ve seen, it’s being well received on > the VMS side. I know of one company that is interested in seeing if they > should add support in their product for it. > Over the years, I've seen all sorts of people enthusing about how great they think VMS would be, if only it: - could use commodity SCSI disks - could be orders of magnitude faster - could do networking with this, that or the other - could be more compatible with Unix - could be more compatible with Windows - could have a goofy graphical user interface - could have native support for flavour of the month programming language x - could support comodity ISA/EISA/PCI/USB/whatever flavour of the month I/O - could be run on commodity hardware used for other operating systems - could be used for free by students and hobbyists - etc All of these things and more were delivered in spades or were there from the beginning and yet it never seems to be enough. Some people are just never satisfied, not to mention it never seems to dawn on them just how useful VMS clustering is compared to anything else they have seen. > > Mark Daniel already has WASD up and running on OpenVMS/x86. > I don't want to belittle Mark's achievement here but if this x86 port is going to be in any way worthwhile, it shouldn't be a big deal to build a well behaved, long established VMS application on it. > > There have already been 6 customer releases of the x86 version, with a 7th > due in about a month, in fact the V9.0-F release looks to be pretty > significant > (I believe it’s where cluster support will start showing up). > It doesn't even have cluster support yet??? > > The problem with the x86 port is when you have software that only runs on > older versions or architectures. This is also a big problem for the > Itanium port. For example I keep a system running VAX/VMS 5.5-2 for just > this reason, and there is a ton of software that is VAX only, or at best > Alpha only. > I've had plenty of success doing binary translation of VAX software to Alpha when source was not available. I never had any interest in the Itanium platform so I don't know if the same could be done there. > > One thing that is interesting about the x86 version is that people will be > able to easily get their feet wet with a modern version of the OS. > Why can't people do that now using Alpha emulation running on their platform of choice? > > I’m anxiously awaiting VMware and Hobbyist support. > If VMware was worth it's salt, it would be transparent to whatever is running under it, not needing specific support in whatever is running under it. > > Anything that makes it easier to get OpenVMS into the hands of hobbyists > and students is a good thing. > I've been hearing that for 30 years or more and VMS doesn't seem to have taken over the world yet. Regards, Peter Coghlan > > Zane >
Re: misc stuff - free
On 15-12-2020 10:40, Liam Proven via cctalk wrote: > It's nothing new. 15y ago or something, there were umpteen Communities > on Livejournal for any conceivable subject or interest -- most created > by kids without the wits to check for others' before creating their > own. What's Livejournal? Actually, after thinking about it some more, I probably don't want to know... (Don't you mean created by kids who think the existing community is boring / irrelevant / dominated by someone they don't agree with and think their new creation is going to be cool, interesting and open to all but have yet to discover that they don't have the ability to make this happen?) Regards, Peter Coghlan.
Re: Emails going to spam folder in gmail
> Apologies for asking but what the gmail standards? Anything from > yahoo.com, some of Google's own alerts, and items from > lists.dwarfstd.org were all marked as spam. They really won't tell you. I run into problems with them from time to time, they seem to want to only talk to microsoft.com type domains and other big email domains. Which is odd because a lot of junk comes from them. Maybe they get a cut. Or maybe Gmail just wants you to use it instead of anything else. My experience is also that Google will not tell me. They used to have web pages detailing what they were looking for years ago but I think it eventually dawned on them that the spammers can read these too. I have made sure my forward and reverse dns entries and the EHLO domain name my mailserver uses are all correct and I have set up SPF records for my domain yet Google still put lots of emails I send to gmail.com and other Google mail service users in their spam folders. Additionally, my experience is that when I find someone abusing Google services to send or otherwise facilitate spam, Google do not provide any way that I can notify them about this abuse. Best advice is to suggest to the sender that they use a different email provider, one that doesn't put their legitimate incoming emails in the bin. Regards, Peter Coghlan.
Re: Emails going to spam folder in gmail
Bill Degnan wrote: > On Mon, Dec 28, 2020 at 8:11 PM jim stephens via cctalk < > cctalk@classiccmp.org> wrote: > > > > > > > On 12/28/2020 2:25 PM, Liam Proven via cctalk wrote: > > > On Mon, 28 Dec 2020 at 23:12, Bill Degnan via cctalk > > > wrote: > > >> Hi, > > >> I have noticed the same email addresses' messages routinely end up in > > the > > >> spam folder of gmail. > > > I have 2 nested folders (labels/tags/whatever) in Gmail: > > > classiccmp/talk and classiccmp/tech. In my rule which filters messages > > > into those folders, I ticked the box that says never to send messages > > > matching the filter to spam. > > > > > > Problem solved. > > > > > Googles filters are garbage. Problem not solved. I still get plenty of > > spam markings by Google with the headers or something about the traffic. > > > > I get multiple messages that fail the filter rule (same as yours) which > > stay in the inbox as well. > > > > The only filtering system that's worked (so far) is the one in > > Thunderbird. Also with the flow into Thunderbird, I don't use any spam > > filters, and never see any cctalk/tech messages left behind. > > > > Useless data, in early days when there was unlimited email storage I > > thought I'd be clever and subscribe on both my gmail account and my > > personal alias for cctalk. Didn't work out that way because so much > > screwing up by google. > > > > thanks > > Jim > > > > I do this for a living so I am speaking professionally here. It's not > about filters it's about server to server authentication. There is a best > practice for "mail serving" authentication, DNS, encryption and the like. > The old days when messages were simply scanned for spam phrases is long > over. The greylisting and all that is old fashioned. If your mail server > does not follow the modern best practices your message will accumulate > enough strikes against it to cause it to be marked as spam. On the > receiving end one can filter messages "out of spam" but that's an after the > fact local software thing.. It does not solve the reason / issue causing > the need to have filters in the first place. This is why fewer and fewer > private mail servers are still running. They can't keep up with all of the > required protocols. It's a bummer but it's the way it is. The > commercialization of the web is a done deal. > Bill > Bill, I used to do this stuff for a living until about ten years ago. A lot has changed since then. However, my experience as a small mailserver operator now is that few have problems getting mail from me except users of Google mail services. The big problem with Google is for someone whose business is communications, they just don't want to be communicated with. They don't want to know about faults with any of their services. They don't want to know about anyone abusing their services to send spam or to enable spam and they don't do anything about it unless their automated system detects it. Rogue ISPs have increasingly cottoned on to this and an increasing number of them use Google mail services or in some cases just plain gmail.com mailboxes for the abuse addresses they have to register in ARIN/RIPE/APNIC etc. Then they can ignore the incoming abuse reports forevermore while their corporate mail system chuggs along nicely without getting flooded by them. Better still, they can flag all their incoming abuse reports as spam to Google who will eventually decide the senders are actually sending spams, not genuine abuse reports and guess what happens next? Ever tried to phone Google? You end up in a voice mail jail that asks you in intricate detail what you want to talk to them about and then directs you to some useless web forum where people are talking among themselves about the problems they are having with Google. Unless you are calling Google to spend money on advertising that is. I don't know what happens in that case. Google need to review their motto and start living by it. Regards, Peter Coghlan.
Re: Emails going to spam folder in gmail
> > Attempting to pull in this thread a tad, there are relatively simple > measures that can be taken to bring a private mail server into compliance > with gmail, Amazon, Microsoft level mail server protocol and > authentication. Its not just gmail. The simplest measures are done with > DNS and TLS. Most of the mail that I see routinely falling into spam > folder is from what appears to be spoofed domains. Many of these are legit > messages that dont have a properly configured DNS record, preventing the > receiving server from authenticating the FROM domain as owned by the > sender. A simple fix. > Bill, As I said, I don't have problems sending mail to Amazon, Microsoft or any of the large (or small) email providers except for gmail.com and other Google email services. It really is just Google. I do have DNS properly configured, SPF in place and no TLS. I can't be bothered setting up TLS just to be able to talk to Google when others report that they still can't get through to Google even when they have TLS. Not only do Google not tell me why they will not deliver my emails to their customers, they don't tell their customers why they block non-spam emails that they want to receive either. The most a Google customer has ever been able to pass on to me that Google given them by way of explaination was something like: "This mail was tagged as spam because messages similar to it were spam" which of course is complete nonsense. Regards, Peter Coghlan.
Re: Emails going to spam folder in gmail
Hi Mike, Thanks for chiming in on this. > Disclaimer: I don't speak for Google ... > Large corporations (Google included) are basically a scaling problem, > especially when it comes to customer service. I think that's pretty > obvious, and stories about YouTube problems and account access are legion. > I don't have a solution that can be applied to the problems on this > thread. My purpose in posting was to point out that this probably isn't a > matter of market share or people forgetting not to be evil; it's a > technical problem. Getting the configs right is the first step. > Blacklists are also a problem, and clearly sometimes the filters being > applied are wrong. We try to find and fix these things as they are brought > to our attention. > The big problem is bringing it to Google's attention. > > It took me less than a minute of searching to find this: > https://support.google.com/mail/contact/bulk_send_new > > That's the form to contact the Gmail team for getting help with debugging > your mail being marked as spam/phishing attempts, you get SMTP temp-fails > or rejects, or other problems. (The search term was "problems sending > email to gmail accounts" - go to the first link, follow the workflow, and > assuming all of the preliminary answers to the questions are "I didn't do > anything wrong" then you'll get a link to that contact form.) > I spent hours over days looking for something like this (using Google searches) and I failed to find it. I always ended up in blind alleys that assumed I was a Google customer trying to get an email into my mailbox, not a correspondant of a Google customer trying to get an email out. My issue with Google and evil is that they provide no way that I can find to bring abuse of Google facilites (to send spam for example) to their attention so that the abuse can be stopped. For example, someone has been testing my mail server to see if it can be used to relay spam by forging emails as coming from various email addresses in my domain name and addressed to check212...@gmail.com and attempting to feed these emails into my mail server (which doesn't accept them) from compromised ip addresses. This has happened nearly two hundred times over a period of five years now. I have made numerous attempts to bring this to the attention of Google so that they could put a stop to this check212014 mailbox being used for this abusive purpose yet I have failed. You seem to have the magic touch. Can you let me know how to bring this to Google's attention? (By the way, this doesn't tend to happen with hotmail.com addresses to pick one example. The reason it doesn't is because on the rare occasions when it does, reporting the issue to hotmail or whoever using the standard, easy to find abuse reporting mechanisms results in the problem being stopped and the spammer soon gets fed up having to set up new testing mailboxes every few days so they end up moving over to gmail.com instead where they can keep the same relay testing mailbox for at least 5 years.) Regards, Peter Coghlan. > > Mike >
Re: Emails going to spam folder in gmail
> My issue with Google and evil is that they provide no way that I can > find to bring abuse of Google facilites (to send spam for example) > to their attention so that the abuse can be stopped. For example, > someone has been testing my mail server to see if it can be used to > relay spam by forging emails as coming from various email addresses in > my domain name and addressed to check212...@gmail.com and attempting > to feed these emails into my mail server (which doesn't accept them) > from compromised ip addresses. This has happened nearly two hundred > times over a period of five years now. I have made numerous attempts > to bring this to the attention of Google so that they could put a > stop to this check212014 mailbox being used for this abusive purpose > yet I have failed. You seem to have the magic touch. Can you let > me know how to bring this to Google's attention? What you describe is a well known spam tactic and is not Gmail -> Google specific. It is hoping to abuse a questionable setting of allowing relay based on source domain, e.g. they are hoping that messages purportedly from your domain will be allowed to relay through your server(s). You misunderstand. What is Gmail / Google specific about it is that this is going on for nearly 5 years using the same recipient mailbox because it is so far impossible to let Google know about it so that Google can can delete the mailbox being used to receive the results of the relay testing which would force the spammer create a new receiving mailbox nearly every time they test. Similar probing using receiving mailboxes on other major email providers systems does not last last more than a day or two before the mailboxes get deleted after mail admins reported them. Aside: This is exactly why you should not allow relay based on the purported source domain. Anyone who tries to do that will rapidly find out that it does not work and they certainly won't have to wait 5 years to find it out. If the IPs perpetrating this attack are outside of Google's control, then there really is nothing that Google can do. There most certainly is something that Google can do. They can cancel the mailbox that is being used to receive the results of the relay testing, provided it is possible to let Google know that the mailbox is being abused that is. I just don't have that difficulty with other major email providers. Mike reports in another reply that he has unearthed a possible mechanism to let Google know what is happening so maybe the problem has is becoming soluble now. It will be interesting to see if the mechanism he found works. Regards, Peter Coghlan. -- Grant. . . . unix || die
Re: Emails going to spam folder in gmail
> Hi Peter, > > About two minutes of searching lead to this: > https://support.google.com/mail/contact/abuse. The keywords were "gmail > report spam abuse", which led me to a page that was centered on > organizations using Gmail as their backend and how to file a report against > them that Google will handle. However, the top link of the page was "Need > to report abuse? Please see our Reporting Abuse Incidents page.", which was > a link to a general abuse form to fill out for any Google product including > Gmail. > > I selected the product (Gmail), selected "Report an abusive Gmail account" > and that led to "https://support.google.com/mail/contact/abuse";, which has > the form you want to use to report the owner of that Gmail account. There > are enough fields on that form to make your specific abuse report, and > there are plenty of free form entry areas so you can explain how this has > been going on for years. > > I'm not sure if you have seen that form or tried this process before. > Clearly what "check212...@gmail.com" is wrong and is an abuse of the > service. Please try it out. > Hi Mike, I appreciate the trouble you are going to here. I am prepared to accept your suggestion in good faith. However, I am not a big fan of filling in webforms to report abuse. It is a slow and tedious manual process to have to engage with in comparison to the highly automated abuse I am attempting to deal with. It is difficult to create tools to make it easier for me and less error prone for me to fill in webforms plus I don't easily get to keep a copy of what I have put in the form for filing with the abuse reports I make to other major email providers. So, when I see further abuse of a gmail.com account, I find it difficult to see whether I reported this particular one previously or not and when. I resent having to jump through hoops to help Google do what they should be doing anyway. Many other mail providers are grateful for abuse reports received by whatever means is most convenient to the reporter of the abuse. They regard encouraging abuse reports as a way of minimising the abuse they have to deal with because their abusive customers tend to up sticks and go to another provider when they are repeatedly stopped in their tracks. I appreciate that you are the messenger here and I am trying not to shoot you. It's just that you represent the only feedback most of us have ever got from Google. Anway, I went to https://support.google.com/mail/contact/abuse as you suggested. This form is clearly designed to report spam sent from a gmail.com account, not a gmail.com account being used to receive the results of relay testing. The form has mandatory fields which require me to provide for example "Email headers of the questionable message". I don't have any headers for any of the messages concerned because my mail server rejects every one of them before the sender gets a chance to send headers as per best practice for dealing with unauthorised relay attempts. Even if I had headers, they would not be from an email sent by a gmail.com account. I am betting that when this form finally gets to a real person in Google, it will go straight in the bin because I wasn't able to provide email headers that came from an email sent from a gmail.com account. Nevertheless, I will try it anyway, just to see what happens. By the way, I looked at the other link you suggested earlier for getting mail through to Google: https://support.google.com/mail/contact/bulk_send_new It turns out I had come across this link before some time ago but had forgotten about it. I had formed the impression that this particular one was aimed at commercial mailing list operators who are having difficulty getting their (legitimate) mailshots through to gmail.com customers of theirs, advertising that people have signed up for by ticking the "please send me information about your product" box or the "please put me on your monthly newsletter" box etc. It does not appear it is designed to help out someone who is trying to get an email through to their friend who has a gmail.com account. I also took a look at https://support.google.com/mail/answer/81126 which you suggested yesterday. This is definately aimed at well funded commercial senders of email that are sending out thousands of mailshots at a time, not the person in the street who is trying to communicate with a friend or someone with a shared interest. Just look at the original title of the page! It suggests I send messages that have different purposes from different ip addresses for heavens sake. (I can do this but do you think I am going to?) I apologise to my friends on cctalk for going on about this at such length and I don't propose to waste any more of the mailing lists time on this. (Unless eve
Re: DDCMP sync?
> > The other option would be synchronous links, which would enable connections > to DMC11 or the like at speeds up to 1 Mb/s. But synchronous comm devices > that connect to modern computers aren't so easy to find, though I have seen > a few. > Not what would be called modern these days but I managed to run across two MicroVAX 3100 machines with DST32/DHT32 synchronous serial interfaces in them plus two V.24 and one each of V.35 and X.21 cables that will plug into them. With some help from the people here, I managed to get the machines talking to each other using a null modem between the two V.24 cables. I also have two nearly identical syncronous modems, one with a V.35 interface and another with an X.21 interface but I have not managed to get these to talk to each other, probably because they can't be configured to match any of the speeds the DST32/DHT32 interfaces can do. One of the MicroVAXes has since died (again) and I haven't got around to looking at it yet to see what is wrong this time. Regards, Peter Coghlan.
Re: DDCMP sync?
I wrote: > >> >> The other option would be synchronous links, which would enable connections >> to DMC11 or the like at speeds up to 1 Mb/s. But synchronous comm devices >> that connect to modern computers aren't so easy to find, though I have seen >> a few. >> > > Not what would be called modern these days but I managed to run across two > MicroVAX 3100 machines with DST32/DHT32 synchronous serial interfaces in them > plus two V.24 and one each of V.35 and X.21 cables that will plug into them. > With some help from the people here, I managed to get the machines talking to > each other using a null modem between the two V.24 cables. I also have two > nearly identical syncronous modems, one with a V.35 interface and another with > an X.21 interface but I have not managed to get these to talk to each other, > probably because they can't be configured to match any of the speeds the > DST32/DHT32 interfaces can do. > Forget I said anything. the DST32/DHT32 won't do anything like 1 Mb/s. Why do you want to go so fast? Regards, Peter Coghlan.
Re: [simh] RSTS processor identification
Johnny Billquist wrote: On 2021-03-06 02:33, Paul Koning wrote: The explanation I heard for the slow J-11 clock is that the original J-11 spec called for it to operate at 20 MHz. When Harris failed to deliver and the max useable clock speed ended up to be 18 MHz, most designs had no trouble. But the Pro support chips were designed to run synchronous with the CPU clock and for various other reasons needed a clock frequency that's a multiple of 10 MHz, so when 20 MHz was ruled out that left 10 MHz as the only alternative. I do think it sounds weird that the support chips would require a clock that is a multiple of 10 MHz. But I wouldn't know for sure. Somewhere else I read/heard that they didn't work reliable above 10 MHz, but for the F11 that was ok. When the -380 came, they just reused those support chips. The 6502 CPU in the BBC Micro operates at 2 MHz but periperals such as the 6522 Versatile Interface Adapters contain timers which only run at their expected speed when used with a 1 MHz clock. I wonder could it be that the Pro support chips would run ok at 18 MHz but there would have been difficulties with programming timers etc which are clocked at an odd speed? (The BBC Micro got around this problem by running the CPU at 2 MHz and stretching the clock cycle to 1 MHz when accessing the VIAs. The clock circuit is a real birds nest...) Regards, Peter Coghlan.
Re: Tymshare PDP-10 tapes
Tony Aiuto wrote: > On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter wrote: >> On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk >> wrote: >> > I think that is an artifact of the files being created with the wrong >> names. >> > For example, with tape 169249, after you skip the UFDs, tito -t prints >> > >> >(SYS).SHR1977-01-26 22:22 [1,4] >> >(SYS).LOW1977-01-26 22:23 [1,4] >> >(SYS).SHR1986-08-19 03:53 [1,4] >> >(SYS).LOW1975-10-24 14:52 [1,4] >> >(SYS).SAV1964-01-02 00:01 [1,4] >> >(SYS).SAV1964-01-02 00:01 [1,4] >> > >> > All the file names are missing. That seems not right. >> >> Very not right, because this is what tito -t is giving me: >> >>(SYS) PIP .SHR1977-01-26 22:22 [1,4] >>(SYS) PIP .LOW1977-01-26 22:23 [1,4] >>(SYS) LOGINN.SHR1986-08-19 03:53 [1,4] >>(SYS) COBOL .LOW1975-10-24 14:52 [1,4] >>(SYS) BINCON.SAV1964-01-02 00:01 [1,4] >>(SYS) VPDATA.SAV1964-01-02 00:01 [1,4] >> >> Those are the first 6 after the UFDs, and extensions and >> date/timestamps match yours. I don't have any, at least on 169249, >> missing the first part of the file name. >> >> Jim >> > > Well. I'm stumped right now. I verified the tape checksum again, and even > got a fresh copy from http://vtda.org/bits/software/DEC/PDP-10/tymshare/. > That is not the problem. > > I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc > 8.3.0) so I doubt this is a portability problem. I'll try again next > weekend. > Out of curiosity, I tried building tito on VMS (with DECC V7.3-009 on an Alphaserver 800). I had some errors compiling memory.c but it appears the code involved does not get called by tito so this didn't cause me any problems. I was able to list the contents of tape 169249 with the resulting executable and the output I got matched the "right" output above exactly. I didn't see anything that looked wrong elsewhere in the file listing either. Regards, Peter Coghlan.
Re: Preventing VAX running VMS / Multinet from being used as SMTP relay
> > I have a microvax set up with VMS 5, running MULTINET (and decnet > locally). The server has a FQDN and after a while being exposed to the > WWW someone out there started using the server as an SMTP relay. I can > disable and clear the queue, but I'd like to block entirely this from > happening in the first place. I'd like to learn more about how this > happens in VMS. > > Anyone have had this same problem before? I realize back when VMS 5 was > current it was not so much of an issue, but today it is. I am working on a > solution. I can envision a few ways including blocking the smtp relay port > from the firewall, but if possible I'd like to set up a VMS Multinet > solution as a learning exercise. > I had this problem about 25 years ago. I suspect lots of people did. In the VMS world, networking stacks are separately packaged from the base operating system and it is possible to install one or more of DECnet, TCP/IP, X25 and various other networking products and have them all running simultaneously. VMS doesn't know or care about SMTP, the issue here is with Multinet which seems to be what was installed to provide TCP/IP networking on your machine. Multinet includes a basic SMTP server which can be used to move mail between VMS MAIL and the internet. Very old versions of Multinet came with SMTP relaying enabled because this is what the standards required at the time. Later versions came with easy ways to disable SMTP relaying. Later still versions shipped with SMTP relaying disabled out of the box when spammers targetting open relays became a serious problem. More recently still, Multinet comes with pretty much all of the TCP/IP servers it provides disabled and requires the installer to enable the services they want, leaving less opportunity for surprises when servers are running that nobody knew existed, except the bad guys targetting them. The Multinet SMTP server is pretty basic and people who are serious about doing SMTP on VMS typically disable it and install a proper mailserver like PMDF. That's my excuse for not knowing how to disable SMTP relaying in Multinet. That and because it probably varies for different versions of Multinet and you haven't said what version of Multinet you have. I used to be one of the people supporting Multinet in this part of the world and I seem to have inherited a stack of Multinet documentation for different old versions so if I knew what version, I could probably look it up. I think the documentation for the most recent couple of Multinet versions is on the Multinet website: http://www.process.com/psc/service-support/multinet-support/ Try the Adminstrator's guide or Adminstrator's reference. I do however know how to disable the SMTP server in Multinet completely: $ MULTINET CONFIGURE /SERVERS SERVER-CONFIG> DISABLE SMTP SERVER-CONFIG> RESTART Configuration modified, do you want to save it first ? [YES] Regards, Peter Coghlan
Re: Preventing VAX running VMS / Multinet from being used as SMTP relay
On 11/30/17, 9:26 PM, "cctech on behalf of william degnan via cctech" wrote: > > >I have a microvax set up with VMS 5, running MULTINET (and decnet > >locally). The server has a FQDN and after a while being exposed to the > >WWW someone out there started using the server as an SMTP relay. I can > >disable and clear the queue, but I'd like to block entirely this from > >happening in the first place. I'd like to learn more about how this > >happens in VMS. > > > >Anyone have had this same problem before? I realize back when VMS 5 was > >current it was not so much of an issue, but today it is. I am working on > >a > >solution. I can envision a few ways including blocking the smtp relay > >port > >from the firewall, but if possible I'd like to set up a VMS Multinet > >solution as a learning exercise. > > > >I am open to suggestions, and once I find the solution I'll post it. > > > >I understand that this kind of thing is not cookie cutter, there are > >different levels one could address something like this. I have a comcast > >business router, and one of the 5 IPs I have is NAT assigned to the > >internal 10.1.10 port of the microvax. > > > >This is the same machine I wrote about previously as with then, thanks for > >your help. I find the best way to learn is on the actual hardware warts > >and all. > > > >Bill > > Look at the SMTP_SERVER_REJECT file example here: > http://www.process.com/docs/multinet5_4/admin_guide/Ch15.htm. > It¹s a set of rules that decide whether a message gets rejected (rule > ending in ³y²) or let through (rule ending in ³n²). You¹d normally set > this up to first let through those emails you want, then reject everything > else at the end of the rules file. > I am not sure whether this method will work on the clearly elderly but unspecified version of Multinet in use here. I should also have suggested checking whether there are other TCP/IP services running that may have issues. DNS in particular would be open to very serious abuse affecting lots of innocent third parties on the internet if not brought up to current patchlevels. NTP also springs to mind. The easiest way to deal with all these issues comprehensively would probably be to update the machine to the current version of Multinet (5.5). This is not hard to do and is covered by the Multinet hobbyist license. Regards, Peter Coghlan.
Re: Preventing VAX running VMS / Multinet from being used as SMTP relay
Paul Koning wrote: > > > On Dec 2, 2017, at 5:48 AM, Doug Jackson via cctech > > wrote: > > > > Camiel, > > > > Without sounding super negative (my day job as a security consultant let's > > me do that enough...) I would be especially wary of connecting anything > > with a 10 year old stack to the modern internet. The range of automatic > > attacks based on what the state of the OS was when it was last patched is > > staggering. > > That's true to a point. On the other hand, many attacks require that the > machine is running on Intel instruction set hardware, and most of them also > depend on the OS being Windows. > > While bugs happen, the level of security competence applied by VMS > engineering is quite high compared to the usual "hack it till it no longer > crashes" practice seen all too often nowadays. That applies especially to > network protocol implementations. > > If the issue is design defects in the protocol specifications, such as may > be found in various revisions of SSL, then having a good OS is not a > complete answer. Even there, it can help; for example, I suspect that the > "heartbreak" attack on older SSL stacks, if it were operable on VMS, > wouldn't get you very far because of OS and instruction set differences. > Certainly script kiddy attacks would not work. > Security is very good on VMS, however, the Bind DNS server code for example is dropped more or less as-is into products like TCP/IP Services for VMS and Multinet. This brings in a bunch of vulnerabilities common to all other platforms running this code. Attempting to exploit these vulnerabilities is unlikely to gain any access to the host VMS system they are running on but there is no defence against vulnerabilities which target systems other than the host system over the network with denial of service attacks and there are lots of these vulnerabilities. They are only fixed, worked around or whatever in relatively recent versions of Bind and therefore only in relatively recent versions of TCP/IP Services for VMS and Multinet. Similar issues may well exist with other TCP/IP servers running on VMS. There is no use in thinking that the bad guys will never find my one little old server which runs only occasionally and is tucked away in my corner of the internet either. They can and they will, just like the spammers can sniff out the most obscure open mail relays and they continue to look for them long after any sane person would persist. I see attempts to exploit various kinds of vulnerability all the time on my VMS systems and many would succeed in causing grief to others on the internet if I did not keep an eye on recent vulnerabilities in the TCP/IP software I am running and keep patchlevels up to date. Whatever about vulnerabilities of our classic computer systems themselves, can we please ensure that what is just a hobby for most of us is not inadvertently causing problems for others on the internet? Regards, Peter Coghlan. > paul
Re: BT139-600G Triac Equivalent
> > I have a suspicion that this component may be faulty on the input side of my > H7826 PSU. A little tester I have does not recognise it, it is possible that > the currents it uses are too low for this particular triac, but I am not > sure. > What is the function of this triac in your power supply? I have come across a triac which is used to switch between 115V and 230V input in the PSU of a DEC 3000/300. My triac went short circuit which caused some release of magic smoke when the PSU was used on 230V. I also had difficulty finding a replacement for it so I ended up leaving it out. The PSU worked fine on 230V only without it once I replaced the other damaged components. If your triac has a different function, ignore the above. Regards, Peter Coghlan.
Re: Odd Connections to Rectifier?
> > I am reverse engineering the schematic for the input stage of my H7862 PSU. > I have come across a KBU6J bridge rectifier which seems to be connected only > to the two middle pins, which are the AC inputs. I can't see any other > connections. Before I desolder it to verify there are no connections I can't > see, does this make any sense? > If it is the main rectifier, continuity checks should show a dead short from the other two pins to the main smoothing capacitor(s) or maybe a very low resistance through a surge limiting resistor or inductor either of which should be easy to spot once you know what to look for. If it is not the main rectifier, could the AC inputs be connected across a current sensing resistor in the mains input with the DC outputs going to an optoisolator or something like that? Seems a bit unlikely though as the voltage drop across the rectifier would likely be too large compared to the voltage available across any current sensing resistor. Regards, Peter Coghlan.
Re: Reviving ARPAnet
Here's a link with a lot of gory details on NetWare's support of multiple Ethernet frame types. Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2 - https://support.novell.com/techcenter/articles/ana19930905.html Here are the four frame types that NetWare supports: - Ethernet II - I think this is what we are using for just about everything today. - IEEE 802.3 "raw" - I'm speculating that this is the frame type that Frank is referring to above. I thought that what Novell refers to as "IEEE 802.3 raw" was an early day foulup on their part where they put IPX data directly into IEEE 802.3 frames with nothing to indicate what protocol was being transported. It became a problem because lots of people whose first experience of networking was a Novell Netware server used it because it was the default frame type, making life difficult for them when they wanted to add other protocols to their network later on. - IEEE 802.3 with 802.2 - IEEE 802.3 with 802.2 SNAP The above are what they should have used instead of IEEE 802.3 "raw" if they really wanted to fly the 802.3 flag. As far as I know, anyone who wanted everything to work just used Ethernet II (and 802.3 / 802.2 SNAP if they also wanted Appletalk support). I don't thing IEEE 802.3 with 802.2 and no SNAP was very useful because of the limited number of protocols it could be used to specify. I /think/ that NetWare can bind IP to all four Ethernet frame types. Hopefully one of them is compatible with V-delta-4 and before. Maybe, if V-delta-4 and before used IEEE 802.3 with 802.2 but I doubt if anyone other than Novell used what they called IEEE 802.3 "raw". Regards, Peter Coghlan.
Re: DEC H7260 PSU fault
With the drive actually hooked up to the controller, I'm getting "?54 RETRY" messages when it's trying to boot - however, I'm not entirely sure what device it's trying to boot from! Maybe it's attempting the TK50, or via Ethernet. I still need to read up on that and work out how to force it to attempt a disk boot. On a VAXStation/MicroVAX 2000 (which could behave the same as or completely differently to an MV-II), "?54 RETRY" is what you get when attempting to boot from the network when nothing is responding (also, if I recall correctly, so take this with a giant pinch of salt...) Regards, Peter Coghlan.
Re: DEC Storageworks
The alphaserver 1000a I have has a storageworks array. The disk carriers are green in color, I see storageworks disks for sale on ebay that are blue. What is the difference? Are they interchangeable? As far as I know, the green ones are 8 bit SCSI and the blue ones are 16 bit SCSI. If I recall correctly, if you put green disks in a blue shelf, they work but I'm not sure if they force the rest of the bus to work in 8 bit mode. If you put blue disks in a green shelf, they work in 8 bit mode. I'm looking at one here doing just that. Is it possible (or even wise) to open one of the green carriers and change the disk out? It shouldn't be a problem. The green ones have 50 pin connectors for the disks and the blue ones have 68 pin connectors. Other issues that might arise include whether the internal cables will reach to where the connectors are on the replacement disk. In the days of the green disks, it was possible to buy empty (white) containers to put your own disks in from DEC or whatever they were called then. I think these were slightly more flexible on the mounting arrangements and cable layout for the disks inside them than the green containers. Regards, Peter Coghlan.
Foolproof power supply interfaces
> > I've done worse--used an AC-supply wall wart on a piece of equipment. > Poor thing didn't stand a chance. > > You'd have thought that after all these years, some sort of keying > system would have been developed, but I guess not. > I'm not sure it would help. What do we get when we try to make things foolproof? A friend asked me to fix his mains powered radio which he said used to work but had stopped working. I thought the mains lead looked rather flimsey but I said I would take a look at it anyway. I opened it up and found that the power went directly onto the PCB where there were some damaged tracks. There was no sign of a transformer or other evidence of a power supply section. I asked my friend if anybody else had done anything to the radio before he asked me to look at it. He said there used to be a big black heavy lump of a moulded plug on the end of the mains lead but he got someone to cut it off and change it for a normal sized plug because it wouldn't fit into the socket he wanted to use it with which was too close to his worktop. He didn't recall hearing a bang when he first plugged in the new arrangement. Regards, Peter Coghlan.
Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)
Guy Sotomayor Jr wrote: > >> On Feb 21, 2018, at 12:19 PM, Rich Alderson via cctalk >> wrote: >> >> From: Guy Sotomayor Jr >> Sent: Wednesday, February 21, 2018 11:24 AM >> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk wrote: >> Typically you'd emulate the I/O device functionality, regardless of whether that is implemented in gates or in co-processor firmware. That's the approach taken with the MSCP I/O device emulation in SIMH, or the disk controller emulation in the CDC 6000 emulator DtCyber. >> >>> It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the >>> mainframe I/O is complex to say the least. >> >> Also the method used by the KLH10 emulator (KS-10, KS-10/ITS microcode, >> KL-10). >> There, each device type runs in a separate fork, using System V style memory >> mapping. This of course means that it only runs under certain Unix variants. > > I haven’t looked at KLH10 in a long time, but Hercules runs on a lot of > different platforms > including Windows (and I would not call that a Unix variant by any stretch of > the imagination). > Hercules uses posix threads, not forks, however, each device does not necessarily get it's own thread. It's pretty portable stuff though. With very few tweaks, I run it on VMS. Regards, Peter Coghlan. > > TTFN - Guy >
Re: AlphaServers
> > How many more years do you think it'll take before decent, practical-sized > Alphas, like the DS15, and to some degree, the DS10, will be obtainable at > hobbyist-friendly prices? > A former colleague of mine has a DS10L. I don't like these very much. It makes the wrong kind of noise, a loud high pitched squeal and can only take one PCI card. This one was probably got for nothing because the services it was running were shut down. Marketplace prices probably reflect whether people are still using them for useful work and will probably remain high if there continues to be demand for them. > > I have an ES47 I got for a price I could stomach, but it's sans rail kit, > drinks power like it's going out of style, and can anchor a 40-ft yacht. > That's more like it. A nice big animal of a machine you can use to heat the room. A few years ago, I had lots of fun looking after a few racks of ES40s running VMS. They ran great but the memory had to be exactly right to avoid wierd failures under heavy load. Unfortunately, I didn't manage to snag any of them when they went out of service. > > Anyone out there do Alphas anymore? > I've got a few: An Alphaserver 2100 (old and slow but makes the right kind of noise) A PWS 500a(u?) (faster but doesn't look the part, needs more memory) An Alphaserver 800 with rails but not currently in a rack. 3 x Alphaserver 1000A (lots of problems, none working now) 2 x DEC 3000 / 600 and 1 x DEC 3000 / 300 (none currently working either) Regards, Peter Coghlan.
Re: AlphaServers
> > Several people have now mentioned they have dead Alphas. What is generally > failing about them? > The B-Cache on the CPU card on every Alphaserver 1000A I have laid eyes on has failed at some point. It can be disabled with a jumper but this makes the machine a lot slower for some tasks. I have also had problems with intermittent shutdowns for no reason on these machines, probably due to failures in the thermal protection logic. Also possibly problems with the connector the CPU card sits in and just plain failure to do anything. The 115/230V power supply in my DEC 3000 / 300 decided to go permanently into 115V mode despite the power here being 230V which resulted in a bang. Removing the shorted triac and replacing the exploded VDR and fuse fixed that for a while but now the machine has some other problem that I can't recall. The monitor that was with it has some sort of EHT problem. My two DEC 3000 / 600 machines go through their power up tests, flashing the diagnostic LEDs nicely but don't boot or produce a console prompt afterwards. One of them went into this state when I was trying to reboot it remotely while it was in service. It really needed a reset or power cycle at the time but I couldn't do that remotely so I tried various not very likely to succeed console commands. I may have somehow damaged the firmware doing that or a fault may have arose coincidentally but I never got a console prompt since on it. The other one behaves the same as it but it started happening when noone was looking at it. Regards, Peter Coghlan.
Re: AlphaServers
> > When my 1000 started failing, the manual lead me to believe it was b-cache, > but the jumper map wound up to be wrong, > There are a number of variants and the manuals are extremely unclear. > > it was actually failed RAM. > I forgot. I had that too. The firmware is supposed to specify which bank and SIMM is faulty. Another reason to not love these machines: If SIMM 0 has failed, the firmware reports a failure in SIMM 0. If SIMM 1 has failed, the firmware reports a failure in SIMM 1. If SIMM 2 has failed, the firmware reports a failure in SIMM 3. If SIMM 3 has failed, the firmware reports a failure in SIMM 3. > > Even knowing that, I’m not sure I want to > invest hundreds in new RAM for a machine whose b-cache is known to be a > ticking time bomb. (1000s and 1000As have notoriously unreliable b-cache) > I might be willing to swap my AS1000A RAM (some of which may be faulty and I probably can't test it unless I can resurrect one of my machines briefly) for memory for a PWS 500, Alphaserver 2100 or an Alphaserver 800. Regards, Peter Coghlan.
DEC 3000 (alpha) faultfinding
I've got a DEC 3000 model 300 and a couple of DEC 3000 model 600 alphas which failed some time ago and the recent Alphaservers thread has rekindled my interest in getting them working again. A couple of years ago, there was another thread "AlphaStation 200 NVRAM Problem" where the Alpha SROM mini console and various items of useful documentation were mentioned. I have now made up an adapter (cable and MAX232 line driver / receiver) as described in that thread to allow me to to talk to the the SROM mini console in my alphas and I am please to find they are all responsive at this level. I also found: "DEC 3000 300/400/500/600/700/800/900 AXP Models System Programmer's Manual Order Number: EK-D3SYS-PM. B01" (d3syspmb.pdf) which describes some of the internals of the machines in question. The mini console commands available on the model 300 are very limited compared to those in the documentation which targets a much later machine. However, it does have mt (memory test) which is not present on the model 600 for some reason. Results from this suggests that all 6 SIMMs present are bad in pretty much all locations. This seems a bit unlikely to me. Perhaps there is a failure in logic which causes the memory not to be accessed at all? Unfortunately, the manual does not seem to give any leads on how to diagnose this further. The em (examine memory) and dm (deposit memory) commands only accept 32 bit addresses meaning they cannot to be used to access input/output areas which require at least 33 bit addresses. However, a little experimentation led me to the existance of ei and di commands which can do this on the DEC 3000 machines and I found I can use di to update the diagnostic LEDs on the machines. The DEC 3000 600 machines both (usually) count down to F0 on their diagnostic LEDs and hang without producting any output on the main console. They do however produce output on the mini console - for example: DEC 3000 - M600 SROM 6.1 Powerup Sequence ff.fd.fb.fa.f9.f8.f7.f6.f5.f4.f3.f2.f1.f0. sysROM 0033.06f1 ioROM 0033.0162 MCRstat .808011c0 bnkSize 0300.0c01 memSize 00c0.00c0 However, they do not provide the SROM> prompt or accept mini console commands unless a I engineer another fault condition such as by pulling out one of the memory risers. I wonder if there is a jumper to enable mini console commands to be accepted without doing this? Looking around the system board, I see a pair of jumper pins labelled J9 hidden under the I/O board which looks like it could do this. Unfortunately, while there is legend on the PCB indicating the function of all other jumpers, there is none for J9 and it is not mentioned in the manual either. On the I/O board, there is one three pin jumper labelled simply "Off" and "On" and it is jumpered to the "On" side. It is close to the SCSI connector so I suspect it is more likely to be something to do with termination or termpwr than the mini console. One of the model 600s sometimes generates a machine check, like this: DEC 3000 - M600 SROM 6.1 Powerup Sequence ff.fd.fb.fa.f9.20. MCHK exc_addr.1484 biu_stat.22d8 dc_stat .0007 fill_adr0001.f0080050 fill_syn. DataExp . DataRec . MCRstat .808011c0 bnkSize 0300.0c01 memSize 00c0.00c0 SROM> While this can be useful because it gets me to the SROM> prompt, I can't find anything in the manual which helps me diagnose what might be causing this. The meaning of the contents of biu_stat might be a useful start. The 600 machines have a socketed 27C512 EPROM. I assume this must be the SROM (although I can't see what is serial about it) as the machines fail to update the diagnostic LEDs or write to the mini console if it is removed. I dumped the two EPROMs and compared them and they are identical. However, I can't see any ASCII strings in them. Perhaps the bits are not used in the standard order? The manual suggests that there are 8 different 8KB SROM images present and those other than the "standard" one may be used for testing and diagnostics by setting jumpers. Unfortunatly, there is no further information about these images. The manual hints that the System ROM (SYSROM) (actually an FEPROM) is located at 1 E000 to 1 E003 , however, looking at the beginning of this area with ei suggests it is in fact the IOROM (also an FEPROM). Hunting around some more, it seems that setting bit 9 of the System Support Register at 1 E004 0100 brings in the SYSROM instead (although the manual suggests bit 7 is also involved which seems unlikely as this bit is one of the diagnostic LEDs). The format of the headers in the SYSROM and IOROM do not exactly match the format given in the manual but they are "close". I wonder if this might be my problem or if the manual is incorrect. If anyone else has a 3000 600, could they take a peek at their
