Date   

Re: 9825 disassembly status

Paul Berger
 

Craig:

You understand that there are two 1K word windows into the ROM and the bank selection is done by write to the area occupied by the base page ROM, I think my writeup included with the package gives a good description of how it works.

Paul.

On 2017-02-11 4:46 PM, Craig Ruff wrote:
I’ve been working on preliminary disassembly of the 9825T ROMs this week, and have some initial symbol information and comments generated for the built in extension ROMs. Nothing to the detail of those from the patent listing, but enough to start deciphering what is going on in each ROM.

I started looking at the banked 98228A disk ROM today. My disassembler currently does not understand banking, so I just have to dump the base page and each of the other banks separately. I did have to byte swap the 16-bit ROM image that Paul provided so that the byte order conformed to those of the mainframe ROMs. I expect that this is done by the ROM pin connections in his clone module. My ROM header decoder script was then happy with the 98228A base page, so I will proceed with some investigation of this ROM’s contents.


9825 disassembly status

 

I’ve been working on preliminary disassembly of the 9825T ROMs this week, and have some initial symbol information and comments generated for the built in extension ROMs. Nothing to the detail of those from the patent listing, but enough to start deciphering what is going on in each ROM.

I started looking at the banked 98228A disk ROM today. My disassembler currently does not understand banking, so I just have to dump the base page and each of the other banks separately. I did have to byte swap the 16-bit ROM image that Paul provided so that the byte order conformed to those of the mainframe ROMs. I expect that this is done by the ROM pin connections in his clone module. My ROM header decoder script was then happy with the 98228A base page, so I will proceed with some investigation of this ROM’s contents.


Re: Unobtanium obtained!

 

On Wed, Feb 8, 2017 at 08:01 am, Jack Rubin wrote:
 I live near Chicago and got a brief chance to say hello to you at VCF-Midwest last year though you were probably too deep in Jay West's system to remember! 

 Yes, this was my first VCF and I was a bit overwhelmed, not knowing anyone really. I came primarily to meet Jay and learn more about his experience with restoring HP 1000's. I learned more than I hoped for as we (that is, mostly Jay) powered up and succesfully debugged a 1000-E right at the show! When is the show this year?


Re: Unobtanium obtained!

 

Actually, I just stuck a DC2000 in an unmodified 9825 tape drive , and to my surprise it worked a little bit. The tape fit nicely, transport seemed to work fine, it rewound on the correct reel. I tried to initialize a few files, sometimes I could read the entire "catalog" back, sometimes I had errors. I don't know if it's my drive or if I need to make a write current modification for the new tape like I did on the HP 85. I suspect it's the latter, so that would next step. Anyhow I thought it was encouraging.

Marc 


Re: Unobtanium obtained!

Jack Rubin
 

Marc (and everyone else),

Yes, we live in exciting times! :>)

I'm about to rebuild my HP85 tape drive capstans for DC100 tapes; I don't have the resources for the full DC2000 conversion. Hopefully, DC100 cassettes with new belts will be a little more robust but I just got my plastibands yesterday and I have the same concerns that you do though I've yet to actually crack a cassette and try one. If nothing else, at least the cassettes will be more colorful with bright pink and green drive belts. I'll be looking forward to hearing about your results.

From Rik's early results, it seems that rebuilding the drives for the 9825 drives will be a bit more challenging to retrofit for DC2000 tapes so hopefully the DC100 fix will provide at least an interim solution.

Unfortunately, I'm not in the Bay area though I used to visit Larry on business trips to the coast. I live near Chicago and got a brief chance to say hello to you at VCF-Midwest last year though you were probably too deep in Jay West's system to remember! I'm planning a return to VCF-West later this year so we should be able to meet then.

Jack



Re: Unobtanium obtained!

 

Rik, thanks so much for the detailed instructions. I am just at the step where I need to do just that, try to read old DC100 tapes.


Re: Unobtanium obtained!

 

