Is the CPU strictly an I/O machine or does it do any of the timing for the
counter?
If it's just I/O then indeed, replacing it would be a reasonable task.
-----Original Message-----
From: Poul-Henning Kamp
Sent: Sunday, February 20, 2011 3:21 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Rom Expansion for HP5370B
In message <AANLkTi=Z8oX4dQWY_nRQDcnkMDHZRRc3QhsaB0=7_...@mail.gmail.com>,
paul
swed writes:
Though only 8K of eprom I suspect its cleverly coded.
It's not really that bad. There has clearly been somebody there to pound
structure into the result, and there is very little evidence of
code-bumming.
So its quite speedy and does also have interrupt capability. At a cost of
$3-4 each its nothing to use several for different apps like the front
panel
display and keys, control for actual counting and finally a third for
ethernet or GPIB. (Maybe I will get to that one day)
Well, all the existing I/O shares the same 16A8D databus, and there
is hardly anything gained from having multiple processors fight for
that bus.
The I/O is also very much built to reduce CPU work, the display/leds
are self refreshing, the GPIB has its own ROM based state-machine etc.
But really the key to any of this would be the accurate decoding of the
existing software.
I have 303 bytes undecoded right now, 256 of these is a table which
I suspect is related to floating point squareroots, and a fair
number of the rest are padding. As I said it is quite structured.
It is a total no-brainer if you executed it by emulating a
M6800, and only intercepted a few places to add features.
Though HP service docs are somewhat useful in this approach for the 5370
vintage. At least you tend to be able to understand what IO does what.
The HP5370B is actually very good in that respect, I have been able to
figure out all the I/O that way.
For me since the 3 5370s are working, I won't be hacking them anytime soon.
Like'em the way they are.
Now, that's the other part: It is a very good instrument.
The only feature I have been able to dream up yet is a digital
clock, and only because that is sort of the default for anything
with a display.
But it could be interesting to see what the hardware can do with
sufficient CPU resouces, because right now it is clearly CPU-limited.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
