Subject: RS232 hardware handshake can't work between two TIs

From: "Michael Zapf" <[email-masked]>
Date: Sat, 30 Jul 2011 12:00:43 -0000

The last weeks of my work on the RS232 have been both encouraging and frustrating. I think I have come to a point where I have to say that what I achieved is all we can get, but before I get to premature conclusions I want to discuss the problem here, and I hope that either some of you can point me to a solution I did not see, or we have to live with it and at the same time finally understand why handshaking between two TI never really worked and can actually never work.

Full story...

Recall that during the last weeks I've been working on the support of serial connections between emulated systems in MESS and real, external computers. My primary goal is to connect a real Geneve and an emulated TI or Geneve by serial line and to exchange data over that link.

I had some good progress up to now, and my last tests showed that I was able to transfer files by XModem between two TELCOs or MYTERMs. TELCO can cope with 4800 baud before losing bytes, while MYTERM can achieve 9600 baud. I was not able to transmit by 19200 baud, not even if the receiver is the real Geneve, so that does not seem to be a failure of the emulation but just a bit too high a goal.

Not everything went as smoothly as I hoped. MYTERM works quite well for files that are not too large, but as soon as MYTERM starts to save the received fragment, the next record is invalid. That is understandable because the sender has not been suspended, and bytes are lost during the save operation. 

XModem actually cannot work with XON/XOFF because it has no escaping for its bytes, so the handshake bytes would go unnoticed. Instead, we have a simple flow control by the record number. However, the longer the file becomes, the more errors we collect. When too many errors have been detected, the transmission is aborted, which is not what we want.

I came to believe that higher rates require proper handshaking. With some efforts during th last three weeks I managed to control the real serial interface lines via MESS, so all those lines like RTS, CTS, DSR, DTR, DCD are really used. So I was hoping that this finally leads us to the complete emulation of the serial connection.

Well, despite several attempts, safe handshaking has failed up to now. 

I recently reported that I found that the TI interface is not designed as a DTE (computer-type device) but as a DCE (modem-type device), and that very fact is now quite nastily kicking our backside. 

After my last attempt I came to the conclusion that hardware handshaking cannot work in the common way at all between two TIs or Geneves. Between TI and PC, yes. Between TI and modem, yes. Between two TIs, no. 

I'll give some explanations on serial handshaking with the TMS9902 in the following which is used in TI RS232 cards and compatible ones.

The TMS9902 UART has a data in, data out, RTS, CTS, and DSR pin. As I mentioned they are a bit unconventionally wired to the connector: RTS goes out via the DCD pin (8), CTS and DSR are connected together and get their input via the DTR (20) pin. There is a third line going out of the CTS pin (5) which is controlled via CRU address 130A. So how can handshaking work with this setup?

Following the RS232 manual, if we have a setup with a TI connected to a PC we can use a 1-1 direct cable. The RTS of the 9902 will signal a carrier detect to the remote computer, so the terminal can get ready to receive data. Using the CRU line we can halt and resume the remote computer's transmission. The remote computer should use the DTR line to activate the CTS line on our 9902.

The manual suggests that between two TIs, we should use a simple crossover cable. It actually does not allow for any hardware handshake because it just pulls up the DTR input to high by the respective other side. RTS, CTS are not used.

