4 Apr
2006
4 Apr
'06
6:44 p.m.
woodelf wrote:
No. That is a (stationary) receiver with dedicated hardware
to monitor the incoming RF to make sure it's what and "where"
(in terms of *time*) it should be. E.g., it is dedicated to
a particular GRI (Group Repetition Interval), hears the
Master broadcast (at that period), expects to hear each of
the slaves respond (at reasonably fixed intervals in relationship
to the Master's transmission, based on where *they* are
located and where *it* -- the PDP8 -- is located). The
timing of the signals is done in hardware with a high speed
counter timer, etc. The waveshape of each pulse is rigidly
defined so you can see if it has been distorted by the
transmitter, etc. (you track the position -- in time -- of
each pulse by watching for a certain zero crossing of the
carrier defined within the envelope).
All it has to do is worry about stations going off the air
and some minor variations in signal timing based on changes
in atmospheric propagation (since the transmitters are in
fixed locations).
A *plotter* takes two or more pairs of "time difference"
coordinates (TD's) and converts them to a geographical
(Lat-lon) location. The TD's define families of
"concentric" :-/ hyperbolae. The intersection of a
"line (hyperbola) of constant time difference" for one
Master-Slave pair with an intersection of another line of
constant time difference determines your location.
But, these are hyperbolae, not nice spherical coordinates.
And, there can be ambiguties -- a given set of TD coordinates
can represent two different points on the globe (sometimes,
quite close together, sometimes quite far apart!).
So, you have to capture the incoming coordinates, solve the
difference equations to map the hyperbolae onto a spherical
globe, compensate for the *oblateness* of that globe, do
a 2D mercator projection, scale it to the desired user's
scale and then drive X & Y motors to move the pen from
where you were (last update) to where you *are* (in a straight
line, of course) -- without running off the edge of the page,
etc.
In addition to driving the multiplexed displays, scanning the
keyboard (debouncing keys, etc.), interacting with the user, etc.
Nowadays, I could code the whole thing in a month or so.
But, it sure wouldn't fit in that hardware footprint!
(keep in mind, 2Kx8 EPROMs were $50 at the time... $250 just
to store the code!)
I don't believe any are that tied to the hardware. Even PL/M
has no provisions for it *directly*.
--don
Don Y wrote:
There are advantages to simplicity! :>
Exactly. And the code in that application is likely to be revised.
The code in your microwave oven, isn't!
Hey I still like the MECHANICAL microwave oven controls. Great! Here
are 256 bytes of ram. Design and implement
a LORAN-C position plotter in C. It has to process data in real
time (i.e. maybe 1.5 updates per second), run on a *3* MHz CPU
and you have 10KB for TEXT.
Did not the PDP8 do that in 4K? of memory.
see: http://www.parse.com/~museum/pdp8/pdp8e/loranc.html And,
that's a "bountiful" work environment!
Doing decimal arithmetic in C sucks. As does
trying to pack
8 bools to a byte (and access them efficiently), etc. Loss
of the carry is probably the biggest single pisser in most HLLs.
Does any HLL's have access to the carry flag? A unsigned compare
can get a carry for you but I can't remember the details of that
trick.