CP/M on HP-86B

[smp]

Hello all,

As you may have seen from my various posts elsewhere in the VC Forum, I am having an adventure with my new-to-me HP-86B.

I currently have the following equipment working:

• HP-86B
• HP-9121D dual 3.5 inch floppy drive (single sided, 270K capacity disks)
• Dynex 17" LCD TV / video monitor with underscan capability on the VGA input
• VideoSecu TV Video RCA to PC VGA Converter Adapter Switch Box
• HP-82900A Auxiliary Processor (AKA CP/M System module)

My goal was to ultimately get the HP-86B working with CP/M, and I have had CP/M up and running since Friday, June 15, 2012.

Recently, I have spent my time getting back familiar with CP/M version 2.2, using PIP, ED, ASM and DDT as well as a couple of the old CP/M primers that I have saved over the years.

Now that I have my appetite whetted again, I am looking to embark on getting some additional software running on my machine. I have come up with an interesting problem: How the heck can I get CP/M programs into this machine?

Let me explain: This machine is not your run-of-the-mill CP/M machine. The best metaphor might be an Apple IIe with a Z-80 processor card installed and running CP/M (I never had one of those, but the HP-86B is similarly set up).

The HP-86B has a custom HP processor inside along with 128K of memory for user programs. It normally boots up into its HP proprietary BASIC operating system, and it has the capability for folks to write their own programs, purchase programs for a variety of uses from HP, or utilize programs uploaded by users into HP's user library. In addition to other specialty modules produced by HP, HP also created a module originally named 82900A CP/M System, then later changed to 82900A Auxiliary Processor. Simply stated, this module is a Z-80 with 64K memory and an interface to the HP module bus in the back of the HP-86B. There is a special HP CP/M boot disk that contains 3 files: Autost, CP/M, and CP/MSYS.

Autost is a very small BASIC program that the HP-86B will read from the disk drive if it's available on power-up. It sets the screen size and sets the keyboard to be normally lower case, and then loads the binary called CP/M.

CP/M is the binary that stays resident in the HP-86B, loads the CP/M system into the Z-80 Auxiliary Processor, and performs the interface between the Z-80 and the console and disk interfaces in the HP-86B.

CP/MSYS is a large file on the disk that contains the CP/M file system and the basic files normally expected in a bare bones CP/M system.

I believe this is where my problem lies. If the HP-86B is operating normally as an HP-86B, the CAT command will display the directory of the disk as containing the 3 files I just described. When this disk is used to boot up and run CP/M, the DIR command in CP/M will show the normally expected files: PIP, DUMP, LOAD, DDT, ED, ASM, STAT, SUBMIT, XSUB and FORMAT.

When operating within CP/M, I can create my own programs. I have created my HELLO.ASM program in assembly language using ED, and I have assembled it using ASM. I have used LOAD to create a .COM file from the assembled code. On the disk I now see several additional files in CP/M: HELLO.ASM, HELLO.BAK, HELLO.PRN, HELLO.HEX, and HELLO.COM. Everything seems to be working fine.

Now for the Catch. If I boot up the HP-86B normally and use the HP CAT command again, I still get back the same original 3 files: Autost, CP/M, and CP/MSYS. All my HELLO.* files are buried within the CP/MSYS file.

So, I am looking for a way to get a large source file into CP/M on this system. Time to check out the manuals.

The Introduction to the HP 82900A CP/M System clearly states the operation I detailed above on how the Autost program is detected and then runs the CP/M binary, etc. It also states that when CP/M is running, "The HP 82900A CP/M System appears to standard CP/M software as a 61K CP/M system, version 2.2, with 56K bytes of user memory." Then it says, "Only application software that is HP disc-formatted is compatible with your system." (That sounds pretty ominous to me. )

The HP 82900A CP/M System Reference Manual describes the use of PIP, and states that CON: and RDR: are source devices that can be re-mapped to other devices such as TTY:, CRT:, BAT:, PTR:, etc., but then also states that, "All physical input devices use keyboard input." (Things are not getting any better )

Similarly, the CP/M Reference Manual states that CON:, PUN:, and LST: are destination devices, and they also can be re-mapped to a variety of devices. Except for mapping CON: to CRT: or BAT:, and mapping LST: to LPT: or CRT:, it also states that, except when using only those mappings, "Output data is lost." (Oh, my! )

So, there's my situation. I have the source listing for FIG-Forth, and I was hoping to find a way to get the text file onto a disk and then be able to see it in CP/M on the HP-86B, but I have no idea how I could get the text file into the CP/MSYS file properly for the CP/M file system. As well, it does not appear to me that I have the ability to re-map some input to a serial port (I have the HP-82939A Serial I/O module) where I could create a program to read the text file in under CP/M.

Am I doomed to typing this entire source file in by hand? Am I doomed to typing any source text file that I want in by hand?

Any and all comments, observation, or advice are welcome.

Thanks for listening!

smp

 

[natcha]

You may find some help from the people in the following thread from the HPmuseum.org site:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv013.cgi?read=40122

Although the site is mostly about HP Calculators, a lot of the members also have older HP computer equipment and may be able to help you out.

Bill

 

[smp]

You may find some help from the people in the following thread from the HPmuseum.org site:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv013.cgi?read=40122

Although the site is mostly about HP Calculators, a lot of the members also have older HP computer equipment and may be able to help you out.

Bill

Ha! Thanks, Bill. I was actually just looking at that exact thread. Unfortunately, that thread is only about getting boot disks to work.

However, I will also post my question over there on that Forum, in case anyone there has some advice.

Thanks very much!

smp

 

[leeb]

Apparently the HP is using the CP/MSYS file as an IMG file, such as linux does, allowing a file to be attached as a device and accessed as a drive.
IF the FORMAT of the 'image' were known (or decipherable) then it would likely be possible to take that 'file' and insert/delete other files through another system/emulator/program.

What about the 2nd disk... is that completely 'free' or does it contain needed files on it? Does it have an 'image' file too?

It really SUX that you apparently do not have access to the serial port(s)... you could Kermit everything over that way...

Tho I have lots of 'irons in the fire', I would be interested/willing to help in this.. PM if you like.

EDIT:
Im wondering if it would be possible to write a dedicated serial-IO program to access the ports DIRECTLY...
Supposedly you have LST: , that suggests that MECHANICAL access to hardware exists... possibly.
It would be necessary to 'insert' the source file into the 'image' and then compile it with whichever language you have available...
Which might be ?
Of course, if the 'image access' were possible, then the completed COM file could be 'inserted' and runnable from that point.

Just some more musings.

 

[smp]

Hi there, Leeb,

Thanks very much for your thoughts and encouragement.

One of the things that I left out of my original essay is that I/O in the HP-86B (and the entire HP Series 80 line) is by HP-IB, or by a special module that plugs onto the HP bus, like the Auxiliary Processor itself. Yes, the serial I/O module plugs onto that bus, but, so far at least, I have not found lower level design information for the bus or the module. That does not mean that it doesn't exist, it only means that I have not come across it. The normal HP-86B BASIC operating system has an unusual way of doing I/O, using device numbers. I have seen things associated with the Serial I/O module that call it device 10 (this is on the HP module bus). The printer seems to be device 7, on the HP-IB. The disk drives are usually device D7, on the HP-IB.

I made the point of the binary file CP/M that stays resident, performing the connection between the auxiliary Processor and the HP-86B keyboard and display, as well as the disk drives and the printer that are on the HP-IB. I have seen no documentation on how to get to any other devices, although HP does make a few allusions to perhaps making additional devices available "in the future." I do not think that ever occurred.

My perception at this point is that the CP/M binary, resident in the HP-86B, knows how to access the disk drives via the HP-IB (no big surprise), decode things from and encode things to the CP/MSYS file, and presents information back to CP/M running on the Auxiliary Processor as if it were a normal CP/M disk drive interface.

In short, I think this is a closed system. I do not have any experience about how the Apple systems with Z-80 cards or Commodore systems with their auxiliary processors operated, but I believe this is the way HP made CP/M available while still keeping things proprietary, rather that going open and allowing anyone to get software from anywhere.

This is starting to feel like a very early version of controlling the user experience, way, way before Steve Jobs initiated it within Apple.

Thanks again for your thoughts. If you have anything more, keep it coming.

I don't know, but if schematics are available for the HP module bus and for the serial I/O module, maybe there could be some custom code developed? That sounds pretty daunting to me.

smp

 

[smp]

Here's an update:

