Re: Malfunctioning VT240 - help please

2020-06-20 Thread Jon Elson via cctalk



I confirmed the bad one by removing the piggyback and the 
failure returned. Now I need to desolder the bad one 
without ruining the board. I may just cut the leads off 
close to the bad chip, and solder the replacement to the 
stumps. (Normally I remove the legs and install a 
machine-pin DIP socket). Or just solder the piggyback and 
leave it there... thoughts?


Cut the leads close to the body.  Apply a soldering iron to 
each lead, and pull the lead out with tweezers,
simultaneously heating and pulling.  This is very gentle to 
the board, just doing one at a time.  Then, you can vacuum 
out the holes and install a new chip or socket.


I've done this many times, and never wrecked a board.

Jon



Re: Malfunctioning VT240 - help please

2020-06-20 Thread Charles via cctalk

On 06/11/2020 02:29 AM, Mattis Lind via cctalk wrote:
>/If that would be the case I think the system would fail />/quite soon rather 
than on test 5. A guess is that this is />/a memory problem. /
That was a good guess, everyone ;) I got some new 4116's and piggybacked 
(dry, no solder) two of them atop my suspects at E3 & E4.


Didn't fix it. Of course :/

In the meantime I've acquired a nice HP 1630G logic analyzer complete 
with pods and cables. Setting it up was going to take quite a while 
since I'm not familiar with this model. So I decided to try a simple 
brute-force approach before the analyzer. I piggybacked another 4116 
onto each soldered-in 4116, one at a time. Actually easy to do since 
with the leads properly formed, I didn't even have to solder it in 
place, just turn off the power and move it to the next chip.


On the 16th, the last one of course, the terminal booted normally and 
works again. :)


I confirmed the bad one by removing the piggyback and the failure 
returned. Now I need to desolder the bad one without ruining the board. 
I may just cut the leads off close to the bad chip, and solder the 
replacement to the stumps. (Normally I remove the legs and install a 
machine-pin DIP socket). Or just solder the piggyback and leave it 
there... thoughts?




Re: Ancient transistor ?computer board (Peter Van Peborgh)

2020-06-20 Thread Jon Elson via cctalk

On 06/20/2020 04:20 AM, Peter Van Peborgh via cctech wrote:

Guys,

I now know it is an early CDC board. IT had C*NT*OLDATA on the reverse - how
I missed that must be attributed to old age. (Thanks Doug)

Here are shots of the back: https://photos.app.goo.gl/UPozyBB3zp7XYcP79



Ah, the missing letters are covered by solder!


Any idea what the row of hole opposite the contacts were? Testing points?


Yes, for sure.  The way they are made so close to the edge, you can just clip a 
scope probe to them for testing.

Jon



Re: Future of cctalk/cctech

2020-06-20 Thread Grant Taylor via cctalk

On 6/19/20 9:42 PM, Fred Cisin via cctalk wrote:

We need, or at least want, to handle BOTH.


Agreed.

Long-term, "permanent" content, as well as the casual "What is 
this? here's what it looks like"


I think that short term can sort of ride the coat tales of the long term 
solution.


I have no idea whether it is practical to handle those the same, or 
differently.


What if the "short term" is the current URL to files that have been 
removed from emails (or uploaded directly).  Admittedly this would be 
somewhat subject to the current location of the archive.


Conversely the "long term" solution could simply be URL agnostic in that 
you go to the at the time current URL and navigate to the message you 
are looking for attachments to.  I'd like to see the ability to search 
by subject / date / sender / message ID / etc.


I think this method of long term solution makes the actual archive 
somewhat URL agnostic.  As in you get there, wherever there is, and then 
pick the file(s) you want.


With this type of long term solution, it doesn't really matter if the 
URL in the email breaks in the future.




--
Grant. . . .
unix || die


Re: Future of cctalk/cctech - text encoding

2020-06-20 Thread Grant Taylor via cctalk

On 6/18/20 7:34 AM, Daniel Seagraves via cctalk wrote:
I vote we move the list to an Exchange server behind a SSL VPN 
and mandate the use of Outlook, then force all messages to be in 
quoted-printable encoding.


I see your quoted-printable and raise you TNEF.

This way nobody “wins” and everyone is equally miserable. It’s 
only fair.


Are you listening to "The Trees" from Rush?



