Project Questions

[iceblu3710]

I have an HP 4952A as well and want to start playing with its brains but I have a few questions.

How are you getting your custom code onto the machine? I do not have a floppy drive so I am not sure what I will need for a mondern computer. USB FDD, FDD Emulator? LIF_Utils says the disks are:

lifversion: 010708
Volume : HP4952 
Tracks: 77 Surfaces: 2 Blocks per Track: 16 Total size: 2464 Blocks, 630784 Bytes
Directory start : 2 (0/0/3) end : 11 (0/0/12)
User data start : 12 (0/0/13) end : 448 (14/0/1)
EXTD_ASYNC  ?(C403)     22784/22784                     
COPYDISC    ?(C403)     12544/12544                     
DEMO_DATA   ?(C402)     41216/41216                     
TERM        ?(C403)     22784/22784                     
IPARS_MEC   ?(C403)     12544/12544                     
5 files (80 max), last block used: 448 of 2464

I have been able to pull off programs and open them in ghex. I see the structure your /lib/header.asm and similar files are refering too. I assume you destructed these programs to figure out the required file structure. I do not see anything on the hackaday.io page on how you actually achieved figuring this out. I assume dumping the ROM's and looking at all OUT commands then manually poking them?

I decided the easiest way to find the keyboard I/O was to do a read scan of all the I/O addresses I found the HP firmware to be reading... This did the trick!

At this point I have deciphered the menu data formats, the runtime linker used in HP's applications, and how to do some basic text output.

Have you figured out which of the 5 processors is ACUTALLY the main CPU? On my hackaday page I have identifed as many systems and groupings of chips as I could on a busy weekend but I literally pulled both main board z80's, the 8051 and 68008 on the memory board and had the disk board removed so no 8088. I pulled EVERY ROM except system ROM_1 and I could still use the UI and run the self tests. This means the main prcessor is still magically in there. I summerised it had to be in that custom chip on the memory board.

Anyways, If you have some time can you summerise HOW you got to where you are and I will hopefully be able to help out! My neck of the woods as no computer clubs so it's slow going alone.

[dkgrizzly]

Yep, I’ve not gone to pulling chips, or found any code I can identify as 68008 yet. Z80 is definitely where apps are run. For getting stuff on and off the units, the easiest way is with 5xremote.exe running in dosbox. there are several disk images on the hp computer museum website for the 4951/4952/4957. the dos software disks among them. dosbox needs a com port set to directserial mode and a real port assigned.

Sent from my iPhone

On Jan 2, 2019, at 9:36 PM, iceblu3710 notifications@github.com wrote:

I have an HP 4952A as well and want to start playing with its brains but I have a few questions.

How are you getting your custom code onto the machine? I do not have a floppy drive so I am not sure what I will need for a mondern computer. USB FDD, FDD Emulator? LIF_Utils says the disks are:

lifversion: 010708 Volume : HP4952 Tracks: 77 Surfaces: 2 Blocks per Track: 16 Total size: 2464 Blocks, 630784 Bytes Directory start : 2 (0/0/3) end : 11 (0/0/12) User data start : 12 (0/0/13) end : 448 (14/0/1) EXTD_ASYNC ?(C403) 22784/22784
COPYDISC ?(C403) 12544/12544
DEMO_DATA ?(C402) 41216/41216
TERM ?(C403) 22784/22784
IPARS_MEC ?(C403) 12544/12544
5 files (80 max), last block used: 448 of 2464 I have been able to pull off programs and open them in ghex. I see the structure your /lib/header.asm and similar files are refering too. I assume you destructed these programs to figure out the required file structure. I do not see anything on the hackaday.io page on how you actually achieved figuring this out. I assume dumping the ROM's and looking at all OUT commands then manually poking them?

I decided the easiest way to find the keyboard I/O was to do a read scan of all the I/O addresses I found the HP firmware to be reading... This did the trick!

At this point I have deciphered the menu data formats, the runtime linker used in HP's applications, and how to do some basic text output.

Have you figured out which of the 5 processors is ACUTALLY the main CPU? On my hackaday page I have identifed as many systems and groupings of chips as I could on a busy weekend but I literally pulled both main board z80's, the 8051 and 68008 on the memory board and had the disk board removed so no 8088. I pulled EVERY ROM except system ROM_1 and I could still use the UI and run the self tests. This means the main prcessor is still magically in there. I summerised it had to be in that custom chip on the memory board.

Anyways, If you have some time can you summerise HOW you got to where you are and I will hopefully be able to help out! My neck of the woods as no computer clubs so it's slow going alone.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dkgrizzly]

One more thing, the Z80 chips you see on the base board are the serial chips for the pod interface, there is a national semiconductor chip that contains an embedded Z80 with multiplexed bus, and some peripherals.

Sent from my iPhone

On Jan 2, 2019, at 9:36 PM, iceblu3710 notifications@github.com wrote:

I have an HP 4952A as well and want to start playing with its brains but I have a few questions.

How are you getting your custom code onto the machine? I do not have a floppy drive so I am not sure what I will need for a mondern computer. USB FDD, FDD Emulator? LIF_Utils says the disks are:

lifversion: 010708 Volume : HP4952 Tracks: 77 Surfaces: 2 Blocks per Track: 16 Total size: 2464 Blocks, 630784 Bytes Directory start : 2 (0/0/3) end : 11 (0/0/12) User data start : 12 (0/0/13) end : 448 (14/0/1) EXTD_ASYNC ?(C403) 22784/22784
COPYDISC ?(C403) 12544/12544
DEMO_DATA ?(C402) 41216/41216
TERM ?(C403) 22784/22784
IPARS_MEC ?(C403) 12544/12544
5 files (80 max), last block used: 448 of 2464 I have been able to pull off programs and open them in ghex. I see the structure your /lib/header.asm and similar files are refering too. I assume you destructed these programs to figure out the required file structure. I do not see anything on the hackaday.io page on how you actually achieved figuring this out. I assume dumping the ROM's and looking at all OUT commands then manually poking them?

I decided the easiest way to find the keyboard I/O was to do a read scan of all the I/O addresses I found the HP firmware to be reading... This did the trick!

At this point I have deciphered the menu data formats, the runtime linker used in HP's applications, and how to do some basic text output.

Have you figured out which of the 5 processors is ACUTALLY the main CPU? On my hackaday page I have identifed as many systems and groupings of chips as I could on a busy weekend but I literally pulled both main board z80's, the 8051 and 68008 on the memory board and had the disk board removed so no 8088. I pulled EVERY ROM except system ROM_1 and I could still use the UI and run the self tests. This means the main prcessor is still magically in there. I summerised it had to be in that custom chip on the memory board.

Anyways, If you have some time can you summerise HOW you got to where you are and I will hopefully be able to help out! My neck of the woods as no computer clubs so it's slow going alone.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[iceblu3710]

I figured the z80 on the main board was for pod serilization. Why does one have dedicated memory and one not, and why are there two I think is a question for the HP wizards of the 80's.

So the custom looking National chip is indeed a NS800. It was weird to have a huge GAL so I assumed bus arbiter which is still technically correct if the NS800 is anything like the SC/MP which is designed for multiple processors on the same bus.

I assume the "Remote/Printer" dsub on the back is actually a HPIB interface and that is how you are getting a serial connection? I presume you had to load a link program on the 4952 or is the rx commands built right into the system?

I don't have a floppy, real serial, or HPIB cable so when I figure out what I need I can move forward. I may try and dump all the system ROM chips this weekend.

[dkgrizzly]

So the remote / printer is RS232 DTE, so you need a null-modem to connect it to a computer. The remote board is semi autonomous, it can do some operations no matter where in the menus you are, others require being at the home screen, and some - like “Delete Application” will kick you out to the main menu even from running apps (unless they disable interrupts).

The HP DOS software also includes some utilities for using a real floppy drive in real dos (not dosbox or command prompt) to read/write HP LIF formatted disks.

