Re: Future of cctalk/cctech
On 2020-06-19 11:27 p.m., Al Kossow via cctalk wrote: > >> Images take up a lot of space and are best dealt with via links. > > Which rot over time. > > If you're going to create a permanent archive, you need to archive any > attachments as well. > > http://www.vcfed.org/forum is a perfect example of messages full of link > rot. > Yes, we could have learned from the fact that Photobucket and dozens of other image hosting services chosen arbitrarily by users have disappeared, leaving forums full of posts without context, often making them useless. --Toby
Re: Future of cctalk/cctech
Images take up a lot of space and are best dealt with via links. On Fri, 19 Jun 2020, Al Kossow via cctalk wrote: Which rot over time. If you're going to create a permanent archive, you need to archive any attachments as well. http://www.vcfed.org/forum is a perfect example of messages full of link rot. We need, or at least want, to handle BOTH. Long-term, "permanent" content, as well as the casual "What is this? here's what it looks like" I have no idea whether it is practical to handle those the same, or differently.
Re: Future of cctalk/cctech
Images take up a lot of space and are best dealt with via links. Which rot over time. If you're going to create a permanent archive, you need to archive any attachments as well. http://www.vcfed.org/forum is a perfect example of messages full of link rot.
Re: CSPI SC-3XL and SC-4XL documentation?
It looks like what I’m looking for from CSPI (aka CSP, Inc.) is the “SuperKit” board support, function, and RPC library for the SuperCard SC-3XL and SC-4XL, along with their documentation. There are mentions of it in the Wayback Machine for http://www.cspi.com/ and the vendor is still around, but there’s obviously no mention anywhere on the current web site of this stuff, and I doubt contacting their support would do any good… Does anyone have more detail? Or do I have to reverse-engineer any ROMs that happen to be on these boards? — Chris
Re: Future of cctalk/cctech
Agree that current mailing list format is best as simple, low bandwidth and can always post links to images or other large files. I still use Eudora as my email client and have text only emails. Seems to perplex a lot of people I deal with when I can't read their emails, but it seems somewhat wastefull to use 1-2 Mb to send a message that only needs 200 bytes at most (once one strips off all zero-information fluff from the email). Run my own mailserver as well so can email myself massive attachments when email is only way of getting data off a remote machine. Images take up a lot of space and are best dealt with via links. I've run my own webserver/ftpserver since 1999 and find that's the easiest way of sharing large files with people. While it's nice having high resolution photos like those that Samsung phones creat, they're in the 3-5 Mb size range. If I need to put a lot of photos on a web page, I'll use the free Photo Studio program (written by John Hawkins) which creates a web page with a series of thumbnails with full image available by clicking on thumbnail and can set size of thumbnail image. Rather old, but works fine for simple web pages where all one wants to do is serve up a set of images. Remember 15 years ago that online documentation was sparse but have found most DEC manuals are online and C64 stuff a lot easier to find than it used to be. Being rather paranoid, I've downloaded manuals for all machines I have and keep a duplicate copy of everything. Not sure how many people are on cctalk/cctech, but keeping everything text only would be best way of minimizing bandwidth for whoever hosts it, Boris Gimbarzevsky On Fri, Jun 19, 2020 at 3:31 PM Maciej W. Rozycki via cctalk < cctalk@classiccmp.org> wrote: > Sure, there's always `uuencode' when you do need to post that non-text > piece (which I guess will keep the eyes of Luddites away from it too). > Or an http, https, ftp, or gopher url to somewhere else hosting the image. Pat
Re: Someone's confused
Yes, there was D and F, and F and G versions. Everything else was emulated slowly. Putt putt it was On 6/8/2020 3:26 PM, emanuel stiebler wrote: On 2020-06-08 11:55, Chris Zach via cctalk wrote: 4) The 11/730 could emulate pdp11 instructions, the MV1 could not. Come to think of it I think the 730's floating point could do D,F,G,H while the MV1 could only do D,F,G. IIRC, there were two versions of the MV I board sets with different floating points?
Re: New drive for my 11/83....
Follow-up: Drive is working well and now has a real virgin install of M+ 4.6 on it. I also was able to make a TK50 backup tape of it, and even remembered how to make BRU64K bootable on a RX01 floppy so I can restore it :-) Next step will be to get the 383mb Wren VI disk up and going. ESDI seems to be pretty darn quick, if that works I might stop there or pick up an 8760 drive for 700mb of storage. Far cry from the dual RM02's I used to work with back in the day, but it does seem to work well C On 6/9/2020 11:46 PM, Chris Zach via cctalk wrote: Picked up a CDC 94166 ESDI disk on Ebay last week, arrived and sure enough it works. No errors either, so I can now give my 30+ year old Fujitsu 2322 a rest and load up rsx11m+ instead of 11/m 4.2 After formatting it on the MTI controller (MQD13) I set the first partition to 30mb and loaded up my RT11 5.7 backup from the TK50 onto it with no issues. Productive. If I can find my DEQNA and an AUI to wireless adapter I could get this thing up on the net.
Re: Fixing an RK8E ....
On 6/19/2020 12:24 PM, Robert Armstrong via cctalk wrote: Ok, maybe a bad bit in the command register so I'll check it out. But then it dawns on me - how do you work on this thing? It's three boards connected with "over the top" connectors - you can't use a module extender on it. Worse, the M7105 Major Registers board is the middle one of the stack! Is there some secret to working on this thing? Has anybody fixed one? Any suggestions? I hadn't thought about it before, but the KK8E CPU would have the same problem. Fingers crossed that one never dies... Jack Rubin has worked on this problem a fair bit, and his solution: http://www.vcfed.org/forum/showthread.php?47821-DEC-extender-adapter-for-over-the-top-OMNIBUS-boards Basically he's found a compatible edge connector, and made a little PCB that interfaces it to a a ribbon cable. A couple of those per cable and you are all set. You may want to contact him about acquiring the female edge connectors, as they can only be ordered in bulk. (It might be my turn to order them, if he's out.) Vince
Re: Future of cctalk/cctech
Or an http, https, ftp, or gopher url to somewhere else hosting the image. On Fri, 19 Jun 2020, Maciej W. Rozycki via cctalk wrote: Well, not everyone can afford to host their own site, for various reasons, and if hosting externally you have to agree to T's you may not necessarily be happy about. I thought that it was generally agreed that we were talking about a "files" section on the server(s) hosting the list. That would have a lower resource requirement than including every attachment within every email. (AND them being replicated indefinitely by everybody who doesn't trim their posts)
Re: Fixing an RK8E ....
On Fri, 2020-06-19 at 12:24 -0700, Robert Armstrong via cctech wrote: > It appears that my RK8E has a problem - it fails the diskless > control test > with > > .R DHRKAE.DG > SR= > > COMMAND REGISTER ERROR > PC:1160 GD: CM:0001 > DHRKAE FAILED PC:6726 AC: MQ: FL: > WAITING > > Ok, maybe a bad bit in the command register so I'll check it > out. But then > it dawns on me - how do you work on this thing? It's three boards > connected > with "over the top" connectors - you can't use a module extender on > it. > Worse, the M7105 Major Registers board is the middle one of the > stack! Is > there some secret to working on this thing? Has anybody fixed > one? Any > suggestions? > > I hadn't thought about it before, but the KK8E CPU would have the > same > problem. Fingers crossed that one never dies... > I seem to recall that there were some "special" (read unobtanium) over the top connectors that permitted one of the boards in a board set to be up on an extender. TTFN - Guy
Re: Fixing an RK8E ....
On Fri, Jun 19, 2020 at 12:24 PM Robert Armstrong via cctech < cct...@classiccmp.org> wrote: > It appears that my RK8E has a problem - it fails the diskless control > test > with > > .R DHRKAE.DG > SR= > > COMMAND REGISTER ERROR > PC:1160 GD: CM:0001 > DHRKAE FAILED PC:6726 AC: MQ: FL: > WAITING > > Ok, maybe a bad bit in the command register so I'll check it out. But then > it dawns on me - how do you work on this thing? It's three boards > connected > with "over the top" connectors - you can't use a module extender on it. > Worse, the M7105 Major Registers board is the middle one of the stack! Is > there some secret to working on this thing? Has anybody fixed one? Any > suggestions? > I did some debugging on mine with two quad-height extenders and one half-height (used upside down). In such a way you can raise up two of the boards in back (on the quad extenders) with the one in front installed normally but with the half-height extender upside-down and plugged into the top connectors, so the edge fingers of the extender plug into the top blocks. Yes, it's ugly, and it only gains you access to half of the board you're trying to poke at. Building some sort of ribbon cables to substitute in for the top blocks/upside-down extender would be more, uh, flexible, but I was fortunate that what I needed to look at was on the unobscured side. - Josh > > I hadn't thought about it before, but the KK8E CPU would have the same > problem. Fingers crossed that one never dies... > > Bob > > >
Fixing an RK8E ....
It appears that my RK8E has a problem - it fails the diskless control test with .R DHRKAE.DG SR= COMMAND REGISTER ERROR PC:1160 GD: CM:0001 DHRKAE FAILED PC:6726 AC: MQ: FL: WAITING Ok, maybe a bad bit in the command register so I'll check it out. But then it dawns on me - how do you work on this thing? It's three boards connected with "over the top" connectors - you can't use a module extender on it. Worse, the M7105 Major Registers board is the middle one of the stack! Is there some secret to working on this thing? Has anybody fixed one? Any suggestions? I hadn't thought about it before, but the KK8E CPU would have the same problem. Fingers crossed that one never dies... Bob
Re: Future of cctalk/cctech
On Fri, 19 Jun 2020, Patrick Finnegan via cctalk wrote: > > Sure, there's always `uuencode' when you do need to post that non-text > > piece (which I guess will keep the eyes of Luddites away from it too). > > > > Or an http, https, ftp, or gopher url to somewhere else hosting the image. Well, not everyone can afford to host their own site, for various reasons, and if hosting externally you have to agree to T's you may not necessarily be happy about. Maciej
Re: Future of cctalk/cctech
On Fri, Jun 19, 2020 at 3:31 PM Maciej W. Rozycki via cctalk < cctalk@classiccmp.org> wrote: > Sure, there's always `uuencode' when you do need to post that non-text > piece (which I guess will keep the eyes of Luddites away from it too). > Or an http, https, ftp, or gopher url to somewhere else hosting the image. Pat
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
On Fri, 19 Jun 2020, Peter Corlett via cctalk 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. > > Any old mail client can read "modern mail": MIME is designed to be > backwards-compatible and the text parts readable on non-MIME clients. One > quickly learns the ASCII renderings of important non-ASCII characters after > using such a client for a while. (How do I know this? I still use trn, which > doesn't understand character sets at all. There are *no* "modern" newsreaders, > apart from the occasional kitchen-sink monstrosity which does nothing well.) I guess depending on how you define "modern". For instance (AL)PINE does handle UTF-8 (your UI might not however, if you run say on a VT220), which fulfils my definition of modernity, and it happens to have handled NNTP as well, since time immemorial. I have stopped participating with Usenet due to the lack of NNTP servers I could access, but I used to use PINE in this manner for years, and it did the right thing there. I continue using ALPINE for e-mail and I'm quite happy with the stuff it keeps away from me. An occasional PDF attachment I can deal with. And I can pipe a Git commit being read directly to `git am' with no fuss and no need to bother if it has been encoded in any way for transport. > The "no attachments" rule on many mailing lists is not a Luddite thing, but a > quality filter. There is a strong inverse correlation between those who feel > that they can't communicate without images and fancy text formatting, and > those > who have something useful or interesting to say. Less is more, and all that. Sure, there's always `uuencode' when you do need to post that non-text piece (which I guess will keep the eyes of Luddites away from it too). Maciej
Re: : Unknown Intel blinkenlight panel circa 1973
UNIBUS. Cable plugged into a UNIBUS slot connected to an external box with up to 128Kwords. > On Jun 19, 2020, at 4:07 PM, Noel Chiappa via cctalk > wrote: > >> From: Camiel Vanderhoeven > >> I know Intel made the in-4011 for the PDP-11, but I never saw a picture >> of it. > > Was it UNIBUS memory, or what? It doesn't seem to be in that table of early > Intel products. > > BTW, speaking of Intel PDP-11 memory, I have this: > >http://gunkies.org/wiki/File:IN-1611.jpg > > QBUS Intel memory board; hven't tried to get it running, though. > > Noel >
Re: PLATO V Terminal
> On Jun 19, 2020, at 2:32 PM, Lars Brinkhoff wrote: > > Paul Koning wrote: >>> I think Greg Thompson said he brought Maze to MIT in 1974. Wikipedia >>> says 1973. The game was first developed at NASA Ames in 1972. >> Ok, chances are that predates PLATO MUGs by 2-3 years. > > Spasim from 1974 is usually regarded as contemporary with Maze. > I'm not so sure about that 1973 dating; after all it's Wikipedia. Yes, I can confirm Jim Bowery's spasim was created in November 1974. And I'm fairly sure it wasn't the first MUG. It was actually rather ambitious for the time because it has a full 3d model, as opposed to some other games that were more like 2d (or stack of 2d, as in a number of the "dungeon and dragons" games). I just checked the history section of the "dnd" game on Cyber1; it makes it pretty clear that MU versions existed in 1974. "airfight" is dated 1976. paul
Re: PLATO V Terminal
Paul Koning wrote: >> I think Greg Thompson said he brought Maze to MIT in 1974. Wikipedia >> says 1973. The game was first developed at NASA Ames in 1972. > Ok, chances are that predates PLATO MUGs by 2-3 years. Spasim from 1974 is usually regarded as contemporary with Maze. I'm not so sure about that 1973 dating; after all it's Wikipedia.
RE: [EXTERNAL] Re: Farewell Etaoin Shrdlu
We have a working Linotype at the System Source Computer Museum in Hunt Valley Maryland. Open now only by appointment with a maximum of two masked visitors due to COVID https://museum.syssrc.com Bob Roswell -Original Message- From: cctalk On Behalf Of Alan Perry via cctalk Sent: Friday, June 19, 2020 1:41 PM To: cctalk@classiccmp.org Subject: [EXTERNAL] Re: Farewell Etaoin Shrdlu On 6/17/20 1:27 PM, Paul Koning via cctalk wrote: > > >> On Jun 17, 2020, at 3:25 PM, Liam Proven via cctalk >> wrote: >> >> https://archive.org/details/FarewellEtaoinShrdlu >> >> 28min documentary on the last ever edition of the NY Times to be >> printed using hot metal -- before they switched to what are now a >> quite choice assortment of late-'70s minicomputers. I think I spotted >> a PDP, a Data General and some IBM device, but I am no expert in this >> era. >> >> As a veteran reader of Fredric Brown, especially "the Enchanted >> Linotype", I have been using ETAOIN SHRDLU to win at Hangman for many >> years... but I'd never seen one working before. It all still seems >> like magic to me. > > They should be fairly easy to find in printing musea. > A friend of mine who was in Seattle collected this stuff. He had a couple Linotype/Intertype machines, a press, and lots and lots of magazines of type. It was set up in his garage and he would give demos of it in action. It was interesting how it worked. Unfortunately, he had to move out of the area for work and moving that stuff to another state was not feasible, so another local collector got it all. There was another documentary on them, Linotype: The Film (https://linotypefilm.com). alan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> On Jun 19, 2020, at 10:43 AM, Ethan Dicks via cctalk > wrote: > > On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk > wrote: >> Its been ages since I did this but looking here >> >> 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. I had the same reaction. The sync serial devices I know use modem-supplied clocks. That's why there is such a device as a "modem eliminator", which is different from the familiar asynchronous "null modem". A modem eliminator is essentially a null modem plus a clock source along the lines discussed a day or two ago. If you had a sync device that had the ability to send a local clock out, you could make a sync null modem that would just be wires, as an async null modem is. Perhaps this is something RS232 standardized but that wasn't adopted in the real world. paul
Re: Farewell Etaoin Shrdlu
On 6/17/20 1:27 PM, Paul Koning via cctalk wrote: On Jun 17, 2020, at 3:25 PM, Liam Proven via cctalk wrote: https://archive.org/details/FarewellEtaoinShrdlu 28min documentary on the last ever edition of the NY Times to be printed using hot metal -- before they switched to what are now a quite choice assortment of late-'70s minicomputers. I think I spotted a PDP, a Data General and some IBM device, but I am no expert in this era. As a veteran reader of Fredric Brown, especially "the Enchanted Linotype", I have been using ETAOIN SHRDLU to win at Hangman for many years... but I'd never seen one working before. It all still seems like magic to me. They should be fairly easy to find in printing musea. A friend of mine who was in Seattle collected this stuff. He had a couple Linotype/Intertype machines, a press, and lots and lots of magazines of type. It was set up in his garage and he would give demos of it in action. It was interesting how it worked. Unfortunately, he had to move out of the area for work and moving that stuff to another state was not feasible, so another local collector got it all. There was another documentary on them, Linotype: The Film (https://linotypefilm.com). alan
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On 19/06/2020 11:07, Peter Coghlan via cctalk wrote: 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 think messing with the kits isn't likely to produce a working system. You need more than the driver to make everything work. At the very least LES (Layered Environment Services) has to be available. 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 :-) I've found some notes that suggest that the DST32 and DSH32 both use the same driver (ZSDRIVER, as you've found). The other "busless" one was the DSW21/DSW41/DSW42. I can't find a WANDD SPD either locally nor online, but (iirc) V1.2 was Phase IV and certainly ran on V5.5-2. A bunch of stuff changed radically in V6.0 so if there was a Phase IV release for V6 then it would almost certainly have been post-V1.2. Antonio -- Antonio Carlini anto...@acarlini.com
Re: : Unknown Intel blinkenlight panel circa 1973
> On Jun 19, 2020, at 3:07 PM, Noel Chiappa via cctalk > wrote: > > BTW, speaking of Intel PDP-11 memory, I have this: > >http://gunkies.org/wiki/File:IN-1611.jpg > > QBUS Intel memory board; hven't tried to get it running, though. > > Noel > I have a similar M8044 DD PDP-11 QBUS board populated with Intel C2117 gold-ceramic chips. Much like you, i’ve not tried powering it up. Intel memory chips were used in quite a few QBUS RAM boards.
Re: PLATO V Terminal
> On Jun 19, 2020, at 11:34 AM, Lars Brinkhoff via cctalk > wrote: > > Noel Chiappa wrote: >>> Paul Koning wrote: >>> airfight and any number of other multi-user games -- a thing made >>> popular by PLATO and possibly originated there. >> >> What was the date on that? Multi-player MazeWar on the Imlacs/ITS at >> MIT was running before 1976 (I played it about then), but I don't >> recall exactly when it first ran (before my time). > > I think Greg Thompson said he brought Maze to MIT in 1974. Wikipedia > says 1973. The game was first developed at NASA Ames in 1972. Ok, chances are that predates PLATO MUGs by 2-3 years. paul
Re: Future of cctalk/cctech
On Fri, 19 Jun 2020 at 17:36, Peter Corlett via cctalk wrote: > There are *no* "modern" newsreaders, > apart from the occasional kitchen-sink monstrosity which does nothing well.) There was... https://panic.com/blog/the-future-of-unison/ -- 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 2020-06-19 11:43 a.m., Ethan Dicks via cctalk wrote: On Fri, Jun 19, 2020 at 4:26 AM Dave Wade via cctalk wrote: Its been ages since I did this but looking here 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 On the machines I worked on it was an option, but I never saw it used as the modem clocking was usually synchronized across the common carrier's network making it much more reliable. Most customers also used modems provided by the common carrier, which was a good thing as it was pretty easy to determine where the fault was. When one of our modems was used trouble shooting was more difficult, but I do recall discussing with the common carrier that receive level was too low, and having the deny that was possible only to have the level come up while still on the phone with them. Paul.
RE: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> -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. Dave > -ethan
Re: Future of cctalk/cctech
On Thu, Jun 18, 2020 at 10:28:05PM -0400, Tony Aiuto via cctalk wrote: [...] > And sometimes, a picture really is worth 1000 words. But pictures also consume magnitudes-of-order more resources than a thousand words, and should be used rather more judiciously than they are. > 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. My physics textbooks had editors who ensured that the text made sense and the images were useful to the reader. I'm sorry if you went to a bad school where your physics textbooks were similar to the vast majority of email. > 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. Any old mail client can read "modern mail": MIME is designed to be backwards-compatible and the text parts readable on non-MIME clients. One quickly learns the ASCII renderings of important non-ASCII characters after using such a client for a while. (How do I know this? I still use trn, which doesn't understand character sets at all. There are *no* "modern" newsreaders, apart from the occasional kitchen-sink monstrosity which does nothing well.) The "no attachments" rule on many mailing lists is not a Luddite thing, but a quality filter. There is a strong inverse correlation between those who feel that they can't communicate without images and fancy text formatting, and those who have something useful or interesting to say. Less is more, and all that. Images and HTML formatting also present an accessibility problem. At least one of the posters to this list gives a few "tells" in the way they write which suggest they are blind. Good luck doing text-to-speech on a JPEG.
Re: PLATO V Terminal
Noel Chiappa wrote: > > Paul Koning wrote: > > airfight and any number of other multi-user games -- a thing made > > popular by PLATO and possibly originated there. > > What was the date on that? Multi-player MazeWar on the Imlacs/ITS at > MIT was running before 1976 (I played it about then), but I don't > recall exactly when it first ran (before my time). I think Greg Thompson said he brought Maze to MIT in 1974. Wikipedia says 1973. The game was first developed at NASA Ames in 1972.
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 > > 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
Re: Future of classiccmp
You forgot to mention the freenode irc channel as well Sent from my iPad > On Jun 18, 2020, at 12:01 PM, jwest--- via cctech > wrote: > > 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. > > > > > > > > > >
Re: : Unknown Intel blinkenlight panel circa 1973
> From: Camiel Vanderhoeven > I know Intel made the in-4011 for the PDP-11, but I never saw a picture > of it. Was it UNIBUS memory, or what? It doesn't seem to be in that table of early Intel products. BTW, speaking of Intel PDP-11 memory, I have this: http://gunkies.org/wiki/File:IN-1611.jpg QBUS Intel memory board; hven't tried to get it running, though. Noel
Re: PLATO V Terminal
> From: Paul Koning > airfight and any number of other multi-user games -- a thing made > popular by PLATO and possibly originated there. What was the date on that? Multi-player MazeWar on the Imlacs/ITS at MIT was running before 1976 (I played it about then), but I don't recall exactly when it first ran (before my time). Noel
Re: Origin of 3-D printing (again)
On Fri, 19 Jun 2020 at 07:27, Stan Sieler via cctalk wrote: > > 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. That is really quite remarkable! Good find! -- 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 Jun 19, 2020, at 6:07 AM, Peter Coghlan via cctalk > wrote: > >> ... > > The specifications manual says that the maximum speed for the DST32 is > 19200 bps (for HDLC or SDLC) or 9600 bps (for DDCMP) but worryingly > doesn't list a speed for BISYNC which is what I want to do with it :-( > > It also says the supported line interfaces for the DST32 are: > RS-232-C/V.24/V.28, RS-423-A/V.10/RS-449 and RS-422-A/V.11/RS-449 but not > V.35 which seems strange because the only reaction I have got from it so > far is using the V.35 interface cable. At least it suggests it should work > with the V.24 cables when once I manage to come up with a suitable clock. The interfaces should all work about the same, for short cables. RS232 isn't rated as high as the others but if you're just running a 6 foot cable across the bench that isn't much of a problem. Interesting that DDCMP is rated lower. I wonder why that would be. If the device handles the data CRC, the software would do the header CRC but that is easy. I'd expect 9600 or so for BISYNC. I forgot how CRC works -- are the escape characters in BISYNC included in the CRC, or not? If not then you're probably looking at software CRC. Still, 9600 baud with software CRC is doable for a J-11, so it should be for a MicroVAX as well. paul
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 specifications manual says that the maximum speed for the DST32 is 19200 bps (for HDLC or SDLC) or 9600 bps (for DDCMP) but worryingly doesn't list a speed for BISYNC which is what I
Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
On Fri, Jun 19, 2020 at 12:21:14AM +0100, Pete Turnbull via cctalk wrote: > [...] 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. Hobbyists are still running Viewdata BBSes. Here's one connected to the Internet and provided with a JavaScript client so you can log in and have a poke around: http://fish.ccl4.org/java/. Offering access to one's BBS via TCP/IP isn't really optional any more now that many of us no longer have suitable analogue POTS lines to plug our old modems into, what with a mobile being a better choice for most purposes. I think (HS)CSD might have carried over from GSM into 3G, and it's even possible that my tinpot telco would connect such a call, but the odds that I could convince my mobile to make the call is pretty much zero. How do you enter AT commands on an iPhone anyway? Also, I resent paying per minute for low-bandwidth phone calls when I've got unmetered VDSL. I would write Viewdata clients in the nostalgia wave of the late 1990s and early 2000s, as it was also a nice easy introduction into a new platform's graphics and I/O subsystems. Maybe I'll do one in WebAssembly for old time's sake. > 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. That's 75WPM with the usual rule of thumb of six characters per word. I can copy-type at about 75-85WPM, which would interact badly with a small FIFO on a very basic terminal, what with that being an average and some words are typed at a faster rate. Fortunately, I've never suffered a Viewdata terminal that awful: the BBC Micro backed its 6850 UART and its 1-byte FIFO with a luxurious 192-byte software FIFO, for example. Having to stop for a sip of tea while the buffer drains isn't so terrible. Normally one would compose longer bits of text offline, of course, so that BT would get the smallest pound of flesh possible. Definitely a company with the "never mind the quality, feel the price" mentality, but that's all telcos for you.
Re: Ancient transistor ?computer board (Peter Van Peborgh)
Core memory driver board? On 19/06/2020 02:22, Boris Gimbarzevsky via cctalk wrote: 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: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech
> -Original Message- > From: cctalk On Behalf Of Peter Coghlan > via cctalk > Sent: 18 June 2020 23:11 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: 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 trimmed this because we seem to be missing the crux of clocks and why we need them! In async data we take our clock from the edge of the start bit, and we have a stop bit which is really there to stop characters running together. With sync we just have a stream of digital data and we use the clock to know when to sample it. There are no stop bits or start bits, and we use a synchronisation character at the start of each block to work out how the characters are positioned in the data stream. So we need clocks... Its been ages since I did this but looking here 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 as suggested here:- https://www.synclink.com/nullmodem.html This assumes you have RS232 interfaces. If its X21 then eliminators are available on e-bay for a few pounds. Dave
