Re: Tape85

[Prev][Next][Index][Thread]

Re: Tape85

I am very experienced with handshaking and com protocols, even over highly
unreliable channels.

My plan for protocol follows this:

For now, the calculator can directly send the tones through the link port
for data storage. However, perhaps I will throw in a DAC convertor
(Probably a dual.. DAC/ADC.. can go from digital to analog and back) so
that I have better control.

To get back to the calc, there *HAS* to be an ADC. the link port alone
cannot read data off analog wave output. (Walkman, soundcard, whatever.)

The protocol itself, roughly.

4 seconds of a distinctive tone. Before that, you might want to voice-speak
in the program for your own reference. When the calc is running the RECV
tape85 driver, it waits for quite some duration of this distinctive signal.
Think of it as the whine a modem gives during connection. Once this signal
ends, the header comes in. The header contains what type of data is being
sent, how many blocks (or how many bytes, and the calc converting that into
how many blocks and how much is waste in the last block). So that's either
Bytes, or blocks/number of bytes in last block. Still have to see what's
most efficient. The name of the variable, although if I write a complicated
driver user can name it to whatever. Then the actual data comes in, plain,
bytes.

However, every block of data on the tape is 64 bytes long.
After these 64 bytes, there is a CRC which can auto-correct 1 byte error.
If one byte comes in wrong, the calculator knows which one is wrong, and
what it should be, just by the CRC info. That will mean a rather sizable
CRC, but it will be a lot shorter than copying a block, and more efficient
anyhow, since when using doubles, and thre is a mistake, the prog doesn't
know which one is the wrong one. That CRC system is mostly advanced math,
but should not be hard to implement. Have used error-correcting CRCs quite
a lot.

As to storage.. there are 4 different tone-ranges. The ADC will pick up
which tone range is currently pon the tape and output 00,01,10, or 11, over
the red/white wires of the linkport, depending on tone. The calculator
binds four different signals over the lport together into a byte. it will
get a block of 64 bytes + it's CRC, does an error check, and corrects 1
mistake if there are any. If it detects there are 2 or more mistakes (in
which case it can detect 2 and sometimes 3 mistakes, but will not be able
to fix it, and thus the data cant be used.. user iwll be notified). if it
detects 2+ mistakes, it sends a special exist signal to the variable
writer. If 0 or 1 mistake, it corrects and then removes the CRC, and sends
that along to the var writer.

The var writer reads and decodes the header, and stores the data.

supported data types is String, Prgm, and picture.

Backups are not possible. duh. It needs a special driver, and that driver
gets wiped on backups. and that can't be :-P.

furthermore, any such stuff as getcbl and [2nd]|Link will of course not
work.

I have no clue yet as to how tight I can bind the notes. In other words,
the duration of each tone. I will use whatever causes nearly no errors. I
might, in the driver, provide 3 different storage mechanisms. Fast, Normal,
and Slow. Fast will mean you can store more on a tape, and record/load
times are small, but data errors are likely- good quality tape needed. Slow
will mean that errors are just about impossible, but you can't use much
tape, and load/rec times are long. (note here.. take a 90 minute tape.
Let's assume 5 minutes for 32k (I really doubt it would take that long)..
that would mean you can store 18*your calc mem on that tape with a
relatively slow storage process.. ie: you can store quite a lot.

My real problem is finding the hardware. I know now I will need an ADC,
possibly a DAC, but I would have absolutely no clue a to how to make them
work correctly, what kind of power source to connect, all that hardware
stuff, I have no clue.

So, unless I somehow get to learn all about it, I will not be making
Tape85. I someone manages to get the hardware straight, I will not hesitate
to send you all the protocol details I have put on paper.

--
-R.Zwitserloot@BTInternet.com

Neil Padgett <padgett@mcmaster.ca> wrote in article
<33ca7e60.388484@informer1.cis.mcmaster.ca>...
> Jeff Tyrrill <Jeff_Tyrrill@MSN.COM> muttered:
>
> ->The commands must do some handshaking. They can be used to "steal"
> variables
> ->from another TI-85, as long as the other calc is at the Home Screen.
> It can't
> ->just read the memory through the link port; handshaking would have
> to occur.
> ->________________
>
> I am not quite sure in what fomrat you plan to store the information
> on the tape. Am I right in assuming that you plan some sort of
> Frequency Shift Keying, in that I mean you have one tone for 0 and
> another for 1? Or do you have a greater variety of tones? Basically I
> am wondering in what form these tones are sent. A definite
> possiblility could be to use a single tone and then pick it up with an
> NE567 tone decoder. This decoder sets a logic high whenever its input
> contains a certain tone (this tone can be selected by the support
> resistors, etc.) However, this decoder can be quite slow with low
> tones. So, data rates couldn't probably exceed 300 bps. This speed
> however would be acceptable and would allow the use of cheap tapes. Of
> course, I haven't tried any of this out, and maybe greater data speeds
> could be possible... BTW the NE567 costs about 0.47 US. Even with a
> few resistors, and a jack we could be talking less than $5. I would
> also suggest having a CRC on data on the tape. Possibly every block
> should be written twice for realiability?
>
> Perhaps something like a cable with a SPDT switch. This switch could
> have a write setting which is simply a cable with no electronics, and
> a read setting which switches the tone detector into the circuit?
>
> Just some thoughts,
> Neil Padgett
>
>
References: