sjt Posted March 28, 2014 Share Posted March 28, 2014 Hi I just got a TI rs232. At this moment I don't even have a cable made up for it. I loaded the TI diagnostic into MiniMem. When selecting the RS232 test it shows a bit failure at 1302 I used easy bug, C1300 1 and the card doesn't turn on. It does turn on at C130E 1 Is this normal for the rs232 card ? Is there a better test? Steve Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted March 29, 2014 Share Posted March 29, 2014 Heya sjt - I too am having trouble with my hardware, and I'm not sure if it's the 32k expansion or the CorComp RS232. Is that diagnostic program on disk? If so I'd love to have a copy- I really would like to check out my machine and get a better idea what's wrong before I start my own thread. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 29, 2014 Share Posted March 29, 2014 (edited) Hi I just got a TI rs232. At this moment I don't even have a cable made up for it. I loaded the TI diagnostic into MiniMem. When selecting the RS232 test it shows a bit failure at 1302 I used easy bug, C1300 1 and the card doesn't turn on. It does turn on at C130E 1 Is this normal for the rs232 card ? Yes. The RS232 card uses bit 7 to control the LED. Unlike other cards, it does not light up when the DSR is active. Bit 7 at base 1300 is 130E. This also explains why nothing can be seen on the LED when setting 1300. I don't know what exactly is tested with the diagnostics. Maybe you should have a look at http://nouspikel.group.shef.ac.uk/ti99/rs232c.htm#CRU%20map which lists all bits with their meanings. Bit 1302 is used for PIO, not RS232. (Why is the forum software always messing up weblinks??) Edited March 29, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 30, 2014 Share Posted March 30, 2014 Heya sjt - I too am having trouble with my hardware, and I'm not sure if it's the 32k expansion or the CorComp RS232. Is that diagnostic program on disk? If so I'd love to have a copy- I really would like to check out my machine and get a better idea what's wrong before I start my own thread. Here is the TI Diagnostic Disk Set (3 total). You want the third disk for the utilities. NOTE: You really DO need Mini-Memory for the Diagnostics to work right. If you use Editor/Assembler and test the memory it will tell you it's bad. Use Mini-Memory! -Dano TI Diagnostics.zip 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 30, 2014 Share Posted March 30, 2014 Judging from the diagnostic tool and from the schematics, the CRU Bit error message may indeed indicate a defect 74LS259 latch or other issues on the signal path. The error message is printed on the screen when the bit value read via CRU differs from the bit value previously written on the same address. Concerning CRU operations, it is not guaranteed that you can read the bits that you previously wrote with SBZ/SBO/LDCR. The circuitry must allow for reading bits via CRU and giving them meaningful values. In this case, we can actually read the latches values. Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted March 30, 2014 Share Posted March 30, 2014 Here is the TI Diagnostic Disk Set (3 total). You want the third disk for the utilities. NOTE: You really DO need Mini-Memory for the Diagnostics to work right. If you use Editor/Assembler and test the memory it will tell you it's bad. Use Mini-Memory! -Dano Thanks Dano! I might be up the creek still for a moment since I don't have a minimemory . I really need to get to the bottom of this. Good luck stj in figuring out what's going on - there are a lot of helpful people here, so you should be good hands. Sorry I couldn't be much help . Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 30, 2014 Share Posted March 30, 2014 OK, there is one issue in the code: The reported CRU address is wrong. The bit it actually wants to complain about is 1304, not 1302, but as we see in the CRUERR block, it takes the R12 address, strips off the first 3 hex digits, moves the remainder to the high byte but divides by two: (0x1304 & 0x000f) << 7 This makes sense when you want to say: "Bit x", but they add the string "130" before (BASE). So if the address is actually 1304, we can see in the CRU map that this is the HANDSHAKEIN pin when reading, and doing a SBZ/SBO means to set the HANDSHAKEOUT (see Thierry's CRU map). I'd say this is not guaranteed to be equal. So maybe this is a false alarm. *** CRU BASE ROUTINE *** CRU INCT R12 SBO 0 TB 0 JNE CRUERR SBZ 0 TB 0 JEQ CRUERR CI R12,>130E JEQ PIO JMP CRU CRUERR LI R0,>169 LI R1,CRERR LI R2,11 BLWP @VMBW ANDI R12,>F SLA R12,7 LI R0,>1A9 LI R1,BASE LI R2,3 BLWP @VMBW MOVB R12,R1 AI R1,>3000 LI R0,>1AC BLWP @VSBW CRWAIT JMP CRWAIT 1 Quote Link to comment Share on other sites More sharing options...
sjt Posted March 30, 2014 Author Share Posted March 30, 2014 I Think I may have the answer here. My assumption is this test will fail on everyone's system attempting to test the TI card without a loop back cable mentioned but not described in one of the doc files uploaded here recently... Here is the paragraph: *RS232 INTERFACE TEST: THIS PROGRAM TESTS THE ROM AND BOTH THE SERIAL AND PARALLEL PORTS. THIS TEST REQUIRES A SPECIAL SERIAL TO PARALLEL CONNECTOR. IF AN ERROR IS DECTECTED, THE PROGRAM STOPS AND A DIAGNOSTIC ERROR MESSAGE IS DISPLAYED. {THE THREE PRECEDING PROGRAMS WERE WRITTEN IN A SONSTANT LOOP. THIS MEANS {THAT THE TESTING CONTINUES UNTIL AN ERROR IS DETECTED, THE UNIT IS TURNED {OFF, OR A QUIT IS PERFORMED. Note: The typos are theirs To verify this someone needs to load the program into minimem and try it on another system Meanwhile I need to find a description of how they wanted a cable to be wired for this test. Steve Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 30, 2014 Share Posted March 30, 2014 I think the only test that fails is the 32k test with Editor/Assembler. And possibly the Pcode Card test required the MM cartridge. The other tests seemed to work, although I noticed I had a lock up or two here and there before I realized that I needed to be doing this from MM. Once I switched to MM it, everything was stable. I'll try and see if I can build one of the special loop-back cables they are referring to and test it on my system. There is pretty substantial documentation so I'm hoping it's in there. I also have a failing RS232 card and woud like to fix it. My symptoms are; it keeps blowing away the TL084CN (Quad JFET OpAmp) chip. Not sure why or how to trouble-shoot that. I have an oscilloscope and hopefully a logic analyzer soon. But even once I get those, I'm not sure how to logically narrow down the problem. Anyone have some steps for me to take? TIA! -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 30, 2014 Share Posted March 30, 2014 Thanks Dano! I might be up the creek still for a moment since I don't have a minimemory . I really need to get to the bottom of this. Good luck stj in figuring out what's going on - there are a lot of helpful people here, so you should be good hands. Sorry I couldn't be much help . Ok, so I just re-tested the TI Diagnostic disks to make sure I wasn't misleading anyone. 32k Test fails with Editor/Assembler - Works with MiniMem. However, you can run a "EXPANSION BOX TEST" if you utilize Disk 0291A.DSK and run it from Extended Basic. Definitely not as informative as the tools from disk 0291B.DSK & MM. Be sure to rename the TI disk 0291A.DSK as "TEST". The XB loader is referencing the disk by label name only. Don't know if that will shed any light on your 32k memory problem on your other post or not but, at least it doesn't require MiniMemory. -Dano 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 30, 2014 Share Posted March 30, 2014 The diagnostic program cannot run with Editor/Assembler because of AORG >7120 at the beginning of the file. Unless, of course, you somehow installed RAM at that location. I'd expect that loading seems to work, but the console will lock up on start or do other weird things. The REF/DEF table will be updated, but points into the void. If you remove that line or do a AORG >A000 there is some hope that you can assemble it for E/A as usual, and it may run. Take care of the memory test routine; it must not overwrite the test program. Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted March 30, 2014 Share Posted March 30, 2014 Ok, so I just re-tested the TI Diagnostic disks to make sure I wasn't misleading anyone. 32k Test fails with Editor/Assembler - Works with MiniMem. However, you can run a "EXPANSION BOX TEST" if you utilize Disk 0291A.DSK and run it from Extended Basic. Definitely not as informative as the tools from disk 0291B.DSK & MM. Be sure to rename the TI disk 0291A.DSK as "TEST". The XB loader is referencing the disk by label name only. Don't know if that will shed any light on your 32k memory problem on your other post or not but, at least it doesn't require MiniMemory. -Dano Thanks Dano! I will give this a shot this evening . Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted March 31, 2014 Share Posted March 31, 2014 O.K. I gave disk 0291A.dsk a shot (of course after renaming it to 'TEST'). The box tested as good. Unfortunately there is no diagnostic for the 32k memory itself, but the PEB is good, according to the test. Quote Link to comment Share on other sites More sharing options...
sjt Posted March 31, 2014 Author Share Posted March 31, 2014 Ok...we seem to have gotten away from testing the RS232 card using the Mini Mem utility supplied by TI to the user groups. Here is the answer as to what is needed to make that test work. It took a bit of hunting, but I found it. I will post a photo of it when it's built. I don't have a 16 pin idc connector around for the PIO portion. I may just construct it to plug directly into the serial port and add a ribbon to connect the pio port. See the attached Schematic. I didn't see a way to embed the photo here, I'm attaching it in hopes it will be viewable. There are just a few parts needed. I will post a list once I have it assembled and tested. I think there are 6 Leds, 1 resistor, 1 Transistor, and a resistor pack (that can be subbed by individual resistors) throw in some hookup wire, and few connectors to the whole thing. Steve 4 Quote Link to comment Share on other sites More sharing options...
sjt Posted April 21, 2014 Author Share Posted April 21, 2014 (edited) I built the test jig. To run with the diagnostic. I found the test never gets far enough to use it. It stops with a CRU arror at 1302. When I try and write to C1300,C1301 I can't change the values (using easy bug) I can change the value at 1302 however. There some other addresses i can't change in addition in the 1300---> 130e block. Trying to determine if there is an actual fault on the rs232 card or not, according to the test the answer is yes. If someone with a mini mem cart could load the TI mini mem menu diagnostic. I can upload the file if needed. Then in easy bug C 1300 (enter) change values Edited April 21, 2014 by sjt Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 21, 2014 Share Posted April 21, 2014 Hi I just got a TI rs232. At this moment I don't even have a cable made up for it. I loaded the TI diagnostic into MiniMem. When selecting the RS232 test it shows a bit failure at 1302 I used easy bug, C1300 1 and the card doesn't turn on. It does turn on at C130E 1 Is this normal for the rs232 card ? This is normal. It is possible that the "failure" is indicative of being unable to sense the PIO port being in input vs. output mode. (1302 controls PIO direction). Curiosity time: are you trying to run these tests because the card doesn't work or simply to try out the test program? I think you may be giving yourself a bit of a headache for little reason (IMHO). Do you have a cable to connect the RS232 to a modem or PC? Quote Link to comment Share on other sites More sharing options...
sjt Posted April 21, 2014 Author Share Posted April 21, 2014 That is an interesting take. I was testing the card since I didn't have anything to connect it to, and it and was just purchased. It seemed like a simple way to test it, to be sure it was working. I actually have built the hardware to connect tot he card to simulated the rs232 port, I just hadn't added the PIO part of it. I will and try the test again. I was hoping someone could help me get to the bottom by just loading and testing another rs232 card on another system. So far no one stepped up. Without the test fixture if it tested the same way i would have my answer. Steve Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 21, 2014 Share Posted April 21, 2014 I built the test jig. To run with the diagnostic. I found the test never gets far enough to use it. It stops with a CRU arror at 1302. When I try and write to C1300,C1301 I can't change the values (using easy bug) I can change the value at 1302 however. There some other addresses i can't change in addition in the 1300---> 130e block. As I said above (#7), the reported address is wrong. The problem actually occurs on the 1304 address (HANDSHAKEOUT/IN). If you set the 1302 address, this is the one that Diagnostics also found as good (but falsely calls it 1301). When you write to 1300 you turn on the DSR. When you read that value you will always get 0 (according to Thierry's description). The same is true for 1301, since the CRU address space only knows even addresses (means, 1300=1301). Actually, if you connect pins 1 and 10 of the PIO, the test should succeed. If everything is OK. Quote Link to comment Share on other sites More sharing options...
sjt Posted April 21, 2014 Author Share Posted April 21, 2014 Thanks for the reply. I had built half of the TI factory test jig (the rs232 side). I will complete the PIO side of it and try the test again. It's sad that I don't even have a PIO printer anymore to try this with real hardware at this time. Thanks for explaining that CRU addresses are only even. I wondered about that as well on easy bug. Steve Quote Link to comment Share on other sites More sharing options...
Ed in SoDak Posted April 22, 2014 Share Posted April 22, 2014 I have a TI setup with MM and TI RS232 + 32k so I took a shot at using Dano's zip of the Diagnostic disks, but couldn't get them into native TI format to run the tests. Or open them via FIAD Extractor, for that matter. I can handle V9T9 dsk or FIAD or a TI ArcIII file or zip of Arcs ready for me to send by xmodem. Quote Link to comment Share on other sites More sharing options...
Space Centurion Posted May 6, 2014 Share Posted May 6, 2014 (edited) Hi all, I've been having the same 1302 error too, and after reading some of the posts I'd thought I'd experiment a bit. Made some progress, but it is not fully working yet. I want to try and tele-bbs with the TI, so I've been BBS server, similar to TCPSER, but GUI based. Works well on my Commodores and Atari 1040ST. I am also using the TELCO communication program, if that helps. Anyways, there was no response to the BBS server, and I even tried a modem, same thing. But I did notice that when I tried to type anything, the card would blink with the keystrokes, as if it was at least processing the requests. I opened the card and took a good look at it, and noticed that the heat sink compound on the regulators had dried up. I got to thinking that perhaps they were not working well anymore, and may not be supplying enough volts for some chips. Someone mentioned it might be the 74ls259 chip, which needs 4.7v min. So, I replaced both the 7805 and 7812, added some new heat sink compound, and tried it with the diagnostic. Still failed....lol.... So I replaced the 74LS259. Still failed. But, I figured lets try it again with the modems....got some LEDs to light up this time.Sadly, I did not test the modems after I replaced the regulators, so it may just be them and not the chip. Anyways...it would not respond to AT commands though. I did notice something while using the BBS Server, if I set the Telco program to local echo and half duplex, it would repeat the keys as I typed, but it would repeat them continually. Example, ATZ would start off with.... aaaaaaaaaaaaaaaaaaaaaa(then I hit T)atatatatatatatatatatatatatatatatat(then z)atzatzatzatzatzatz....and it would fill the screen. Once I hit return, the cursor would start stay on the same line, but jump back and forth with the characters. Not sure if this info helps anyone, but there is hope on the horizon! I am going to replace the caps in the next few days, see what that does. If I can ask, what communication programs are being used out there successfully to connect to other tele-bbs's? Maybe it's the program too? And before any asks about the BBS Server....here is the link... http://www.jammingsignal.com/leif/bbs/ If anyone else has any ideas, or further guidance, let us know!!! Edited May 6, 2014 by Space Centurion Quote Link to comment Share on other sites More sharing options...
Ed in SoDak Posted May 6, 2014 Share Posted May 6, 2014 (edited) I have the working TI hardware, but I don't have the Diagnostic software to do these specific tests. If we can get that dealt with, I'll try to help. Maybe a TIFILES Archive of the needed program(s) would be easiest to get to me to transfer to my TI for testing? I use Telco myself for connecting my TI to my Macs. Used my TI online a lot many years ago and also set up a BBS as a way to get files from it to various computers at work. You get the endless echo key repeats when your terminal settings are not playing well with the host system. Try Full Duplex and Local Echo. The TI's RS232 signal wires are reversed compared to the PC. Since the signal wires are already swapped, if you're using an off-the-shelf Null Modem cable that might work on another system and try it on your TI, they may not talk to one another, which leads you to try terminal settings and around you go till it's all sorted out. You may need to make sure the cable you're using will work on a TI. I custom-made my null-modem using the published pinouts, which I had to anyway, as the Mac used non-PC connectors. I think I also did the same when I used a modem on it, hardwired my own connectors to a ribbon cable. Edited May 6, 2014 by Ed in SoDak Quote Link to comment Share on other sites More sharing options...
Space Centurion Posted May 6, 2014 Share Posted May 6, 2014 "Cantstopclicking" posted a diagnostic zip file in message #4 here. I am going to look into the null modem pins in a few minutes. If it helps anyone, I found the schematics for the card.... http://www.mainbyte.com/ti99/schematic/rs232_new_1.jpg http://www.mainbyte.com/ti99/schematic/rs232_new_2.jpg Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted May 6, 2014 Share Posted May 6, 2014 A note about TELCO. Using TELCO between two TI's (one emulated the other real), I have found that "Tibbs Xmodem" is the protocol to use. Quote Link to comment Share on other sites More sharing options...
Ed in SoDak Posted May 13, 2014 Share Posted May 13, 2014 With a known working RS232, I got the indentical results as listed in post #1. Maybe not proof of much, but at least your card and mine behave the same on this test. -Ed 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.