If you are truly interested in running CP/M on these, I would recommend looking at CP/M for the HP 125, it may be a rabbit hole, but in some ways relevant as they used HP LIF formatted floppies in HPIB interfaced boxes (so autonomous, and somewhat related to how the disk system on the 495x works). I had that in my plans as well, but getting some simple stuff working first was my priority.

I’ve not yet figured out how to swap VRAM pages or disable the VRAM window yet, the later being somewhat important for CP/M to work correctly. I imagine something like RomWBW’s HBIOS setup would make sense. Most of the drivers are hidden in a banked rom page, with small stubs in the top and bottom of user ram pages.

In the Basic-80 port I’m abusing the ramdisk, stealing a page from it for the basic environment. This has the benefit of making it easy to backup and restore with the disk copy program from HP. Eventually I’ll figure out how to properly allocate a block of it so nothing tramples the basic environment. Something similar could make sense for CP/M. You get the benefit of a battery backed environment which can be booted into quickly at power-up.

I should also note that the later 4957 ROMs include an 80x24 version of the VT100 emulator, I’m going to be dumping that and try to export it as a .app to see if it will work on the 4952, if it is just reprogramming the crtc, or if they added an expanded clock generator for the video pixel clock.

Sent from my iPhone

On Jan 3, 2019, at 7:21 AM, iceblu3710 notifications@github.com wrote:

I figured the z80 on the main board was for pod serilization. Why does one have dedicated memory and one not, and why are there two I think is a question for the HP wizards of the 80's.

So the custom looking National chip is indeed a NS800. It was weird to have a huge GAL so I assumed bus arbiter which is still technically correct if the NS800 is anything like the SC/MP which is designed for multiple processors on the same bus.

I assume the "Remote/Printer" dsub on the back is actually a HPIB interface and that is how you are getting a serial connection? I presume you had to load a link program on the 4952 or is the rx commands built right into the system?

I don't have a floppy, real serial, or HPIB cable so when I figure out what I need I can move forward. I may try and dump all the system ROM chips this weekend.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iceblu3710]

I have dumps of all the roms in the device but I have never done disassembly without my own source to accompany it. It is no simple job making sense of all that. Need to figure out how to pass a block def file so I can turn the obviously ascii data into the proper entry types. All it takes is one odd character and the rest of the disassembly turns to garbage...

As for the CRT it has some interesting possibilities. The CRTC is a FUJITSU MB89321BP. I can not find any details on it besides one page that says its a drop-in replacement for the Motorola 6835. That chip, however, is well documented and descriptions line up. It is a fully programmable video timing chip and you should be able to increase the resolution easily with the downside of losing double buffering due to memory size. The 4951C schematics have a 16k dual port RAM listed and describes it as able to hold two screens to eliminate screen artifacts.

I am getting a 3D printed 40pin wide dip clip so I can throw my logic analiser on it during bootup. From there I will know exactly what the setup is and can poke in a new configuration from my new EEPROM.

A few more questions:

• Do you have a "basic app framework". A simple template that when loaded jumps to a certian spot in the file but there are still the soft key breakouts (they trigger the KBD/Remote Intterut ~RSTB) for easy app exit? It would be nice if I can just focus on the hardware by doing a hex patch with test code into a template app.

• Do you know the Remote/Printer pinout? The 4951C does not have it in the schematics as far as I can see.

[dkgrizzly]

Yep. In my GitHub repo there are a few very small examples that have an exit function.

The remote/printer is bog standard RS232C 25 pin serial port, wired as DTE (same as a terminal or PC) so needs a nullmodem cable to connect to a PC.

Sent from my iPhone

On Jan 6, 2019, at 3:17 PM, iceblu3710 notifications@github.com wrote:

I have dumps of all the roms in the device but I have never done disassembly without my own source to accompany it. It is no simple job making sense of all that. Need to figure out how to pass a block def file so I can turn the obviously ascii data into the proper entry types. All it takes is one odd character and the rest of the disassembly turns to garbage...

