VAXmate PSU

[Mattis Lind via cctalk]

onsdag 8 april 2020 skrev Rob Jarratt :

> I will look at all the suggestions, particularly of a failure on the
> secondary side. Something must have burned up, because there was a distinct
> burning smell after the initial failure, although I have never been able to
> see any physical damage to anything, despite looking many times.
>
>
Aha. Don’t think I seen you writing about that before, or did you? It might
be very hard to find the source some times. Even just a small burn will
give quite some smell. Check ALL semiconductors very carefully.

>
>
> But the thing that really puzzles me is that, after correcting the probes
> to include the D19 anode, there doesn’t seem to be anything that would
> cause D19 to trigger. Am I reading the trace wrong?
>
>
It is very hard to tell from the traces what is going on since the
resolution is too low.  Use a faster timebase. 5 or 10 microseconds. Find
out if you can trigger on something that happen only when it stops. Like
channel 2 negative slope.

/Mattis

>
>
> Thanks
>
>
>
> Rob
>
>
>
> *From:* Mattis Lind 
> *Sent:* 08 April 2020 07:42
> *To:* r...@jarratt.me.uk; Rob Jarratt ;
> General Discussion: On-Topic and Off-Topic Posts 
> *Subject:* Re: VAXmate PSU
>
>
>
>
>
>
>
> Den ons 8 apr. 2020 kl 00:34 skrev Rob Jarratt via cctalk <
> cctalk@classiccmp.org>:
>
>
>
> > -Original Message-
> > From: cctalk  On Behalf Of Brent Hilpert
> via
> > cctalk
> > Sent: 06 April 2020 21:07
> > To: General Discussion: On-Topic and Off-Topic Posts
> 
> > Subject: Re: VAXmate PSU
> >
> > 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.
>
> Oh dear! After Brent's question about D19 anode, I realise that the probe
> was connected to the cathode! I have now done it again with the probe
> connected to the anode. I have taken two images of the same capture, one at
> low resolution to show the overall behaviour
>
> https://rjarratt.files.wordpress.com/2020/04/primary-side-shutdown-1.png
>
> And one zoomed in to show what happens when the SCR shuts down.
>
> https://rjarratt.files.wordpress.com/2020/04/primary-side-
> shutdown-detail-2.
> png
>
> The channels are the same as before, namely:
> Ch1. 555 timer.
> Ch2. D19 Anode (now corrected as it was previously the cathode!)
> Ch3. D19 Gate.
> Ch4. Q1 Source.
>
> I got an earlier trace which showed the D19 anode at 9V, which is under the
> Undervoltage Lockout threshold, but I have not been able to repeat it.
>
> I don't fully understand the debate about using the variac.
>
>
>
> I am not going to debate this either since I know what I have been doing
> for years and it works perfectly well for me. I have fixed the bigger PSUs
> in a VAX 11/750 (one broken switch transistor and multiple broken output
> rectifiers). PSU in NORD-10/S (most carbon composition resistors had gone
> out of spec). PSUs in many smaller machines as well.
>
>
>
> I prefer to work in circuits where I can fiddle around without the danger
> of getting killed all the time. Regardless of use of HV differential probe
> it can be dangerous. Running it on 50VAC with a protection transformer do
> expose a lot of problems already and you can poke around safely in the PSU.
>
> I have not yet seen a problem that wasn't seen at low voltage, but I
> expect there could be semiconductors that experience breakdown that occur
> at lower than specified voltage.
>
>
>
>
>
> However, my
> measurements appear to suggest that when I use the variac the SCR triggers
> because of 

Re: Help installing HP 2000 contributed library in simh

[J. David Bryan via cctalk]

On Wednesday, April 8, 2020 at 13:42, David Williams via cctalk wrote:

> I have some old tapes from my Honeywell 66/60 GCOS days that I
> sometimes wonder if I could still get dumped. 

A number of folks have 800 NRZI/1600 PE/6250 GCR 1.2-inch tape drives 
connected to PCs via SCSI interfaces that can be used to copy physical 
tapes to SIMH tape images.  You might ask on this list to see if someone in 
your area can accommodate you.


> Ah SNOBOL... I discovered that language shortly before graduating HS
> and always wanted to play around with it but never had an instillation
> where I could. 

The HP Orsay (not Grenoble, as I misremembered) implementation is the only 
SNOBOL3 implementation I've used.  There's a free SNOBOL4 implementation 
here for various PC operating systems:

  https://github.com/spitbol/

Actually, it's a SPITBOL implementation, which is a compiled version of 
SNOBOL4; see:

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

I've used the Windows NT version for years; it's still my preferred 
language for string manipulation.  Note that SNOBOL3 and SNOBOL4 are 
different syntactically, though learning one certainly would aid in 
learning the other.


> ALGOL as well. Thanks for the suggestions, I'll check some of that out
> too.

If you're not necessarily wedded to the HP 21xx/1000 architecture, the HP 
3000 simulator and its associated MPE operating system kit from the SIMH/HP 
site has a number of languages preinstalled:

  - BASIC (interpreter and compiler)
  - COBOL 68
  - COBOL 74/85
  - FORTRAN 66
  - Pascal
  - RPG
  - SPL

The latter is HP's proprietary Systems Programming Language, an ALGOL-like 
derivative used in lieu of assembler to implement MPE and most of the 
compilers and utilities.

  -- Dave

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Bill Degnan via cctalk]

On Wed, Apr 8, 2020, 7:15 PM Vincent Slyngstad via cctalk <
cctalk@classiccmp.org> wrote:

> On 4/8/2020 12:34 PM, Bill Degnan via cctalk wrote:
> > . FRTS
> >
> > ..dumps me to the * prompt ...
> >
> > *RKB0:ADVENT.LD  [return]
> > *   [esc]
> >
> > rather than loading ADVENTURE I get the following result:
> >
> > D.F. TOO BIG INIT  
> > MAIN 1740
> > .
>
> Have you seen this?
> https://tangentsoft.com/pidp8i/artifact/48a782b6930cb809
>
> Vinc
>

Thank you.  As said recently I have the SV file making this perhaps moot,
but I better understand the strategy to support pdp os/8 fortran

Bill

>

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Vincent Slyngstad via cctalk]

On 4/8/2020 12:34 PM, Bill Degnan via cctalk wrote:

. FRTS

..dumps me to the * prompt ...

*RKB0:ADVENT.LD  [return]
*   [esc]

rather than loading ADVENTURE I get the following result:

D.F. TOO BIG INIT  
MAIN 1740
.


Have you seen this?
https://tangentsoft.com/pidp8i/artifact/48a782b6930cb809

Vince

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Eric Smith via cctalk]

On Wed, Apr 8, 2020 at 2:54 PM Eric Smith  wrote:

> That stands for "data field too big", i.e., too much data to fit in 4KW.
> That's as opposed to "instruction field", which if too big would mean that
> there's too much code.
> Although I used OS/8 Fortran in the distant past, I never tried to compile
> large Fortran programs or programs that used much data, so I don't know
> what it takes to solve that problem. Maybe there is some way to get Fortran
> to use more than one 4KW field for data, issuing the necessary CDF
> instructions to switch data fields?
>

Checking the OS/8 Language Reference Manual reveals that I was totally
incorrect.
That stands for Data File too big.
"Product fo number of record times number of blocks per record exceeds
number of blocks in file."
So I have no idea how to fix that.

DEC OS/8 Question (getting an error TOO BIG INIT)

[Bill Degnan via cctalk]

Hi,
I am sure this question has come up before, but can anyone advise an OS/8
change I can run to avoid the following issue (below)?  I am unsure if I
need to fix my simh INI file or make more space for the program from the
OS/8 dot prompt, or FORTRAN * prompt.

Running pidp-8i (simh PDP 8i kit)

I load OS/8 and initiate the command from the dot prompt:

. FRTS

..dumps me to the * prompt ...

*RKB0:ADVENT.LD  [return]
*   [esc]

rather than loading ADVENTURE I get the following result:

D.F. TOO BIG INIT  
MAIN 1740
.

(..andkicks me back to the dot prompt).

the INI is the default

reset
set cpu 32k
set cpu noidle
att rk0 ../imagefiles/os8/advent.rk05
boot rk0

what changes are needed?  I searched around, I don't quite understand how
to load an LD file in OS/8 to debug the error.  It may be I have the wrong
RK05 disk, but I'd really like to understand what this error means if
anyone knows.  My physical RK05 disk loads ADVENT as an SV file, I don't
need the extra steps.

Thanks

BIll

Re: Old FORTRAN programs, libraries, graphics

[Lee Courtney via cctalk]

You've seen this, right?

http://www.softwarepreservation.org/projects/FORTRAN

Lee Courtney

On Wed, Apr 8, 2020 at 8:35 AM emanuel stiebler via cctech <
cct...@classiccmp.org> wrote:

> On 2020-04-06 22:48, Douglas Taylor via cctech wrote:
> > Got similar interests here.  I've been using PGPLOT on the Vax since it
> > came out, the price was right!
> > Tried to get it to work with a Tektronix 4207, but something is a little
> > different between it and the 4105 series.
> > I was able to get an old version of Gnuplot (3.4) to compile and run on
> > a Vax alpha under Openvms 8.4.
> > It wouldn't compile on a 32 Vax under OpenVms 7.3, too bad, I had wanted
> > to run gnuplot on that machine.  Maybe I needed an older version of
> > gnuplot.
>
> That's pretty much the setup I was trying. VAX & PDP11, an some fun ;-)
>
> However, a Tektronix Terminal is still not in the budget or space, so I
> will probably go with the RPI 4 setup
>
> https://github.com/rricharz/Tek4010
>
> But probably just use a Ubuntu for the display, as it gives a better
> resolution ...
>
> CHEERS!
>
> > On 4/6/2020 6:00 AM, Dave Wade via cctech wrote:
> >> I have been using PGPLOT but I guess you are aware of that.
> >>
> >> https://www.astro.caltech.edu/~tjp/pgplot/
> >>
> >> I also wonder if you might be interested in
> >>
> >> https://github.com/rricharz/Tek4010
> >>
> >> what I was looking for was a Calcomp Basic Plotting calls to HPGL as
> >> most of my plotters are HPLG and would like to plot some of the
> >> Calcomp sample plots on them
> >>
> >> Dave
> >>
> >>> -Original Message-
> >>> From: cctalk  On Behalf Of emanuel
> >>> stiebler
> >>> via cctalk
> >>> Sent: 05 April 2020 14:22
> >>> To: General Discussion: On-Topic Posts Only 
> >>> Subject: Old FORTRAN programs, libraries, graphics
> >>>
> >>> Being stuck at home, was musing the idea to look into some graphics
> >>> software from the '70's, or early 80's ...
> >>>
> >>> Looking for some wire frames, hidden line removal, 3d graphics...
> >>>
> >>> Any pointers?
> >>>
> >>> View month ago or longer, somebody on this list recovered some large
> >>> package of FORTRAN code, and wanted to invest it, but I think it was
> >>> posted
> >>> under a wrong subject, so I can't find it anymore ...
> >>>
> >>> THANKS!
> >
> >
>
>

-- 
Lee Courtney
+1-650-704-3934 cell

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Eric Smith via cctalk]

On Wed, Apr 8, 2020 at 1:34 PM Bill Degnan via cctech 
wrote:

> D.F. TOO BIG INIT  
> I'd really like to understand what this error means if
> anyone knows.
>

That stands for "data field too big", i.e., too much data to fit in 4KW.
That's as opposed to "instruction field", which if too big would mean that
there's too much code.
Although I used OS/8 Fortran in the distant past, I never tried to compile
large Fortran programs or programs that used much data, so I don't know
what it takes to solve that problem. Maybe there is some way to get Fortran
to use more than one 4KW field for data, issuing the necessary CDF
instructions to switch data fields?

Re: pdp11/05 key?

[Fred Cisin via cctalk]

On Wed, 8 Apr 2020, Joshua Rice via cctalk wrote:
Late to the party, but there’s PDP11 keys sold on ebay here: 
https://www.ebay.co.uk/itm/DEC-PDP-8-PDP-11-Computer-Key-XX2247-Digital-PDP-8E-8I-8L-8S/333296145346?epid=2164686531=item4d99ff93c2:g:nWcAAOSwZtlZ7TIB 

I’m 100% sure your local locksmith / cobblers / hardware shop can do 
it cheaper.


MOST of the other PDP machines use the XX2247 key, which is a tubular one.
But, THIS thread is about the weird one that is NOT tubular.


I have a few padlocks that use tubular keys.  I've been considering 
rekeying them to XX2247, and using one for my shed, since I don't think 
that the thieves around here are into obsolete computers.

I've never re-pinned a tubular lock, so it might be fun.

--
Grumpy Ol' Fred ci...@xenosoft.com

RE: VAXmate PSU

[Rob Jarratt via cctalk]

I will look at all the suggestions, particularly of a failure on the secondary 
side. Something must have burned up, because there was a distinct burning smell 
after the initial failure, although I have never been able to see any physical 
damage to anything, despite looking many times.

 

But the thing that really puzzles me is that, after correcting the probes to 
include the D19 anode, there doesn’t seem to be anything that would cause D19 
to trigger. Am I reading the trace wrong?

 

Thanks

 

Rob

 

From: Mattis Lind  
Sent: 08 April 2020 07:42
To: r...@jarratt.me.uk; Rob Jarratt ; General 
Discussion: On-Topic and Off-Topic Posts 
Subject: Re: VAXmate PSU

 

 

 

Den ons 8 apr. 2020 kl 00:34 skrev Rob Jarratt via cctalk 
mailto:cctalk@classiccmp.org> >:



> -Original Message-
> From: cctalk   > On Behalf Of Brent Hilpert
via
> cctalk
> Sent: 06 April 2020 21:07
> To: General Discussion: On-Topic and Off-Topic Posts
mailto:cctalk@classiccmp.org> >
> Subject: Re: VAXmate PSU
> 
> 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.

Oh dear! After Brent's question about D19 anode, I realise that the probe
was connected to the cathode! I have now done it again with the probe
connected to the anode. I have taken two images of the same capture, one at
low resolution to show the overall behaviour

https://rjarratt.files.wordpress.com/2020/04/primary-side-shutdown-1.png

And one zoomed in to show what happens when the SCR shuts down.

https://rjarratt.files.wordpress.com/2020/04/primary-side-shutdown-detail-2. 

 
png

The channels are the same as before, namely:
Ch1. 555 timer.
Ch2. D19 Anode (now corrected as it was previously the cathode!)
Ch3. D19 Gate.
Ch4. Q1 Source.

I got an earlier trace which showed the D19 anode at 9V, which is under the
Undervoltage Lockout threshold, but I have not been able to repeat it.

I don't fully understand the debate about using the variac. 

 

I am not going to debate this either since I know what I have been doing for 
years and it works perfectly well for me. I have fixed the bigger PSUs in a VAX 
11/750 (one broken switch transistor and multiple broken output rectifiers). 
PSU in NORD-10/S (most carbon composition resistors had gone out of spec). PSUs 
in many smaller machines as well.

 

I prefer to work in circuits where I can fiddle around without the danger of 
getting killed all the time. Regardless of use of HV differential probe it can 
be dangerous. Running it on 50VAC with a protection transformer do expose a lot 
of problems already and you can poke around safely in the PSU.

I have not yet seen a problem that wasn't seen at low voltage, but I expect 
there could be semiconductors that experience breakdown that occur at lower 
than specified voltage.

 

 

However, my
measurements appear to suggest that when I use the variac the SCR triggers
because of what appears to be a genuine overcurrent detected by R13. I think
this is because the duty cycle at low AC input voltages is 50% (rather than
about 10% or less as per the trace I have just taken), and I measured 2V
across R13, which does seem to be enough to trigger the SCR. When I use
220VAC, the voltage across R13 does rise to 6V, which should also trigger
the SCR I think, except that the peak last a lot less and so perhaps the
fact that the 6V last for a brief period is insufficient to trigger it?

 

 

