[cctalk] Re: Intel 4004

2023-11-21 Thread Brent Hilpert via cctalk
On 2023-Nov-21, at 1:03 AM, ED SHARPE via cctalk wrote:
> On Mon, Nov 20, 2023 at 7:01 PM ben via cctalk  wrote:
>> On 2023-11-20 5:36 p.m., Murray McCullough via cctalk wrote:
>>> On Nov. 15, 1971 Intel commercially released the 4004 microprocessor which
>>> some consider to be the first. Nonetheless, even if not in agreement, it
>>> made possible the instrument which drives the classic-computing industry or
>>> at the very least our hobby!
>>> 
>>> Happy computing.
>>> 
>>> Murray 
>> 
>> https://retrocomputingforum.com/t/swiss-physicist-builds-complete-intel-4004-computer-out-of-smd-transistors/3738
>> THE DIY VERSION
> 
> So what are the other contenders and what do they bring to table


A claim is made for the first microproc being the CADC processor of an early 
flight-control system for the F-14, made by Garrett AiResearch ~ 1969. I 
haven't looked into it in depth - or I don't know of detailed info being 
available - but apparently it was a CPU made up of several LSI chips. In my 
opinion that disqualifies it, but it's all into the mug's game of specifying 
'first at what?'

There's also the TMS-1000 series of calculator chips which were single-chip 
programmed processors and came in the same time-frame (measured in months) of 
the 4004. IIRC, there's some argument there about development vs production vs 
release vs availability dates.

Also to note, there were multi-chip programmed-processor calculator chip-sets 
in that time-frame, not sure of the exact timing relative to the 4004.

The microproc was simply a development whose time had come. It was a 
predictable, 'in-the-air' idea brought to fruition with increasing integration 
capabilities.

In reality the 4004 was/would-be awkward to use for a general-purpose system. 
The 4004 CPU was tailored for use with mask-programmed ROM chips and RAM chips, 
all specific to the MCS-4 family. IO was also in those MCS-4 chips. To make a 
system with off-the-shelf ROM/RAM/IO chips required going through other special 
MCS-4 family chips for that purpose.
Or put another way, it was a multi-chip CPU by the time you tried to make a 
system with standard RAM/ROM/IO chips.

I have two embedded systems using 4004s:

- an M900 PROM programmer.
  This system does have interfacing for use of off-the-shelf ROM 
(1702s) and RAM.
  The manual for this includes the firmware source code listing.

- the remnants of the PLL control from an avionics transceiver.
  An example of a 'proper' MCS-4 system, as it was intended to be used,
  with 4004 CPU, 4001 ROMs, 4002 RAM & 4201 clock-gen.
 http://madrona.ca/e/4004Monument/index.html



[cctalk] Re: Theory of operation of DEC H7441 regulator?

2023-09-28 Thread Brent Hilpert via cctalk
On 2023-Sep-28, at 3:55 AM, Tom Hunter wrote:
> Thank you very much Brent !!!
> 
> Your explanation beautifully clarified how the H7441 works.
> I have asked the same question over at vcfed.org without an answer..
> I hope it is Ok to share to vcfed.org what you wrote as others are likely to 
> struggle too with the complexity of the H7441 in the future and vcfed.org is 
> searchable.
> 
> Thanks again for your time and effort to explain what I really struggled to 
> understand.
> 
> Tom

Great.
With the basic form identified, if you're unfamiliar with buck converters, I'm 
sure the AofE you mentioned (I've heard of the book but never seen it) must 
have some discussion of their operation.



[cctalk] Re: Theory of operation of DEC H7441 regulator?

2023-09-28 Thread Brent Hilpert via cctalk
On 2023-Sep-28, at 12:29 AM, Brent Hilpert via cctalk wrote:
> ...
> Excessive current through Q5 produces a V-drop across R10 which may turn on 
> Q7 to take the PWM-mono into reset (E2.4=low).
> D7,D8,R3 clamp and sink reverse voltage/energy from the T1 secondary to avoid 
> reverse breakdown/damage to Q1,Q2,Q3.
   ^^
correction: that should be R7, not R3.



[cctalk] Re: Theory of operation of DEC H7441 regulator?

2023-09-28 Thread Brent Hilpert via cctalk
On 2023-Sep-27, at 9:01 PM, Tom Hunter via cctalk wrote:
> The DEC H7441 regulator is a relatively complex circuit using 2 x 555
> timers, 2 x LM301 op-amps, 2 x transformers and 2 inductors
> I am struggling to understand how it is meant to work and was hoping to
> find a maintenance manual for it.
> 
> Could anyone with such a manual please help?
> 
> Alternatively is there another explanation of the operation of this or
> similar types of circuits?
> The circuit implements a switch mode supply.
> 
> One of the two 555 timers operates as an oscillator, the second I think
> operates as a monoflop with the pulse length controlled via one of the
> LM301s.
> Overall the circuit seems very complex and while I understand parts of it,
> other parts are mysterious.
> 
> In particular the top left section around Q1/Q2/Q3 and T1/T2 and E3 is most
> confusing.
> 
> I did not find anything remotely similar in "The Art of Electronics" from
> Horowitz & Winfield.
> 
> The H7441 schematics are available from here:
> 
> https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/08%20PDP-11/01%20PDP-1104-1134/02%20PDP-1134A%20Power%20Supply/H7441%20FMPS%20MP00271%20part-1%20(H7441).pdf
> 
> Thanks for any help or suggested reading material.



I'll take a stab at a brief description:

The basic form is that of a switching inductive buck/step-down regulator.

L1 is the main bucking inductor.
D12 is the inductor discharge diode for the bucking operation.
Q1 and Q2 are the main switching transistors, operating in parallel with T2 in 
their emitter circuits to balance current through the two transistors.
Q3 is a driver stage for Q1,Q2.
C11,L2,C16 are the main output filter.

Fixed-frequency oscillator E1 triggers variable-width monostable E2 via Q6 to 
create the PWM switching pulses.
Q8 and associated form a constant-current source for the timing capacitor C10 
of this PWM-monostable, to linearize the charge curve of the capacitor for 
better operation of the pulse-width timing.

The switching pulses from the PWM-mono are amplified by Q5 to drive T1.
T1 provides galvanic (voltage) isolation to shift the pulses up to the higher 
operating voltage of Q1,Q2,Q3.
All base-drive energy for Q1 and Q2 is delivered through Q3 from T1, thus Q5 
driving T1 must itself be a reasonably hefty driver.
Excessive current through Q5 produces a V-drop across R10 which may turn on Q7 
to take the PWM-mono into reset (E2.4=low).
D7,D8,R3 clamp and sink reverse voltage/energy from the T1 secondary to avoid 
reverse breakdown/damage to Q1,Q2,Q3.

Op-amp E4 is the voltage-sense amplifier for the main regulation feedback loop.
D18 and associated provide the master reference voltage.
An increase in the sensed +5 output voltage presented at -input E4.2 relative 
to the reference voltage at +input E4.3 lowers the voltage into the PWM-mono 
control input E2.5 to shorten the ON-width of the switching pulses, and 
vice-versa for a decrease in the +5 output.

Op-amp E3 is running open-loop to function as a comparator for over-current 
sense.
R17,R18 are the current-sense resistors, placed here in the negative supply 
line of the +5 main output.
If the current-induced voltage drop across R17,R18 becomes high enough, E3 
trips high, turning on Q7 to take the PWM-mono into reset.
R19,R20 provide the counter-bias V that the R17,R18 V-drop must overcome to 
trip E3.
E3 tripping high also turns on Q9 to short the reference voltage to GND at 
E4.3, to minimize the ON-width of the switching pulses.

D20,D21,D22 form a crowbar for the +5 output.
The crowbar tripping performs two actions: shorting the +5 output via D19, as 
well as shorting the switching pulses at the base of Q5 via D23 so the supply 
doesn't keep pumping energy into the shorted output.

D2,Q4 and associated form a simple linear regulator for internal supply of ~ 
+12V to the control electronics.
C7,D17,D25,C8 are a little charge pump driven off oscillator E1 to create a 
negative V supply for the op-amps E3,E4.



[cctalk] Re: Concorde cabin display technology?

2023-09-16 Thread Brent Hilpert via cctalk
On 2023-Sep-16, at 8:52 AM, Shoppa, Tim via cctalk wrote:
> Not quite computer tech but I figure this is the best place to ask:
> 
> Does anyone recognize the display tech that was used on the Concorde's 
> in-cabin display?
> 
> Examples:
> https://samchui.com/wp-content/uploads/2016/02/CON15.jpg
> https://samchui.com/wp-content/uploads/2016/02/CON16.jpg
> 
> The display had fully-formed digits and letters, and showed either Mach and 
> Feet, or Temp and MPH. Some pictures show the display in green and others 
> show it in orange - which of course were popular monochrome CRT colors, yet 
> the display looks too "flat" to be a couple CRT's. Those colors were also 
> popular for Electroluminiscent displays which matches the evident "flatness" 
> but I'm not sure I've seen any EL's with fully formed digits like this with 
> no visible segmentation?
> 
> I want to guess it was individual digits back-projected - which was a popular 
> control-theater display tech at the end of the 20th century - but I can't 
> rule out, say, really well-done edge-lit character plates. In any event there 
> doesn't seem to be any visible jitter up and down between digits that I might 
> expect with either of those technologies.
> 
> The "FEET" display in the above-referenced JPG's shows some artifacts at the 
> left and right edges which might be a clue?
> 
> Some pics of the BA Concorde interior had a simple 15-segment and 7-segment 
> green LED display. Don't need help with that one .


It sure looks like back-projection. Rather than individual digits, perhaps it 
was a single scroll for each of the items. E.g. the altitude display may have 
been only 1000-ft resolution, the temperature display only 5-degree resolution, 
etc., reducing the count of values to be presented to something manageable. 
Even then though, I can't say I've seen an off-the-shelf type that would fit, 
even with custom films. But being Concorde, a full-custom design is quite 
conceivable.



[cctalk] Re: NGPL TCS - 1969 Industrial Control

2023-08-21 Thread Brent Hilpert via cctalk
On 2023-Aug-20, at 5:32 PM, Eric Moore via cctalk wrote:

> https://youtu.be/-CaUafVqnbw
> 
> Super stoked to be able to share my latest video, I hope yall like it.
> 
> -Eric


I'll third Ken and Rick's comments.
Nice to see this restored as its original-use system - the CPU together with 
the process control I/O hardware environment.

[cctalk] Re: 1974 No Name Terminal

2023-07-05 Thread Brent Hilpert via cctalk
On 2023-Jul-05, at 9:45 AM,  
 wrote:

> Thank you!  I couldn't remember if I'd posted it here before, I've been off
> the list for a while.
> 
> Because I don't know really anything about it, I'd been operating on the
> belief the power sent from the PSU was DC.  So maybe that's my issue.  There
> is a single 10 pin connector from the PSU to the motherboard.  I tested for
> DC and found the following:
> 
> Brown- +5V
> Red- +5V
> Orange   - +5V
> Yellow   - -16V
> Green - +16V
> Blue  - -0.8V
> Purple - GND
> Grey - GND
> White- GND
> Black- -2.4V
> 
> I'm not sure if the +16 and -16v need to be adjusted, or if they are that
> high because they don't have a load during my testing.  The -16V is directly
> connected to the VEE on a nearby 1488, and I think the max voltage there
> should be -15V.
> 
> The blue and black are the ones that didn't seem right.  But, if they're not
> DC then maybe that's my issue.  Also last night I found more cold solder
> joints, so maybe one or both are affected by that.  I will test with my DMM
> as AC instead of DC and see if I get something there instead.  Barring that,
> I'm working on a schematic of the PSU to try and figure out what it's
> supposed to be delivering.
> 
> Like I said, very tempting to plug in, I suspect it may be just fine.. but..
> there's a lot of chips to blow up here if I'm wrong.

Seeing as how you're looking at the connections from the PS to the logic, 
raises the question of how the monitor is being powered: does it have it's own 
PS from 120VAC, wired to the PS directly, or from the PS via the logic board.

Some points about supplies:
- The memory chips are 1402 256*4 PMOS shift registers. These need 
supplies of Vcc = +5 and Vdd = -5 to -9V.
  The 1402s also need higher voltage clock signals, between Vcc-15 and 
Vcc-17 (may be -10 to -12 relative to gnd).
  The two MMH0026 ICs beside the 1402s are the clock drivers for the 
1402s.
- The 3258 character generator needs -12 (and +5).
- The 1602 UART probably needs -12 (and +5).
- The RS232 needs +something and -something line-drive levels of course.
- There's what looks to be a potted crystal clock module on there, 
might check what its supply is.
  Could be +5, but could be something else.
- There's probably a MOS keyboard encoder that may require some 
supplies besides just +5.
- Some of these supplies may be derived via components (e.g. zener & 
dropping R) on the logic boards.
- And of course the monitor needs its supply(s).

Seeing as how you have some odd things appearing on the PS, if it were me, I 
would be:
- RE-ing the PS thoroughly,
- figuring out the power connections on the logic boards to these 
special ICs,
- figuring out the monitor power supply/sources
.. so it's known how all these requirements are intended to be met before 
powering the whole thing up.

I recently refurbished a Teleray terminal from the same period. It uses MOS 
shift registers from the same family (1404s) and similar funky clock drivers. 
The power supplies design was more straightforward than what you appear to be 
dealing with. On things like this I also like to look at the DB25 connector to 
see exactly how it's wired - fixed-level ctl-sig outputs, connections for 
ctl-sig inputs that may be required, DCE vs DTE, whether there are any 
non-EIA-standard connections present.



[cctalk] Re: 1974 No Name Terminal

2023-07-05 Thread Brent Hilpert via cctalk
On 2023-Jul-05, at 8:25 AM, Brad H via cctalk wrote:

> Seems to be RS-232 compatible, which in my experience is unusual for a 
> terminal in the early half of the 1970s.  It has little serial number 
> stickers tucked around but they're all random numbers, nothing really lines 
> up.  A few of the boards have what appears to be serial numbers in the low 
> hundreds.
> 
> So tempting to just plug in and see what happens, but I'm concerned about the 
> voltages on two pins that seem off.

What does 'seem off' mean?

One possibility is they are a floating supply for the CRT heater. Not unusual 
in those days was just to have an independent 6.3 or 12.6 VAC secondary on the 
PS transformer dedicated to the heater and it often wouldn't be grounded. You 
could try checking between the two pins with multimeter ACV range.

This terminal (this specific unit) was mentioned on the list 2 years ago:

https://classiccmp.org/pipermail/cctalk/2021-February/thread.html#57808

2021-Feb-12
Mystery (unusual) 1973 terminal

Around a dozen messages. In one of those messages I list & ref some of the 
more-significant ICs from the board photos.




[cctalk] Re: Rainbow H7842 PSU Fault

2023-05-26 Thread Brent Hilpert via cctalk
On 2023-May-25, at 1:43 PM, Rob Jarratt via cctalk wrote:
> 
> This evening I went to check Vstart for any oscillation. However, all of a 
> sudden, the current draw is down to 85mA and PWM has started working. I am at 
> a loss to explain it. I wondered if there might be a dry joint, but I have 
> tried a few light taps and shakes and it continues to work. Perhaps your idea 
> of some debris causing a short might explain it, otherwise I just don't know.

Operation with only VStart+12 places the circuitry into an unspecified 
operating region - a region outside of the design intentions. In part, several 
semiconductor junctions and portions of circuitry are polarised opposite to 
their normal/designed-for state. It is not surprising that you are seeing 
odd/unpredictable behaviour under this operating environment, nor is it 
surprising that it's different than the 'good' supply under the same operating 
environment.

So why was it in shutdown earlier the other day but not now? :
Who knows - it's operating in an unspecified region. Perhaps the room 
temperature is 2 degrees higher. That's a serious point, not phase-of-the-moon 
satire.

When you supplied the proper startup environment with both Vstart+12 and 
Vstart-12 both the bad and good unit behaved as expected for the design.

Why is the VStart+12 current draw higher when it was in shutdown versus when 
the PWM controller IC is pulsing? :
Because in shutdown the 'Chopper Driver' transistor (PSU Sheet 2) is held hard 
ON (conducting) (see datasheet).
Holding this transistor ON subtracts it's off-state current (~ 17mA) but adds 
it's on-state base current (~ 37mA) and it's on-state collector current (~ 
73mA), for a net up-to ~ 93mA increase (may be less dependant on duty cycle of 
PWM), to the Vstart+12 current.

There remain two unexplained things here:
- Where was that unusual current-sense voltage that sends it into 
shutdown coming from?
(I provided one potential explanation earlier, but it remains unknown 
at this time).

- The 51-ohm current-sense resistor in the -12V supply vs the mode of 
operation of 
the -12 supply remains unexplained/non-sensical. At the max current you 
mentioned (150mA),
the V drop across that R would be >7V (!), which makes no sense. If I 
had it in hand, I'd be
double-checking the drawing of that current-sense circuit around the 
51-ohm R as a start.

But this is not to say that either of these has anything to do with the fault 
you were/are dealing with, they're just things that aren't understood at this 
point. Either or both could be pursued out of curiosity or for the sake of 
completeness.


> I am thinking I may put it back together and test with a light bulb in series.





[cctalk] Re: Continental 50 Pin connector vs. AMP 200276 50 pin connector - same?

2023-05-15 Thread Brent Hilpert via cctalk
> On 4/22/2023 6:14 PM, Jay Jaeger wrote:
>> I have an HP 2875B paper tape drive that I want to interface to.  It has a 
>> 50 pin block connector (using well under 1/2 the pins).  The connector 
>> manufacturer was Continental.
>> I have already discovered, the hard way, that it is not a winchester 
>> connector - the pins on the 50 pin Winchester connector I just obtained via 
>> ePay that otherwise fits are too small in diameter and won't make contact.  
>> I *could* increase their diameter using solder - but -- yuck.
>> The other connectors of this sort I am familiar with that have the same 
>> general overall size and pinout were made by AMP.  Does any one know if the 
>> AMP connectors and the Continental connectors would be compatible?

On 2023-May-13, at 6:54 PM, Jay Jaeger via cctalk wrote:
> Will reply in answer myself on this one:
> 
> Firstly the paper tape reader is an HP 2748B - sorry about that typo (blush).
> 
> Secondly the AMP connector I acquired was NOT compatible with the Continental 
> connector on the paper tape reader.  The pins on the AMP connector, while 
> larger than those on the Winchester connector, were still a shade too small 
> to make a reliable connection - the connector was clearly loose when mated.
> 
> Which brings up the question: does anyone have a spare cable or 50 pin male 
> Continental connector that I could purchase/trade for?


No spare connector, sorry.

If it's of any help though, on my 2748 connector (the cord-plug-in end) the 
male pin diameter is 0.061 ~ 0.062" (measured with a cheap micrometer, perhaps 
the actual spec is 1/16=0.0625).

I understand the confusion - I have on hand 3 different examples of ~0.062" 
dia. male pins. Cursorily they look the same and plug into the same female pin, 
but are different in length and in the shoulder-housing-insert area. Then there 
are similar-looking pins that are ~0.040" diameter, which may be what you 
acquired.

These kind of look like they might be the 0.062 diameter:

https://www.ebay.com/itm/115573632341

whereas these look like they could be the 0.040 diameter:

https://www.ebay.com/itm/115573630849

But then you have to watch out to be getting the correct type of pin for the 
housing one is using, for as stated above they can differ in that section of 
the pin even though of the same mating diameter.



[cctalk] Re: KIM-1 stuck bits from $280 to $29f

2023-05-11 Thread Brent Hilpert via cctalk
On 2023-May-11, at 7:41 PM, Cameron Kaiser via cctalk wrote:
> it's actually an artifact of the monitor that the upper 6 were clear. 
> Actually,
> the stuck bit is entirely bit 2 (i.e., it goes
> 
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 0 1 2 3 0 1 2 3 8 9 a b 8 9 a b
> 
> and the high nybble is OK). Now that sounds more like a bad RAM chip, but why
> would it be *just* those addresses? Does that sound like a plausible failure 
> mode?

