How hard is to build a processor?
in [Embedded]
|
Prev: LCD interfaces
Next: warentest berufsunfähigkeitsversicherung, berufsunfähigkeitsversicherungen vergleich, privathaftpflicht versicherung, volksfürsorge, kündigung berufsunfähigkeitsversicherung,
From: D Yuniskis on 27 Feb 2010 01:06 Hi Joe, Joe Pfeiffer wrote: > 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.... 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)
From: Mark Harriss on 27 Feb 2010 03:57 Tim Watts wrote: > > I knew a chap (York University Computing Services) who claimed to have a > mate who built an elementary CPU from fruit machine relays[1]. Occupied a > bit of board about one square yard. He lost interest in building RAM from > more relays, so wedged a 1k RAM chip with suitable interfacing on the side. > Ran at about 1 IPS apparently... > > [1] he got a box load from a surplus store, old stripped out ones. Had an > unusual contact configuration that made them quite suitable. > > Here's one built by a guy named Harry Porter: http://www.youtube.com/watch?v=n3wPBcmSb2U
From: Joe Pfeiffer on 27 Feb 2010 11:11 D Yuniskis <not.going.to.be(a)seen.com> writes: > Hi Joe, > > Joe Pfeiffer wrote: >> 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.... > > 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 :> ) 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. > Like me, at least you'll have plenty of Sun to play with! (NM) I like living down here! -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
From: Dennis on 27 Feb 2010 12:34 Thad Smith wrote: > Jon Kirwan wrote: >> On Fri, 26 Feb 2010 14:18:14 -0700, Bill Cooke >> <bcooke(a)cookedata.com> wrote: >> >>> Joe Pfeiffer wrote: >>>> Bill Cooke <bcooke(a)cookedata.com> writes: >>>>> In 1961 a colleague told me of a machine in a lab at Cornell named >>>>> CADET, which reputedly stood for "can't add, doesn't even try". > >>>> IBM 1620. See http://en.wikipedia.org/wiki/IBM_1620 >>> Hah! My leg's been pulled. and to think I'd just finished a year on >>> 1401, 705 code! I'd thought 'cadet' was a lab project, not a >>> for-real machine. I've even read a 1620 manual, but never got to >>> write for one. > >> I can remember hearing that phrase from time to time when I >> worked on the 1620. It was a fun machine. I used to swap >> out the colored bezels on the control panel just to tease. > > 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! > I remember my research adviser telling me about reworking op codes on the 1620 for x-ray crystallography work. It seems that some of them did table lookup rather than actual computation (probably where CADET came from). Apparently the tables were in memory so with a bit of work could be replaced. He redefined some to optimize for x-ray analysis code, which got quite a bit of use. Search "svetich ibm 1620" to see abstracts of some of the compounds. Before that he used the IBM 650 with SOAP - an optimizing assembler for the drum memory on the 650. It figured out instruction placement optimized for the drum rotation while an instruction was executing. I had less fun, my research was done using an IBM 360/30.
From: Thad Smith on 27 Feb 2010 14:17
Dennis wrote: > Thad Smith wrote: >> Jon Kirwan wrote: >>> On Fri, 26 Feb 2010 14:18:14 -0700, Bill Cooke >>> <bcooke(a)cookedata.com> wrote: >>> >>>> Joe Pfeiffer wrote: >>>>> Bill Cooke <bcooke(a)cookedata.com> writes: >>>>>> In 1961 a colleague told me of a machine in a lab at Cornell named >>>>>> CADET, which reputedly stood for "can't add, doesn't even try". >> >>>>> IBM 1620. See http://en.wikipedia.org/wiki/IBM_1620 > I remember my research adviser telling me about reworking op codes on > the 1620 for x-ray crystallography work. It seems that some of them did > table lookup rather than actual computation (probably where CADET came > from). The computer had a 10 x 10 digit lookup table for addition as well as one for multiplication. The table contained the digit for the sum and the flag bit was set to indicate a carry. > Apparently the tables were in memory so with a bit of work could > be replaced. Actually it was very easy to replace. > He redefined some to optimize for x-ray analysis code, > which got quite a bit of use. Search "svetich ibm 1620" to see abstracts > of some of the compounds. I always wondered how to take advantage of it. You could implement arithmetic with bases less than 10, but that didn't seem sufficiently interesting. > Before that he used the IBM 650 with SOAP - an optimizing assembler for > the drum memory on the 650. It figured out instruction placement > optimized for the drum rotation while an instruction was executing. Darn. I worked on a Bendix G-15 drum computer and had to optimize my own instruction placement. > I had less fun, my research was done using an IBM 360/30. Computers have always been fun in one way or another. -- Thad |