On the issue of duty cycle. If we look at this 

Re: Help installing HP 2000 contributed library in simh

[David Williams via cctalk]

On 2020-04-08 00:26, J. David Bryan via cctalk wrote:

Assuming that your tapes are sources, there are several folks with
operational HP 21xx/1000 computers who probably have paper-tape-reading
capability.  Dumping the tape to a PC-hosted terminal emulator can 
capture
the text into a host-PC file, which can then be loaded into the 
simulator
via the simulated paper tape reader.  So I wouldn't discard them just 
yet.


They won't be discarded until my kids decide that all this crazy stuff 
they inherited isn't meaningful enough to them to keep around. :)



I had retained a stack of 1/2" mag tape dumps of our company RTE system
holding all of the programs I had written over a period of twenty years 
or

so.  A fellow enthusiast in my area (Mike Gemeny) kindly copied them to
SIMH-compatible tape images, which I was then able to use to recreate 
our

company system under simulation.


I have some old tapes from my Honeywell 66/60 GCOS days that I sometimes 
wonder if I could still get dumped. No idea what is even on them any 
more. I've brought up the DPS8 emulator with Multics but to be able to 
actually run my old GCOS again would be a dream come true.


The RTE (Real-Time Executive) family of operating systems had a long 
run at
HP -- from about 1968 through 2005 or so, with a dozen or so variants 
from
simple to sophisticated.  Languages supported included the HP 
assembler,
FORTRAN IV, ALGOL 60 (partial), BASIC, Fortran 77, and Pascal.  The 
RTE-II

software kit on the HP simulator site has the assembler and FORTRAN IV
compiler preloaded, and it's easy to add the ALGOL compiler from the HP
software collection on Bitsavers.  Fortran 77 and Pascal required later
versions of RTE (I intend to get kits posted for these before too 
long).


Perhaps most interesting to me is a SNOBOL3 interpreter in the HP
contributed library that ran under the DOS-III operating system.  It 
was
written by HP Grenoble, and all of the prompts and error messages were 
in
French.  I used it to write a runoff clone way back when.  Still have 
my
"SNOBOL3 Primer" by Allen Forte (MIT Press, 1968) sitting on my 
bookshelf.


Ah SNOBOL... I discovered that language shortly before graduating HS and 
always wanted to play around with it but never had an instillation where 
I could. ALGOL as well. Thanks for the suggestions, I'll check some of 
that out too.


Thanks.
David Williams

Re: pdp11/05 key?

[Dennis Boone via cctalk]

 > Late to the party, but there’s PDP11 keys sold on ebay here:

Though that may be useful to many, it's the wrong key for this thread.

De

Re: pdp11/05 key?

[Joshua Rice via cctalk]

Late to the party, but there’s PDP11 keys sold on ebay here: 
https://www.ebay.co.uk/itm/DEC-PDP-8-PDP-11-Computer-Key-XX2247-Digital-PDP-8E-8I-8L-8S/333296145346?epid=2164686531=item4d99ff93c2:g:nWcAAOSwZtlZ7TIB
 


I’m 100% sure your local locksmith / cobblers / hardware shop can do it 
cheaper. 

> On Apr 7, 2020, at 2:04 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Ian McLaughlin
> 
>> I can confirm that about 6 months ago I gave this very information to
>> our corporate locksmith, and he was able to make a key for me that
>> works.
> 
> Thanks for the confirmation that that info is sufficient to produce a working
> key. I have updated the page to indicate that the info has been confirmed.
> 
>   Noel

Re: ISO: Documentation for Interphase SMD 2181 disk controller

[Josh Dersch via cctalk]

On Tue, Apr 7, 2020 at 10:29 AM Al Kossow via cctech 
wrote:

> On 4/7/20 10:03 AM, Bill Degnan wrote:
>
> > Wondering if you can get/inquire from http://retrotechnology.com/#multi   
> > site.
> Manuals are not always listed there, you have to ask.
> > Bill
>
> Herb is on the intel-devsys mailing list, I just posted a request over
> there which would also
> get to a bunch of other people with Multibus boards.
>
> Thanks, Al!

- Josh

Re: Help installing HP 2000 contributed library in simh

[J. David Bryan via cctalk]

On Tuesday, April 7, 2020 at 13:19, David Williams via cctech wrote:

> First I want to say again how much I appreciate your assistance.

You're very welcome.


> Up until now my only experience with this system was as a HS student
> first learning to program and never had any access to the system
> outside of that. Learning a lot reading the manuals for the system as
> well as the doc on Simh and from you.

Prior to SIMH, my experience with TSB had been limited to running an HP 
contributed library program, "HP 2000F BASIC FOR DOS-M/DOS III," on an HP 
1000 M-Series running DOS-III (circa 1975).  Only with simulation have I 
been able to expand my experience, both as a user and as a sysop, to 
include running the C-prime, E, F, and Access versions of TSB.


> Looking at the Access doc on the conversion program's dump command I 
> noticed it says it dumps 2000/Access "BASIC formatted files" which the 
> one file I was able to transfer is where the others are not.

Oops.


> Looking through the manuals to see if there is a different way to save 
> the programs that could work but don't see anything yet.

I had wondered.  HP BASICs store their programs in transliterated form, 
i.e., substituting table index numbers for statement keywords, operators, 
etc.  So, for example, a "10 PRINT" statement gets stored internally as two 
integers -- the line number, and an index into the keyword table.  A "LIST" 
command reconstructs the text representation from the internal form.

So were you to load a program into 2000F that uses an Access feature, the 
stored statement keyword index would be beyond the end of the 2000F table.  
Running or listing that program would then either fail (best case) or send 
the interpreter into the weeds (probable case).  That's the origin of the 
feature code comparison and the warning that if you proceed with the load, 
you take responsibility for the cleanup.


> Haven't looked into punch tape with Simh, is that working?

The system paper tape reader and punch (simulator devices PTR and PTP) work 
under Access.  You can use the Access PUNCH command with the "OUT=" 
redirection option to output to the system punch device; the result is a 
plain-text file listing of your program, albeit with a bunch of NULs for 
tape leader and trailer.

You could do almost the same thing by listing your program to the system 
line printer; this results in a plain-text file, with some extra blank 
lines to divide the output into pages.

Unfortunately, while 2000F has a working system tape reader, TSB does not 
provide a way for users to read programs from it.  It's used only for 
bootstrapping the system.

Both Access and F allow the user to input programs by using the paper tape 
reader that's part of the ASR 33 Teletype.  But the simulated terminal 
multiplexer supports only KSR 33 models (no punch or reader).


> Not sure punching each program and reloading into the 2000F would be
> any better than copy/paste though.

Depending on your host system and Telnet client, you should be able to copy 
an entire text file and paste it into a logged-in TSB session terminal 
emulator in a single operation.  It's not necessary to copy-and-paste each 
line.  So it shouldn't be too difficult to employ this method -- maybe just 
tedious.

2000F provide the TAPE and KEY commands to suppress and then re-enable any 
diagnostic messages generated by the intervening program input.  They may 
be useful if the programs you're pasting might have Access-only features 
that would cause errors when entered.


> Open to any other ideas for getting a bunch of programs back to a 2000F 
> system...

There's an HP 2000 users' group at:

  https://groups.io/g/hp2000family

They might have some additional ideas or know where to locate a compatible 
CSL tape.

  -- Dave

Re: State of New Jersey needs COBOL programmers

[ben via cctalk]

On 4/7/2020 12:31 PM, John Ames via cctech wrote:


*That said,* there are definitely some languages that are more
conducive to building these habits than others (and, within each
group, many that emphasize different aspects more or less strongly.) I
can't speak to COBOL as I've never had cause to get any experience
with it, but I would say that BASIC (as in, the old-school,
unstructured BASICs of the Bad Old Days) really does teach you a bunch
of habits that you end up needing to un-learn as soon as you start
working with better languages (not even *newer* languages - ALGOL and
Lisp both predate it.)


Where does a TINY PASCAL compiler written in BASIC fit?
Then you have Some posible better languges that never seem to make it 
out of a LAB or UNIVERSITY. Like CLEOPATRA-comprehensive language for 
elegant operating systems and translator design. 1974

(From the "Internet archive")
The Internet Archive has a lot of good books, that somebody distroyed by 
convering to PDF's the wrong way.

Re: Old FORTRAN programs, libraries, graphics

[emanuel stiebler via cctalk]

On 2020-04-06 22:48, Douglas Taylor via cctech wrote:
> Got similar interests here.  I've been using PGPLOT on the Vax since it
> came out, the price was right!
> Tried to get it to work with a Tektronix 4207, but something is a little
> different between it and the 4105 series.
> I was able to get an old version of Gnuplot (3.4) to compile and run on
> a Vax alpha under Openvms 8.4.
> It wouldn't compile on a 32 Vax under OpenVms 7.3, too bad, I had wanted
> to run gnuplot on that machine.  Maybe I needed an older version of
> gnuplot.

That's pretty much the setup I was trying. VAX & PDP11, an some fun ;-)

However, a Tektronix Terminal is still not in the budget or space, so I
will probably go with the RPI 4 setup

https://github.com/rricharz/Tek4010

But probably just use a Ubuntu for the display, as it gives a better
resolution ...

CHEERS!

> On 4/6/2020 6:00 AM, Dave Wade via cctech wrote:
>> I have been using PGPLOT but I guess you are aware of that.
>>
>> https://www.astro.caltech.edu/~tjp/pgplot/
>>
>> I also wonder if you might be interested in
>>
>> https://github.com/rricharz/Tek4010
>>
>> what I was looking for was a Calcomp Basic Plotting calls to HPGL as
>> most of my plotters are HPLG and would like to plot some of the
>> Calcomp sample plots on them
>>
>> Dave
>>
>>> -Original Message-
>>> From: cctalk  On Behalf Of emanuel
>>> stiebler
>>> via cctalk
>>> Sent: 05 April 2020 14:22
>>> To: General Discussion: On-Topic Posts Only 
>>> Subject: Old FORTRAN programs, libraries, graphics
>>>
>>> Being stuck at home, was musing the idea to look into some graphics
>>> software from the '70's, or early 80's ...
>>>
>>> Looking for some wire frames, hidden line removal, 3d graphics...
>>>
>>> Any pointers?
>>>
>>> View month ago or longer, somebody on this list recovered some large
>>> package of FORTRAN code, and wanted to invest it, but I think it was
>>> posted
>>> under a wrong subject, so I can't find it anymore ...
>>>
>>> THANKS!
> 
> 

Re: ICL1501 Cobol manual available

[Neil Thompson via cctalk]

BASIC was all we had - we used COBOL on the ICL VME 2900 maniframes that
were backending the 15xx machines.  Believe me, if the programming staff
had known COBOL was available on the 15xx machines, we would have moved
heaven and earth to put it on the micros.

So no, not the end-all, and I'm fairly sure I never implied that anywhere.

On Wed, 8 Apr 2020 at 00:48, Chuck Guzis via cctalk 
wrote:

> On 4/7/20 3:24 PM, Neil Thompson via cctalk wrote:
> > Why?  Because we used to run out of resources regularly on that machine
> > writing the stuff in EBB, which was also compiled (I may be wrong, but I
> > seem to remember compiling stuff on it).  And BASIC, even EBB, is
> generally
> > smaller than COBOL.
>
> COBOL provides for better data typing than most other languages.  (COMP,
> COMP-1, COMP-2 or COMP-3), picture clauses, data structuring, etc.
>
> If what you need is simple, maybe BASIC is fine.  But it's not the
> end-all by any means.
>
> --Chuck
>
>

Re: VAXmate PSU

[Mattis Lind via cctalk]

Den ons 8 apr. 2020 kl 00:34 skrev Rob Jarratt via cctalk <
cctalk@classiccmp.org>:

>
>
> > -Original Message-
> > From: cctalk  On Behalf Of Brent Hilpert
> via
> > cctalk
> > Sent: 06 April 2020 21:07
> > To: General Discussion: On-Topic and Off-Topic Posts
> 
> > Subject: Re: VAXmate PSU
> >
> > 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.
>
> Oh dear! After Brent's question about D19 anode, I realise that the probe
> was connected to the cathode! I have now done it again with the probe
> connected to the anode. I have taken two images of the same capture, one at
> low resolution to show the overall behaviour
>
> https://rjarratt.files.wordpress.com/2020/04/primary-side-shutdown-1.png
>
> And one zoomed in to show what happens when the SCR shuts down.
>
>
> https://rjarratt.files.wordpress.com/2020/04/primary-side-shutdown-detail-2.
> png
> 
>
> The channels are the same as before, namely:
> Ch1. 555 timer.
> Ch2. D19 Anode (now corrected as it was previously the cathode!)
> Ch3. D19 Gate.
> Ch4. Q1 Source.
>
> I got an earlier trace which showed the D19 anode at 9V, which is under the
> Undervoltage Lockout threshold, but I have not been able to repeat it.
>
> I don't fully understand the debate about using the variac.


I am not going to debate this either since I know what I have been doing
for years and it works perfectly well for me. I have fixed the bigger PSUs
in a VAX 11/750 (one broken switch transistor and multiple broken output
rectifiers). PSU in NORD-10/S (most carbon composition resistors had gone
out of spec). PSUs in many smaller machines as well.

I prefer to work in circuits where I can fiddle around without the danger
of getting killed all the time. Regardless of use of HV differential probe
it can be dangerous. Running it on 50VAC with a protection transformer do
expose a lot of problems already and you can poke around safely in the PSU.
I have not yet seen a problem that wasn't seen at low voltage, but I expect
there could be semiconductors that experience breakdown that occur at lower
than specified voltage.



> However, my
> measurements appear to suggest that when I use the variac the SCR triggers
> because of what appears to be a genuine overcurrent detected by R13. I
> think
> this is because the duty cycle at low AC input voltages is 50% (rather than
> about 10% or less as per the trace I have just taken), and I measured 2V
> across R13, which does seem to be enough to trigger the SCR. When I use
> 220VAC, the voltage across R13 does rise to 6V, which should also trigger
> the SCR I think, except that the peak last a lot less and so perhaps the
> fact that the 6V last for a brief period is insufficient to trigger it?
>


On the issue of duty cycle. If we look at this from the start up
perspective rather than the steady state perspective. At startup there are
no stored energy in the output filter capacitors. The voltage on the output
is thus 0. As soon as the PSU is doing its first switching pulse energy is
transfered as the main switch transistor is cutting off. The energy is
transfered into the capacitor and into the load. The voltage is starting to
increase.

The duty cycle generated by the PWM circuitry is in pure relation to the
voltage error, i.e. the difference between output voltage and reference
voltage. In essence it is a P-regulator.

When there are 0 Volt out the duty 

RE: VAXmate PSU

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Matt Burke via
> cctalk
> Sent: 08 April 2020 01:25
> To: cctalk@classiccmp.org
> Subject: Re: VAXmate PSU
> 
> On 07/04/2020 23:34, Rob Jarratt via cctalk wrote:
> > I have seen the suggestions to study the waveforms at a much higher
> > resolution. What I am doing is setting the overall timebase in the
> > 100ms range so that I can trigger on when the 555 starts to oscillate
> > and capture the whole period of operation until the SCR triggers. I
> > can then zoom in, as can be seen from the trace provided in this
> > email. I hope that is good enough, or am I missing some problem with doing
> it this way?
> >
> 
> The timebase will also affect the sampling rate (due to the finite memory
> depth) so some finer details of the waveform may not be captured when
> running at a slower rate.
> 

I did have this in mind but it seemed to me that the sampling was fine enough. 
To be sure though, I just now changed my trigger to capture the drop in the D19 
anode voltage and set the timebase to 10us, but the results looked identical. I 
couldn't see any spikes that were different to the pictures I posted last night.

Thanks

Rob
 
> Matt