Re: Future of classiccmp
that relationship has become quite difficult lately. So much so, that I'm ready to just turn it off and walk away. I'm sorry, but I have reached the point in my life where that stress outweighs the benefits. Throw in to the mix that for whatever reason - while I have dutifully taken care of this list and a lot of other related websites for probably 15+ years or more ... I think it's time for fresh eyes and attitudes to carry it forward. I hope no one begrudges me for after decades finally saying "it's time". I have enjoyed being of service. Second, I do not wish to pass this off to someone who "has a server in their basement" or has spare space on a vps. While I appreciate these offers and the desire to help, I'm not sure you have full knowledge of what all is here. Putting it on a "PC in your basement" is not the environment this stuff requires. At the very least, asymmetric bandwidth (what most people have in their homes) is a non-starter. Sneaking it on to your company infrastructure isn't good either, as there is almost always a builtin "need to move this stuff soon" disruption in store. Also, I am definitely not leaving the hobby; I just look forward to participating as an end-user instead of host. Just as a heads up at the same time I am looking to thin my herd; not because I've lost interest but because I want to gain focus. Jay: Thank you for all that you've done in this hobby! I left VCFed six months ago for (pretty much) the same four reasons as you cited above.
Re: Ancient transistor ?computer board (Peter Van Peborgh)
Hi Peter, That is a stunning board, and in beautiful condition. The square cubes are transformers, most likely some sort of pulse transformer on the base of the transistor. A multimeter will tell you in quick form. Doug Kindest regards, Doug Jackson em: d...@doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net --- Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard - for this I apologise in advance - It's ok bec we don* nee* accu tex* to unde** actu** mean***. Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-) Be nice to your parents. Go outside and do something awesome - Draw, paint, walk, Setup a radio station, go fishing or sailing - just do something that makes you happy. On Fri, Jun 19, 2020 at 6:14 AM Peter Van Peborgh via cctech < cct...@classiccmp.org> wrote: > OK, now here are some pics that should be available to everybody. I hope. > > https://photos.app.goo.gl/h64tye8ecmPHQfJD7 > > Smells of (early) 1960s transistorized. > No helpful marking apart from > * "GATE JJ01" on SIDE A. (components). > * "C NT OL DATA" on side B (solder traces). > > Big transistors are Motorola "180376008". Also, any ideas what the "246 636 > B" boxes are, they have four legs? > > A curse on TinyURL and praise to Camiel Vanderhoven. > > peter > >
Origin of 3-D printing (again)
Hi, Back in 2017, I posted something about seeing a possible first-ever reference to the idea of 3-D printing in a 1951 issue of Galaxy Science Fiction magazine. I stumbled over an even earlier one tonight... The September, 1941, issue of Astounding Science Fiction magazine has a story called "Elsewhere" by Caleb Saunders (a pseudonym of Robert A. Heinlein). On page 118 we see: [They used] a single general type of machine to manufacture almost anything. They fed into it a plan which Igor called, for want of a better term, the blueprints. It was, in fact, a careful scale model of the device to be manufactured; the machine retooled itself and produced the artifact. A three-dimensional pantograph, Igor called the machine, vaguely and inaccurately. One of them was, at that moment, molding the bodies of fighting planes out. of plastic, all in one piece and in one operation. Stan
RE: Future of cctalk/cctech
Tony Aiuto wrote >It's time to adopt a platform that can handle modern mail. >Some may still choose a degraded experience, but everyone is entitled to their >own fetish. Yes, everyone is free to chose to use the list or the discord server or whatever is down the road years from now; but as a side note, the irony of posting that on a mailing list dedicated to teletypes and perkin elmers and 1401's and such... is not lost I'm sure 😊 J
Re: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 9:47 AM geneb via cctalk wrote: > On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote: > > > 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??? > > > > Yes, you too can produce a bountiful word salad with UTF-16 characters in > place of spaces! Amaze your friends! Women will want you! Men will want > to BE you! > > g. > I don't mean to point at anyone on this thread. I'm not good at seeing who is serious or sarcastic in this thread, and I really don't care, because this This conversation has come up again and again and gotten stale. It fundamentally amounts to a few people asserting "There is nothing worth saying that can't be said with the 25 letters of the English alphabet, so therefore the list should only include text that I can't read on a teletype". I say enough. We live in a remarkable world where it is possible to share knowledge and experiences with people from all over the world. Some of them might be disruptive enough to have things like ASCII-inconvenient accented characters in their names. I would like to be able to spell my friends and colleagues' names correctly. And sometimes, a picture really is worth 1000 words. A tiny SVG diagram in the middle of a description can do wonders. Did your physics textbook pull all the diagrams out to an appendix, just leaving a reference in the text? No it didn't. That would have been inconvenient and unnecessary. Except for those who choose otherwise, we all have the capability to view mail that presents like any other printed matter. It's time to adopt a platform that can handle modern mail. Some may still choose a degraded experience, but everyone is entitled to their own fetish.
Re: Attachments
On Thu, Jun 18, 2020 at 5:01 AM Peter Corlett via cctalk < cctalk@classiccmp.org> wrote: > On Wed, Jun 17, 2020 at 10:50:20PM +0100, Rob Jarratt via cctalk wrote: > [...] > > Easy, pictures of unidentified components, sending out schematics that > have > > been reverse engineered, documentation, pictures of scope traces when > trying > > to find a fault, all sorts. I would agree on a size limit though. > > The kind of size limit required to keep attachments small enough to not > annoy > people who are not interested in them would be too low for this purpose. > The > annoyance increases further when people with broken email clients (or who > just > never bothered to learn their tools) include senders' attachments in their > replies. > This is a tradeoff. - Allowing, let's say, 50MB attachments would enhance the experience for some people. I suspect there are many of them on this list. - Allowing any attachments at all would annoy some people. They tend to post a lot about how annoyed they would be. I suspect there are fewer of them than the others. - Allowing tiny attachments doesn't please anyone. A typical digicam or scanner produces multi-megabyte files. Reducing them in > size to fit within e.g. a 1MB limit would still cause the same level of > inconvenience to the sender as uploading it somewhere and posting a link as > well as reducing the quality and utility to those who are interested. I also note an inverse relationship between the size of an email and the > quality of its contents > Further, an orders-of-magnitude explosion in the resources used by this > list > would reduce the number of people willing to host it. My shell server > which I > use for mail is perhaps typical: it has a 20TB/month transfer cap which is > effectively infinite, but its 20GB disk would be eventually consumed by > all of > those attachments kept forever in the list archives that people also want. > A *person* willing to host it is the wrong approach. That makes the truck number 1. For redundancy you need to pay a service to host it, and have a few people with administrative rights. If people are scared of the service turning down and losing all history, they can personally archive every message.
Re: Ancient transistor ?computer board (Peter Van Peborgh)
Remember buying boards like that at electronics surplus places in late 60's but never knew where they came from. Just used them as a cheap source of parts. Also suspect the black boxes are pulse transformers although all of the pulse transformers I pulled off boards were circular. Never thought much then about where they came from and just got ones with most transistors and diodes on them so could make DTL logic gates from them. Think a board like that might have gone for $1-2 back then which was way cheaper than buying new transistors and diodes in those days and TTL IC's were ridiculously expensive then. Boris Gimbarzevsky OK, now here are some pics that should be available to everybody. I hope. https://photos.app.goo.gl/h64tye8ecmPHQfJD7 Smells of (early) 1960s transistorized. No helpful marking apart from * "GATE JJ01" on SIDE A. (components). * "C NT OL DATA" on side B (solder traces). Big transistors are Motorola "180376008". Also, any ideas what the "246 636 B" boxes are, they have four legs? A curse on TinyURL and praise to Camiel Vanderhoven. peter
Re: PLATO V Terminal
> On Jun 18, 2020, at 5:53 PM, Chuck Guzis via cctalk > wrote: > > On 6/18/20 1:19 PM, Paul Koning wrote: >> > >> Nice. Yes, airfight and any number of other multi-user games -- a >> thing made popular by PLATO and possibly originated there. There is >> a running PLATO system around, see www.cyber1.org for details. Its >> users normally use a terminal emulators, but real terminals can be >> connected to it and a few are around that are set up that way. > > In my collection, I've got a 5.25" (360K) floppy sent to me back in the > day that has the PLATO software for the IBM PC. Other than filing the > disk away, I never thought to boot it and see what was there. > > Still have the disk, though. I don't imagine that it's particularly rare. I don't know. My PLATO experience predates the PC. Are you sure that's what it is? The later PLATO terminals (starting with the "PLATO V" one, in fact) had local execution capability, and some of them included a floppy drive for local program load. Those would be essentially PLATO software executing on the terminal rather that at the host. If so, recovering that information may turn up something not previously preserved. If it is indeed a PLATO terminal implemented as PC software, you could hook it up to Cyber1. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 5:47 PM, Antonio Carlini via cctalk > wrote: > > ... >> 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. Not with modems, but of course the "local" line cards (coax pairs) for the DMC/DMR/DMP sync DDCMP controllers could go at 1 Mb/s. DMC only barely (with a few bugs). The DMV doesn't have that capability if I remember right. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 7:21 PM, Pete Turnbull via cctalk > wrote: > > On 18/06/2020 21:31, Paul Koning via cctalk wrote: > >> I did see something vaguely similar. Bell 202 modems are 1200 baud FSK, so >> on a voice channel they normally are 1200 bps half duplex. They can also be >> hooked up to 4-wire fixed circuits. But they have a reverse channel, good >> for 150 baud if I remember right. > > IIRC the Bell standard allows for only 50 baud and the back channel uses ASK > (basically switching a carrier on and off). That rings a bell (so to speak). Chances are those specs were all pretty lenient and the 126 bps used by PLATO was non-standard but not a real problem. I don't know how common those connections were or what distance was needed. A large number of PLATO terminals were fed via a microwave video signal. That was a pretty neat setup: all 1008 terminal lines, TDM muxed into what looked like a video signal (so 60 frames per second). Devices called "site controllers" would receive that and extract the data streams for 32 terminals from that data. They'd also accept the 126 bps terminal->host data stream and stat-mux it into a single data stream going to the host, I don't remember seeing the format for that. The data center had a TV monitor that showed the outgoing signal. It looked vaguely like a punched card with a lot more than the usual number of holes in it. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 5:55 PM, Peter Coghlan via cctalk > wrote: > > ... > 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? Yes. Both sides are looking for a receive clock to tell them were the incoming bits begin, and a transmit clock to control the shifting out of the transmit bits. Any speed should work so long as it's slow enough. So a 555 feeding a MAX232 should be fine. Most variants of that device have several drivers so you can split the four loads over more than one driver if you want to. That's probably not necessary. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 6/18/20 2:55 PM, Peter Coghlan via cctalk wrote: > Ethan Dicks wrote: > 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? Sync, in my recollection, is a bit fussier than async with respect to the clock signal. Unlike async, which "samples" the bit cell more-or-less in the center (hexce the 16x or 64x clock rate), synchronous is edge-sampled, so that the clock signal must match the data signal with respect to phase. The clock signal for receive data is recovered by the receiving modem and so is always in-phase. Such stuff as protocol details can differ greatly (e.g. Bisync vs. SDLC), but remember that there are no start or stop bits like as in async. Synchronization is done by pattern-matching with "idle" bits being sent to fill gaps or to form preamble to sync. In some respects, not terribly different from hard disk recording. It's been years since I fooled with the stuff, so I may have quite a bit wrong. --Chuck
Re: mail on spool as G-d intended was Re: Future of cctalk/cctech
Sometimes I'll log into alembic and read my mail with BABYL. On 6/18/2020 6:03 PM, Eric Korpela via cctalk wrote: I used to use netcat, but now I just watch an oscilloscope. On Wed, Jun 17, 2020 at 1:41 PM Cameron Kaiser via cctalk < cctalk@classiccmp.org> wrote: I read this list on PINE, on a shell account at my ISP. Barbarian! At least upgrade to Alpine. (That's what I use.) :D Philistines, all of you. I use a hacked version of Elm. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Never interrupt your enemy when he is making a mistake. -- Napoleon
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 18/06/2020 21:31, Paul Koning via cctalk wrote: I did see something vaguely similar. Bell 202 modems are 1200 baud FSK, so on a voice channel they normally are 1200 bps half duplex. They can also be hooked up to 4-wire fixed circuits. But they have a reverse channel, good for 150 baud if I remember right. IIRC the Bell standard allows for only 50 baud and the back channel uses ASK (basically switching a carrier on and off). The CCITT equivalent standard is 1200/75 baud, FSK both ways, and in the 1980s and early 90s that was used for Prestel and similar systems, including Micronet, Telecom Gold email, Packet SwitchStream (PSS), BT Tymnet and some online banking systems, here in the UK. It was also used for Minitel in France, BTX in Germany and later for Telidon in Canada. Some of the UK banking systems like HOBS survived using viewdata that way up to the end of the 1990s, and I still have at least a couple of 1275 modems. The idea was to use 1200 for the transmission from central computer to consumer, and the back channel for user responses/commands. Not many people type faster than 7.5cps. -- Pete Pete Turnbull
Re: mail on spool as G-d intended was Re: Future of cctalk/cctech
On 18/06/2020 23:03, Eric Korpela via cctalk wrote: I used to use netcat, but now I just watch an oscilloscope. Reminds me of a cartoon in a HiFi mag several years ago. Enthusiast talking to friend in front of dual 'scopes, "Why listen to it when I can see it's perfect?" -- Pete Pete Turnbull
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
On Thu, Jun 18, 2020 at 6:08 PM Peter Coghlan via cctalk wrote: > Ethan Dicks wrote: > > 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... > 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 have an abundance of 1488/1489 chips, but I used to make comms devices. I only have a few MAX232 devices not already baked into projects. > 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? It does need to be the same on both ends, and, yes, a 555 should work, but it's unlikely to be within 1% of a "real" rate. > 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? Yes. Pins 15 and 17 on both ends. 4 loads. You can do asymmetric speeds, but the TX for one end has to match the RX for the other end. I see some discussion of that in this thread, but in my experience, we always had same-room direct connect lines, or dial-up lines over POTS and modem speeds like 1200 bps or 2400 bps because we didn't want to pay for leased or conditioned lines. Every connection I ever set up was symmetric. 99.9% were 56kbps or slower. -ethan
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: mail on spool as G-d intended was Re: Future of cctalk/cctech
I used to use netcat, but now I just watch an oscilloscope. On Wed, Jun 17, 2020 at 1:41 PM Cameron Kaiser via cctalk < cctalk@classiccmp.org> wrote: > > > I read this list on PINE, on a shell account at my ISP. > > > > Barbarian! At least upgrade to Alpine. (That's what I use.) :D > > Philistines, all of you. I use a hacked version of Elm. > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- Never interrupt your enemy when he is making a mistake. -- Napoleon > > -- Eric Korpela korp...@ssl.berkeley.edu AST:7731^29u18e3
Re: PLATO V Terminal
On 6/18/20 1:19 PM, Paul Koning wrote: > > Nice. Yes, airfight and any number of other multi-user games -- a > thing made popular by PLATO and possibly originated there. There is > a running PLATO system around, see www.cyber1.org for details. Its > users normally use a terminal emulators, but real terminals can be > connected to it and a few are around that are set up that way. In my collection, I've got a 5.25" (360K) floppy sent to me back in the day that has the PLATO software for the IBM PC. Other than filing the disk away, I never thought to boot it and see what was there. Still have the disk, though. I don't imagine that it's particularly rare. --Chuck
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
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. 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 --- ZSA0 ZS_DST32 UCB address: 814EAA40 [snip] Wonderfully confusing :-) 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 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 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. 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. Antonio -- Antonio Carlini anto...@acarlini.com
Ancient transistor ?computer board (Peter Van Peborgh)
OK, now here are some pics that should be available to everybody. I hope. https://photos.app.goo.gl/h64tye8ecmPHQfJD7 Smells of (early) 1960s transistorized. No helpful marking apart from * "GATE JJ01" on SIDE A. (components). * "C NT OL DATA" on side B (solder traces). Big transistors are Motorola "180376008". Also, any ideas what the "246 636 B" boxes are, they have four legs? A curse on TinyURL and praise to Camiel Vanderhoven. peter
Re: Ancient transistor ?computer board (Peter Van Peborgh)
On 06/18/2020 03:14 PM, Peter Van Peborgh via cctech wrote: Big transistors are Motorola "180376008". Those would be "house numbers" in the customer's part numbering system. Also, any ideas what the "246 636 B" boxes are, they have four legs? Most likely pulse transformers. This might be a core memory sense amp/inhibit driver board. Jon
Re: Ancient transistor ?computer board (Peter Van Peborgh)
On 06/18/2020 03:14 PM, Peter Van Peborgh via cctech wrote: * "C NT OL DATA" on side B (solder traces). Sure looks like Control Data, a major manufacturer of mainframe computers in the 60's and 70's. And, being all discrete transistors, that would likely be late 60's. Jon
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 2020-06-18 3:34 p.m., Chuck Guzis via cctalk wrote: On 6/18/20 6:06 AM, Peter Coghlan via cctalk wrote: 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. We would have been delighted to get 19.2K on our 11/750. Leased line with a Bell 209 modem, 9600 sync. Back then, that ran about $5K/month for the hookup. --Chuck When I started out in customer service many years ago anything faster than 9600 was very rare and even then they where often split off using stat muxes or multi-drop lines. I call one store have a 9600 line back to head office in Toronto that served two store controllers, four 3777s with 3203 to print orders, one with a tape drive to transmit orders entered on a Nixdorf mini, as well as some miscellaneous terminals in the local warehouse and order office. It was not uncommon for users of 3270 terminals to have the controllers in a few offices sharing a multi-drop line, the banks did the same thing with their terminal controllers and ATMs. I also remember some data centers having conditioned dial-up lines that included a handset that you could talk on, but it was pretty weird as the conditioned lines did not have echo suppressors. The first banking terminal I worked on where on a multi-drop 300 baud async line and I also worked on finance company terminals that where on a multi-drop telegraph line at a speedy 75 baud. Paul.
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 3:26 PM, Ethan Dicks via cctalk > wrote: > > On Thu, Jun 18, 2020 at 3:08 PM Chuck Guzis via cctalk > wrote: >> On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: >> >>> We used to run our sync serial stuff between 9600 and 56kbps, both our >>> own Bisync products, and DDCMP over interfaces like the one that's >>> part of the DMF32... >> >> My recollection of the Bell 209 is that it supported a low-speed reverse >> channel in addition to the FDX primary. > > I had to look that up. Yes. I see that in the spec, at *5*bps. Wow, that's weird. >> Did any DEC equipment ever take advantage of that? > > I've never encountered it before, so I cannot confirm. Not that I know of. I did see something vaguely similar. Bell 202 modems are 1200 baud FSK, so on a voice channel they normally are 1200 bps half duplex. They can also be hooked up to 4-wire fixed circuits. But they have a reverse channel, good for 150 baud if I remember right. PLATO used that in its original terminal connections, in a slightly strange way: 1260 bps data to the terminal, and 126 bps data from terminal to host. The protocols are peculiar: terminal output is "synchronous", 21 bit frames at 60 frames per second, but each frame has a start bit (no stop bit). Data to the host is asynchronous, 1 start, 1 stop bit, 10 data bits. Since a 202 modem is just plain FSK, it doesn't matter that the data rate is not quite the standard 1200 bps. paul
Re: mail on spool as G-d intended was Re: Future of cctalk/cctech
On 6/18/2020 6:33 AM, Jan-Benedict Glaw via cctalk wrote: Indeed. I get quite a lot of emails and mutt allows me to properly fight back. err Mutt bites back. I use whats free. Ben.
Re: PLATO V Terminal
> On Jun 18, 2020, at 3:12 PM, Chuck Guzis via cctalk > wrote: > > On 6/18/20 4:18 AM, Tom Hunter via cctalk wrote: >> I have been "hunting" for a PLATO V terminal for some time. It was made by >> Regency - Carroll. >> >> If there is such a terminal gathering dust in a shed or garage and the >> owner would like to find a good home for it then please let me know. >> >> I have successfully restored a Control Data Corp IST-3 terminal and 721 >> Viking terminal and have the skills, equipment and passion to restore the >> terminal to its former beauty and functionality. > > So what does one do with a PLATO terminal? I was acquainted only with > the PLATO IV terminal and, although I took a couple of CDC-mandated > courses on it (don't remember a thing), I mostly sneaked time to play > AIRFIGHT. > > At one NCC, I remember asking the folks in the PLATO booth if they > minded if I checked out their setup. Since there was virtually no one > around, I brought up AIRFIGHT. Within 10 minutes, I had a crowd > straining for a peek. Nice. Yes, airfight and any number of other multi-user games -- a thing made popular by PLATO and possibly originated there. There is a running PLATO system around, see www.cyber1.org for details. Its users normally use a terminal emulators, but real terminals can be connected to it and a few are around that are set up that way. paul
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 3:08 PM Chuck Guzis via cctalk wrote: > On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: > > > We used to run our sync serial stuff between 9600 and 56kbps, both our > > own Bisync products, and DDCMP over interfaces like the one that's > > part of the DMF32... > > My recollection of the Bell 209 is that it supported a low-speed reverse > channel in addition to the FDX primary. I had to look that up. Yes. I see that in the spec, at *5*bps. > Did any DEC equipment ever take advantage of that? I've never encountered it before, so I cannot confirm. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote: > 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. Yep, last Sat on the VAX/NetBSD mailing list. Maciej
Re: PLATO V Terminal
On 6/18/20 4:18 AM, Tom Hunter via cctalk wrote: > I have been "hunting" for a PLATO V terminal for some time. It was made by > Regency - Carroll. > > If there is such a terminal gathering dust in a shed or garage and the > owner would like to find a good home for it then please let me know. > > I have successfully restored a Control Data Corp IST-3 terminal and 721 > Viking terminal and have the skills, equipment and passion to restore the > terminal to its former beauty and functionality. So what does one do with a PLATO terminal? I was acquainted only with the PLATO IV terminal and, although I took a couple of CDC-mandated courses on it (don't remember a thing), I mostly sneaked time to play AIRFIGHT. At one NCC, I remember asking the folks in the PLATO booth if they minded if I checked out their setup. Since there was virtually no one around, I brought up AIRFIGHT. Within 10 minutes, I had a crowd straining for a peek. That's now you sell hardware! --Chuck
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 6/18/20 11:55 AM, Ethan Dicks via cctalk wrote: > We used to run our sync serial stuff between 9600 and 56kbps, both our > own Bisync products, and DDCMP over interfaces like the one that's > part of the DMF32. We had customers in Europe running our products at > 64kbps with no problems, and we did have one modem eliminator clocked > at 115kbps for testing, which is the max speed for V.24, IIRC. > > 56kbps should be safe for the devices you are describing, but it might > go a little faster. My recollection of the Bell 209 is that it supported a low-speed reverse channel in addition to the FDX primary. Did any DEC equipment ever take advantage of that? --Chuck
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
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. > 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. 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. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 2:48 PM Paul Koning via cctalk wrote: > > On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk > > wrote: > > 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, ... > > 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. We used to run our sync serial stuff between 9600 and 56kbps, both our own Bisync products, and DDCMP over interfaces like the one that's part of the DMF32. We had customers in Europe running our products at 64kbps with no problems, and we did have one modem eliminator clocked at 115kbps for testing, which is the max speed for V.24, IIRC. 56kbps should be safe for the devices you are describing, but it might go a little faster. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
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. -ethan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 18, 2020, at 2:14 PM, Peter Coghlan via cctalk > wrote: > > ... > 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, ... 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. paul
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
On 6/18/20 6:06 AM, Peter Coghlan via cctalk wrote: > 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. We would have been delighted to get 19.2K on our 11/750. Leased line with a Bell 209 modem, 9600 sync. Back then, that ran about $5K/month for the hookup. --Chuck
RE: Future of classiccmp
The period of me making decisions about the list is coming to an end, but based on all the posts I just caught up with here's some thoughts: I would be predisposed to handing it to someone that intends to continue the mailing list format. We already have a very active discord group (which works fantastic for posting pics with your posts), so I see little reason to move to a web based format for this list. Most of us are here cause we prefer the email format. Those who don't - use the discord server, those who like both - use both 😊 Picture attachments have been a shortcoming here, there's times when it would be really nice. There are also situations where its likely to be abused especially in the eyes of those who prefer the email format. I would suggest either allow pic posts but only if 1000% on-topic, and even better yet, only allow pics if the mailing list automatically stores them somewhere and only puts a link to the pic in the email. That way, the email stays text only, and users that want to see the pic can. Another approach is maybe 'if you need to post pics, do it on the discord'. One or the other, but the email list should stay a text email service IMHO. I did not like the list splitting (cctalk/cctech) when it was done, and still don't. I have intended to rejoin the lists into one list for the past few years and just never got around to it. I will be asking whoever winds up getting the list to do the following tasks as part of the agreement: 1) Rejoin the lists, 2) completely straighten out the archives. Get all the missing stuff, make it all processed and stored in the same way (downloadable archives or text scannable online), and automated. I am embarrassed by how I have let the archives degenerate, but they are still fix-up-able. Whoever takes on the list needs to be prepared to do this as well.
PLATO V Terminal
I have been "hunting" for a PLATO V terminal for some time. It was made by Regency - Carroll. If there is such a terminal gathering dust in a shed or garage and the owner would like to find a good home for it then please let me know. I have successfully restored a Control Data Corp IST-3 terminal and 721 Viking terminal and have the skills, equipment and passion to restore the terminal to its former beauty and functionality. Tom Hunter
Future of classiccmp
Al wrote: >With Jay retiring, what are the hosting plans for these mailing lists? Well at least for me, there's more to it than that 😊 I retired from general work on 4/30/20. My consulting firm is going to be kept open on paper for a few years at least but I doubt I will be transacting much business through it. I guess if someone comes by with a short project that I find interesting, I may do it through that company but mostly it's staying open to handle a few germane expenses. All staff and offices are gone and regular payrolls ended 4/30. That leaves the hosting company for me to determine scope/future. Since that company (as long as you are proactive with admin tasks) takes virtually zero work and allows me to have a grossly oversized but paid for full-on high availability virtualization architecture, I was going to keep it going during retirement with just a few very low maintenance customers that cover the costs. I basically can then host any personal/hobby related sites for myself and friends at literally zero cost. In this company I do have one business partner, and that relationship has become quite difficult lately. So much so, that I'm ready to just turn it off and walk away. I'm sorry, but I have reached the point in my life where that stress outweighs the benefits. This infrastructure is of course where I've hosted not only the classiccmp mailing list, but a fair chunk of other classic computing related websites and services at zero cost to their respective owners. Throw in to the mix that for whatever reason - while I have dutifully taken care of this list and a lot of other related websites for probably 15+ years or more - I honestly don't feel that I am doing a good job of it's care & feeding lately. I think it's time for fresh eyes and attitudes to carry it forward. I hope no one begrudges me for after decades finally saying "it's time". I have enjoyed being of service. First and foremost, there is no worry about future hosting plans for above content. I'm not going to just turn it off one day - the grizzled veterans here that know me well know that I would not let that happen. There is no sense of immediate urgency nor any possibility of data just disappearing. That being said, I do wish to move steadily forward with those plans. Second, I do not wish to pass this off to someone who "has a server in their basement" or has spare space on a vps. While I appreciate these offers and the desire to help, I'm not sure you have full knowledge of what all is here. Putting it on a "PC in your basement" is not the environment this stuff requires. At the very least, asymmetric bandwidth (what most people have in their homes) is a non-starter. Sneaking it on to your company infrastructure isn't good either, as there is almost always a builtin "need to move this stuff soon" disruption in store. I've already been working with folks in this community to figure out what to offload, where, how, etc. That work will continue, and I suspect that each separate migration will go off transparently with little or no outward signs of change. Also, I am definitely not leaving the hobby; I just look forward to participating as an end-user instead of host. Just as a heads up at the same time I am looking to thin my herd; not because I've lost interest but because I want to gain focus. That means most likely that I will be moving out a lot of choice DEC, Data General, Heathkit, and related items. I will post separately on that topic, but at the least I am going to keep/focus on HP and a couple others. Will post more info once I have it 😊 Best, J
Re: Future of cctalk/cctech
On Wed, Jun 17, 2020 at 09:46:53AM -0500, John Foust via cctalk wrote: > > I'm most puzzled by the eager hosting volunteers who'd volunteer even before > they have a full understanding of the job. Wouldn't you want to know > how much time it might take you to administer the list, how much > bandwidth it eats, storage, format of the archives, etc.? I can't speak for anyone else, but in my case: I've been running mailing lists for 35-ish years, so I may have a fairly good handle on the scope. To address some of those points: administering a migrated mailing list -- once it's past the transition -- requires very little effort. How much effort it takes during the transition can be guesstimated via the number of users and their aggregate clue level, e.g., technical lists are usually much easier because people on them know how to speak to Mailman/majordomo/et.al. or can figure it out. Bandwidth is inconsequential for all but the largest/busiest lists, e.g., thousands of subscribers X thousands of messages a day. Storage is too: I have decades of archives of a few thousand mailing lists and they fit comfortably on a 250G drive without even bothering to compress them. Archives, if kept in mbox format, are easy to manipulate, combine, separate, etc. If they're not in mbox format, tools like formail can assist in making them so. (It's not at all unreasonable for every member of a mailing list like this one to stash a complete copy of the archive as insurance.) This isn't entirely pain-free: I run a mailing list with an approximately 250,000-message archive accumulated over many years over multiple hosts, and there a few outlier messages that Mailman's archiver won't process. But: "few", so while it's an annoyance it's really quite a minor problem. ---rsk
Re: Amiga Vendors?
On Thu, 18 Jun 2020, Peter Corlett via cctalk wrote: > DB-23 to SCART cables were (and still are) readily-available from anywhere > that > has anything to do with the Amiga. Sometimes they had sawn-down DB-25 plugs > since DB-23 wasn't exactly a common connector even in the Amiga's heyday. Unsurprisingly, given that the shell chosen isn't really DB nor any of the remaining D-sub standard DA, DC, DD, DE shell sizes (which may then come in various signal, power or RF pin configurations, e.g. the Sun DB-13W3, or DEC DA-3W3, or VGA DE-15 connectors). They could have opted for standard DA-26 if they were after connector space saving rather than locking customers into an inherently more expensive proprietary solution. Maciej
RE: Future of cctalk/cctech
On Thu, 18 Jun 2020, Peter Coghlan via cctalk wrote: 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??? Yes, you too can produce a bountiful word salad with UTF-16 characters in place of spaces! Amaze your friends! Women will want you! Men will want to BE you! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
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: Future of cctalk/cctech - text encoding
> On Jun 18, 2020, at 4:03 AM, Lars Brinkhoff via cctalk > wrote: > > 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.
Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 09:42:16AM +0100, Dave Wade via cctalk wrote: [...] > I wrote this as one dollar => $1.00 > This as one pound => $1 > And this as one euro => €1 > Lastly one cent => ¢1 This came over the wire as follows: > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: quoted-printable [...] > I wrote this as one dollar =3D> $1.00 > This as one pound =3D> $1 > And this as one euro =3D> =E2=82=AC1 > Lastly one cent =3D> =C2=A21 IOW, it has the correct headers to unambiguously decode the text. Whether the receiving software is competent enough to handle Q-P UTF-8 text is something else entirely, especially if it's in an obscure or recently-added script or symbol set where suitable fonts don't exist or haven't been installed, but your example doesn't contain any difficult code points. The correct Q-P UTF-8 encoding for "£" is "=C2=A3". (I've dealt with so much broken software that I know this without looking it up.) It seems likely that it got mangled by something at your end in whatever converts it to "modern" (1993) email format.
Re: mail on spool as G-d intended was Re: Future of cctalk/cctech
On Wed, 2020-06-17 16:44:26 -0400, Diane Bruce via cctalk wrote: > On Wed, Jun 17, 2020 at 01:41:39PM -0700, Cameron Kaiser via cctalk wrote: > > > > I read this list on PINE, on a shell account at my ISP. > > > > > > Barbarian! At least upgrade to Alpine. (That's what I use.) :D > > > > Philistines, all of you. I use a hacked version of Elm. > > mutt! Indeed. I get quite a lot of emails and mutt allows me to properly fight back. MfG, JBG --
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
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. Paul.
Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, 18 Jun 2020 at 11:10, ED SHARPE via cctalk wrote: > > Dave -- I suppose the solve is to write it out long hand as in > One Dollar One Cent One Pound... Dear hypothetical deities, no. That causes problems with translation, people not knowing the name of another country's currency in a foreign language, etc. There is a standardized internationally-agreed set of 3 ASCII letter symbols for this reason and this is why people use them. USD = US dollar GBP = GB pound EUR = Euro CZK = Czech crown (korun/koruny/koruna, depending on quantity, in Czech) Etc etc. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: E-Mail Formats RE: Future of cctalk/cctech
On Thu, 18 Jun 2020 at 10:42, Dave Wade via cctalk wrote: > > I wrote this as one dollar => $1.00 Dollar symbol, one > This as one pound => $1 Dollar symbol, 1 > And this as one euro => €1 Euro symbol, one > Lastly one cent => ¢1 Cent symbol, one Fascinating. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
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! 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. 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! Antonio -- Antonio Carlini anto...@acarlini.com
Re: Ancient transistor ?computer board (Peter Van Peborgh)
Nope, those tiny urls still refer to URLs that we can’t open. As was suggested before, these URLs are probably specific to your browser session. > On Jun 18, 2020, at 11:31 AM, Peter Van Peborgh via cctech > wrote: > > Sorry guys about the unusable tera-URLs. > > To reiterate, I have acquired this board and have trouble assigning it to a > particular computer manufacturer and type: > > > Try this for the photos: > https://tinyurl.com/ydxnzh9g > and > https://tinyurl.com/yb6z3utv > > Smells of (early) 1960s transistorized. > No helpful marking apart from > * "GATE JJ01" on SIDE A. (components). > * "C NT OL DATA" on side B (solder traces). > > Big transistors are Motorola "180376008". Also, any ideas what the "246 636 > B" boxes are, they have four legs? > > Can any of you of mature years suggest anything? > > Many thanks, ( praise be to TinyURL), > > peter > > >
Ancient transistor ?computer board (Peter Van Peborgh)
Sorry guys about the unusable tera-URLs. To reiterate, I have acquired this board and have trouble assigning it to a particular computer manufacturer and type: Try this for the photos: https://tinyurl.com/ydxnzh9g and https://tinyurl.com/yb6z3utv Smells of (early) 1960s transistorized. No helpful marking apart from * "GATE JJ01" on SIDE A. (components). * "C NT OL DATA" on side B (solder traces). Big transistors are Motorola "180376008". Also, any ideas what the "246 636 B" boxes are, they have four legs? Can any of you of mature years suggest anything? Many thanks, ( praise be to TinyURL), peter
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: E-Mail Formats RE: Future of cctalk/cctech
Dave -- I suppose the solve is to write it out long hand as in One Dollar One Cent One Pound... I never considered how the monetary vales could get screwed up. Ed#...CIn a message dated 6/18/2020 1:42:27 AM US Mountain Standard Time, cctalk@classiccmp.org writes: > -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 pointsSo:- I wrote this as one dollar => $1.00This as one pound => $1And this as one euro => €1Lastly 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. Dave > 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
Re: Future of cctalk/cctech - text encoding
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 hear MIT-MC is a popular host for mailing lists. Remind me, is ARPANET still up and running?
Re: Attachments
On Wed, Jun 17, 2020 at 10:50:20PM +0100, Rob Jarratt via cctalk wrote: [...] > Easy, pictures of unidentified components, sending out schematics that have > been reverse engineered, documentation, pictures of scope traces when trying > to find a fault, all sorts. I would agree on a size limit though. The kind of size limit required to keep attachments small enough to not annoy people who are not interested in them would be too low for this purpose. The annoyance increases further when people with broken email clients (or who just never bothered to learn their tools) include senders' attachments in their replies. A typical digicam or scanner produces multi-megabyte files. Reducing them in size to fit within e.g. a 1MB limit would still cause the same level of inconvenience to the sender as uploading it somewhere and posting a link as well as reducing the quality and utility to those who are interested. I also note an inverse relationship between the size of an email and the quality of its contents. Further, an orders-of-magnitude explosion in the resources used by this list would reduce the number of people willing to host it. My shell server which I use for mail is perhaps typical: it has a 20TB/month transfer cap which is effectively infinite, but its 20GB disk would be eventually consumed by all of those attachments kept forever in the list archives that people also want.
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: Amiga Vendors?
> -Original Message- > From: cctalk On Behalf Of Peter Corlett via > cctalk > Sent: 18 June 2020 09:38 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: Amiga Vendors? > > On Wed, Jun 17, 2020 at 05:39:44PM -0400, Ethan O'Toole via cctalk wrote: > [...] > > The early plasma TVs usually had BNC RGBHV inputs and such. They could > > take VGA in very easily. I'm pretty sure a PC would have been way > > easier to deal with and could reach much higher resolutions... without > > needing a DB-23 connector :-) > > Everything had RGB on this side of the Pond. There was a protectionist > decree that all TVs sold in France would have a SCART socket, but of course > this just meant that pan-European models sprouted SCART sockets and the > French TV industry was back to square one. Old standards never die, and the > TV I bought in 2018 has a SCART socket and would quite probably decode > SECAM but I have no SECAM sources to test it (and they'll even be rare in > France these days). > The latest TVs do not have anything other tan HDMI. I bought a pile of converter boxes that take SCART and convert to HDMI but for old VGA machines I am just hanging on to my monitors. > DB-23 to SCART cables were (and still are) readily-available from anywhere > that has anything to do with the Amiga. Sometimes they had sawn-down DB- > 25 plugs since DB-23 wasn't exactly a common connector even in the Amiga's > heyday. Dave
E-Mail Formats RE: Future of cctalk/cctech
> -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. Dave > 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' Fredci...@xenosoft.com > >
Re: Amiga Vendors?
On Wed, Jun 17, 2020 at 05:39:44PM -0400, Ethan O'Toole via cctalk wrote: [...] > The early plasma TVs usually had BNC RGBHV inputs and such. They could take > VGA in very easily. I'm pretty sure a PC would have been way easier to deal > with and could reach much higher resolutions... without needing a DB-23 > connector :-) Everything had RGB on this side of the Pond. There was a protectionist decree that all TVs sold in France would have a SCART socket, but of course this just meant that pan-European models sprouted SCART sockets and the French TV industry was back to square one. Old standards never die, and the TV I bought in 2018 has a SCART socket and would quite probably decode SECAM but I have no SECAM sources to test it (and they'll even be rare in France these days). DB-23 to SCART cables were (and still are) readily-available from anywhere that has anything to do with the Amiga. Sometimes they had sawn-down DB-25 plugs since DB-23 wasn't exactly a common connector even in the Amiga's heyday.
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
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. Christian
