tschak909 Posted January 17, 2019 Share Posted January 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 17, 2019 Share Posted January 17, 2019 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. Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 17, 2019 Share Posted January 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted January 17, 2019 Share Posted January 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 17, 2019 Author Share Posted January 17, 2019 How are you supposed to enable the port? -Thom Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted January 17, 2019 Share Posted January 17, 2019 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 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 17, 2019 Share Posted January 17, 2019 (edited) See: http://atariage.com/forums/topic/261650-nanopeb-v1-rs232 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 January 17, 2019 by FarmerPotato Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted January 17, 2019 Share Posted January 17, 2019 See: http://atariage.com/forums/topic/261650-nanopeb-v1-rs232 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 17, 2019 Author Share Posted January 17, 2019 // 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 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 18, 2019 Share Posted January 18, 2019 (edited) // 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 January 18, 2019 by InsaneMultitasker Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 18, 2019 Author Share Posted January 18, 2019 @insanemultitasker - do the rs232raw_ routines here, look okay? https://github.com/tursilion/libti99 -Thom Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 18, 2019 Share Posted January 18, 2019 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... Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 18, 2019 Author Share Posted January 18, 2019 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 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 18, 2019 Share Posted January 18, 2019 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 18, 2019 Author Share Posted January 18, 2019 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 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 18, 2019 Share Posted January 18, 2019 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 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted February 12, 2019 Share Posted February 12, 2019 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 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted February 12, 2019 Share Posted February 12, 2019 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 I wonder if Custodio just patched your code himself then. Greg 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 25, 2020 Share Posted June 25, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 25, 2020 Share Posted June 25, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 25, 2020 Share Posted June 25, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
JB Posted June 26, 2020 Share Posted June 26, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 27, 2020 Share Posted June 27, 2020 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 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 28, 2020 Share Posted June 28, 2020 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. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 28, 2020 Share Posted June 28, 2020 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.. 1 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.