Start with replacing the existing board with something new. Step 2, add a USB interface.
Step 3, world domination! Ok, maybe not so much with the last one... On Sun, Feb 20, 2011 at 3:21 PM, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote: > 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.