Awesome discovery. This group is making great progress. With Paul's Flex Disc ROM reverse engineering, you could just copy it to a 9895 8" disk, and with Ansgar Kueckes HPDIR transfer the image back to my (not so) modern PC dedicated to do just that. Actually scratch that, since you can emulate a 9895 with Ansgar HPDRIVE, I could just hook that up to the 9825 and dump it straight to the PC! That should be very straightforward. I'd have to build the ROM first (I intend to make a PCB when I get a chance). And get a lot of practice to get really good at reading DC 100's in my restored tape drive following Rik's advice. So this would take a while.

I have ton's of rather new DC2000 that I can steal the bands from, and quite a few old DC100 to practice read (maybe 15 or so). I also just received my plastibands, but was disappointed at how stretchy and sticky they felt, I am not holding my breath for these. I'll try them out just for kicks. Lots of practice coming up.

I am also going to splurge on some Kathana's for good measure, so I have a set of known good tapes. 

Jack, you mention Larry Lehman, who was based in San Jose, CA, close to where I live. I have quite a few parts from him - like most of the local HP collectors. Are you local to me in the San Francisco Bay area by any chance?


Re: Using VGA TFT monitors on HP 9000/300 series

Ansgar
 

I'm not an expert on this, but I guess the dark green effect depends on the nature of the sync signals. The sync signal is added to the green video signal, but the sync can be either a high pulse or a low pulse (depending on the video board). If you have a high pulse on sync, you probably will not notice any effect on the black level (the high pulse is restricted to retrace), whereas if you have a low pulse, the sync signal is high during a normal scanline run and low during retrace. Take it as a weak trial for explanation. In fact the LM1881 does not remove the sync from the video signal (it actually has no video output), but replicates the sync info to its sync outputs. But it should be possible to subtract the composite sync (coming from the LM1881) from the original green video signal by another circuit (e.g. opamp) and so achieve a "clean" green signal.

-Ansgar


New file uploaded to VintHPcom@groups.io

VintHPcom@groups.io Notification <VintHPcom+notification@...>
 

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the VintHPcom@groups.io group.

File: Pascal.rar

Uploaded By: Rik Bos

Description:
HP Pascal 3.25 hpi image tailored for the HP 9000/380 /382 /345 /375 Supports fast HP-IB and HFS partions. HP-IB address for the image is 0 and drive emulation is set to HP 7958B.

You can access this file at the URL:
https://groups.io/g/VintHPcom/files/HP9000%20S200300/Pascal.rar

Cheers,
The Groups.io Team


Re: Using VGA TFT monitors on HP 9000/300 series

 

I’m using a Belinea 10 17 05 and Samsung SyncMaster 720N with both medium (1024 x 768) and high (1280 x 1024) resolution cards. I haven’t noticed any problem with the green color. I know the 1881N is susceptible for parasitic capacities on the input but that shouldn’t influence the green color levels.

 

-Rik

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Ansgar
Verzonden: maandag 6 februari 2017 21:33
Aan: VintHPcom@groups.io
Onderwerp: Re: [VintHPcom] Using VGA TFT monitors on HP 9000/300 series

 

I currently use a NEC 1770NX (the "NX" is important!) and am quite satisfied. Not every monitor with sync-on-green works well, this one does (and looks damn good). I guess for proper operation the horizontal sync capabilities are essential. Jon from hpmuseum once said (and it is still on his web site) that the  NEC LCD1800, LCD1810, LCD2010 and LCD1830 are good replacements for the higher resolution HP monitors, but I personally like the more compact 17" and especially the more decent 1770NX. The NEC starts hsync at ~30 kHz (original VGA timing). The low res monochrome video boards, however, provide a 15 kHz hsync, which is supported only by some LCDs with composite video input. My DELL for example has that kind of input, but still does not detect the output from the low res HP 300 monochrome boards, So I am glad I still have my 82913A at hand.

I also tried with an LM1881 sync splitter, but it cannot replace a true sync-on-green input circuit (the LM1881 does not correct the wrong black level, or shall I say dark-green-level...).


Re: Using VGA TFT monitors on HP 9000/300 series

Ansgar
 

