[cctalk] Re: Tips on VME board access
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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: HP 2113e Battery resistor
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
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
