Jump to content
Sign in to follow this  
tschak909

Using the RS232 DSR

Recommended Posts

I have some questions,

 

Apparently the NanoPEB v2 uses a 16550 for its UART, which means the 9902 routines will not work, understandable...

 

but the RS232 devices have a DSR...

 

How can i use this from TI GCC?

 

If I use this, how bad is the overhead? Will this impact overall performance? Understanding on this subject seems a bit thin, so I really need input. I am trying to make PLATOTerm work on as many TI systems as possible (even possibly going as far as rewriting it in GPL so it can run on unexpanded 16K consoles, but I digress...)

 

thoughts?

 

-Thom

Share this post


Link to post
Share on other sites

I have some questions,

 

Apparently the NanoPEB v2 uses a 16550 for its UART, which means the 9902 routines will not work, understandable...

 

but the RS232 devices have a DSR...

 

How can i use this from TI GCC?

 

If I use this, how bad is the overhead? Will this impact overall performance? Understanding on this subject seems a bit thin, so I really need input. I am trying to make PLATOTerm work on as many TI systems as possible (even possibly going as far as rewriting it in GPL so it can run on unexpanded 16K consoles, but I digress...)

 

thoughts?

 

-Thom

 

I am not up to speed with TI GCC yet (I only followed it for the shift left / shift right bug fix, that bit you hard too). Access to the DSR ROM is a DSRLNK call with a PAB structure.

 

Essentially the code can be the same as disk access via DSRLNK, just with "RS232.BA=2400.DA=8.PA=N" instead of "DSK1.SOMEFILE". Other than that, read/write flags and record parameters work according to TI's standard DSR behavior. Which was the good side of the whole DSR specification.

 

But calling the DSR is going to get you only so far. A bunch of us (myself included) started BBS software using BASIC to call the DSR and as soon as possible went to direct assembly access to the 9902 for character i.o.

On the input side, a DSR call will block, waiting for N characters or a carriage return, then miss chars between calls. The output direction should be ok.

 

(In my opinion, TI fixed all the problems with their DSR spec in the 1983 HexBus RS232 peripheral and it was usable from Basic. I found it quite versatile on the CC-40 Enhanced Basic with just OPEN, LINPUT and PRINT and I guess we would have seen some kid write a whole BBS in Extended Basic II on the 99/8, if TI had not killed it.)

 

 

I am game for locating the 16550 character i/o routines in the NanoPEB ROM, if Fred Kaal did not already reverse engineer them.

Share this post


Link to post
Share on other sites

A quick question or two as this was the first time I heard anything used the 16550 UART on the TI.

 

1. Is V2 still available for purchase new, or just Ebay resellers?

2. Who made it and wrote the DSR?

3. Are there many in existence?

4. Was there any terminal emulator software written for it or was it mainly for printer interface?

5. Is the V1 still available?

 

Trying to understand the history as this was not a device I had followed.

Beery

Share this post


Link to post
Share on other sites

A quick question or two as this was the first time I heard anything used the 16550 UART on the TI.

 

1. Is V2 still available for purchase new, or just Ebay resellers?

2. Who made it and wrote the DSR?

3. Are there many in existence?

4. Was there any terminal emulator software written for it or was it mainly for printer interface?

5. Is the V1 still available?

 

Trying to understand the history as this was not a device I had followed.

Beery

 

1- no he stopped making them as they were incompatible, if you have one you are one of the few

2- jamie, dude that made the nanopeb/cf7

3- eh.. that's a question for him.. i can ask him

4- CFHDXS is the only program that I know of that works with it (Fred Kaal)

5- the v1 is being sold.. i have 4 on arcadeshopper available now..

 

If it were me, I'd ignore the v2.. there's just not enough to bother. 9902 code for the TI/cc/myarc/other rs232 cards should work fine with all of them with the exception of the nanopeb which requires enabling the port before it will work..see tim

 

Greg

Share this post


Link to post
Share on other sites

How are you supposed to enable the port?

 

-Thom

 

Tim discusses this in the TIMXT thread but I assume accessing the DSR and enabling it.. even if you are reading it directly

 

Greg

Share this post


Link to post
Share on other sites
See:

How are you supposed to enable the port?

 

-Thom

 

    LI R12,>1300
    SBO 0 page in the dsr rom

* example. do your port 1 serial stuff now as usual
    LI R12,>1340
    TB  3      

    LI R12,>1300
    SBZ 0 page out the dsr rom

It is still >1300 right?

 

Other points from that thread summarized:
The nanoPEB v1 (9902) addresses the serial port as “RS232”, “RS232/1” and “SIO”. For some reason Jaime left out the “SIO” reference in some (all?) of the recent v1 releases. The nanoPEB v2 (16550) addresses the serial port as “COM1”, with none of the other monikers.
...lee

 

 

v1 with a 9902: requires the DSR to be paged in during RS232 operations by setting bit 0 at >1300. TI RS232 doesn't need it.
v2 with a 16550: these only have a COM device in the DSR.
I agree with Greg - unless you only have the v2 right now... just ignore them. I think I have a v2.

 