I currently use a NEC 1770NX (the "NX" is important!) and am quite satisfied. Not every monitor with sync-on-green works well, this one does (and looks damn good). I guess for proper operation the horizontal sync capabilities are essential. Jon from hpmuseum once said (and it is still on his web site) that the  NEC LCD1800, LCD1810, LCD2010 and LCD1830 are good replacements for the higher resolution HP monitors, but I personally like the more compact 17" and especially the more decent 1770NX. The NEC starts hsync at ~30 kHz (original VGA timing). The low res monochrome video boards, however, provide a 15 kHz hsync, which is supported only by some LCDs with composite video input. My DELL for example has that kind of input, but still does not detect the output from the low res HP 300 monochrome boards, So I am glad I still have my 82913A at hand.

I also tried with an LM1881 sync splitter, but it cannot replace a true sync-on-green input circuit (the LM1881 does not correct the wrong black level, or shall I say dark-green-level...).


Re: Unobtanium obtained!

 

Ok, some remarks about restoring tapes and something about the tapes I have.

After a private mail from Jack, I checked my tape inventory.

The tapes I have are :

09915-10014 Tape duplication and eprom programming

09877-10002 9825 B/T tape binary

09825-90036 9825A System test Rev. A, E & F

09885-90035 9885 System Tape Cartridge Rev. F and D

09815-10004 9815 General Utility and Test routines

09831-10004 9831A General Utility Routines

09825-10004 9825A General Utility Routines (Available on the Museum site I believe)

03042-90211 3042A Verification Application

03045-10001/10002 3045A (9825) System Program and Compiler tapes

09835-90041 9835 A/B System Test

09825-12524 9825 Waveform Analysis

And probably some other tapes which I overlooked in the hurry…

 

All those tapes are on my backlog for archiving, but..

Most of the times I only get one chance to read a HP 98200 type of tape.

To understand why I’ll explain the way I read 98200 tapes, the procedure is the following:

 

First I have to open the case and warm the tape to about 50-60C(degrees) so I can remove the drive belt without ripping the magnetic layer of.

The next thing is backing the tape at 60C for 2 or 3 hours, this dehydrates the tape and prevents the magnetic layer coming loose.

Next step is cleaning the tape guiding posts and placing a ‘new’ belt and getting the tape tension right.

After closing the tape I have about 3 or 4 runs to read the tape and copy it to a disc.

It’s mandatory to clean the heads after every run, sometimes I also have to clean the guiding posts in the tape cassette because there is too much tape friction to read the tape.

Friction between the tape and guidance posts can ruin the tape by stretching it too much!

I’ve used this procedure to recover information from about  10 tapes, 80% of the time it worked..

I used the same procedure for DC600 (9144/45 tapes) to recover HP-UX files.

One last remark after the tapes have cooled down from the oven you will have about one or two days before the tapes will degrade and become sticky and flaky again.

A second run in the oven doesn’t work in most cases, so it’s a one-time right case.

 

-Rik

 

 

 

 

 

 

 

 

 

 

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Craig Ruff
Verzonden: zaterdag 4 februari 2017 14:40
Aan: Vin
tHPcom@groups.io
Onderwerp: Re: [VintHPcom] Unobtanium obtained!

 

 

On Feb 3, 2017, at 9:22 PM, Jack Rubin <j@...> wrote:

 

Who is best qualified to attempt to read these tapes and hopefully image the data on them?

 

I believe a 9875 should be useable to read the data off these tapes, and I think, also to create new tapes.  There are commands RF (read file), RR (read record), WF (write file), and WR (write record) that allows the transfer of arbitrary data words.  Sounds like incentive for me to get to figuring out the issue with my 9875 next so I can test it.

 

With a suitable binary program, it may be possible for a 85 A/B to also image these tapes if the tape controller uses the same low level encoding format, but I don’t know the answer to this.


Re: Unobtanium obtained!

 


On Feb 3, 2017, at 9:22 PM, Jack Rubin <j@...> wrote:

Who is best qualified to attempt to read these tapes and hopefully image the data on them?

I believe a 9875 should be useable to read the data off these tapes, and I think, also to create new tapes.  There are commands RF (read file), RR (read record), WF (write file), and WR (write record) that allows the transfer of arbitrary data words.  Sounds like incentive for me to get to figuring out the issue with my 9875 next so I can test it.

With a suitable binary program, it may be possible for a 85 A/B to also image these tapes if the tape controller uses the same low level encoding format, but I don’t know the answer to this.


Re: Unobtanium obtained!

Paul Berger
 

