Accessing RS232 via C in gcc/libti99

[tschak909]

Hey guys,

 

Now that I've got PLATOTerm successfully brought up on the 99/4A and displaying and decoding protocol data correctly, I need to wire in RS232 support. Could somebody well versed help out in what I need to be able to make an RS232 solution that would work reasonably well for most users?

 

-Thom

[+Lee Stewart]

Redirected from Need-linedot-drawing-facilities-for-ti99-gcc, post #23:

 

... Then your next hurdle, is that everyone who as accessed RS232 for terminal programs has done it in assembly... You'll invariably have to get dirty with inline assembly or some assembly modules in your program anyway... I believe the RS232 byte level access is going to involve a bunch of CRU bit manipulation.. but I've never done it... and I don't know where the reference material for that particular bit is. ...

 

-M@

 

FYI, here, on Thierry’s site, is the CRU map of the TMS9902 chips on the RS232 card.

 

...lee

[tschak909]

I'm not a TI guy. This is literally the VERY first piece of software that I've done for the platform, and I'm only doing it just so I can bring this piece of software to the community.

 

-Thom

[tschak909]

What am basically saying is, either:

 

(a) somebody write some routines, or

(b) I need a chalk-talk on TI I/O.

 

-Thom

[+InsaneMultitasker]

Sending and receiving via the serial port is not that difficult; however, TI's implementation of the RS232 leaves much to be desired.

 

Most of our terminal emulators rely upon the built-in RS232 interrupt-driven buffer mechanism, which is limited to max speed of about 4800bps, has a 1-byte serial buffer, and a 255 byte video ram based circular buffer. A second option is to settle on some sort of handshaking/polling routine, where you enable reception, capture a set number of bytes, then disable reception - rinse, lather, repeat. A third option is to constantly poll the RS232 port but unless there is some sort of packet control (e.g., an Xmodem file transfer or http request) you'll drop a lot of characters.

 

What are the basic requirements for the terminal in terms of min/max baud rate, parity, data bits, stop bits? And how is the data controlled/sent/received? That may help sort out which option(s) would be suitable for RS232.

 

Is TIPI support an option? I don't know if there is a tipi library you can reference but it certainly seems (to me) that it could be easier to implement.

[tschak909]

It's not about being easier to implement, I am trying to implement methods that will work for the majority of TI 99/4A users with suitable connectivity.

 

The PLATO service was optimized to run at about 1200bps, but of course runs better with faster speeds.

 

WIFI modems have CTS/RTS handshaking typically, so if enabled and the system can properly assert them, then you have a modicum of flow control.

 

PLATO does support XON and XOFF flow control, and my protocol decoder does enable it, however, the vast asymmetry of the transmission speed of the source TCP port makes this option completely untenable.

 

Just set the modem to say, 1200bps, No parity, 8 data bits, one stop bit, and the protocol decoder in PLATOTerm will automatically strip parity as needed.

 

Essentially, the most common use case on other systems is a WIFI modem connected via RS232 to the computer, and handling the TCP connection to IRATA.ONLINE.

 

TIPI would be nice, but there is NO emulation, and I don't know how many #@)$%@# times I have to say this, I do not have actual hardware to work on TIPI support, and the response I get from Gregory & Co. is "Buy a TI and buy one of my TIPIs" as if I had the money. sigh.

 

-Thom

[+InsaneMultitasker]

It's not about being easier to implement, I am trying to implement methods that will work for the majority of TI 99/4A users with suitable connectivity.

 

The PLATO service was optimized to run at about 1200bps, but of course runs better with faster speeds.

 

WIFI modems have CTS/RTS handshaking typically, so if enabled and the system can properly assert them, then you have a modicum of flow control.

 

PLATO does support XON and XOFF flow control, and my protocol decoder does enable it, however, the vast asymmetry of the transmission speed of the source TCP port makes this option completely untenable.

 

Just set the modem to say, 1200bps, No parity, 8 data bits, one stop bit, and the protocol decoder in PLATOTerm will automatically strip parity as needed.

 

Essentially, the most common use case on other systems is a WIFI modem connected via RS232 to the computer, and handling the TCP connection to IRATA.ONLINE.

 

TIPI would be nice, but there is NO emulation, and I don't know how many #@)$%@# times I have to say this, I do not have actual hardware to work on TIPI support,

-Thom

Understood. My comments were based on the fact that our RS232 has limited emulation support, so implementing a TIPI connection in C might be easier to program and troubleshoot given you don't have either hardware device.

 