Edited by FarmerPotato

Share this post


Link to post
Share on other sites

 

See:

 

    LI R12,>1300
    SBO 0 page in the dsr rom

* example. do your port 1 serial stuff now as usual
    LI R12,>1340
    TB  3      

    LI R12,>1300
    SBZ 0 page out the dsr rom

It is still >1300 right?

 

Other points from that thread summarized:

 

v1 with a 9902: requires the DSR to be paged in during RS232 operations by setting bit 0 at >1300. TI RS232 doesn't need it.
v2 with a 16550: these only have a COM device in the DSR.
I agree with Greg - unless you only have the v2 right now... just ignore them. I think I have a v2.

 

 

 

it says on your ti colorbar screen.. nanopeb Vx

Share this post


Link to post
Share on other sites
// RS232 code for the TI-99/4A by Tursi
// You can copy this file and use it at will 

#include "rs232.h"

// turns off the card and the card LED
void rs232raw_activateCard(int card) {
    __asm__ (
        "mov %0,r12\n\tsbo 0\n\rsbo 7" : : "r"(card) : "r12"
    );
}

-Thom

Share this post


Link to post
Share on other sites
// RS232 code for the TI-99/4A by Tursi
// You can copy this file and use it at will 

#include "rs232.h"

// turns off the card and the card LED
void rs232raw_activateCard(int card) {
    __asm__ (
        "mov %0,r12\n\tsbo 0\n\rsbo 7" : : "r"(card) : "r12"
    );
}

-Thom

 

The comment is misleading; this code is for enabling/activating the RS232 port. Replace SBO with SBZ to disable/deactivate the card.

 

For the nanopeb you MUST enable the card before accessing it. Be sure you are not using a routine that turns the card off after use, which may lull you into thinking the card is on when it really isn't. For simplicity, just assume that the other RS232 cards also require you to enable them, and you'll be good to go.

 

Edit: After turning on the card, read the byte at 0x4000. It should be 0xAA when the card is on. this will at least tell you if the routine to enable the card is working as expected. Sometimes it is the simple things that trip us up in CRU land.

Edited by InsaneMultitasker

Share this post


Link to post
Share on other sites

Sorry, I don't have the bandwidth to look through all that code. If you share all of the specific routines/function names you are calling, I or some of the others here can probably double-check the routines for the right activation sequence. That said, if you call the activatecard routine before your read/write calls and deactivate after, seems to me you'd probably have success...

Share this post


Link to post
Share on other sites

ok, just wanted to make sure.

 

Does anyone have a TI BASIC program that I can type in to quickly get a terminal to test my RS232 sidecar?

 

-Thom

Share this post


Link to post
Share on other sites
10 OPEN #1:"RS232.BA=2400.PA=N.DA=8",UPDATE
20 INPUT #1:A$
30 NL$=CHR$(13)&CHR$(10)
40 PRINT #1:"HELLO SAILOR"&NL$
50 CLOSE #1

eliminate 20 if its not getting anywhere and put in a 50 GOTO 40

 

or try

10 OPEN #1:"RS232.BA=2400.PA=N.DA=8",UPDATE,DISPLAY,VARIABLE 1

This is from memory, I syntax checked it on my NanoPEB v1, but I can't find a DB9 serial cable.

 

You can substitute your baud rate in BA=2400 but I figure why not start slow.

Likewise PA=E.DA=7 would be 7 bits even parity . The TI RS232 checks two letters so you can write

10 OPEN #1:"RS232.BAUDRATE=2400.PARITY=N.DATABITS=8",UPDATE,DISPLAY,VARIABLE 1

but nobody does that.

 

Just for fun

10 OPEN #1:"RS232.BANANA=2400.PARTY=N.DANCE=8",UPDATE

Share this post


Link to post
Share on other sites

ok good, seems to work :) too bad you can't check if there is something in the buffer via the standard I/O routines..would make it easy to write a dirt simple terminal program"

-Thom

Share this post


Link to post
Share on other sites

FYI, to access the other port, change RS232 to RS232/2.

 

I checked my (1 year old) nanoPEB v1 and found these devices in the DSR ROM (devices on same line are aliases)

RS232, RS232/1

RS232/2

PIO, PIO/1

PIO/2

RS232/3

nanoPEB dsr

4000 aa01
4002 0000
4004 4010 power up list
4006 0000
4008 4016 dsr list
400a 0000
400c 406c interrupt
* power up header
4010 0000
4012 40f2
4014 0000
* dsr headers
4016 4020 link to next
4018 4164 address
401a 0552 name: 'RS232'
401c 5332
401e 3332

4020 402c link to next
4022 4164 address
4024 0752 name: 'RS232/1'
4026 5332
4028 3332
402a 2f31

402c 4038 link to next
402e 416a address
4030 0752 name: 'RS232/2'
4032 5332
4034 3332
4036 2f32

4038 4040 link to next
403a 4154 address
403c 0350 name: 'PIO'
403e 494f

4040 404a link to next
4042 4154 address
4044 0550 name: 'PIO/1'
4046 494f
4048 2f31

