The OS actively increases the amount of delay in the copy function when it detects a certain bit set that indicates the device is connected. I can snip the relevant section from Brandon's 2.41 disassembly:


Code:
As you can see, bit 3 of (iy+41h) indicates the presence of the Presenter when set.

A more useful application would be to use the port mirroring hardware for something else, like writing a custom driver PC-side that would let you access the LCD's contents through that extra hardware. That way the calculator doesn't have to do anything special, and it allows teachers to connect any 84+/SE's LCD directly to their computer, which they can probably already output to a TV. It completely eliminates the need for the TI Presenter and the Presentation Link adapter.

But that's a lot of work for not a lot of gain, and I'm not convinced the port mirroring hardware can work that way (peripheral vs. host mode).

If it was possible, though, wouldn't that mean better TI-Connect software that could actually take screenshots even when not at a GetKey or similar situation?

Yes. It actually does require running some code on the calculator as it'll have to enable the port mirroring hardware, but actually it could be done by silently transferring a small temporary program to do it.

And presumably also executing it? There's a mechanism for that as well via the Silent Link protocol, correct?

Yes, there is a command spefifically for transferring over a temporary program and remotely executing it, all in one step, and it'll delete itself.

Uh, wouldn't that make creation of a malicious virus-type program to install a SilentLink hook that would in turn transmit itself to other calculators?

Yes. It's been done.

For those who care I did some digging and here is some datasheety goodness for the two of the seemingly important chips on the thing.
http://www.xilinx.com/support/documentation/data_sheets/ds064.pdf
http://www.datasheet.org.uk/pdf-datasheets/Datasheets-6/DSA-113248.pdf

That's exactly the sort of thing I was talking about, except with an intermediate device between calculator and computer/whatever you want to send the information to. My question was if the increased LCD delay is required by the port mirroring hardware or the TI-Presenter.

If mirroring the LCD to a computer is possible it would be a cool way to make game demo videos though it sounds like there would be some small code modifications needed for the demo and maybe speeding up the video a little to compensate.

The only code modifications would need to be in the display routines, specifically iFastCopy and its derivatives, as we usually take shortcuts around TI's buffer copying routines. On my to-do list for Doors CS is to invoke a different buffer copy routine when the TI-Presenter bit is set, which would mean that coders wouldn't have to modify anything in their programs and games, given that they usually just call their shell's FastCopy routine.

@Elfprince13: That's a good question, I'm not actually sure. I assumed it was some combination of the two.

If it's the port-mirroring hardware, than using proper delays would be necessary for any DIY devices, but if it is only for the TI-Presenter hardware, then DIY devices pretending to be a TI-Presenter could potentially run at full speed.

I tend to think, and this is just an educated guess, that the extra delays are necessary to give the LCD hardware time to send over each chunk of data. This would mean that it's the mirroring hardware rather than the Presenter that requires the extra delays, and hence that DIY devices connected thereto would have to operate at the same reduced speeds.

Of course, a simple use of the LCD delay ports would require no modification to program source code.

Modification of the LCD delay ports does work, as proven by somebody on the Omnimaga thread.

I don't think the delay is necessary with the calculator itself, just the Presentation Link / TI Presenter. Since none of this requires either device to test, you can try to make this work yourself by outputting 1 to port 5Ah (this enables the hardware) and then trying to get it working as a USB peripheral, perhaps with another calculator to start. (BCALL 5290h initializes a connected USB peripheral; you could disassemble this to see exactly what's happening at the end to enable this hardware (it does some other stuff besides just port 5Ah, but that's enough to make it work)).