[TI-H] Re: Parallel link woes, how does screenshot work etc.
[Prev][Next][Index][Thread]
[TI-H] Re: Parallel link woes, how does screenshot work etc.
First:
>Or maybe I should try to build the serial link instead? Does it have a
>higher 'success' rate?
Yes, the serial has a higher success rate.
I would recommend this. It is also compatible with more link programs.
It even works with TIs own software, thats why its often is referred to as
"Black Cable Compatible".
>All programs that feature a test segment (linktest, Cal) report that the
>cable is working just fine.
>But when nothing worked I wrote a simple program
>that monitored the parallel-port status, and it seemed like the signals that
>the calculator sent never came through, the value returned from port 378h
>returned 3 all the time. When using a link-program set to 'send' mode it
>changed to 1 or 2, but it seemed like the calculator never responded to
>this.
This is because the reading isn't done on the dataport (378h) but on the
status/control port. I don't remember if it is 377 or 379, but the
neighbour port of the data port.
The sending is though made on the data port, why you can see this reading.
>I then decided to do some tests with a multimeter:
>
>* Cable not connected to the computer:
>- Pins 2 and 3 (also 12,13) are at 4-5V when the calculator is in 'normal'
>mode.
>- Pins 2 and 3 (also 12,13) are at about 0V when the calculator is set to
>send a file.
>This seems to be the way it should.
>
>* Cable connected to LPT1 (but no link software running)
>- Pins 2 and 3 at 3.3V (12,13 somewhat higher) when the calculator is in
>'normal' mode.
>- Pins 2 and 3 still at 3.3V when the calculator is set to send a file, but
>12 and 13
>go down to about 1V.
>Shouldn't 2 and 3 also go down to 'low' level at this point??
>Isn't pin 2 and 3 those that the computer uses to read input from the calc?
>Since they don't change to anyhting but 3.3 even when the calc tries to send
>a low (0) signal, this seems to be why my calc isn't working. The quesion
>though is WHY is this happening?
See below.
>Then I read in Andreas Westfeld's FAQ that pins 2,3 are used for _sending_
>only, and that 12,13 are used to read. In that case, the problem I described
>above is not a problem, since 2,3 shouldn't change when the calc is sending
>then. But if this is the case, isn't the diodes switched wrong then? I mean,
>the data you set at 2,3 can't make it's way onto the cable! If 2,3 are meant
>to READ data from and 12,13 meant to send, it would make more sense. Or am I
>misinformed?
The reason it works is that the pins are "naturally" high, until something
pulls them low.
(because of the open collector type of input/output on the calc)
The inputs on 12,13 does not affect this, so as long as you want to output
a high voltage, everything is fine, and then when you want to output a low
voltage, you pull 2 or 3 low, wich lets current flow from the calc to the
pin, dragging it low. (or at about 0,6V because of the diode)
The diode is needed when you want to read, and the calc is doing the
pulling of the line, so that the last output you made on 2,3 should not
affect the reading. (stops the output from pulling the lines high)
Had the outputs on the parallell port been open collector like the calc,
those diods would not have been needed.
I'm sorry, I can't from this see why it doesn't work. maybe the computers
you've tested with was too fast.
This is a problem with the paralell link. Another problem is that it
doesn't work with some computers link port.
There might be a bios setting that makes it work, but I don't remember wich
is the right. Try that.
Sounds like the cable is ok...
The paralell cables are tricky. I had a cable that worked perfectly with a
ti83, but totally refused to work with my ti89, if I didn't put my fingers
on some solderings. (that where perfectly fine, I resoldered them more
times then I held count on)
I rebuilt the cable from scratch about 15-20 times, with different
modifications, (caps, resistors, you name it..) before I finally gave up,
and built a serial that worked on the first try and have worked flawlessly
since...
>Finally, can someone explain how screenshot-functions in transfer programs
>are supposed to work? I mean, the calc is not supposed to be in send mode,
>how does it know that it should start sending a screenshot? Does it
>constantly poll the link-port when in 'normal' operating mode?
When one of the link lines on the calc go low, a link interrupt is
generated, and the link routine starts reading from the port. If it reads a
"send screenshot"-command, it sends the screenshot.
If there is an error, there will be a timeout. This is the reason the calc
can feel reeeaaally slow if you plug it in to a computer without a running
link program, with some link cables.
The link interrupt is called over and over again, and times out every time.
///Olle
References: