[cctalk] Re: Tips on VME board access

2023-06-03 Thread J. David Bryan via cctalk
Kurt,


On Saturday, June 3, 2023 at 9:33, Kurt Nowak via cctalk wrote:

> Does anyone have any tips on how to get at it since it's buried in the
> VME chassis. I was thinking of having an extension card made but
> thought I'd ask here and see what others have done first. 

I don't know anything about VME, but Vector Electronics makes VME 
extenders:

  https://www.vectorelect.com/extenders.html

...which might save you some effort.

  -- Dave



[cctalk] Re: ESD Bags

2022-11-16 Thread J. David Bryan via cctalk
On Tuesday, November 15, 2022 at 23:15, Ali via cctalk wrote:

> Does anyone have a REASONABLY priced source for 6" x 14" anti-static
> bags with zip lock tops? 

I bought a few dozen in several sizes, with zip-lock and plain tops, a 
couple of years ago from McMaster-Carr.  Search their site for "antistatic 
bags."

  -- Dave



Re: Any CodeWright users: still have patch installers?

2022-04-07 Thread J. David Bryan via cctalk
On Tuesday, April 5, 2022 at 17:52, Daniel Moniz via cctech wrote:

> This is a long shot, but on the off chance anyone else on the list
> shares some of my particular weirdnesses, anyone got a line on the
> *patches* for Embarcadero (nee Borland (nee Starbase (nee Premia)
> CodeWright? 
> 
> I have the latest version Embarcadero sold (and maybe still sells?) as
> of not all that long ago -- 7.5 -- but it's basically patch level 3
> (e.g., 7.5.3) instead of patch level 5 (e.g., 7.5.5). I'm hoping
> someone has the patch installers squirreled away somewhere, and that I
> can find that person. 

I'm a 27-year-and-counting Codewright user, and I use it daily.  I still 
think it's a terrific editor.

I'm still on version 5.0d, but I thought I had picked up all of the patches 
from there through 7.5 against the day that I was going to upgrade.  I was 
looking periodically to see if they had fixed two crash bugs that are in 
5.0, and I kept waiting -- too long, as it turned out, as it was pulled 
from the market before I could buy the upgrade.

In any event, I looked around here, and apparently I have a full set of 
release notes and a full set of user's guides through 7.5, but no patch 
files except for the ones for 5.0.

Sorry I couldn't help, but I wanted to let you know that there is at least 
one other "weird" person out here who understands your affliction.

  -- Dave



Re: OT: looking for help remembering name/info about security bug

2022-01-11 Thread J. David Bryan via cctalk
On Tuesday, January 11, 2022 at 17:56, Stan Sieler via cctalk wrote:

> I *think* it was some kind of authentication failure (e.g.,
> incorrectly reporting "ok"), but I'm not sure. 
> 
> I do know I wrote a several page article about it, and how certain
> coding practices led to it, but I can't *find* the article now  :( (not
> published) My guess of 4-6 years ago is possibly narrower than it
> should be, but I'm not sure. 

Have you had a squint at the RISKS archives:

  http://catless.ncl.ac.uk/Risks/

Major computer-related issues are usually mentioned here, frequently (but 
not always) with capsule summaries.  A search with some of your remembered 
characteristics might turn up something.

  -- Dave



Re: HP 5061-3476: Which boards go where

2021-09-21 Thread J. David Bryan via cctalk
On Saturday, September 11, 2021 at 21:31, Chris Zach via cctech wrote:

> Ok, thanks!

You're welcome.


> I just tried mine again, it's a dud so I am going to have to figure it
> out. First step was to see if the rectifier had any voltage so I
> disconnected the + side and checked it with a voltmeter. With 120v
> plugged in I saw 200v DC which is probably not too far off. That seems
> to go to the inverter card, which I don't know what it's doing with
> that. 

There's a reasonably complete theory of operation of the "B" power supply 
(which is what you have) in section IXB of the HP 1000 M/E/F-Series 
Computers Engineering and Reference Documentation.  There were several 
revisions of the "B" supply, but they all used the same motherboard (as far 
as I know), so the various plug-in card functions would be pretty much 
equivalent across versions.


> Is there a block schematic of what does what on this PS?

Page IXB-6 of the above manual has one.  There's also a troubleshooting 
flowchart on page IXC-3.  Section IXC is specifically for your supply 
version and has the appropriate schematics, but the theory from the earlier 
"B" supply should be broadly applicable.

  -- Dave



Re: ISO PFT (Precision Fabrication Technologies) MOD-U-LINE catalog/brochure

2021-09-15 Thread J. David Bryan via cctalk
On Wednesday, September 15, 2021 at 9:00, Al Kossow via cctalk wrote:

> PFT made MOD-U-LINE MCLS modular aluminum enclosures (sides, top and
> front/back).
> 
> The only information on the web is
> https://www.ceitron.com/passive/pft.html
> 
> Does anyone still have a copy of their brochure?

I don't think I have a brochure, but PFT products occupy about ten pages of 
my 1997 Allied Electronics catalog.  Mod-U-Line cabinets are on the first 
page.  PFT catalog numbers, dimensions, and a bit of material data.

  -- Dave



Re: HP 5061-3476: Which boards go where

2021-09-12 Thread J. David Bryan via cctalk
On Thursday, September 9, 2021 at 21:30, Chris Zach via cctech wrote:

> Quick question: I've been cleaning out and repairing an HP5061 supply 
> for a 1000 computer. However I didn't take a picture of the 4 boards 
> when I pulled them and I want to make sure they go in the right places.
> 
>  From the manual (page 99 of 92851-90001_Sections-IXB_Mar-1981.pdf) the
> slots are labeled A6-J1 through A6-J5. Does this mean that:
> 
> J5 is the control board (A3A5)
> J4 is a jumper board for +12 adjustments
> J3 is unused (battery backup boards)
> J2 is the inverter board (A3A2)
> J1 is the pre-regulator board (A3A1)
> 
> Seems right but I know how bad things can go :-)

Those are correct.  I just pulled the cover off my (working) 1000 M-Series 
that has a later model supply (5061-6630 date code 2601) but has the same 
motherboard as yours (5061-1371).  J1, J2, and J5 are as above -- 
Preregulator (5061-3457), Inverter (5061-3454), and Control (5061-6627).  I 
have the power fail option, so J3 is the Battery Charge card (5061-1348) 
and J4 is the Battery Backup card (5061-1349).

  -- Dave



Re: problem in HP 3000 System 37

2021-09-02 Thread J. David Bryan via cctalk
On Thursday, September 2, 2021 at 8:16, Gavin Scott via cctech wrote:

> P.S. The HP Museum has the CE handbook for the 37 and Micro 3000, but
> it's in the 3000 Micro XE section. You can find it by searching within
> the Documents page linked at the bottom of the left side navigation
> bar. 
> 
> 3000-37-MicroFamily_CEServiceHandbook_30457-90039_200pages_Feb89.pdf

Page 5-31 of that manual details the LED display codes.

Note also that the Series 37 requires certain PCAs to be in certain slots 
(pages 3-2 and 3-4), so it would be good to verify this too.

And as Gavin mentions, the CPU tries to talk to the terminal after 
completing the self-test, so it's important to have a working terminal 
connected and turned on when powering up the system.

  -- Dave



Re: Linearizing PDF scans

2021-08-16 Thread J. David Bryan via cctalk
On Monday, August 16, 2021 at 22:46, Wayne S wrote:

> I asked because i was curious if what you wanted to do could not be
> done in Acrobat. 

Never having used Acrobat, I cannot say.

  -- Dave



Re: Linearizing PDF scans

2021-08-16 Thread J. David Bryan via cctalk
On Monday, August 16, 2021 at 14:20, Wayne Sudol wrote:

> Out of curiosity, is there a reason you do not use Acrobat for
> creating pdfs? 

Primarily because I have not purchased a license for Acrobat.  Also, when I 
started scanning manuals ten years ago, Al Kossow recommended tumble, which 
worked well.  And with source available, I've been able to extend it to 
give me finer control over some aspects of PDF production.

  -- Dave



Re: Linearizing PDF scans

2021-08-16 Thread J. David Bryan via cctalk
On Sunday, August 15, 2021 at 1:20, Alexander Schreiber wrote:

> My current toolchain for that:

Thanks; that was quite helpful.

One aspect that I find of great assistance in navigating large PDF manuals 
is original page numbers.  Often a manual will contain references, e.g., to 
"page 4-13" or "Appendix B-23".  Having just a set of ascending integers 
for PDF page numbers and having to guess where Section 4 page 13 might be 
in that list is difficult, especially when PDF page 1 doesn't correspond to 
manual page 1-1 and the sections are very large.  Being able to enter a 
referenced page number directly into a PDF reader's "go to page" dialog is 
very convenient.


> >   http://www.leptonica.org/
> 
> Thanks for the pointer, I'm going to take a look - apparently
> tesseract uses leptonica for some image processing work. 

You're welcome.  Yes, tesseract is one of the major users of Leptonica.

When I first started using the library about ten years ago, I found the 
documentation very reminiscent of those school mathematics textbooks that 
said, "The proof is left as an exercise for the reader."  There were a 
couple of examples on the host site but no comprehensive index of the 2500+ 
library routines.  The approach was, "read the source," which was fine if 
one was familiar with image processing terms, such as affine 
transformations, morphology, convolution, and octcube-based color 
quantization.

It may be better now, but it was something of an intellectual challenge at 
the time.


> What is that? Never heard of linearizing PDF before

It's documented in the PDF Reference Manual from Adobe.  Apparently, it's 
been around since PDF 1.2.  The introduction to the chapter says:

   A linearized PDF file is one that has been organized in a special way
   to enable efficient incremental access in a network environment. The
   file is valid PDF in all respects, and it is compatible with all
   existing viewers and other PDF applications. Enhanced viewers can
   recognize that a PDF file has been linearized and can take advantage
   of that organization to enhance viewing performance.

...which, as others have mentioned, essentially is to allow page-at-a-time 
access via a browser without having to download the entire file first.

  -- Dave



Re: Linearizing PDF scans

2021-08-15 Thread J. David Bryan via cctalk
On Sunday, August 15, 2021 at 12:55, Kevin Parker wrote:

> I think it used to be called Byte Range Serving i.e. it would only
> serve up the page requested so URL's like
> somewebsite.com/myfile.pdf#page=4 would only send page 4 to the browser
> - I think this is what you are talking about 

That's it exactly.


> ...but on my limited understanding it required support from the web
> server to actually give effect to this.

I believe that's right.  At least all of the servers I used seemed to 
support this option.


> I don't know if PDF's are optimised out of the box these days for this
> but if you optimise a PDF for web delivery it should have the markers
> in it for byte range serving. While the markers may add a bit to the
> file size, which I suspect would be negligible, the action of
> optimising it for web delivery should reduce file size quite noticeably
> anyway.

I use Ghostscript to perform the linearization as a post-process of the 
tumble-produced PDFs.  It seems to add about 5-10% in size to the dozen or 
so files I've produced in both formats.

Assuming one only looks at a few pages, it would certainly reduce the 
amount of data served, though, of course, if one requested the entire file, 
it would actually be a slight disadvantage.


> Is it useful these days - probably not so much because of better
> bandwidth in my view (although directing a browser to open to a
> specific page can still be useful) but that is conditional on having
> well prepared PDF files.

It's an extra, albeit automated, step in my process, so it requires a 
limited effort on my part.  But for a version or two, GS linearization was 
broken, so I wound up with a mix of linearized and non-linearized files.  
Which had me wondering whether it was worth going back and linearizing the 
ones that weren't.

I could see it being most useful for something like IC databooks, where one 
might only want a one-time look up of a couple of pages out of a several 
hundred page PDF.  For something like a service manual, though, I'd 
anticipate that folks would want to download the whole manual rather than a 
page here and a page there.

As you say, it requires server support, and to be honest I've not checked 
recently to see if servers bother byte-serving anymore.  Maybe pipes are 
too big to worry about it.

Anyway, I was wondering if I was a dinosaur to keep linearizing these 
things if no one else was.

Thanks for your thoughts.

  -- Dave



Re: Linearizing PDF scans

2021-08-14 Thread J. David Bryan via cctalk
On Saturday, August 14, 2021 at 12:22, ben via cctech wrote:

> I tend to have my PDF's on portable device, so PDF's need to be easy
> to use on those devices.

Linearizing keeps PDFs as complete files but rearranges (and expands) them 
internally so that individual pages can be rendered from a subrange of 
bytes sent by the server.  Before linearization, the information necessary 
to render a given page is scattered around the PDF file, so typically the 
whole file must be downloaded before displaying the page.  Once the whole 
file is present locally, there's no difference in access or display whether 
linearized or not.

I guess the operative question is whether people tend to view PDF pages on 
a server or download files and view them locally.

Thanks.

  -- Dave



Re: Linearizing PDF scans

2021-08-14 Thread J. David Bryan via cctalk
On Saturday, August 14, 2021 at 11:04, Al Kossow via cctech wrote:

> Jay Jager is trying to deal with scanning manuals with colored text
> and backgrounds. Is your workflow for dealing with this around
> somewhere? 

I'm still using the same set of programs that I sent to you in April 2016 
(as image-utilities.zip).

Have Jay contact me directly, and I'll see what I can do to help.

Spot color (colored text being a specific case) is the most difficult issue 
to handle, in my experience, especially as the colors are usually screened 
from CMYK.  Solidifying screened colored areas and quantizing into a small 
number of solid colors that can be rendered, e.g., as a four-color PNG page 
in a PDF, is not trivial, especially when text or line drawings touch or 
overlay the screened areas.

  -- Dave



Re: Linearizing PDF scans

2021-08-13 Thread J. David Bryan via cctalk
On Friday, August 13, 2021 at 17:23, Alexandre Souza wrote:

> Is any kind of standard, recomendation, group, mail list, to discuss
> the subject? 

I am not aware of any.  I started with Al Kossow's basic recommendations, 
modified slightly:

  - scan at 600 dpi
  - use TIFF G4 where feasible
  - use tumble to convert to PDF

I then wrote and use a couple of simple image-processing utilities based on 
the Leptonica image library:

  http://www.leptonica.org/

...to clean up the scans (the library makes the programs pretty trivial).  
They start with the raw scans and:

  - mask the edges to remove hole punches, etc.
  - size to exactly 8.5" x 11" (or larger, for fold-out pages)
  - remove random noise dots (despeckle)
  - rotate to straighten (deskew)
  - descreen photos on pages into continuous-tone images
  - quantize and solidify screened color areas into solid areas
  - assign page numbers and bookmarks in the PDF

A good example PDF produced by these programs is:

  http://www.bitsavers.org/pdf/hp/64000/software/64500-90912_Mar-1986.pdf

The cover is a "solidified" black/gray/white image, manual pages 1-2 and 
1-4 are continuous-tone JPEG images overlaying bilevel text images, and the 
rest of the pages are masked, deskewed, bilevel text images.  The PDF 
bookmarks and logical page numbers are auto-generated from the original 
scan filenames.

The final step is linearizing the PDFs, but I'm wondering whether this is 
still useful.

  -- Dave



Linearizing PDF scans

2021-08-13 Thread J. David Bryan via cctalk
Is it still useful to linearize PDFs?

I've been scanning and PDFing manuals for 16 years, and I've been 
linearizing them regularly.  My understanding is that this made them 
accessible on a page-by-page basis in Web browsers without requiring a 
complete file download first.  But given the increase in typical bandwidth 
in 16 years, I wonder if this is still useful.  It is an extra step, and it 
does make the files somewhat larger.

Recommendations?  Does linearizing confer any advantage locally once the 
entire file is downloaded?

Thanks.

  -- Dave



Re: HP Journal back issues

2021-02-03 Thread J. David Bryan via cctalk
On Wednesday, February 3, 2021 at 9:25, ED SHARPE via cctech wrote:

> Indeed this site is great for reference but alas are too lo-res for good
> museum display images.

They appear to be scanned at 150 dpi.

The ones here are scanned at 300 dpi:

  http://hparchive.com/hp_journals


  -- Dave



Re: 9 track tapes and block sizes

2020-10-06 Thread J. David Bryan via cctalk
On Monday, October 5, 2020 at 8:25, Chuck Guzis via cctech wrote:

> So increasing the mask for block length wouldn't seem to be a problem,
> assuming that SIMH could support it.

SIMH could be written to support it (I'm the maintainer-by-default of the 
tape handling portion of SIMH).  I don't know of any existing simulators 
that depend on the length being exactly 24 bits.  The tape handling library 
defines an integer type to hold tape record lengths (it's a 32-bit unsigned 
value), and simulators are supposed to declare tape record length variables 
of this type.  So extending the record length field to 28 bits shouldn't 
cause problems.

The current library assumes that anything that's not one of the three 
defined metadata markers (EOF, EOM, or erase gap) is a tape record length, 
so there's no error recovery for undefined markers.  This could be changed, 
however, so that unrecognized markers would be ignored, i.e., transparently 
skipped when reading or writing, as long as those markers contained the 
length of the record to be skipped.

For example, if the upper four bits were dedicated to the marker type field 
and the length field expanded to 28 bits, then we could have something 
like:

  Type  Length   Meaning
    ---  
0  0 tape mark
0 >0 "good" data record
1 >0 \
  ... | undefined records (reserved for SIMH)
7 >0 /
8 >0 "bad" data record
9 >0 \
  ... | user-defined records
D >0 /
E anyuser-defined single-word marker
F   FFF  end of medium
F   FFE  erase gap
Fother   undefined single word marker (reserved for SIMH)

The type E single-word marker and record types 9-D (that must contain 
record lengths at both ends of the record) would be transparently ignored 
by SIMH.  These could be used for tape information or other uses devised by 
the community.

  -- Dave



Re: 9 track tapes and block sizes

2020-10-05 Thread J. David Bryan via cctalk
On Sunday, October 4, 2020 at 16:00, Chuck Guzis via cctalk wrote:

> A 16MB tape block is impossibly large in any case. 

The HP 3000 mag tape diagnostic attempts to write a single record from BOT 
to EOT, which unfortunately fails under simulation due to the 16 MB 
limitation.  In hindsight, it would have been better to accommodate record 
lengths corresponding to the highest density and longest reel length, which 
I think would need 28 bits.  Four bits for metadata identifier would still 
have been be good enough, and one of those should have been dedicated to 
"private data" that would appear invisible to programs running under 
simulation (and could be used to include information about the tape image 
with the tape image).

  -- Dave



Re: 9 track tapes and block sizes

2020-10-04 Thread J. David Bryan via cctalk
On Friday, October 2, 2020 at 13:51, Al Kossow via cctech wrote:

> Those would already be broken with Bob's use of large negative numbers
> for physical end of tape and 'bad block is here' (you don't get to know
> how big that bad block was, so that is hell with tapes with
> variable-length records, grumble..)

I'm not sure I understand.  SIMH metadata markers are treated in the tape 
library code as unsigned values, so EOM and erase gap are seen as large 
unsigned values.  The format limits record lengths to 24 bits (so about 16 
MB maximum per record), reserving the upper 8 bits to indicate the type of 
the marker, and the bad record marker is the top byte = 0x80.  The record 
length of a bad block is encoded in the lower 24 bits and indicates how big 
the bad block was.

What am I missing?

  -- Dave



Re: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany

2020-09-16 Thread J. David Bryan via cctalk
On Wednesday, September 16, 2020 at 8:19, Lee Courtney via cctech wrote:

> Al - it would be a Very Good Thing to get those APL ROMS dumped when
> possible.

It would be good as well to dump the Series III main instruction set ROMs, 
assuming they're socketed.  Bitsavers has a Series II microcode listing, 
and there are some notes available on the microcode changes from the II to 
the III, but there is no existing Series III listing.

I've written reverse-microassemblers for the HP 1000 M-Series and for the 
1000 E/F-Series microcode, which could be easily adapted to produce a 
listing from the 3000 Series III ROMs.

  -- Dave



Re: Hp 21mx loader rom set

2020-07-02 Thread J. David Bryan via cctalk
On Thursday, July 2, 2020 at 11:06, Curious Marc wrote:

> Thanks a lot.

You're welcome.


> Anyone wants me to dump the DS/1000 rev 1826 ROMs or are these already
> available?

To my knowledge, they are not available.


> What´s the CBL ROM? The one that´s on the cable interface card?

No, it's a boot loader ROM ("CBL" is Communications Bootstrap Loader) that
will load absolute programs across a DS/1000 link.  So it's one of the
small PROMs that mount on the CPU board and that is invoked by the front
panel IBL button.  It's used to bring up a memory-based system node by
loading the OS from a disc-based node across the link.

  -- Dave



Re: Hp 21mx loader rom set

2020-06-29 Thread J. David Bryan via cctalk
On Sunday, June 28, 2020 at 22:20, CuriousMarc via cctech wrote:

> I also have a 91740-80033/34/35 set which I don't know what it is. Does
> anyone know? 

Those are DS/1000 revision 1826.

Page 3-130 of the HP "Communicator/1000 for Software Update 6.0" 
(5951-6201, December 1992) has a full list of the DS/1000 ROMs and 
revisions, as follows:

  91740-80001/02/03/16 -- Rev. 1740
  91740-80018/19/20/17 -- Rev. 1813
  91740-80033/34/35/48 -- Rev. 1826
  91740-80049/50/51/48 -- Rev. 1913
  91740-80064/65/66/48 -- Rev. 2003 (bad ROMs; withdrawn)
  91740-80067/68/69/48 -- Rev. 2003 (good ROMs)
  91740-80070/71/72/48 -- Rev. 2540 (adds 7974 loader; no DS change)

(The first three ROMs in each entry are the microcode ROMS; the fourth is 
the CBL ROM.)

Pages 3-104 through 3-136 of that document give the firmware revisions of 
all of the HP products then in support.


> Anyhow, looking at the ROMs and dates, I suspect these are E/F
> microcode only and would not work on the 21MX. 

All of the above are E/F-Series only.

  -- Dave



Re: Hp 21mx loader rom set

2020-06-28 Thread J. David Bryan via cctalk
On Saturday, June 27, 2020 at 14:48, grant--- via cctech wrote:

> 12992-80011 
> 91740-80070
> 91740-80071
> 91740-80072
> 
> there is a set of 91740 on bit savers but with a suffix of 67-69 ?

These are the original DS/1000 ROMs (date code 2003) without the 7974 
loader extension.  That was added in 1985 (date code 2540) with the 
80070-72 set.  The 12992-80011 ROM loads the extension from the DS/1000 
ROMs into memory for execution.


> any help would be appreciated.

Contact me off-list if you still need copies of these ROM files.

  -- Dave



Re: Wanted, Papertape Reader for Archiving Tapes

2020-04-28 Thread J. David Bryan via cctalk
On Tuesday, April 28, 2020 at 17:56, Tony Duell via cctech wrote:

> The HP2748 is a common-ish example of this type of un[i]t. 

David Collins of the HP Computer Museum and I just recently completed 
reading some 200+ paper tapes from the museum collection.  He used a 2748 
coupled with a custom Arduino-based interface to produce plain-text files 
containing an octal representation of the tape bytes.  We passed these 
through a small program to convert them to binary files and a second 
program to verify checksums of those tapes containing relocatable or 
absolute binary object data.  The resulting files can be used as is with 
the HP 2100 SIMH simulator or could be punched back into physical paper 
tapes if desired.

  -- Dave



Re: Scanning incomplete and updated documents

2020-04-17 Thread J. David Bryan via cctalk
On Friday, April 17, 2020 at 9:02, Alan Perry via cctech wrote:

> But the really interesting thing is that the copyright date on the 
> "primary" document is AFTER the date in the footers of the "inserted"
> pages.

Sometimes an update contains a replacement title page (containing the 
update date), and sometimes updates supersede other updates for the same 
manual.  I've seen ones that have different change dates at different 
points in the manual, with the title page reflecting the date of the last 
update.  Maybe you have something like that.


> So, any recommendations on what I should do?

If you can't clearly determine whether the pages you have belong to one 
manual print date or two, then it certainly wouldn't hurt simply to include 
both sets of pages in one PDF.  My personal goals for scanning, in 
decreasing priority, are:

 1. Preserve the exact representation of a manual.

 2. Preserve the information in a manual in a usable format.

 3. Preserve the pages of a manual.

Even if you have to fall back to #3, something might turn up later that 
would allow you to go back and reorganize the pages into a more useful 
arrangement or into an original format.

  -- Dave



Re: Scanning incomplete and updated documents

2020-04-17 Thread J. David Bryan via cctalk
On Friday, April 17, 2020 at 18:06, Antonio Carlini via cctech wrote:

> pdftk works well for managing pages and PDFs.

I'll second that.  It's been invaluable for combining PDFs (such as when a 
supplier insists on delivering its general catalog in individual sections), 
as well as extracting subsets of pages.

  https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/

I find that the free one works fine for my applications.

  -- Dave



Re: Scanning incomplete and updated documents

2020-04-17 Thread J. David Bryan via cctalk
On Thursday, April 16, 2020 at 23:53, Frank McConnell wrote:

> The folks who did the 3000 manuals didn´t do that very often.  What we
> got were almost always update packets that simply replaced pages in
> their manuals.

To be fair, the 1000 (DSD) manuals were updated by replacement pages also.
What was odd and frustrating about the LSD folks was that a given update
might have two replacement pages and fifteen instructions to modify
existing pages.

Interesting that each division seemed to have its own rules.


> The 3000 folks I think had to make some effort to get beyond paste-up
> to where they were doing their manuals and updates in something, and
> it didn´t happen until the not-so-early 1980s.

The pre-1980 1000 software manuals, and pretty much all of the hardware
manuals, appeared to be typeset.  Starting around 1980 through 1986 or so,
the software manuals had typeset headings and chain-line-printed body text.
After that, they appear to have been mastered on a laser printer.


> Sometimes I thought the thing was TDP/3000 and the camera-ready copy
> came out of a 2680A or 2688A printer.

I recall receiving one manual that was actually printed on a 2680...on
fanfold blank letter-size paper.  Had to de-perf it and punch holes for a
binder.

  -- Dave



Re: Scanning incomplete and updated documents

2020-04-17 Thread J. David Bryan via cctalk
On Thursday, April 16, 2020 at 23:18, Frank McConnell wrote:

> Sometimes I have come across shrink-wrapped manuals and later updates,
> and scanned them as found.  I wouldn´t want to deny other people the
> opportunity to apply updates to manuals, you know?

Oh yes, especially the ones that would say, "Insert the six paragraphs
below between the third and fourth lines of page 23."  :-)

I used to despise HP when they would send updates that consisted of
instructions to modify existing manual pages instead of sending replacement
pages.  I recall one update, maybe for the HP 64000 logic station mainframe
service manual, that instructed me to change a dozen or so schematics --
simple things, like "replace feedback resistor R23 with the active filter
circuit shown below."  That one got stuck in the front of the outdated
manual, as I just couldn't bring myself to butcher the pages as they
required

When it came to manual updates, the Logic Systems Division was aptly named.

  -- Dave



Re: Scanning incomplete and updated documents

2020-04-16 Thread J. David Bryan via cctalk
On Thursday, April 16, 2020 at 8:52, Alan Perry via cctech wrote:

> 1. One document is a software installation manual in a loose leaf
> binder with other documents. It has a title page, tables of contents,
> etc., several chapters, and then it gets interesting. It has several
> appendix sections (starting at A), an index, then more appendix
> sections (starting at A as well), and then another index. The document
> title and its font match of the second set of appendix sections and
> second index matches the table of contents and chapters. 

I've scanned roughly 450 manuals.  What you describe might be the result of 
a manual update.  Some updates include replacement pages, with the intent 
that the replaced pages are discarded.  I've encountered manuals, though, 
where both the old and new pages were kept, perhaps to retain a record of 
the changes.


> Should I create two different pdfs with different appendix sections or 
> create a single pdf with both sets?

Where both old and new pages were present, and where they could be 
differentiated clearly, I made a separate PDF for each manual printing.  
That is, I'd have two PDFs with the same part number with different print 
dates -- one containing the old (original) pages, and the other containing 
the new (replacement) pages.  See, for example:

  /pdf/hp/64000/hardware/64161-90901_Jan-1984.pdf
  /pdf/hp/64000/hardware/64161-90901_May-1984.pdf

and the update ("Manual Change Sheet"):

  /pdf/hp/64000/hardware/64161-90901-MCS_May-1984.pdf

...from which the later manual was created at Bitsavers.


> 2. One document is missing the title page and table of contents.
> Should the pdf just be what I have or should I create those pages for
> the pdf? 

If you know how the title page and TOC should appear, I would add them.  If 
you wish, you could add a note, such as "(Reconstructed)", as a page footer 
on the added pages.  I've reconstructed missing front and back cover pages 
where the manual is part of a family of manuals that all share the same 
basic cover and title page designs.

I think PDFs, ideally, should allow one to reprint an extinct manual in its 
entirety.  So I include the blank pages, covers, inserts, etc. from the 
original when I make mine.


> Thanks, 

You're welcome.

  -- Dave



Re: Help installing HP 2000 contributed library in simh

2020-04-08 Thread 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: Help installing HP 2000 contributed library in simh

2020-04-08 Thread 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: Help installing HP 2000 contributed library in simh

2020-04-07 Thread J. David Bryan via cctalk
On Tuesday, April 7, 2020 at 18:28, David Williams via cctalk wrote:

> Still have a box of paper tapes from back then that I suspect I'll
> never be able to do anything with again but the pack rat in me refuses
> to let go. Every so often I consider trying to decode them again. 

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.

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.


> That's the old Yahoo group isn't it?

It is.  I think they were migrating from Yahoo to the groups.io site.


> Any other suggestions of interesting operating systems or software to
> try out besides TSB? Interesting development environments or uncommon
> or unusual languages tend to grab my interest.

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.

  -- Dave



Re: Help installing HP 2000 contributed library in simh

2020-04-06 Thread J. David Bryan via cctalk
On Monday, April 6, 2020 at 13:47, David Williams via cctech wrote:

> The first few tries I didn't see any messages, it just went on to the
> enter date and time and start up but when I'd check the account's
> directory there was nothing there. 

As I noted, I'm not that familiar with TSB (I'm an RTE guy).  But you might 
have to create the desired accounts with the "NEW" sysop command before you 
can restore to them.


> The last couple of times I tried I did get a message about something
> unsupported and listed something about 200 vs 1500 iirc (block
> size??). 

Feature level codes, I think.


> It asked if I wanted to take responsibility and continue which I said
> yes but still nothing appeared to be restored.

Pages 4-21 and 4-22 of the Access operator's manual (22687-90005, July 
1976) say:

   Each system is assigned a Feature Level Code identifying the level of
   features it supports. Currently, codes are assigned as follows: 

   Feature Level Code
   ---   
   2000/C (High-Speed Option) 200
   2000/F (All Options)   200
   HP 2000 Operating System, Release A   1000
   HP 2000 Operating System, Release B   2000

   Normally, systems with Feature Level Codes of 1000 or greater cannot
   access tapes from systems with Feature Level Codes of less than 1000
   and vice versa. For exceptions to this rule, refer to conversion
   information in Appendix F. 

If the tape reported a feature level code of 1500, then I'd think it was an 
Access tape.

Access does come with a conversion program, described in Appendix F of the 
above manual, that allows one to dump Access programs in 2000F format.  
Presumably, you could load the CSL tape into an Access system and then dump 
the programs to a 2000F tape that could be read into the latter system.  
I've never tried this myself, though.

Another possibility, if you can get listings of the CSL programs you want, 
is to copy-and-paste the source into a logged-in user terminal window 
session.


> The CSL tape image comes from Bitsavers as well and was the only copy
> I've found. It is listed as the 2000F CSL so figured it was
> compatible. 

Which specific tape are you using?  Bitsavers shows three CSL tapes under 
/bits/hp/tapes/2000tsb, but they all seem to be feature level 1500.


> Could the Simh hardware configuration in the default set up need to be
> changed? 

I don't think that's it.  Those couple of test programs installed with the 
software kit are loaded from a selective dump magnetic tape image as part 
of the sysgen process, so the DUMP and LOAD commands do work with the 
hardware setup.

  -- Dave



Re: Help installing HP 2000 contributed library in simh

2020-04-06 Thread J. David Bryan via cctalk
On Monday, April 6, 2020 at 23:53, David Williams via cctalk wrote:

> Access is set up and running fine already so things should have already 
> been configured for it I'd have thought.

The simulator executable always starts up with a default hardware 
configuration (a 32K 2116 CPU, no extra firmware, and every possible I/O 
interface card assigned somewhere in the I/O space).  The supplied 
simulator command files change that default to match the Access (or 2000F, 
etc.) hardware requirements, but the changes are not sticky across 
sessions.  So restarting the simulator reverts to the default 
configuration.

In other words, running the simulator with "hp2100" gets you the default 
configuration.  Running with "hp2100 tsb-auto" (e.g.) starts with the 
default, and then the "tsb-auto.sim" command file execution changes it to 
match the TSB requirements before bootstrapping the system.


> Thank you for your help so far.

You're welcome.

  -- Dave



Re: Help installing HP 2000 contributed library in simh

2020-04-06 Thread J. David Bryan via cctalk
On Monday, April 6, 2020 at 20:39, David Williams via cctalk wrote:

> The problem I'm having is to load it I have to:
> 
> [...] 
> 
> 2) Select the S-register and clear the display. Set bits 15 and 0. Set 
> bits 11 through 6 to the low number (high priority) octal select code of
> the magnetic tape device controller.
> 
>   - Bit more of an issue for me as I'm not sure what value to enter for 
> the tape device.

The included "spconfig.inc" file indicates that the tape interface is 
assigned to select codes 16 and 17.  So the command you want is:

  DEPOSIT S 101601

> 3) Select the A-register and clear the display. Set bit 0. Press STORE 
> and IBL. The contents of the magnetic tape loader ROM are loaded into 
> memory.
> 
>   - Here it stops. The doc says to use the "LOAD CPU" command to simulate
> pressing the IBL button but when I do I just get "Command not allowed".

The LOAD CPU command is not allowed unless the CPU is configured as a 
21MX-series machine.  By default (meaning unless you've changed it since 
starting the simulator), it is configured as a 2116, which does not have 
loader ROMs.  So doing this after setting the S-register would work:

  SET CPU 21MX
  DEPOSIT A 01
  LOAD CPU

However, if the CPU isn't configured for Access, then probably the I/O 
devices aren't configured for Access as well.  The initial SIMH startup 
settings have to be changed to rearrange things to where Access expects 
them to be.

The simplest way to set up the proper configuration and then load the 
Master Control Program is to modify the existing "tsb-reload.sim" file.  
First, copy it to a new file named "tsb-convert.sim".  Then edit the latter 
by locating the line that says:

  go until "LOAD WHICH MODULE?  "  ; reply "%DISC%\r"

Delete this line and all of the remaining lines in the file.  Then append 
the command:

  go

...to the end, so that the last two lines of the file read:

  go until "2754? "; reply "YES\r"
  go

Save the file and then run it:

  hp2100 tsb-convert

