I was working at a small shop that had a hand-me-down 1620. They had a simple Fortran compiler, "PDQ Fortran", but it lacked some features they wanted. On my own, I wrote a disassembler for the 1620, disassembled the compiler, studied the code, figured out how to save some code space (memory was limited), then add some features, basically enhanced write commands and formatting, all with no external documentation. When the code was almost ready I was so excited I couldn't sleep, so went into work at 4 AM or such and got it working. Fun days!
Yes, Mick and Brick. An absolutely outstanding book on datapaths. and microprogramming; it was all based on 2900-series, but the concepts mapped to everything.
Yup! I read Mick and Brick cover to cover and learned a lot from it. I never built anything with bit slice other than on paper. But I have a lot of respect for those who did. I even used a "high end" workstation once that was a suped up 68000 made out of bit slice. I think it had a marketing window of 15 minutes before Moto came out with a 680xx or something much faster than the 68000.
I have thought about how to make a time piece that is actually regulated by the flow of water. It would be hard to get this to be accurate, but I havae some ideas on how to make it fairly good. I am in the mid-east US, so we normally have lots of rain. I have thought about ways to make it "self-winding". One is to simply catch rain from the roof and keep the top reservoir full. Another would be to use wind power to pump water from the lower reservoir to the top. That would be doubly cool. It might even allow the clock hands to be in front of the windmill blades!
But this project is way off in the distance. I have many other things to do first.
The clock/calendar I hope to build over the next year or so will be solar. The shadow of a post uniquely determines both date and time, if you look at both angle and length....
AMD published a lot of app notes and manuals that really catered to the 2900 family of devices. In my Great Databook Purge, they are among the few items that I kept! (along with Mick 'n' Brick, of course!)
I plan on cheating: detecting the "displayed time" and using that in a feedback loop to control the pump speed. It would probably need to be a terribly overdamped control system given all the other "cruft" between the pump and the "display".
Yes, that's my approach. We don't have enough rainfall to "self wind". I suspect it would be very difficult to keep enough water in the system to span the gaps between rains! (or, if you could keep enough water, trying to keep that water "clean" of algae, etc. over that long of a time period).
We get *lots* of sun so PV seems to be an essential part of any solution.
Ah, I don't plan on displaying the time in such a "traditional" format. :> I don't want folks to recognize it as a timepiece unless they *know* how to "read" it. Instead, it will just look like a kinematic sculpture...
Yup. In my case, the problem is figuring out what
*will* work "on paper" before investing lots of time building something that just turns out to be a nonfunctional eyesore.
Hmmm... is that (really) true? Or, don't you end up with
*two* date,times for each angle,length? E.g., won't the angle,length be the same for HH:MM on the day before and after the Summer Solstice? Or, close enough to make it near impossible to differentiate? (dunno, I find thinking in 3D on astronomical scales difficult :> )
Like me, at least you'll have plenty of Sun to play with! (NM)
Yes, I should have said "just about unique." I wouldn't be at all surprised to find out the variation with date won't be possible to distinguish more accurately than a couple of days, too.
I'm not sure where I got this image in my mind, but I seem to recall that the motion of the end of the shadow at a given time each day moves in a figure eight over the course of the year. Ok, I got over my laziness and googled it. This is called the "analemma" and is caused by the tilt of the Earth's axis and the elliptical orbit around the sun. This still does not make the position at all times and days unique, but it does help a bit (and hurt since it becomes a lot more complex to label).
The elevation of the sun varies very little close to the solstice, about the solar diameter (0.5 degrees) at +/-8 days from solstice and only about 12 arc secs at +/- 1 day from the solstice.
Various tropospheric refractions can alter the apparent elevation. The refraction is worst close to horizon, so the winter solstice will be worse. Trying to determine sunrise and sun set times is even worse, since average refraction is just slightly less than one degree and can vary quite a bit from day to day (even mirages).
The solar elevation changes rapidly close to the equinoxes (about the solar diameter/day), so this is the best time to determine the date.
Determining the local solar time is easy, just determine when the sun transmits the meridian (i.e is directly in the South in Northern hemisphere). Some local clocks are required to divide the time until the next solar transit into 24 hours. The time between two transits is not usually 86400 (atomic) seconds, but varies slightly according to the equation of time (which is due to the elliptical orbit of the Earth).
Averaging these variation over the year, you can calculate the mean solar time, in which the day is exactly 86400 seconds long.
Waiting for a year to determine the mean solar time or using a sufficient accurate local frequency standard, you can determine, if the actual solar day is longer or shorter than 24 hours, which may help some ambiguity problems in the elevation measurements. Determining the date is much harder due to the refractions, but averaging over a sufficient number of measurements (days), this should give relative accurate results at the equinoxes.
Once you know the mean solar time and know your longitude, you know the time at the zone meridian (0, 15, 30, 45 ... degrees E/W). Knowing your latitude, you can determine in which country you are in and hence which time zone is actually used at that area. Finally by knowing your date, will allow you to calculate, if daylight saving time should be used :-).
The IBM 1620 was the first computer I used. It had some interesting features, a BCD machine with variable length data words.
I ran a fibonacci series on it to 2000 terms it took 18 hours.
A lot of neat things could be done with the math tables which could be set at run time. The math tables were also the target some elaborate pranks in IBM 1620 labs
It was also the first computer that I wrote a compiler for. I have a lot of good memories of the 1620.
Actually, it happens for every day of every year other than the solstices. The two solstices (actually a day or two on either side depending of the season) has the lowest or highest path across the sky, so no other day will have quite in that same path. But every time of every other day (excluding a few seconds at the start and end of the day when one day has sunshine and the other does not) will match a time of two days, between spring to fall and one between fall to spring. The path of the sun may not be the same on those two days, but each point will map to two different times and days.
So (thinking in terms of a *truly* unique hack), if you *watched* the motion over the course of a particular day (e.g., 'yesterday'), could you *uniquely* determine that day?
In terms of the project I've got in mind, people are really over-thinking this..... I'll be very surprised if the shadow ends up distinguishing the day with better than a couple-of-days precision anyway.
That said, two days won't follow *exactly* the same path: a fall day's shadow is going to be between two spring days' shadows, and so forth.
Arrrgh -- I misread what you were saying, so my response didn't make much sense.
But, I still don't expect a point to necessarily correspond to two date/time pairs. Time is continuous, but days aren't. There will be a gap between any two days' shadow tracks (probably smaller than the fuzziness of the shadow caused by diffraction but there all the same). Unless two tracks exactly overlay for some meaningful part of the tracks, a given track can only intersect other days' tracks at a finite number of points points.
Sounds like a cool idea. Would need this sort of correction :
formatting link
which means it could take a couple of days to 'train', in order to be certain.
For the best precision, you'd probably do a simple sliding-data- match, where maybe the last 7? days of readings, are moved along to a point of least-errors. (and maybe a cloudy-day default, where it just increments the day ?
I don't see why you think you can't get 'correct day' precision out of this ?
Pushing the actual-time precision is likely to be more challenging ?
Possibly in March or September, but absolutely not in July or December, just look at the graph.
A 7 day period would be sufficient to figure out, if it is March or September by checking the direction of the solar movement.
That is trivial. The apparent solar diameter is 30 arc minutes and since the sun moves 15 degrees each hour, it only takes 2 minutes to move its own diameter, thus the actual noon can be determined with much better precision.
In order to get the solar mean time noon, you also need to know the approximate date to apply the equation of time.
So, a *device* that watched these things could deduce date/time (?) How much more would it have to do to deduce location (or, at least, latitude)? Probably just watch for a longer period of time?
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.