Re: Anyone familiar with these vintage touchscreens?

2019-10-20 Thread Brent Hilpert via cctalk
On 2019-Oct-20, at 9:14 AM, Nigel Johnson via cctalk wrote:
> On 20/10/2019 06:43, Peter Corlett via cctalk wrote:
>> On Sat, Oct 19, 2019 at 02:23:46PM -0400, Nigel Johnson via cctalk wrote:
>>> Judging by the year, it was probably a teletext terminal. [...]
>> It's not Teletext, unless that word means something different on the other 
>> side
>> of the Pond. Teletext was basically a text system (the hint's in the name) 
>> with
>> graphics (and indeed colour) being a weird hack that gave it a particular
>> appearance, especially in typical implementations which used the SAA5050
>> character generator chip.
>> 
>> The palette and colour fringing suggest Apple II to me.

> It was called teletext despite the implications, at least here in Canada.  
> People just couldn't get their tongue around NAPLPS!
> 
> It looks just like the teletext systems I worked on, maybe ours was better 
> than yours?


For elucidation, here's an example of a Canadian Telidon terminal with display 
examples:
http://madrona.ca/e/telidon/index.html

(The processor is indeed a 6809, as Diane was mentioning.)

Graphics was very much a part of the Telidon/NAPLPS protocol.
(Note: Colour capabilities may differ between terminals, the protocol was such 
as to permit a range of compatible implementations.)

While the store directory terminal of the OP 'could' have been a Telidon/NAPLPS 
terminal, I'd be placing my bets more on the Apple-II (or similar) as others 
mentioned. Strikes me more as a standalone unit. I think using a 
videotex/teletext/Telidon/NAPLPS terminal would have been awkward and the 
economics poor, there'd either have to be a rented comm line to a remote 
server, an additional local server, or storage hacked onto the terminal.

The touch-screen is another issue, while it could have been supported in a 
proprietary manner I'm not aware of explicit support for touch-screens in the 
protocol.

I believe the NAPLPS designation (designation as an industry standard) came 
rather late in the game, an attempt to gain some recognition for a dying 
project. As "Telidon", it had begun years earlier.



Re: Restoring dull BOT markers?

2019-10-14 Thread Brent Hilpert via cctalk
On 2019-Oct-14, at 12:46 PM, Chuck Guzis via cctalk wrote:
> On 10/14/19 12:26 PM, Al Kossow via cctalk wrote:
>> 
>> On 10/14/19 9:32 AM, Daniel Seagraves via cctalk wrote:
>>> What’s the best way to restore a dull BOT marker
>> 
>> replace it
>> 
>> there were rolls of brady BOT tape on ebay but I don't see them now
> 
> There are still people selling sensing foil tape for audio applications.
> That might work well.  Search for "sensing foil tape" on eBay.


For the sake of a couple of passes through the transport how, about some really 
thin Al foil - like that which some chocolate, or cigarettes, are wrapped in - 
stuck on with common transparent office tape. The tape would cover the Al edges 
so those edges wouldn't directly transit across anything in the transport path, 
but it's on the opposite side from heads anyways.



Re: Mystery chip SCM44506L

2019-10-10 Thread Brent Hilpert via cctalk
On 2019-Oct-10, at 5:33 AM, Wouter de Waal via cctech wrote:
>> Very likely a semi custom or custom memory device, due to the prefix.
> 
> Armed with that and the fact that pin 1 connects to the leadframe I figured 
> maybe it's something like the 6830 Mikbug prom -- 0V on 1, 5V on 12, data on 
> the left, address on the right. Tried reading it like that (for all 16 
> combinations of chip selects) but 0xFF throughout.
> 
> So I popped the lid, stuck it under a microscope. The chip says "MCM6816" 
> which is in fact a 1k ROM.
> 
> Anyone have more information on the 6816 ROM?


Funny, the usual goto reference for early 6800-series chips is the 6800 Micro 
System Design manual:

http://bitsavers.org/components/motorola/6800/MC6800_Microcomputer_System_Design_Data_1976.pdf
but it's not in there.

There are a couple of other 1K ROMs however (6830,68308).
Might compare pinout with those.



Re: fix? Repair? or leave alone? http://rcade.camden.rutgers.edu/2020symposium.html

2019-09-27 Thread Brent Hilpert via cctalk
On 2019-Sep-27, at 6:47 AM, Paul Koning via cctalk wrote:
> I make it a habit to assume that every email which contains just a link but 
> no explanation is a scam with a forged sender address.
> 
> Ed, if this is actually from you and actually real, and you want people to 
> look at it, you need to say what the link is.
> 
>> On Sep 27, 2019, at 3:10 AM, ED SHARPE via cctalk  
>> wrote:
>> 
>> http://rcade.camden.rutgers.edu/2020symposium.html 


"... explored these processes of repair and has focused on their non-linear 
temporalities."

"Repair does not necessarily focus solely on “the reproduction of social and 
material order,” but also opens up space for the “creative, inventive and 
innovative work that happens in the process of fixing, across human and 
non-human bodies."

"... offering us a way to historicize and contextualize the work of repair and 
maintenance. That means avoiding the romanticization of repair while also 
recognizing “traditions of women's work, domestic and reproductive labor, and 
all acts of preservation, formal and informal.”"


Don't waste your time, unless you're going for some entertainment in watching 
ridiculous people.



Re: HP vintage boards being sold as scrap

2019-09-25 Thread Brent Hilpert via cctalk
On 2019-Sep-25, at 3:07 AM, Guy Dunphy via cctalk wrote:

> Does anyone else recognise some of the other boards?


There is a stack of IO interface boards, including HSTs, for the HP 2100/1000 
series there.

Lower-right stack in this pic, 7 boards, boards have one red and one grey 
handle:
https://i.ebayimg.com/images/g/n08AAOSwjY5dg5Kd/s-l1600.jpg

"HS Terminal" is discernible on one of them, and the one on top looks to be an 
HS Terminal as well.
Can't be certain about the others but they have the same size IO connector, 
they may all be HSTs.

HSTs are the basic RS232 & current loop, async serial-line interface boards, 
12531D, used for the console and such in the 2100/1000 series,
going back to the early machines of the series.

(HS is 'High-Speed', but that's relative to the late-60s, billed for up to 
2400bps, but it is possible to operate them at higher speeds).

I'd buy one for, say 60$, if someone picks up the bunch and wants to flog one.
 

Re: Cleaning an old keyboard

2019-09-23 Thread Brent Hilpert via cctalk
On 2019-Sep-23, at 4:24 PM, Kevin Parker via cctalk wrote:
> I resurrected an old keyboard and mouse I like. Not wishing to gross anyone
> out but it looks like over time there was a build-up of oil etc from my
> hands etc and over time being stored away its turned to a really almost hard
> paste like stuff on both the mouse and keyboard.
> 
> I've tried number of agents to clean it off but limited success.
> 
> Any tips please.

Isoprop as a preferable first resort, as others have suggested.

If that doesn't do it, common TSP (Tri-Sodium Phosphate) is good at cleaning 
off grimy organics.
However, best to be taking things apart so keycaps and housings (not the 
electronics or keyswitches) can be immersed in solution and then thoroughly 
rinsed.
I wouldn't want to let TSP soak into parts from a wipe-down where it couldn't 
be well-cleaned-out.

Re: Info on testing vintage power supplies

2019-09-02 Thread Brent Hilpert via cctalk
On 2019-Sep-02, at 9:35 AM, Alan Perry via cctech wrote:
> Can anyone here provide a pointer to info on testing vintage power supplies? 
> Search results on the web may eventually lead to the kind of info that I am 
> looking for, but I have to get through too many pages of modern PC power 
> supplies first.
> 
> Specifically, I will be testing the power supplies in my Sun 3/260, which has 
> 24V, 12V and 5V. I am wondering things like what is suitable loads and do I 
> need to put a load on all three or can I test them one at a time and what I 
> haven't thought of with regards to testing them.

Regarding incandescent bulbs, 12V bulbs can be used on the +5.
They tend to be cheaper and more readily available than 6V bulbs.

Dual-filament tail-light-with-brake-light bulbs such as the 1034 and 1157 are 
common and inexpensive.
The dual filaments allow for some load variation, the tail-light filament is 
lower current, the brake filament higher.
Parallel a couple such bulbs (and the filaments) for more current.
You don't have to buy sockets for them, you can solder wires to the base and 
contacts.

Note the current draw is not a straight linear relationship with reduced 
voltage.
At lower voltage they'll draw something more than the linearly-reduced current 
level.
E.g. for the 1034:

@ 5V@ 12V
-   -
tail0.35A   0.6A
brake   1.2A2.4A


I don't know that you'll find any sort of generalised reference for your 
request.
While some general rules may cover many models, the only way to be comprehensive
over such a topic is to understand the principles and then look at the specific
design of the supply one is dealing with.

For switching supplies, usually only one of the outputs is actually regulated 
and the others
will 'follow' in regulation (designed for a low enough 
source-impedance-to-load-impedance ratio that
they'll be in range if the controlled output is in range).

Sometimes lesser-current outputs actually have a linear regulator between the 
switching transformer and the output. 



Re: So what the heck did I just pick up?

2019-08-31 Thread Brent Hilpert via cctalk
On 2019-Aug-30, at 7:24 PM, John Ames via cctalk wrote:
> Ran into this at the electronics-surplus store just down the way from
> my workplace and grabbed it on the cheap. I don't actually know what
> it *is,* but the labels on the switches make it look a *hell* of a lot
> like a 16-bit general-purpose computer of some kind. Despite the
> claims of being "microprocessor-controlled," I looked at every board
> inside the thing and couldn't spot anything that looked like a 16-bit
> or even 8-bit CPU. Genuinely curious what this is, but I can't find
> much on it online - the name pops up in a few archived documents, but
> Bitsavers doesn't have anything for the company. Though the design is
> attributed to Stanley Kubota and Edward Corby - looks like Mr. Kubota
> still has an online presence at https://www.exsellsales.com/about-us/
> so I'll have to drop them a line...
> 
> Anybody heard of or encountered one of these before?
> 
> http://www.commodorejohn.com/whatsit-front.jpg
> http://www.commodorejohn.com/whatsit-back.jpg


"couldn't spot anything that ... looked like a CPU"

By what criteria? Were you just looking for 'large' chips?
Might you have overlooked an 8008 or 4004? - they were in 'small' 18 & 16 pin 
DIPs.
Given the mid-70's appearance (confirmed by Chuck's 1976 ref) those would have 
been possibilities for the task.

If there's no single-chip microproc in there, there might be a minimal CPU 
built out of multiple chips.
"Microprocessor" in that era was sometimes used in a wider sense than just 
single-chip-processor.
ROMs or EPROMs for firmware could be another hint as to architecture.




Re: GW-DEC-1: A New DEC Prototyping Board

2019-08-16 Thread Brent Hilpert via cctalk
On 2019-Aug-16, at 11:56 AM, systems_glitch via cctalk wrote:
> On Fri, Aug 16, 2019 at 2:53 PM Paul Koning  wrote:
>> 
>>> On Aug 16, 2019, at 2:43 PM, systems_glitch via cctalk <
>>> 
>>> I'm sure DEC wouldn't have bothered with hard gold plating if their
>>> connectors were metallurgically incompatible :P The few busted DEC
>>> connectors I've replaced did indeed have selective gold plating on the
>>> contact surfaces. Most quality edge connector slots are similarly
>>> constructed.
>> 
>> It's been a while and I never looked in depth, but it most definitely is
>> not true that gold is only compatible with gold.
>> 
>> From what I remember, the detailed analysis involves an "electrochemical
>> series", which has metals like sodium at one end, copper closer to the
>> middle, and gold at or near the other end.  Metals are compatible if their
>> potential value differs by less than a limit.  The limit depends on the
>> environment; in an office you can have a larger limit than on a ship where
>> you have salt spray, or a tire factory with lots of SO2 in the air.
>> 
>> There are also some twists; I think stainless steel is compatible with
>> many things thanks to the alloy ("stainless") properties.  In fact, I think
>> the subject came up in connection with failure analysis of coin cell
>> battery holders.  The battery cases are stainless steel; the question is
>> what contacts are acceptable.  Gold is; there may be others but some things
>> that are used in the market are not good choices.

> You can look it up in an electronegativity chart for a quick "will these
> ruin each other" check.
> 
> I think a lot of this comes from the SIMM era in PCs, where folks were told
> to only use gold-flash SIMMs in gold sockets, and only tin plated SIMMs in
> tin plated sockets.


I've seen pieces of HP high-end lab equipment from thru the 60s that used tin 
plating on the PCB edge fingers, mating into gold-plated edge connectors on the 
backplane.
Never quiet understood it, they (HP) were doing gold-plated edge fingers on 
other equipment at the same time.




Re: XXDP on PDP-11/03

2019-08-14 Thread Brent Hilpert via cctalk
On 2019-Aug-14, at 1:26 PM, Allison Parent via cctalk wrote:
> IPhoned it in!
> 
>> On Aug 14, 2019, at 2:19 PM, Noel Chiappa via cctalk  
>> wrote:
>> 
>> From: Jonathan (systems_glitch)
> 
>> Yep, fun times on LSI-11/2!
> 
> Heh, this one was _utterly trivial_ compared to the 'must have working memory
> at 0 or ODT won't start'! (I don't think I've ever seen that one in DEC
> documentation anywhere...)
> 
>   Noel
> 
> ! Seriously?  
> The architecture of pdp-11 has
> the first 256 words as interrupt
> vectors and software locations.
> Memory of some form there is
> a must. How else would the console vectors at 60 work.



Well, the J11 ODT works fine with no memory.

I wouldn't have thought any of the (various 11 CPU) ODTs used interrupts for 
the console, and so wouldn't rely on the presence of vector memory.

Don't know which CPU Noel was referring to.



Re: Ill NLS MS-230

2019-07-30 Thread Brent Hilpert via cctalk
On 2019-Jul-29, at 6:34 PM, Jim Brain via cctalk wrote:
> I have an ill NLS MS-230 Miniscope.  Is there anyone on list that might be 
> interested in getting it running for me?  I'm willing pay for the privilege.  
> I'd like to see the unit working, but I have no experience with analog 
> scopes, and I'd rather just entrust it to someone who can see it to success.  
> I did replace the batteries and let it charge for quite a while.  The red LED 
> lights up on the front when on, but no sign of a trace, even when fed a known 
> good 1kHz wave.  The CRT does not appear to be on.
> 
> Anyone a fan of these units and might be interested in taking a look?


It's tempting but I'm across the border and some shipping distance away.

Looking at the schematic (readily available online), it's fairly 
straightforward.
If you're willing to spend a little time on it, you could do the basics and 
check
for the power supply voltages as listed on the schematic.

The power supply is essentially 3 stages:
1) line -> charging circuit for the batteries,
2) batt -> +5 regulator,
3) +5 -> simple switching supply for +/-7V, +80V, +100V, -720V, 0.5V 
heater, 12V for U11.

With nothing on the CRT (esp with the intensity turned full up), suspicion may 
fall around the little switching supply.

A key point to note with 'scopes like this is the cathode/heater runs at high 
negative voltage relative to GND, rather than the TV/monitor convention of the 
anode running at high positive voltage. This is done so the amplifiers to drive 
the electrostatic deflection plates can be be operated near GND level rather 
than having to raise them way above GND.

So according to the schematic the heater (acting as cathode; either pin) should 
measure -720V relative to GND and there should be 0.6V across the two heater 
pins.
U11 should have 12V across pins 14 & 7, but like the heater, it to is floating 
at -720V below GND.

Re: Resurrecting integrated circuits by cooking them.

2019-07-24 Thread Brent Hilpert via cctalk
On 2019-Jul-24, at 10:31 AM, Jeffrey S. Worley via cctalk wrote:

> Yesterday evening, in the process of refurbishing five very badly
> treated Atari 800 computers I had a hunch and subjected a failed Pokey
> chip (Atari Part CO12294 Wikki link https://en.wikipedia.org/wiki/POKEY
>) to high heat by way of the barrel of my soldering iron until
> saliva evaporated from it in about 1 second.
> 
> The chip, which did not work before in any of the machines now works
> perfectly.

> ...

> I stumbled upon a fix for this one and wonder if I reinvented the wheel
> or if this information may be of use to the group in treating other
> sorts of chips.
> 
> Reflowing is a treatment for a lot of hardware these days and generally
> regarded as a hack which won't last.  As modern hardware, CPU's and
> video chips in particular run very hot, I can see how this might be,
> but Pokey and most of the stuff we work with don't have this
> environmental restriction.  Most of our gear runs at 40 degrees
> centigrade or lower.  So I'm guessing the problem with my disused chip
> was oxidation within the package and that cooking the chip a bit
> cleaned things up?  Any advise or observations would be appreciated.
> 
> I tried this on another chip the same evening, an Antic.  The Antic DID
> work for a second or two, whereas it had before given no signs of life,
> but then returned to its failed state.



.. cross your fingers that it stays working. I performed a fix like this some 
years ago with a ca.1970 chip from an SSI logic family from Sony. However, it 
reverted to its failed state some weeks or months after the heat application, 
long after (obviously) the chip had returned to ambient temperature. So it 
wasn't merely that the chip was temperature sensitive, the heat application 
indeed must have had made some internal alteration, but it wasn't permanent.



Re: Margaret Hamilton Guardian interview.

2019-07-13 Thread Brent Hilpert via cctalk
On 2019-Jul-13, at 1:48 PM, Lyndon Nerenberg via cctalk wrote:
> Another of the un-acknowledged people in the upcoming July 29
> 'celebrations'.
> 
> https://www.theguardian.com/technology/2019/jul/13/margaret-hamilton-computer-scientist-interview-software-apollo-missions-1969-moon-landing-nasa-women


On 2019-Jul-13, at 8:55 PM, Richard Loken via cctalk wrote:
> Lyndon, I have never heard of her before and had no idea.  I am frequently
> amazed when I discover just how much you know...  Or how much spare time
> to surf the web for obsure stuff...  Either way you earn my respect.


Margaret Hamilton is well known in regards to the AGC, and as the article 
mentions she received a Presidential Medal of Freedom, amongst other awards 
including from NASA.
She is not unknown, nor unacknowledged.



Re: Kids these days...

2019-06-10 Thread Brent Hilpert via cctalk
On 2019-Jun-10, at 11:11 AM, Mark J. Blair via cctalk wrote:
> I wouldn’t invest in an IoT buzzword company whose web page admits that the 
> products they are talking about don’t exist yet, headed by a non-engineer, 
> even without the fishy international money laundering smell. It’s interesting 
> how quickly you ferreted that out, William. I don’t have a clue about 
> business stuff like that. 
> 
> Yesterday I saw a company car for a presumed IT service company called Telnet 
> something or other. I don’t think I would rely on Telnet for my information 
> security needs. 


The disclaimer at the bottom of the page is good for a laugh, and could be a 
hint.  
>   http://www.gopherprotocol.com

Summary:
What we say here isn't what we are doing, it's what we might do in the future.
And if we change our minds or can't do it, don't expect us to tell you.

Summary of summary:
Don't trust anything we say.



Re: Abandoned FACOM system in Italy?

2019-05-28 Thread Brent Hilpert via cctalk
On 2019-May-27, at 5:53 PM, Glen Slick via cctalk wrote:
> On Mon, May 27, 2019 at 4:14 PM shad via cctech
>  wrote:
>> 
>> Hello,
>> do you know the people who made the video?
>> I think the factory is the Satilai in Saronno.
>> 
>> Andrea
> 
> I believe those guys are based somewhere in the US. Sometime in the
> last few months they made a trip exploring several places in Europe.
> They usually do not provide in their videos the exact identity or
> location of the places they visit, although a lot of their viewers can
> figure it out with a bit of research.
> 
> http://theproperpeople.com/about/
> https://www.youtube.com/user/TheProperPeople/videos
> 
> I have seen some interesting old computer gear briefly appear in a few
> of their other videos. Not something they stop to focus on, as most of
> the people on this list would.

With shad's hint of Saronno, it's not difficult to spot:

https://www.google.com/maps/place/21047+Saronno,+VA,+Italy/@45.6308352,9.0453149,399m/data=!3m1!1e3!4m5!3m4!1s0x47869159b2e042bd:0xb507c6b15c96294f!8m2!3d45.6242491!4d9.0359607




Re: M7264 Troubleshooting

2019-05-26 Thread Brent Hilpert via cctalk
Didn't this start out with the RUN LED not lighting up?
I don't recall it being mentioned that that was repaired.
Perhaps pursue fixing that - while it may be a secondary problem that
doesn't resolve a 'bigger' problem, it could be that it uncovers a common 
problem.



Re: M7264 Troubleshooting

2019-05-20 Thread Brent Hilpert via cctalk
On 2019-May-20, at 12:11 AM, Glen Slick via cctalk wrote:
> On Sun, May 19, 2019 at 11:48 PM Brent Hilpert via cctalk
>  wrote:
>> 
>> Except the SRUN (K8 SRUN L) action is not latched, so it probably appears as 
>> an
>> active-low heartbeat pulse with some periodicity when the processor is in 
>> run mode.
>> A low-going pulse during PH 3 every instruction cycle perhaps.
> 
> http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf
> 
> Page 171 of the PDF, Lights & Switches Board schematic
> 
> The SRUN L signal (routed from the backplane through the power supply)
> is fed through a 74123  retriggerable monostable multivibrator
> one-shot before driving the RUN LED. If the SRUN signal is a pulsing,
> the LED might effectively be driven constantly on.
> 
> I don't have the H11 schematic. It's front panel might have similar
> logic driving the RUN LED.


Good, that makes sense together, as the duty cycle could be expected to be too 
low to light the LED driven directly.

TTL monostables weren't the most reliable components.



Re: M7264 Troubleshooting

2019-05-20 Thread Brent Hilpert via cctalk
On 2019-May-19, at 9:09 PM, Glen Slick via cctalk wrote:
> On Sun, May 19, 2019 at 8:05 PM Mister PDP via cctalk
>  wrote:
>> 
>> After that, I decided to try and find out why the
>> Run/Halt light was not coming on when I hit the switch. Looking at the H11
>> schematics, the light relies on the SRUN signal coming off of the
>> backplane. The problem I am currently facing is I cannot find where the CPU
>> board generates the SRUN signal. If anyone who is more experienced that me
>> knows how the M7264 generates the SRUN signal, that would be wonderful.
> 
> http://www.bitsavers.org/pdf/dec/pdp11/1103/1103_Schematics.pdf
> 
> Page 27 of the PDF, LSI-11 CPU MODULE (K8) schematic
> Grid position B1, the SRUN L signal is driven on to the backplane bus line 
> AF1.
> 
> I have no idea how the logic works on the M7264 module that drives that 
> signal.



It looks like the CPU chipset is putting a binary 'state action code' onto the
WMIB 18-21 lines (sources on page K2) during clock phase 3 (PH 3 H at gate 
E45.10).

The action code is decoded to 1 of 8 actions by E68.

Most of the states are latched by the subsequent flip-flops,
and those states are cleared or set by the action codes.

Except the SRUN (K8 SRUN L) action is not latched, so it probably appears as an
active-low heartbeat pulse with some periodicity when the processor is in run 
mode.
A low-going pulse during PH 3 every instruction cycle perhaps.



that AGC DSKY auction

2019-04-18 Thread Brent Hilpert via cctalk
So it appears it went for 168 K$ at hammer.

With buyer's premium, that puts the sale price at 210 K$.

https://www.rrauction.com/bidtracker_detail.cfm?IN=5222




Re: Plane of core memory

2019-04-18 Thread Brent Hilpert via cctalk
On 2019-Apr-18, at 9:30 AM, Chuck Guzis via cctalk wrote:
> On 4/18/19 9:02 AM, Jim Manley via cctalk wrote:
>> Jussi Kilpelainen's page cited above (
>> https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduino/)
>> refers to the work of Ben North and Oliver Nash to create another core
>> memory shield for Arduino Unos.  Their site inspired Jussi to create his
>> shield kit, which can be viewed at:
>> 
>> http://www.corememoryshield.com
>> 
> 
> I remember seeing that one some time ago.
> 
> Anyone with a Williams tube project?  Mercury delay lines?
> Magnetostrictive delay memory?


- The Manchester Baby replica recreated Williams tube memory (aka 
Williams-Kilburn tube memory).
Williams tube memory uses conventional oscope CRTs, so it wasn't that difficult.
(i.e. it's Williams 'tube memory', rather than 'Williams tube' memory.)

Holding-beam CRT memory ala Whirlwind would be another matter as the tubes were 
highly specialised.


- The EDSAC replica is using a new-production magnetostrictive delay-line 
memory to substitute for the mercury tanks.
From what I've seen of it (utube), it's a standard MR looped-wire design using 
modern components and production techniques.



Re: Plane of core memory

2019-04-18 Thread Brent Hilpert via cctalk
On 2019-Apr-18, at 8:47 AM, Jon Elson wrote:
> On 04/18/2019 04:49 AM, Brent Hilpert via cctalk wrote:
>> It's a 4-wire 3D planar array. By topology and construction I would guess it 
>> date it from the 60s.
> Make that EARLY '60s.  As soon as somebody figured out that you could combine 
> the sense and inhibit wires, everybody immediately went to 3-wire planes.


Well, not everybody - I have a 4-wire, diagonal-sense module with IC date codes 
extending from 1974 to 1978.
Certainly it's an outlier, on the tail-end of the distribution curve of 
production of such design,
but that's why I expressed dating it to the 60s as a likelihood, not an 
absolute surety.

(The ICs are 711 comparators and diode arrays. The 711 does go back to at least 
1969 so it's conceivable
 the design of the module goes back to the late 60s, although that's seems less 
likely considering production into 1978.)




Re: Plane of core memory

2019-04-18 Thread Brent Hilpert via cctalk
On 2019-Apr-17, at 9:47 PM, Grant Taylor via cctalk wrote:
> On 4/17/19 10:30 PM, Andrew Luke Nesbit via cctalk wrote:
>> Hello all,
> 
> Hi,
> 
>> I have been wanting to acquire a plane of magnetic core memory as a piece of 
>> computing history.  My partner actually thinks they look very beautiful and 
>> says we should frame it, if we ever find a plane.
> ...
>> Does anybody here have any ideas?  For example, what is it?  Or, if you 
>> don't know, could you point me in the right direction so I can do the 
>> research myself?  Thanks!!
> 
> I have no idea.
> 
> The connectors remind me of a DEC machine bus, but I don't know what the bus 
> name is.  I also find it odd that memory would plug into the system bus like 
> that.


It doesn't plug into a system bus, it would plug into a dedicated slot 
connected to other dedicated boards.
There's piles of circuitry necessary for it be fully functional: decoded x/y 
drivers, inhibit drivers, sense amplifiers, word latch, cycle sequencer.

It's a 4-wire 3D planar array. By topology and construction I would guess it 
date it from the 60s.
Into the 70s most (American) core production had moved on to simpler weave 
topologies (the crosshatch sense winding, as in this unit, was very laborious 
to weave),
(although it is not precluded from being from the 70s).

From an historic perspective, the 4-wire, 3D, crosshatch sense aspects go back 
to the original core topology,
although here the earlier physical stack for the 3rd dimension is flattened to 
a planar array.



Re: "arx-149" computer. .. what Is?

2019-04-15 Thread Brent Hilpert via cctalk
On 2019-Apr-15, at 1:29 PM, William Donzelli wrote:
>> It doesn't show up here:
>>
>> https://en.wikipedia.org/wiki/List_of_military_electronics_of_the_United_States
> 
> I think 99.99mumble percent of JETDS systems ("AN/") do not show up on
> that list.
> 
> I have a 1972 edition of one of the JANAP guides (I forget which one)
> used to determine the security classification of every JETDS item up
> to that point (and I mean EVERY one, including the unicorns and
> unmentionable ones). 70 rows, 2 entries per row on each of the full
> pages. The book is close to 5 inches thick. And yes, from nearly 50
> years ago.
> 
> Wiki, shmiki.


Lovely. So have you checked it for the mentioned type?



Re: "arx-149" computer. .. what Is?

2019-04-15 Thread Brent Hilpert via cctalk
On 2019-Apr-15, at 12:16 PM, ED SHARPE via cctalk wrote:

> It is in a  metal  suitcase appears  to  be  military analog  computer Ed!
> 
> On 4/14/2019 5:44 PM, Sam O'nella via cctalk wrote:
>> Is there a specific reference you have for this?
>> 
>>> On Apr 14, 2019, at 2:16 AM, ED SHARPE via cctalk  
>>> wrote:
>>> 
>>> "arx-149"  computer. .. what Is?thanks ed#


It doesn't show up here:

https://en.wikipedia.org/wiki/List_of_military_electronics_of_the_United_States

Only two "149"s and no "ARX"s.



AGC DSKY auction / was Re: Control Console, but not PDP-10

2019-04-12 Thread Brent Hilpert via cctalk
On 2019-Apr-11, at 10:04 PM, Paul Birkel via cctalk wrote:
> 
> Now consider a DSKY.  Currently at $27,500.00.  Auction estimate: $60,000+
> Great provenance!  “The DSKY that saved Apollo 14.”
> 
> https://www.rrauction.com/bidtracker_detail.cfm?IN=5222


I looked up this auction too, after Marc mentioned it in his latest AGC 
restoration video.

But while looking up the current auction, an earlier auction showed up.
The same auction house sold a DSKY in 2011 for  93K$.

https://www.rrauction.com/past_auction_item.cfm?ID=3242600

(That 93K$ includes the buyer's premium, so the hammer price was presumably 
74K$, for comparing to the current auction.)

My sense is awareness of the AGC has gone up in the intervening years, so this 
sale will be interesting.
I guess one could debate which one has a more 'valuable' provenance.

One can only speculate what an entire AGC would go for.



Re: Yes there is a PDP 10 front panel and Kenbak on Ebay

2019-04-04 Thread Brent Hilpert via cctalk
On 2019-Apr-03, at 11:17 PM, Pontus Pihlgren via cctalk wrote:

> Could you provide an URL. ebay search works (or not works) in mysterious 
> ways.


https://www.ebay.com/itm/Digital-Equipment-PDP-10-Control-Console/183760017149

https://www.ebay.com/itm/ULTRA-Rare-Vintage-ORIGINAL-KENBAK-1-aka-CTI-5050-Computer-1st-Personal/254187561426

AGC restoration / was Re: PDP-8 signed overflow detection - Apollo guidace computer

2019-03-26 Thread Brent Hilpert via cctalk
On 2019-Mar-26, at 9:28 AM, Noel Chiappa via cctalk wrote:
>> From: Ben Bfranchuk
> 
>> Now they seem to have have found a SCRAPPED Apollo guidance
>> computer and am rebuilding the missing pieces.
> 
> Wow. What a great site (and that guy has mad skills, everything from
> repairing old Teletypes, through designing boards, to repairing analog
> stuff). Just 'wasted' a good chunk of the morning reading back through
> it; tons of really neat things (including recovery of the very first
> FORTH, along with a lot of Diablo drive - from the Alto - repairs).
> 
> As a shortcut, here:
> 
>  http://rescue1130.blogspot.com/2018/11/
> 
> is the backstory on the AGC; about 1/3 of the way down, in "Restoring an
> Apollo Guidance Computer, part V".



This is the same AGC restoration that curious marc has been making videos about:

https://www.youtube.com/watch?v=2KSahAoOLdU

The project and videos were mentioned on the list back in December.
There's an interview with Jimmie there (4:13) with more details about the 
backstory.



Re: Only never in Canada - dumb terminals - video tex

2019-03-24 Thread Brent Hilpert via cctalk
On 2019-Mar-24, at 3:14 PM, ben via cctalk wrote:
> On 3/24/2019 10:27 AM, Mike Stein via cctalk wrote:
>> And I have some in Toronto; Falco, ADM-11 and bits & pieces.
> Did anyone out there (In Canada) buy the surplus VideoTex terminals,
> I saw Many Many  years  ago.



Like this?:
http://madrona.ca/e/telidon/index.html

Can't say I bought it, it was a donation, and I don't know the story of whoever 
donated it.
Might have been purchased from the surplus store BCTel used to run, or it may 
have come from a former Microtel employee, or who knows.

Saw a boxed converter-only unit (needed a TV for the display) in a thrift store 
around 2000, but passed it over.
(I'm sure everybody else did too).

I also scrapped a converter-only unit back around 2000 or so.



Re: What 6502 macro assembler was used for the AIM-65 Monitor ROM?

2019-03-22 Thread Brent Hilpert via cctalk
On 2019-Mar-22, at 11:14 AM, Chuck Guzis via cctalk wrote:
> On 3/22/19 10:28 AM, Glen Slick via cctalk wrote:
>> On Fri, Mar 22, 2019 at 9:59 AM Chuck Guzis via cctalk
>>  wrote:
>>> 
>>> At the expense of being boo-ed for this, could the original Rockwell
>>> stuff perhaps have been assembled using a mainframe/mini-hosted
>>> cross-assembler?
>>> 
>>> I'm aware of several situations where this was the case.
>> 
>> The date in the AIM-65 Monitor Program Listing header block in the
>> source code is Aug 22, 1978. That is less than 1 year after the
>> introduction date of the VAX-11/780. I suppose it still could have
>> been something that ran on a VAX by then, or a PDP-11 (or PDP-10?), or
>> some other mainframe/mini host if it wasn't self hosted on a Rockwell
>> 6502 development system.
>> 
>> It's really just more of a curiosity issue at this point if anyone
>> finds a definitive answer.
> 
> Many cross-assemblers for early MPUs were written in (shudder!) FORTRAN.
> There were several good reasons for this.
> 
> The first is that if you had a mini or mainframe, you were pretty much
> guaranteed to have FORTRAN, which had been implemented under various
> standards since 1966.
> 
> The other is that in the 70s, there was still a population of six-bit
> character machines not using ASCII, not to forget the ones using EBCDIC.
> So hard-coding character sets into programs that were supposed to be
> portable over a wide range of machines was an issue.
> 
> I think some of the old FORTRAN code for PALASM may still be around, as
> an example.

In that vein:

When I was tasked (1980) with producing a cross-assembler and cross-compiler
for the 68000 for our R sys, (Verex OS / Z language), the first operating 
target
was Motorola's 68000 emulator running on the campus mainframe (MTS on Amdahl / 
370).
(Followed by hardware, which was a 68000 exerciser board or a bare SUN-1 
processor board).

I'm pretty sure there was also a 68000 cross-assembler from Moto on the Amdahl,
although I'm not sure whether I used it or not, might have to confirm it's 
output with the output from mine.
IIRC the Moto programs were written in Fortran (oops, FORTRAN).



Re: DEC RC25 / CDC 9457 lark disc

2019-03-12 Thread Brent Hilpert via cctalk
On 2019-Mar-12, at 1:21 AM, shad via cctech wrote:
> I always have been amazed by the complexity and peculiarity of
> fixed/removable hybrid discs like DEC RC25 and CDC 9457.
> Looking at some specifications found on the web, these drives look quite
> similar each other, even if these are completely different on an exterior /
> interface point of view...
> Maybe there's some compatibility between the two products?


Comparing an RC25 cartridge in my hands with pics of a 9457 cartridge online;
at a quick glance they look similar, with the two angled corners and grip area.
However they actually have significant differences:
- the RC25 has a sliding door over the hub mount, while the 9457 
doesn't,
- the head-arm access door is very different between the two,
- the hub attachment appears to be different.

So it doesn't look like the cartridges would be swappable in either direction.

Whether there might be compatibility at the platter/encoding level I have no 
idea.
The concept, platter size, and time period are similar enough that one would 
wonder whether
they shared some development history, such as (speculating) initial dev by CDC 
and
licensed and repackaged by DEC.



Re: Thinking about PDP11 PC05 Emulation

2019-03-11 Thread Brent Hilpert via cctalk
On 2019-Mar-11, at 2:37 PM, allison via cctech wrote:
> On 03/11/2019 02:11 PM, Jay Jaeger via cctech wrote:
>> I have several PDP-11's in my collection (among other things), and not
>> enough PC05 tape readers (or enough room) to go around.  But most if not
>> all of my machines have M7810 PC11 interfaces, and I have one I could
>> move from machine to machine as needed.  Moving a PC05 around would be a
>> lot more work, and not every rack has room.  ;)
>> 
>> So, I took a look at what it might take to interface with an M7810 (or,
>> down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
>> have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
>> IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
>> Qualify or Skip], and would have to drive 11 lines into the pullups on
>> the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
>> RDR RUN L/RDR Busy L).
>> 
>> So, a total of 14 interface lines. (The 8 or 12 would take a few more
>> lines).

. . . 

>> BUT - it also occurs to me someone may have already done something like
>> this?  Any leads / ideas?

. . .
> To do the data you need 8 bits but you can bit bang them out using two
> lines on a nano to
> a 74ls164.  The rest you use transistors (open collector) to do high
> current (though 5V,
> 1K pullup is only 5ma) and I'd do that to make the IO more rugged and
> ESD proof.  That
> covers the strobes and control lines.  Just using two lines to get the 8
> data lines via a 164
> frees enogh pins for there to be surplus IO lines.

. . .

I've used an RPi for tasks like this in much the same way as Allison is 
describing -
reduce the number of I/O pins needed on the modern microcontroller by 
serialising
the legacy-device parallel data lines with a simple TTL shift register.
2-4 pins (CLK,LATCH,DIN,DOUT, depending on app) from the microcontroller
can be translated to 8,16,32 or as many data lines as you need.



Re: Thinking about PDP11 PC05 Emulation

2019-03-11 Thread Brent Hilpert via cctalk
On 2019-Mar-11, at 2:37 PM, allison via cctech wrote:
> On 03/11/2019 02:11 PM, Jay Jaeger via cctech wrote:
>> I have several PDP-11's in my collection (among other things), and not
>> enough PC05 tape readers (or enough room) to go around.  But most if not
>> all of my machines have M7810 PC11 interfaces, and I have one I could
>> move from machine to machine as needed.  Moving a PC05 around would be a
>> lot more work, and not every rack has room.  ;)
>> 
>> So, I took a look at what it might take to interface with an M7810 (or,
>> down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
>> have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
>> IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
>> Qualify or Skip], and would have to drive 11 lines into the pullups on
>> the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
>> RDR RUN L/RDR Busy L).
>> 
>> So, a total of 14 interface lines. (The 8 or 12 would take a few more
>> lines).

. . . 

>> BUT - it also occurs to me someone may have already done something like
>> this?  Any leads / ideas?

. . .
> To do the data you need 8 bits but you can bit bang them out using two
> lines on a nano to
> a 74ls164.  The rest you use transistors (open collector) to do high
> current (though 5V,
> 1K pullup is only 5ma) and I'd do that to make the IO more rugged and
> ESD proof.  That
> covers the strobes and control lines.  Just using two lines to get the 8
> data lines via a 164
> frees enogh pins for there to be surplus IO lines.

. . .

I've used an RPi for tasks like this in much the same way as Allison is 
describing -
reduce the number of I/O pins needed on the modern microcontroller by 
serialising
the legacy-device parallel data lines with a simple TTL shift register.
2-4 pins (CLK,LATCH,DIN,DOUT, depending on app) from the microcontroller
can be translated to 8,16,32 or as many data lines as you need.



Re: Pioneers of computing

2019-03-11 Thread Brent Hilpert via cctalk
On 2019-Mar-10, at 5:16 PM, Al Kossow via cctalk wrote:
> On 3/10/19 2:18 PM, Murray McCullough via cctalk wrote:
>> Historians, though not all, credit this development as the
>> beginning of the electronic-computing revolution that was truly underway by
>> the mid-70s.
> 
> Scotty, more power to the Reality Distortion Field!


It's not an out-to-lunch suggestion.

The digital pocket calculator was the first mass-market digital electronic 
device to be put in the hands of the consumer.

Yes, all of us here know there were digital computers and other digital 
electronic devices around many years before, 
but the digital pocket calculator has a significant place at the beginnings of 
the transition to the ubiquity of such technology in everyday life,
as opposed to being behind-the-scenes in business, labs, and industry.

One can argue the transition would have happened without the pocket-calculator 
market -
just how influential it was in driving the innovation can be debated - but the 
historical fact is it was there,
and a large market in the context.



Re: Pioneers of computing

2019-03-11 Thread Brent Hilpert via cctalk
On 2019-Mar-10, at 3:59 PM, Will Cooke via cctalk wrote:
>> On 3/10/2019 3:18 PM, Murray McCullough via cctalk wrote:
>>> Back in 1965 Jack Kilby, Jerry Merryman and James Van Tassel at texas
>>> Instruments created an integrated circuit designed to replace the
>>> calulator. Historians, though not all, credit this development as the
>>> beginning of the electronic-computing revolution that was truly underway by
>>> the mid-70s. Vintage/classic computing our hobby goes back that far as us
>>> baby-boomers can attest to.
. . .
> Here is a little bit of info on it:
> http://www.vintagecalculators.com/html/ti_cal-tech1.html


On 2019-Mar-10, at 10:48 PM, ben via cctalk wrote:
> On 3/10/2019 7:30 PM, Guy Dunphy via cctalk wrote:
> 
>>> Here is a little bit of info on it:
>>> http://www.vintagecalculators.com/html/ti_cal-tech1.html
>> That's fascinating, thanks. I'd never heard of it.
>> The Intel 4004 came out in 1971.   https://en.wikipedia.org/wiki/Intel_4004
>> I'd understood that was the first chip that could be considered a 
>> 'processor' (though it required some support chips to do anything.)
>> The TI Cal-Tech design was begun in 1965 and they had a working calculator 
>> in 1967. I wonder if the chips in that had any kind of code programmability?

> Looking at the vintage calculator page, I would give the "FAR EAST" my vote 
> for the first processor type chips. Everything was in-house development you 
> can say they all came out at the same time. Look at TTL
> pre 1970 4 gate logic, after 1970 74181 alu 7416x 4 bit counters 7489 16x4 
> RAM. About 1973 Tristate logic and 32x8 , 256x4 PROMS.


If you read the link provided by Will, the Cal-tech was four ICs, not one.
It was a forward-thinking lab R project which you would expect to be ahead of 
the IC technology on the market.

It would be several more years, ca. 1971 before the complete logic for a 
calculator was stuffed onto one chip and available on the market,
so coincident in time with the 4004.
There was the TMS-0100 series from TI , single-chip calculators, 1971.
https://en.wikichip.org/wiki/ti/tms0100

TI and others did produce some calculator chip-sets (calc on several dedicated 
LSI chips) for the market prior to the single-chip implementations.

No, the first 'processor-type' chips didn't come out of the 'far east'.
The Japanese were producing calculators with hard-wired / random logic / 
dedicated state-machine architectures in the late 60s.
With the advent of LSI, they came to the Americans to get chips designed, 
resulting in one case in the 4004.

See also the TMS1795 (1971) and TMS1000 (1974).
Rockwell was another of the big players.




Re: 1983 UBC PDP-11 Unix tools distribution

2019-03-06 Thread Brent Hilpert via cctalk
On 2019-Mar-05, at 10:07 PM, Richard Loken wrote:
> On Tue, 5 Mar 2019, Brent Hilpert via cctalk wrote:
> 
>> TRIUMF was using /11s for cyclotron control I believe, that's not where you 
>> anticipate UNIX showing up.
> 
> But was it Unix or something else like RT-11?  Or was it a VAX?
> 
> Between 1985 and 1990 I became aquainted with a guy named Jim Stewart who was 
> teaching VAX/VMS programming for DEC in Vancouver and had a previous life 
> administering and programming VAX/VMS machines at TRIUMF.

Well, I don't know for certain, I was just trying to recall where I was aware 
of there being /11's around campus.
I had the impression from somewhere at the time that /11s were running the 
cyclotron, or were present in some significant capacity at TRIUMF.
It would make sense in terms of TRIUMF chronological dev, predating VAX.
And for real-time control, don't expect UNIX.

So I wasn't aware of, or it seemed unlikely to me, the tools came out of TRIUMF.
The quoted text from the tape seems to confirm it came out the UBC biosci 
service.

Granted that a facility like TRIUMF can be expected to have more than one 
computing cluster/service.
Come to recall, I did have some minor contact with TRIUMF in a professional 
capacity -
we supplied our X400 email program to them (as well as to the biosci facility),
and that would have been for a VAX, most likely VMS, machine.
The HEP community was quite fond of VAXen & VMS in that era.


> Even three or four years ago Dow Chemical was still using VAXen running VMS 
> to manage their chemical plant(s) near Fort Saskatchewan, Alberta and some 
> time earlier the last surviving L-1011 (or was it a DC10?) flight simulator 
> was in Vancouver and it was controlled by a VAX-11/7?? long after VAXen had 
> fallen out of fashion.
> 
> PDP11 boxes and VAXen show up in some really obscure places.




Re: 1983 UBC PDP-11 Unix tools distribution

2019-03-05 Thread Brent Hilpert via cctalk
On 2019-Mar-05, at 8:36 PM, Warner Losh via cctalk wrote:
> On Tue, Mar 5, 2019 at 5:17 PM Al Kossow via cctalk 
> wrote:
>> On 3/5/19 5:16 PM, Al Kossow via cctalk wrote:
>>> Today's tape recovery gem. UBC's PDP-11 UNIX tools distribution ca. 1983
>> 
>> oh.. and Bill Webb's name is all over this stuff
>> 
>> Bill went to IBM, and worked on AOS for the PC-RT
> 
> UBC is what? University of British Columbia?


That was my first question too.
Having worked at the University of British Columbia through that era, a "UNIX 
tools distribution" kind of surprised me,
and was wondering if it was some other meaning of "UBC".

The Computing Centre (at that time) had nothing to do with UNIX, revolving 
entirely around MTS.
They used /11s as front-end terminal muxes for the MTS mainframe, but those 
were running their own
internal system software written in their own language (PLUS, IIRC).

The Computer Science Dept. (my home base) ignored ATT Unix and had no /11s 
running UNIX, instead running BSD on vax(en).

There was a small facility in biosci or genetics running UNIX on /11s or 
(later) a vax (IIRC), serving the bio community.
I had some minor association with them, saw the machine room once and recall 
the fellow who managed it,
but was unaware of them doing general system tools development, or being known 
for such outside the university/bio dept.

TRIUMF was using /11s for cyclotron control I believe, that's not where you 
anticipate UNIX showing up.

But . . . buried in ubc/fcdoc/fclet is:

)m Biology Data Center 
)l 2204 Main Mall
)l The University of British Columbia
)l Vancouver, B.C., Canada ~~V6T 1W5 )ml2e
go
)t2 August 24, 1979.
)l2 Dear Fortran 77 user:
!p there is now available a new version of the UBC Fortran 77 compiler. 
. . .
. . . 
)l6t2 Sincerly )l4t2 W. E. Webb 

Learn somethin' new every day.



Re: BASIC for HP 1000, 21xx series

2019-02-24 Thread Brent Hilpert via cctalk
On 2019-Feb-24, at 2:03 AM, GerardCJAT via cctalk wrote:

> Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 
> 2116B, 2100A, just for FUN.
> 
> Is there some copy still around ??
> 
> I had a look in Google, Bitsavers, HPmuseum, with NO success.
> 
> Thank for help and/or advise.


This is my own writeup about it, including assembler source and loader files, 
but as noted there it's Guy Sotomayor (list member)
 that deserves the thanks for keeping it around and making it available:

http://madrona.ca/e/HP21xx/software/hpbasic/index.html

The source files are also available on bitsavers, link included on above page. 



Re: PDP-11/45 RSTS/E boot problem

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 10:37 PM, Fritz Mueller via cctalk wrote:

>> 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 
>> 14.5uS from the manual would give 1.86 mS, 7% shy of 2.
>> The schematic specs 1% resistors, and the parts list does appear to spec a 
>> high-tolerance "1%200PPM" cap.
>> 
>> Although there are the internal voltage divider Rs in the 555 which are also 
>> critical for the timing and everything is 40+ years old.
>> 
>> Idle speculation at my distance, we'll see what Fritz observes.
> 
> Brent:  11.8us, 6.4us position 
> Manual: 14.5us, 6.0us positive
> Actual: 15.2us, 8.5us positive
> 
> So yeah, a little pokey there...


15.2uS gives a 1.95mS refresh, so it's awfully close to the 2mS spec, but still 
within.
The datasheet I was looking at doesn't seem to give any spec for tolerance on 
the refresh so one would guess there's a safety margin built into the 2mS spec.

Seems a little less-likely to be the problem, given(?) as well that you have 
fairly consistent (is deterministic overstating it?) behaviour.

If you wanted to test it by experiment, without having to remove the installed 
Rs, you could test-clip another R in parallel with the 38.4K,
probably something around 200K, to shorten the 555 period.



Re: Mounting HP7970e 9-Trk 1/2" Tape Drive

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 7:48 PM, Chuck Guzis via cctalk wrote:
> On 2/6/19 6:33 PM, Brent Hilpert via cctalk wrote:
> 
>> Granted you could drill the holes from the rear of the flange,
>> however from what I can see the hinge design doesn't look like it
>> will allow the transport frame to swing far enough to clear access
>> for the screwdriver shaft to tighten the screws from the front (might
>> swing to around 110deg, but not to 170-180). The 2-1/2" thick
>> transport frame pivots near the middle of it's thickness, at 90deg
>> half the thickness is still well across the flange. You'd need a ~ <
>> 1" clearance right angle screwdriver to fit between the flange and
>> the transport frame, or bolt head screws and box wrench which then
>> necessitates the milling of clearance for the heads out of the cast
>> frame.
> 
> 
> Nah, there's plenty of room to get a screwdriver in there.  I've had
> much tighter spots.


Well, maybe they changed the hinge design slightly for the model you're looking 
at.
Here are some pics of the 7970A with the transport open at 90 deg:
http://madrona.ca/tmp/HP7970A/hingeTop.jpg
http://madrona.ca/tmp/HP7970A/hingeInt.jpg
http://madrona.ca/tmp/HP7970A/hingeExt.jpg

That's about 1-1/4" between the flange and the cast frame.
There's no way you're angling a regular shafted screwdriver in there to 
adequately tighten screws.
One could undo the catch that limits the angle of swing, but I still don't 
expect it's going to swing far
enough to get the frame out of the way, let alone the PCBs and motors still in 
the way.

(The black part next to the Al flange is the 'proper' steel mounting bracket.)

Flat-head hex bolts with a shortened allen-key could do it, as long as the 
tensional strength of the screw-heads was adequate.



Re: Mounting HP7970e 9-Trk 1/2" Tape Drive

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 4:19 PM, Chuck Guzis via cctalk wrote:
> On 2/6/19 2:29 PM, Brent Hilpert via cctalk wrote:
> 
>> (I take it you mean "now look at the -left- side".)
> 
> Well, you know, my *other* right... :)
> 
>> However, looking at my 7970A, it appears you could separate the cast-Al 
>> transport frame from the chassis box
>> by unscrewing the 4 exterior left-side hinge screws, as well as detaching 
>> all the cabling between them involving
>> a wire harness and a dozen-or-so plugs.
> 
> Swing the drive assembly out from the back cover--you'll note that the
> pivot points on the two hinges are about 1" away from the cover flange.
> You've got plenty of room to drill your mounting holes from the *rear*
> of that flange.  You might even have enough clearance for a
> countersink--but that may not be necessary--the frame casting only
> extends in from the left about a half-inch--you may even clear some
> oval-headed screws or get away with some truss-head screws.
> Alternatively, could mill a slight relief in the casting to clear the heads.
> 
> I think it's doable without removing the drive from the cover.

Granted you could drill the holes from the rear of the flange, however from 
what I can see the hinge design doesn't look
like it will allow the transport frame to swing far enough to clear access for 
the screwdriver shaft to tighten the screws from the front
(might swing to around 110deg, but not to 170-180).
The 2-1/2" thick transport frame pivots near the middle of it's thickness, at 
90deg half the thickness is still well across the flange.
You'd need a ~ < 1" clearance right angle screwdriver to fit between the flange 
and the transport frame,
or bolt head screws and box wrench which then necessitates the milling of 
clearance for the heads out of the cast frame.

I might consider the transport removal approach next time I have to mount mine 
- 
even though I have the proper mounting bracket - just to split the weight up.
I did once do a one-person free-lift mount of the thing, but that was about 20 
years ago.


>> For loading concerns raised by Jay, in both cases (designed-for steel
>> bracket vs drilled flange) the weight of the drive ends up being 
>> borne by 4 rack-screws on the left and 3 on the right. The difference
>> would be steel vs Al bearing down on the 4 screws on the left, and
>> some altered bending moments on the left side of the Al chassis box
>> around the flange, offhand I wouldn't think it would matter.
> 
> I tend to agree--the force is mostly downward on the front of the drive.
> I suppose that you could reinforce the aluminum housing with some steel
> bar backing up the mounting flanges, but that seems like overkill to me.



Re: PDP-11/45 RSTS/E boot problem

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 5:29 PM, Paul Koning wrote:
>> On Feb 6, 2019, at 8:25 PM, Brent Hilpert via cctalk  
>> wrote:
>> On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote:
>>>>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk 
>>>>>  wrote:
>>>>> 
>>>>> Is the schematic available for the memory board at-issue?
>>>>> Curious myself to see what approach for refresh DEC used.
>>>> 
>>>> Yes, here: 
>>>> http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
>>> 
>>> For completeness, from the technical manual:
>>> 
>>> "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H 
>>> and the refresh address. Sig- nal REF CLK H is derived from a 555 timer 
>>> (E5) which is set up as a free running oscillator, powered by the + IS V / 
>>> + 12 V module input (V-555). The REF CLK H signal oscillates with a period 
>>> of 14.5us and has a positive pulse width of 6us during each period."
>> 
>> So I could have saved myself some fun if I had read the manual rather than 
>> just looking at the schematic.
>> Not that they're way out of whack, but the mild disparity between the 
>> manual's 14.5uS and my calculated 11.7uS is curious
>> (the calculation being based on the schematic RC values and the 555 
>> equations).
> 
> Perhaps the period was changed in a schematic rev or ECO, and the manual 
> wasn't updated to reflect it.  It would be interesting to check the data 
> sheet for the RAM chip to see what it likes for refresh cycle.  And given 
> that this is an RC oscillator your theory about out of tolerance timing 
> definitely deserves checking.


Checking further..

4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS 
from the manual would give 1.86 mS, 7% shy of 2.
The schematic specs 1% resistors, and the parts list does appear to spec a 
high-tolerance "1%200PPM" cap.

Although there are the internal voltage divider Rs in the 555 which are also 
critical for the timing and everything is 40+ years old.

Idle speculation at my distance, we'll see what Fritz observes.
Could be other problems in the refresh circuitry too, like failed outputs from 
the row counter, etc.



Re: PDP-11/45 RSTS/E boot problem

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 3:39 PM, Fritz Mueller wrote:
>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk  
>> wrote:
>> 
>> Is the schematic available for the memory board at-issue?
>> Curious myself to see what approach for refresh DEC used.
> 
> Yes, here: 
> http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
> 
> There is also a technical manual adjacent, with circuit descriptions.
> 
> I will scope this up tonight and take a look!

Mixed up To: fields.
The following was intended to go to the list and was originally sent a moment 
before I saw Fritz's message mentioning the 555:


Ha!, simple free-running 555 oscillator generating the refresh cycles 
(pdf.pg27).

I suspect there is a mistake in the schematic there:
V-555 more likely connects on the other side of R4 (E5.4-C1-R4, rather 
than E5.7-R4-R5)
to make it into the standard 555 astable circuit.