The script will start up the IOP (I don't know if it's necessary in this 
case, but it's harmless) and then print:

  Waiting for the IOP to complete its initialization...

  Programmed halt, T: 102077 (HLT 77), P: 77756 (ALF,ALF)

  2754? YES
  LOAD WHICH MODULE?  

...on the system console.  Enter CONVERT, and then follow the remaining 
instructions in the sysop manual.  Note that the default uses an HP 7905 
disc drive for the system disc, so the question:

  DISC-0 A 7905 OR A 7920?

...should be answered YES.

  -- Dave



Re: Help installing HP 2000 contributed library in simh

2020-04-06 Thread J. David Bryan via cctalk
On Monday, April 6, 2020 at 9:20, ED SHARPE via cctech wrote:

> For  some  reason I  do not  remember having to enter each and every 
> file  name  to load  it  in to a real 2000f   but  then again it  has 
> been 40 years!

You can enter just the account names, which will restore all of the dumped
files for those accounts.  2000 Access lets you enter ALL to restore all
accounts from the tape, but I don't think that 2000F has that option.

  -- Dave



Re: Help installing HP 2000 contributed library in simh

2020-04-06 Thread J. David Bryan via cctalk
On Saturday, April 4, 2020 at 21:54, David Williams via cctech wrote:

> I've been able set up Simh with 2000F TSB and everything is working
> fine. Using the latest release I can find out there, HP2100 release
> 29. Now I'd like to be able to install some of the Contributed
> Software Library but despite reading the various TSB manuals and Simh
> doc, I've been unable to actually get anything loaded.

My acquaintance with the HP Time-Shared BASICs is only passing, and you 
didn't mention where you picked up the CSL image, but the ones at Bitsavers 
appear to be selective dumps of various accounts.  For those, you'd want to 
do a selective load of the desired files from the tape image.

If you're using the 2000F kit from the trailing-edge site, you can use the 
"tsb-man" startup file to begin a manual system startup.  You'd answer the 
startup questions as follows:

  CONFIGURATION OPTIONS? YES
  NUMBER OF PORTS? 
  LOAD OR DUMP COMMANDS? LOAD
  ENTER NAME LIST, ONE PER LINE; TERMINATE WITH 'END'

At this point, mount the CSL tape on the tape drive and then enter the 
account and file names of the files you wish to restore.  When you enter 
the END command, the system will load the named accounts or files from the 
tape.

The process is described on pages 4-19 through 4-22 in the "HP 20854A 
Timeshared BASIC/2000, Level F System Operator's Manual" (HP part number 
02000-90074, Nov-1974) that is available from Bitsavers.

One caveat: I don't know, but I suspect that the selective dump tapes are 
version-specific, i.e., one for 2000 Access won't work on 2000F.  I don't 
know with which systems the Bitsavers tapes are compatible.


> Thanks in advance.

You're welcome.

Feel free to contact me directly I can clarify anything.

  -- Dave



Re: Connecting SIMH to teletype via USB

2019-09-13 Thread J. David Bryan via cctalk
On Friday, September 13, 2019 at 18:31, Charles via cctalk wrote:

> I'm using a slightly older SIMH and user's guide (3.8 something). This
> SIMH will not allow Set Console Serial, apparently 

Serial support is not present in versions prior to 4.0.


On Friday, September 13, 2019 at 20:56, Charles via cctalk wrote:

> I just downloaded the latest version 4 from GitHub and sure enough it
> does accept SET CONSOLE SERIAL. Now I just have to figure out the port
> name since it doesn't like COM4:

Enter the port name without the colon (i.e., "COM4" and not "COM4:").  
You'll need to include the optional port configuration, which defaults to 
9600 baud if omitted.

You can verify the valid host port names with a SHOW SERIAL command.

  -- Dave



Re: Connecting SIMH to teletype via USB

2019-09-13 Thread J. David Bryan via cctalk
On Friday, September 13, 2019 at 15:42, Charles via cctalk wrote:

> I could use a hint... I have a USB to current-loop (Volpe) interface
> board, and Windows 7 on my laptop does recognize it as COM4 at 110
> baud. So far so good. No problem hooking it up to my ASR-33 Teletype. 
> 
> Now I'd really like to figure out how to set SIMH to use the 33 as the 
> console, so the TTY will be attached to the virtual PDP-8.

Section 3.14, "Console Options" of the "SIMH Users' Guide V4.0" suggests 
that:

  set console serial=com4;110-8n2

...should work (though you might need "7e2" or "7o2" instead, depending on 
how your Teletype is set up).


> Anything that starts with "set console..." gives a "no settable
> parameters" error.

Does the above also give this error?

  -- Dave



Re: Identification of an HP minicomputer

2019-08-12 Thread J. David Bryan via cctalk
On Monday, August 12, 2019 at 15:48, Guy Sotomayor Jr via cctalk wrote:

> I´ll see about firing it up and if that goes well (anyone have
> suggestions for this type of mini?)

You didn't list the cards in the rear I/O cage (the IDs should be on the
card ejectors).  However, if you have a 12821A HP-IB Disc Interface, you
could run the standard HP diagnostics, which are quite thorough.  They're
available here:

  http://www.hpmuseum.net/display_item.php?sw=567

You'd also need the 12992J CS/80 Disc Loader ROM, if it's not installed
(the binary is available at Bitsavers, and the chip is a fairly common 256
x 4-bit bipolar PROM), a $50 GPIB card for a PC, and Ansgar Kueckes'
HPDrive program:

  http://www.hp9845.net/9845/projects/hpdrive/

...which emulates a cartridge tape drive (among other HP mass-storage
peripherals).  That setup (12821A card/GPIB card/HPDrive program) also
opens up the possibility of running some of the HP disc-based operating
systems without requiring an HP disc or tape drive.

Without removing the CPU, you can't easily tell which loader ROMs are
installed in sockets on the PCB (there are up to four, with the first being
a paper tape loader), except by loading each one into memory and comparing
it to the binary listings in the 12992 manual.

Also, you can't easily determine if any optional firmware instruction set
PCBs are installed (they mount to the CPU board via standoffs).  Removal of
the bottom chassis panel is simple, which will reveal the firmware PCBs,
but the part numbers are on the underside, i.e., facing the CPU board,
typically requiring their removal from the CPU PCB for identification.

  -- Dave



Re: PDP-11 disk image question

2019-02-17 Thread J. David Bryan via cctalk
On 2/16/19 7:55 AM, Bill Gunshannon via cctalk wrote:

> So, I used SIMH to do an install of a complete OS on an RA81 disk.  I
> would like to  move this to a real disk and try it on a real PDP-11.

Note that SIMH always writes disc images in little-endian format, 
regardless of host platform.  If your real PDP-11 expects to see big-endian 
16-bit words coming from the drive, you'll need to byte-swap the disc image 
before writing it to a real disc.

(This is necessary, e.g., when copying an HP 1000 disc image generated by 
SIMH to a real HP disc drive.)

  -- Dave



Re: HP 2000 / 2100 emulator

2018-09-12 Thread J. David Bryan via cctalk
On Wednesday, September 12, 2018 at 21:01, Comcast via cctalk wrote:

> It´s possible to run hp2000 access (or earlier versions) using simh.
>
> You´d just need an interface for your teletypes.

Specifically, SIMH's HP2100 simulator will run HP 2000E, F, and Access
Time-Shared BASIC with external terminals connected via the host machine's
serial ports, and a current-loop-to-RS-232 adapter would permit connection
to the Teletype.

  -- Dave



Re: Anyone have an HP 12661A DVS card manual, 12661-90004?

2018-05-11 Thread J. David Bryan via cctalk
On Friday, May 11, 2018 at 11:29, Al Kossow via cctalk wrote:

> scanned, and uploaded to
> http://bitsavers.org/pdf/hp/21xx/interfaces

Very much appreciated, thanks.

  -- Dave



Re: HP 2100 prototyping card

2018-05-10 Thread J. David Bryan via cctalk
On Wednesday, May 9, 2018 at 16:51, Al Kossow via cctech wrote:

> https://www.ebay.com/itm/163039837440

This card also functions as the Privileged Interrupt Fence in RTE operating 
systems to permit the use of privileged I/O drivers, such as the one for 
the 12920A terminal multiplexer.

  -- Dave



Re: HP 3000/37 console

2018-05-08 Thread J. David Bryan via cctalk
On Tuesday, May 8, 2018 at 0:36, Mike Loewen via cctech wrote:

> Does anyone know if a non-HP terminal will work as the console for
> a HP 3000 Series 37?

Page 3-7 ("Minimum Requirements for Terminals") of the "Series 37 System 
Processing Unit Self-Paced Hardware Training Guide" (32450-90001 June 1984) 
begins with:

 * The system console must be connected to port 0 on the TIC installed in
   slot 1 (channel 1) of the SPU. MPE and DUS expect this configuration.

 * The ENQ/ACK handshake capability must be present.

That suggests that it won't.


> The power-on self-test uses ENQ/ACK to speed sense, but the manual also
> implies that it will sense speed from a .

Page 7-27 (functional description of the TIC) says:

   Speed sensing is accomplished by executing an ENQ/ACK handshake with
   the connected device.  [...]  If there is no response after
   transmitting at all [eight] of the baud rates, the PCC senses the
   line waiting to receive a Carriage Return.  [...]  When the Carriage
   Return is received, the PCC will configure the port for the baud rate
   of the sending device.

But perhaps this doesn't pertain to the system console, as it seems to 
contradict the requirement above.

  -- Dave



Re: Anyone have an HP 12661A DVS card manual, 12661-90004?

2018-05-01 Thread J. David Bryan via cctalk
On Monday, April 30, 2018 at 10:22, Al Kossow via cctech wrote:

> If it doesn't turn up in what I have, I'll check with Jeff to see if he
> still has it.

If I'm not imposing, could you also please ask him for:

  OPERATING AND SERVICE MANUAL
  12653A LINE PRINTER INTERFACE KIT
  FOR 2767A LINE PRINTER
  MANUAL NO. 12653-90002
  [1 copy OCT 1970]
  [1 copy MAR 1973]
  [Card #12653-60002, cable #12653-60001]

...in the same "orange file box" as the 12661 manual?  Thanks.

  -- Dave



Re: Attaching SIMH devices without halting simulation?

2017-12-31 Thread J. David Bryan via cctalk
On Sunday, December 31, 2017 at 14:03, Mark J. Blair via cctalk wrote:

> That appears to work perfectly. I don't know what I did wrong when I tried
> that before.

You mentioned that you "tried putting the system console on a telnet port," 
so you might have used the "SET CONSOLE TELNET" command (section 3.14 in 
the user's guide).  This separates the system console from the simulation 
console, leaving the latter attached to the initiating window.  But you 
still have to interrupt simulation with CTRL+E (at the simulation console) 
to enter the ATTACH command.

The "SET REMOTE TELNET" command, by contrast, connects a second, limited 
simulation console in parallel with the original simulation console.  
Commands entered at the remote console are performed internally by stopping 
the simulation, executing the command, and then resuming.  The simulator 
still pauses to execute the command, but only for the minimum time 
necessary.


> Thanks! 

You're welcome.

  -- Dave



Re: Attaching SIMH devices without halting simulation?

2017-12-31 Thread J. David Bryan via cctalk
On Sunday, December 31, 2017 at 12:58, Mark J. Blair via cctalk wrote:

> Is there any way to attach/detach media images in SIMH without halting the
> simulation?

See section 3.15, "Remote Console" in the SIMH User's Guide.  The "SET 
REMOTE TELNET" command will allow you to attach and detach while the 
simulator is running.

  -- Dave



RE: (Classic Computers) HP 7970 1/2" 9-Track Reel-to-Reel Tape Drive

2017-10-09 Thread J. David Bryan via cctalk
Marc,


On Sunday, October 8, 2017 at 11:48, CuriousMarc wrote:

> Thanks, I wasn't aware of this subtlety.

You're welcome.


> But this is for the 7970E only, right? 

Right.


> Can you boot a 21MX from a 7970B tape with the standard boot ROM? 

Yes.

The boot ROM data transfer loop is just a tiny bit too slow -- 14.26 usec 
worst case (i.e., with an intervening RAM refresh) -- for the 1600 bpi 
interface, which allows 13.9 usec before indicating a Timing Error.  The 
800 bpi interface allows double that time, which the ROM loop easily meets.

  -- Dave



RE: (Classic Computers) HP 7970 1/2" 9-Track Reel-to-Reel Tape Drive

2017-10-06 Thread J. David Bryan via cctalk
On Tuesday, October 3, 2017 at 20:58, Jay West via cctalk wrote:

> Wasn't there some deal where a M/E/F could drive it at 45ips but a 2100
> couldn't (next lower speed)?? 

You might be thinking of the limitation regarding the use of the 12992D 
Magnetic Tape Loader ROM with a 1000 M-Series and a 7970E (1600 bpi) 
operating at 45 ips.  This bootstrap loader used skip-on-flag 
(word-at-a-time) mode, and the data transfer loop could not keep up at tape 
speeds greater than 37.5 ips.  The faster E- and F-Series CPUs could run 
the bootstrap with the drive configured for the full 45 ips.

The 2100 and the 1000 M/E/F-Series machines had no such limitation if 
DMA/DCPC was used to access the tape drive.  DMA wasn't used in the boot 
loader ROM because the code wouldn't fit in the 64-word ROM size.

(That said, I've rewritten the 12992D bootstrap to tighten the timing 
loops, and it works fine on my 1000 M-Series and 7970E drive.  I think the 
original limitation was due to suboptimal coding.)

  -- Dave



Re: HP 12653A line printer interface

2017-07-11 Thread J. David Bryan via cctalk
Marc,


On Monday, July 10, 2017 at 22:24, CuriousMarc wrote:

> I thought I did, but what I have is the HP 12845B Line Printer interface
> card, for which I could find the documentation.

Thanks for checking.  Yes, that does seem to be the more common card.  As 
far as I know, the 12653A was used only for the HP 2767 (a rebranded Data 
Products 2310), whereas the 12845B was used for a number of other HP 
printers.


> Reading some more, it is meant for the 2607/261x series of printers,
> which apparently use a narrower 7 bit interface (the 12566 is a 16 bit
> interface card).

Which is all a bit odd, as the 2767 also uses 7 bits for data.  Unlike the 
other printers that use differential interfaces, the 2767 uses single-ended 
TTL-level (more or less) drivers and receivers, which may explain the use 
of the microcircuit-based interface.

The 2767 signal drivers are adjustable for a 3- to 8-volt output level, so 
perhaps the 12635A "modification" was to clip the inputs to avoid damaging 
the standard microcircuit receivers (7400 TTL with an absolute maximum 
input spec of 5.5 V).  In the absence of a manual, I was hoping that a 
photograph would reveal the modification.


> But maybe you can inspire yourself from it.

The existing 2767/12653 simulation was reverse-engineered from the 
diagnostic and OS drivers.  Although it works, I was hoping for something 
more authoritative so that the code could serve as a reference for the 
now-extinct hardware.

  -- Dave



HP 12653A line printer interface

2017-07-05 Thread J. David Bryan via cctalk
Does anyone have an HP 12653A line printer interface?

It is used to connect an HP 21xx/1000 CPU to an HP 2767A line printer.  I 
am unable to find a manual for this card, but the HP "General Purpose 
Register Diagnostic" manual suggests that it is a modified HP 12566B 
Microcircuit interface.  I'm trying to determine what modifications were 
made, so that I can model it accurately in the SIMH/HP2100 simulator.

If anyone has this card and wouldn't mind sending me high-resolution photos 
of the front and back, I'd be most grateful.

  -- Dave



Fourth release of the HP 3000 Series III simulator

2017-01-25 Thread J. David Bryan
The fourth release of the HP 3000 Series III simulator is now available 
from the Computer History Simulation Project (SIMH) site:  

  https://github.com/simh/simh

This release adds the HP 32234A COBOL II Extended Instruction Set firmware, 
enabling execution of programs produced by the COBOL II ('74 and '85) 
compilers.  The new SET CPU CIS option enables the firmware.

In addition, two new debug tracing options were added.  The SET CPU 
DEBUG=OPND command turns on memory byte operand tracing to show the values 
supplied, e.g., to the CMPS (Compare String) instruction.  The SET CPU 
DEBUG=EXEC command turns on execution tracing for a specific instruction or 
instruction family.

The full set of new features is listed in the release notes that accompany 
the simulator source files.  In addition, an updated HP 3000 Simulator 
User's Guide that covers the new commands is provided in Microsoft Word 
format with the source download and also as a PDF file at:

  http://alum.mit.edu/www/jdbryan/hp3000_doc.pdf

The preconfigured MPE-V/R disc image available here:

  http://simh.trailing-edge.com/kits/mpe-vr-software-kit.zip

...has been updated to add the COBOL II runtime routines to the system 
Segmented Library and COBOL example programs to the OPERATOR.SYS account.  
The startup command files also now enable the COBOL II instruction set.  

  -- Dave Bryan



Third release of the HP 3000 Series III simulator

2016-09-21 Thread J. David Bryan
The third release of the HP 3000 Series III simulator is now available from 
the Computer History Simulation Project (SIMH) site:

  https://github.com/simh/simh

This release adds the cold dump facility.  Entering the DUMP command 
simulates pressing the ENABLE and DUMP front panel buttons.  The contents 
of main memory are written to an attached magnetic tape in a format 
suitable for analyzing with the DPAN4 program provided with MPE.  The new 
SET CPU DUMPDEV and SET CPU DUMPCTL options specify the default device 
number and control byte for the dump.

Also, the user may simulate a system power loss with the POWER FAIL command 
and resume powered operation with the POWER RESTORE command.  The SET CPU 
ARS/NOARS command determines whether or not MPE automatically restarts when 
power is restored.

The full set of new features is listed in the release notes that accompany 
the simulator source files.  In addition, an updated HP 3000 Simulator 
User's Guide that covers the new commands is provided in Microsoft Word 
format with the source download and also as a PDF file at:

  http://alum.mit.edu/www/jdbryan/hp3000_doc.pdf

The preconfigured MPE-V/R disc image available from Bitsavers:

  http://www.bitsavers.org/bits/HP/HP_3000/

...was not changed for this release.

  -- Dave



Re: HP Computer Museum in the (local) News

2016-07-22 Thread J. David Bryan
On Friday, July 22, 2016 at 17:43, Rodney Brown wrote:

> http://www.abc.net.au/news/2016-07-22/vintage-computer-museum-revives-hp21
> 16a-founder-dies/7638458
> 
> A keen mountaineer who died trekking in Tibet has left a rare computer
> collection behind as his legacy.

A touching article; thanks for posting it, Rodney.

  -- Dave



Re: Second release of the HP 3000 Series III simulator

2016-07-09 Thread J. David Bryan
On Friday, July 8, 2016 at 8:57, SPC wrote:

> So I assume that we can make operative programs *only* with the COBOL
> 74 compiler, Isn't so ?

The software kit contains two COBOL compilers:

 - a COBOL '68 compiler invoked with the :COBOL command

 - a COBOL '74 compiler invoked with the :COBOLII command.

The second compiler has an alternate mode, invoked with the :COBOLIIX 
command, where it operates as a COBOL '85 compiler.  This second compiler, 
in either '74 or '85 mode, generates programs that use the HP 32234A COBOL 
II firmware instructions.  These instructions are not yet implemented in 
the simulator.

Programs generated with the COBOL '68 compiler will run on the simulator.

As Keven mentioned, the kit also comes with BASIC, FORTRAN '66, Pascal, 
RPG, and SPL compilers.  Programs generated with these compilers will run 
on the simulator too.

  -- Dave



Second release of the HP 3000 Series III simulator

2016-07-07 Thread J. David Bryan
The second release of the HP 3000 Series III simulator is now available 
from the Computer History Simulation Project (SIMH) site:

  https://github.com/simh/simh

This release adds a simulation of the HP 2607, 2613, 2617, and 2618 line 
printers and supports the use of custom VFU tape images, as well as the 
built-in HP-standard VFU tape.  The full set of configurable options is 
detailed in a new section of the HP 3000 Simulator User's Guide that is 
provided in Microsoft Word format in the "doc" subdirectory of the code 
base snapshot downloaded from the github site.  A PDF version of the 
updated manual is also available at:

  http://alum.mit.edu/www/jdbryan/hp3000_doc.pdf

In addition, the preconfigured MPE-V/R disc image available from Bitsavers:

  http://www.bitsavers.org/bits/HP/HP_3000/

...has been updated to add the following features:  

  - The MPE cold load command files attach the line printer to the "lp.txt"
output file and specify the "-n" option to clear the file before use.

  - Preinstalled User-Defined Commands (UDCs) provide access to the COBOL
74 compiler with the MPE-V/E :COBOLII, :COBOLIIPREP, and :COBOLIIGO
commands, and to the COBOL 85 compiler with :COBOLIIX,
:COBOLIIXPREP, and :COBOLIIXGO.  However, note that the simulator
currently does not provide the HP 32234A COBOL II firmware
instructions, so programs generated by the COBOLII compiler will
abort at run time with "ILLEGAL INSTRUCTION" errors, limiting the
current utility of the compilers to syntax checking. 

Thanks once again go to Frank McConnell for providing the HP line printer 
subsystems manuals that facilitated development of the new simulation, and 
to Robert Mills for providing the COBOLII UDCs.

  -- Dave



Release of the HP 3000 Series III simulator

2016-03-07 Thread J. David Bryan
I am pleased to announce the release of a simulator for the HP 3000 Series 
III computer system.  It is available from the Computer History Simulation 
Project (SIMH) site:

  https://github.com/simh/simh

The simulator runs the MPE-V/R operating system, supports a selection of 
simulated disc and tape drives, and accommodates up to sixteen concurrent 
users.  A software kit containing a disc image with MPE preinstalled is 
available as described in the release notes that accompany the simulator.

I would like to thank Frank McConnell and Al Kossow for their invaluable 
help in answering questions and supplying documentation for the HP 3000.

  -- Dave



Re: HP 21MX paper tapes

2016-03-07 Thread J. David Bryan
On Monday, March 7, 2016 at 22:14, Mattis Lind wrote:

> I have been going to our HP 21MX paper tapes that come with a M-series
> system that we received many years ago:
> 
> http://www.datormuseum.se/documentation-software/hp-paper-tapes
> 
> I tried to check if they already were available online somewhere but
> didn't find them 

The HP 1000 Software Collection at Bitsavers has a numerical list of all of 
the tape images that are archived.  It's under:

  /bits/HP/HP_1000_software_collection/master-files/

Please check your list against the "master-files-list.txt" file, which 
lists all of the files in the collection.  But first, please check against 
"master-bad-files-list.txt", which are the files in the collection that are 
damaged.  If you have good copies any of the damaged files, or of any files 
that are not in the full list, they would be welcome additions.

  -- Dave



RE: 21MX proms (per request

2015-09-13 Thread J. David Bryan
On Sunday, September 13, 2015 at 8:42, Jay West wrote:

> 3) Any I/O instructions in the loader are automatically patched during
> the transfer (based on switch register bits 11 through 6) so that the
> correct I/O address (device) is referenced.

It's actually a bit more nuanced than this.  What occurs is:

 3a) Except for halt instructions, any I/O instruction referencing select
 code 10 (octal) or greater is patched by adding the select code
 value in the switch register minus 10. 

This means that (a) halt instructions, which are in the I/O group, are not 
altered, (b) DCPC I/O instructions, which reference select codes 2, 3, 6, 
or 7 are not altered, and (c) interfaces that use two select codes, e.g., 
the 7900 disc interface, get both select codes updated properly.  It also 
implies that all loaders are written to reference select code 10 (or 10 and 
11, etc.).

 3b) The two's-complement of the memory address of the first word of the
 loader is stored in the last word in memory.