Since the RS232 connections would be through wimodem or wifimodem or UDS type device, handshaking seems like an appropriate choice for serial support. The routines would be relatively self-contained and not require any interrupt nonsense, which for all I know wouldn't even play well with C.

 

Beery might have some serial handshake code that would work well for the three basic modules you would need: (1) set up the RS232 (2) receive a block of data with thresholds and debounce timeout and (3) send a byte of data. I don't have access to my own code at present or I'd scrape out a few routines for you to stub into the C code.

[+arcadeshopper]

It's not about being easier to implement, I am trying to implement methods that will work for the majority of TI 99/4A users with suitable connectivity.

 

The PLATO service was optimized to run at about 1200bps, but of course runs better with faster speeds.

 

WIFI modems have CTS/RTS handshaking typically, so if enabled and the system can properly assert them, then you have a modicum of flow control.

 

PLATO does support XON and XOFF flow control, and my protocol decoder does enable it, however, the vast asymmetry of the transmission speed of the source TCP port makes this option completely untenable.

 

Just set the modem to say, 1200bps, No parity, 8 data bits, one stop bit, and the protocol decoder in PLATOTerm will automatically strip parity as needed.

 

Essentially, the most common use case on other systems is a WIFI modem connected via RS232 to the computer, and handling the TCP connection to IRATA.ONLINE.

 

TIPI would be nice, but there is NO emulation, and I don't know how many #@)$%@# times I have to say this, I do not have actual hardware to work on TIPI support, and the response I get from Gregory & Co. is "Buy a TI and buy one of my TIPIs" as if I had the money. sigh.

 

-Thom

 

Hey now.. I also offered to TEST ANYTHING YOU LIKE ON REAL HARDWARE and have done so on three occasions for you. right?

 

I also can't loan you a TIPI as there's no spare one, just what we have built for the beta test and the people purchasing them. I don't have a box of them sitting around as those would have been sold too. I said I'd be happy to sell you what you need and that means when I have one in stock to sell. They are all sold faster than we can make them.

 

Emulation is probably easy to add if someone wants to do the work it will require a interface to python on the PC.. In fact the author of Classic99 has a tipi in hand (that he purchased) but he's probably too busy with his real job to even plug it in.

 

Reality is the telnet code is in the github repo for tipi, its tested and solid.. and I'm here to test (as well as 3-4 other TIPI owners) when you get something that will possibly work on hw.

[Tursi]

Emulation is probably easy to add if someone wants to do the work it will require a interface to python on the PC.. In fact the author of Classic99 has a tipi in hand (that he purchased) but he's probably too busy with his real job to even plug it in.

 

With apologies, this is true. I've gotten as far as placing the TI on a table. No cables or monitor yet. :/ I expect to be finished my current mad death march this month, one way or the other.

[+jedimatt42]

Patience is often rewarded. Settle... this is a forum, not a live chat. It's been 30 years... no one is in a race. There really isn't a lot of room for anything that needs to be done tomorrow. Anyone asking for help needs to be prepared to accept that an answer, or the help they need may not come right away... we all have our own priorities.

 

I've seen your TIPI code, and it smelled fine... but I haven't had more time to build, test, or debug it. I haven't even had time to read all of the communications you've generated.

 

You could stub tipi_msg code out, and have the same signature provide the blocks from your byte stream, or write an interface to the way you want to connect and collect data, and then just drop it off, let one of us make it work with TIPI or other real hardware once we actually have the time to invest, meanwhile, carry on with one of the other platforms you have on your rather ambitious list.

 

-M@

[tschak909]

Yeah, it's all good.

 

To bring transparency into what I'm doing:

 

I have 12 of these terminals I am writing, and I am doing them all in parallel. So if I am blocked in one, I simply move to another, and that strategy has paid off very well, as there are now 4 working targets.

 

It just so happened, that a whole lot of things fell into place in just the right way to make a significant amount of headway towards the TI client, and I hit a long stride.

 

I have the TIPI stuff happening in its own branch, and the RS232 stuff will happen in its own branch, and this will give me an idea of how to refactor to make it cleaner (I say this because on some systems function pointers are expensive, so I have to be clever in some cases, I have to see what works well)

 

Apologies if I'm coming off too intense. This is how I am, and I have a _very_ specific mission that I'm doing here. Please nobody take it personally.

 

-Thom