Project Questions about 4952oss HOT 12 OPEN

from 4952oss.

from 4952oss.

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.

from 4952oss.

from 4952oss.

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.

from 4952oss.

from 4952oss.

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.

from 4952oss.

from 4952oss.

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

from 4952oss.

from 4952oss.

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?

from 4952oss.

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.

from 4952oss.