As for the CRT it has some interesting possibilities. The CRTC is a FUJITSU MB89321BP. I can not find any details on it besides one page that says its a drop-in replacement for the Motorola 6835. That chip, however, is well documented and descriptions line up. It is a fully programmable video timing chip and you should be able to increase the resolution easily with the downside of losing double buffering due to memory size. The 4951C schematics have a 16k dual port RAM listed and describes it as able to hold two screens to eliminate screen artifacts.

I am getting a 3D printed 40pin wide dip clip so I can throw my logic analiser on it during bootup. From there I will know exactly what the setup is and can poke in a new configuration from my new EEPROM.

A few more questions:

Do you have a "basic app framework". A simple template that when loaded jumps to a certian spot in the file but there are still the soft key breakouts (they trigger the KBD/Remote Intterut ~RSTB) for easy app exit? It would be nice if I can just focus on the hardware by doing a hex patch with test code into a template app.

Do you know the Remote/Printer pinout? The 4951C does not have it in the schematics as far as I can see.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iceblu3710]

Well, I made some interesting progress. I learned that its a lot harder to think in asm as you always want to 2 or 3 step things and realize you need to do a lot of shuffling sometimes. I did have my logic analyzer hooked up as I probed around and found to CRTC addresses.

_crtc_wr: equ 0a0h
_crtc_wd: equ 0a1h
_crtc_rr: equ 0a2h
_crtc_rd: equ 0a3h

I modified you'r port test program to list all 10 registers of the CRTC and let me inc/dec via the keyboard. I was able to eek out a 35 x 32 char screen but the 28hz refresh is pretty annoying and the screen's ram starts to roll over after 32 x 32. No not exactly the most useful finding but does answer the question of if it is possible. I'm going to guess the 4957A has a much larger ram chip and very likely twice the dot clock if not a selectable source if there is a VT100 program that does resize the screen nicely.

[dkgrizzly]

Turns out the 57 has a more integrated chipset with lots of programmable logic from xilinx. I’d love to know if you happen to figure out how to disable the VRAM window, as that would be kind of important for getting a large TPA in CPM.

Sent from my iPhone

On Jan 26, 2019, at 8:51 PM, iceblu3710 notifications@github.com wrote:

Well, I made some interesting progress. I learned that its a lot harder to think in asm as you always want to 2 or 3 step things and realize you need to do a lot of shuffling sometimes. I did have my logic analyzer hooked up as I probed around and found to CRTC addresses.

_crtc_wr: equ 0a0h _crtc_wd: equ 0a1h _crtc_rr: equ 0a2h _crtc_rd: equ 0a3h I modified you'r port test program to list all 10 registers of the CRTC and let me inc/dec via the keyboard. I was able to eek out a 35 x 32 char screen but the 28hz refresh is pretty annoying and the screen's ram starts to roll over after 32 x 32. No not exactly the most useful finding but does answer the question of if it is possible. I'm going to guess the 4957A has a much larger ram chip and very likely twice the dot clock if not a selectable source if there is a VT100 program that does resize the screen nicely.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iceblu3710]

What do you know about the MMU so far?

I watched the first 8 seconds of boot on the logic analyzer and it is clear that out 0x20, NN is the MMU. It looks like something more than simple logic as there is a few cycle "lag" before the new memory selection takes effect. There is a write to 0x20 immedeatly before and after every RAM/ROM chip enable switches (except a few cases). There is some wierd overlaying going on here as well becuase all three ROM's are 512k and all tree RAM's are 256k. Also decoding the first handful of instructions via the analyzer the stack is set up at 0x4800 (ld sp,0x4800 is the 4th instruction actually) which is not on a 32k boundry so they are not simpily switching on a ram over the top or bottom of the rom.

Below is the chip enables and the immediate IO writes before and after. In all cases only one CE is ever selected but in a few modes like out 0x20, 0x03 somehow both RAM & ROM are enabled and the RD/WR is all the selects which one to use. There are a TON of GAL/PAL and a programmable interrupt controller I have no documentation on so a complex MMU wouldn't be out of the question.