Based on that, calculations indicate that the output from E5 (TP18) should be 
around 85 KHz, cycling 6.4 uS high, 5.3 uS low.
So it's generating a refresh cycle every 11.8 uS. With 7 bits used from counter 
E43 (128 rows) for full refresh, that's a cell refresh
every 1.5mS which (without having checked the 4116 specs) sounds sensible for a 
DRAM from that period.

Note the 555 (E5) is running on +12 or +15V, with a R voltage divider on the 
output before driving into TTL.


Re: PDP-11/45 RSTS/E boot problem

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote:
>>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk 
>>>  wrote:
>>> 
>>> Is the schematic available for the memory board at-issue?
>>> Curious myself to see what approach for refresh DEC used.
>> 
>> Yes, here: 
>> http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
> 
> For completeness, from the technical manual:
> 
> "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H 
> and the refresh address. Sig- nal REF CLK H is derived from a 555 timer (E5) 
> which is set up as a free running oscillator, powered by the + IS V / + 12 V 
> module input (V-555). The REF CLK H signal oscillates with a period of 14.5us 
> and has a positive pulse width of 6us during each period."



So I could have saved myself some fun if I had read the manual rather than just 
looking at the schematic.
Not that they're way out of whack, but the mild disparity between the manual's 
14.5uS and my calculated 11.7uS is curious
(the calculation being based on the schematic RC values and the 555 equations).



Re: Mounting HP7970e 9-Trk 1/2" Tape Drive

2019-02-06 Thread Brent Hilpert via cctalk


On 2019-Feb-06, at 12:24 PM, Chuck Guzis via cctalk wrote:

> On 2/6/19 11:25 AM, Jay West wrote:
> 
>> Yes, it's all "standard 19 inch" but. the HP gear and mounting
>> kits of that time expected certain things to be present in the rack
>> design/construction well beyond just the space between the vertical
>> posts.
>> 
>> As I recall, on the left, the flange (where mounting holes are - on
>> the right) does not have mounting holes. And drilling and tapping
>> would be difficult because a 2 inch thick piece of solid metal from
>> the side of the casting covers those...
> 
> Okay, here's what I'm talking about.  Take a look at PDF page 6 from
> this document:
> 
> http://bitsavers.informatik.uni-stuttgart.de/pdf/hp/tape/7970/07970-90383_7970B_7970C_Operating_and_Service_Manual_upd_Feb76/07970-90383_7970B_7970C_Operating_and_Service_Manual_Section_1.pdf
> 
> This shows very clearly the naked "box" without the transport works.
> Said box is aluminum, with 1/8" or so thick flanges on each side.
> 
> Note that the right side has 3 mounting slots (and the transport has 3
> "notches" to make room for bolt heads and washers.
> 
> Now look at the right side of the drive box.

(I take it you mean "now look at the -left- side".)

If you drill holes in the left-side flange for rack mounting, you have to be 
able to access them at mount time,
which is not possible with the drive fully assembled.

However, looking at my 7970A, it appears you could separate the cast-Al 
transport frame from the chassis box
by unscrewing the 4 exterior left-side hinge screws, as well as detaching all 
the cabling between them involving
a wire harness and a dozen-or-so plugs.

This would have the benefit of splitting up the weight involved in the mounting 
process.
Holding the transport frame and aligning it with the hinges during reattachment 
while trying to get the screws
in place might nonetheless require two people.

In a slightly-alternate design, HP might have made the left-side bezel over the 
manual controls removable,
giving access to the left-side flange without detaching the transport frame, 
but that would also require a slight modification
to the casting near the screw holes for clearance for the screws.

For loading concerns raised by Jay, in both cases (designed-for steel bracket 
vs drilled flange) the weight of the drive ends up being
borne by 4 rack-screws on the left and 3 on the right.
The difference would be steel vs Al bearing down on the 4 screws on the left, 
and some altered bending moments on the
left side of the Al chassis box around the flange, offhand I wouldn't think it 
would matter.



>  Note that the hinges for
> the transport are secured to a similar flange, but without any mounting
> holes.   I propose that drilling a couple of mounting holes to match
> rack spacing and countersinking said holes so that they don't interfere
> with the transport body would do the trick.  My rack uses cage nuts on
> the rails, so there would be no fiddling with nuts and bolts.  I'd
> probably also feel better if the rear of the drive were secured to the
> rack also, but I haven't worked that one out yet--nor am I likely too,
> as my current setup works just fine without the danger of hernia.



Re: PDP-11/45 RSTS/E boot problem

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 1:21 PM, Noel Chiappa via cctalk wrote:
>> From: Brent Hilpert
> 
>> what about the refresh circuitry of the memory board?
>> ...
>> It might also explain why a number of 4116s were (apparently) failing
>> earlier in the efforts ... replacing them might have just replaced them
>> with 'slightly better' chips, i.e. with a slightly longer refresh tolerance.
> 
> Ooh, excellent idea!


Is the schematic available for the memory board at-issue?
Curious myself to see what approach for refresh DEC used.



Re: PDP-11/45 RSTS/E boot problem

2019-02-06 Thread Brent Hilpert via cctalk
On 2019-Feb-06, at 10:53 AM, Noel Chiappa via cctalk wrote:
> 
> I'm not sure that's going to tell us much: the latest development is that
> Fritz looked at the actual memory contents again, and it is once again
> trash; _almost_ identical to what was there before:
> 
>  PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144
> 
> but with some extra 01 bits:
> 
>  PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
> 
> (It's not clear if this represents a real difference, or if that 
> front panel issue Fritz mentioned caused the contents to be displayed
> incorrectly.)
> 
> The exciting thing is that if the latter really is what's in main memory,
> that '16700 16152' at the PC of the MM trap could indeed generate the MM trap
> we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1,
> which is only 03500 long
> 
> If so, i) we're down to one problem (good news), and our problem turns into
> finding out how that section of the code got trashed (bad news). Which is not
> going to be simple, alas, I suspect. I don't think it's the RK11, because
> Unix reads the program image into system buffers in low memory, and that's
> clearly working OK in the 'sleep;ls' case. (It may not use the exact same
> buffers, though...) It then copies it out to the memory where it's going to
> execute from, using an MTPI loop. So maybe the memory still has issues, or
> maybe the MTPI isn't working with some main memory locations or or or...


I haven't followed this in detail enough to know what the configuration and 
memory board at play are so maybe
this can be ruled out from your end, but for consideration, what about the 
refresh circuitry of the memory board?

Mem diagnostics, unless they explicitly account for it, may not show up 
problems with memory refresh
if the loop times are short enough to effectively substitute as refresh cycles, 
while they could show up later in
real-world use with arbitrary time between accesses.

Refresh on some early boards/systems was asynchronously timed by monostables or 
onboard oscillators
which can drift or fail on the margin/slope. (I don't know what DEC's design 
policy was for DRAM refresh).
It might also explain why a number of 4116s were (apparently) failing earlier 
in the efforts (if I recall the discussion correctly),
replacing them might have just replaced them with 'slightly better' chips, i.e. 
with a slightly longer refresh tolerance.



Re: Mounting HP7970e 9-Trk 1/2" Tape Drive

2019-02-04 Thread Brent Hilpert via cctalk
On 2019-Feb-04, at 3:40 PM, Jack Harper via cctalk wrote:
> 
> I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to a 
> 19" rack.
> 
> The screw holes that mate to the standard spaced holes on the right side of 
> the drive after you open the case are visible and obvious.
> 
> However, the holes on the left are hidden under the heavy die-cast(?) frame 
> of the drive.
> 
> Anyone know how to get to those three screw holes with a horrible disassembly.
> 
> There has to be a trick to this that I don't see (so what else is new? :)


If, or presuming, it's the same as the 7970A:

The left-side mount is actually a vertical right-angle bracket screwed to the 
drive proper.

1. Open the drive and unscrew that bracket from the inside.
2. Mount the bracket to the left side of the rack.
3. Lift the drive into place. The mounted bracket has a short right 
angle bend at the bottom (and top)
 that provides a lip on which to rest some of the weight of the 
drive and guide it in.
4. Screw the right side of the drive to the rack.
5. Replace the screws removed in step 1, reattaching the drive to the 
bracket.

The right side of the drive (should) have little pieces of 1/8" thick aluminum 
glued at the back of the rack-mount holes to match
the thickness of the left-side bracket, to make the drive seat parallel to the 
face of the rack.
In my (limited) experience those can have a tendency to fall off and may be 
lost when the drive is unmounted due to dried glue.



Original AGC restoration / was Re: Apollo 8 Mission Control printers, or not?

2018-12-28 Thread Brent Hilpert via cctalk
On 2018-Dec-28, at 4:43 PM, Adrian Stoness via cctalk wrote:
> have u seen the agc being fired up videos


Yes, videos from list member curiousMarc :
Episode 1:   https://www.youtube.com/watch?v=2KSahAoOLdU

He's up to Episode 5, the others should show up in subsequent links from the 
1st.

Lucky bunch of guys to have the opportunity (although I can't say I'd want to 
be stuck in a congested hotel room like that for the task).



Re: CDC floppy disks on Ebay.

2018-12-09 Thread Brent Hilpert via cctalk
On 2018-Dec-09, at 2:06 PM, Adrian Graham via cctalk wrote:
>> On 9 Dec 2018, at 21:40, Mattis Lind via cctalk  
>> wrote:
>> 
>> Don't know if this worth saving. https://www.ebay.com/itm/283294561797
>> 
>> 8 inch CDC disks from 1982. Maybe something interesting?
> 
> It might be just me, but those look like they’ve got great big holes cut in 
> them?
> 

If you're thinking of the blue 'slashes' near the horizontal middle of the 
disks that look like the back of the pouch showing through a hole cut in the 
disk, I think those are  actually tabs on the back of the pouch extending up in 
front of the next disk back, kind of like file folder tabs.
Don't think I've seen pouches with that before but probably intended to make it 
easy to grab a disk by the pouch when they're all down in the box.
Look at the magnified view of the 3rd pic.

Re: Battery warning in Falco terminals

2018-11-20 Thread Brent Hilpert via cctalk
On 2018-Nov-20, at 11:18 AM, Paul Koning wrote:
>> On Nov 20, 2018, at 2:07 PM, Brent Hilpert via cctalk 
>>  wrote:
>> 
>> ...
>> The PCB-transformer key design is novel, but (in the TS-1) so is the 
>> scanning & communication.
>> There is no microcontroller on the keyboard, scanning is performed by the 
>> main unit, it sends a key matrix address to the keyboard in serial, the 
>> keyboard sends back nothing but a binary key-pressed indication.
> 
> I'm not positive, but my impression is that the same is true for the VT-100 
> keyboard.


You may be right, rings a bell from working on one,
Wasn't intending to suggest the falco was necessarily unique.
IIRC, the VT-100 keyboard comm involved standard async UARTs.
It's a little weirder on the TS-1, one edge of pulses on the address-line are a 
clock-pulse, some uS later - determined by a monostable - the state of the same 
line is sampled for an address bit. After 8-10 such pulses the matrix is 
strobed, involving another monostable, so there are some timing issues both 
sides have to independently account for.



Re: Battery warning in Falco terminals

2018-11-20 Thread Brent Hilpert via cctalk
On 2018-Nov-20, at 11:42 AM, Al Kossow via cctalk wrote:
> On 11/20/18 11:28 AM, Brent Hilpert via cctalk wrote:
> 
>> Were there 3 PROMs on the TS-1? I don't remember
> 
> There are three bipolar proms on the 2624 that you can see on the pcb picture
> I still need to dump those, only one is socketed.
> 
> It looks like the keyboard is very similar in the 2624 with an added row of
> function keys.
> 
> I just bought the users and programming manuals for the TS-1, need to get 
> those
> scanned today.



Just curiousity, but was there something special about the Falcos that's 
generating particular interest, or of note?

Re: Battery warning in Falco terminals

2018-11-20 Thread Brent Hilpert via cctalk
On 2018-Nov-20, at 1:21 AM, Mike Stein via cctalk wrote:
> - Original Message - 
> From: "Al Kossow via cctalk" 
> To: "General Discussion: On-Topic and Off-Topic Posts" 
> Sent: Monday, November 19, 2018 6:29 PM
> Subject: Battery warning in Falco terminals
> ... 
>> Also, I suspect the first generation of terminals all have similar hardware 
>> with different
>> firmware, so if someone has any of the other models (TS-1, etc.) we could 
>> get them simulated
>> pretty easily once the firmware is dumped.
>> 
> -
> Don't forget the three PROMs ;-)
> 
> There were at least 2 models of the TS-1; the TS-1SP added paging & 
> scrollback among other features, and there was also the similar TS-100.
> 
> Their magnetic core & transformer keyboard technology always intrigued me; 
> very reliable & spillproof but I never saw it used anywhere else.



Were there 3 PROMs on the TS-1? I don't remember (and unfortunately didn't dump 
them, unless you're including the character generator amongst the 3).
They were probably soldered in and I was probably thinking mainly about 
eraseable chips and did the CG as well as it (would have been) socketed.
If they were small PROMs, they were perhaps I/O and memory address decoding.



Re: Battery warning in Falco terminals

2018-11-20 Thread Brent Hilpert via cctalk
On 2018-Nov-20, at 5:11 AM, Al Kossow via cctalk wrote:
> On 11/19/18 11:54 PM, Brent Hilpert wrote:
> 
>> I didn't have need / get as far as doing an I/O map or memory map for the 
>> Z80.
>> 
>> Should I send these files along?
>> 
> 
> Yes, please to dumps/docs and board/terminal pics from you and Mike!
> 
> I'm sure Richard would appreciate these as well for the terminals wiki.
> 
> They have a preliminary memory and I/O map in the MAME driver
> 
> Falco keyboards are pretty funky. They use transformer-coupled switches
> with a core that slides between coils on the top and bottom of the PCB
> 
> They appear to use a serial bitstream for the keypresses. EPROM dumps
> from the later keyboards with an 8035 would be very useful too, since
> CHM has a later model 52xx terminal with a 5 pin DIN, but I've been
> unable to find the keyboard.
> 
> I'm guessing the TS-1 series all used the same PCB with different keyboards
> and firmware.
> 
> The Fame series use 267x CRT controllers. The 52xx have a custom video ASIC
> I've not seen the insides of any of the Fame series.


(The TS-1 data files have been sent to Al.)

I did happen to RE the keyboard and analyse it's functioning some as it needed 
repair, so that's included in the schematic bits.

The PCB-transformer key design is novel, but (in the TS-1) so is the scanning & 
communication.
There is no microcontroller on the keyboard, scanning is performed by the main 
unit, it sends a key matrix address to the keyboard in serial, the keyboard 
sends back nothing but a binary key-pressed indication.



Re: Battery warning in Falco terminals

2018-11-19 Thread Brent Hilpert via cctalk
On 2018-Nov-19, at 3:29 PM, Al Kossow via cctalk wrote:

> I've been helping the MAME guys simulate a TS-2624, which is a block mode HP 
> emulating terminal.
> I had bought this a while ago, and never dumped the firmware. Unfortunately 
> there is a large
> NiCd battery right in the middle of the board that leaked all over. I've 
> taken some pictures
> which are up under falco on bitsavers.
> 
> If anyone has one of these, you want to do battery mitigation ASAP. I'm in 
> the middle of replacing
> every socket on the board since they were all within range of the leakage 
> corrosion.
> 
> Also, I suspect the first generation of terminals all have similar hardware 
> with different
> firmware, so if someone has any of the other models (TS-1, etc.) we could get 
> them simulated
> pretty easily once the firmware is dumped.


I had a Falco TS-1 dating from ca. 1981 in my possession a couple of years ago 
and dumped the ROMS.
It was based on a Z80 with 6845 CRT controller and 2651 UART.

I have data from two 2732s (Z80 firmware), as well as an EA8316 (2K*8) used for 
character generation.
That's in text format.

Also have a PDF with some notes on the hardware and reverse-engineered 
schematic segments.

I didn't have need / get as far as doing an I/O map or memory map for the Z80.

Should I send these files along?



Re: Another IC I Can't Identify