They could not, anyway. According to the specification of the 9902 and following the mode of operation, the RTS line of the 9902 has one specific meaning: "I want to send you a byte." It does not mean: "Please send me a byte." This second meaning was introduced by some device manufacturers and led to the definition of the "Ready to receive" signal. (Also see http://en.wikipedia.org/wiki/RS-232#RTS.2FCTS_handshaking )

In our case RTS is really the first one, "I want to send a byte." Next thing for the 9902 is to check whether CTS is active. Sometimes you can see that there are null-modem cables that use a crossover of RTS/CTS and DTR/DSR. This will miserably fail here. CTS should mean "Yes, you can send." If you cross-connect both pins, you will make the "Yes, you can send" equivalent to "I want to send a byte" of the other side. That is, the first 9902 will only send its byte if the second 9902 declares that it wants to send a byte in the opposite direction.

The bad thing is that RTS *must* be set to send a byte; it's not an optional feature. This entails that if TI #1 wants to suspend TI #2 by clearing RTS it will break this pause as soon as it sends a byte to #2, which may instantly make #2 send one or more bytes to #1.

I watched the MYTERM operation and noticed that RTS is used in the expected way: RTS is set when it wants to send a byte and then cleared when the byte has been sent. The bad thing about that is that by the RTS/CTS crossover, my real opposite Geneve was now muted. I have no chance to send a byte back to the emulated Geneve.

So let's turn to DTR/DSR. The 9902's operation is actually not affected by changes of DSR; you can enable an interrupt when it occurs, so the operating program may react on that. Unfortunately, on our boards, DSR is directly connected to CTS. If we pull down DTR, we again mute the opposite site. This may be desired, you say, but what signal will be used to control the DTR? If we swap wires and use RTS we get the exact problem from above.

So the only output line that is left is the CRU bit 130A. If we link this bit to the DTR line instead of to the CTS line, we can halt the other side by means of the CRU bit and release it again. Well, if software actually used it. And MYTERM does not, as my logging outputs showed. So much for options.

Sadly, there seems to be no way of creating a working hardware handshake between the emulated TI/Geneve and the real machine. We will have to live with the fact that XModem will fail at higher rates for longer files due to accumulated lost bytes. 

Prove that I'm wrong.

As I said: I am not claiming that hardware handshake does not work at all. It's just not working between two directly connected TIs or Geneves. It is likely to work between a TI/Geneve and a PC. But that does not help me with my emulation.

Michael

---

From: Jeffrey White <[email-masked]>
Date: Sat, 30 Jul 2011 07:59:10 -0700 (PDT)

Michael,

Note that the following does not prove you wrong.  It is just an attempt to 
explain the hardware handshaking possible with an alternate cable and true DCE 
(modem-like) equipment.

Here is the new cable I would try with a TI-to-TI connection:

TI RS232  TI RS232  Name defined by "left" pin 
  1      1    Protective Ground 
  2 <--  3    Receive Data 
  3 -->  2    Transmit Data 
  5 -->  20    Request to Send 
   7      7    Logical Ground 
  20 <--  5    Clear to Send 
 
This cable requires deft use of the RS232.  It requires re-purposing the of the 
CRU output bit that controls pin 5 of the RS232 RTS  (by my "correct" naming 
convention) and repurposing the DSR/CTS (they are tied together at the 9902) on 
pin 20 as the CTS.
 
With a CRU base address of >1300, the offsets of RTS and CTS as defined by me 
are:
 
RTS1 EQU 5
CTS1 EQU 32+28 
RTS2 EQU 6
CTS2 EQU 64+28
 
The 32 and 64 above are to account for the offsets of the 9902's on the RS232 
cards.
 
Yes, this really gets confusing to all heck.  I have renamed the CTS pins as 
defined by TI as RTS pins.  Then I get to use the CTS functionality of the 9902, 
which is tied together with DSR at the 9902.  

The RTS pins are Outputs.  The CTS pins are inputs.  Each side will only send 
when CTS is active -- i.e., I am "clear to send".  Each side will acknowledge  
its availability to receive data by asserting RTS.
 
Playing with the useless RTS signal of the 9902 is futile for handshaking.  I 
use it for a hangup of the modem.
 
Did you try Tim Tesch's PORT terminal emulator with the JEFF cable?  Here it is 
described as in a conversation between Jeff Brown and me:

"Jeff, you are quite right.  TI's naming scheme is quite annoying.  I think you 
have duplicated my cable design, but a chart of the pinouts my Port (Term80?) 
cable uses is as follows: 

RS232  Modem  Name 
  1      1    Protective Ground 
  2 <--  3    Receive Data 
  3 -->  2    Transmit Data 
  5 -->  4    Request to Send 
  6      -    No connection 
  7      7    Logical Ground 
  8 --> 20    Data Terminal Ready 
 20 <--  5    Clear to Send 

The names are standard for modem (data communication) equipment.  TI's RS232 
is DCE, but named improperly.  The inaccuracy comes from swapping the names 
of pin 6 and pin 20.  RS232 convention says that pin 6 of DCE is Data Set 
Ready (DSR), and pin 20 is Data Terminal Ready. 

Oh, had TI just stuck with the standard.  TI named pin 6 the DTR line, and pin 
20 the DSR line.  What is wrong with that, you might wonder.  I remember the 
RS232 convention as follows -- Data SET Ready sets (or sends) the signal; a 
signal terminates at Data TERMINAL Ready.  Of course, this logic cannot be 
applied to data terminal equipment (DTE) definitions. 

However, the RS232 standards seem defined by the DCE side of things.  It 
certainly is easier for me to start at the modem and determine where the 
signals need to go rather than some ill-defined RS232 port. 

Jeff White" 
 
Another possibly useful quote from that conversation:
 
"Back to the 99/4A RS232 cards.  As I said, CTS and DSR are wired together 
at each 9902 UART.  This is fine.  DSR is active whenever the modem is 
ready (like when it is turned on, and the MR -- modem ready -- light is 
lit).  The modem will not activate CTS unless the modem is ready.  There 
is no need to connect pin 6 from the 25-pin modem port to the RS232, unless 
you want to know if it is turned on.  If your program sends a Hayes command 
and gets a response, the modem must be on or the static electricity in the 
air quite organized (which is against the nature of static). 

CRU bit 28 is where the status of CTS can be read.  CRU bit 27 is the DSR 
status read location.  Both bits will always have the same value.  We do 
not care about the modem DSR signal (pin 6), so we route the modem CTS 
signal (pin 6) to pin 20 (CTS/DSR) of the RS232 port. 

If the 99/4A is going to send to the modem when the CTS signal is active, 
the RTS signal on the 9902 UART must be active.  If we connect this RTS 
signal to the modem RTS signal, this would tell the modem it can send to 
the 99/4A.  This is not necessarily true.  It is best to find a different 
signal that is not coupled with the CTS signal like RTS. 

On the TI, Corcomp, and my-upgrade-Myarc RS232 cards, output CRU bits 5 and 
6 are put on pins 5 and 12 of the RS232 port.  Pin 5 of this port becomes 
the RTS for RS232/1 or /3, and pin 12 the RTS for RS232/2 or /4.  This new 
RTS is connected to RTS (pin 4) of the modem.  [Incidentally, my-upgrade 
to the Myarc RS232 makes output CRU bit 4 toggle the DTR line -- something 
TI and Corcomp cards cannot do unless modified, too.] 

Back to pin 8 of the 99/4A RS232 ports:  We know that it must always be 
active for transmission to occur from the 99/4A to the modem.  We also know 
that the computer and RS232 must be on for this transmission to occur.  It 
is thus logical to make it perform like the modem ready (MR) signal.  If 
the 99/4A is running terminal software, turn on CRU bit 16 to activate the 
Data Terminal Ready.  Hang up the modem by turning it off. 

Now for the final piece.  Most 99/4A software toggles CRU bit 16 (RTSON) on 
before transmitting a character, and off after transmission is complete. 
This is wasting CPU cycles.  If you locate the "SBZ 16" code (>1E10) in the 
transmit character loop, change it to a "SBO 16" code (>1D10).  You will 
not notice a difference in performance of your terminal software.  You will 
speed your software by removing the "SBO 16" and "SBZ 16" instructions in the 
transmit character loops. 

If you do not want to edit the code, but want to use terminal software that 
does not support my Port cable, simply send the Hayes command "AT&D0" to 
make the modem ignore DTR.  That is an ampersand (shift-7) character in 
front of the D and zero if someone runs this article through the formatter. 

Now aren't you glad you asked? 

Jeff White"

Jeff White (natch)

________________________________
From: Michael Zapf <[email-masked]>
To: [email-masked]
Sent: Sat, July 30, 2011 8:00:43 AM
Subject: [TI994A] RS232 hardware handshake can't work between two TIs

The last weeks of my work on the RS232 have been both encouraging and 
frustrating. I think I have come to a point where I have to say that what I 
achieved is all we can get, but before I get to premature conclusions I want to 
discuss the problem here, and I hope that either some of you can point me to a 
solution I did not see, or we have to live with it and at the same time finally 
understand why handshaking between two TI never really worked and can actually 
never work.

Full story...

Recall that during the last weeks I've been working on the support of serial 
connections between emulated systems in MESS and real, external computers. My 
primary goal is to connect a real Geneve and an emulated TI or Geneve by serial 
line and to exchange data over that link.

I had some good progress up to now, and my last tests showed that I was able to 
transfer files by XModem between two TELCOs or MYTERMs. TELCO can cope with 4800 
baud before losing bytes, while MYTERM can achieve 9600 baud. I was not able to 
transmit by 19200 baud, not even if the receiver is the real Geneve, so that 
does not seem to be a failure of the emulation but just a bit too high a goal.

Not everything went as smoothly as I hoped. MYTERM works quite well for files 
that are not too large, but as soon as MYTERM starts to save the received 
fragment, the next record is invalid. That is understandable because the sender 
has not been suspended, and bytes are lost during the save operation. 

XModem actually cannot work with XON/XOFF because it has no escaping for its 
bytes, so the handshake bytes would go unnoticed. Instead, we have a simple flow 
control by the record number. However, the longer the file becomes, the more 
errors we collect. When too many errors have been detected, the transmission is 
aborted, which is not what we want.

I came to believe that higher rates require proper handshaking. With some 
efforts during th last three weeks I managed to control the real serial 
interface lines via MESS, so all those lines like RTS, CTS, DSR, DTR, DCD are 
really used. So I was hoping that this finally leads us to the complete 
emulation of the serial connection.

I recently reported that I found that the TI interface is not designed as a DTE 
(computer-type device) but as a DCE (modem-type device), and that very fact is 
now quite nastily kicking our backside. 

After my last attempt I came to the conclusion that hardware handshaking cannot 
work in the common way at all between two TIs or Geneves. Between TI and PC, 
yes. Between TI and modem, yes. Between two TIs, no. 

I'll give some explanations on serial handshaking with the TMS9902 in the 
following which is used in TI RS232 cards and compatible ones.

The TMS9902 UART has a data in, data out, RTS, CTS, and DSR pin. As I mentioned 
they are a bit unconventionally wired to the connector: RTS goes out via the DCD 
pin (8), CTS and DSR are connected together and get their input via the DTR (20) 
pin. There is a third line going out of the CTS pin (5) which is controlled via 
CRU address 130A. So how can handshaking work with this setup?

Following the RS232 manual, if we have a setup with a TI connected to a PC we 
can use a 1-1 direct cable. The RTS of the 9902 will signal a carrier detect to 
the remote computer, so the terminal can get ready to receive data. Using the 
CRU line we can halt and resume the remote computer's transmission. The remote 
computer should use the DTR line to activate the CTS line on our 9902.

The manual suggests that between two TIs, we should use a simple crossover 
cable. It actually does not allow for any hardware handshake because it just 
pulls up the DTR input to high by the respective other side. RTS, CTS are not 
used.

They could not, anyway. According to the specification of the 9902 and following 
the mode of operation, the RTS line of the 9902 has one specific meaning: "I 
want to send you a byte." It does not mean: "Please send me a byte." This second 
meaning was introduced by some device manufacturers and led to the definition of 
the "Ready to receive" signal. (Also see 
http://en.wikipedia.org/wiki/RS-232#RTS.2FCTS_handshaking )

In our case RTS is really the first one, "I want to send a byte." Next thing for 
the 9902 is to check whether CTS is active. Sometimes you can see that there are 
null-modem cables that use a crossover of RTS/CTS and DTR/DSR. This will 
miserably fail here. CTS should mean "Yes, you can send." If you cross-connect 
both pins, you will make the "Yes, you can send" equivalent to "I want to send a 
byte" of the other side. That is, the first 9902 will only send its byte if the 
second 9902 declares that it wants to send a byte in the opposite direction.

The bad thing is that RTS *must* be set to send a byte; it's not an optional 
feature. This entails that if TI #1 wants to suspend TI #2 by clearing RTS it 
will break this pause as soon as it sends a byte to #2, which may instantly make 
#2 send one or more bytes to #1.

I watched the MYTERM operation and noticed that RTS is used in the expected way: 
RTS is set when it wants to send a byte and then cleared when the byte has been 
sent. The bad thing about that is that by the RTS/CTS crossover, my real 
opposite Geneve was now muted. I have no chance to send a byte back to the 
emulated Geneve.

So let's turn to DTR/DSR. The 9902's operation is actually not affected by 
changes of DSR; you can enable an interrupt when it occurs, so the operating 
program may react on that. Unfortunately, on our boards, DSR is directly 
connected to CTS. If we pull down DTR, we again mute the opposite site. This may 
be desired, you say, but what signal will be used to control the DTR? If we swap 
wires and use RTS we get the exact problem from above.

So the only output line that is left is the CRU bit 130A. If we link this bit to 
the DTR line instead of to the CTS line, we can halt the other side by means of 
the CRU bit and release it again. Well, if software actually used it. And MYTERM 
does not, as my logging outputs showed. So much for options.

Sadly, there seems to be no way of creating a working hardware handshake between 
the emulated TI/Geneve and the real machine. We will have to live with the fact 
that XModem will fail at higher rates for longer files due to accumulated lost 
bytes. 

Prove that I'm wrong.

As I said: I am not claiming that hardware handshake does not work at all. It's 
just not working between two directly connected TIs or Geneves. It is likely to 
work between a TI/Geneve and a PC. But that does not help me with my emulation.

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 30 Jul 2011 15:41:25 -0000

Hi Jeff,

thanks for the reply ... going to read all of that in the next minutes ...

> TI RS232  TI RS232  Name defined by "left" pin 

yes, agreed, that's the "final option" I was talking about - using the CRU bit 130A for handshaking. We just need software make use of it. :-)

Michael

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 30 Jul 2011 10:44:05 -0500

Michael,
 
Jeff and I have both mentioned PORT and/or TERM80/ZT4.  There *is* software that makes
use of hardware handshaking.

> From: [email-masked]
> Date: Sat, 30 Jul 2011 15:41:25 +0000
> Subject: [TI994A] Re: RS232 hardware handshake can't work between two TIs
> 
> Hi Jeff,
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 30 Jul 2011 15:50:21 -0000

Hi Tim,
  
> Jeff and I have both mentioned PORT and/or TERM80/ZT4.  There *is* 
> software that makes use of hardware handshaking.

then I guess it's about time for me to try that, instead of playing around with MYTERM and TELCO. :-)

Where can I find a copy of PORT or TERM80/ZT4?

Michael

---

From: Jeffrey White <[email-masked]>
Date: Sat, 30 Jul 2011 16:50:47 -0700 (PDT)

ftp://ftp.whtech.com/geneve/mdos/port96.ark

Sent: Sat, July 30, 2011 11:50:21 AM

Hi Tim,

> software that makes use of hardware handshaking.

then I guess it's about time for me to try that, instead of playing around with 
MYTERM and TELCO. :-)

Michael

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 30 Jul 2011 22:10:49 -0500

Myterm and Telco are more polished than PORT.  As for file locations, check the WHT ftp 
site.  Happy hunting.  

> Date: Sat, 30 Jul 2011 15:50:21 +0000

---

From: "Michael Zapf" <[email-masked]>
Date: Sun, 31 Jul 2011 09:48:39 -0000

Hi Tim,

> Myterm and Telco are more polished than PORT.  As for file locations, check the WHT ftp 

(I should have looked before asking ... I have WhTech on a USB stick here. :-) )

OK, found the files & will try.

Don't have to be polished, I just need a way to verify the handshaking. I suspect a problem that has not even shown up yet because I have had not way of testing: The handshaking in the current implementation will fail because of the buffering in the socket connection and in the PC UART. There will be bytes in the queue even after stopping the sender. I think the serial bridge will have to mirror the handshaking behavior itself and not rely on the sender to stop sending instantly.

(Possibly all this stuff might be re-used outside of the emulation area for the purpose of remotely operating a serial port via network.)

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 01 Aug 2011 22:15:04 -0000

Hi there,

PORT is running OK, but I cannot make any use of the TERM80 files on WHTech, because they are "naked" ARK files, lacking a TIFILES header. Could someone export the TERM80 files in TIFILES format please? (Or give me a disk image?)

Michael

---

From: Jeffrey White <[email-masked]>
Date: Tue, 2 Aug 2011 14:58:15 -0700 (PDT)

IIRC, TERM80 uses 99/4A direct CRU keyboard scanning.  Some versions also can 
use Jeff Brown's interrupt mod board (described on Thierry's pages).

Attached is the shell script I wrote to create 4k, 6k, and 8k TIFILES headers 
for some type of file -- probably program image.  Why I needed this I do 
not recall exactly.

There is a disk file for Term80 at 
ftp://ftp.whtech.com/communications/term80.dsk 