Cold Boot
ROM_SYS_1 CE
out 0x20, 0x01
SRAM_SYS_3 CE
out 0x20, 0x11
ROM_SYS_1 CE
out 0x20, 0x01
SRAM_SYS_3 CE
out 0x20, 0x03
ROM_SYS_1 CE & SRAM_SYS_3 CE Somehow
out 0x20, 0x00
SRAM_SYS_1 CE
out 0x20, 0x02
ROM_SYS_2 CE
out 0x20, 0x01
ROM_SYS_1 CE
out 0x20, 0x03
ROM_SYS_1 CE & SRAM_SYS_3 CE Somehow
out 0x20, 0x04
SRAM_SYS_3 CE

Fully Booted (~2850ms)

Main loop every 14ms
keyscan every 88us
out 0xd0, 0x80/40/20/10/8/4/2/1/0

[dkgrizzly]

I suspect 0x03 would be for rom shadow copy. There is a table that remaps some of the window values for the rom routines, $0E60/$0E90 comes to mind but I can’t check right now. I’ll have to dig out the probes for my logic analyzer and try to make sense of some of this from my end too.

On Jan 28, 2019, at 10:35 PM, iceblu3710 notifications@github.com wrote:

What do you know about the MMU so far?

I watched the first 8 seconds of boot on the logic analyzer and it is clear that out 0x20, NN is the MMU. It looks like something more than simple logic as there is a few cycle "lag" before the new memory selection takes effect. There is a write to 0x20 immedeatly before and after every RAM/ROM chip enable switches (except a few cases). There is some wierd overlaying going on here as well becuase all three ROM's are 512k and all tree RAM's are 256k. Also decoding the first handful of instructions via the analyzer the stack is set up at 0x4800 (ld sp,0x4800 is the 4th instruction actually) which is not on a 32k boundry so they are not simpily switching on a ram over the top or bottom of the rom.

Below is the chip enables and the immediate IO writes before and after. In all cases only one CE is ever selected but in a few modes like out 0x20, 0x03 somehow both RAM & ROM are enabled and the RD/WR is all the selects which one to use. There are a TON of GAL/PAL and a programmable interrupt controller I have no documentation on so a complex MMU wouldn't be out of the question.

Cold Boot ROM_SYS_1 CE out 0x20, 0x01 SRAM_SYS_3 CE out 0x20, 0x11 ROM_SYS_1 CE out 0x20, 0x01 SRAM_SYS_3 CE out 0x20, 0x03 ROM_SYS_1 CE & SRAM_SYS_3 CE Somehow out 0x20, 0x00 SRAM_SYS_1 CE out 0x20, 0x02 ROM_SYS_2 CE out 0x20, 0x01 ROM_SYS_1 CE out 0x20, 0x03 ROM_SYS_1 CE & SRAM_SYS_3 CE Somehow out 0x20, 0x04 SRAM_SYS_3 CE

Fully Booted (~2850ms)

Main loop every 14ms keyscan every 88us out 0xd0, 0x80/40/20/10/8/4/2/1/0 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iceblu3710]

Well what I thought would be a somewhat easy project turned into a nightmare. I figured if I know the paging call I can simply page in, do some reads/writes and note what chip was selected with the logic analyzer, move onto the next page. I forget that on the asm level if I change a page the next instruction fetch may be somewhere strange. And that indeed is the problem.

I pulled the NS800 and wired in an Arduino Mega to try and simulate an out (0x20), _page then do a read/write loop shifting 0x1000 left to 0x8000 and note on the LA which chips where selected. I thought this would work as there is no "unlock" code and the first signs on life on the bus are ROM_1 0x0000 instructions. Unfortunately, timing is either so crutial the arduino can not do it, or the bus is not tristating properly due to lack of S0/S1 outputs for the missing CPU.

So, in the end, one long weekend of absolutely no results. Do you have any suggestions on how to figure out the ram mapping?

[okejokej]

Do you perhaps have an idea how the copy protection in 4951C might work? The headers seem to be virtually the same aside for compatibility flag, but setting the assumed copy protection flag to 0000 at the same location as in 4952 doesn't resolve it.