404a 4054
404c 415a
404e 0550 name: 'PIO/2'
4050 494f
4052 2f32

4054 4060
4056 4176
4058 0752 name: 'RS232/3'
405a 5332
405c 3332
405e 2f33

Share this post


Link to post
Share on other sites

 

I am game for locating the 16550 character i/o routines in the NanoPEB ROM, if Fred Kaal did not already reverse engineer them.

 

No sorry, I don't own a NanoPeb V2, I only have a V1. I have used a 16550 for one of my early DIY HDX devices though. If somebody has a nanoPeb ROM dump I can have a look.

 

Fred ;-)

Share this post


Link to post
Share on other sites

 

No sorry, I don't own a NanoPeb V2, I only have a V1. I have used a 16550 for one of my early DIY HDX devices though. If somebody has a nanoPeb ROM dump I can have a look.

 

Fred icon_winking.gif

 

I wonder if Custodio just patched your code himself then.

 

Greg

  • Like 1

Share this post


Link to post
Share on other sites

Programmable RS232 DSR ?

 

I didn't want to start another topic so I am putting this here.

 

I find the RS232 DSR code pretty useless for my (very tiny) world.  In a cooperative multi-tasking system blocks of code that don't yield when they are busy are very bad. :( 

This has meant that I ignore it and wrote my own driver.

After building and using a super cart it occurred to me that the RS232 might benefit from a battery backed-up RAM, letting the programmer load a driver that works for them.

 

Has this ever been done?

Any thoughts?

 

I must confess that thought of being able to compile a Forth driver into the card and/or blit a memory image into it when a program starts,  makes me salivate just a little. :) 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, TheBF said:

Programmable RS232 DSR ?

 

I didn't want to start another topic so I am putting this here.

 

I find the RS232 DSR code pretty useless for my (very tiny) world.  In a cooperative multi-tasking system blocks of code that don't yield when they are busy are very bad. :( 

This has meant that I ignore it and wrote my own driver.

After building and using a super cart it occurred to me that the RS232 might benefit from a battery backed-up RAM, letting the programmer load a driver that works for them.

 

Has this ever been done?

Any thoughts?

 

I must confess that thought of being able to compile a Forth driver into the card and/or blit a memory image into it when a program starts,  makes me salivate just a little. :) 

 

Sorta, yes.  MDOS on the Geneve uses it's master DSR and does not use the DSR on the card.  If you think you are going to go that route, you are going to need to support TI, Myarc, and CorComp.  The Geneve has a test routine to identify the cards I think Jeff White came up with years ago.

 

Beery

 

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, BeeryMiller said:

 

Sorta, yes.  MDOS on the Geneve uses it's master DSR and does not use the DSR on the card.  If you think you are going to go that route, you are going to need to support TI, Myarc, and CorComp.  The Geneve has a test routine to identify the cards I think Jeff White came up with years ago.

 

Beery

 

OK. Good to know. 

Supporting all those platforms is way outside my scope. 

It's not really a practical idea unless everyone gets a new RS232 card with the battery RAM.

I supposed it wouldn't be too much to write a loader or use some existing loader to allow others to use a card like this. (?)

 

For me it's about wasting memory in program space for the driver when there is address space devoted to the job on the card. 🥵

 

I understand the serial port cards are hard to come by now but it might be fun to mod a second card at CRU >1500 for this purpose.

It would certainly be the way to go for writing new DSRs for the card.

  • Like 1

Share this post


Link to post
Share on other sites
20 hours ago, TheBF said:

After building and using a super cart it occurred to me that the RS232 might benefit from a battery backed-up RAM, letting the programmer load a driver that works for them.

 

Has this ever been done?

Yeah. That was the HDX mod, if I'm not mistaken.

  • Like 2

Share this post


Link to post
Share on other sites

Yes the HDX MOD uses battery backed ram to load the DSR ROM for the RS232 card.. 

 

www.ti99-geek.nl/Projects/ti99hdx/ti99hdx.html

 

Share this post


Link to post
Share on other sites
8 hours ago, arcadeshopper said:

Yes the HDX MOD uses battery backed ram to load the DSR ROM for the RS232 card.. 

 

www.ti99-geek.nl/Projects/ti99hdx/ti99hdx.html

 

Thanks for the reply.  I notice you are out of those baby boards. Any thoughts on when another run will be made? I don't think I am going the HDX route for now.

I would like to try my crazy idea of putting my own RS232 driver on the board. 

It's easy to BLIT the original code from Forth so I can keep the bank switch idea if your board supports that functionality as I saw in the original project online.

Or if all else fails I can always put the ROM back. 

Share this post


Link to post
Share on other sites
1 minute ago, TheBF said:

Thanks for the reply.  I notice you are out of those baby boards. Any thoughts on when another run will be made? I don't think I am going the HDX route for now.

I would like to try my crazy idea of putting my own RS232 driver on the board. 

It's easy to BLIT the original code from Forth so I can keep the bank switch idea if your board supports that functionality as I saw in the original project online.

Or if all else fails I can always put the ROM back. 

thanks i have plenty i'll put them back in stock.. 

  • Thanks 1

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...