2018-11-12 Thread Brent Hilpert via cctalk
On 2018-Nov-11, at 2:04 PM, Rob Jarratt wrote:
>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent
>> Hilpert via cctalk
>> Sent: 11 November 2018 21:50
>> To: General Discussion: On-Topic and Off-Topic Posts
>> 
>> Subject: Re: Another IC I Can't Identify
>> 
>> On 2018-Nov-11, at 1:32 PM, Rob Jarratt wrote:
>>>> -Original Message-
>>>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of
>>>> Brent Hilpert via cctalk
>>>> 
>>>> On 2018-Nov-11, at 11:52 AM, Rob Jarratt via cctalk wrote:
>>>>> Thanks for all the replies. If that is indeed what it is, then I
>>>>> still
>>> have not
>>>> been able to find the source of one of the signals that seems to be
>>> causing
>>>> the Reset, every pin I have found so far is an input, I have not
>>>> found it connected to the output of anything yet :-(
>>>> 
>>>> 
>>>> Have you tried the reverse? : follow an origin that you know should
>>>> be controlling reset, such as the power-on indication from the PS,
>>>> and see if
>>> you
>>>> can trace it to the CPU.=
>>> 
>>> I have already found that source and it all looks OK. I think I have
>>> identified another input to a NOR gate that is high and causing the
>>> reset, but I can't find where it comes from.
>>> 
>> 
>> Perhaps I'm not clear on what you're saying, I was taking you as meaning
> you
>> hadn't found a source driving the reset line.
>> While you've found a PWR-OK signal and it looks good, have you found how
>> it connects to the reset line?
>> 
>> Reset-line arrangements on small machines aren't usually that complicated.
>> (Usually the power-on signal source is a series RC combination (often with
>> additional discretes such as diodes) between a power-bus and ground).
>> 
>> Perhaps put up an image of the schematic you have so far.
> 
> I have posted an image here:
> https://rjarratt.files.wordpress.com/2018/11/system-board.png
> 
> At the far right you will see a "To F11 Reset", my understanding is that
> this is active High. I have determined that the D input on E141 is always
> high. The CLR input on E141 is periodically set, thus causing a pulsing high
> output on E141, leading to a pulsing Reset on the F11 chipset.


Well that (the circuit, as much as is presented) is quite bizarre.
There's not a lot to make sense of from what's shown.
If it's really that complex then the question is why? What is all that 
complexity intended to do, for the sake of reset?
Without understanding the intention you're stuck tracing your presumed faulty 
signal back hoping (luck) that you encounter a fault along the way.
But it may be that the pulsing is not itself a fault, but an intended (perhaps 
looped-back) consequence of some more-distant condition (ala the watchdog 
timers others were mentioning earlier).

Aside from continuing as you have been and hoping that you luck out, I'd be 
looking at options such as:
- RE the whole thing and analyse it in entirety to figure out the 
intended reset operation.
- Find the docs on the CPU and see if they could provide some 
explanation as to the intention, based on the CPU reset functionality.
- Examine the schematics of other machines using the same CPU (as 
others have mentioned) to see if they have similar complexity around reset.
- Double/triple check to ensure you haven't gone astray in the tracing.

A note regarding E141, the 7474 (and following 74174) are edge-triggered, not 
transparent, and will require activity on the CLK input to produce a pulsing 
output (if PRE is fixed high), activity on the CLR input is not alone 
sufficient.



Re: Another IC I Can't Identify

2018-11-11 Thread Brent Hilpert via cctalk
On 2018-Nov-11, at 1:32 PM, Rob Jarratt wrote:
>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent
>> Hilpert via cctalk
>> 
>> On 2018-Nov-11, at 11:52 AM, Rob Jarratt via cctalk wrote:
>>> Thanks for all the replies. If that is indeed what it is, then I still
> have not
>> been able to find the source of one of the signals that seems to be
> causing
>> the Reset, every pin I have found so far is an input, I have not found it
>> connected to the output of anything yet :-(
>> 
>> 
>> Have you tried the reverse? : follow an origin that you know should be
>> controlling reset, such as the power-on indication from the PS, and see if
> you
>> can trace it to the CPU.=
> 
> I have already found that source and it all looks OK. I think I have
> identified another input to a NOR gate that is high and causing the reset,
> but I can't find where it comes from.
> 

Perhaps I'm not clear on what you're saying, I was taking you as meaning you 
hadn't found a source driving the reset line.
While you've found a PWR-OK signal and it looks good, have you found how it 
connects to the reset line?

Reset-line arrangements on small machines aren't usually that complicated.
(Usually the power-on signal source is a series RC combination (often with 
additional discretes such as diodes) between a power-bus and ground).

Perhaps put up an image of the schematic you have so far.


Re: Another IC I Can't Identify

2018-11-11 Thread Brent Hilpert via cctalk
On 2018-Nov-11, at 11:52 AM, Rob Jarratt via cctalk wrote:
> Thanks for all the replies. If that is indeed what it is, then I still have 
> not been able to find the source of one of the signals that seems to be 
> causing the Reset, every pin I have found so far is an input, I have not 
> found it connected to the output of anything yet :-(


Have you tried the reverse? : follow an origin that you know should be 
controlling reset, such as the power-on indication from the PS, and see if you 
can trace it to the CPU.

Re: A very sad PDP-8/S

2018-11-04 Thread Brent Hilpert via cctalk
On 2018-Nov-03, at 9:27 PM, Guy Dunphy via cctalk wrote:
. . .
> The front panel is in pieces atm. And clean now.
> Incidentally, several people called the material used for the lamps shroud 
> plate 'MDF.'
> It's not, it's that high density cloth+bakelite (or something) material used 
> for electrical switchboard panels. Very tough stuff.

Likely Micarta.

(I don't think MDF existed at the time).



Re: behaviour of classic PDP-8 frontpanel

2018-10-30 Thread Brent Hilpert via cctalk
On 2018-Oct-30, at 8:07 AM, Klemens Krause via cctalk wrote:
> Is there anybody out with a working classic PDP-8?
> 
> For a long time we had the problem, that starting a program on our 8 by 
> pressing   keys, this program crashed. Examining the memory 
> contents showed, that typically one or two words short behind the starting 
> adress after such a crash had inadvertently content .
> For a long time I suspected a subtle memory problem. But now after carfully 
> having revised the memory timing I hopefully found the real reason for this 
> nasty misbehaviour:
> if the machine is running and I press the  key, it stops and
> there is also the chance, that one word in memory is nullified.
> A look in the maintenance manual shows, that pressing  clears the 
> memory data register and others asynchronously. Naturally if this occours in 
> the moment, when a memory read is in progress, data from core has been 
> transfered to memory data register, which clears the word just have been red, 
> and before the memory timing chain was able to write this word back to 
> memory, then this word is cleared out.
> 
> Scoping the  signal coming from the front panel shows heavy bouncing 
> of this key: ing a program produces in many cases more than one 
>  pulse. The first starting the program, the following in some cases 
> nullifying a memory location near the start address. The problem showed only, 
> if the second start pulse came just in the moment
> between reading and rewriting the word in core. In the other cases
> program just went on.
> 
> My workaround for this problem in the moment is a 22uF electrolytic capacitor
> between the  signal line and ground to make a "brut force" debounce of 
> this switch.
. . .


If you haven't tried it already, a good exercising with contact cleaner (stay 
away from the stuff with oil in it) or isoprop will often clear up excessive 
contact bounce on old switches. Getting contact cleaner into the switch can 
sometimes be difficult though. With mini-toggle switches (if that's what they 
are behind the flat levers) the toggle can usually be pressed in a bit against 
the internal spring to open come clearance down the throat.

For a proper design fix, if the switch has both NO and NC contacts, a solution 
might be to build an SR flip-flop from two transistors and a few R and 
interposing that between the switch and logic as a de-bounce circuit.

Re: Does anyone recognise these boards please

2018-10-05 Thread Brent Hilpert via cctalk
On 2018-Oct-05, at 5:38 PM, Kevin Parker via cctalk wrote:
> Be most grateful if anyone can advise here please. Rescued a TRS-80 MC10 from 
> deceased estate recently - it was headed for the bin
> but got saved. 
> 
> The original owner was a bit of an electronics hobbyist and his 
> brother-in-law tossed these boards in with the bundle I grabbed.
> 
> http://koken.advancedimaging.com.au/index.php?/albums/boards/

Regarding the 2nd board:

Is there a likelihood this board could trace back to the Vancouver, B.C., 
Canada region? - there was an "Intek Electronics" near the south end of Main St 
in Vancouver in that era (70s-80s). I don't know if they had other outlets 
across the country.
It was a component supplier/retailer but like other such retailers it might 
have been a kit or in-house effort made and sold by them.



Re: SPACEWAR! Switch Boxes for a PDP-12

2018-09-23 Thread Brent Hilpert via cctalk
On 2018-Sep-23, at 7:46 AM, Michael Thompson via cctech wrote:

> Visitors to the RICM like to play SPACEWAR! in the PDP-12. Unfortunately
> using the console switches is uncomfortable, not intuitive, and is tough on
> the switches. We would like to recreate the switch boxes used on the PDP-1
> to make playing a better experience.
> 
> We modified the source
> 
> from D.E. WREGE
> 
> to use the LINC SXL instruction to read the PDP-12 GPIO signals, and
> prototyped two switch boxes using recycled toggle switches. This works
> great, so now we need to make better switch boxes.
> 
> This CHM article shows what we want to recreate.
> 
> This article shows a sketch of the switch boxes.
> 
> A generous donor made these boxes for us.
> 
> 
> The lever switches are turning our to be difficult to find at a reasonable
> price. We found some NOS SwitchCraft lever switches that looked like the
> sketch and the PDP-1 pictures and were a reasonable price, but our order
> was rejected because they only had one in stock. eBay has Mossman and
> SwitchCraft, but they are either very expensive (more than $50 each), or
> they only have one available.
> 
> The switches that we are looking for need to be SPDT, three-position,
> non-locking, center off. (If the switches have more than one pole we can
> remove the extra poles to keep the operational force low.) Before we cave
> in and buy some modern C toggle switches, does anyone have a source for
> Mossman or SwitchCraft switches at a reasonable price?



You haven't provided much detail about what limits you're willing to entertain 
in style of switch.

There are a wide variety of lever switches available.
There are leaf-contact switches that mount with two screws and a slot for the 
lever,
leaf-contact with a throated actuator that mount in a 1/2 inch hole (much 
easier to mount than making a narrow slot),
wafer switches with the two-screw/slot mount, etc.
Slot-styles may have the lever plane made from stamped/sheet metal with a slide 
on knob vs. made from thick ~3/16-1/8 inch metal with a thread-on knob.
The latter were very robust and the type typically found in telephone 
switchboards, although there were also some cheaper japanese makes.

Do you want period-correct even if not the exact manuf/type originally used, or 
when you mention C are you referring to modern mini-toggles as acceptable?



Re: SPACEWAR! Switch Boxes for a PDP-12

2018-09-23 Thread Brent Hilpert via cctalk
On 2018-Sep-23, at 7:46 AM, Michael Thompson via cctech wrote:
> Visitors to the RICM like to play SPACEWAR! in the PDP-12. Unfortunately
> using the console switches is uncomfortable, not intuitive, and is tough on
> the switches. We would like to recreate the switch boxes used on the PDP-1
> to make playing a better experience.
> 
> We modified the source
> 
> from D.E. WREGE
> 
> to use the LINC SXL instruction to read the PDP-12 GPIO signals, and
> prototyped two switch boxes using recycled toggle switches. This works
> great, so now we need to make better switch boxes.
> 
> This CHM article shows what we want to recreate.
> 
> This article shows a sketch of the switch boxes.
> 
> A generous donor made these boxes for us.
> 
> 
> The lever switches are turning our to be difficult to find at a reasonable
> price. We found some NOS SwitchCraft lever switches that looked like the
> sketch and the PDP-1 pictures and were a reasonable price, but our order
> was rejected because they only had one in stock. eBay has Mossman and
> SwitchCraft, but they are either very expensive (more than $50 each), or
> they only have one available.
> 
> The switches that we are looking for need to be SPDT, three-position,
> non-locking, center off. (If the switches have more than one pole we can
> remove the extra poles to keep the operational force low.) Before we cave
> in and buy some modern C toggle switches, does anyone have a source for
> Mossman or SwitchCraft switches at a reasonable price?


I have some options that might be suitable but you haven't provided much detail 
about what's ideal or limits you're willing to entertain in style of switch.
Are you trying to be period-correct?

 . . there are a wide variety of lever switches available.
There are leaf-contact switches that mount with two screws and a slot for the 
lever,
leaf-contact with a throated actuator that mount in a 1/2 inch hole (much 
easier to mount than making a narrow slot),
wafer switches with the two-screw/slot mount, etc.
Slot-styles may have the lever plane made from stamped/sheet metal with a slide 
on knob vs. made from thick ~3/16-1/8 inch metal with a thread-on knob.
The latter were very robust and the type typically found in telephone 
switchboards, although there were also some cheaper japanese makes.



Re: DEC H744 +5 supply

2018-09-23 Thread Brent Hilpert via cctalk
On 2018-Sep-22, at 11:54 AM, Noel Chiappa via cctalk wrote:
>> From: Brent Hilpert
> 
>> A glance at the schematic ... you might think it's just a linear
>> regulator
> 
> And the writeup in the maint manual gives that impression too, which didn't
> help! (Hence my assumtion that it was acting in the way a plain linear
> regulator might, in terms energy efficiency.)
> 
>> Diode D5 provides the current path for L1 to supply energy to the load
>> when the source is switched off.
> 
> Right. What is the role of the pair of big caps, C8/C9. Is that just to
> filter ripple, or do they play a role in the provision of current when the
> supply is switched off (by Q2)?
> 
> (My guess would be only the former, since unlike the energy stored in L1,
> which can be used provide electrons when Q2 is off, capacitors only store
> electrons, so they can't play much of a role in the conversion of V1I1 to
> V2I2, which requires 'creation' of more electrons when I2>I1. Oh, reading the
> maint manual, when Q2 is on, they store some of the current coming through
> L1. So I guess they have a peripheral role in the overall operation.)

Your conceptualisation around the role of electrons is perhaps a little off.
Displacement of electrons is the generation of potential (voltage), current is 
a RATE of electron flow.
You don't need 'more' electrons to generate a higher current, you just need to 
'expend them' more quickly -
using words like 'more' and 'expend' loosely, as it's not about moving a 
quantity of electrons from source to load, or creating or consuming them.
Energy transfer is not equivalent to electron flow, or, electron flow does not 
correspond to (or theoretically even imply) energy transfer.

Filtering ripple and supplying current are not mutually exclusive functions.
Capacitors very much play a role in supplying current to the load.
Both the L & C play a role as energy reservoirs.

You can charge two identical capacitors with identical charges (number of 
electrons displaced); discharging one of them into a load in 1mS will generate 
some peak current, discharging the other in 10mS will generate a much smaller 
peak current, with the same energy expended in both cases.


>> The subtle thing about designs like this is where does the switching
>> oscillation come from?, as there is no obvious oscillator present.
> 
> The maint manual does cover that. It more or less says that as the output
> voltage rises through 5.05V, the voltage regulator turns off Q2, and as
> it falls through 4.95, it turns it back on. (Presumably when the whole
> works is first turned on, the output voltage is less than 4.95V, so Q2
> stays on until it gets to the turn-off voltage.)

OK, my analysis of the operation may have been partly off then, I didn't think 
they'd be trying to look at just slight voltage variation of the regulated 
output to generate the switching/oscillation so thought it might be done via 
input current and Q7 providing a sharper switch.
Not  clear to me whether the whole is working as an on-off switcher relying on 
high enough gain in the 723/driver chain to make it a comparator or whether it 
is more like a phase-delay oscillator with the amp/semis operating in the 
linear region.


> Q7 is part of the over-current sensing, it says.
> 
> 
>> the switching is taking place after the transformer rather than
>> straight off the mains, this allows the switcher design to be simpler
>> and get away with using much lower voltage semiconductors.
> 
> Ah, I was wondering about why they did it that way.
> 
>> The transformer is nonetheless much smaller than it would be in a
>> straight linear regulator design because the secondary current it has
>> to supply is several factors lower than for a comparable linear reg.
> 
> That's because of the higher efficiency of this circuit, as opposed to a
> straight linear regulator, which would need more mains power in to produce an
> equivalent power out?

The higher efficiency means less power expended in toto, so that's a partial 
influence, but primarily it's because it's still a higher voltage by several 
multiples than the eventual target output voltage and thus the current that the 
transformer secondary has to deal with is the same factor lower to deliver the 
same output power, meaning less copper for the secondary and less iron for the 
core.
The EI conversion in this supply is taking place in two stages, firstly in the 
transformer step-down from mains to 20-30VAC, then further in the subsequent 
switcher(s).


>> Q5 is functioning as a common-base stage in the driver chain ...
>> It is not part of the +15V supply to the 723, that is provided by
>> R2, zener D2, C2.
> 
> I was confused by the maint manual, which says "D2 is used with Q5 and R2
> to provide +15V to E1".

I don't know why they would phrase it that way but I haven't seen/read this 
TofOp.
E1.12 is the 723 supply pin (being supplied with +15V from D2), E1.11 is the 
control signal out.


>> There are a thousand 

Re: DEC H744 +5 supply

2018-09-21 Thread Brent Hilpert via cctalk


On 2018-Sep-21, at 4:03 PM, Noel Chiappa via cctalk wrote:

>> From: Brent Hilpert
> 
>> In typical "down-converters" there are additional current paths in the
>> supply, paralleling the input path, that can provide the 'additional'
>> electron flow rate. ... the whole rationale of a switching supply is to
>> use time (varying switching periods) and temporary energy storage to
>> change that EI relationship from input to output without energy loss.
> 
> So, two more questions (if you have the time):
> 
> I can see that there's a nice synergy between the switching concept and the
> buck converter (since the switch does exactly what the buck converter needs,
> in terms of turning the input current off and on), _but_ - are there switching
> supplies that operate the way I described (up-convert the frequency, then use
> a transformer to get directly to more or less the right voltage)? I.e. without
> needing to use a buck converter to do the conversion from low current at
> higher voltage to higher current at lower voltage? (Although I guess the coil
> for the buck might be cheaper than the transformer - even though the use of a
> high frequency would reduce the size of the latter - making the buck approach
> superior.)
> 
> To put it another way, there's no _necessary_ connection between the switching
> concept, and the buck converter is there? Does that mean it is in theory
> possible to stick a buck converter on the output of a linear supply to do the
> V1I1-> V2I2 conversion? (Although I know it's probably a stupid design, 
> because
> you'd still need some sort of switcher for the buck converter, so the linear
> supply would be basically pointless.)

There are a thousand configurations for power supplies possible depending on 
what needs to be accomplished: circuit isolation (e.g. mains from load), EI 
conversion up or down, degree of regulation, economy tradeoffs, etc.

An example that perhaps fits what you're thinking of is the old motor-generator 
setups which convert 60Hz to 400Hz, the 400Hz then being used as input to a 
variety of supplies.

It's useful to keep in mind that regulation and EI conversion are different 
objectives but they can be achieved either separately or in concert.
What we commonly refer to as a "linear power supply" does EI conversion (and 
circuit isolation) in one stage (the transformer), followed by an independent 
regulator stage.
Your common modern generic switching supply integrates EI conversion, 
regulation and circuit isolation into one feedback loop across one transformer 
(switching at high frequency).

A buck converter is inherently a switching converter, the buck operation 
requires the switching to function.
There is a corresponding boost converter with a different circuit topology 
around the inductor, for . .  boosting voltage.
There are also boost-buck converters.

Dropping 5V to 3.3V or 1.xV for ICs is often accomplished with little on-board 
buck converters which you may not have realised were there, to avoid the losses 
and heat of a linear regulator.
 

> 
>> If the heatsinks seem huge compared to modern day supplies, that's more
>> likely the result of technology improvements - faster devices, and
>> moving from bipolar switching transistors to mosfets. Bipolar
>> transistors have a near-fixed voltage drop which can't be reduced
> 
> Right, I knew bipolars had the fixed drop, but I hadn't made the connection
> to that being the cause of the large amount of heat needing to be dumped.
> Useful enlightenment!
> 
> 
>> If you supply a link & location to a schematic I'll take a look
> 
> Here:
> 
>  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/H744.tif
>  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/H744.jpg
> 
> Thanks to everyone for taking the time and energy to reply!
> 
>   Noel




Re: DEC H744 +5 supply

2018-09-21 Thread Brent Hilpert via cctalk
On 2018-Sep-21, at 4:03 PM, Noel Chiappa via cctalk wrote:
>> From: Brent Hilpert
> 
>> If the heatsinks seem huge compared to modern day supplies, that's more
>> likely the result of technology improvements - faster devices, and
>> moving from bipolar switching transistors to mosfets. Bipolar
>> transistors have a near-fixed voltage drop which can't be reduced
> 
> Right, I knew bipolars had the fixed drop, but I hadn't made the connection
> to that being the cause of the large amount of heat needing to be dumped.
> Useful enlightenment!

To clarify, bipolars have a fixed MINIMUM drop, which can be used in a 
switching supply to as much advantage as possible with bipolars, but have a 
varying drop in a linear regulator (that's where the 'linear' comes from) which 
results in the large losses and inefficiency of linear regs.

Re: DEC H744 +5 supply

2018-09-21 Thread Brent Hilpert via cctalk


On 2018-Sep-21, at 3:20 PM, Noel Chiappa via cctalk wrote:

>> From: Mattis Lind
> 
>> The H744 is a buck converter. You can read about buck converters here:
>> https://en.wikipedia.org/wiki/Buck_converter
> 
> Wow, that was incredibly hard to read; no clear and simple explanation of the
> basic concept of how it works, before getting into the details!
> 
> If I understand it correctly, it stores part of the incoming energy of a block
> of current in the field around the inductor; later, switches change state to
> create a loop that includes the inductor, and it uses the stored energy to
> cause electrons to flow around the new (temporary, because of the switch)
> circuit. Is that about right?

Yes, that's a basic part of the operation.


> The H744 manual doesn't really talk much about that aspect of the circuit's
> operation (at least in terms of 'we use this trick to get all the energy out
> of the incoming current flow'); it just describes the stuff around the coil as
> "an LC filter". It says "This type circuit is basically only an averaging
> device", which I wouldn't say is really on point - that would describe my
> (incorrect) prior description as well as the correct one.
> 
> And just to make it even more confusing, it says "most of the input voltage is
> absorbed across the emitter-collector of Q5", but I looked, and Q5 is tiny,
> and I eventually figured out that that only applies to the +15V needed to run
> the voltage regulator.


Q5 is functioning as a common-base stage in the driver chain (base tied to 
fixed +15V).

It is not part of the +15V supply to the 723, that is provided by R2, zener D2, 
C2.

Q5 'voltage isolates' the 723 from the higher voltages around Q4-3-2 while 
nonetheless providing a control signal path from the 723 to the drivers.



Re: DEC H744 +5 supply

2018-09-21 Thread Brent Hilpert via cctalk
On 2018-Sep-21, at 1:03 PM, Noel Chiappa via cctalk wrote:
> Oh, one thing I forgot to include:
> 
>> a lot of the incoming power in that 30V AC has to be thrown away, in
>> producing +5V.
> 
> So, if my understanding is correct, the 'switching' H744 really isn't much
> better than a classic linear supply. It still wastes a very large amount of
> the input power, and it still has a massively heavy transformer in it. Yes?

No, it's much better than a linear supply.
With the given 20-30VAC input (do I have that right?) - lets take a 
conservative 25VDC after rectification and filter - if input to a linear 
regulator producing 25A @ 5V,
that's a loss of (25-5)V * 25A = 500W, to produce a usable 125W.
That heatsink isn't sinking 500W and DEC wouldn't be producing a supply that 
inefficient.

A glance at the schematic (as Eric provided the ref to) you might think it's 
just a linear regulator: AC input, rectification, cap filters, pass 
transistors, filter choke, with a 723 IC regulator controlling it, all the 
standard elements are there.

But it's not: L1 is the bucking inductor - it's not just a filter choke.
Diode D5 provides the current path for L1 to supply energy to the load when the 
source is switched off.

The subtle thing about designs like this is where does the switching 
oscillation come from?, as there is no obvious oscillator present.
I think what's going on is:
- Q1/R4 are sensing current from the source via voltage drop across R4.
- As that current goes up Q1 starts to conduct, eventually tripping SCR 
Q7 hard on.
- This raises the voltage at E1.4, the error amp sense input.
- This fools the regulator into thinking it's seeing way too high an 
output voltage so it hard shuts down the Q5-4-3-2 chain,
   disconnecting the source from L1 and the output, and shutting off 
the source current.
   E1.4 is now back to sensing the output voltage via the V-SENSE 
feedback.
- With source current off, L1 now starts supplying energy to the load 
through D5, as it's magnetic field starts to collapse rather than build.
   As that energy peters out and the output voltage droops, E1.4 via 
the V-SENSE line now sees too low an output voltage and turns
   Q5-4-3-2 back on so the source can supply current, and energy into 
L1 and the load.
- repeat. Hence oscillation.

There is still a sizeable 60Hz transformer (step down to 20-30VAC) because the 
switching is taking place after the transformer rather than straight off the 
mains, this allows the switcher design to be simpler and get away with using 
much lower voltage semiconductors.
The transformer is nonetheless much smaller than it would be in a straight 
linear regulator design because the secondary current it has to supply is 
several factors lower than for a comparable linear reg.


> So I wonder what exactly the advantage was in going to the switching approach?

Improved power efficiency.
Improved material economics.


> Yes, it keeps the output voltage steadier then a pure linear supply could -
> but I'll bet there are analog approaches that can do the same. (They'd need
> something that can produce a steady reference voltage, but the switching
> approach needs, and has, the same thing.)

In addition to reference stability, the basic error factor in a regulator is 
the loop gain of the error amplifier, and applies to both linear and switching 
regs.
Neither produces a perfect output, it just reduces the the variation by some 
factor (the gain factor).
If you think about it, if the output were perfectly stable how would the 
regulator know to provide correction?


> Maybe the main output transistors
> are happier being full-on or full-off, or something like that?

Yes, that is one of the benefits of switching regulator over a linear 
regulator. It keeps the in-regulator losses to a minimum.



Re: DEC H744 +5 supply

2018-09-21 Thread Brent Hilpert via cctalk


On 2018-Sep-21, at 12:38 PM, Noel Chiappa via cctalk wrote:

> So there's something about the H744 I'm not sure I understand; hopefully those
> with more analog-fu will set me straight if I'm confused.
> 
> This supply runs off 20-30V AC. It takes the input AC, rectifies it, and runs
> it through a cap to filter out the ripple. What's next is that it's an early
> switching supply; i.e. the electronics inside switches that newly-created main
> DC off and on very quickly to keep the output voltage at around +5V.
> 
> However...
> 
> My understanding is that, without using a transformer (which creates an
> independent circuit loop - more below), there's no way to increase the
> _amperage_ out of circuit over what's fed into it: since amps are
> electrons/second, the electrons/second out more or less have to equal
> electrons/second in, since one can't easily 'create' electrons - at least, in
> normal electonic gear! (Transformers, by creating a whole new circuit loop,
> can 'create' more electrons/second in the new loop; since they tie the 'out'
> of the new circuit back to its 'in', they can recirculate the 'extra'
> electrons.)
> 
> And to the extent that the output is at lower voltage, the energy differential
> has to be dumped; hence the huge heat sinks - a lot of the incoming power in
> that 30V AC has to be thrown away, in producing +5V. Right?
> 
> My (possibly confused) understanding is that later switching supplies take the
> incoming 60Hz wall AC, transform it to a higher frequency, run _that_ through
> a transformer (which can be a lot smaller, since it's at a higher frequency,
> and the higher the frequency, the smaller the transformer you can use - hence
> the use of high frequency AC in airplanes, to allow use of smaller - and thus
> lighter - transformers). That then turns out a massive amount of amps in the
> output loop (since with a transformer, energy out is roughly energy in, modulo
> resistive losses; and with constant power, if V goes down, I goes up).
> 
> So the losses are a lot lower - N amps at 110V in produce ~20N amps out at
> +5V. (Well, depending on all the losses, ~20.) And the whole works is a lot
> lighter, to boot.
> 
> Did this programmer get all that analog stuff correctly?


No. You don't need a transformer to increase the current  ('electrons/S') in 
the output above that of the input.

In typical "down-converters" there are additional current paths in the supply, 
paralleling the input path, that can provide the 'additional' electron flow 
rate.
There are the parallel filter capacitors, and in the typical 'bucking 
converter'  - which, while I'm not familiar with the H744 design*, I suspect it 
probably is - there will be what looks like a reverse-biased diode across the 
(switched) input which allows 'arbitrary' current levels to flow out of a 
series inductor which previously stored energy from the source, and deliver 
that current through the load.

The energy differential from the voltage reduction is not being dumped as a 
power loss, it was converted by the supply to a different EI relationship 
between the input and output.

The forgotten factor in your analysis is time: the whole rationale of a 
switching supply is to use time (varying switching periods) and temporary 
energy storage to change that EI relationship from input to output without 
energy loss.

If the heatsinks seem huge compared to modern day supplies, that's more likely 
the result of technology improvements - faster devices, and moving from bipolar 
switching transistors to mosfets. Bipolar transistors have a near-fixed voltage 
drop which can't be reduced and thus present an increasing power loss as 
current goes up, while mosfets can be designed for lower 'insertion' losses.

* If you supply a link & location to a schematic I'll take a look, I don't feel 
like wading around in bitsavers pdfs to try to find it right now.

Re: Some late fifties HP measurement equipment available. ( Switzerland )

2018-09-03 Thread Brent Hilpert via cctalk
On 2018-Sep-03, at 8:39 AM, jos via cctalk wrote:
> the following late fifties HP equipment is available in Switzerland.
> Stored in less than ideal conditions, but seem otherwise quite OK.
> 
> Feel free to forward to more fitting mailing list / fora.
> 
> Not my equipment, my only interest in this is saving these from the scrapheap.
> 
> 
> HEWLETT PACKARD TIME INTERVAL UNIT 526B
> HEWLETT PACKARD ELECTRONIC COUNTER 524C
> HEWLETT PACKARD DIGITAL RECORDER 560A
> 
> ( Possibly a second HP524(b) , unsure of this )
> 
> I will forward email adresses tio the seller, up to you to complete.
> He expects to raise some money, unsure if realistic or not.



I think I've made this comment before when this type of equipment has been 
mentioned on the list,
but as it's being mentioned again:

The 524C is a tube-based NIXIE-display digital frequency/period/event counter,
the 526B is a plug-in input module for the 524,
and IIRC the 560 is a printing recorder for use with the 524.

http://madrona.ca/e/edte/HP524C/index.html
http://madrona.ca/e/edte/HP520/index.html

In my opinion, it's a reasonable acquisition for a computer museum as an 
example of
tube-based digital technology from which the 1st generation of computers were 
built
(seeing as how tube-based computers are a tad difficult to come by these days).

If you're an HP collector, the 520 series was HP's first step into digital 
technology.



Re: HP-2116 front panel lamps

2018-07-25 Thread Brent Hilpert via cctalk
On 2018-Jul-25, at 6:47 AM, Christian Corti via cctalk wrote:
> On Wed, 25 Jul 2018, it was written
>> Christian, when I was restoring the HP Computer Museum's 2116A I ordered a
>> bunch of these 345 bulbs from 1000bulbs.com - but it seems they no longer
>> stock them.
>> 
>> I did find this listing though which looks current...
>> https://www.lighting-pros.com/eiko-345-t-1-3-4-midget-flanged-sx6s-case-of-1
>> 0
>> 
>> They are around 0.04A current draw - not 0.75A!
> 
> Yes, the Installation and Maintenance Manual on bitsavers 
> (02116-9153_2116B_Vol2_Oct70.pdf) contains several errors.
> Interesting enough, my printed copy of this manual from 1968 (that is 
> completely different from the 1970 one; it only has parts lists and 
> schematics, the chapters for installation and maintenance are simply not 
> there) is right: 2140-0035  6.3V 0.04A
> 
> In the meantime I've ordered a bunch of JKL 345 from Mouser (60 Ecent/piece)


To mention, they are actually run below-spec in the processor, which of course 
improves longevity and reduces the heat next to the plastic front panel.

From actual measurements in my 2116C the lamps (CM345) draw:
register-bit positions:   ~  31ma @ 4.1V
inside the push-buttons:  ~  36mA @ 5.4V

compared to the spec: 40mA @ 6V

( I obtained CM345s from Mouser in 2013.  "95 in stock", that would have left 
83 after my purchase).


Re: MOS MCS2529 math chip

2018-07-20 Thread Brent Hilpert via cctalk
On 2018-Jul-20, at 10:18 AM, Jules Richardson via cctalk wrote:
> Anyone got pinout/spec information for a MOS MCS2529? In particular, I'm 
> curious about operating voltage. I acquired a Melcor SC-635 calculator 
> yesterday and there seems to be some uncertainty about the output voltage of 
> its (rechargeable) battery pack; some places say 2.4V, i.e. the pack is a 
> pair of 1.2V cells, but others say 9V.
> 
> 2.4V seems a little low to me for typical logic, but on the other hand I've 
> seen a period ad which says that the external PSU was 9V - and so the 
> rechargeable battery must have been somewhat less than that.


Rechargeable and 1.2V/cell would correlate to 2 NiCd cells, a not-unusual 
configuration for calculators of that period.

Such units would typically use a simple built-in switching power supply to 
boost the battery voltage up to levels adequate for the logic and/or display.
In the pic of the PCB board here:
http://www.teclas.org/maquina.php?mm=C125
the chunky box component 'below' the IC is probably a switching PS module.

It was also common to use simple resistive current limiting in the charge 
circuit for NiCds.
In consequence, the voltage supplied by the external AC charger may be quite a 
bit higher than the battery voltage.
It's possible that's where the 9V external spec comes from, if not just a 
mistake.
Sometimes the current limiting R is in the external charger, sometimes it's in 
the calculator.

Further, such designs also tended to rely on the battery to provide AC 
filtering & voltage regulation (limiting) of the charger V down to the battery 
V.
If the battery/cells have been removed or are in really bad condition, 
operating the calc from the original external charger
can result in too high a voltage being applied to the electronics.

My usual procedure for such calcs is to cut out the NiCd cells (there is ~0 
probability they are any good), noting the polarity.
For testing, clip on a bench supply to substitute for the batteries, set of 
course to the appropriate V for the battery ( # of cells * V/cell ).

If the batteries have already been removed and there are no polarity markings, 
let me know if you'd like some assistance trying to figure it out.

If you want to power it through the charger jack, then you need to assess 
whether there is any internal charging circuitry (rectification, aforementioned 
current-limiting R, etc.) sitting between the jack and the cells.



Re: BASIC (Was: Reading HP2000 tapes

2018-07-17 Thread Brent Hilpert via cctalk
The HP9830 (1972) with it's ROM'ed BASIC works this way.
LIST produces a 'cleaned up' version of the source code.



On 2018-Jul-17, at 1:21 PM, Guy Sotomayor Jr via cctalk wrote:

> I should also mention that for the IBM S/23, once the BASIC program is 
> entered, the original
> source is discarded and only the tokenized code remains (comments are 
> retained as-is).   The
> LIST command runs a de-tokenizer and reconstructs the original source (well 
> close to it anyway).
> 
> TTFN - Guy
> 
>> On Jul 17, 2018, at 12:33 PM, John Foust via cctalk  
>> wrote:
>> 
>> At 03:53 PM 7/14/2018, Fred Cisin via cctalk wrote:
>>> On Sat, 14 Jul 2018, Ed Sharpe via cctalk wrote:
 isn't the  basic  programs  also stored in tokinized  forms!?!?
>>> 
>>> Yes.
>>> And the tokens are not the same between different brand implementations, or 
>>> even between different versions, such as MBASIC 4 and MBASIC 5.
>>> http://fileformats.archiveteam.org/wiki/Tokenized_BASIC
>> 
>> I remember a detokenizer for RSTS BASIC-PLUS that's not on that list.
>> 
>> I think it was called a "decompiler" though.  Seemed like magic at the time.
>> 
>> Googling reveals "You may be remembering the BASIC PLUS
>> decompiler under RSTS.  RSTS BASIC PLUS was interpreted from "push-pop" code.
>> The symbol table was available in the compiled file, and the correspondence
>> between push-pop operations and BASIC PLUS source was very close, so you
>> could get back very reasonable code."
>> 
>> And our previous discussion of it a decade ago:
>> 
>> https://marc.info/?l=classiccmp=121804804023540=2
>> 
>> - John
>> 
> 



Re: Looking for Tektronix 4051 or 4052 Display Board

2018-07-03 Thread Brent Hilpert via cctalk
On 2018-Jul-03, at 5:59 PM, Jon Elson via cctalk wrote:
> On 07/03/2018 03:35 PM, Ian Finder via cctalk wrote:
>> On Tue, Jul 3, 2018 at 1:21 PM, Monty McGraw via cctalk <
>> cctalk@classiccmp.org> wrote:
>> 
>>> I've been repairing my Tektronix 4052.
>>> 
>>> I've got the digital logic working - but the text and graphics are messed
>>> up.
>>> 
>>> I posted photos of the screens in my Tektronix 4052 troubleshooting thread
>>> on vcfed.
>>> 
>>> With a scope on the final X amplifier stage - it is oscillating - so I see
>>> weird horizontal strokes instead of dots for text.  I know from the service
>>> manual that this circuit includes a feedback loop, and with the scope I see
>>> oscillation all around the loop - so I haven't found the source.
>>> 
>>> 
> If it is basically working, but just has oscillation, then it is almost 
> certainly a capacitor issue.
> There are likely capacitors in the feedback loop to reduce bandwidth, and 
> decoupling capacitors
> on the power rails.  It would be fairly easy to track down the specific 
> capacitors from the manual and check them.


I had the same initial thought, but Monty's msgs & scope trace show a solid 
ramp waveform down around 37Hz, not the higher F ringing or transient sort of 
sine oscillation
one would expect from failed small-C bypass/suppression/etc. caps. It's more 
like a relaxation-oscillator type of activity. He's already replaced a couple 
of the larger-C caps in the circuit.



Re: Looking for Tektronix 4051 or 4052 Display Board

2018-07-03 Thread Brent Hilpert via cctalk
On 2018-Jul-03, at 5:06 PM, Brent Hilpert via cctalk wrote:
> However, compare to:
>   https://drive.google.com/file/d/1TJjeZqszca1C7XILsnDyO9D_r64ZMwoo/view
> the 2 & 3 pin labels on U184A should be swapped.

Whoops, correction to my correction, they got the pins right, but the +/- input 
labelling should be swapped there.



Re: Looking for Tektronix 4051 or 4052 Display Board

2018-07-03 Thread Brent Hilpert via cctalk
On 2018-Jul-03, at 1:21 PM, Monty McGraw via cctalk wrote:
> I've been repairing my Tektronix 4052.
> 
> I've got the digital logic working - but the text and graphics are messed
> up.
> 
> I posted photos of the screens in my Tektronix 4052 troubleshooting thread
> on vcfed.
> 
> With a scope on the final X amplifier stage - it is oscillating - so I see
> weird horizontal strokes instead of dots for text.  I know from the service
> manual that this circuit includes a feedback loop, and with the scope I see
> oscillation all around the loop - so I haven't found the source.
> 
> Does anyone have a spare Tektronix 4052 (or 4051) Display Board that I
> could buy?


I take it you are referring to discussion and info from your post on may 27th 
at:

http://www.vcfed.org/forum/showthread.php?63656-Tektronix-4052-Troubleshooting/page2=4051

Re a comment in that discussion:

The feedback loop in the op-amp circuitry is the negative-feedback gain-control 
loop.
If you open that loop the gain will shoot off to -->infinity (in the real 
world, the highest the amplifier can do, the output would go binary 
rail-to-rail).

If you noticing and wondering why the "negative" feedback loops around to the + 
input on the op-amp,
it's because the output drivers provide a stage of inversion (specifically 
Q84/95).

Note there are some mistakes in those Tek schematics around U184A/B. They are 
mixing up the pin numbering and +/- input labelling.
There seems to be half-a-dozen variations on the deflection circuitry (was 
looking also at the 4051 service manual from bitsavers)
and the error seems to morph around between the versions, like someone tried to 
fix it at one point but misunderstood and reintroduced
at another.

On this version you reffed:
https://drive.google.com/file/d/1FQxqfVyOeA1BJjUS7b7X-FzL7Wb8g7q5/view
they get it right.

However, compare to:
https://drive.google.com/file/d/1TJjeZqszca1C7XILsnDyO9D_r64ZMwoo/view
the 2 & 3 pin labels on U184A should be swapped.

On another version on page 96 of the manual they have the +/- flipped on U184B.

Suggestion re the problem:

As you are seeing the oscillation at C196 on the common X/Y bias supply, I 
would try looking at Q186, in particular for a B-C short or leakage.
A B-C short/leakage there would be adding C196 to the X output and could be 
providing the time constant for the ramp/oscillation.
You could try scoping the B & C of Q186, if the signal and voltage levels there 
are similar, consider removing Q186 to resistance check it OOC.



Re: Thicknet/10base5 Test Segment: The Cable is In!

2018-06-29 Thread Brent Hilpert via cctalk
On 2018-Jun-29, at 1:27 AM, Peter Coghlan via cctalk wrote:
> 
> A telephony connection is the most plausable theory I have come across yet.
> I can remember devices that looked like large junction boxes with a ground
> connection that were installed where an overhead telephone line entered a
> building.  They contained a fuse in series with each line conductor and
> a surge arrestor consisting of a spark gap and/or a VDR from each conductor
> to ground.  I think the theory was that they might provide some protection
> against brief high voltage spikes induced onto the line by thunderstorm
> activity.  I think they might have been more trouble than they were worth.

Over here at least, they are still a standard part of any telephone landline.

Many decades or a century ago they were a big white 4*5 inch ceramic block 
mounted in the basement, with two long red (fusible?) resistors in series with 
each pair-wire and a double carbon-block spark gap to ground underneath a black 
bakelite knob.

Now they're built into the house-side connection box and you might not even 
know there is something besides the connection terminals there.

How often they actually come into active play I have no idea, but they still 
strike me as a good idea when you have miles of overhead line back to the CO.



> If the shield is being used to reduce noise on the line, surely it should be
> connected to pin 7 at both ends?

Surely you'll often get away with such, but "surely it should be connected to 
pin 7 . ."? No.

I don't know whether the -232 spec actually refers to pin 1 as "protective" 
ground, but regardless, "protective" here doesn't have to mean the same thing 
as "protective" in the mains wiring arena (or provide the identical functions).

Protective ground in the mains arena serves both to flatten voltages and bleed 
off slight currents from leakage and L/C coupling, and to carry enough current 
to blow the mains breaker in the event of shorts to chassis.

The "protective" ground on a -232 connection could be performing at least two 
functions: the afore-mentioned neutralisation of leakage, and noise suppression.
It is not at all insensible to separate those functions into a separate wire 
from the wire providing signal-circuit continuity (signal common / signal 
ground).
You don't want currents or voltages from leakage or noise upsetting the 
signal-circuit common level.
I don't think anyone was intending the -232 protective ground to provide the 
'blow the mains breaker' function.

Yes, sometimes the noise/leakage/signal-common functions are all combined into 
one wire, or stated alternatively, sometimes the environment and needs allow 
one to combine them into one wire.
Consumer audio for instance - where the shield is commonly both the signal 
common and noise/hum shield.
But even in that low-requirements arena you might remember turntables - where 
there were two channel-cable common/ground shields but there was also a 
separate chassis ground wire.

Equipment, esp. back in the 60's, might not have a mains ground. Even in 
equipment that does, signal common/ground and chassis ground may be separated.
Relying on the signal ground wire to provide all these functions when 
connecting equipment with varying grounding policies is asking for problems. 

-

Speaking of abusing RS-232, in our CS dept (UBC) in the 80s when we moved our 
project offices to another room some ways away from the machine room we were 
faced with getting terminal cabling between them.
'Properly' this would involve calling in the physical plant dept or the telco 
to run new wire or make twisted-pair connections on the telephone wiring.
However, a little OCD observation of wall panels over my time there, some 
speculation, and some continuity testing allowed me to figure out there were 
some
little-to-unused 100-pair cables terminating in punch-blocks in panels in 
various rooms, so with a little punching between blocks within a panel I was 
able to get
continuity between the machine room and our new room.
No new wire-runs and no bureaucracy involved.

We used -232 over those connections. Something makes me think I reserved 3 pair 
per line but used 2 (4 wires): XMT, RCV, DTR to let the terminal switch know a 
terminal was present, and signal-GND. 

The university timesharing Computing Center, to provide terminals across the 
large campus, used 422-style balanced-line signaling.
Every CC-connected terminal around campus had a little 3*4*6 box sitting with 
it, with 3 LEDS (power, XMT, RCV), and containing dual power supplies (232 
terminal side & 422 'campus' side), two opto-isolators (XMT & RCV) and assorted 
drivers. Each connection was 2-pair (XMT,RCV) over the telephone wiring 
physical plant.
There were various manufacturers (Gandalf and Develcon come to mind) that made 
such devices, but in UBC's case the computing centre made their own.
I saved what is probably the last existent one when I ran across it in a 
radio-musuem donation pile 

Re: Looking for info on Motorola 4015 chip

2018-05-12 Thread Brent Hilpert via cctalk
On 2018-May-12, at 11:03 AM, Noel Chiappa via cctalk wrote:
> Hey, all, the RK11-D contoller for the PDP-11 uses Motorola 4015 MSI chips on
> one of the boards (M7254), but I can't find out anything about them. Google
> didn't turn anything up, and the appendix in the RK11-D Maintenance Manual
> that has info about 'all' the MSI chips used in the RK11-D doesn't have this
> one. It appears to be a quad flop - anyone have more info? Thanks!


If it comes to replacement, the 74LS279 (quad nSnR latch) looks like a good 
candidate to consider in the application.



Re: Old core memory system.

2018-05-05 Thread Brent Hilpert via cctalk
On 2018-May-05, at 2:57 AM, Mattis Lind via cctalk wrote:

> Can anyone tell what kind of computer this might have been connected to?
> 
> https://i.imgur.com/IC3AVCf.jpg
> 
> I googled MS8192X26-1.9-RT and found one hit:
> 
> http://www.nsn-now.com/Indexing/ViewDetail.aspx?QString=7025013480747
> 
> And then FABRI-TECH (maybe miss-spelled) gave a nice broschure:
> 
> https://archive.org/details/TNM_Fabri-Tek_Inc_-_Brochure_20170629_0325
> 
> The core memory system boxes indeed look similar.
> 
> But still no clue what kind of system this has been connected to.
> 
> What kind of system made use of 26 bits? Maybe 24 bits + check bits?
> 
> It could be flight control related since it is aviation museum that
> currently have it. But the person I have contact with don't know the actual
> source. Possibly flight simulation since the same guys do have several old
> flight simulators.

Can't help with the target system, but I'd guess the "1.9" is likely the cycle 
time in uS.
26 bits might be 24 with parity and a spare.



Re: Looking for opinions...

2018-03-29 Thread Brent Hilpert via cctalk
On 2018-Mar-28, at 6:52 PM, Fred Cisin via cctalk wrote:
  [...]
> If only that were 16mm or 35mm continuous rolls, instead of microfiche!
> 
> In 1931, Emanuel Goldberg, then a chief engineer at Zeiss built the 
> "Statistical Machine". By recording bits optically in the margins of 
> microfilm, and reading them with photocells, it could find appropriate frames!
> 
> For use in soundtrack for films, Mauer puts up to 8 parallel variable area 
> optical tracks in the margin!
> 8 bit parallel!
> Goldberg was also apparently responsible for the Contax camera.
> BUT, in the days leading up to World War Two, he fled Dresden and Zeiss could 
> not afford to have mention of a Jew in a high profile position, and by the 
> time the war ended, they had systematically erased most clues that he had 
> existed!
> 
> http://people.ischool.berkeley.edu/~buckland/goldberg.html
> 
> A decade later, Vannevar Bush stole the idea, and without credit, claimed it 
> as his own, as the foundation for his Memex device.


An article ( http://people.ischool.berkeley.edu/~buckland/goldbush.html ) on 
your referenced site assesses the state of the art in between Goldberg and Bush 
(1931-1938).
Near the end the writer states:

" Three considerations suggest that he [Bush] was unaware of the detail
of Goldberg's work when he [Bush] built his prototype in 1938-40: [. . 
.] "

and makes no conclusion of conscious influence (on Bush by Goldberg).

So when you say Bush "stole", and "claimed it as his own", etc., do you have 
some other reference or is this merely your pejorative accusation and hyperbole?


> Bush did not successfully build his machine.

(Not the Memex you mention, but, as discussed in the article, he did build the 
predecessor 'microfilm rapid selector'.)


> Bush's Atlantic Monthly article, "As We May Think" is sometimes considered 
> the foundation of modern information science.
> Bush did not understand nor accept the concepts of index nor hierarchical 
> organization, so he pushed for linkage to go from one topic into another.
> Ted Nelson credits it as the inspiration for Hypertext, and Cern credits Ted 
> nelson.



Re: Bendix G-15 [was: Re: VCF PNW 2018: Pictures!]

2018-02-18 Thread Brent Hilpert via cctalk
On 2018-Feb-18, at 11:57 AM, Al Kossow via cctalk wrote:
> On 2/18/18 11:53 AM, Brent Hilpert via cctalk wrote:
> 
>> Paul Pierce has a G-15:
>>  http://www.piercefuller.com/collect/bendix/index.html
>> 
>> Or he did, ca 2001.
> 
> Paul donated it to CHM
> 
> http://www.computerhistory.org/collections/catalog/102728118

Oh, OK.
I take it Paul downsized a fair bit. I think you (or someone) mentioned 
previously his 709 went to the CHM.
Anything else of the big stuff?




Re: Bendix G-15 [was: Re: VCF PNW 2018: Pictures!]

2018-02-18 Thread Brent Hilpert via cctalk
On 2018-Feb-18, at 11:30 AM, Mark Linimon via cctalk wrote:
> On Sun, Feb 18, 2018 at 01:04:38PM -0600, Jon Elson via cctalk wrote:
>> Wow, even a Bendix G-15 in there (although with Control Data logo).
> 
> Nope, look again, there are two :-)
> 
>> Talk about a restoration project!!!
> 
> AFAIK these are the only ones being restored.
> 
> The last time I checked, the remaining inventory was:
> 
> - Smithsonian (S/N 1)
> - CHM (on static display)
> - these 2
> - the one at MARCH
> - a University in Australia who was attempting to restore theirs
> 
> My G-15 website is pretty stale but here it is:
> 
>  http://www.obscurecomputers.org/g15/index.html
> 
> The site is in dire need of attention; helpers wanted :-)


Paul Pierce has a G-15:
http://www.piercefuller.com/collect/bendix/index.html

Or he did, ca 2001.

I would so like to be restoring a tube computer.

How is Cory's LGP-30 project going, if he's reading?



Re: Ethernet cable (Was: Sun3 valuations?)

2018-01-24 Thread Brent Hilpert via cctalk
On 2018-Jan-23, at 12:27 PM, Paul Koning via cctalk wrote:
> The Ethernet spec says that the cable OD is in the range .365 to .415 inch, 
> which is 9.27 to 10.54 mm.  The nominal OD of RG-8/U is .405 inches, or 10.28 
> mm, which is within spec for Ethernet cable.
> 
> One place where the two cable specs differ is in the velocity factor, 0.66 
> for RG-8/U and 0.77 for Ethernet cable.  That relates to the dielectric -- 
> solid polyethylene for RG-8/U and foamed material (unspecified) for Ethernet. 
>  Also, Ethernet requires a solid inner conductor (for the tap) while RG-8/U 
> may come stranded.  (Maybe only in some variants, I'm not sure.)  And there 
> are the stripes, of course, but those have no electrical significance.  You 
> can use a tape measure if you don't have the stripes.

I was attempting some calculations to see if I could derive the 2.5M 
transceiver spacing and was wondering what the velocity factor for the cable 
was, as it should affect the transceiver spacing in theory.

I haven't seen any pictures during this thread of the transceivers we used with 
the 10MB yellow hose - heavy gauge metal boxes about 3" * 4" * 1" with N 
connectors. I remember piling up the 3 ft diameter loops of yellow coax in the 
machine room where you had a bunch of machines together and didn't need the 
cable lengths between them, until the DEC DELNI (ethernet AUI hub) cleaned up 
that mess.



Re: Sun3 valuations?

2018-01-22 Thread Brent Hilpert via cctalk
On 2018-Jan-22, at 1:24 AM, Pete Lancashire via cctalk wrote:
> My interest would be from having the first Sun systems in the Portland
> Oregon area. It consisted of a 3/260 w a Fujitsu Eagle, and a 90 ips 9
> track that I cant remember the make.
> Tied to it where 3 3/50s. Initially diskless then I added a 40 MB drive to
> each of them.
> 
> Networked into the companies network, tapped into on of the yellow coaxes
> up in the ceiling.
> 
> I all was for running Interleaf. Oh yea printing was via a Imagin (sp?)
> print engine.

The early 'compact' laser printer ca. 1984 (table-top sized as opposed to the 
20sqft of floor space of the 1st gen of laser printers)?
My recollection is it was "Imagen".
I took it as incorporating "image", and "generate" or "engine" (my perception).

We had one in the CS department. Nice for the time, but required regular 
cleaning/maintenance, dept. tech guy would roll his eyes - " . . again?"

Wasn't the internal controller the early Sun processor board (basically a 68000 
single-board computer that preceded or was used in the Sun 1), or am I 
conflating things? (We had a Sun 1 quite early as well).



Re: Sun3 valuations?

2018-01-22 Thread Brent Hilpert via cctalk
On 2018-Jan-22, at 1:24 AM, Pete Lancashire via cctalk wrote:
> My interest would be from having the first Sun systems in the Portland
> Oregon area. It consisted of a 3/260 w a Fujitsu Eagle, and a 90 ips 9
> track that I cant remember the make.
> Tied to it where 3 3/50s. Initially diskless then I added a 40 MB drive to
> each of them.
> 
> Networked into the companies network, tapped into on of the yellow coaxes
> up in the ceiling.
> 
> I all was for running Interleaf. Oh yea printing was via a Imagin (sp?)
> print engine.

The early 'compact' laser printer ca. 1984 (table-top sized as opposed to the 
20sqft of floor space of the 1st gen of laser printers)?
My recollection is it was "Imagen".
I took it as incorporating "image", and "generate" or "engine" (my perception).

We had one in the CS department. Nice for the time, but required regular 
cleaning/maintenance, dept. tech guy would roll his eyes - " . . again?"

Wasn't the internal controller the early Sun processor board (basically a 68000 
single-board computer that preceded or was used in the Sun 1), or am I 
conflating things? (We had a Sun 1 quite early as well).



Re: Help identifying IC

2018-01-20 Thread Brent Hilpert via cctalk
The mid-70s saw a plethora of dedicated-logic LSI TOD clock chips in 24-28 and 
sometimes 40 pin packages.
Most prevalent IME were those made by National, Mostek and Fairchild.

Going by the labelling for the other two chips, fair chance the ID of the big 
chip is staring right at us: MPS 7123.
Micro Power Systems and Commodore Semiconductor Group used chip ids of the form 
MPS, although I have nothing for specifically MPS7123.
The former would fit the battery operation.
Try tilting the IC obliquely to the light and viewing angle if you haven't, 
often shows up a remnant impression of printing on the IC.

I never did see a TOD clock chip in a gold-topped package - they were generally 
targetted for the low-cost consumer market - although by the date code it may 
be early enough, in the period that consumer products would have such packages.

The clock chips were pretty straightforward but varied in options:
generally 2 power pins
2 oscillator pins (for the multiplexing)
50/60hz input pin (for TOD timing if separate from internal 
oscillator)
4 or 6 digit-drive pins
7 segment-drive pins
some setting/mode control pins which could be either switched 
direct to a power rail or multiplexed with isolation diodes off the digit pins
often an AM/PM indicator pin
alarm control output pin

(There were some for non-multiplexed display drive but that would be >28 pins.)
(Some had BCD rather than 7-seg numeral outputs)

So, yes, it's hard to say, could be a dedicated TOD clock, could be an 
evaluation module for something like a multi-digit decade counter IC.
Perhaps a start-stop timer, 3 switches: start / stop / reset.

Not difficult to trace out, could see if there are any other pins that might be 
for external connections like timing control or counter inputs.



On 2018-Jan-20, at 6:06 PM, Josh Dersch via cctalk wrote:

> Hi all --
> 
> I picked up this little toy at VCF West last summer:
> 
> https://1drv.ms/i/s!Aqb36sqnCIfMouYd0HV0ZThE3FnE_Q
> 
> As far as I can tell, it's supposed to be a clock and I assume it was a kit 
> -- this one was definitely hand-assembled.  It's powered by two AA's 
> (apparently, there are no markings), has a 4 digit LED display, and at the 
> moment it does not work at all.
> 
> Can't find anything about this item at all.  At the moment I'm curious what 
> the 28-pin IC at the top is -- there are no markings of any kind anywhere on 
> the chip.  It has an interesting construction -- blue plastic on both sides 
> with a metal cap over the die.  The two other ICs are RCA 3081 and RCA 3082 
> which are simply transistor arrays for driving the 4-digit LED display.  I 
> assume the 28-pin IC is a simple microcontroller with built-in ROM, or 
> perhaps it's a device specifically designed to run a digital clock.  Whatever 
> it is, I'd love to know what it does so I can debug this thing and possibly 
> source a replacement.
> 
> I realize this is not a lot of information to go on, but on the off-chance 
> someone's seen something like this before I figured I'd give it a go...
> 
> Thanks,
> 
> Josh
> 



Re: Computing from 1976

2018-01-01 Thread Brent Hilpert via cctalk
On 2018-Jan-01, at 5:06 PM, Paul Koning via cctalk wrote:
>> On Jan 1, 2018, at 3:57 PM, David Bridgham via cctalk 
>>  wrote:
>> On 01/01/2018 03:33 PM, Noel Chiappa via cctalk wrote:
 From: Paul Koning
>>> 
 The only asynchronous computer I can think of is the Dutch ARRA 1
>>> 
>>> Isn't the KA10 basically asynchronous? (I know, it has a clock, but I'm
>>> not sure how much it is used for.)
>> 
>> This was my understanding, as well.
>> 
>> More recently there was the AMULET processors designed at the University
>> of Manchester.
>> 
>> https://en.wikipedia.org/wiki/AMULET_microprocessor
>> 
>> One of the stories I read about the AMULET was that they wrote a little
>> program to blink an LED where the timing was determined by a busy loop. 
>> If they sat a hot cup of coffee on the processor, the light would blink
>> slower; a cup of ice water and it would blink faster. 
> 
> Neat.  I found this 2011 paper that's interesting: 
> http://www.cs.columbia.edu/~nowick/nowick-singh-ieee-dt-11-published.pdf
> 
> The company I was trying to remember is Fulcrum, which was bought by Intel; 
> they had morphed into an Ethernet switch chip company by then.  A pretty good 
> one, as I recall.  But the original concept was a microprocessor, possibly a 
> MIPS one, I don't remember.  The idea was that the chip speed would depend on 
> how fast things happened to work, so different chips would run at different 
> speeds due to process variations, and power supply and temperature changes 
> would also affect things just as you described.
> 
> The paper I just mentioned lists a number of early computer designs as 
> asynchronous, though it doesn't mention the ARRA 1, probably because it's not 
> well known (a problem common to Dutch computers).  Also, those other 
> computers did work.


The IAS machine (1952, and in some measure a template design for modern 
processors) and its clones (ILLIAC, ORDVAC, MANIAC, etc.) were billed as an 
asynchronous design, although I haven't seen the details to see precisely what 
that meant in context.



Re: Non-Yahoo MTS Mailing Lists

2017-12-30 Thread Brent Hilpert via cctalk
On 2017-Dec-30, at 6:26 PM, Adrian Stoness via cctalk wrote:

> mts???
> 
> as in manitoba telcome services now known as bellmts??



No, Michigan Terminal System.

A timesharing system for IBM 360/370 series mainframes, used and maintained at 
a number of universities from the late 60s through early 90s for campus-wide 
computing services.

Re: Help Identifying Components

2017-12-24 Thread Brent Hilpert via cctalk
On 2017-Dec-24, at 12:01 PM, Chuck Guzis via cctalk wrote:
> On 12/24/2017 11:15 AM, Rob Jarratt wrote:
> 
>> I think the orange components are capacitors (they are taller than the 
>> browner ones), but their markings don't seem to hint at the values, some are 
>> marked "AA4", which does not seem to correspond to any marking scheme I have 
>> been able to find. Any idea if they *are* capacitors and what the values 
>> might be?
> 
> My guess is capacitors also.  


Noting they are paralleling resistors, they're probably just noise/AC bypass, 
on the order of 0.01 uF, and not overly consequential to understanding the 
basic circuit.

Again, one can draw it out with the above presumption and then assess whether 
it makes sense or for alternative functions.


> This "SMD Code Book"  should be of some value:
> 
> http://www.sphere.bc.ca/download/smd-codebook.pdf
> 
> --Chuck



Re: Help Identifying Components

2017-12-24 Thread Brent Hilpert via cctalk
On 2017-Dec-24, at 10:27 AM, Rob Jarratt via cctalk wrote:
> I am continuing work to reverse engineer the schematic for my H7826 PSU. I
> have removed one of the daughter cards in order to draw its schematic, but I
> can't identify some of the surface mount components on it. I have posted a
> picture of it here:
> https://rjarratt.files.wordpress.com/2017/12/50-19530.jpg
> 
> The ones I can't identify are:
> 
> 1.   The component with two wide pins that looks like an IC
> approximately in the middle of the board. It is marked M106 (or it might be
> AA106) and 91813 underneath. I think it may be a resistor, but I am not
> sure.
> 
> 2.   Just to the right of this is another much thinner two-pin component
> which is black on top with a kind of white notch. I have no idea at all what
> this is.
> 
> 3.   The three 3-pin black components to the left of the first
> component. Two of them are marked "2T L" (or is that "ZT L"?), one appears
> to be marked "2X I" (letter "ih", not letter "el"). I guess they are
> transistors, but they may not be of course, and I don't know their pinout.
> 
> 
> 
> Any help with identifying what these are would be very helpful.



SMD codes are a mess as the same code is often used by different manufacturers 
for different devices.
Resolving them is often an effort working between the multiple code 
possibilities, what makes electrical sense after reverse engineering the 
circuit topology, and ohmmeter measurements of the device.

2: Try measuring the resistance, if it's a low resistance perhaps a fuse as 
Chuck suggested, but considering the precision reference on the board, if it's 
a higher resistance perhaps a precision-trimmed resistor.

3: As per Chuck's suggestion likely bipolar transistors, and probably:
2T: PNP
2X: NPN
with pinout (hopefully this renders unambiguously):
C
B   E

Try drawing it out presuming the above and then assess whether it makes sense 
electrically for polarity, current flow and control.



Re: Odd Connections to Rectifier?

2017-12-18 Thread Brent Hilpert via cctalk
On 2017-Dec-18, at 12:06 AM, Rob Jarratt via cctalk wrote:
> I am reverse engineering the schematic for the input stage of my H7862 PSU.
> I have come across a KBU6J bridge rectifier which seems to be connected only
> to the two middle pins, which are the AC inputs. I can't see any other
> connections. Before I desolder it to verify there are no connections I can't
> see, does this make any sense?

It's barely conceivable it could be getting used as a clamp or snubber.

If you haven't found another bridge or rectifiers for the mains rectification,
then keep looking for unseen connections to this bridge.

Re: BT139-600G Triac Equivalent

2017-12-17 Thread Brent Hilpert via cctalk
On 2017-Dec-17, at 3:23 AM, Rob Jarratt via cctalk wrote:
> I have a suspicion that this component may be faulty on the input side of my
> H7826 PSU. A little tester I have does not recognise it, it is possible that
> the currents it uses are too low for this particular triac, but I am not
> sure.
> 
> There are new ones on ebay, but I am not sure if I can trust ebay sellers to
> have genuine parts. So I would like to identify a suitable replacement. I
> have found a few suggestions for replacements, but looking at the datasheets
> many seem to have a lower peak gate power then the BT139. I am not sure what
> the critical parameters are, so I don't know how to choose a replacement.
> 
> Can anyone suggest a good replacement for this part?


Any parameter can be critical, depending on how the device is being used.

The parameters primarily or commonly of issue with triacs are the peak blocking 
voltage and the RMS conducting current.

The gate power is going to be a function of the trigger circuitry, so one isn't 
going to know for sure without analysing the trigger circuit design.
With that said, gate circuits are generally designed for fairly low-level 
operation and not to be using a lot of power.

If this triac is on the input side and just used as a switch for input voltage 
selection, the requirements are probably pretty generic.

The Q-thousand series of triacs are (were?) pretty common:
https://www.digchip.com/datasheets/parts/datasheet/472/Q2003L-pdf.php

Try comparing with the Q6015L5 (pdf.32-33).



Re: ISC Intecolor 8300 terminal

2017-12-14 Thread Brent Hilpert via cctalk

On 2017-Dec-14, at 10:20 PM, Chuck Guzis via cctalk wrote:

> On 12/14/2017 08:58 PM, Gregory McGill via cctalk wrote:
>> I recently picked this up from shopgoodwill and it has an older power
>> plug.  It is NOT a standard plug as shown in the picture below that is too
>> tall and pins are smaller etc..
>> 
>> Anyone know the name of this 'standard' so I can find a cable? Or possibly
>> have one  around I can get from you?
>> 
>> Greg
>> 
>> https://sgws3productimages.azureedge.net/sgwproductimages/images/8/11-25-2017/31024892557io.JPG
>> https://photos.app.goo.gl/HzXVUDqfCv5U7zBC2
>> 
> 
> From the looks of your unit, it might just be simpler to fit it with a
> standard IEC receptacle.  Note that the cutout is already rectangular,
> so an IEC may just fit without any case modification.


The screw holes have a slightly different spacing between the two types, they 
have to be 'moved' (filed) out about a mm each;
and it looks like the existing opening will have to be enlarged vertically a 
bit.
If there's nothing interfering on the inside it does look like an easy 
candidate for replacement with IEC.

Re: ISC Intecolor 8300 terminal

2017-12-14 Thread Brent Hilpert via cctalk
On 2017-Dec-14, at 8:58 PM, Gregory McGill via cctalk wrote:
> I recently picked this up from shopgoodwill and it has an older power
> plug.  It is NOT a standard plug as shown in the picture below that is too
> tall and pins are smaller etc..
> 
> Anyone know the name of this 'standard' so I can find a cable? Or possibly
> have one  around I can get from you?
> 
> Greg
> 
> https://sgws3productimages.azureedge.net/sgwproductimages/images/8/11-25-2017/31024892557io.JPG
> https://photos.app.goo.gl/HzXVUDqfCv5U7zBC2


https://web.archive.org/web/20150310022909/http://www.cs.ubc.ca:80/~hilpert/e/powerConn/index.html

Re: Epson PX-8 specifically TF-10 problem...

2017-12-09 Thread Brent Hilpert via cctalk
On 2017-Dec-09, at 6:06 PM, allison via cctalk wrote:
> On 12/09/2017 07:52 PM, Fred Cisin via cctalk wrote:
>> On Sat, 9 Dec 2017, allison via cctalk wrote:
>>> I have several Epson PX-8s and i used them.. They work well with the
>>> various wedges I have.
>>> I also Have a PF-10 which is the portable 3.5" 40 track two side floppy.
>>> The problem is it randomly does not turn the media unless I give it a
>>> push to get it turning.
>>> Things checked:
>>> * Batteries, NEW fully charge (Both).
>>> * internal Power supplies, current voltage and bridged with external
>>>supplies does not help.
>>> * media checked for binding, it does not.
>>>  When it turns it reads and writes correctly and at the correct speed.
>>>  It may do so without help for many tries then will stop required a
>>> manual push.
>>> At first glance I though there were motor bearing issues but have
>>> verified
>>> this is not so.   If I force motor on and restrain it I has good torque
>>> and no
>>> dead spots.  All signals in the motor control look good on the scope.
>>> Any thoughts?
>> 
>> How does it detect the presence of a disk?   and/or disk change?
>> 
>> 
> Functions normally save for the motor does not always turn on command
> but will if manually pushed.  All other functions are normal.

How about a problem with the current supply to the motor, such as low gain in 
the driver.
A progressive failure may be just on the edge of supplying enough current to 
keep it rotating, but not enough for startup torque.

Re: Playing with HP2640B

2017-12-05 Thread Brent Hilpert via cctalk
On 2017-Dec-05, at 1:20 PM, Brent Hilpert via cctalk wrote:

> On 2017-Dec-05, at 1:08 PM, Mattis Lind wrote:
>> 2017-12-05 20:44 GMT+01:00 Brent Hilpert via cctalk <cctalk@classiccmp.org>:
>>> On 2017-Dec-05, at 9:14 AM, Mattis Lind via cctalk wrote:
>> 
>>>> Does the 27S82 have any equivalents that I could look up instead in the
>>>> device list?
>> 
>>> FWIW, 27S82 is listed in the 1982 IC Master as
>> 
>>>  AM27S82M:   TTL 1024*8 ROM, 275nS access, OC outputs, 24 pin, 5V supply
>> 
>>> So half the size of a 2716.
>>> The book lists PROMs and ROMs separately, so it was probably 
>>> mask-programmed.
>>> (M would be for mil temp going by other AMD numbers.)
>> 
>> I would think bipolar PROM since rest of the AMD 27S series were bipolar 
>> PROMs. I will check this weekend if I can find an old AMD databook.
> 
> The ref did specify it as TTL, so yes, bipolar.

Oh, as for being PROM vs ROM, I'm just going by the way things are listed in 
the ref.
It lists different 27Sxx devices under PROM vs ROM,
for example 27S180, 27S181 are 1024*8 listed under PROM, but 27S80, 27S81, 
27S82, 27S83 are 1024*8 listed under ROM.
It's possible they're mis-listed of course, but manufacturers often did make 
equivalent devices as both fusible and mask,
I don't know what AMD did for series names in that regard.



Re: Playing with HP2640B

2017-12-05 Thread Brent Hilpert via cctalk
On 2017-Dec-05, at 1:08 PM, Mattis Lind wrote:
> 2017-12-05 20:44 GMT+01:00 Brent Hilpert via cctalk <cctalk@classiccmp.org>:
> >On 2017-Dec-05, at 9:14 AM, Mattis Lind via cctalk wrote:
> 
> >> Does the 27S82 have any equivalents that I could look up instead in the
> >> device list?
> 
> >FWIW, 27S82 is listed in the 1982 IC Master as
> 
> >   AM27S82M:   TTL 1024*8 ROM, 275nS access, OC outputs, 24 pin, 5V 
> > supply
> 
> >So half the size of a 2716.
> >The book lists PROMs and ROMs separately, so it was probably mask-programmed.
> >(M would be for mil temp going by other AMD numbers.)
> 
> I would think bipolar PROM since rest of the AMD 27S series were bipolar 
> PROMs. I will check this weekend if I can find an old AMD databook.

The ref did specify it as TTL, so yes, bipolar.



Re: Playing with HP2640B

2017-12-05 Thread Brent Hilpert via cctalk
On 2017-Dec-05, at 9:14 AM, Mattis Lind via cctalk wrote:
> 
> Looking more into this document revelas that it covers three boards
> 02640-60009, 02640-60088 and 02640-60112.
> 
> Now I had the idea of dumping the character ROM as well. But what is a AMD
> 27S82? I cannot really find a datasheet online. From the schematics above
> it looks not too much off from standard 2716 EPROM with pin 19 (A10) as E3
> , pin 21 (VPP)  as /E1. But my Data I/O 29B does not seem to be compatible
> with 27S82 and as  pin 21 is active low it gives that a 2716 setting in the
> programmer (reader) won't work.
> 
> Does the 27S82 have any equivalents that I could look up instead in the
> device list?

FWIW, 27S82 is listed in the 1982 IC Master as

AM27S82M:   TTL 1024*8 ROM, 275nS access, OC outputs, 24 pin, 5V supply

So half the size of a 2716.
The book lists PROMs and ROMs separately, so it was probably mask-programmed.
(M would be for mil temp going by other AMD numbers.)



Re: Can anyone identify what this board is/does?

2017-12-01 Thread Brent Hilpert via cctalk
On 2017-Dec-01, at 7:12 AM, Tony Aiuto via cctalk wrote:

> https://www.ebay.com/itm/263005049078
> 
> EBay listing for a "Soviet Magnetic Ferrite Core Memory Board". It looks
> like 20 something gigantic cores and a lot of diodes. I am guessing it is
> some kind of ROM, but it doesn't look like a rope memory. And maybe the
> cores are not cores at all, but some sort of inductor. I've not seen this
> before.


That's very funny.
It looks to be a core rope memory that hasn't been programmed.

Other organisations might be possible, but it looks like a pulse-transformer 
type of core-rope,
where the cores are just for ordinary induction, not switching/memory cores.

- the matrix of black what-look-to-be diodes would be data-wire 
isolation diodes 

- the little brown 'stools' are wire routing posts

- you can see the mulit-turn sense windings (bluish) already present on 
the cores

- above the cores are the sense amplifiers or 1st stage thereof

- there is one wire through all the cores, perhaps a test wire for core 
and sense amp response

Each data-wire would start at one of the solder pins in the pin matrix on the 
left, weave through the cores to encode the data,
turn back 180, then 90 degrees around one of the stools to drop down and 
terminate at the solder pin by an isolation diode.

There would be another board for decoding the address to 1-of-x and 1-of-y.

I didn't count precisely but it looks like it would be 256 words of 20 bits.

That might be a date code of 6847 on a cap (or is it 6B47?), so perhaps earlier 
than the listing-stated 1981.

Actually, it kind of hints at it in the description: "With out Firmware ROM 
wire (empty slots)"




Re: Livermore Data Systems / was Re: what is this NCR modem? what did it go to?

2017-11-28 Thread Brent Hilpert via cctalk
On 2017-Nov-28, at 2:54 PM, Fred Cisin via cctalk wrote:
> On Tue, 28 Nov 2017, Brent Hilpert via cctalk wrote:
>> I couldn't find the ebay listing for the NCR modem for some reason, either 
>> using the number or by searching by keywords.
> 
> https://www.ebay.com/itm/132411929563


That works . . . forgot about composing the URL directly from the item number.

Still won't show up with regular searches on ebay.com , although these do with 
"ncr acoustic":

https://www.ebay.com/itm/NEW-ACOUSTIC-REVIVE-RTP-4-absolute-Power-supply-box-outlet-From-JP-with-tracking/252956939311?hash=item3ae568942f:g:YAgAAOSwJH1ZJosl
Latest audiophool scam.



Re: Livermore Data Systems / was Re: what is this NCR modem? what did it go to?

2017-11-28 Thread Brent Hilpert via cctalk
On 2017-Nov-27, at 5:25 PM, steve shumaker via cctalk wrote:
> On 11/27/2017 2:26 PM, Fred Cisin via cctalk wrote:
>>>> The Livermore Data Systems modems that I sold off were from about 1964?
>> 
>> On Mon, 27 Nov 2017, Brent Hilpert via cctalk wrote:
>>> Were those the Livermore Data Systems modems in a wood box you were selling?
>>> Did you have anything to ascertain the 1964 date for LDS, or were you 
>>> getting that date from the stuff on the web?
>> . . .
>>> Someone in some comments suggests LDS wasn't building these until 1968, 
>>> which strikes me as more plausible.
>> 
>> Thank you!
>> 
>> That is why I put a question mark after 1964.
>> I was basing it on nothing more than verbal comment by the guy that I got 
>> them from.   And, while I had them, I hadn't had any reason to particularly 
>> care.
>> 
>> 1968 does, indeed, seem more plausible.
>> 
>> It still serves to illustrate that 1971 is NOT too early for that NCR.
>> 
>> -- 
>> Grumpy Ol' Fred ci...@xenosoft.com
>> 
> I can add another data point to the discussion:
> 
> My LDS Model A with SN 0491 has two TI transistors both with data code "6914"
> 
> And for what it's worth, if you have one and have never opened it up, go do 
> so right now!The three small circuit boards have a 3"x4" piece of the 
> infamous black foam to pad the cards when inserted in the case.  Of course 
> the foam is mostly gone now except for where it wraps around the cards and 
> corrodes the components that it touches!


Thanks for the additional datapoint.
It does suggest Model A production may likely have started in 1968.
Actual date codes in mine were 6908 to 7008.
The larger caps are also a good place to look for date codes.

I did the schematic, if you have an interest.
Eventually I'll get a little web article up for the model.


I couldn't find the ebay listing for the NCR modem for some reason, either 
using the number or by searching by keywords.

  1   2   >