Jeff White

Sent: Mon, August 1, 2011 6:15:04 PM

Hi there,

PORT is running OK, but I cannot make any use of the TERM80 files on WHTech, 
because they are "naked" ARK files, lacking a TIFILES header. Could someone 
export the TERM80 files in TIFILES format please? (Or give me a disk image?)

Michael

---

From: "Tursi" <[email-masked]>
Date: Tue, 2 Aug 2011 15:23:01 -0700

>PORT is running OK, but I cannot make any use of the TERM80 files on 
>WHTech, because they are "naked" ARK files, lacking a TIFILES header. Could 
> >someone export the TERM80 files in TIFILES format please? (Or give me a 
>disk image?)

Just as a note for people writing software that parses TI files on a PC file 
system, files without a TIFILES header by convention are intended to be 
treated as Display/Fixed 128. This is the same format that Archiver files 
are normally stored in, and is convenient for interworking with PC files, 
since it stores exactly two records per sector (IOW, no reformatting of the 
file is needed, it ends up on the TI disk just like the original file).

It looks like Archiver files are normally Internal/Fixed 128, though, so 
they should have a header. Of course, the only difference is a single byte 
in the TIFILES header (byte 10 - >02 for Internal/fixed, >00 for 
display/fixed). I tested it, though, and Archiver doesn't seem to parse the 
file correctly if it's DF128 instead of IF128.