So I take it the KIM1 uses 6102 1K*1 RAM chips.
(I'm seeing some modern redrawings, but is there no original schematic online?)

Any RAM chip internally has the bits organized in a matrix.
I haven't found a proper 6102 datasheet, but the most likely array size is 
obviously 32 * 32.
Your bad address range of xx80::xx9F is a span of 32 on base-32 boundaries.

So a failed internal driver or sense-amp for one row or column of one chip 
would produce your fault.
That's a pretty plausible failure mode.

Don't know how much luck you'll have finding a 6102.
Cursorily it looks like it's just a CMOS version of the 2102, and 
pin-compatible, so that might be an alternative.
The 2102 comes in low-power flavors (often but not always called 21L02).
It also comes in various speeds so you might have to watch that, something like 
a 21L02-3 might do.

[cctalk] Re: Altair 8800 question

2023-05-09 Thread Brent Hilpert via cctalk
On 2023-May-09, at 11:08 AM, W2HX via cctalk wrote:
> I see some altairs have a metal escutcheon on the bottom with the stylized 
> words "MITS ALTAIR 8800 COMPUTER" whereas others, the front panel is just the 
> dark faceplate top to bottom. What is the difference? Would one have been a 
> kit and the other sold fully assembled? Or maybe later units vs earlier units?


I'm currently working on restoration of an 8800. On this unit, as Jonathan 
mentioned, the strip is glued/stuck on and some could easily be getting lost 
over the years.

Might note also that the Altair on/in the Pop Electronics issue is physically 
vastly different than what shipped, it's not even the same case.

[cctalk] Re: Rainbow H7842 PSU Fault

2023-05-09 Thread Brent Hilpert via cctalk
On 2023-May-09, at 12:28 AM, Brent Hilpert via cctalk wrote:
> I thought I must be off somewhere by 10^n when first doing the calc. The 51Ω 
> is 3 orders of magnitude away from the 0.01Ω on the other outputs, so a 
> similar diff could be anticipated on the current sense.
> 
> The low current sense might be explained as follows:
> 
> ...

> I'm speculating the unusual shunt regulator in the -12V output is actually a 
> 'controlled freewheeling diode' for a -12V bucking step-down. The choke would 
> be stepping down the voltage from the -12 output secondary from something 
> higher down to the actual -12V output. With a higher V from the secondary, a 
> lower current is needed for the same energy throughput, and thus sense on a 
> lower max current from the secondary. However, one would anticipate the 
> regulation V sense point in such operation to be on the other side of the 
> choke than what's shown in the schematic.

Thinking further this morning. The TIP121 is the wrong orientation or polarity 
to be acting as a freewheeling conductor (--explanation). However, that's the 
transistor section. The 121 has a built-in flyback diode which is the right 
orientation (++explanation). Still some things that don't make sense though, 
like the high EI ratio needed from the order 100 I difference (--explanation), 
and how the load current would be supplied during the charge portion of the 
cycle (--explanation).



[cctalk] Re: Rainbow H7842 PSU Fault

2023-05-09 Thread Brent Hilpert via cctalk
On 2023-May-08, at 12:27 PM, Peter Coghlan via cctalk wrote:
> However, Brent's calculations show that the current trip value for the -12V
> line is as low as 1.3mA and I can't see any reason to disagree with his
> calculations or his conclusion that this seems very low (except that another
> tiny smidgen of current is available from the negative startup supply but
> this won't really have any bearing on things). If this is really the case,
> then placing something like a 5k6 resistor across the -12V line on the good
> PSU should cause enough current to flow for the trip to operate.  Finding
> this level of leakage in the failed PSU is not going to be easy.
> 
> On the other hand, if this test doesn't trip it, then please look very
> closely at the resistors and connections to the inputs of E3d and verify
> that they are as described on the circuit diagram.
> 
> It seems very strange indeed to have a trip value as low as 1.3mA combined
> with a shunt regulator whose method of regulation is to pull the voltage
> down by drawing current from the supply line.  Perhaps the shunt regulator
> might be able to pull enough current to cause the trip to operate if the
> -12V line was too high (in the negative sense) or if the shunt regulator
> was under the mistaken impression that the -12V line was too high?
> 
> (This is a bit unlikely but the 115V/230V switch is set correctly, isn't it?)
> 
> On the other other hand, if the manual says that the -12V line is supposed
> to be able to supply 150mA, then it doesn't make sense for the current trip
> to operate at 1.3mA and we must be going wrong somewhere.


I thought I must be off somewhere by 10^n when first doing the calc. The 51Ω is 
3 orders of magnitude away from the 0.01Ω on the other outputs, so a similar 
diff could be anticipated on the current sense.

The low current sense might be explained as follows:

This power supply does not follow the more-common design of flyback switching 
mains supplies.
This supply is actually 2 (or 3) bucking regulators being fed from a 
mains-isolation transformer, with the bucking regulation going to the PWM 
oscillator then looping back to the driver on the primary side of the 
mains-isolation transformer. This is discernible in the presence of the 
freewheeling diodes beside the rectifier diodes of the +5 & +12 outputs. DEC 
seemed to like doing this as the VaxMate supply from jarratt last year was of 
similar design. A guess is it may have made the inductor design easier, 
separating the flyback operation out to separated inductors rather than in the 
all in the same mains transformer.

I'm speculating the unusual shunt regulator in the -12V output is actually a 
'controlled freewheeling diode' for a -12V bucking step-down. The choke would 
be stepping down the voltage from the -12 output secondary from something 
higher down to the actual -12V output. With a higher V from the secondary, a 
lower current is needed for the same energy throughput, and thus sense on a 
lower max current from the secondary. However, one would anticipate the 
regulation V sense point in such operation to be on the other side of the choke 
than what's shown in the schematic.




[cctalk] Re: Rainbow H7842 PSU Fault

2023-05-09 Thread Brent Hilpert via cctalk
On 2023-May-08, at 11:24 PM, Rob Jarratt via cctalk wrote:
> 
> I am going to read your answer more carefully later. But I wanted to check 
> one thing. I measured the base-emitter voltage as negative in both cases, and 
> yet the TIP121 appears to be conducting on the bad PSU. Surely that means 
> that the TIP121 is not working correctly?

The TIP121 would/could be conducting because under your test setup with no 
VStart-12 it's biased in the reverse-from-normal direction and could be 
conducting in reverse through the BC junction. The 0.016V across the 10Ω R from 
C-to-GND is nonetheless higher than would be expected from the trickle current 
available.

Which brings me to this, in reply to earlier message:

On 2023-May-08, at 5:03 AM, Rob Jarratt wrote:
>> From: Brent Hilpert 
>> 
>> From earlier measurements and the 45uA calc of current through the 51Ω
>> sense resistor, the V across the 51Ω ISense-12 resistor should be only 
>> 0.002V.
>> 
>> So a question is where is this 0.08V coming from? An unfulfilled -12V supply
>> for the E3 power pin might have been an explanation, as extra current might
>> be drawn out of the E3d.+in input due to the +in being pulled below
>> (negative to) the
>> E3 -power pin. But you say that pin is connected to GND, so the source of the
>> 0.08V should be sought, some more comprehensive measurements around
>> the E3d inputs / ISenseR might help.
> 
> I thought I had answered where the Vcc and GND are connected on the 
> comparator. Vcc is connected to Vstart and GND to GND. ...

Yes, this was acknowledged. I was explaining how it might have been the source 
of the mystery 0.08V, so if/as it's not then here's another possibility:
 It's conceivable there is an oscillation being generated around this -12V 
output circuitry, perhaps by a bad semiconductor junction or because some of 
the junctions are operating in reverse to normal under the test setup in 
conjunction with the caps and inductors, the mystery voltage being generated in 
consequence. Have you poked around the -12V area with a scope, as opposed to 
multi-meter V measurements? 

[cctalk] Re: Rainbow H7842 PSU Fault

2023-05-07 Thread Brent Hilpert via cctalk
On 2023-May-07, at 1:54 AM, Rob Jarratt via cctalk wrote:
> The comments about the tolerance of the 7812 were right, it doesn’t appear to 
> be an issue with the replacement 7812 regulator because when I tried using 
> the bench PSU to feed exactly 12V to the circuit from the output of the 7812 
> the comparator still gave the wrong result. It was still wrong if I applied 
> only 11V
> 
> I then looked at the value of Vz on the good and bad PSUs, when applying 12V 
> to the 7812 output. That was 5.4V in both the good and bad PSUs. Where I saw 
> a difference was on the -12V output, it was +0.4V on the good PSU and 0.56V 
> on the bad one (the voltage varied so this was an average). I checked the 
> voltage drop across the current sense resistor. It is 0.01V on the good PSU 
> and 0.08V on the bad PSU, which would explain the higher positive voltage on 
> the -12V output and the comparator being turned on.


From earlier measurements and the 45uA calc of current through the 51Ω sense 
resistor, the V across the 51Ω ISense-12 resistor should be only 0.002V.

So a question is where is this 0.08V coming from? An unfulfilled -12V supply 
for the E3 power pin might have been an explanation, as extra current might be 
drawn out of the E3d.+in input due to the +in being pulled below (negative to) 
the 
E3 -power pin. But you say that pin is connected to GND, so the source of the 
0.08V should be sought, some more comprehensive measurements around the E3d 
inputs / ISenseR might help.

From calculations from design/schematic:
  - E3d.+in should = 1/2 the voltage across the 51Ω ISense-12 resistor.
  - E3d.-in should = 0.033 V.
  - The trip condition to send the E3d output high (shutdown) is: V(ISR-12) > 
0.066V  (V across ISense-12 Resistor).

Also: Is that ISense-12 resistor really a 51Ω resistor? Or is it 5.1Ω or 0.51Ω? 
Again from calculation, 51Ω would imply a current limit of only 1.3mA, which is 
rather low.



[cctalk] Re: Rainbow H7842 PSU Fault

2023-05-01 Thread Brent Hilpert via cctalk
On 2023-May-01, at 2:25 AM, Peter Coghlan via cctalk wrote:
> It seems a bit odd that a power supply from someone like DEC of that era would
> be designed to depend so critically on the absolute value of a rail used
> for startup purposes.

Further to Peter's point above, the 1988 NatSemi databook - which is to say, 
from the era of this power supply - specs the 7812 output min-max to be 11.4 to 
12.6V (+/-5%). Your measured Vstart=12.4V is well within this.
Looking at the schematic, nothing stands out where the distinction from 12 or 
12.1 would matter.

You still haven't reported the IC power pin connections. If the neg-supply pins 
are supplied by -12 rather than GND, it could explain the odd voltage seen on 
the E3d +input.

There are 3 explicit components in the design which provide -12V at startup. 
They didn't throw those components in there just to fill up board space and 
look pretty. Why would you expect the control circuit to be testable for valid 
startup state when you haven't provided the startup environment?



[cctalk] Re: Rainbow H7842 PSU Fault

2023-04-23 Thread Brent Hilpert via cctalk
On 2023-Apr-23, at 8:04 AM, Peter Coghlan via cctalk wrote:
...
>  This should result in a current
> of about 45 microamps flowing to ground through those components mentioned.

...
> It ought to be possible to measure the same 0.6V across the diode to confirm
> this is where it is being dropped (and to measure the remaining 3.4V of the
> 4V at E1b across the 75k resistor).  As to why it is only 0.4V on the working
> power supply, I haven't thought that far ahead yet :-)

The 0.4V across the working-supply diode in contrast to 0.6V is because the 
current is way down in the microAmps. This is well on the low side of the curvy 
knee of typical Si diode switching, so lower voltage drop and high 
per-component in-circuit variability are not a surprise.


> I think the +0.6V on the -12V line is explainable and to be expected under the
> test conditions described.  It looks like there could be something wrong in
> the control circuitry which is preventing the power supply from starting up.
> This might also account for the difference between the 0.4V and 0.6V.
> 
> Brent's suggestions for checking the condition around the comparators and how
> they are supplied with power are good ones.  I haven't made any further
> suggestions because I don't have any right now :-)


In addition to the IC power pins:

The voltage value of Vz (V of zener by 390 ohm R) is not presented in the 
schematic.
Calculating from the measurement of 4V suggests it will be ~ 5V.
It tends to be helpful if the voltages of zener diodes are presented in a 
schematic.

Also note:

The ISense+/Isense- labeling in the schematic is the reverse of the polarities 
which will actually be present/expected on those lines (for all three outputs). 
That is, the lines labeled ISense- will be more + than the lines labeled 
ISense+ under normal operation as well as at times of over-current shutdown.





[cctalk] Re: Rainbow H7842 PSU Fault

2023-04-22 Thread Brent Hilpert via cctalk
On 2023-Apr-22, at 3:53 PM, Peter Coghlan via cctalk wrote:
   On 2023-Apr-22, at 1:07 AM, Rob Jarratt via cctalk wrote:
>> This seems to be because I measure a steady 0.6V on pin 6 of the transformer
>> (p4, PSU Sheet 3). I just can't imagine where it might be coming from as the
>> chopper won't be running. I had previously removed the transformer and there
>> are no shorts between the pin 5-pin 6 winding and any of the other pins on
>> the transformer. I checked all the DC outputs of the PSU when powering the
>> 7812 from the bench, both on a working PSU and the non-working one. They are
>> all at zero except the -12V output on the non-working PSU, which is +0.6V.
>> But the voltage can't come out of nowhere.
> 
> I've looked at it some more.  On page 5 (control module sheet 1), at the
> non-inverting input of E1b, there is a 75k resistor and 16k9 I think?
> resistor between -12V and V2 which is derived from Vstart.  Perhaps this
> would account for the +0.6V?
> 
> (Ignore what I said earlier about the possibility of one of the two diodes
> connected to pin 6 of the transformer being shorted.  The 51 Ohm (or is it a
> 5 Ohm?) resistor across one of them would look like a short compared to 75k.)


Following on Peter's observation above, note that under normal (as opposed to 
test-bench) operation, a limited -12V is supplied at startup by the same little 
mains transformer that supplies VStart (schematic: PSU sheet 1). 

This startup -12V would appear to be or may be required to bias things 
correctly for startup to proceed. 
It follows that the -12V current-sense shutdown being observed is not 
(necessarily) part of the fault being looked for, but just a consequence of the 
absence of the -12V startup.

Also, minor note: not indicated on the schematic is the power supply pin 
connections for the comparator ICs (E1,2,3) (or I haven't spotted them). 
Presumably the +supply is VStart, but you might check and record whether the 
-supply is GND or is it -12V (and check all 3 ICs).



[cctalk] Re: IBM PC/XT and NEC "gold" tam

2023-01-21 Thread Brent Hilpert via cctalk
On 2023-Jan-21, at 10:14 AM, Chris via cctalk wrote:

> And if your lids aren't gold plated, is the lid aluminum or some related 
> alloy?  


Tin-plate on copper would be likely, easy to solder-seal on. Al would not 
solder on easily.

Tin does make a nice plating. Even HP made some lab/computing equipment in the 
60/70s with tin-plate (not solder 'tinned') PCBs including the edge-connector 
fingers, even though that is the era they were known for full-gold-plate PCBs.



[cctalk] 2102s and other chips / was Re: IBM PC/XT and NEC "gold" tam

2023-01-21 Thread Brent Hilpert via cctalk
On 2023-Jan-21, at 11:25 AM, Mike Stein via cctalk wrote:

> Finally, some Burroughs memory boards containing what I think are 2102s,
> but I'd have to investigate.

Soldered or socketed?

I'm on the lookout for 16 (or more to have some spares) 2102s to populate an 
EconoRAM S100 memory board to go in an Altair. Proviso being they have to be 
'fast enough' (<=450nS, not sure whether 650 would be OK or not).

...
> Speaking of gold-plated chips, I'm finally scrapping the last remnants of a
> Redactron mag card word processor; the main board has some house numbered
> white ceramic chips with the usual gold pins and lids (24, 40, 16 pins).

(Could probably figure out many of them with some rev-eng'ing to get their 
pinout.)



Re: Replacement for a DEC 7474 Chip

2022-05-16 Thread Brent Hilpert via cctalk
On 2022-May-15, at 3:53 PM, Eric Smith wrote:
> On Sun, May 15, 2022, 13:03 Brent Hilpert via cctalk  
> wrote:
> On 2022-May-15, at 1:16 AM, Eric Smith via cctalk wrote:
> > On Sat, May 14, 2022, 16:09 ben via cctalk  wrote:
> >> On 2022-05-14 11:50 a.m., Nigel Johnson Ham via cctalk wrote:
> >>> AFAIR LS can only drive one unit TTL load.
> >>>>paul
> >> LS is 4 TTL, 4 ma low.
> >> Was there a trick of forcing the output of D flip flip
> >> to clear it? I was wondering if this is what kills all
> >> the 7474's?
> > 
> > I don't think that worked on any TTL (or CMOS) 74x74 flip flops, except
> > maybe by accident if you shorted the output enough to draw Vcc down (or
> > ground up) enough to disrupt the FF, and then you have other problems.
> > 
> > Despite the logic diagram showing feedback from the outputs, all 74x74 have
> > buffered outputs.
> 
> Per TI schematics from 1969: 74 standard, H and L series flip-flops are 
> unbuffered. Or at least many of them are/were, in their then-original form. 
> Including 7475, 7490, etc. The output transistors connect both to the pins 
> and wrap back to form the FF or other purposes.
> 
> Collector-triggering was discussed a some years ago on the list in regards to 
> a pdp8 front panel where DEC used collector-triggering on 74175's (IMO, bad 
> design practice). From (my) empirical tests at the time, it turned out some 
> 74S (Schottky) parts could be collector-triggered. However, between standard, 
> LS, and S types, behaviour could vary with manufacturer and production date.
> 
> 
> > The recent TI data sheets show an equivalent schematic
> > only for the 74LS74. I can't at the moment find one for the 7474.
> 
> > It seems likely to me that early pre-TTL logic families like RTL might have
> > had FFs with unbuffered outputs, but I haven't checked.

> I specifically said 74x74. Early TTL flipflops were very crude by comparison.


S = { "", "L", "H", "S", "LS", "F", "AS", "ALS", "AC", "ABT", etc. }

x ∈ S

"", "L", "H", "S" ∈ S

"L", "H", "S" != ""

7474: x == ""

pre-TTL != early TTL



Re: Replacement for a DEC 7474 Chip

2022-05-15 Thread Brent Hilpert via cctalk
On 2022-May-15, at 1:16 AM, Eric Smith via cctalk wrote:
> On Sat, May 14, 2022, 16:09 ben via cctalk  wrote:
>> On 2022-05-14 11:50 a.m., Nigel Johnson Ham via cctalk wrote:
>>> AFAIR LS can only drive one unit TTL load.
paul
>> LS is 4 TTL, 4 ma low.
>> Was there a trick of forcing the output of D flip flip
>> to clear it? I was wondering if this is what kills all
>> the 7474's?
> 
> I don't think that worked on any TTL (or CMOS) 74x74 flip flops, except
> maybe by accident if you shorted the output enough to draw Vcc down (or
> ground up) enough to disrupt the FF, and then you have other problems.
> 
> Despite the logic diagram showing feedback from the outputs, all 74x74 have
> buffered outputs.

Per TI schematics from 1969: 74 standard, H and L series flip-flops are 
unbuffered. Or at least many of them are/were, in their then-original form. 
Including 7475, 7490, etc. The output transistors connect both to the pins and 
wrap back to form the FF or other purposes.

Collector-triggering was discussed a some years ago on the list in regards to a 
pdp8 front panel where DEC used collector-triggering on 74175's (IMO, bad 
design practice). From (my) empirical tests at the time, it turned out some 74S 
(Schottky) parts could be collector-triggered. However, between standard, LS, 
and S types, behaviour could vary with manufacturer and production date.


> The recent TI data sheets show an equivalent schematic
> only for the 74LS74. I can't at the moment find one for the 7474.

> It seems likely to me that early pre-TTL logic families like RTL might have
> had FFs with unbuffered outputs, but I haven't checked.



Re: Core memory

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Apr-01, at 11:51 AM, Paul Koning wrote:
>> On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk  
>> wrote:
>> On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote:
>> 
>>> When I looked at that ebay listing of "glass memory" it pointed me to 
>>> another item,https://www.ebay.com/itm/265623663142 -- described as "core 
>>> rope memory".  Obviously it isn't -- it's conventional core RAM.  
>>> Interestingly enough, it seems to be three-wire memory (no inhibit line 
>>> that I can see).  It looks to be in decent shape.  No manufacturer marks, 
>>> and "GC-6" doesn't ring any bells.
>> 
>> Well, it would still work for 1-bit-wide words, so to speak. One wonders 
>> what the application was.
> 
> I wonder if the sense wire was used as inhibit during write cycles -- that 
> seems doable.  It would make the core plane simpler at the expense of more 
> complex electronics.  With that approach, you have regular memory, not 
> limited to 1 bit words.

Maybe I'm being overly cautious, but offhand I'm initially skeptical without 
doing the math or some good vector diagrams, or seeing an example. With the 
diagonal wire you're changing the current/magnetic sum vectors in direction and 
magnitude. The question is coming up with a current that reliably performs the 
cancellation function on the selected core of a bit-array while reliably *not* 
selecting another core, while accounting for all the variation tolerances in 
the array. 

While there's probably some value by which it would work in theory, I wonder 
whether the diagonal wire would narrow the operating margins. From some stuff 
I've seen, the hysteresis curves for cores weren't spectacularly square. With 
the usual 3D-3wire scheme of a close parallel inhibit wire you have 
'cancellation by simplicity', you maximise the difference (cancellation) 
influence on one wire while minimising it's sum influence on the other.

A related issue is the normal diagonal sense stringing (which this looks to 
have) has the wire entering the cores from both directions relative to the 
address wires, which is why sense amplifiers respond to pulses of both 
polarity. If this diagonal wire is put to use as an inhibit wire, some logic is 
needed to decide the direction of the inhibit current from the address, though 
that may not be very difficult.

Some history of the 3-wire development might tell, whether inhibit was first 
applied to a diagonal sense stringing or whether sense was first applied to an 
adapted parallel-inhibit stringing. The real benefit of the 3-wire development 
was getting rid of the diagonal stringing for manufacturing ease.


>> There are a couple of Soviet core-rope memories up right now:
>>  https://www.ebay.com/itm/294558261336
>>  https://www.ebay.com/itm/294851032351
> 
> Neat looking stuff.  It doesn't look like core rope memory in the sense of 
> the AGC ROM, nor in the sense of the Electrologica X1.  It looks more like 
> the transformer memory used in Wang calculators that you documented in your 
> core ROM paper.

Yes, (I was, perhaps lazily, slipping into the habit of referring to both forms 
(of woven-wire ROM) as rope).


Re: Core memory

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote:

> When I looked at that ebay listing of "glass memory" it pointed me to another 
> item, https://www.ebay.com/itm/265623663142 -- described as "core rope 
> memory".  Obviously it isn't -- it's conventional core RAM.  Interestingly 
> enough, it seems to be three-wire memory (no inhibit line that I can see).  
> It looks to be in decent shape.  No manufacturer marks, and "GC-6" doesn't 
> ring any bells.


Well, it would still work for 1-bit-wide words, so to speak. One wonders what 
the application was.

There are a couple of Soviet core-rope memories up right now:
https://www.ebay.com/itm/294558261336
https://www.ebay.com/itm/294851032351
Shipping from New York, curiously.

The glass memory has apparently sold.

Re: Glass memory?

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Apr-01, at 10:52 AM, Chuck Guzis via cctalk wrote:
> On 4/1/22 10:27, Paul Koning wrote:
>> 
>>> On Apr 1, 2022, at 1:25 PM, Chuck Guzis via cctalk  
>>> wrote:
>>> 
>>> Wasn't some of this glass delay line memory used in early raster-scanned
>>> computer video displays?
>> 
>> I don't know about that one, but a delay line is a key component of a PAL 
>> (European) system color TV receiver.
> 
> I know that the CRT display controller on the CDC 200 series terminal
> (INTERCOM, Export/Import 200 software) used a 10 msec magnetostrictive
> delay line.for image storage.Glass would seem to be a more
> mechanically robust storage medium.
> 
> See:page 1-5
> http://bitsavers.org/pdf/cdc/terminal/82128000_200_User_Terminal_Hardware_Reference_Jul68.pdf
> 
> Later raster terminals used MOS shift register memory.
> 
> The STAR-100 stations used a track on the station microdrum for video
> refresh.



CRT monitors would seem like a likely target application for them.

Their higher speed may have worked to advantage to reduce the total memory 
requirement. The MOS-shif-register-memory displays typically had two R/W 
memories: a frame buffer and a character-line buffer, the line buffer captured 
one line of characters from the frame buffer as it cycled by, so it could be 
rescanned several times for the multiple H-scan lines forming a character. The 
higher speed of the glass memories perhaps would have eliminated the need for 
the line buffer.

Re: Glass memory?

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Apr-01, at 5:54 AM, Paul Koning via cctalk wrote:
>> On Apr 1, 2022, at 2:56 AM, Mark Huffstutter via cctalk 
>>  wrote:
>> 
>> https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185
> ...
> That Corning document is also interesting because of its comparison of memory 
> technologies it shows.  Tunnel diode memories?  Hm.  And cryogenic, in 1962?  
> Hm again.



Are you alluding to a question of actual use in a practical large-scale 
implementation?

Tunnel diodes did work as storage (state-holding elements), at least on a small 
scale. I have a frequency counter that uses a 5-stage tunnel-diode counter for 
the first high-speed counting stage. That is the most tunnel diodes I've seen 
in use in one place.

As two-terminal negative-resistance devices, I wonder if there were some design 
attempts to put them in a matrix, something along the lines of providing the 
matrix axes in whole with a 'holding current' to retain state, along with 2D 
addressed R/W.

Cryotrons I only know of from reading the period 'laboratory announcements', 
don't know how far they got in any practical use.

Re: PDP 11/24 - A Step Backwards

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 7:44 PM, Noel Chiappa wrote:
>> From: Brent Hilpert
>> DCLO & ACLO behave as power-on-reset signals to the system.
> 
> Minor nit: actually, I think it's DCLO which performs that function in a lot
> of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT,
> usually in buffered form, is used more widely for this function, but I doubly
> digress in that observation.)
> 
> As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU
> operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC 
> P/S's
> carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted
> first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first
> (the later de-assertion of ACLO is the signal for the CPU to start running).