Wow nice find those tapes are indeed rare there is no complete copies known to exist.

Paul.


On 2017-02-04 12:22 AM, Jack Rubin wrote:

 I figure this is worth a new message topic. Today, I finally relocated 3 boxes of HP 80 series and 9825 items that got lost in storage during a move nearly 10 years ago. I haven't even gotten to the 85/87 stuff yet, but the 9825 box included a few data cartridges - three with user data and then:

** 09825-90035 - 9825A System Test Cartridge **

** 09885-90035 - 9825A/B 9885 System Tape Cartridge **

Also included was a 98015-66501 disk alignment fixture for the 9885 drives and a couple of 98032-085 disk interface cables.

I'm pretty sure I got all this stuff from Larry Lehman when he was shutting down Crisis Computers but at the time I was much more interested in the 2100 boxes and just sort of scooped these things up without paying much attention. Until I found them this afternoon, I didn't even remember getting them.

The tapes have been in cool, dry storage since I got them - I've never tried to use them and I certainly won't now!

Who is best qualified to attempt to read these tapes and hopefully image the data on them? I'll pose the same question directly to Al Kossow and Chuck Guzis but if the expertise is here, please let me know.


Jack




Unobtanium obtained!

Jack Rubin
 

 I figure this is worth a new message topic. Today, I finally relocated 3 boxes of HP 80 series and 9825 items that got lost in storage during a move nearly 10 years ago. I haven't even gotten to the 85/87 stuff yet, but the 9825 box included a few data cartridges - three with user data and then:

** 09825-90035 - 9825A System Test Cartridge **

** 09885-90035 - 9825A/B 9885 System Tape Cartridge **

Also included was a 98015-66501 disk alignment fixture for the 9885 drives and a couple of 98032-085 disk interface cables.

I'm pretty sure I got all this stuff from Larry Lehman when he was shutting down Crisis Computers but at the time I was much more interested in the 2100 boxes and just sort of scooped these things up without paying much attention. Until I found them this afternoon, I didn't even remember getting them.

The tapes have been in cool, dry storage since I got them - I've never tried to use them and I certainly won't now!

Who is best qualified to attempt to read these tapes and hopefully image the data on them? I'll pose the same question directly to Al Kossow and Chuck Guzis but if the expertise is here, please let me know.


Jack



Re: 9825 restoration notes and questions

 


On Feb 3, 2017, at 2:25 PM, Paul Berger <phb.hfx@...> wrote:

I don't think it is that big a deal I am half way there already with the rig I used to dump the ROMs.  The service manual talks about the signals the state machine monitors and what they mean.  the ROM feeds 6 bits into a an 8-1 multiplexer that select a bit based on the state of  A12, A13, and A14, in other word the 4K ROM provided a bit map of the the entire memory map from from 0 through 0x5FFF. 

Ok, good news.  Let me know if I can provide any information.  I’ll probably be ready to make an initial release of the base firmware and General I/O ROM disassembly outputs in a few days.

Looking at the code that is run for a ‘ldb’ (load binary from tape), there does not appear to be a check to see if a binary program would be large enough to overlap with any of the ROM address space, which would prevent a 9825T from executing it properly.  Binary programs are loaded so they end at 076547 in RAM.  Presumably HP assumed that since only they would be providing binary programs, they would know not to make them too large to cause conflicts with the address bit map on the A25 board.


Re: 9825 restoration notes and questions

Paul Berger
 



On 2017-02-03 4:41 PM, Craig Ruff wrote:

On Feb 3, 2017, at 1:34 PM, Paul Berger <phb.hfx@...> wrote:

Now that I think of it, it would be possible to verify the operation of the whole state machine on the A25 card using sometime to provide the appropriate input signals to the card since it is all static logic.

A big effort, as you would need to simulate instruction fetches at specific addresses  (including the instruction words for the state machine to decode the instruction type) along with the corresponding operand fetch(s).  Not impossible, but similar to just running the system.
I don't think it is that big a deal I am half way there already with the rig I used to dump the ROMs.  The service manual talks about the signals the state machine monitors and what they mean.  the ROM feeds 6 bits into a an 8-1 multiplexer that select a bit based on the state of  A12, A13, and A14, in other word the 4K ROM provided a bit map of the the entire memory map from from 0 through 0x5FFF. 