---

From: "Tursi" <[email-masked]>
Date: Tue, 2 Aug 2011 15:56:45 -0700

>are normally stored in

Oi, just to correct my confusing message, this is NOT the format that 
Archiver files are normally stored in.

>they should have a header.

.. and this IS the format.

---

From: "Michael Zapf" <[email-masked]>
Date: Tue, 02 Aug 2011 23:19:27 -0000

Hi Tursi, 

thanks for the hint. For the sake of interoperability I wish we'd stay with a consistent use of TIFILES headers for all TI files on the PC. As this is always a 128 byte header this should not complicate things too much.

Michael

---

From: Jeffrey White <[email-masked]>
Date: Tue, 2 Aug 2011 16:57:00 -0700 (PDT)

There is an archive format that is DF128 -- the original Barry Traver Archiver.

Barry Boone added compression, and that archive format is IF128.

Jeff White

________________________________
From: Tursi <[email-masked]>
To: [email-masked]
Sent: Tue, August 2, 2011 6:56:45 PM
Subject: Re: [TI994A] Re: RS232 hardware handshake can't work between two TIs

---

From: "Tursi" <[email-masked]>
Date: Tue, 2 Aug 2011 19:37:55 -0700

>thanks for the hint. For the sake of interoperability I wish we'd stay with 
>a consistent use of TIFILES headers for all TI files on the PC. As this is 
>always
>a 128 byte header this should not complicate things too much.

If I may be so bold, if it's for the sake of interoperability, you should 
support the standard that has already been out there for 20+ years. :) For 
any other reason, okay, but not interoperability.

The reason for the lack of header is so that the TI can interwork with 
non-TI files without corrupting them. It's rare that it will cause you any 
issue, but discarding the old behavior may lead to increased confusion in 
the future, not less.

---

From: "Tursi" <[email-masked]>
Date: Tue, 2 Aug 2011 19:38:56 -0700

>Barry Boone added compression, and that archive format is IF128.

Ah ha! that's helpful, thanks for the clarification. :)

---

From: Insane Multitasker <[email-masked]>
Date: Tue, 2 Aug 2011 21:55:17 -0500

In a fair number of terminal emulators you will find an option to add the TIFILES header to DF128 files. As Tursi points out, the DF128 "standard" allows files interoperability, to a degree.  There is one instance where sending a DF128 TIFILES header has definite value: whenever a TI is receiving a "DF128" file. 
 
Reason: 
 
TI terminal emulators usually buffer and write 8K (32 sectors) at a crack.  However, if a TIFILES header is not received, most TI terminal emulators will perform record-based IO to the specified device.  Unbuffered DF128 record IO causes a DSR write every 2 records (2*128 bytes=256 bytes=1 TI sector).  Add to this the need for the DSR to allocate a new Allocation Unit (AU) & update the bitmap every time the sector-per-AU threshhold is met, and your file transfer speeds suffer tremendously.
 