Based on the ideas presented by Leeb, I went over to the HP Computer Museum site (http://hpmuseum.net/) and took a look at available documentation for the HP-82939A Serial I/O Module. I found the 82939A Serial Interface Installation and Theory of Operation Manual (http://www.hpmuseum.net/capcha/freecap_wrap.php?r=1991).

Unfortunately, the module is designed around an 8048 programmable controller. The module is designed to receive commands from a BASIC program running in the HP-86B. There is a schematic, but I have not scoured it thoroughly at this point. I figure that some sort of higher level command comes from the BASIC program to the 8048 processor, and then things will be sufficiently hidden that we may be able to go no further. I don't know that we will be able to create a program in the Z-80 processor running CP/M that can reach across the HP-86B module bus, through the HP-86B, and back out the HP-86B module bus to get to this module without a pile of additional information.

Thanks for listening.

smp

 

[smp]

What about the 2nd disk... is that completely 'free' or does it contain needed files on it? Does it have an 'image' file too?

Hello again, Leeb,

Sorry that I missed answering this question before...

When operating in CP/M, I formatted a disk in drive B as a simple CP/M data disk. Then I copied only my HELLO.* files onto it. Before copying the files, the DIR command in CP/M returned the message: NO FILE. After copying the files onto the disk, the DIR command showed the several HELLO.* files.

I then reset the HP-86B back into the normal BASIC operating system. At that point, when I perform the CAT command, I see one file: CP/MSYS.

This supports my assumption in a previous post that the CP/M binary program resident in the HP-86B knows how to decode this file and how to encode additional things into this file, and presents information to CP/M running on the Auxiliary Processor as if it was a disk drive interface.

Thanks for asking.

smp

 

[gslick]

Apparently the HP is using the CP/MSYS file as an IMG file, such as linux does, allowing a file to be attached as a device and accessed as a drive.
IF the FORMAT of the 'image' were known (or decipherable) then it would likely be possible to take that 'file' and insert/delete other files through another system/emulator/program.

That should be possible.

See the HP 82900A CP/M System Reference Manual, pages A-2 and A-3.
http://www.series80.org/PDFs/HP82900A-CPM-Ref.pdf

If I get an HPDrive emulator system setup it should be possible to format an emulated disk images as a CP/M disk, and then from that disk image extract the disk sectors containing the CP/M disk image, then use CP/M disk utilities to update files on that CP/M disk image, then insert that disk image back into the HPDrive disk image and access it from the HP 86B CP/M system again.

-Glen

 

[leeb]

Hello again, Leeb,

Sorry that I missed answering this question before...

When operating in CP/M, I formatted a disk in drive B as a simple CP/M data disk. Then I copied only my HELLO.* files onto it. Before copying the files, the DIR command in CP/M returned the message: NO FILE. After copying the files onto the disk, the DIR command showed the several HELLO.* files.

I then reset the HP-86B back into the normal BASIC operating system. At that point, when I perform the CAT command, I see one file: CP/MSYS.

This supports my assumption in a previous post that the CP/M binary program resident in the HP-86B knows how to decode this file and how to encode additional things into this file, and presents information to CP/M running on the Auxiliary Processor as if it was a disk drive interface.

Thanks for asking.

smp

Everything in your previous post tells me that there IS a way to handle this...
If the SYSTEM is able to access 'device 07' then there SHOULD be a way for us to do the same thing...
When you send a write to LST: (since the only read is for status), it goes thru the BDOS entry (0005h) to a table of subroutine addresses in the BIOS that handle all the 'non-existent' device functions... (cldboot,wmboot,constat,conin,conout,lstout--all I can remember right now) and eventually acesses that 'cp/m interface' with the 'right stuff'...
It should only be a question of finding that 'right stuff' and where to send it...
EDIT:
Do you have access to DDT? You can use it to see where things 'go'...
:D
EDIT2:
Okay... having thought about it... it is POSSIBLE that the CPM 'resident interface' does not have the capability of working with anything but the printer. But I have difficulty believing that they enabled access to the printer device w/o being able to get to the others. I CAN see that the z80-based BIOS might have been 'shorted' them IOT reduce its footprint, altho they would have 'blank' entries in the table to keep things kosher...

Can you get me a copy of that CP/MSYS file?
Or, is there such a file somewhere that I could download and 'play with'?

 

[smp]

Can you get me a copy of that CP/MSYS file?
Or, is there such a file somewhere that I could download and 'play with'?

If you send me a PM with your mailing address, I will send you the disk.

Thanks,
smp

 

[leeb]

The PDF file above only references 5.25 (and 8") disks...
what does 'STAT DSK:' show you?

EDIT:
Something else that might be interesting... an entry in the 'boot thread' referred to:

BTW, if you happen to have the software for the HP 82900A terminal emulation co-processor, then this should be usable with the CP/M module, since the actual hardware card is the same for both systems. Unfortunately, I do not have this S/W.

:D

 

[gslick]

The PDF file above only references 5.25 (and 8") disks...
what does 'STAT DSK:' show you?

I assume the 9121 3.5-inch floppy has the same logical format as the 5.25-inch floppy. Physically the 5.25-inch floppy has 2 sides and 33 tracks with 16 sectors of 256 bytes and 270,336 bytes total, while the 9121 3.5-inch floppy has 1 side and 66 tracks with the same 16 sectors of 256 bytes and the same 270,336 bytes total.

If I dump the raw sectors of the floppy I can see the ASCII text of the DUMP.ASM file, but I can't find anything that I can recognize as a CP/M directory structure.

-Glen

 

[leeb]

I assume the 9121 3.5-inch floppy has the same logical format as the 5.25-inch floppy. Physically the 5.25-inch floppy has 2 sides and 33 tracks with 16 sectors of 256 bytes and 270,336 bytes total, while the 9121 3.5-inch floppy has 1 side and 66 tracks with the same 16 sectors of 256 bytes and the same 270,336 bytes total.

If I dump the raw sectors of the floppy I can see the ASCII text of the DUMP.ASM file, but I can't find anything that I can recognize as a CP/M directory structure.

-Glen

What you would want to focus on is tracks 3 to 63, all sectors (0-15).
Track 3 is the CP/M directory.
Tracks 4-63 are the file space (according to the 5.25 format), while the last 2 tracks contain the BASIC file and the CP/M 'binary'...

This is according to the PDF I downloaded from the link above...

EDIT:
The directory will look fairly symmetrical with the filenames followed by the extent values...
:D

 

[leeb]

Some (hopefully) exciting news!

Some (hopefully) exciting news!

I have a program called

22disk

that is able to read/write multiple formats... and I was able to configure it to read/write the 3.5 HP...

But that's not the best part! When I did a CP/M directory, I was VERY SURPRISED to see the CONTENTS OF THE CPM 'directory'!!

I expected it to show me the 'base' HP area with CP/MSYS... but no!
DIRECT into the CP/M 'file'!

I am returning the DATA disk you sent me, with a couple of my own placed on it... you will need to see if there is any 'head alignment/erase' issue(s) between your original SS/DD drives and the DS/HD one I wrote with.

I am also sending another floppy with DOS 6.22 and the 22disk program, properly configured, etc. for you to try. (see cpmx.bat in / )

If you can get your files onto a PC this should just about cover the issue, short of actually getting the serial I/O working...

It'll be a day or 2 before I get the mail out, but it is 'on its way'!

Sorry for the blurry pics, but you will see what I mean!
EDIT: I intend to work on getting my Model 4p emulator (thus my 4p) to be able to open these disks as well.. yet another 'avenue' into storage-land!

 

[smp]

Hi Lee (and Glen),

I am at work right now, so I cannot answer the question about what STAT DSK: will report in CP/M. I'll try that tonight or tomorrow and report back to you.

As far as the HP terminal emulation software is concerned, please remember that it is also initiated from the HP BASIC operating system, so it will also have no knowledge about the CP/M OS or file system. If the terminal emulation software is actually another separate system, being a terminal emulator, it may not have any file transfer or storage capability at all (I have never looked into it).

It really looks to me like HP did all they could to provide their customers the ability to use CP/M, but keep them in a "walled garden," to use a term we hear often today. The business of only being able to use "HP disc-formatted software" would keep customers coming back to HP, rather than being able to tap into the vast array of software that was blooming at the time.

I am now wondering if the actual schematic is available for the HP-82900A Auxiliary Processor module, could a serial I/O port be patched in, and then an assembly program could be written to use it to perform I/O with the outside world?

Thanks for listening...
smp

 

[smp]

Hi Lee,

Holy cow!

Apparently, while I was writing my previous reply, you were sending in that last message of yours. Thanks very much for this info. Very exciting, indeed. I will look for the disk that you will be sending, and I'll let you know what I find.

Just for the record, I am a Macintosh kind of guy... We have had only Macintosh computers in the house over the years, so my experience with PCs is pretty much limited to using them at work. Not a lot of rooting around in the inner hardware and software on my work computers, I'm afraid. I just picked up an older PC that is supposed to have Windows 98 on it, but I have yet to go out and get a keyboard and mouse for it, and fire it up. Hopefully, this will be the machine that I will bring up to do the things that you are describing to me here. For some reason, dealing with PCs is daunting to me. I'd much rather be skulking around inside an old S-100 machine or playing with this HP machine. But we'll see what comes about.

Thanks, once again, for all your attention and advice!
smp

 

[leeb]

For the record, 22disk will not work on XP or above - the NT subsystem prevents 'direct hardware control' as used by the program.
Which is why I built a bootable DOS 6.22 for you....

What you need is one of these....

That you can use to 'interbreed' to your heart's content!

But you cant have that one... not my 2810!!!
I actually used my 3800hd, which has the 22disk AND my 4p emulator on it.

I kinda guessed you were a MAC guy from the avatar...
Wont hold it against you!


Will try to get the envelope out today! :D

 

[smp]

OK, here's the result of the command STAT DSK: on my HP-86B with HP-9121D 3.5" disk unit, running CP/M:

A: Drive Characteristics
1952: 128 Byte Record Capacity
244: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
128: Checked Directory Entries
128: Records/ Extent
8: Records/ Block
32: Sectors/ Track
3: Reserved Tracks

If I do the STAT command on drive B: I get the same thing.

That doesn't seem to correlate with what Glen said earlier. 1952 128 byte records = 249,856 bytes, or 244 KBytes per disk. I suppose that's right when you are talking data only and not the directory stuff, too?

Anyway, that's what the system tells me.

smp

 

[smp]

Nice computer, by the way, Lee.

I had a Tandy 1400FD a long, long time ago, and it was a tremendously solid laptop computer. Not such a nice screen as you have there on the 2810. Recently, I have wondered if I had held onto it if it would have made a good terminal for my S-100 machine, or whether it would have been good for doing some of this disk investigation and copying business. Being a floppy only system, I would have been only running DOS, just like you say. Maybe I need to be on the lookout on eBay? The Sellers probably want a mint for those, though.

Sigh!

smp

 

[leeb]

OK, here's the result of the command STAT DSK: on my HP-86B with HP-9121D 3.5" disk unit, running CP/M:

A: Drive Characteristics
1952: 128 Byte Record Capacity
244: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
128: Checked Directory Entries
128: Records/ Extent
8: Records/ Block
32: Sectors/ Track
3: Reserved Tracks

If I do the STAT command on drive B: I get the same thing.

That doesn't seem to correlate with what Glen said earlier. 1952 128 byte records = 249,856 bytes, or 244 KBytes per disk. I suppose that's right when you are talking data only and not the directory stuff, too?

Anyway, that's what the system tells me.

smp

Dont forget... some of that TOTAL capacity is being used by the BASIC pgm and the CP/M 'interface' file...

Nice computer, by the way, Lee.

Awww, shucks... THAT old thing?? :D

I had a Tandy 1400FD a long, long time ago, and it was a tremendously solid laptop computer. Not such a nice screen as you have there on the 2810. Recently, I have wondered if I had held onto it if it would have made a good terminal for my S-100 machine, or whether it would have been good for doing some of this disk investigation and copying business. Being a floppy only system, I would have been only running DOS, just like you say. Maybe I need to be on the lookout on eBay? The Sellers probably want a mint for those, though.

Sigh!

smp

Well, as I said, I used the 3800hd to get the info I put up...
(And I have 'one or two' machines Id be willing to part with if interested. Just FYI... )
... and yes, Terminal (in windows 3.1 for example) would be an EXCELLENT interface for a terminal-based system. Have not used many dos-based terminal emulations but sure an acceptable one could be found...
Even something like Kermit would satisfy that requirement, and still provide the type of comms youre looking for.
Machines this old are usually limited to 19200 baud, but should be plenty for such an application.
EDIT:
Of course, being in the 'Apple world', you still have plenty of options there too... just would have to set your speed DOWN... and down....

BTW... disks went out TODAY before 1PM...
:D
(This is only the 3rd or so edit so far...)
If you have no trouble working with that data disk, I would be more-than-happy to send you a copy of Pascal MT+ that is the language I used to write my PROLOG-compatible z80 assembler. (.ASM sample on data disk)...
(The 22disk SHOULD be capable of creating a data disk... tho I havent tried it yet.)
... another FYI.