I can probably easily modify my disassembler to be able to identify the addresses of instructions that access RAM, which could then be used as a source of input data for such a stand alone verify operation.
Well in a T there is RAM from 0x400 to 0x7FFF, and ROM from 0 to 0x5FFF.  There is a gap of 2K words 0x5400 that does not seem to be used at this time however -CartOE is dropped for that address so there is potential for ROM to occupy that space.  There are also 1K word gaps at 0x3000 (Mass storage),  0x3C00 (Matrix) and 0x5C00 that may be occupied by plugin ROMs, but since there does not appear to be any way for the state machine to know if there are ROMs in that space or not, I would guess the state machine assumes there is.

Paul.


Re: 9825 restoration notes and questions

 


On Feb 3, 2017, at 1:34 PM, Paul Berger <phb.hfx@...> wrote:

Now that I think of it, it would be possible to verify the operation of the whole state machine on the A25 card using sometime to provide the appropriate input signals to the card since it is all static logic.

A big effort, as you would need to simulate instruction fetches at specific addresses  (including the instruction words for the state machine to decode the instruction type) along with the corresponding operand fetch(s).  Not impossible, but similar to just running the system.

I can probably easily modify my disassembler to be able to identify the addresses of instructions that access RAM, which could then be used as a source of input data for such a stand alone verify operation.


Re: 9825 restoration notes and questions

Paul Berger
 

Now that I think of it, it would be possible to verify the operation of the whole state machine on the A25 card using sometime to provide the appropriate input signals to the card since it is all static logic.

Paul.


Re: 9825 restoration notes and questions

Paul Berger
 

I just too a look at the schematic sheets for for the A24 and A25 cards with my scribbled notes.  The two cards are largely independent of each other, with only two signal from the A25 board that affect the A24 board.  Since you now say that the machine operates correctly without the A25 card, that would suggest that would verify function of 99% of the A24 board.  The two signals produced by the A25 board are OptMap and ROMSel.  The OptMap signal is pulled to ground by the A25 board this is inverted and is one input to a NAND gate (U49d) and the output is the C2 input top U48. When the A25 card is not installed the line is pulled high which in effect disables the system programming ROM and also turns off -CartOE for addresses 0x5400, 0x5800, and 0x5C00.  When the A25 card is present and ROMSel is active (high) the system programming ROM is active  at address 0x5000 and -CartOE will be active for addresses 0x5400, 0x5800 and 0x5C00.  Ox5C00 is where the second window to the 98228A ROM exists, the other two addresses appear to be unused.

ROMSel is an output from the state machine that inhibits the RAM and enables ROM.  The RAM on the A24 board is in the upper half of the memory maps, and the RAM on the A25 board is mapped into the lower half of the map, but has the first 2K disabled for space occupied by CPU registers, BasePage ROM and Compiler ROM. The 98228A also uses the area occupied by the BasePage ROM and Compiler ROM Tables for its bank selection mechanism since it is always occupied by ROM, and write to that space have no effect on the ROM.  The two cards independently determine when their RAM should be enabled.

Since the U29 ROM is connected to the demultiplexed  address bus, the contents could be dumped without removing the card you would just need to simulate enough of the bus to generate the addresses and the ALE signal to latch the address and the output of U29 could be captured using something like a logic analyzer.  

Always keep in mind that the MAD bus is NEGATIVE logic if you don't and you are trying to figure out the logic of anything connected to it you will quickly go down the garden path.


Paul.


On 2017-01-31 1:59 PM, Jack Rubin wrote:

Interesting - not much time to play around this morning before leaving for a few days, but I did find that with A25 in place and 64K selected, the system would note the presence/absence of the tape drive (i.e. error 43) if the Monitor Bus cable was _removed_. If the cable was in place, no error was reported whether the  tape drive was connected or not. Clearly _something_ is happening on A25 and the Monitor Bus cable is providing some signals. 

More tantalizing than conclusive. When I return home later in the week, I'll go ahead with a full physical tear-down and inspection of the other end of the Monitor Bus cable. 

More to come ...

_._,_._,_



8301 - 8320 of 8390