- I was thinking of a BEAM robot that can be programmed.
Aren`t cassette tapes analogue or am I dreaming again?
My idea is really strange.
We make a robot with two touch sensors and two motors with wheels.
We make 4 cassette tapes spin with the same speed.2 of them will
have information for the sensors and the other 2 will have
information for the motors.So.......when one of the sensors (let`s
say the left one) hits an object it has a logical "1" (am I going
digital), the tapes are spining (aways) and when the tape
corresponding to the left sensorhas a logical "1" and the other tape
corresponding to the right sensor has a logical "0" ( like the
situation is [ the left sensor has "1" and the right "0" ] ) the
other two tapes are checked (the ones corresponding to the motors)
and if the tape corresponding to the left motor has 1 the left motor
spins and so on.......
It`s really confusing.Anyway are cassette tapes digital or
analogue???And if anyone understands my idea does he think it is
- Yes, tape cassettes are analog. As to the programming method you
describe, it reminds me of my old TRS-80s. These Tandy/Radio Shack
computers came with tape drives that enabled you to save data.
> I was thinking of a BEAM robot that can be programmed.
> Aren`t cassette tapes analogue or am I dreaming again?
> My idea is really strange.
- At 01:22 PM 8/6/2003, you wrote:
>Yes, tape cassettes are analog. As to the programming method youTrue enough, using the Kansas City Format or the like:
>describe, it reminds me of my old TRS-80s. These Tandy/Radio Shack
>computers came with tape drives that enabled you to save data.
>The tape system was *very* slow, both because of the actual data rate and--------------------------------------------(stolen from some page somewhere)
>also because of the data format used. A "1" was stored as a short tone
>pulse at 1.95kHz - a "0" was simply an absence of the tone. This crude
>system worked reasonably well at the low data rate used (once the bug in
>the tape read routine of the original NASBUG had been fixed). The problem
>was that this system was very susceptible to spurious "clicks" and " pops"
>and also suffered if low quality tape was used as "drop-outs" could be
>read as "0" bits. Because of this increasing the data rate was not always
>A design for an improved cassette interface for the NASCOM-1 was published
>in PCW. This used the "CUTS" (Computer Users Tape Standard) format - also
>known as the "Kansas City" format. This represents a "1& as a 2400Hz tone
>and a "0" as a 1200Hz tone. The interface was always known to NASCOM users
>as the "Cottis-Blandford" system after the designers. Of course this
>system was not compatible with the original system, but it was so much
>more reliable that the older system got left behind. The "standard" that
>emerged used this interface at 1200 baud. This was readable on both
>NASCOM-1 and NASCOM-2 systems, although the NASCOM-2 (and modified
>NASCOM-1 systems) could also use 2400 baud with a bit less reliability.
>Many program tapes were sold with 1200 baud data on one side and 2400 baud
>on the other.
So, of course, the tones are obviously analog but they still were used in a