a) "ACLO is only used to trigger a 'power-failing' interrupt"
b) "ACLO is the signal for the CPU to start running"
Only a, or a & b?

You know more about the overall/macro system function of these signals than I 
do, for current purposes I'm just looking at the electrical 
behaviour/requirements for the signals and the particulars of this environment. 
My point is that ACLO (and DCLO) are to remain in the same state as they are 
when power is off, until the power supplies are ready. Or at least the power 
supply design suggests (and enacts) such by intention.

- Suppose ACLO were allowed to waffle high during power-up but then asserted 
low before CPU enable. That could trigger PF logic unless the PF logic has been 
designed to deal with it. Things could be designed to allow ACLO to waffle high 
as long as it's stable low (asserted) by the time DCLO goes high (deasserted) - 
maybe they are - but one would want to know that.

- If bus-ACLO is left open to float high with power up, you have a slow edge 
feeding into FF (E67/K2_PFAIL) and thence to monostables (E126/K6). There are 
rise-time requirements for FF clock-edges, they can be unpredictable with slow 
edges (that's what Schmitt triggers are for). There's a gate there (E70) that 
may provide enough gain to adequately take care of the slow edge, I don't know 
what the specs on those bus receivers are.

Now these things may well not be a problem here; I'm just looking for potential 
failure points because we're looking for an unknown fault by isolating things, 
and it's best done without introducing new potential problems, or at least 
being aware of the potential.


> However, you make a good point with:
> 
>> If they are allowed to just float up as the power supply comes up you
>> have no guarantees as to the end result ('end' meaning the state of
>> things after the power supply has come up)
> 
> DEC specs state that DC power has to be up and stable 5 usec before DCLO can
> be de-asserted ("pdp bus handbook", pg 53). This is precisly so that
> everything is in a known state when operation commences.
> 
> So I guess I'll go back to my original suggestion: disconnect the ACLO from
> the P/S (with its bogus -15V), leaving DCLO, so that it can properly set
> everything to a known state on power-on, and then you can see see if E70 has
> been fried, or is still working.
> 
> 
>> Manually connecting/disconnecting bus-ACLO to GND after power-up will
>> ... disable the clock.
> 
> I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF),
> where all the clocks are generated, that looks at ACLO, or its inverted form
> POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner
> of K2)? Did I miss something? All I can see is DCLO.

ACLO exercises influence over DCLO and hence the CPU clock via those those 
monostables (we both) mentioned earlier.

ACLO -edge:
==> inverted (E70.2/K2) to +edge
==> triggers FF (E67/K2_PFAIL) to latch high
==> triggers MonoFF (E126/K6_AC_TIM)
==> triggers MonoFF (E126.10-5/K6)
==> asserting K6_BUF_DCLO_L for some period
==> which disables MCLK counter (E41/K1)

I haven't analysed things further in full to say what happens after that, 
whether the clock is stopped for good or just temporarily, just that there is a 
path of influence from ACLO (-edge) in there. It may be that it just stops the 
clock temporarily: DCLO asserted resets E67/K2_PFAIL, clearing it to register 
another ACLO / P FAIL.


> I'm too burned out right now to check for uses of ACLO/POWER-OK/PFAIL, to see
> definitively what it does do; tomorrow.

Given Rob's message about alterations on the CPU board regarding ACLO - 
although it's not clear what those alterations are - I thinks he's right to 
poke around the clock circuitry looking for where the clock is being inhibited.



Re: Glass memory?

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote:
> Hey all, found this on eBay:
> 
> https://www.ebay.com/itm/Corning-Glass-memory-/125087612899
> 
> I can't find any info on it - was it some kind of delay-line or magnetic
> laminate stack?
> 
> Interesting!


Very interesting - there were glass/quartz delay lines used in TV but never 
seen such before for digital.

So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but 
wondered how the path would be long enough for delays needed (path too short 
for waves too fast).

Second guess then could be a quartz internal reflection delay line. See pdfPg.9:


https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf

I've analysed a couple of magneto-strictive wire acoustic delay lines so have 
some feel for properties/numbers there, but don't know how glass/quartz 
compares.



Re: Glass memory?

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 11:56 PM, Mark Huffstutter via cctalk wrote:
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent 
> Hilpert via cctalk
> Sent: Thursday, March 31, 2022 11:53 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: Glass memory?
> 
> On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote:
>> Hey all, found this on eBay:
>> 
>> https://www.ebay.com/itm/Corning-Glass-memory-/125087612899
>> 
>> I can't find any info on it - was it some kind of delay-line or magnetic
>> laminate stack?
>> 
>> Interesting!
> 
> 
> Very interesting - there were glass/quartz delay lines used in TV but never 
> seen such before for digital.
> 
> So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but 
> wondered how the path would be long enough for delays needed (path too short 
> for waves too fast).
> 
> Second guess then could be a quartz internal reflection delay line. See 
> pdfPg.9:
> 
>   
> https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf
> 
> The period is right, those Sylvania ICs in the unit place it in mid-late 60s.
> 
> I've analysed a couple of magneto-strictive wire acoustic delay lines so have 
> some feel for properties/numbers there, but don't know how glass/quartz 
> compares.




> Here is some pretty good information.
> 
> https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185
> 
> Mark


Great document!  Yup, internal reflection.



Re: Glass memory?

2022-04-01 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote:
> Hey all, found this on eBay:
> 
> https://www.ebay.com/itm/Corning-Glass-memory-/125087612899
> 
> I can't find any info on it - was it some kind of delay-line or magnetic
> laminate stack?
> 
> Interesting!



Very interesting - there were glass/quartz delay lines used in TV but never 
seen such before for digital.

So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but 
wondered how the path would be long enough for delays needed (path too short 
for waves too fast).

Second guess then could be a quartz internal reflection delay line. See pdfPg.9:


https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf

The period is right, those Sylvania ICs in the unit place it in mid-late 60s.

I've analysed a couple of magneto-strictive wire acoustic delay lines so have 
some feel for properties/numbers there, but don't know how glass/quartz 
compares.


Re: PDP 11/24 - A Step Backwards

2022-03-31 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 4:12 PM, Noel Chiappa wrote:
>> From: Brent Hilpert
> 
>> So apparently I've been looking at the wrong +5V supply (H777) because
>> the rest of you are indeed looking at a different +5 supply (H7140),
>> both of which are in that same 11/24 pdf document
> 
> That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140
> is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably,
> covered in the -11/24 print set.
> 
>> I really wish when people are asking for assistance or talking about a
>> schematic or circuit they would include a link/reference to exactly
>> what they are looking at
> 
> But everone probably _was_ looking at the same document - just different
> pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the
> print set' identifier.

> Still, one could say 'page xx of the PDF'.

Which is what I do in these sorts of discussions, at least if it has not been 
specified previously, and especially when dealing with larger docs. E.g. from 
my previous messages in this thread:

ref: pdfPg.152,etc of 
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf

pdfPg.30 of 
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf

(The latter being the page for the H777 I was mistakenly looking at.)

Makes it easier for a recipient, everyone following, and yourself if you have 
to go back to it in the course of subsequent discussion.

Re: PDP 11/24 - A Step Backwards

2022-03-31 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 2:14 PM, Rob Jarratt wrote:
>> Those three comparators in the H777 are looking at a time-delay ramp
> 
> Is that a typo? This is the H7140 not the H777.

Groan.

When this thread came up I went looking for the 11/24 schematic. I found the 
document I linked earlier for the 11/24 and found 'the' +5 power supply. So 
apparently I've been looking at the wrong +5V supply (H777) because the rest of 
you are indeed looking at a different +5 supply (H7140), both of which are in 
that same 11/24 pdf document.

And indeed, the ACLO control is Q15 in the H7140.

I really wish when people are asking for assistance or talking about a 
schematic or circuit they would include a link/reference to exactly what they 
are looking at (a) so the reader doesn't have to go scratching around to find 
it and (b) to avoid effort-wasting screw-ups like this.

So yes, you can ignore a lot of the details I described, though some of the 
principals I mentioned are still valid.



Re: PDP 11/24 - A Step Backwards

2022-03-31 Thread Brent Hilpert via cctalk
On 2022-Mar-31, at 12:36 AM, Noel Chiappa via cctalk wrote:
>> From: Tony Duell
> 
>> A short in FET Q15 on the bias/interface board in the PSU could do it.
>> The gate of that FET is driven from an LM339 comparator the -ve supply
>> of which is -15V.
> 
> Ah; I hadn't even looked at the P/S prints.
> 
> (Like I said, I'm really weak on analog: for digital, I have the advantages
> that i) although I'm basically/mostly a software person, the MIT CS
> department is part of the EE department, and they made sure that all the CS
> people had a decent grounding in the fundamentals of digital hardware; and
> ii) in my early years, I was involved in a number of actual hardware
> projects, including a UNIBUS DMA network interface that tuned into an actual
> product. So I'm pretty good with a digital circuit diagram, like these CPU
> prints. But analog stuff is still a mostly-closed book to me! :-)
> 
> Anyway, I'm happy to let you provide the analysis of the P/S... :-)
> 
>> From: Rob Jarratt
>> [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
>> did).
> 
> I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU
> card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the
> 1K pF cap there (the purpose of which I still don't understand, unless it's
> just a smoother). Although I suppose that if that cap failed, shorted, maybe
> that could have taken out Q15 somehow.

Note: It's Q14 that controls ACLO, not Q15, Q15 is involved in the +5 startup. 
Unless there are two versions of the schematic and I'm looking at a different 
one than everyone else.

pdfPg.30 of 
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf


>> Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on
>> the same connector
> 
> Now why didn't I think of just un-plugging that whole connector! Du! My
> only concern would be leaving inputs floating...
> 
> DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering
> input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm
> too lazy to work out what leaving that input floating will do, and, if it has
> bad consequences, trace out all the places it goes (it should be connected up
> to cause an interrupt, somewhere), but there's no point; the KW11 has an
> 'interrupt enable' that has to be set by software before it can do anything;
> so at the moment it's safe to just ignore it for now, and stay with a focus on
> getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no
> pull-up on the M9302 for it the way there is for ACLO & DCLO.)
> 
> So unplug that connector, and see if E70 (on K2, lower right corner) is OK.
> (Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.)
> If yes, great, go check the main CPU clock.

Removing DCLO and ACLO from the PS to the bus may allow the CPU/clock to work. 
Or it may not.

DCLO & ACLO behave as power-on-reset signals to the system. If they are allowed 
to just float up as the power supply comes up you have no guarantees as to the 
end result ('end' meaning the state of things after the power supply has come 
up), without doing an analysis of the pertinent logic under their control.

JFETs are being used as the ACLO/DCLO control devices for a reason. In contrast 
to bipolars, the normal/no-gate-voltage state of a JFET is Source-Drain 
conducting, thus the initial state at power-up of ACLO-L & DCLO-L will be 
0V/low-impedance-to-GND. The point is to maintain that state until the power 
supply levels are good so the logic can be forced into a known state.

Those three comparators in the H777 are looking at a time-delay ramp generated 
by C14 and the constant-current circuit of Q11.
What is supposed to happen:
- everything is initially 0V: V+5, ACLO, DCLO.
- power is switched on. Internal voltage levels begin to rise. 
- after some delay, E4 trips first to start the +5 supply.
- after some more delay, E5 trips, de-asserting DCLO (DCLO = High,+V).
- after some more delay, E6 trips, de-asserting ACLO (ACLO = High,+V).

The delays are presumably of some order of mS.

-15V is the expected level from the E6 comparator output if AC is good. A 
Gate-Drain short in Q14 would be allowing that out to the bus. JFETs can be 
flaky, a failed JFET wouldn't be a big surprise.

So E6.6 = Q14.G = -15V is expected after power-up but an additional concern 
would be that a G-D short allowed excessive current from the bus through the E6 
comparator output and damaged E6, or if left on too long burned out pull-up 
resistors on the CPU or bus terminator. However the LM301 is supposed to have 
current limiting so those things may not have been damaged.

The scope could be used to observe what is going on with the +5, DCLO, ACLO 
sequencing at power up (with bus pull-ups, but without CPU).

Removing only the ACLO PS-to-bus connection would allow DCLO to still 

Re: PDP 11/24 - A Step Backwards

2022-03-28 Thread Brent Hilpert via cctalk
On 2022-Mar-28, at 4:07 PM, Noel Chiappa via cctalk wrote:
>> I don't think the CPU is working at all. The reason being that there is
>> absolutely no LED activity. Including an LED that is supposed to indicate
>> a clock.
> 
> Looking at the KDF11-U prints, I finally found that LED (it's pretty low
> level - I was worried that it might be a bit in a register, and driven by
> software, but it's not, it's actually driven directly by the the CPU's
> internal clock signal; it's on page K1 of the prints, 'Clock, State Decode',
> in the very upper left corner). (The source of the CPU's internal clock is
> just an RC circuit, in the lower middle of that page, and the trim pot that's
> part of it - along the upper edge of the board - can be adjusted to set the
> clock speed 'properly', per the note at the back of the prints on the page
> which lists the configuration switches. The 2MHz crystal along the upper edge
> drives the baud rate generator.)

But the LED and CPU clock are not driven directly by that RC oscillator - 
there's a bunch of logic in-between the oscillator and the LED / CPU clock.

[RC clock] => K1 OSC H/L
--> [4-bit counter w parallel load] => K1 MCLK H/L
--> LED
--> [driver] => K1 CHIP CLK H (fonz CPU clock)

The 4-bit counter looks to be generating some additional phases, but it's also 
controlled by a bunch of other signals.
One of those signals is K6 BUF DCLO L which can hold the counter in reset, i.e. 
disable the Master/CPU clock (and LED).
K6 BUF DCLO L is derived on-board from K2 P FAIL H, which is derived from K2 
BUS ACLO L which is input from BF1-in-funky-hex-box which I presume is a bus 
connector pin.

Tony mentioned checking ACLO.
Even if ACLO is good, there's a whack of logic on the CPU board - including two 
monostables - just to get from ACLO to DCLO to enable the CPU clock, as well as 
those other signals controlling the phase counter.

ref: pdfPg.152,etc of 
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf



Re: IBM 5110 (5100) schematics ?

2022-03-18 Thread Brent Hilpert via cctalk
On 2022-Mar-18, at 1:31 AM, Christian Corti via cctalk wrote:
> On Thu, 17 Mar 2022, Brent Hilpert wrote:
>> Does anyone have or know whether the schematics for the IBM 5110 or 5100 are 
>> available?
> 
> No, there are no schematics, only block diagrams. I had created the 
> schematics for the Async/Serial I/O card years ago (it's a TTL only board)
> 
>> And the tightly related question of whether anyone has done ROM (ROS) dumps?
> 
> Yes. I've described the procedure a couple of times in the past ;-)
> And FYI, I have also written a 5110 emulator. And I also have reverse 
> engineered the opcodes (at a time where the 5100 MIM was not available 
> online).
> Everything (ROS listings, dumps, emulator etc) is on our FTP server as usual. 
> You'll also find my Kermit program and Infocom interpreter there, both 
> written in PALM assembler.


Thanks, found the directories and disassembly files, I'll forward this on.



Re: IBM 5110 (5100)

2022-03-17 Thread Brent Hilpert via cctalk
On 2022-Mar-17, at 8:56 PM, D. Resor wrote:
> It looks as if it needs at least a replacement CRT.  From one image it
> appears to be phosphor is blown away in the middle screen. The only way I
> know of this happening, is the neck of the CRT, or the evacuation nipple has
> been cracked/broken.

Thanks for pointing that out, I hadn't looked closely enough previously to note 
it.

... there's a 5" CRT monitor from some 70's-era Olivetti machine in my junk 
box, though it's hard to tell whether it may be a different aspect ratio ...

Re: IBM 5110 (5100)

2022-03-17 Thread Brent Hilpert via cctalk
On 2022-Mar-17, at 9:09 PM, Guy Sotomayor via cctalk wrote:
> But it has APL (you can tell by the keyboard *and* the BASIC/APL switch).
> 
> I can't say if the price is worth it for that...but having the APL ROS and 
> the keytops has some value.



Yes, that is the particular interest in this unit by my friend.

Do you have any tech knowledge of these models? Was the ROS mask-programmed 
ROMS? standard types or IBM special?
I saw a web page or two with failed units that claimed the fault was the ROS 
but have no idea from what analysis they believe it to be the ROS.



Re: IBM 5110 (5100)

2022-03-17 Thread Brent Hilpert via cctalk
On 2022-Mar-17, at 5:02 PM, D. Resor via cctalk wrote:
> Was the computer auction in question a 5100 or a 5110?
> 
> Presently I see there is a 5110-C for sale
> https://www.ebay.com/itm/294865912729 

Yes, that was/is the one. So it has been relisted. It had been listed as a 5100 
or 5100-C earlier, then delisted, and I couldn't find a new listing for 
anything like a 5100 or 5110 this morning.

It might be easy to fix. Or it might have the computing potential of a doorstop.


> There were also a 5110 with 8" external drives and a printer which sold:
> https://www.ebay.com/itm/304377532685



IBM 5110 (5100) schematics ?

2022-03-17 Thread Brent Hilpert via cctalk
Does anyone have or know whether the schematics for the IBM 5110 or 5100 are 
available?
And the tightly related question of whether anyone has done ROM (ROS) dumps?

There are some service manuals on bitsavers, they are field-service board-level 
manuals, mostly step-by-step problem resolution guides, no schematics.

As a system, it's small enough to be reverse-engineered, in that regard it's 
tractable. However, it's implemented using IBM's mid-70s PCB and IC technology, 
increasing an RE effort by a couple orders of magnitude if not approaching 
impossible, unless one were to develop some robotic probing system and software.

There was a 5110 on ebay, non-working, that a friend had some interest in. It 
was quite a gamble at the price, in the absence of real tech info. ... 
Apparently it's been delisted, so my question is just curiousity at this point.



Re: Information about an unknown IC

2022-02-24 Thread Brent Hilpert via cctalk
On 2022-Feb-24, at 11:32 AM, Paul Berger via cctalk wrote:
> On 2022-02-24 14:16, Brent Hilpert via cctalk wrote:
>> On 2022-Feb-24, at 8:29 AM, Clemar Folly via cctalk wrote:
>>> I'm looking for information about Texas Instruments TB-759933 IC.
>>> 
>>> Does anyone have the datasheet or any other information about this IC?
>> 
>> A search shows this question was posted over here, with a picture:
>>  
>> https://atariage.com/forums/topic/331769-unknown-cart-ic-please-i-need-some-help/
>> 
>> It looks like a home-made board for a plug-in ROM expansion for 
>> we-are-not-told.
>> The "TB 759933" is 14-pin DIP, dated coded 7226, has a house number of "239 
>> 2100", but it's on a board with a 27256 from 1985.
>> It looks like somebody hacked up this board with on-hand parts.
>> 
>> 60 seconds of reverse-enginerring from the limited view in the picture 
>> suggests it's likely involved in the address decoding to select the on-board 
>> EPROM. The 759933 interconnects with a 74LS10. The LS10 appears to have 
>> connections to the chip-select and output-enable of the 27256 EPROM.
>> 
>> TB 759933 is not a standard TI number but TI sometimes identified parts they 
>> were second-sourcing by embedding the original number in an expanded number.
>> 
>> So a guess is this is a 933 DTL dual 4-input (AND function) expander, being 
>> used not-strictly-correctly to drive a TTL input.
>> 
>> The 933 should be basically 2*4 diodes.
>> 
>> A complete reverse-engineering of this trivial board would likely explain 
>> the overall intended function.

> 2392100 Look like an IBM house number for a 7400 quad NAND
> 
> Paul.


Glad you said that, I wondered whether that might be IBM, but I'm not very 
familiar with their numbers and don't have a xref.

7400 makes some sense with the board: pins 1&2 and 4&5 are blobbed together, 
i.e. acting as inverters; and the interconnections with the LS10 as far as can 
be seen appear to then make sense as outputs-inputs.



Re: Information about an unknown IC

2022-02-24 Thread Brent Hilpert via cctalk
On 2022-Feb-24, at 8:29 AM, Clemar Folly via cctalk wrote:
> 
> I'm looking for information about Texas Instruments TB-759933 IC.
> 
> Does anyone have the datasheet or any other information about this IC?


A search shows this question was posted over here, with a picture:

https://atariage.com/forums/topic/331769-unknown-cart-ic-please-i-need-some-help/

It looks like a home-made board for a plug-in ROM expansion for we-are-not-told.
The "TB 759933" is 14-pin DIP, dated coded 7226, has a house number of "239 
2100", but it's on a board with a 27256 from 1985.
It looks like somebody hacked up this board with on-hand parts.

60 seconds of reverse-enginerring from the limited view in the picture suggests 
it's likely involved in the address decoding to select the on-board EPROM. The 
759933 interconnects with a 74LS10. The LS10 appears to have connections to the 
chip-select and output-enable of the 27256 EPROM.

TB 759933 is not a standard TI number but TI sometimes identified parts they 
were second-sourcing by embedding the original number in an expanded number.

So a guess is this is a 933 DTL dual 4-input (AND function) expander, being 
used not-strictly-correctly to drive a TTL input.

The 933 should be basically 2*4 diodes.

A complete reverse-engineering of this trivial board would likely explain the 
overall intended function.



Re: Testing H745 Regulators

2022-02-18 Thread Brent Hilpert via cctalk
On 2022-Feb-17, at 11:40 PM, Rob Jarratt wrote:
>> -Original Message-
>> From: Brent Hilpert 
>> On 2022-Feb-17, at 2:38 PM, Rob Jarratt wrote:
 -Original Message-
 From: Brent Hilpert 
 
 20V on a 10 ohm load: current = 2A.
 15V, 1.5A.
 
 In this regulator design there is no path for more current than that
 which the load draws, aside from temporary peak currents to charge
 capacitors. If you're drawing 5A DC from the bench supply, something
 beyond 'failure to start' is wrong.
>>> 
>>> That's interesting. On the H744s I have observed that if I have a high
>>> load the bench PSU current limiter operates and the regulator cannot
>>> output +5V, but if I start with a lower load and then add load, it can
>>> continue to operate. Is the H745 different to the point that I
>>> shouldn't expect this kind of behaviour? If it is the same, then why
>>> do the H744s do this? I have tried waiting a few moments to allow the
>>> input capacitor to charge up, but the regulator just does not start.
>> 
>> Presumably your high test load plus the initial cap-charge current is
> pushing
>> the bench PS into current limit, that is, with a high load there is less
> available
>> current to charge the caps before the bench PS starts current limiting.
> This
>> would slow down the cap charge rate, so it would take longer for the caps
> to
>> charge. I can't say I see it 'stopping starting', but it would lengthen
> the time to
>> 'start'. How long depends on the numbers. There may also be some
>> dependance on how your bench PS responds in current limit.
>> 
> 
> But if that was the case shouldn't it just take a bit of time to get going,
> once the input cap has charged wouldn't it start regulating? It shouldn't
> take more than a few seconds, but it never seems to start. Anyway with the
> H745 the problem seems to be elsewhere.

The 744 derives the +15 supply for the 723 from the same 20-30VAC main input 
supply, in contrast to the 745 where the +15 is from another source.

With the 744, once your bench supply goes into current limit and drops its 
output voltage, that's also dropping the +15 for the 723. Everything is going 
to be out of whack at that point, the reference supply, the amp/comparator 
action, etc. I can't say at this distance and limited info exactly what's going 
on, there's also the Q7 unijunction shut-down circuit in there. It may be in 
some sort of oscillation 'trying to start' or it may be latched up into an off 
state, because the supply voltage is below some threshold. (I've never dealt 
with these supplies directly, I'm just observing the schematics.)

This behaviour may be different for the 745 because the +15 ancillary supply is 
separate/independant from the main input.



Re: Testing H745 Regulators

2022-02-17 Thread Brent Hilpert via cctalk
On 2022-Feb-17, at 2:38 PM, Rob Jarratt wrote:
>> -Original Message-
>> From: Brent Hilpert 
>> 
>> 20V on a 10 ohm load: current = 2A.
>> 15V, 1.5A.
>> 
>> In this regulator design there is no path for more current than that which 
>> the
>> load draws, aside from temporary peak currents to charge capacitors. If
>> you're drawing 5A DC from the bench supply, something beyond 'failure to
>> start' is wrong.
> 
> That's interesting. On the H744s I have observed that if I have a high load
> the bench PSU current limiter operates and the regulator cannot output +5V,
> but if I start with a lower load and then add load, it can continue to
> operate. Is the H745 different to the point that I shouldn't expect this
> kind of behaviour? If it is the same, then why do the H744s do this? I have
> tried waiting a few moments to allow the input capacitor to charge up, but
> the regulator just does not start. 

Presumably your high test load plus the initial cap-charge current is pushing 
the bench PS into current limit, that is, with a high load there is less 
available current to charge the caps before the bench PS starts current 
limiting. This would slow down the cap charge rate, so it would take longer for 
the caps to charge. I can't say I see it 'stopping starting', but it would 
lengthen the time to 'start'. How long depends on the numbers. There may also 
be some dependance on how your bench PS responds in current limit.


On 2022-Feb-17, at 10:19 PM, Rob Jarratt via cctalk wrote:
> Regarding the rating I am not clear what the rating of the original part is, 
> I haven't been able to find a datasheet for it, I have seen suggestions for 
> both 20A and 35A, I do know that the H745 regulator is fed 20-30VAC from a 
> transformer.
> 
> So presumably going for a 35A rating is the safer bet, and going for a 
> minimum of 50V peak reverse voltage would be sufficient?


At 30VAC input, peak V is ~ 44V, you're probably better off with rectifiers 
higher than 50 PIV to provide some safety margin.




Re: DEC AXV11-C analog board

2022-02-13 Thread Brent Hilpert via cctalk
On 2022-Feb-13, at 9:04 AM, Douglas Taylor via cctalk wrote:
> Stopped fooling with the AXV11 for now.  Applied various voltages to the Data 
> Translation input and recorded the A/D octal values to get an idea of what 
> the calibration of the board is.  It looks very linear, +/-10v range.
> 
> Using a single battery and voltage divider I was able to generate voltages on 
> the input of the DT2762 board, however, I had to swap wires to get negative 
> voltages.  Is it possible to construct a battery driven circuit that will 
> present both positive and negative voltages at the input?  A bridge of some 
> sort?


You said it: what amounts to a wheatstone bridge. Take say, two 10K R, in 
series across the battery forming a 1:1-split voltage divider. The center point 
shall be the common/0V. The wiper of a pot across the battery forming a 
variable voltage divider presents the +/- test signal.

That would give e.g. +/-6V from a 12V battery.
It also presumes you have a reasonably high impedance on your target input/load 
as you need to keep the Rs adequately high to keep from draining the battery.

If you wanted to get +/-12V from a 12V battery, or needed a lower impedance 
source, a couple of op-amps could be worked up into an equivalent circuit. E.g. 
two unit-followers, one inverting and one non-inverting, both fed, in 
counter-point, from the fixed divider and the variable divider, 0V from one 
output, signal from the other output.



Re: TTL substitute for DTL

2022-02-10 Thread Brent Hilpert via cctalk
On 2022-Feb-10, at 9:50 PM, Chuck Guzis via cctalk wrote:

> I've got a piece of gear here with a bad MC858P used as a bus
> driver--terminated in 220/330 ohms at the far end.
> 
> Given that old DTL is a hit-or-miss proposition, I'm proposing to
> substitute a 7438 OC buffer.  Pinout's the same, as is Vcc.
> 
> Before I get out the soldering iron, any "don't do it" thoughts?


Are you sure the pinouts match? The Moto book I'm looking at indicates the 858 
gates are 'pointing to the middle' (outputs:3,4,10,11) in contrast to the 7438 
common 'all gates pointing to the right' (outputs:3,6,8,11).

I've replaced DTL with TTL on occasion or two in the past. They're both 
current-sinking logic so they work together well enough as far as output-input 
drive.



Re: Testing H745 Regulators

2022-01-26 Thread Brent Hilpert via cctalk
On 2022-Jan-26, at 3:41 PM, Rob Jarratt via cctalk wrote:
> I am trying to test a couple of H745 regulators with a DC bench PSU and I am
> having some problems with testing them.
> 
> My bench PSU is a twin unit so I can supply the +15V required as well as the
> "AC" input using 20VDC from the other half of the bench PSU. The problem is
> that I don't think the bench PSU can supply enough startup current to allow
> the regulator to run. It can only supply 5A max.
> 
> I have seen with the H744s that if I put too big a load on them, then they
> can't start because of the heavy startup current required. I can start them
> with a lower load and then add load once the regulator is running without
> breaching the current limit of the PSU.
> 
> With the H745s I have tried reducing the load to see if I can get them to
> start, but a 10R load appears to be too much and the regulators draw the
> full 5A without outputting -15V.
> 
> I have two H745s, both exhibit the same behaviour. I suppose they could both
> have the same fault, but I am inclined to think that perhaps they need a
> higher startup current than I can supply. Can anyone confirm this?


20V on a 10 ohm load: current = 2A.
15V, 1.5A.

In this regulator design there is no path for more current than that which the 
load draws, aside from temporary peak currents to charge capacitors. If you're 
drawing 5A DC from the bench supply, something beyond 'failure to start' is 
wrong. I would expect this supply to operate at small load regardless.

What is happening to the bench supply voltage? Does it go into current limit? 
Does this bench supply have an adjustable current limit?, so that you could run 
it up starting at a low current while taking measurements. Or, does the current 
respond with some linearity to varying the input voltage?

What happens with no load R?

Are you running it for any length of time at 5A? (Sounds like a bad idea at 
this point) Anything getting warm?

Is the 723 socketed? Pull it and run it up while watching what happens around 
the drive transistors and elsewhere.
If the 723 is not socketed, consider pulling Q5 or opening it's emitter 
connection. With no drive to the drive transistors, input current should be nil.

Are any of the drive transistors socketed, so they could be measured out of 
circuit? and other R measurements made without them in circuit?

Pull F1 to isolate circuitry. Still draws current?

Have you looked for shorts/leaks?, especially leaky junctions in transistors 
Q2::Q5.
e.g. R measurements, no F1, no load R, both directions:
Q2.B-C ?
Q2.E-GND ?
Q2.C-GND ?
-15-GND ?
Settling time for cap charge/discharge may be needed.

In answer to your earlier question, no, the +15V is not the reference, it is 
the supply for the 723 regulator IC. The reference is the internal reference 
provided by the 723, though that internal reference is powered inside the IC 
from the +15V.



Re: Source for replacement caps in H744 regulators

2022-01-06 Thread Brent Hilpert via cctalk
On 2022-Jan-06, at 4:04 PM, Matt Burke via cctalk wrote:
> On 06/01/2022 12:59, Jonathan Chapman via cctalk wrote:
>> That said, it's not like replacing them with new will *hurt* -- it just 
>> might not fix the whine.
> 
> I suspect that it won't fix the problem. Slightly hijacking the thread
> here but hopefully in a semi-helpful way.
> 
> I have two of these regulators, one from a BA11K and one from a TS11.
> Under the same test conditions the one from the TS11 produces a
> significantly louder whining noise than the one from the BA11K. Given
> that they are largely the same circuit as the H745 regulators and all
> the ones I have are silent in operation I find it hard to believe they
> are supposed to be like this. I used to have two more TS11 drives and
> they both exhibited the same behaviour. Seems to be a common problem.
> 
> Now, for the one from the BA11K (quiet one) the output capacitors were
> completely open (0uF) so I had to replace them. Given that I had the new
> capacitors I decided to try them in the TS11 regulator to see if it
> would fix the whining noise. It made no difference.
> 
> After some probing with an oscilloscope I found that between the two
> regulators there was a very different waveform on the emitter of Q2.
> 
> Quiet regulator: http://www.9track.net/posts/h744/h744_ba11_q2e.png
> Noisy regulator: http://www.9track.net/posts/h744/h744_ts11_q2e.png
> 
> The yellow trace is the emitter of Q2 (input of L1) and the cyan trace
> is the output of L1. Q2 seems to be switching partly on then fully on in
> the noisy regulator. it should of course be fully on or fully off as
> seen on the quiet regulator. Also the switching frequency seems to be lower.


The intermediate step voltage at Q2.E-L1.input is not Q2 partially on. It's D5 
shutting off, as it would do when L1 has discharged and current is no longer 
flowing in it, and follows from the basic principles of a buck converter. 
Notice that the step is 5V, i.e. the output voltage.


> I tried testing/swapping a few parts between the two regulators, L1, Q2,
> Q3, E1. It started out reasonably logical and after several days
> descended into a unscientific mess of swapping anything and everything
> that could possibly be at fault. I got to the point where I had
> eliminated just about every component so I must have overlooked
> something. I was hoping to stumble upon the answer and then learn
> something from it but so far no luck. This project has been shelved for
> a while now.



Re: Memory Tech you don't see very often

2022-01-06 Thread Brent Hilpert via cctalk
On 2022-Jan-06, at 12:19 AM, Joshua Rice via cctech wrote:
> Not cost effective at nearly $10,000! I understand they're very rare, given 
> they were only used for a few years in industry and they're clocking on 3/4 
> of a century old, but even then, that seems an order of magnitude or two off 
> the real value.
> Actually, looking them up, doesn't seem they were used in much at all. Seems 
> to have been a bit of a technological dead-end since core memory quickly 
> superseded it with it's (relatively) cheap costs and (relative) ease of 
> manufacturing. I imagine the US gov. probably used them somewhere, since they 
> were a sucker for cutting edge technology of the time.
> Would be interesting to know how many hours it's got on it

"Not cost effective" ?  What does that mean in the arena of valuation of 
historic artifacts?

No, they didn't go anywhere as a product and apparently only saw use in one 
machine.

However, the 'pro' side of such a debate is that they were a very early attempt 
to produce a fast digital RAM memory specifically for use in Stored-Program 
Machines, at a time when memory was at the top of the list of problems in 
development of the first SPMs, and actually before any SPMs had been produced, 
and weren't a serial technology like drums and delays lines tortured into 
applicability for the task.

They are wrapped up in the history of John VonN and the IAS machine, one of the 
most significant machines in computing history (arguably the most significant).

There's always opinion and subjective valuation in assessments of history but 
if one is acquainted with what was going on in that period of 46-50, they are a 
very interesting and notable development attempt.



> -- Original Message --
> From: "pbirkel--- via cctalk" 
> To: "'General Discussion: On-Topic Posts'" 
> Sent: Wednesday, 5 Jan, 2022 At 17:35
> Subject: Memory Tech you don't see very often
> Selectron Vacuum Tube: https://www.ebay.com/itm/174977901251 
> 
> 
> Really nice photo-shoot! I wonder what the back-story to this particular
> tube might be.
> 
> I don't think that $16.18 shipping would be, um, adequate protection by any
> measure.
> Cheap, but not so sure about "cost-effective" .



Re: Memory Tech you don't see very often

2022-01-06 Thread Brent Hilpert via cctalk
On 2022-Jan-06, at 12:19 AM, Joshua Rice via cctech wrote:
> Not cost effective at nearly $10,000! I understand they're very rare, given 
> they were only used for a few years in industry and they're clocking on 3/4 
> of a century old, but even then, that seems an order of magnitude or two off 
> the real value.
> Actually, looking them up, doesn't seem they were used in much at all. Seems 
> to have been a bit of a technological dead-end since core memory quickly 
> superseded it with it's (relatively) cheap costs and (relative) ease of 
> manufacturing. I imagine the US gov. probably used them somewhere, since they 
> were a sucker for cutting edge technology of the time.
> Would be interesting to know how many hours it's got on it

"Not cost effective" ?  What does that mean in the arena of valuation of 
historic artifacts?

No, they didn't go anywhere as a product and apparently only saw use in one 
machine.

However, the 'pro' side of such a debate is that they were a very early attempt 
to produce a fast digital RAM memory specifically for use in Stored-Program 
Machines, at a time when memory was at the top of the list of problems in 
development of the first SPMs, and actually before any SPMs had been produced, 
and weren't a serial technology like drums and delays lines tortured into 
applicability for the task.

They are wrapped up in the history of John VonN and the IAS machine, one of the 
most significant machines in computing history (arguably the most significant).

There's always opinion and subjective valuation in assessments of history but 
if one is acquainted with what was going on in that period of 46-50, they are a 
very interesting and notable development attempt.



> -- Original Message --
> From: "pbirkel--- via cctalk" 
> To: "'General Discussion: On-Topic Posts'" 
> Sent: Wednesday, 5 Jan, 2022 At 17:35
> Subject: Memory Tech you don't see very often
> Selectron Vacuum Tube: https://www.ebay.com/itm/174977901251 
> 
> 
> Really nice photo-shoot! I wonder what the back-story to this particular
> tube might be.
> 
> I don't think that $16.18 shipping would be, um, adequate protection by any
> measure.
> Cheap, but not so sure about "cost-effective" .



Re: IBM transistor replacements

2021-11-27 Thread Brent Hilpert via cctalk
On 2021-Nov-27, at 11:22 AM, Gregory Beat via cctalk wrote:
> 
> The Texas Instruments (TI) 139 is likely a 2N139 PNP (BJT) transistor, 
> capable of high speed switching (in that era).
> 
> The 2N139 was originally an RCA transistor (tall cylinder) found in RCA and 
> GE transistor radios (455 kHz IF section).
> The TI versions were low profile metal case, TO-33 case (8.5 to 9.5mm 
> diameter)


From the JEDEC number, 2N139 would be a 50s-era transistor, way earlier than 
the ones at issue.
2N139 specs are Ge-PNP, 16V/12V CE max, 15mA IC max, 35mW max, which can find a 
use in transistor radios, but highly unlikely to be what the OP is looking for.

Re: IBM transistor replacements

2021-11-26 Thread Brent Hilpert via cctalk
On 2021-Nov-26, at 1:52 PM, Al via cctalk wrote:

> A while ago I received an IBM 3286 printer, annoyingly some of the 
> transistors in the printer section have been corroded. What I am having 
> trouble with is reading the part codes and finding a modern equivalent of 
> them. 
> There are two types.
> 
> One has a Ti logo and two sets of numbers (attached). Does anybody know which 
> numbers are the part numbers and if they are IBM house numbered? 
> Photos of the Ti transistors and card assembly: 
> https://drive.google.com/drive/folders/1JTnsWS4A8NrYJNFsqK2ejOeqqJNjoF1w?usp=sharing



Have you checked/measured whether they're actually faulty? Yes, they look 
terrible, but that doesn't mean they're faulty. It looks like minor corrosion 
of the steel case under its plating; unless it's all the way through the die is 
probably fine and cozy inside. The electrically active parts of the transistor 
typically aren't as susceptible to corrosion as the steel case is.

(Notable exception to this being 70's-era TI ICs with plated steel pins. I've 
also seen some Motorola ICs with corroded pins).



Re: Programming Bipolar PROMs

2021-09-27 Thread Brent Hilpert via cctalk
On 2021-Sep-27, at 10:52 AM, Brent Hilpert via cctalk wrote:
> On 2021-Sep-27, at 8:23 AM, Tom Hunter via cctalk wrote:
>> While restoring and repairing a Data General Nova 2/10 I found a bad
>> bipolar PROM on the CPU board. The PROM has open-collector outputs and is
>> organized as 32 words by 8 bits. It appears that one of the open-collector
>> driver transistors is faulty (but it could also be that a fuse has
>> "healed").
>> 
>> The part is an Intersil IM5600CP, but these were also made by others, for
>> example Signetics and Philips made the 82S23 and TI and NTE made the faster
>> SN74S188N. Some vendors still sell these parts and there are even a few on
>> Ebay.
>> 
>> How do I program these PROMs? I found one somewhat obscure description of
>> the algorithm in the NTE datasheet, but I suspect that each manufacturer
>> had (somewhat) different algorithms.
>> 
>> Is there an affordable commercial programmer out there which can program
>> these PROMs?
>> 
>> Is there a simple design out there which I could breadboard for a one-off
>> programming job (maybe using an Arduino to control the programming
>> sequence)?

> ...
> Details of the 74S188 programming/burn algorithm is in the 1975 TI Memory 
> Databook for Design Engineers (available at bitsavers) (I expect the 188 is 
> the most likely type you'll find NOS today).


The 82S23 programming algorithm is in the 1975 Signetics Bipolar Memories 
databook (also on bitsavers).
Looks like it may be a little more complex than that for the 188.



Re: Programming Bipolar PROMs

2021-09-27 Thread Brent Hilpert via cctalk
On 2021-Sep-27, at 8:23 AM, Tom Hunter via cctalk wrote:
> While restoring and repairing a Data General Nova 2/10 I found a bad
> bipolar PROM on the CPU board. The PROM has open-collector outputs and is
> organized as 32 words by 8 bits. It appears that one of the open-collector
> driver transistors is faulty (but it could also be that a fuse has
> "healed").
> 
> The part is an Intersil IM5600CP, but these were also made by others, for
> example Signetics and Philips made the 82S23 and TI and NTE made the faster
> SN74S188N. Some vendors still sell these parts and there are even a few on
> Ebay.
> 
> How do I program these PROMs? I found one somewhat obscure description of
> the algorithm in the NTE datasheet, but I suspect that each manufacturer
> had (somewhat) different algorithms.
> 
> Is there an affordable commercial programmer out there which can program
> these PROMs?
> 
> Is there a simple design out there which I could breadboard for a one-off
> programming job (maybe using an Arduino to control the programming
> sequence)?


The hardware & software for a one-off breadboarded programmer is, or should be, 
easy enough with a ~ few-hours/1-day effort if you wanted to go that route.

I did this 8 years ago for a PROM in a HP9830 - a 256*4 Intel 3601 PROM, for 
which I burned, and replaced with, a TI 74S387.
(In the end in turned out it was an unnecessary effort, one data-line from the 
PROM was showing bad but the failure wasn't the PROM output, it was the input 
of the IC the PROM was driving.)

Programmer hardware was 3 TTL ICs, 2 zeners, 6 transistors (more specifically 
2+numDataLines) and a few resistors on a solderless breadboard, and a bench 
power supply for the programming voltage. Software was a python program running 
on a RPi. All program-pulse timing was done in user-land on the RPi.

I can send along the schematic and program if you wish, there will be some 
adaptation required of course. Details of the 74S188 programming/burn algorithm 
is in the 1975 TI Memory Databook for Design Engineers (available at bitsavers) 
(I expect the 188 is the most likely type you'll find NOS today).





Re: Pro-Log M980 Programmer

2021-07-24 Thread Brent Hilpert via cctalk
On 2021-Jul-24, at 2:36 AM, DI Gerhard Kreuzer via cctalk wrote:
> I own a Pro-Log M980 Prom Programmer and want to program a 2732 EProm. I
> have everything needed, but how can I get the data in?
> There is a serial interface, did anybody have some program for a standard
> PC to handle that daa transfer?
> Cabling istn't an issue, can do it.
> 
> Thanks for helping.



Do you not have the manual? The M980 manual is on bitsavers.

I have the slightly earlier M900 model, by the front panel they're quite 
similar. I've used it for programming 2716s, although it's been a few years. 
IIRC it's an ASCII-format protocol for RS-232 serial, so you just have to have 
a terminal program you can dump a file through.

Be careful about the hardware communications interfaces. The 9-pin D connector 
labeled 'serial interface' is not the RS-232 serial standard. There were 
several firmware and hardware communication options. Do you have the pro-log 
adapter, or are you making an assumption about what's there?  My unit had the 
RS-232/serial firmware option but was missing the RS-232 adapter, so I had to 
build one (can be done with just a MAX232 IC).



Re: core matt repair

2021-07-20 Thread Brent Hilpert via cctalk
On 2021-Jul-20, at 4:04 PM, Jules Richardson via cctech wrote:
> On 7/20/21 12:13 PM, pspan via cctech wrote:
>> I worked at a company called DMA located in Amery Wisconsin during the 80's 
>> and 90's that did do core mat repair. Yes, the gal that did the work used a 
>> scope. She replaced cores and wires. Good luck finding someone to do that 
>> work now. If I remember the process, first the mat was removed from the 
>> driver assembly, then the varnish was removed. Then the mat was repaired and 
>> revarnished and then reassembled and final test before returned to the 
>> customer.
> 
> Oh, well there you go... perhaps the board that I have was repaired by the 
> gal that you're talking about :-)
> 
> Unfortunately there are no initials on my board (as was often the case for 
> board repairs), only a date and job number.


In general comment to the topic, I have seen planar arrays ("mats") with some 
number of randomly-situated wire splices in them.
These splices are in the gaps between bit arrays, not interior to a bit array 
(there isn't enough space between cores).
The splices are covered in a tiny dollop of (by appearance) silicon putty for 
insulation.

The number of splices and consistency of appearance suggests they were done at 
the time of manufacture, while the random distribution suggests they were not 
part of the manufacturing intention. That is to say, the manufacturing process 
was itself less than perfect and necessitated 'repairs' so to speak.

On the question of manual vs automated assembly, I take it this could involve a 
mixture. For example, stringing a number of cores onto a single wire for one 
axis would be easy to automate, stringing the second axis is more difficult.
The development of 3-wire topologies over 4-wire would have helped automation, 
or reduced manual effort, considerably. For stringing, the really awkward 
aspect of the original 4-wire topology was the sense wire that angled through 
all the cores at 45 degrees to the X,Y,I wires. This was alleviated in the 
3-wire topology where there is just 90 degree and parallel relations.

USB Serial conversion / was Re: VT340 Emulation

2021-06-26 Thread Brent Hilpert via cctalk
On 2021-Jun-26, at 10:15 AM, Paul Koning via cctalk wrote:
>> On Jun 26, 2021, at 11:31 AM, Tapley, Mark B. via cctalk 
>>  wrote:
>> 
>> At one point FTDI had a reasonably good reputation, and I own one of those 
>> devices based on that reputation. I have used it with no obvious problems 
>> connecting a TRS Color Computer 3 to an iMac G3 for a floppy-drive emulator 
>> (DriveWire on the iMac), but I think only for that application so far.
>> 
>> Are there any particular pitfalls I should watch out for with the FTDI 
>> device, when/if I can get back to working with it?
> 
> I once bought a USB serial port device with a DE-9 connector on it, Belkin I 
> think.  It worked somewhat.  Might have needed its own driver, which on a Mac 
> is highly unusual.  It gave me enough trouble I set it aside.
> 
> Since then I've bought several different flavors of the FTDI USB serial 
> device, one RS-232, one 5 volt logic, one 3.3 volt logic (the latter two with 
> 6-pin connectors to fit onto pin headers such as are found on the BeagleBone 
> Black).  They have always worked flawlessly (on my Mac), at a number of data 
> rates: 4800, 9600, 19.2k, 115k.  I'll admit I haven't needed stranger cases 
> like 5 or 6 bit data, or exotic slow speeds.  As I mentioned, if that need 
> arises and FTDI isn't good enough I'll have the RPico to do the job.

A couple years ago, somewhat on a whim, I checked a small number of USB-Serial 
converters for driving a couple of Model 28 Teletypes.

I didn't really expect anything so modern to work below 300 BPS, or do the 
needed 5-data/2-stop, but the teletypes were 75 BPS, which is just another in 
the division-of-2 series down from 19200,9600,etc.; and I was actually figuring 
on just using 8-bit and ensuring the later bits were 0 so they would be seen as 
stop bits, and take a bit of a penalty on the 28 print speed (might be a little 
rough/abusive on the teletype commutator start/stop though).

Sometimes, ya luck out: one of them actually worked down to 75 BPS, *and* did 
5-data/2-stop.

There's no ID on the physical unit but it shows up on the system (OSX) as: 
Product ID: 0x2303
 Vendor ID: 0x067b  (Prolific Technology, Inc.)

(Product ID 0x2303: Prolific produces a series of PL2303x USB-Serial chips.)

It was plug-n-play on the Mac (given a terminal app program that knows to 
accept and perform the little-used config specs).

There are some other teletypes to get going that need slower speeds, for which 
I intend a solution as (Paul) suggests, bit-banging out of an RPi. The code was 
written some time ago, but haven't gotten around to the physical connections.



Re: VT100 colors

2021-06-21 Thread Brent Hilpert via cctalk
This is funny, as everyone (me too) weighs in with their description of the 
elephant.

My recollection (also from recent observation of a VT278):
- case main: very light cream, somehow with a touch of grey, but not 
pure white
- case insets: very dark brown

Remember, it was the 70s! Earth tones. Black wasn't yet a thing.

- CRT: white phosphor

I never saw a VT1xx style in anything other than white phosphor.


On 2021-Jun-21, at 10:12 AM, Antonio Carlini via cctalk wrote:
> I did find one seemingly untouched image of a VT100 with green text: 
> https://vistapointe.net/cliparts/getsecond. That does appear to be a VT100 
> (not a VT102/VT103 etc) and is green.

That link didn't work for me, but poking around on the same site:
https://vistapointe.net/vt100.html

Yes, some very novel images of a VT100 with green phosphor.
But really, I'd bet *very* strongly that somebody swapped the CRT to get that.




Re: Early Programming Books

2021-06-21 Thread Brent Hilpert via cctalk
On 2021-Jun-20, at 7:38 PM, ben via cctech wrote:
> On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:
> 
>> Tried the Shunting Yard algorithm? But watch out, it was invented by a
>> quiche eater...
> 
> The problem needs backtracking to generate correct code. Stack or 
> muilti-register machines don't have this problem with temporaries.
> Ben.

The parser generates a tree of the algebraic expression, the tree is 
representative of the evaluation order of the expression, earlier evals lower 
in the tree, the node at the top is the last evaluated. Then walk the tree from 
the bottom up to generate code.

I think code to do this (efficient compiler code generation) has been done like 
a gazillion-billion times since 1960.



Re: Early Programming Books

2021-06-20 Thread Brent Hilpert via cctalk
On 2021-Jun-20, at 9:19 PM, ben via cctalk wrote:
> On 2021-06-20 9:01 p.m., Brent Hilpert via cctalk wrote:
>> On 2021-Jun-20, at 7:38 PM, ben via cctech wrote:
>>> On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:
>>> 
>>>> Tried the Shunting Yard algorithm? But watch out, it was invented by a
>>>> quiche eater...
>>> 
>>> The problem needs backtracking to generate correct code. Stack or 
>>> muilti-register machines don't have this problem with temporaries.
>>> Ben.
>> The parser generates a tree of the algebraic expression, the tree is 
>> representative of the evaluation order of the expression, earlier evals 
>> lower in the tree, the node at the top is the last evaluated. Then walk the 
>> tree from the bottom up to generate code.
>> I think code to do this (efficient compiler code generation) has been done 
>> like a gazillion-billion times since 1960.
> 
> Computer science people seem to like to brag about how to parse.

Whatever that means.

> Walking a tree does not solve the tree was built in the wrong order.
 
No. If the tree was built in the "wrong order", then you screwed up in writing 
your parser.
There is no great difficulty in parsing into a tree representation which can be 
walked to resolve your initial issue.

> Parenthesis first implies input string re-scanning and text movement.

Whatever that means.
You don't have to "move text" to accomplish this.

> This what I can't seem to find a good algorithm for.

In summary fashion, I told you how it's done.
If you don't understand state machines and parsing that's your problem.

As it is, you are running into the same issue a thousand minicomputer & 
microproc manufacturers and designers ran into in the 60/70s: building and 
maintaining the support ecosystem for a machine architecture is not trivial.


But I should know better than to bother.



> FORTRAN II and IV did quite well before all this computer science. FORTRAN 
> solved real world problems, ALGOL has yet to have I/O. LISP still can't be 
> compiled.PASCAL is only educational problems, and C mutated into Monster. 
> JAVA is not open source.
> 
> Very little new stuff is on multi-pass parsing.I have a 70's computer design 
> of modest word length (20 bits) that needs 1970's computer science, and 64KB 
> of memory and removable disks.
> Ben.



Re: DEC Computer Lab for sale

2021-05-29 Thread Brent Hilpert via cctalk
On 2021-May-29, at 7:58 AM, William Donzelli via cctalk wrote:
> Over on the Discord, I have posted a DEC Computer Lab H-500 for sale.
> Needs cosmetic help, but will be priced accordingly.
> 
> Offers? Off list...


As I am aware of it Discord is a software package.

What does "Over on the Discord" mean?
Or, what Discord server?, where?



Re: Apple II+ Video questions

2021-05-09 Thread Brent Hilpert via cctalk
On 2021-May-09, at 2:16 PM, David Williams via cctalk wrote:
> Working on restoring my very first computer, an Apple II+. Got it mostly 
> working with just a couple of issues identified at the moment. Some of the 
> keys on the keyboard don't register but I can work on that. The real question 
> I have is about the video, it constantly rolls and no amount of playing with 
> the vertical hold on any monitor I try will completely stop it. I can get it 
> close but it will slowly roll one way or the other at best. Tried several 
> different monitors and it is the same on each. Also tried my old Apple IIe 
> and it seems fine on all the monitors so trying to decide what might be the 
> issue with the II+. Any ideas or areas to look?

It sounds like the vertical sync pulse may be missing, or 'weak', in the 
composite video output signal.

You 'get it close' with the V-Hold as your adjusting effort brings the monitor 
frame rate (V frequency) to match the frame rate the Apple II is generating.

Pull out the schematic and look at how V sync is generated. Probably easiest to 
start at the video output and work backwards, to where the combined V sync 
are added to the pixel video to form the final composite signal, then back to 
where V sync & H sync are combined, and so on.



Re: Motor generator

2021-05-04 Thread Brent Hilpert via cctalk
On 2021-May-04, at 4:06 PM, Donald via cctalk wrote:
> In the deep recesses of my mind I seem to remember something about S/360
> machines using a motor generator.
> 
> If I am right was this to create a stable power source at a certain
> frequency or voltage?

I dont know about the 360, but a motor/gen can provide several benefits:
- isolate the load side from mains noise
- provide a degree of regulation from mains fluctuation thanks to the 
inertia of the rotating mass
- raise the frequency so subsequent power supply transformers and caps 
can be smaller (ala 400Hz operation in aircraft) 
- convert to 3-phase as Chuck mentioned, although I would have thought 
that by the time a 360 is running from a motor-gen
  it's probably already being supplied with incoming 3-phase mains



Re: Exidy S-100 Expansion cards questions

2021-04-24 Thread Brent Hilpert via cctalk
On 2021-Apr-24, at 12:43 PM, David Williams via cctalk wrote:

> Moving forward on setting up my collection and I was taking a look at an 
> Exidy Sorcerer S-100 Expansion box I had received long ago. I wondered if 
> anyone could help with info on the cards I found inside. The first is clearly 
> a memory card but not familiar with the company. The second is a disk 
> controller and the third is a parallel/rs232 interface. I haven't found any 
> doc on any of them yet. If you have doc or info on the cards or anything else 
> about the expansion box please let me know. Haven't tested or done any more 
> with it yet other than open it up and look around inside. Had this for ages 
> but only now had room to take it out of the box.
> 
> 1) 64K Static Memory card copyright 1981 Memory Merchant
> 2) Double Disk controller by Jade Computer (Doesn't seem to match the image 
> on the doc I found on Bitsavers for their Double D controller but suspect it 
> is one)
> 3) Interfacer II  Triple Parallel / RS232 Serial I/O from CompuPro - Godbout

I take it you haven't found s100computers.com.

Info for the Compupro Interfaceer II is readily available there, with scan of 
original manual with schematic.

http://www.s100computers.com/Hardware%20Folder/CompuPro/Interfacer%20II/Interfacer%20II.htm

Mem Merch 64K and Jade FDC are listed there as well, I haven't looked below the 
link level for them though.

There used to be another S100 site under maben-something but it seems to have 
vanished.
It was a lot of duplicate with S100computers but had some additional stuff.



> Links to pics below.
> 
> http://www.trailingedge.com/images/ExidyS100-1.jpg
> http://www.trailingedge.com/images/ExidyS100-2.jpg
> http://www.trailingedge.com/images/ExidyS100-3.jpg
> http://www.trailingedge.com/images/ExidyS100-4.jpg
> http://www.trailingedge.com/images/ExidyS100-5.jpg
> http://www.trailingedge.com/images/ExidyS100-6.jpg
> http://www.trailingedge.com/images/ExidyS100-7.jpg
> http://www.trailingedge.com/images/ExidyS100-8.jpg
> http://www.trailingedge.com/images/ExidyS100-9.jpg





Re: Need a BASIC expert

2021-04-21 Thread Brent Hilpert via cctalk
On 2021-Apr-21, at 1:49 AM, Christian Corti via cctalk wrote:
> I'm trying to find out if the BASIC dialect that was available for the MINCAL 
> computers (aboutn 1971) was something derived from another "system" or 
> whether it was an own dialect.
> 
> Some characteristic instructions that I can't find somewhere else are:
> - Formatted output with PRINT FOR()
>  Example: PRINT FOR(F5.0)500.1
> - Computed GOTO with GOTO  OF n1,n2,...
>  Example: GOTO A+B+1 OF 100,20,50
> - Presence of "DEF FN", lack of RESTORE for DATA/READ constructs.
> 
> This BASIC must have been around 1970-1972.

It's not clear what you're looking for:
  1. A possible predecessor/origin for the source code or design of the MINCAL 
interpreter,
  2. or, earlier BASIC implementations that had the language features you 
mention.

If 2:
  - HPBASIC for the late-60s HP2100 machines (2115,2115,2114) has DEF FN. (Date 
of source reference: 4/70).
  - the HP9830 (released 1972) has both DEF FN and computed goto (as well as 
computed gosub).
  - The 9830 has very Fortran-ish WRITE and FORMAT statements.

DEF FN was nothing new, it was apparently in the original Dartmouth.

Re: Hard To Believe This Person Is Serious

2021-03-25 Thread Brent Hilpert via cctalk
On 2021-Mar-25, at 5:21 PM, Chris Zach via cctalk wrote:
> Well, if there is no cost to asking that amount, why not? It's an 
> inefficiency of Ebay that things can stay up there for years, but that is as 
> it is.

It's been enough years I don't remember when I first saw it, this has been 
listed for 4-5 years or more:

https://www.ebay.com/itm/VINTAGE-VARIAN-DATA-MACHINES-620-L-100-COMPUTER-620L100-620-L100/311466122329

Re: : Re: MSI 6800 EPROM Software

2021-02-23 Thread Brent Hilpert via cctalk
On 2021-Feb-23, at 1:45 PM, Frank Tuccio via cctech wrote:
> On 02/22/2021 01:31 PM, Brad H via cctalk wrote:
>> 
>> A longshot I'm sure - but I am wondering if anyone familiar with MSI
> (Midwest Scentific - SS50 bus system) would happen to have a copy of the
> software for their 1702A EPROM burner, I think the model is PR-1.  I just
> picked one up and am eager to see if I can use it to read/burn 1702As,
> something that has been an issue for me for a while now.
>> 
>> 
> Reading them is pretty easy.  BURNING them is crazy.  They 
> need an 80 V power supply, and I think you XOR the address 
> or something as you apply the programming voltage.
> 
> Jon
> 
> Actually,  programming a 1702 only requires a  -48 volt pulse for each
> address.  Here's the datasheet:
> https://www.jmargolin.com/patents/1702a.pdf


Ya, but that's with a Vbb of +12V, so the differential required from the power 
supplies is 60V.
(Per the datasheet, it was ~ 55V in the 1702 programmer I once had.)

But that's the easy part.
And the semi-complex timing and switched-complementing of the address can be 
done in software.

The hassle is that the data lines, address lines and several of the supply and 
control lines all have to be switched independently with these high voltages. 
So it's a small mess of specialised discrete drivers and hardware.
It's not just pulse a high voltage to one PGM pin like it was for 2716s and 
later eproms.

I don't know what the 2708 (after the 1702, before the 2716) requirements were.



Re: Mystery (unusual) 1973 terminal

2021-02-12 Thread Brent Hilpert via cctalk
On 2021-Feb-12, at 6:08 AM, Paul Koning via cctalk wrote:
>> On Feb 12, 2021, at 7:50 AM, Jules Richardson via cctalk 
>>  wrote:
>> 
>> Hopefully the following link works, but someone over on one of the Facebook 
>> vintage groups has this oddball terminal from 1973 that they've been looking 
>> for any information on:
>> 
>> https://drive.google.com/drive/folders/1-2uEFbi3OKBYr06y6yHnygDiLMtw2Qkj
>> 
>> ... it's somewhat unconventional in that half the CRT is hidden from view 
>> within the machine, i.e. it only actually displays the top half of the 
>> display to the user - I've no idea if that's because it had a specific 
>> application where space was limited, or if it was simply that memory at the 
>> time was horribly expensive and so it was designed to only use a few lines 
>> (I know some vendors did that, although I think they typically presented the 
>> whole CRT and at least had the option of RAM upgrade to more lines).
>> 
>> The blower assembly seems a little on the homebrew side, but on the other 
>> hand the PCBs and case construction make it seem like a professional product.
>> 
>> The owner says the only label anywhere on the thing is the one on the CRT 
>> saying "Mfd in Japan for Conrac", but that's presumably just the CRT itself 
>> and not the entire machine.
> 
> I remember Conrac as a well known CRT maker from that time.  I think they 
> were used in PLATO III terminals (mid 1960s).
> 
>> I don't believe there's anything resembling a microprocessor in the system, 
>> it's all just TTL logic (the large white ceramic IC is an ACIA).
>> 
>> Oh, I believe the owner's in Canada, so it may be it was made there and 
>> never exported to other parts of the world.
>> 
>> Jules
> 
> The photos are not particularly helpful; they show parts of the device but 
> not close enough to tell the details, while much of the case is not shown.  
> Is there any manufacturer label or serial number tag on the case?
> 
> One of those boards is full of rather sloppy ECO wires, which makes it feel 
> like a home made job, but the rest look like decent quality commercial 
> pieces.  And yes, the blower is rather curious, it's hard to see how a device 
> like this might dissipate enough power to need that kind of air mover.


Between google and the browser I'm using, the photos didn't display properly, 
so I downloaded them (upper right corner),
which unzipped to high-res versions.

From those:

The board with the white ECOs is the memory, it has 5 1402's (256*4 shift 
register), 3 of them from Intel and 2 replacements from MIL (Microsystems 
International Limited) which is the only place Canada appears to come into it.
Not clear how they would be organised for the screen .

The main board has a Fairchild 3258 64*7*5 character generator, along with the 
1602 UART/ACIA.

The blower is probably targeting the pass transistors for the linear power 
supply, to avoid requiring a giant heat sink.
Most/many terminals from that period had a large heat sink for the pass trans.

I don't think the CRT is half-hidden, rather just a high-aspect-ratio CRT (very 
wide rel to height).

