Re: Future of cctalk/cctech

2020-06-19 Thread Toby Thain via cctalk
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

2020-06-19 Thread Fred Cisin via cctalk

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

2020-06-19 Thread Al Kossow via cctalk



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?

2020-06-19 Thread Chris Hanson via cctalk
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

2020-06-19 Thread Boris Gimbarzevsky via cctalk
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

2020-06-19 Thread Chris Zach via cctalk
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....

2020-06-19 Thread Chris Zach via cctalk
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 ....

2020-06-19 Thread Vincent Slyngstad via cctalk

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

2020-06-19 Thread Fred Cisin via cctalk

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&C'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 ....

2020-06-19 Thread Guy Sotomayor via cctalk
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 ....

2020-06-19 Thread Josh Dersch via cctalk
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 ....

2020-06-19 Thread Robert Armstrong via cctalk
  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

2020-06-19 Thread Maciej W. Rozycki via cctalk
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&C's you may not 
necessarily be happy about.

  Maciej


Re: Future of cctalk/cctech

2020-06-19 Thread Patrick Finnegan via cctalk
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

2020-06-19 Thread Peter Coghlan via cctalk
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

2020-06-19 Thread Maciej W. Rozycki via cctalk
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

2020-06-19 Thread Camiel Vanderhoeven via cctalk
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

2020-06-19 Thread Paul Koning via cctalk



> 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

2020-06-19 Thread Lars Brinkhoff via cctalk
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

2020-06-19 Thread rar via cctalk
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

2020-06-19 Thread Paul Koning via cctalk



> 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

2020-06-19 Thread Alan Perry via cctalk




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

2020-06-19 Thread Antonio Carlini via cctalk

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

2020-06-19 Thread Joshua Rice via cctalk



> 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

2020-06-19 Thread Paul Koning via cctalk



> 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

2020-06-19 Thread Liam Proven via cctalk
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

2020-06-19 Thread Paul Berger via cctalk



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

2020-06-19 Thread Dave Wade via cctalk


> -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

2020-06-19 Thread Peter Corlett via cctalk
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

2020-06-19 Thread Lars Brinkhoff via cctalk
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

2020-06-19 Thread Ethan Dicks via cctalk
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

2020-06-19 Thread Adrian Stoness via cctalk
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

2020-06-19 Thread Noel Chiappa via cctalk
> 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

2020-06-19 Thread Noel Chiappa via cctalk
> 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)

2020-06-19 Thread Liam Proven via cctalk
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

2020-06-19 Thread Paul Koning via cctalk



> 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

2020-06-19 Thread Peter Coghlan via cctalk

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 wa

Re: Synchronous serial Re: E-Mail Formats RE: Future of cctalk/cctech

2020-06-19 Thread Peter Corlett via cctalk
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)

2020-06-19 Thread Rod Smallwood via cctalk

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

2020-06-19 Thread Dave Wade via cctalk


> -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