MAME and Geneve/TI Serial Interface

[+9640News]

Michael and/or Tim,

 

A question regarding the use of tiimagetool and the serial bridge interface to MAME. I am trying to determine what kind of serial interface will give me similar capability with PORT for the Geneve and other TI terminal emulators.

 

Specifically, I would like to be able to interface either the Lantronix UDS-10 or the WiModem232 to the emulation of the TI or Geneve with all the handshaking these programs have.

 

I'm thinking a USB serial cable with a 9 pin connector will not be suitable as it will not carry all the necessary pinouts?

 

Rather, I am thinking I will need a PCI Express card for my PC and the ones I am seeing have a DB-9. I just want to make sure all the necessary pinouts are present.

 

What I am wanting to do is to do my software development on the Emulation side of things where I have more reliability with the source code for backup.

 

Any feedback would be appreciated.

​Beery

[+mizapf]

Despite all my efforts, a reliable hardware handshaking seems impossible. Or I just did not get the right idea yet.

 

Read this here: https://www.ninerpedia.org/wiki/MESS_Serial_connection#Polling

(Polling and Handshaking Issues)

[Shift838]

As Michael said he has not been able to get the Handshaking to work correctly. Remember though, I am using it with my BBS and a UDS10 without the handshaking and it is solid at 38400bps.

[+InsaneMultitasker]

Despite all my efforts, a reliable hardware handshaking seems impossible. Or I just did not get the right idea yet.

 

Read this here: https://www.ninerpedia.org/wiki/MESS_Serial_connection#Polling

(Polling and Handshaking Issues)

 

I wonder if you aren't being too stringent in your application of the handshake signals.

 

I think of handshaking in terms of my kitchen faucet, the sink, the drain, and the drain plug. If I turn on the faucet, water streams into the sink at a certain rate. If water is dispensed faster than the drain can remove it from the sink (the drain pipe is small or the drain plug is covering the hole) the sink will eventually overflow. I can turn the faucet off to prevent this. However, there is still some residual water that comes out of the spout before the flow stops completely, so I must take care to turn off the water before the sink overflows.

 

In the same manner the hardware handshaking lines (faucet and drain plug) allow water to flow into the sink (faucet) or out of the sink (drain). When you change RTS/CTS state, the computer is telling the modem to stop sending data or the modem is telling the computer to stop sending data. The data capture routines on either side should watch for any remaining character(s) and retrieve them and the sending routines should test the handshake line prior to transmitting. Much like the faucet and the sink, you still need to capture any residual data and store it in the buffer. A debounce period equal to 5-10 characters at the current baud rate may be sufficient, though it really depends on the system the modem and the speed.

 

For the serial bridge application I suppose it is also dependent upon how the data is packetized. The serial bridge is slightly slower and less immediate in its character sends/receives. Seems to me that when implementing hardware handshaking in the bridge, any characters before the handshake line state changes should be sent across the bridge and the receiving program should check for them, buffer them, and process them as part of the handshake process. Buffer them temporarily in your serial bridge, much like a modem would do.

[+mizapf]

Hi Tim,

 

the problem is there because the applications may assume to exert an immediate effect on the transmission, since it is not buffered on the TI. If you design the applications to consider that, then we don't have the issues, right.

 

I spent my thoughts on that point *after* I found out by experiment that I could not prevent a byte loss. (I may be stringent at times, but at least I wait until my code fails. ) I wrote a program that sent bytes over the link, and a second one that received them. The receiver was designed to choke the transmission at every 1000 bytes. Since the emulated and the real TI interface do not know about a buffer in their connection, they don't know that there may be bytes in some buffer and will not request them. But anyway, since the buffer does not know that the receiver is not listening, it will not hold back the bytes. In the emulation, and in the implementation of the serial bridge, if there are bytes in the buffer, they will be sent and cause an overflow in the receiving UART.

 

To rescue the concept, I considered stopping the buffer when a handshake signal is sent by the receiver. However, this is not a safe way either: I cannot relate the buffered bytes to the handshake signal (i.e. I don't know the position in the buffer where the handshake signal belongs to).

[+InsaneMultitasker]

I'm not sure what you mean by "Since the emulated and the real TI interface do not know about a buffer in their connection,"

 

The TI doesn't know that any device is buffering data - whether that is a modem or serial bridge or direct connection. The receiving TI should assert the signal to stop the flow of data, then check for any residual before assuming all data has been received. The sending TI should test the proper signal before transmitting anything, which when delayed may result in the transmission of one or more bytes. So yes, you may still have bytes being sent AND bytes that need to be received after the signal to pause is sent. It seems to me that you could/should propagate the signals and pass the data through, and allow the terminal emulator to handle it. I guess it is slightly more complicate with the bridge but I'd say it should be do-able. None of this will work with a program like Telco; you'll need ZT4/Term80 or PORT. I believe both are written in the manner I describe.

[+mizapf]

The receiving TI should assert the signal to stop the flow of data, then check for any residual before assuming all data has been received.

 

Yes, this is a sane good behavior to prevent the data loss. My test tool was designed not to do that but to bluntly assume that stop means stop, now (just finish the current transmission of the byte). In the case of a communication via a null-modem cable and TMS9902 at both ends (which cannot buffer incoming data), this would be possible, and this is where my concept fails.

 

But as I said, if you assume that there may still be bytes on their way, the handshaking of the serial bridge should work as expected.

 

Edit: If you use RTS/CTS for handshaking, it actually does not make sense to wait for residual bytes, since the line turns off the transmitter in the sending chip (unlike DSR/DTR which trigger an interrupt) - according to the specifications. If you pull down CTS, you mute the sender effectively.

Edited January 30, 2018 by mizapf

[+InsaneMultitasker]

I suppose it would be better if I/we had selected either the case with a modem or the case with a direct connection. The residual bytes do appear with a modem in the middle. I do not recall ever seeing them appear with a direct connection since the sender is expected to test the state before transmitting. This can happen by turning off the transmitter or by checking the signal.

 

To partially answer Beery's question, I would think a 9-pin USB serial port will work just fine but I don't have much experience using the serial bridge.

[Shift838]

I suppose it would be better if I/we had selected either the case with a modem or the case with a direct connection. The residual bytes do appear with a modem in the middle. I do not recall ever seeing them appear with a direct connection since the sender is expected to test the state before transmitting. This can happen by turning off the transmitter or by checking the signal.

 

To partially answer Beery's question, I would think a 9-pin USB serial port will work just fine but I don't have much experience using the serial bridge.

 

 

I use a 9 pin USB Serial myself with Michaels Serial bridge and it works good.

[+mizapf]

I suppose it would be better if I/we had selected either the case with a modem or the case with a direct connection.

 

Yes, that matters for sure. The hardware handshake should only be effective between host and modem, not between the modems, unless someone invented a way to encode a DSR/DTR signal. Handshaking over the distance is certainly possible with XON/XOFF (which are transmitted by the modems).

 

I did my tests between the emulated Geneve via serial bridge and the real Geneve, connected by a null-modem cable. I was not very amused when all work was done and the tests failed, and it showed that this was a flaw in the concept. But it is still useful enough, I guess.