Interesting that aside from the Intel/MIL memory chips, a couple of specialised 
clock drivers for those, and a couple of other chips, it's entirely Fairchild 
9xxx series stuff.

In terms of design & construction it looks pretty typical for its period; 
nonetheless a cool unit to be working on.



Re: tty and video displays

2020-12-15 Thread Brent Hilpert via cctalk
On 2020-Dec-15, at 11:15 AM, Jules Richardson via cctalk wrote:
> On 12/14/20 10:06 PM, Brent Hilpert via cctalk wrote:
>>> (It's definitely -12V, not -5V? I'm just thinking that the -12V noted
>>> on your schematic is quite close the the 15V rating on the cap -
>>> although that could explain why my later setup got caps rated to 35V,
>>> too)
>> I don't remember whether I traced it or measured it, but I'm fairy
>> confident, Vgg = -12 is pretty common for GI MOS ICs. I'll try to
>> remember to double-check it when I have the unit opened again.
> 
> Thanks! I guess I can try it first on -5V too and see if the encoder outputs 
> do anything, and if not give -12V a go. If it works, I like the charge pump 
> idea - I'd probably ultimately give it its own case and use it externally, so 
> saving a wire is handy.


Just double-checked by measurement, yes, it is -12V.



Re: tty and video displays

2020-12-14 Thread Brent Hilpert via cctalk
On 2020-Dec-14, at 7:57 AM, Jules Richardson wrote:
> On 12/14/20 4:41 AM, Brent Hilpert via cctalk wrote:
>> 
>> Yes. Coincidentally I've just been refurbishing one - a Teleray 3931.
>> It's an ASCII/APL terminal, overstriking was included for the APL mode.
>>  http://madrona.ca/e/teleray3931/index.html
> 
> Holy cow, I have that keyboard. 
...
> (It's definitely -12V, not -5V? I'm just thinking that the -12V noted on your 
> schematic is quite close the the 15V rating on the cap - although that could 
> explain why my later setup got caps rated to 35V, too)