A handful of programs will buffer the data then perform on-the-fly allocation at each buffer threshold.  This can be achieved by writing the last buffered record, then by resetting the record pointer to the first buffered record and dumping the remaining buffered data.  (PORT does this on 8K boundaries up to 64K).  
 
Tim

> Date: Tue, 2 Aug 2011 23:19:27 +0000

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 03 Aug 2011 10:09:40 -0000

Hi Tursi,

> any other reason, okay, but not interoperability.

Sure for interoperability. There may be more applications, emulations, and other tools on the PC, and it's much easier to handle TIFILES consistently instead of caring for one exception of a special format.

Being used for some time does not make a good standard per se. Situations and habits may change over time.

What if we just *suggest* to include the TIFILES header for all TI files stored outside?

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 03 Aug 2011 10:18:26 -0000

Whatever, I'll add an option to recreate the header in my tool. Should not be too difficult. 

Michael

---

From: "Tursi" <[email-masked]>
Date: Wed, 3 Aug 2011 03:25:36 -0700

>Sure for interoperability. There may be more applications, emulations, and 
>other tools on the PC, and it's much easier to handle TIFILES consistently 
> >instead of caring for one exception of a special format.

Whether that argument makes sense depends on whether you are creating a 
future or supporting the past.

I'm supporting the past, thus I have to support that behavior. That I agree 
with (and still make use of) the behavior just made it easier to decide. :)

>What if we just *suggest* to include the TIFILES header for all TI files 

Do we have to agree? I think it's a trivial thing to function like the 
actual TI did, and see no need to deprecate files just because they didn't 
need the header when they were transferred from a real machine. On the flip 
side of that same coin, there are probably precious few /actual/ TI files in 
that case, and those files having a TIFILES header doesn't hurt anything. ;)