This is so that loaders can check that what they are loading does not 
overwrite the loader itself.  For example, the paper tape loader does a HLT 
55 if the absolute binary tape contains a record that would overlay the 
loader executable code.

 3c) The contents of the penultimate memory location is patched by adding
 the select code value in the switch register minus 10.

This is used to patch the select code into an optional DCPC control word, 
which is a constant and not an I/O instruction and so wouldn't be patched 
by (3a).  Loaders that use DCPC, e.g., the disc loaders, place their DCPC 
control word at this location.

There's actually quite a lot going on under the hood for that IBL button 
press.

  -- Dave



Re: 21MX proms (per request)

2015-09-06 Thread J. David Bryan
On Sunday, September 6, 2015 at 13:41, Jay West wrote:

> Here's a non-exhaustive but useful list of compatible parts for each:
> 
> [...]
> 
> 4K parts
> Signetics N82S141
> Harris 7641
> MMI 6341

Some additional part numbers:

 - AMD Am27S31
 - National DM87S474


> 8K parts
> Signetics N82S181
> Harris 7681
> MMI 6381

Also:

 - AMD Am27S181
 - National DM87S181

  -- Dave



Re: 1990 Era computer room

2015-06-24 Thread J. David Bryan
On Tuesday, June 23, 2015 at 22:14, jwsmobile wrote:

> Also I don't recall the Data Products ever scaling as fast by
> restricting columns.  At least our 2230, 2260 and 2290 UC only and 96
> character set printers didn't.  Got the same speed regardless of the
> columns on those Data Products printers.

The HP 2767A service manual (02767-90002, available from Bitsavers) is a 
reprint of the Data Products 2310 service manual.  Page 1-17 says:

  "The printer receives data from the user system and stores up to 20
   characters in the buffer memory.  [...]  A full line of data is
   printed in four zones, each zone having 20 consecutive print
   positions.  In this manner, the printer's 20 hammer drivers can be
   time-shared among the 80 print positions." 

...and the spec on page 1-5 says the print rate for the 64-character drum 
is 356 lines per minute for 80 columns, 460 lpm for 60 columns, 650 lpm for 
40 columns, and 1110 lpm for 20 columns.

I tested a 2767A as a customer of the HP Rockville, MD office in the early 
1970s.  As I recall, the character set wasn't staggered on the drum, and 
the hammer force was constant, regardless of glyph area.  The result of 
printing a line of hyphens -- or worse, a line of periods -- was a very 
loud bang and a neatly perfed page.

  -- Dave



Re: HP 2113e Battery resistor

2015-06-23 Thread J. David Bryan
On Tuesday, June 23, 2015 at 11:42, Marc Verdiell wrote:

> Thanks David.

You're welcome.


> I might put NiMH batteries instead

That may not be advisable, given the continuous constant-current trickle 
charger in the CPU power supply.  The Panasonic "Nickel Metal Hydride 
Technical Handbook" recommends charging for no more than 10-20 hours, 
saying:

  "The overcharging of nickel-metal hydride batteries, even by trickle
   charging, causes a deterioration in the characteristics of the
   batteries.  To prevent overcharging by trickle charging or any other
   charging method, the provision of a timer to regulate the total
   charging time is recommended." 

Panasonic's "Nickel Cadmium Batteries Technical Handbook," on the other 
hand, says explicitly that continuous trickle charging for Ni-Cds is a 
recommended charging method.

  -- Dave



RE: 1990 Era computer room

2015-06-23 Thread J. David Bryan
On Monday, June 22, 2015 at 15:39, Jay West wrote:

> The disc drives appear to be HP 7900A drives.

I agree.  A few pictures for comparison here:

  http://www.hpmuseum.net/display_item.php?hw=275

The printers appear to be Data Products 2310 drum printers, also sold as 
the HP 2767A; photos:

  http://www.hpmuseum.net/display_item.php?hw=332

The ones in the original photo do not appear to be the HP versions, though, 
as there are no HP badges present under the operator panels.

  -- Dave



Re: HP 2113e Battery resistor

2015-06-22 Thread J. David Bryan
On Monday, June 22, 2015 at 11:44, Marc Verdiell wrote:

> Now if I can find similar cells I will be able to reconstruct the pack
> inside the same shell.

Ni-Cds are still available from Allied Electronics, Mouser Electronics, and 
others, although they are declining in availability compared to a few years 
ago.

Before investing in a set of batteries, it'd be worthwhile to verify that 
you do have the required battery cards inside your power supply:

 - 5060-8347 Battery Control I PCA
 - 5060-8353 Battery Control II PCA
 - 5060-8346 Battery Output PCA

...as the "12944A Power Fail Recovery System" containing the above card set 
and the battery box and pack was an option to the standard CPU 
configuration.


> Thanks again.

You're welcome.

  -- Dave



Re: HP 2113e Battery resistor

2015-06-21 Thread J. David Bryan
On Sunday, June 21, 2015 at 16:43, Marc Verdiell wrote:

> On this machine the battery connectors are just two pronged, + and -,
> so no thermistor connection apparently. 

That marks it as an "A-version" power supply.


> I just need to find new small 12V lead batteries that fit. 

Note that the "A" supply used a 12 Volt nickel-cadmium battery pack (per 
page IXA-1 of the M/E/F-Series ERD), and the charger is a constant-current 
supply.  The pack is not broken down in the parts list but presumably would 
have contained ten 1.2-Volt cells.

The "B" supply used a 14 Volt lead-acid battery pack (ERD IXB-5), so seven 
2.0-Volt cells, and the charger is a constant-voltage supply.

If you use lead-acid batteries with the "A" power supply, you may wind up 
overcharging them and shortening their life.

  -- Dave



RE: Memory options for an HP 1000 (HP 21MX / 2112A)

2015-05-23 Thread J. David Bryan
On Saturday, May 23, 2015 at 17:48, Marc Verdiell wrote:

> I think I should retrace the path of technology evolution. Start
> getting it up with paper tape tests and BCS. That probably means working
> mostly in assembly and getting to know the most basic level of the
> machine. Which is just about what the doctor prescribed. 

Assuming that you have a working paper tape punch and reader, and the 
associated interface cards, then that's a very workable approach.


> I got a 7900 disk though (with cables and power supply, but no
> interface cards to go with it!). 

The interface is HP product number 13210A.  It's a two-card set; the card 
numbers are 13210-60004 and 13210-6.  The I/O cable is 13210-60003.


> I'd love to get that one going later on. Then it would make sense to
> have the bigger memory to run disk based OS systems. 

The 7900A was supported through the final RTE versions.  However, you could 
run the disc-based DOS-III OS with just the hardware and memory you have 
(assuming that you add the 7900 disc I/O interface).  With the addition of 
a HP 12539 Time-Base Generator card and 8K more of memory, you could also 
run RTE-II on a 7900.  Neither DMS nor more extensive memory is required 
for these OS versions, which are substantial steps up from BCS in terms of 
sophistication and ease of use.


> By the way I also have a punched card reader which I just restored.
> Documation ML600, but the exact same model that HP re-branded I
> believe. 

That's either the HP 2892A or 2893A, depending on whether it has a TTL or 
differential interface, respectively.


> Do you know which interface cards I need to connect it to the HP-1000? 

The interface is the HP 12924A, which was specific to the 2892A card 
reader.  The 2893A was supported only on the HP 3000, as far as I know.


> I suppose one of the 16 bit IO ones with a driver to go with it?

The general-purpose TTL interfaces apparently would not work.  Drivers for 
the card reader were supplied with the various OSes.


> Sorry to keep picking your brain, but that is so much more efficient
> than trying to piece it together (usually wrong at first) from an
> disorganized pile of documentation!

I'm glad that I can be of help.

  -- Dave



Re: Memory options for an HP 1000 (HP 21MX / 2112A)

2015-05-22 Thread J. David Bryan
On Thursday, May 21, 2015 at 23:45, Marc Verdiell wrote:

> I took a quick look inside to confirm
> 
> - there is a DCPC and a MEM protect card

Good.  (To avoid confusion with the Memory Expansion Module, the latter 
card is usually designated MP or Memory Protect.)


> - No MEM card in slot 112

OK.


> - Under the processor board there is a screwed on card, which seems to
> have ROM on it. Microcode I presume, but I don't know if that's the one
> you were talking about.

One such card is present in all M-Series systems and contains the microcode 
for the base set of instructions.  If there's DMS or FFP/DMS firmware 
present, it would be on a second such card, mounted next to and connected 
via an edge-card connector socket to the base set card.

It sounds as though DMS is not present.


> The IO cards and the paper tape reader / punch that came with it
> suggest that it was configured with a paper tape reader, a paper tape
> punch, a mag tape and a TTY interface. A plausible story is that this
> was an early machine setup for paper tape and TTY and didn't have
> extended memory. 

A reasonable assumption.

Did it come with any software on paper tape (or mag tape)?


> So I might be in the hunt for the cards or alternate solutions you
> mentioned.

I'd suggest that the question to answer first is whether you want to expend 
the effort and expense to gather the moderate amount of additional hardware 
necessary to run one of the more advanced disc-based OS versions that can 
use DMS.  Note that the design of the memory mapping hardware in the 1000 
requires explicit software support (i.e., programming of the DMS hardware) 
in order to use more than 32KW of memory.  Earlier OSes that did not 
support DMS will simply ignore all memory in the machine over 32K, even 
when DMS is present.

With the hardware you have, you can run a paper-tape based OS, such as BCS 
(the Basic Control System) in 24K.  BCS is fairly primitive, but it does 
offer an assembler, FORTRAN IV, and ALGOL compilers, and paper-tape BASIC 
interpreters were also available (from the user contributed library).

The hardware requirements for running the disc-based RTEs are listed on 
these HP Computer Museum pages:

  http://www.hpmuseum.net/display_item.php?sw=565
  http://www.hpmuseum.net/display_item.php?sw=566


  -- Dave



Re: Memory options for an HP 1000 (HP 21MX / 2112A)

2015-05-20 Thread J. David Bryan
On Tuesday, May 19, 2015 at 23:12, Marc Verdiell wrote:

> Thanks, very useful info, and the manual is indeed what I was missing.

You're welcome.


> But now where to find the DMS, with two cards in particular, that's not
> going easy to find both that match...

First, are you sure that the machine does not have DMS installed?  It was a 
very common option that became standard later on, as all versions of the 
RTE operating system after RTE-II (circa 1976) required it.

Second, if the machine originally came with DMS but was stripped for 
resale, then possibly only the MEM card (in slot 112) was removed.  The 
firmware card is screwed onto the CPU board on the underside of the machine 
and is only accessible if the bottom cover is removed.  So maybe it was 
overlooked, and the availability of MEM cards is likely to be reasonable, 
as the same card (but with different firmware) was used in the E/F-Series 
machines.

Third, if the machine has neither DMS part, then indeed finding an M-Series 
DMS firmware card might be difficult.  However, DMS firmware was also 
included with the later M-Series Fast FORTRAN Processor firmware (product 
number 12977B).  Again, the FFP was a common option, and availability of 
that card might be better than the older standalone DMS firmware card.

Fourth, if you can find a standalone MEM card, the M-Series DMS/FFP 
firmware source is part of the HP 1000 Software Collection on Bitsavers, so 
you could burn the required firmware PROMs and install them on a 12791A 
Firmware Expansion Module card, which plugs into the I/O backplane and 
cables to the CPU board.  Both the FEM and the MEM were used on E/F-Series 
machines, so availability should be reasonable.

Finally, the simplest HP operating system that used DMS (RTE-III) had 
additional hardware requirements: a Memory Protect card, a Dual-Channel 
Port Controller (i.e., DMA) card, one of several console I/O cards, a Time-
Base Generator (i.e., clock) card, and either an HP 7900A or 7905/06/20/25A 
hard drive and its associated I/O interface(s).  The latter may be the most 
difficult and expensive part.  You can avoid the hard drive and use Ansgar 
Kueckes' HPDrive emulator with an HP-IB I/O card, but that requires RTE-IVB 
as the minimum OS, which requires at least 96KW of memory (128KW if you 
want to do anything other than boot the system :-).  MP and DCPC also were 
exceedingly common options, so I'd be surprised if your system didn't 
contain them, unless they've been stripped out for resale.

Without DMS, you're limited to 32KW.  In that, you could run (with some 
additional hardware, most notably an HP hard drive) DOS-III or RTE-II.  
Without a hard drive, you'd be limited to running one of several paper tape 
or mag tape-based HP OSes.  There are third-party OSes that run on the 
1000, but I know nothing about them.

At least software is no problem; virtually everything that HP developed for 
the 2116/2100/1000 machines is available via the Bitsavers collection.

  -- Dave