I don't remember whether I traced it or measured it, but I'm fairy confident, 
Vgg = -12 is pretty common for GI MOS ICs.
I'll try to remember to double-check it when I have the unit opened again.

I have some other orphan keyboard of the period, don't recall which scanner IC 
it uses, but it has the similar +Vcc/-Vgg requirement.
I made up a little negative supply with a 7660 charge pump and tacked it onto 
the keyboard PCB so the keyboard now only needs +5 externally.

Re: tty and video displays

2020-12-14 Thread Brent Hilpert via cctalk
On 2020-Dec-14, at 6:28 AM, Paul Koning wrote:
>> On Dec 14, 2020, at 9:26 AM, emanuel stiebler via cctalk 
>>  wrote:
>> On 2020-12-14 05:41, Brent Hilpert via cctalk wrote:
>>> On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote:
>>>> Often for data input one could use over strike characters for input. Not 
>>>> EQ might be = BS | Did any video display terminals
>>>> repeat the same effect?
>>> 
>>> Yes. Coincidentally I've just been refurbishing one - a Teleray 3931.
>>> It's an ASCII/APL terminal, overstriking was included for the APL mode.
>>> 
>>> http://madrona.ca/e/teleray3931/index.html
>>> 
>>> Note the screenshots in APL mode.
>> 
>> Is it really an overstrike? They look simply like different characters.
>> At least, I didn't (probably missed it) how they can be generated out of
>> the available ones...
> 
> I wondered too.  General overstrike requires a bitmap display, or some sort 
> of persistent display.  Paper is an example; a Tek 4010 would also handle 
> overstrike since it uses a storage tube.  And PLATO terminals did overstrike 
> just fine since they are bitmap displays with per-pixel memory.



Yes, it really is overstrike. This is pretty much explained in the text. You 
generate overstrikes by backing up and entering a 2nd character.
There are two full screen buffers, but only one page of display. There is a 
spring-loaded 3-position switch that allows you to temporarily 'disable' either 
of the buffers, so that only the characters in the other buffer are on screen 
while you hold the switch.

There are 95 symbols in the APL set encoded in the range 0x20 to 7E, as shown 
on the screenshots.
Now I haven't tried all 9025 possible overstrike combinations, but all sorts of 
non-sensical combinations produce what would be the expected result - an OR of 
the pixels of the contributing characters. For example, "A" can be overstruck 
with all the other letters of the alphabet, and all the letters of the alphabet 
can be overstruck with "A". It's not just the valid APL overstrike combinations.

A general overstrike capability like this doesn't need a bitmap display to 
accomplish. I haven't RE'd the character-pixel generation section, but the ICs 
present and the behaviour points to it doing something along the lines of:
In raster scanning, for each screen character cell:
- address buffer 1, send code through character generator, 
store result in pixel shift register.
- address buffer 2, send code through character generator, OR 
result into pixel shift register.
- shift the shift register pixels out to CRT.
- repeat for next character cell

Re: tty and video displays

2020-12-14 Thread Brent Hilpert via cctalk
On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote:
> Often for data input one could use over strike characters for input. Not EQ 
> might be = BS | Did any video display terminals
> repeat the same effect?

Yes. Coincidentally I've just been refurbishing one - a Teleray 3931.
It's an ASCII/APL terminal, overstriking was included for the APL mode.

http://madrona.ca/e/teleray3931/index.html

Note the screenshots in APL mode.



Re: when was memory "above" the terminal screen invented?

2020-12-14 Thread Brent Hilpert via cctalk


On 2020-Dec-13, at 6:37 PM, Stan Sieler via cctalk wrote:
> ...
> When was the concept of memory "above" the screen invented for terminals?
> 
> I.e., previously displayed data that had scrolled up and off the screen ...
> but could be retrieved (usually by scrolling down).
> 
> (Sometimes called "scrollback", or "offscreen memory".)
> 
> (BTW, I'm talking about terminal-local memory, not a scrollback implemented
> by the computer to which the terminal is connected.)
> 
> The HP 2640A, 1974, had (IIRC) several pages of memory available ... the
> user could scroll
> backwards and see what had been on the screen before it scrolled off (as
> long
> as it hadn't been lost by having too much subsequent output).
> 
> I suspect the DEV VT100, 1978, had it, but I can't find definitive proof
> online (sure, I can find VT102 emulators that have scrollback, but reading
> an old VT102 manual doesn't make it clear that it has it.)


If it fits your definitions, you might look into the Teletype Model 40 if more 
info to that below can be found.

On pdf.pg.60 of this article:

http://www.bitsavers.org/pdf/datapro/alphanumeric_terminals/Datapro_C25-010_197904.pdf
the Model 40 is shown with "Paging: Opt. 2/3 pages" and "First production 
delivery: 10/73"



Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Brent Hilpert via cctalk
On 2020-Oct-04, at 1:55 PM, Chris Hanson wrote:
> On Oct 4, 2020, at 1:53 PM, Brent Hilpert  wrote:
>> 
>>> For the latter two, I need to figure out whether my backplane supports ABCD 
>>> use in the first couple of slots, or if it’s purely an ABAB model. (The 
>>> KDF11-A, RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to 
>>> interpret that as ‘these were configured together in this pattern” rather 
>>> than “these happened to fit in here for storage.”)
>> 
>> I have an ~ 30 page manual for the MDB MLSI-BA11-600 series chassis, if 
>> there is something that might be answered from that.
> 
> Whoa, cool—that’s the chassis I have! Is the manual scanned?

Photographed. No scanner.
It's not as good as 600dpi scan, but pretty good.

I'll send access url.



Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Brent Hilpert via cctalk


On 2020-Oct-04, at 1:14 PM, Chris Hanson via cctalk wrote:

> Thanks to everyone who replied, on- and off-list! There’s an MXV11-B (M7195) 
> on its way to me. :)
> 
> Since people were asking about my setup, here’s what I have:
> 
> - MDB BA11-clone enclosure, PSU, and 8-slot 22-bit backplane
> - DEC KDF11-A (M8186) rev C processor with FPP added
> - DEC DLV11-J (M8043) SLU
> - Motorola M1132 128KW RAM
> 
> And some stuff that’s untested but I’m eager to try:
> 
> - (soon) Emulex UC07 SCSI controller
> - (soon) DEC MXV11-B (M7195) system controller
> - DEC MSV11-LF (M8059) 64KW RAM
> - DEC DEQNA (M7054) Ethernet controller
> - DEC RLV12 (M8061) RL01/02 disk controller
> - MDB MLSI-SCM11 system controller
> 
> For the latter two, I need to figure out whether my backplane supports ABCD 
> use in the first couple of slots, or if it’s purely an ABAB model. (The 
> KDF11-A, RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to 
> interpret that as ‘these were configured together in this pattern” rather 
> than “these happened to fit in here for storage.”)

I have an ~ 30 page manual for the MDB MLSI-BA11-600 series chassis, if there 
is something that might be answered from that.


> I’m actually still looking for docs on the MSLI-SCM11, since it looks 
> extremely configurable and I have no idea how to use it or what it’ll provide…



Re: Identifying mystery TI ICs (Motorola MDP-1000 investigation continues...)

2020-10-04 Thread Brent Hilpert via cctalk
On 2020-Oct-04, at 1:22 AM, Josh Dersch via cctalk wrote:

> More mysteries while poking at the MDP-1000.  Spent some time this evening
> working out the rest of the signals on the power harness (I suspect inputs
> for an LTC circuit and a "power good" signal, as well as something
> connected to a relay on the backplane, probably related to power control).
> 
> There are a lot of unidentifiable ICs on the main CPU logic board and on
> the backplane, mixed in with bog-standard 7400-series TTL.  Curious if
> anyone has any ideas, as my searches and perusal of datasheets/databooks on
> Bitsavers have turned up nothing.  These are all TI-manufactured ICs, 1969
> manufacturing dates, with "SN48xx" and "SN63xx" part numbers (a few omit
> the "SN" prefix.)  I'm wondering if these are just standard 7400 ICs with
> special codes; for example there are several SN4816's near the edge
> connector for the I/O bus, where a 7416 might (?) make sense, and from some
> basic probing and following traces I think the pinouts make sense.
> (Everything's conformal coated so it's a real bear to beep things out...)
> 
> Any ideas?

I have run across TI ICs from that era with odd/unknown series numbering, in 
particular the SN3900 and SN4500 DTL ICs.
Notably:
- by pinout they match up with standard DTL series ICs,
- I have only found these in equipment from one manufacturer: 
calculators built by Canon.

I received a solitary page of datasheet for some of them (by way of a Canon 
service center many years ago), but I have never seen them mentioned in TI 
databooks from the era, even in those sections where they list e.g. "other 
products from TI" and proceed to list little known series and part numbers.

So an obvious guess is these were house numbering systems of standard parts 
done for the purchaser/equipment manufacturer but with TI's format scheme 
rather than a format specified by the manufacturer. Another guess would be 
standard parts tested and selected for purchaser-specified parameters, although 
that seems a little excessive for these cases.

The 54/7400 series originated with TI in 65, I'm not aware of them producing 
any other TTL series, other than perhaps second-sourcing some other 
manufacturer's.
I guess that's another possibility - another manuf's TTL series, labeled 
differently.

Odd that this Motorola CPU is filled with ICs manufactured by TI.

It's conceivable, although it seems less probable, that they're DTL rather than 
TTL.

On the whole, best guess would seem to be 7400-series inside.

--

On another issue, did you trace the +/-15V lines to the core address/inhibit 
drivers?
Could some of the remaining wires from the PS be other core supplies - 15V was 
a little low compared to most core systems I've seen.



Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives

2020-10-02 Thread Brent Hilpert via cctalk
On 2020-Oct-01, at 2:03 PM, Paul Koning via cctalk wrote:
>> On Oct 1, 2020, at 1:20 PM, dwight via cctech  wrote:
>> 
>> It is going to need a lot of contact cleaning.
>> The one thing I like is the carry design the Zuse used. Really fast for 
>> relays but not of much use for solid state.
>> Dwight
> 
> Where did you find that?  I looked through the document that was posted and I 
> don't see that detail in it.


On 2020-Oct-01, at 2:38 PM, Eric Smith via cctalk wrote:
> Where is that circuit described?


Try a search for "zuse adder", although I haven't gone through the results to 
see which one provides a 'good' explanation, but it looks like there are 
explanations out there.

If I may, and in the following I hope I'm not conflating things, as it was some 
years ago I looked at this stuff:

The idea is that a set of relays are energized in accordance with the state of 
the bits of the two operands.
This can occur in parallel so is fast (one relay-unit-delay).
Contact logic of those relays produces the sum, carry and not-carry for each 
bit,
and the carries are wired sequentially through the contact logic of all bits.
There are no intervening relays, and no relay energization is dependant upon a 
preceding relay in the bit sequence.
Thus the entire sum and final carry are available immediately (at electric 
speed) after the one relay-unit-delay.
No mechanical-speed ripple carry.

If you try to do this with relays in a more 'obvious' manner you end up with a 
mechanical ripple delay down the bits.

I'm not sure how unique this is to Zuse however.
The raw design presented in the Radio-Electronics/Edmund Berkeley Simon 
articles of 1949/50 presents this scheme,
although more complex (unoptimised) in the contact logic.
This is post-Zuse of course, but it's a question and investigation as to how 
the design may have gotten from Zuse to the US/Berkeley in those years.
That is, I wonder if it's a design that was arrived at independently in 
multiple places, or did it all derive from Zuse.

When I was figuring-out/recreating the design of 'Simon' some years ago, I 
optimised the RE/Simon adder design down considerably.
That's written up here, in the ALU/adder section:
http://madrona.ca/e/simon/imp.html
The schematic there presents the idea.
Some years later I ran across the Zuse design and found I was one optimisation 
short of Zuse
(IIRC, one more contact could be optimised out and it would match the Zuse 
design).
I've been long meaning to add the Zuse circuit into that page to present the 
further optimisation.

Re: [GreenKeys] Omaha craigslist - Teletype RO printer - what model?

2020-08-03 Thread Brent Hilpert via cctalk
On 2020-Aug-03, at 12:34 PM, John Foust via cctalk wrote:

> At 12:56 PM 8/3/2020, Nick England wrote:
>> Looks interesting - I know nothing more
>> https://omaha.craigslist.org/sys/d/omaha-heathkit-h19-terminal-vintage-old/7170438478.html
>> 
>> What model printer is that? typewheel, not dot matrix.
> 
> Any ideas over here?


The type cylinder and other visible construction details appear consistent with 
the Model 33 mechanism.
(as in the well-known Model 33-ASR / ASR-33. ASR = Automatic Send Receive).
Perhaps then, a Model 33-RO (Receive Only).

While there's tractor-feed paper in there, it doesn't appear to actually be a 
tractor-feed drive.

Re: Any interest in "newer" hardware, software?

2020-07-28 Thread Brent Hilpert via cctalk


On 2020-Jul-28, at 6:40 PM, Jay Jaeger via cctech wrote:

> On 7/28/2020 1:43 PM, Brent Hilpert via cctech wrote:
>> 
>> Per the OP's machine, the early HP21xx machines were based on CTµL, for 
>> which the main supply is +4.5V.
>> DTL and TTL chips in these machines ran off that 4.5 supply.
>> 
> 
> The DTL I referred to in my posting are in a third-party (IOMEC) disk
> controller, not the HP 2114 CPU.

Oh, I take it you mean in a separate chassis with it's own power supply then.
(I thought you were referring to the interface boards in the CPU chassis).



Re: Any interest in "newer" hardware, software?

2020-07-28 Thread Brent Hilpert via cctalk
On 2020-Jul-28, at 4:48 PM, Carlos E Murillo-Sanchez via cctalk wrote:
> 
> So, what would two chips marked
> 
> F  U6A7709393
>  7043

F   : Fairchild

U   : monolithic device (as opposed to e.g. hybrid)
6A  : package, DIP (6), 14-pin (A)
7709: circuit/function code. As Jay suggests, a 709 op amp.
39  : temp range, 0::+70C for linear types
3   : I don't know, in 1966 this was a reserved-for-future-use digit position.

7043: date code of course.

I've seen other analog ICs from Fairchild similarly labeled, e.g. U5B7741393 
for a 741 op amp.


> and
> 
> F   7306
>  7-6987

My guess is a house number 7-6987, with a 7306 date code, made by Fairchild.



Re: Any interest in "newer" hardware, software?

2020-07-28 Thread Brent Hilpert via cctalk
Fairchild part numbers trivia following.


On 2020-Jul-28, at 7:35 AM, Jay Jaeger via cctalk wrote:
> My DTL chips have markings like:
> 
> DT uL93659   (Chip type 936)
> F 7016
> 
> DT uL909759   (Chip type 9097)
> F 7013
> 
> (I expect 7016 and 7013 are date codes.  Not sure what the "59" is about.)

The 59 is the temperature range. For DTµL, 59 is 0C::+75C.



On 2020-Jul-28, at 8:11 AM, Paul Koning via cctalk wrote:
>> On Jul 28, 2020, at 10:35 AM, Jay Jaeger via cctalk  
>> wrote:
>> 
>> DT uL93659   (Chip type 936)
>> F 7016 ...
> 
> Is that DTL or RTL?  Fairchild originally came out with RTL chips, which had 
> uL part numbers like uL914 (dual 2 input NOR) and uL923 (JK flop) in TO cans 
> with 8 leads.


The 936 is DTL.

Fairchild part numbers were a bit of a mess when looked at over their 
production period.
The part numbers did not readily distinguish between logic families.
Some units had the RTµL/DTµL/TTµL labeling, but that was not always present 
(the Fairchild labeling there actually is mu/micro rather than u).

Some examples of the mish-mash:
 901 : RTµL
 915 : RTµL
 926 : RTµL
 936 : DTµL
 946 : DTµL

 960 : CµL
 961 : DTµL

9007 : TTµL
9097 : DTµL
9997 : RTµL

There was often an additional 9 in front of the 3-digit types.
e.g. 9936 is DTµL 936.

Even the 59 suffix for the temp range, mentioned above, was ambiguous.
59 meant 0::+75C for DTµL, TTµL & CµL,
but 
59 meant +15::+55C for CTµL.


> The supply voltage would tell you; RTL uses 3.6 or so, while DTL uses 6 volts.

Per the OP's machine, the early HP21xx machines were based on CTµL, for which 
the main supply is +4.5V.
DTL and TTL chips in these machines ran off that 4.5 supply.



Re: In search of 4B3A Microswitch Keyswitches (for a restoration, not a keyboard collector!)

2020-07-10 Thread Brent Hilpert via cctalk
On 2020-Jul-10, at 11:27 AM, Ian Finder via cctalk wrote:
> On Fri, Jul 10, 2020 at 11:06 AM Al Kossow via cctalk 
> wrote:
>> 
>> Since it isn't very fancy, I wonder if you could make a new board with a
>> modern Hall
>> effect sensor? You just need a contact closure.

> Yeah Al, that's a great suggestion. I was looking at the AH1815 last night.
> The challenge is getting the whole assembly as thin as the original, which
> presents a not insignificant challenge-
> 
> Even using the SOT553 package of this:
> https://cdn.sparkfun.com/assets/4/4/8/2/a/AH1815.pdf - I'd have to do some
> trickery, like have it mount into a hole into the center of the board.


Reading that datasheet, it appears that to reduce power consumption those 
sensors employ pulsed sleep/wake operation, presenting up to a 1/8 second delay 
in response time. Probably not very good for use in a keyboard, and something 
to watch out for if looking for a modern replacement sensor.



Re: In search of 4B3A Microswitch Keyswitches (for a system restoration, not keyboarding)

2020-07-10 Thread Brent Hilpert via cctalk
On 2020-Jul-09, at 10:12 PM, Ian Finder wrote:
>> On Jul 9, 2020, at 21:58, Brent Hilpert  wrote:
>> On 2020-Jul-09, at 9:39 PM, Ian Finder via cctalk wrote:
>> 
>>> I know what you guys are thinking- no, this isn't for a keyboard collection
>>> or some modern build or some other nonsense like that.
>>> 
>>> I have a friend who is restoring a fairly interesting and historically
>>> significant vintage computer-
>>> The correct SD-series replacement switch would be the 4B3A-
>>> 
>>> *** These can allegedly be found on some of the Diablo printing
>>> terminals.***
>>> 
>>> Subject to what /appears/ to be a batch-related encapsulation failure in
>>> the glue on the proprietary hall effect sensors, around a little over half
>>> of the switches on the current keyboard are bad.
>>> 
>>> It is possible other switches ending in ***A could be made to work with a
>>> bit of labor and disassembly (swapping the fairly brittle sensors).
>>> 
>>> I am not a keyboard expert but I have learned that you can remove a key on
>>> some of these microswitch keyboards and read the model fairly easily on
>>> each switch.
>>> 
>>> Please let me know if you have a lead on a donor for these switches. They
>>> will be put to good use, and you can reply to me off-list for more details.
>> 
>> Are these the key-switch model which snap into a thin-gauge springy 
>> stainless-steel U-channel to form the rows of the keyboard?

> No, as I understand it that is the predecessor

OK, too bad, in my parts stash I have an orphan (caseless) made-by-Microswitch 
keyboard from 1975, using the key-switch type as I described.

I had a couple of the key-switches open years ago. According to my notes there 
are two types of key-switch, one for characters (black plunger) and one for 
modifiers (shift,ctl) (green plunger), the chip IDs (inside the key-switches) 
are 42B and 40H respectively.



Re: In search of 4B3A Microswitch Keyswitches (for a system restoration, not keyboarding)

2020-07-09 Thread Brent Hilpert via cctalk
On 2020-Jul-09, at 9:39 PM, Ian Finder via cctalk wrote:

> I know what you guys are thinking- no, this isn't for a keyboard collection
> or some modern build or some other nonsense like that.
> 
> I have a friend who is restoring a fairly interesting and historically
> significant vintage computer-
> The correct SD-series replacement switch would be the 4B3A-
> 
> *** These can allegedly be found on some of the Diablo printing
> terminals.***
> 
> Subject to what /appears/ to be a batch-related encapsulation failure in
> the glue on the proprietary hall effect sensors, around a little over half
> of the switches on the current keyboard are bad.
> 
> It is possible other switches ending in ***A could be made to work with a
> bit of labor and disassembly (swapping the fairly brittle sensors).
> 
> I am not a keyboard expert but I have learned that you can remove a key on
> some of these microswitch keyboards and read the model fairly easily on
> each switch.
> 
> Please let me know if you have a lead on a donor for these switches. They
> will be put to good use, and you can reply to me off-list for more details.

Are these the key-switch model which snap into a thin-gauge springy 
stainless-steel U-channel to form the rows of the keyboard?

Re: Ever seen a Cromemco Cyclops in the wild?

2020-06-09 Thread Brent Hilpert via cctalk
On 2020-Jun-09, at 6:21 AM, Shoppa, Tim via cctalk wrote:
> I think a Stanford AI lab has one in a display case. Any others out there?
> 
> It was supposedly "commercial" but I don't even remember ever seeing an ad 
> for the Cyclops from Cromemco and I had a really good stash of Cromemco 
> literature and hardware.
> 
> I do remember the BYTE article where you pop the top off of a DRAM chip to 
> make a Camera but that was 1983-ish, nearly a decade after the Cromemco 
> Cyclops was supposedly "commercial". In the discussions I had in the 80's 
> none of us seemed to know about the Cromemco Cyclops having preceded it.



As a teenager, I assembled a Cyclops from kit in 1977. An EE friend of my dad 
had an IMSAI for which I had been
assembling boards back to at least mid '76. He obtained the Cyclops and the 
S100 interface board for it,
and I assembled them. This was the model in a small blue diecast Al case with a 
lens on one end,
internally there were 3-4 little boards that slid into board slots formed in 
the Al case.

When I took the assembled units back to the friend and IMSAI and we tried it 
out, it didn't work.
So I went home and constructed from scratch the oscilloscope interface (7 or 8 
ICs) for the camera
that could allow it to be used and tested without the added complexity of the 
S100 interface, computer, software, etc.
The schematic for that was included in the Cyclops documentation. I still have 
the mylar-&-stick-on-graphics artwork
I made up to produce the PCB for it, which I just confirmed the '77 date from.

I never saw it produce an image though, the stuff was left with the EE friend 
and I don't know whether he was
eventually successful with it or not.



Re: Someone's confused

2020-06-07 Thread Brent Hilpert via cctalk
On 2020-Jun-07, at 8:30 AM, Noel Chiappa via cctalk wrote:
> Love the title on this:
> 
>  https://www.ebay.com/itm/184317705963
> 
> eBait auction: "16K Sense Inhibit Board .. VAX 6000, VAX-11/730".
> Yeah, core on a VAX! And such a deal, a mere US$400!

To add to the weirdness, here are some actual core boards (the module 
companions to the above board?),


https://www.ebay.com/itm/DEC-Digital-Core-Memory-H-217C-13258-H217C-1210711/111384020221

https://www.ebay.com/itm/DEC-Digital-Core-Memory-H217D-H2127D-6207/111384018413

Same "VAX 6000 / VAX-11/730", but from a different seller.

Re: MicroVAX 3100 Model 95 Ripple

2020-05-09 Thread Brent Hilpert via cctalk
On 2020-May-09, at 9:32 AM, Rob Jarratt via cctalk wrote:
> I have recently been trying to improve the ripple on the output of my
> MicroVAX 3100 Model 95 PSU because occasionally it would fry a memory
> module. I replaced a bunch of capacitors, some of which had started to leak.
> However, the ripple does not seem much better. There is a scope trace here: 
> 
> https://rjarratt.files.wordpress.com/2020/05/microvax-3100-model-95-psu-ripp
> le-after-re-capping.png
> 
> Ch1 is the 12V output and Ch2 is the 5V output. I had an old RD53 connected
> as a dummy load. It is possible that the memory was breaking because of
> occasional spikes that are worse, but I don't know. Does that seem OK?


Two guesses come to mind, but a lot depends on, or greater insight might be 
gained from, knowing the design configuration of the power supply.

The spikes are suggestive of ringing from a fast and undamped switching 
operation. Might be from switching of the primary-side driver, or from the 
switching of the secondary-side rectifiers in the conduction/non-conduction 
cycle.

More scope observation and knowledge of the design might sort out whether the 
spikes are synchronous to the primary driver vs. the sec rectifiers.

Guesses:
- The snubbing/damping C/L/diode networks around the primary winding of the 
transformer.

- The snubbing caps (usually) paralleling secondary-side rectifiers.
As the spikes look to be heavier on the 5V circuitry, it may be those on the 
12V output are 'just' induced reflections through the transformer from what's 
happening on the 5V circuitry.




Re: Hopefully on topic

2020-05-05 Thread Brent Hilpert via cctalk
On 2020-May-04, at 8:10 PM, Martin Crockett via cctalk wrote:
> ..
> I noticed there is a capacitor that has vaporized, but I cant determine
> what value it is.
> 
> I have the DEC VT-100 maintenance guide but it is very blurry in the
> relevant area.
> 
> I cant even read the board designation.
> 
> This is the area of the circuit, I can trace the 2 Zener diodes on the -23V
> rail, to one end of the cap, the other end seems to go to ground. The
> obvious culprit is C6, but that doesn't match the mud map of the board, as
> in C1x.
> https://imgur.com/a/tm8mn8b
> 
> This is the capacitor in question.
> 
> It looks like C1x where x is undetermined.
> 
> I think it was a ceramic monolithic capacitor, it seems to be different to
> any other caps on the board, i.e. slightly larger and a different colour
> blue. When I look at this hires photos on Google images, it is the blue
> capacitor circled below
> 
> Does anyone have a VT-100 and mind checking what the value of this
> capacitor is please?
> Ideally value and voltage or even just the nomenclature written on it, I
> can work out the value and voltage from that.



You sure that isn't C14, connected to pin 2 of E24, Vgg PS pin on the 
non-volatile RAM?
(bitsavers schematic pdf pg 15 / "VT100 BASIC VIDEO Sheet 2 of 6" / upper 
middle of page).
See also the board pics on bitsavers.

0.22uF, 50V CER



Re: Ok, got the Perq tapes

2020-04-26 Thread Brent Hilpert via cctalk
On 2020-Apr-26, at 4:33 PM, Chris Zach via cctalk wrote:
>  Latest pictures are at https://www.crystel.com/bob .


https://www.crystel.com/bob/DSC_0255.JPG

HP 9825 (the ochre keyboard) underneath the PCB.



Re: Great, my VT52 is shot.

2020-04-21 Thread Brent Hilpert via cctalk
On 2020-Apr-21, at 8:35 PM, Chris Zach wrote:
>> The D8 5V ref and the targetted output V are divided via R15 and R17,R18 to 
>> provide the sense input at E2.2.
>> If one does the R ratio of the three resistors, it comes out, as would be 
>> expected, to ~ 0V.
> 
> Ah hah, that is clever. I wonder if the .8 volts means the output is higher 
> than what should be expected and the op amp isn't amping down or something. 
> However if the op amp was blown it should just allow full voltage through. 
> Maybe (is there a crowbar circuit in there).
> 
>> I'm a little surprised there's that much difference between E2.2 & E2.3 ( 
>> (-0.022) - (-0.8) ) without sending the E2 output off to +V, but not sure 
>> how much device variability to expect normally.
> 
>> You might look for the on-board values of R15,17,18. If they have been 
>> changed from those values specified in the schematic, then the -12 may have 
>> been changed to -15 (could do the ratio calc).
> 
> I tried measuring the resistance in circuit, but that never works. It's 
> possible they are measuring out properly and that .6 volts is the 
> representation of too much voltage at the output side (-15 instead of the 
> expected -12).

Look at the marked (as opposed to measured) values of the (3) installed Rs, to 
see if they have been intentionally changed in a revision to alter the output V.


>> Also what is the V at Q4.E (should be ~ +2.6V), also Q4.B & C.
> 
> I'll check that tomorrow. Connecting Q4.E to B did bring the output voltage 
> down to pretty much zero so that does seem to work.

When Q4.BE shorted, E2.6 should swing well-negative.


> If I can't figure this out I might just pull Q10 and put a 7912 in its place. 
> One chip does the whole job of regulating the output, end of story. Bad me of 
> course, but what the heck and if the display came up I would know where the 
> problem was.
> 
> If it turns out the op amp is dead, would a 741 work as a replacement?

Note comment lower left corner of schematic page.

Re: Great, my VT52 is shot.

2020-04-21 Thread Brent Hilpert via cctalk
On 2020-Apr-21, at 5:27 PM, Chris Zach via cctalk wrote:
> Meantime reading the manual I found an interesting test: If you short emitter 
> to base on Q4 (easiest way is to jumper diode D10) the voltage on the -12v 
> supply goes to .4 volts. They're saying it's E2, R15,R17,R14.
> 
> Is there a way I can test the op-amp in circuit? Maybe it's dead.


The three regulators are all referenced via D8 (~ +5V).

Circuit-wise, for the -12, 0V/GND is the reference input at E2.3.
The D8 5V ref and the targetted output V are divided via R15 and R17,R18 to 
provide the sense input at E2.2.
If one does the R ratio of the three resistors, it comes out, as would be 
expected, to ~ 0V.

I'm a little surprised there's that much difference between E2.2 & E2.3 ( 
(-0.022) - (-0.8) ) without sending the E2 output off to +V, but not sure how 
much device variability to expect normally.

You might look for the on-board values of R15,17,18. If they have been changed 
from those values specified in the schematic, then the -12 may have been 
changed to -15 (could do the ratio calc).

Also what is the V at Q4.E (should be ~ +2.6V), also Q4.B & C.


> On 4/21/2020 5:36 PM, Chris Zach via cctalk wrote:
>> Ok, some test results below.
>> 1) Are we sure J2-2 should be -12? It really seems to like being -15.
>> 2) The voltage across the zener diode there is a nice solid -3.8-3.9v. It 
>> appears to be a germanium diode (.1v drop across, both directions) I could 
>> disconnect it and see if that makes things better.
>> 3)

