Jump to content
IGNORED

libti99 rs232_writebyte not sending...


tschak909

Recommended Posts

I'm currently trying to get RS232 support up and running in the TI99/4A version of PLATOTerm...

 

I am receiving data, however, transmitting data doesn't seem to be happening, despite me calling it correctly (activating the card, getting the cru from the uart, and calling writebyte), does anyone see an issue with the following code?

// RS232 code for the TI-99/4A by Tursi
// You can copy this file and use it at will 

#include "rs232.h"

// writes a byte to the specified serial port - does not check the transmission register!
// this does manipulate RTS/DCD since everyone does 
void rs232raw_writebyte(int rawCRU, int ch) {
    __asm__ (
        "  mov %0,r12\n"        // get rawCRU
        "  sbo 16\n"            // set RTS low (this is what the card and FlipSide did...? maybe enables the write?)
        "  swpb %1\n"           // get the value into the MSB
        "  ldcr %1,8\n"         // write the byte
        "  sbz 16\n"            // set RTS high (will happen after transmission)
        "  swpb %1\n"           // fix the reg in case gcc wants it
        : : "r" (rawCRU), "r" (ch) : "r12"
    );
}

Am ultimately asking for help because Tursi of course has his hands full with real life, and I know there is at least one or two people on this forum with the requisite experience in talking to the RS232 card... :/

 

-Thom

Link to comment
Share on other sites

Oh yes.

 

I have tiimagetool connected to a com0com port (COM8), where the other side of the com0com is connected to a tcpser instance running on COM7. This setup works in my other test harnesses for other systems.

 

I can receive, and the baud rate and line parameters are being set correctly, I just don't seem to be transmitting.

 

The one major setting in mame is for pin assignment, which there are three options, 5-20, 6-20, and 8-20, I am currently set to 8-20...

 

-Thom

Link to comment
Share on other sites

yes:

// CRU addresses
// standard card
#define RS232_CARD              (0x1300)        // base CRU for the card
// alternate card
#define RS232_ALT_CARD  (0x1500)

// TMS9902 CRU offsets
#define RS232_9902A             (0x0040)        // base CRU of the first UART
#define RS232_9902B             (0x0080)        // base CRU of the second UART


I do wonder if the data sent back is potentially aligned properly..my PLATO routines expect 8-bit bytes for input and output, while:

// RS232 code for the TI-99/4A by Tursi
// You can copy this file and use it at will 

#include "rs232.h"

// reads a byte from the specified serial port - whatever is there. Does not check or
// block, so if you need correct data do a poll first!
int rs232raw_readbyte(int rawCRU) {
    int ret;

    __asm__ (
        "  mov %1,r12\n"        // get rawCRU
        "  clr %0\n"            // clear rx register
        "  stcr %0,8\n"         // get byte
        "  swpb %0\n"           // make LSB
        "  sbz 18\n"            // reset rx flag
        "  swpb %0\n"           // fix the reg in case gcc wants it
        : "=rm" (ret) : "r" (rawCRU) : "r12"
    );

    return ret;
}

When the data shows up in the receive register, is it LSB aligned?

 

-Thom

Link to comment
Share on other sites

You are showing the definitions for the RS232 base and ports; I am asking if you know that what is passed to writebyte is in fact 0x1340.

 

In assembly, the written character will be in the MSByte. Looks like the byte order is swapped twice in the inline assembler code so unless I am misreading it, the returned value would be in the MSByte. (edit: see post#1 for the writebyte routine; post #7 contains readbyte; did you solve the transmit issue?)

 

The raw routine does not validate whether or not the port is ready to transmit. It is simply dumping the character to the RS232. Typically, when the transmitter signals it is not ready, it will 'freeze' the system when you try to transmit the 2nd byte. This usually indicates a cable configuration issue as noted by Stuart a few posts earlier.

 

Can you test your mess configuration with a TI terminal program? Might be helpful to troubleshoot the serial IO with something like Telco or Mass Transfer, as they are both simple programs that do not use any flow control, only 'standard' signaling. Might help you determine whether your program or MESS/serial bridge or the rs232 library is the problem.

Edited by InsaneMultitasker
Link to comment
Share on other sites

Found an old thread with what appears to be a Telco disk image. Mount to DSK1. It might auto-start with Extended BASIC or by using Editor Assembler option #5 to load DSK1.TELCO. Some of the other programs are probably in other threads or the WHT ftp server.

 

 

http://atariage.com/forums/topic/237508-lantronix-hook-up/?do=findComment&comment=3224057

Link to comment
Share on other sites

Yeah, the raw function is just that - the raw function that reads or writes the byte. Software is generally expected to call the non-raw functions, which do the status checks, unless the developer has taken care of those themselves (for instance, for performance reasons, since the non-raw ones turn the card on and off and check the bits for every byte, software might want to batch operations in a single CRU enable, for instance).

 

Unfortunately I've not had any time to test these functions, I wrote them for tschak based on my really, really old BBS functions, but since Classic99 doesn't support serial I didn't have a quick way to validate them. Thanks to everyone who is taking a peek and trying to help.

 

tschak, maybe it would be worth just writing a bare-minimum piece of code that reads and writes the same way you are doing so in your port, that would be small enough for us to step through and see if either you or I messed something up. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...