--
Grant. . . .
unix || die


Re: Future of cctalk/cctech

2020-06-20 Thread emanuel stiebler via cctalk
On 2020-06-19 23:42, Fred Cisin via cctalk wrote:
>>> 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.

Some mailing lists accept only attachments, if those are links into the
permanent storage at the mail server ...



Re: Someone's confused

2020-06-20 Thread emanuel stiebler via cctalk
On 2020-06-19 20:37, Chris Zach wrote:
> Yes, there was D and F, and F and G versions. Everything else was
> emulated slowly. Putt putt it was

Right! I have at least one of them. You know how one would see, which
one it is? Different board numbers?

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



Ancient transistor ?computer board (Peter Van Peborgh)

2020-06-20 Thread Peter Van Peborgh via cctalk
Guys,

I now know it is an early CDC board. IT had C*NT*OLDATA on the reverse - how
I missed that must be attributed to old age. (Thanks Doug)

Here are shots of the back: https://photos.app.goo.gl/UPozyBB3zp7XYcP79

Any idea what the row of hole opposite the contacts were? Testing points?
But then why holes and not short pillars? Some are labelled on both sides.

Continuing in hope,

peter




Re: Fixing an RK8E ....

2020-06-20 Thread Todd Goodman via cctalk

I have some of these connectors (from ECS) for $10 each

Shipping in the US is a flat rate $8.30

(Poor) pictures at 
http://bonedaddy.net/tgoodman/photos/tgoodman/ECS-Connector/


Todd

On 6/19/2020 5:19 PM, Vincent Slyngstad via cctalk wrote:

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: Hercules SDLC/BSC interfacing project - want 3174-x1R

2020-06-20 Thread Mattis Lind via cctalk
lördag 20 juni 2020 skrev Al Kossow via cctalk :

> On 6/20/20 2:36 AM, Mattis Lind via cctalk wrote:
>
> If anyone has a type 1 3174 that does BSC and SDLC so I could test my stuff
>> I would be very interested.
>>
>
> Dave Wade just posted that he had some in the UK he was interested in
> getting rid of.


Talked to Dave already. Appears that they all were type 2, at least the
tabletop ones, except for one that Dave would prefer to keep.

/Mattis


Re: Hercules SDLC/BSC interfacing project - want 3174-x1R

2020-06-20 Thread Al Kossow via cctalk

On 6/20/20 2:36 AM, Mattis Lind via cctalk wrote:


If anyone has a type 1 3174 that does BSC and SDLC so I could test my stuff
I would be very interested.


Dave Wade just posted that he had some in the UK he was interested in getting 
rid of.




Hercules SDLC/BSC interfacing project - want 3174-x1R

2020-06-20 Thread Mattis Lind via cctalk
Hello!

I have been working on interfacing the Hercules emulator with various real
terminals for some time. First project was an Alfaskop terminal cluster
which I connected using a small STM32 controller handling BSC.

Next is an Informer 213, portable 3178/3174 compatible terminal. It it
using SDLC.

A friend has a 3178 and 3279 which would interesting to work with. A
3174-51R/-61R/-81R/-91R would be very suitable for this.

It would be very nice to test my BSC and SDLC code with the real IBM stuff.

I have put my project here:
 https://github.com/MattisLind/alfaskop_emu/tree/master/Utils


Still very much Work In Progress.

If anyone has a type 1 3174 that does BSC and SDLC so I could test my stuff
I would be very interested. No need for fancy features like TCP/IP and/or
token ring.

I of course pay shipping. But can throw in various DEC QBUS stuff as a
trade.

/Mattis


RE: Fixing an RK8E ....

2020-06-20 Thread Robert Armstrong via cctalk
>Josh Dersch 
>   one half-height (used upside down).

  Thanks, Josh - I hadn’t thought about using an extender card "backwards".  
That's a good idea.  Next question is "how many extender cards do I have?"...  
Better go start digging.

  In the meantime I did some more fooling around with the diagnostic and 
discovered that it's apparently not really a stuck command bit after all.  The 
tests are failing are #30 and #31, "VERIFY THAT RECALIBRATE INHIBITS LOAD 
COMMAND" and "VERIFY THAT RECALIBRATE INHIBITS LOAD DISK ADDRESS".  Sounds like 
a problem with the recalibrate function instead.

Bob