>> E2.2 is -.8 volts referenced to ground.
>> E2.3 is -22mv referenced to ground
>> E2.6 is around .6v. Ramps up from about .58 at startup to .61 then down to 
>> .60something. Note that is a positive voltage wrt ground.
>> Q12 was reading
>> -24.4v emitter
>> -15v collector
>> -23.8v base
>> Q12 does not have a CE short
>> What is this using as a reference to get the -12v from the transistor?



Re: Great, my VT52 is shot.

2020-04-21 Thread Brent Hilpert via cctalk
On 2020-Apr-21, at 7:57 AM, Chris Zach via cctalk wrote:
> Well I'm starting to walk through this. First I took an IR picture of the 
> boards in operation, then started troubleshooting.
> 
> First I started checking voltages. J2 is easily accessible so I put a ground 
> probe on pin 10, and checked voltages as follows:
> 
> J2-3 Should be -5v, reading -3.8v
> J2-2 Should be -12v reading -15v
> J2-4 Should be 5v, reading 5.04v
> J1-10 Should be 15v reading 14.84
> 
> Hm. That's odd. Looks like the negative voltages are a bit off.
> 
> According to the schematic the key transistor on the 5v rail is Q6, which is 
> a 2n3055. The key transistor on +15 is Q10 and that circuit looks ok. However 
> whatever is running the -5 and -12 volts is not working right Looks like 
> Q12 is the key power transistor there with E2 serving as the control.
> 
> Hm

It's conceivable there was a revision change where the -12V was changed to 
-15V, but it does seem unlikely.

The -12 is used by the vertical deflection circuit, the CRT filament, (and the 
RS-232).

I wouldn't immediately anticipate -12 going to -15 alone would produce the 
upset you're seeing on the screen but there could well be interrelated failures 
between the vertical deflection and the over-voltage -12, so the excessive -12 
should probably be addressed.

In the power supply, you could measure some voltages around the -12 regulator.

E2.2 and E2.3 should be around 0V.
E2.6 I expect would normally be within +/- 2V of GND.
If E2.6 is way-positive (>Q4.E, > ~ +2.6V), then E2 is attempting to throttle 
down the output but failing due to some failure around Q4/Q12.

Measure the voltages on Q4 and Q12.
They could be leaky or low-gain.
It's conceivable Q12 has a CE short, but I'd expect the input to the reg to be 
more than -15.

The low -5 is odd, zener D14 looks to be a 5.1V type.
R45 is probably burning up.
I haven't spotted anything in the schematic that actually uses the -5,
it looks to be provided for some alternative character generator (schematic 
pdf.42),
so that may depend on what character generator chip / daughter board is used in 
your unit.



Re: Great, my VT52 is shot.

2020-04-19 Thread Brent Hilpert via cctalk


On 2020-Apr-19, at 3:09 PM, Chris Zach via cctalk wrote:

>> As I wrote earlier in the thread I think it is a good idea to check the V
>> sync and H sync signals to check that they are right in pulse length and
>> shape.
> 
> Good starting point. From the schematics would that be scope probe to J1 pin 
> 5 for horizontal and j1 pin 9 for vertical? Also which is J1, and how are 
> they numbered :-) Also is there a good ground reference point?
> 
> Also is there a document that links the part numbers on the boards with 
> what's on the schematics?
> 
>> There are indeed electrolytic capacitors in the vertical deflection circuit
>> but I am not sure if that would make the beam move much faster since for a
>> faster move of the beam also requires a higher voltage over the deflection
>> coil to create a faster ramp up of the current trough it. But it is
>> definitely worth checking. Especially since the scan lines are sloping a
>> bit and not straight as one would expect.
> 
> I would believe a capacitor failure due to heat, any ones in particular I 
> should check?
> 
>> So do I. And now we need Chris to do some measurements on it to get further.
> 
> More than happy, just haven't worked on TV sets before and would rather not 
> blow off my hand. I'm guessing the really dangerous voltage is the one on the 
> bottom left that comes off the step up transformer over to the odd plug going 
> into the VT52 rear bulkhead (HV to display)


Using the schematic and maintenance manual from bitsavers:
http://bitsavers.org/pdf/dec/terminal/vt52/MP00035_VT52schem.pdf

http://bitsavers.org/pdf/dec/terminal/vt52/EK-VT52-MM-002_maint_Jul78.pdf

Monitor schematic: MP00035_VT52schem pdf-page 10
Monitor board component layout: MP00035_VT52schem pdf-page 8

There are *two* horizontal signals from the logic to the monitor (plus the 
vertical & video).

There are some waveform diagrams for what to expect around the monitor board 
presented in the maint manual: 
EK-VT52-MM-002_maint_Jul78 pdf-page 92

Something else that might help with diagnosis is taking pictures of the screen 
with known, simple elements on the screen.
e.g.:
- clear the screen
- take pic if it doesn't clear
- type a simple character like a "-"or "1"
- pic
- type a half line or full line of characters
- pic
- type different characters on two different lines
- pic

The idea being to find out, from simple known patterns, where the pixels end up 
being displayed,
so it may be possible to figure out what's happening with the scan, whether 
it's getting stretched, folding over, etc.

Yes, you want to watch out for HV around the flyback transformer.
The very HV is reasonably insulated, but there's also a few-hundred volts 
around the open componentry around the focus and intensity controls, the stuff 
feeding the neck end of the CRT.




Re: Another Unrelated PSU Question

2020-04-18 Thread Brent Hilpert via cctalk
On 2020-Apr-18, at 10:03 AM, Rob Jarratt via cctalk wrote:
> I have another PSU I have been meaning to look at for a long time. This one
> has fairly high output ripple and some of the voltages do not appear to be
> where they should be. I have checked all the capacitors for ESR and they
> appear to be OK, with the exception of the two big smoothing capacitors on
> the primary side. One of them appears to be slightly bulging, but has
> low-ish ESR, the other has a much higher ESR. Is it possible that these
> capacitors could be the cause of the out-of-spec outputs?

What frequency is the ripple - mains frequency (50/60Hz) or switching frequency?

If the ripple is at mains frequency then, yes, the problem could be the 
mains/primary filtering. (Primary supply drooping far enough across mains 
cycles that the switcher is affected and unable to maintain drive.)

Either way, you could scope the primary supply under operation (some load), to 
see what the ripple there looks like.



Re: Great, my VT52 is shot.

2020-04-17 Thread Brent Hilpert via cctalk


On 2020-Apr-15, at 5:23 PM, Chris Zach via cctalk wrote:

> Wonderful: A few weeks ago I forgot to turn off my VT52 and left it running 
> for a day or two. Now the screen is filled with snow and it looks like the 
> text is all over the place horozontally.
> 
> Any tips or thoughts on where to start looking to fix? The keyboard seems to 
> be working as does the RS232 input (the snow on the screen changes when the 
> pdp11 talks to it)


Try turning the contrast or brightness up till the black level starts becoming 
illuminated. Is the raster (the screen character field / framing rectangle) 
stable?

If no rectangle or stable display field becomes apparent then as Jon suggests 
it may be loss of sync, probably horizontal, and likely to be in the monitor 
circuitry.

(Any affect from twiddling the H or V sync controls?)

If the raster is stable then it might be something in the character generation 
pipeline (the character generator or the row pixel serializer), or in the 
monitor video amp.

("snow" as a description leaves for a range of possible interpretations.)

There's always checking power supply levels to start with. In addition to the 
+5, there's probably a +/-12 or -5 for the character generator.



Re: VAXmate PSU

2020-04-06 Thread Brent Hilpert via cctalk
On 2020-Apr-05, at 11:12 PM, Rob Jarratt wrote:
>> 
>>> I have obtained a scope trace as you suggest. R32 is still lifted so
>>> the
>>> UC3842 is powered by the bench PSU, but I am using the full 240VAC (no
>>> variac). The channels are:
>>> 1.  Ch1. 555 timer.
>>> 2.  Ch2. D19 Anode
>>> 3.  Ch3. D19 Gate.
>>> 4.  Ch4. Q1 Source.
> 
> Sorry, that looks like a cut and paste error, here is the link to the scope
> picture
> https://rjarratt.files.wordpress.com/2020/04/h7270-primary-scr-trigger.png
> 
> I used a 100ms timebase for the capture and then "zoomed in" a bit 


You would need to zoom in far more to see what's going on when the SCR 
triggers, to cover just a few cycles around the trigger time.

Once an SCR has been triggerred, the gate becomes a voltage/current supply, a 
diode drop above 0.
You see this on your trace in that after triggerring the gate sits at something 
+V above 0.
The spike you see may just be an artifact of the internal SCR trigger action.
I presume you see some increased current draw from your bench supply for the 
3842 after the SCR triggers.

What's up with channel 2? Above you say it's D19 anode which is 3842 Vcc but it 
shows on the trace as just noise around 0V.

I would still suggest that you scope the state of the secondary-side crowbar - 
the gate of Q2, and base of Q4.
Should be simple to do, before trying to remove or disconnect the main 
transformer.


Re: State of New Jersey needs COBOL programmers

2020-04-06 Thread Brent Hilpert via cctalk
Here in Canada, ongoing for several years now, we've had the major fiasco of 
the Phoenix payroll system.
I've never heard an accounting of where the fault lies, or why IBM isn't being 
held more accountable.
A brief summary from Wikipedia:

The Phoenix pay system is a payroll processing system for Canadian federal 
government employees, provided by IBM in June 2011 using PeopleSoft software, 
and run by Public Services and Procurement Canada.
... first introduced in 2009 .. intended to replace Canada's 40-year old system 
with a new, cost-saving "automated, off-the-shelf commercial system."
By July 2018, Phoenix has caused pay problems to close to 80 percent of the 
federal government's 290,000 public servants through underpayments, 
over-payments, and non-payments.
The Standing Senate Committee .. investigated .. and submitted their report, 
"The Phoenix Pay Problem: Working Towards a Solution" on July 31, 2018, in 
which they called Phoenix a failure and an "international embarrassment"
Instead of saving $70 million a year as planned, the report said that the cost 
to taxpayers to fix Phoenix's problems could reach a total of $2.2 billion by 
2023.



Re: VAXmate PSU

2020-04-05 Thread Brent Hilpert via cctalk
On 2020-Apr-05, at 2:53 PM, Rob Jarratt wrote:
> I have obtained a scope trace as you suggest. R32 is still lifted so the
> UC3842 is powered by the bench PSU, but I am using the full 240VAC (no
> variac). The channels are:
> 1.Ch1. 555 timer.
> 2.Ch2. D19 Anode
> 3.Ch3. D19 Gate.
> 4.Ch4. Q1 Source.
> The picture is here:
> https://rjarratt.files.wordpress.com/2020/04/h7270-control-pulse-width-modul
> ator.png
> 
> 
> You are correct, I have mixed up the values with R30 and R31, the correct
> value is 15K. I have updated the schematic, and rearranged it to look
> diagrammatically more like a sample diagram in the TI datasheet for the
> UC3842. The updated schematic is here:
> https://rjarratt.files.wordpress.com/2020/04/h7270-control-pulse-width-modul
> ator.png


The links for pic and schematic don't seem to be correct.
I picked up a modified 15K+15K schematic from the blog web page but haven't 
found the scope pic.

Keep in mind at a low scope timebase resolution (long timebase) (as per your 
previous scope pics), a brief spike on R13 may not show up in the scope display 
(too brief for the discrete per pixel display interval, but it could have 
charged C18 enough where it will linger longer and show up on the display. DSOs 
can present some vagaries like this. If you haven't done so, examine the traces 
at a higher timebase resolution (it could have been recorded in the sampling, 
just not being seen).



Re: VAXmate PSU

2020-04-05 Thread Brent Hilpert via cctalk
On 2020-Apr-05, at 6:05 AM, Rob Jarratt via cctalk wrote:
> I found time to follow Mattis’s suggestion today and I got some interesting 
> results.
> 
> I powered the UC3842 with about 16V from a bench power supply. I lifted R32 
> so that the transformer would not supply it. I then used an isolating 
> transformer to power a variac and applied the variac to the AC inlet. I also 
> used a load board from a MicroVAX 2000 and an old RD53 disk as the load, so 
> there should be enough load.
> 
> I found that I can vary the AC input up to a maximum of about 40VAC before 
> the SCR triggers, the  5V output reaches about 400mV. If I raise the AC input 
> more slowly, it will usually cut out before that, around 30VAC. I noticed 
> that the inrush thermistors also get quite hot at these low AC voltages, I 
> don’t know if this is because of the relatively low AC supply voltage, or if 
> this indicates a problem of some kind.
> 
> The voltage coming out of L3 into the T1 “bounces” somewhat. I guess this is 
> because the AC input is only 20V or so, or it may be expected ripple from the 
> smoothing capacitors? In the description below, the peaks of the bounces are 
> used. Throughout the variation from 0VAC to 40VAC the duty cycle of the 
> oscillation of the UC3842 output does not change, I guess because the output 
> voltage has not reached its target value.
> 
> With the AC input at about 25VAC the circuit seems to be stable (apart from 
> the bounces mentioned above). At this supply voltage, the voltage at the 
> source of Q1 reaches 2V. The current sense resistor is 1 Ohm, which means 2A 
> must be flowing through it at that time.
> 
> When the Q1 source is at 2V, the other end of R14 is at about 0.5V, which is 
> just below the trigger voltage for the SCR. This makes sense because R14 and 
> R15 form a voltage divider that looks to be nominally 25% of the Q1 source. 
> Given the SCR nominally triggers at about 0.8V, this means that the current 
> sense resistor is set to trigger the SCR at about 2.5A, I think. This would 
> suggest that the duty cycle on Q1 is too high and causing too much current to 
> be drawn. So presumably the feedback to the UC3842 is not working correctly.
> 
> I tried setting the AC input at 120V and using a one-shot sample. Q1 is 
> switched for about 30ms and then there is a spike on the SCR gate to 2V and 
> it triggers. The gate voltage then remains at 1V. However, there is no spike 
> across the current sense resistor (R13), so I don’t know if the spike is 
> because the SCR is being turned for some other reason. There is nothing 
> unusual on the anode of D19 to cause it to trigger due to avalanche 
> breakdown. I got the same result when the AC input was 220V. I wonder if the 
> SCR is behaving slightly differently because I have lifted R32?
> 
> Since there might be a feedback problem, I looked at the VFB input to the 
> UC3842 when doing a one-shot test at 240VAC. I can see VFB steadily rise over 
> the period when Q1 switched, up to a maximum of 4V. I don’t really know if 
> this is how it should behave though, but it seems to make logical sense. 
> During all that time the duty cycle of Q1 does not change.
> 
> I am not too sure where to go from here. I hope the above makes sense. I 
> would appreciate any further thoughts.


Switching power supplies are, to coin a phrase, voltage/current-ratio power 
translators.
They will attempt to adjust the (cycle-averaged) input-current demand in 
inverse proportion to the input voltage, to meet the power demand of the load.

When you load a switching supply, and run it with a low input voltage, it will 
attempt to increase the input-current demand, either with increased peak 
current or increased duty-cycle (ON-time of primary switching transistor(s)).

Suppose you have a load demand of 100W. At 100V input the input current needed 
is 1A.
At 10V input, the input current needed is 10A.

If a supply is not explicitly designed for low supply voltages, it can lead to 
excessive primary-side currents.
This is why it is a bad idea to 'run up' switching supplies from a variac or 
otherwise run them outside their specced input voltage range.

You don't say what the observed duty-cycle (ON-time) is. What would be expected 
is it's running 'wide-open' because it's trying to get enough energy through 
the transformer to meet the load demand while gasping for resources from the 
input because the input voltage is so low.

So from the scenario you've set up, it's difficult to discern whether the 
behaviour is normal or faulty (the scenario masks the otherwise-observed faulty 
behaviour).

All this is also dependant on how large your dummy load is (as a % of the rated 
max power output of the supply).

If you want to run at a low input voltage, remove or very lightly load the 
output.
From your schematic, there is a small load presented internally from various 
voltage dividers around the outputs, although not all the R values are in the 

Re: Vaxstation 400/90 power supply

2020-03-23 Thread Brent Hilpert via cctalk
On 2020-Mar-23, at 6:56 AM, emanuel stiebler via cctalk wrote:
> I have 4000/90 which behaves funny. It only starts, after switching on
> twice. The first time, all LEDs stay on, flipping the switch off/on, it
> boots happily.
> 
> Any insight?


I've experienced behaviour like this in an Apple-something.
It related to a dead RTC/boot-ROM battery. I figured it out (years ago) but now 
forget the exact mechanistics, but it was along the lines of the first power-on 
leaves enough charge in a capacitor for the subsequent power-on to see the 
RTC/ROM as at least 'valid', albeit not 'correct', if you get my drift.

That's just a suggestion/possibility - I'm not acquainted with the 4000/90 
specifically.

  1   2   3   >