+FarmerPotato Posted January 5, 2021 Author Share Posted January 5, 2021 On 1/2/2021 at 5:03 AM, pnr said: Happy to hear that you found the problem. Well, it is not solved. I can sample SERENA* with the hi-Z analog probe or digital probe. As soon as I connect a gate input, it fails. Both LS and HCT. The driver is an ALS138A output (decoding the IO bus state and A14:13). As far as I can tell, it should be compatible. My last ideas are 1. try a buffer on breadboard, see if it has the same issue with output drive. 2. desolder the ALS138A driving it--this was not meant for a bus driver, but I cheated rather than add another line driver (which I clearly must do in the next pcb rev). I've ordered all the combinations of new 138 parts--my stock is used up. Quote Link to comment Share on other sites More sharing options...
Willsy Posted January 6, 2021 Share Posted January 6, 2021 Try adding a 2N7000 or something similar to drive the signal. Worth a try if you have a MOSFET lying around... Quote Link to comment Share on other sites More sharing options...
pnr Posted January 6, 2021 Share Posted January 6, 2021 20 hours ago, FarmerPotato said: Well, it is not solved. I can sample SERENA* with the hi-Z analog probe or digital probe. As soon as I connect a gate input, it fails. Both LS and HCT. The driver is an ALS138A output (decoding the IO bus state and A14:13). As far as I can tell, it should be compatible. Maybe it is not a DC but an AC issue: maybe the bus line is ringing? Have you tried a 100R series resistor to dampen reflections (as in the firehose interface)? 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 6, 2021 Author Share Posted January 6, 2021 4 hours ago, pnr said: Maybe it is not a DC but an AC issue: maybe the bus line is ringing? Have you tried a 100R series resistor to dampen reflections (as in the firehose interface)? OK, I'll try a resistor. I considered whether to add the 220/330 ohm bus terminator packs. I see these on the S-100 bus. A fellow in our retro club here says that's not really needed with a 6" bus and 6MHz. I wonder what capacitance is added when I insert the 138 that is using the input. I think this is in the datasheet somewhere... I have replaced the ALS138 driver with a new LS138. The new LS138 is driving the bus SERENA* perfectly but is there really a load on it? The sink LS138 is not adding any current draw to the total! And all the outputs are low, yikes. Not a short? Maybe fried? I should test the chip separately, after I see this. I tested continuity through the chip socket itself, in case the contacts were weak. Goldang it, both the VCC and GND pins do not have continuity between the chip and the wire wrap pins! The WW socket contacts must be worn out. Unkown if it's from Unicorn, or some surplus shop, or worst case, from TI's dumpster and used already. Spraying some Deoxit in there before I pull it out. Spoiler I was surprised by how easy hot-air *rework* is. Flux, no Capton tape, no solder wick, no sucker, no extra solder! The original soldering was pretty difficult. (Except for the 99105, the cpu card is all SOIC-16 and the like.) 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 7, 2021 Author Share Posted January 7, 2021 On 1/2/2021 at 5:03 AM, pnr said: Happy to hear that you found the problem. At last it is fixed. The wire wrap socket of the LS138 was broken at the VCC and GND pins (only!) I replaced it with a new, machine pin WW socket. 4 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted January 7, 2021 Share Posted January 7, 2021 Bad sockets are eeeeevvvviiiiillllll! 1 1 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 8, 2021 Author Share Posted January 8, 2021 Here is the "clean" screenshot. Yellow SERENA* is from the CPU card to the '138, Red 1380 is the Y2* output to enable the 9902. AD and ALATCH show CRU address 13B6 being latched. (ignore the LSBit) IN is 1, from the 9902. With no chips inserted, it would be floating or 0. Glitches remain. I don't see much when I look at the analog. At sampling rate 125 MS/s they are repeatable. But not at 50 MS/s; they dance around. I conclude that the glitches are at least 8 ns and shorter than 20 ns. With glitches appearing on RESET*, the cpu keeps on ticking, so they can't be real. (But then again that is too fast) The RESET* line is driven by a debounced switch, with an RC decay time and two series Schmitt Trigger inverters (74LS14). The debounced switch is rock solid over 50 presses, each recorded in a 200ms window. (It needed a decoupling cap on the LS14 to fix ringing.) The 99105 has Schmitt trigger inputs but those are now redundant. I've spent more time hand-soldering on that #@! reset switch... Onward to debugging serial! It is in a tight loop (comments mostly from Thierry's code) 0035 002A 020C 20 li r12,conr12 002C 1380 0036 002E 1F1B 20 lp1 tb 27 test dsr pin (i.e. dtr on the connector) 0037 0030 16FE 14 jne lp1 line is high 0038 0032 1F15 20 tb 21 line is low: test receive buffer 0039 0034 16FC 14 jne lp1 else keep waiting Address 13B7: (ignore LSbit) TB 27 finds 1 for DSR* low. DSR* is pulled low by 10K resistor (my 4-wire cable has no DTR) indicating online. Address 13AB: TB 21 finds 0 for no character in receive buffer. 1 Quote Link to comment Share on other sites More sharing options...
pnr Posted January 8, 2021 Share Posted January 8, 2021 Again, congrats on getting it to work! 1 hour ago, FarmerPotato said: With glitches appearing on RESET*, the cpu keeps on ticking, so they can't be real. (But then again that is too fast) This by itself is not certain. My understanding (after experimentation) is that reset is only sampled by the CPU on the rising edge of CLKOUT. Although the datasheet says that it must be asserted for at least 3 machine cycles (clocks), actually one is enough for the processor to reset. If the glitches occur outside the setup/hold time around the clock edge, the CPU would not notice. It may be interesting to do an analogue measurement for CLKOUT an RESET and see how that relates to the digital measurements. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 9, 2021 Author Share Posted January 9, 2021 3 hours ago, pnr said: Again, congrats on getting it to work! This by itself is not certain. My understanding (after experimentation) is that reset is only sampled by the CPU on the rising edge of CLKOUT. Although the datasheet says that it must be asserted for at least 3 machine cycles (clocks), actually one is enough for the processor to reset. If the glitches occur outside the setup/hold time around the clock edge, the CPU would not notice. It may be interesting to do an analogue measurement for CLKOUT an RESET and see how that relates to the digital measurements. RESET* is clean in analog. I wonder if this is an issue with my digital harness (about 7" of wire) or the VB-8012 itself. It has continued across firmware updates. I pushed the probes on more forcefully and it seemed to get a little better. Addressing the VCC ripple, I added some more bypass 0.1uF caps. I see the VCC ripple is present in the CLK ripple, or is it the other way round? It's tempting to think the biggest VCC ripple coincides with an ALATCH glitch. Stats say that VCC min/max peak to peak is 1.15V A different stat says Voltage 4.8 to 5.31. A VCC that occasionally touches 4.5 or 5.5 is not a good thing. but 4.8 to 5.31 is sort of ok. The CPU has one 0.1 cap just outside VCC. RDBENA and RD seem to match the demand on VCC, as the bus buffers switch direction. Those chips also have 0.1uF caps on VCC (on the cpu pcb) Quote Link to comment Share on other sites More sharing options...
pnr Posted January 9, 2021 Share Posted January 9, 2021 Well, the analog shows that the signals are as I would expect them to be. Had a quick look at the spec sheet for the VB-8012: https://www.ni.com/pdf/manuals/371527d.pdf It says that the input threshold on the digital inputs can be adjusted between 0V and 2V. For TTL signals I think low is 0-0.7V and high is 2.4-5V. Maybe the threshold is currently set to a quite low or high value), where overshoots are detected as a reverse signal for one sample. Mathematically, 1.5V should be ideal, but in a circuit that mixes (LS-)TTL, HCT, NMOS, etc. some experimentation may be in order. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 11, 2021 Author Share Posted January 11, 2021 On 1/9/2021 at 10:20 AM, pnr said: Well, the analog shows that the signals are as I would expect them to be. Had a quick look at the spec sheet for the VB-8012: https://www.ni.com/pdf/manuals/371527d.pdf It says that the input threshold on the digital inputs can be adjusted between 0V and 2V. For TTL signals I think low is 0-0.7V and high is 2.4-5V. Maybe the threshold is currently set to a quite low or high value), where overshoots are detected as a reverse signal for one sample. Mathematically, 1.5V should be ideal, but in a circuit that mixes (LS-)TTL, HCT, NMOS, etc. some experimentation may be in order. Yes, I've played with the 0-2V settings, it didn't affect it as far as I can see. I think the glitches are in the probe wires or the digitizer chip. I don't get any such glitches when I use a GPIO pin. I'm going to focus on cleaning up VCC with bypass caps--I've got a measly 0.1 on the 99105. The last couple 0.1 uF didn't affect the noise on CLKOUT, but I'm not sure if that is coupled from VCC or just the way NMOS square waves come out. I'm keeping measurements on CLKOUT as I add bypass caps, for specific frequencies. \ FFT of CLKOUT. Blue=before Orange=after adding 0.1uF on each remaining IC. No effect. Square wave of 3MHz should have harmonics at 9,15,21. There's a pretty big ripple at 6 that I'm watching. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 11, 2021 Author Share Posted January 11, 2021 On 1/7/2021 at 4:39 PM, FarmerPotato said: At last it is fixed. The wire wrap socket of the LS138 was broken at the VCC and GND pins (only!) I replaced it with a new, machine pin WW socket. Goldang reset button flaked out again. A solder ball on the LS14 (inverter with Schmitt trigger inputs) broke free. The LS14 has two unused gates, 6 and 1, which must not be left floating. Input 6A was tied to VCC, output 6Y was giving 0V as it should, but the teeny wire connecting 6Y to feed input 1A was separated. The symptom was that input 4A was a solid 0V, but output 4Y was an erratic around 2.5V. A demonstration of how floating inputs can mess up other gates in the same chip (floating gate 1 screwed up gate 4). That's what interrupted my testing of 9902 bits on Saturday. One moment it was working, then #@!$@$#!. Broken solder ball. EDIT Multiple issues existed. As I started putting components back together in a system, the RESET line flaked out. Button panel by itself, fixed. Button panel + CPU, erratic. Repaired one crimped lead, and cleaned up solder joints, fixed. CPU + Button panel working perfectly. Attach to backplane with memory board, same erratic again! Inspected RESET pin at memory card... no obvious short. Corrected a slightly bent GND pin next to it. Perfect! I don't know what the bent GND pin could have to do with it. It bends away from the RESET pin and goes into a 3x32 pin backplane socket! Maybe bad stuff happens inside the socket. I'll have to take one apart. There is no other connection to backplane RESET. It's a backplane input to the cpu card. CPU card asserts RESOUT* on the backplane, when it enters a reset bus cycle. RESOUT* is for the reset inputs of cru, video etc. All back to normal now though. No more time this evening to test serial bits, though. 5 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted February 18, 2021 Author Share Posted February 18, 2021 I haven't done any hardware testing in a month (In fact I had been hospitalized one day.) Zach Freedman says you have to do the boring parts! I picked up last night, testing the 9902 to PC link. The whole system was haywire. A short had developed? Cold solder? VCC was oscillating wildly about 2.5V. Reset stuck low. Maybe the common to PC ground was a disaster? I disconnected the reset switch, tested it in isolation, perfect. Put it back, and went over wire wraps with a magnifying glass. Then I tried to measure VCC on the backplane, slot 7. A solid 5V. Huh? All my logic leads go to the prototype card in slot 8. Hmm... how can VCC differ between slot 7 and 8? What had happened: one of the GND pins broke off my prototype card. x a31................................ a1 b32 b31................................ b1 c32 c31................................ c1 GND VCC The backplane connector is 3x32. From the angle I work at, as I plug the proto card into the backplane, I should see pin a32 going into its socket. b32 and c32 are hard to see. a32 is a convenient reference point to ensure the card is aligned properly. Nope. I had no pin a32, so I had pushed a31 into its socket. All the pins were off by one. VCC did not go into the board. Measuring RESET at c31 was actually measuring GND. The symptom of VCC oscillating wildly, is just like my previous ugly problem. When VCC is not connected to a chip, reading that pin just shows some garbage that leaks through the chips. Last time it was a bad socket--VCC pin of the chip did not make continuity. This time it was just bad alignment. This can't happen with final cards, just the prototype header. A couple hours poking about and things look normal. Onward to the boring parts. Quote Link to comment Share on other sites More sharing options...
JB Posted February 19, 2021 Share Posted February 19, 2021 (edited) 1 hour ago, FarmerPotato said: I haven't done any hardware testing in a month (In fact I had been hospitalized one day.) Glad you're doing better now! Edited February 19, 2021 by JB 2 1 Quote Link to comment Share on other sites More sharing options...
Jimhearne Posted February 19, 2021 Share Posted February 19, 2021 Only found this thread recently, sounds like you are getting a lot of problems caused by the breadboard. I gave up with them years ago, always getting trouble with intermittent connections, even putting a big pin like a header in a hole can stretch the contact so it doesn't make a good connection with a later smaller wire. If i am reasonable sure of my design i will straight to a PCB, otherwise it's 30awg PTFE (so it doesn't melt) wire and perf board. This is my prototype TS68483 video card ! And, yes, i do wish i'd waited a day longer before starting for some more perfboard to come rather than using the only bit i had left. Jim 6 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 24, 2021 Author Share Posted August 24, 2021 9902 transmit, still buggy I am seeing consistent single bit errors in chars transmitted from the 9902. In each char, a sent 1 becomes a 0 received. The first string has 0x40 masked out. Two more strings have 0x08 masked out. The first string is sent by the code STROUT, the other two by the code TXRX. Baud rate is 2400, where the 9902 rate registers have >D0 and the clock is 3 MHz. That checks out as (3 MHz/3) / (2 * 208) = 2403.84 bits/second. The 3MHz comes out of the 99105 CLKOUT (yeah, not 6Mhz still.) What would cause this? 3MHz Clock jitter? But the bit errors are predictable? Bad 9902? Instruction timing on the 99105/9902 after a TB? Remember, the TMS99105 takes an extra wait state per CRU bit out, to account for running at 6MHz. So mine is actually slower than the TMS9900 when sending multiple bits, but faster in between a TB, LDCR. I have captured some oscilloscope traces but that's more tedious to follow. Here is a breakdown of 3 strings, showing the consistent bit errors. 54 68 69 73 20 69 73 20 47 65 6e 65 76 65 20 32 30 32 30 14 28 29 33 20 29 33 20 07 25 2e 25 36 25 20 32 30 32 30 T h i s i s G e n e v e 2 0 2 0 \14 ( ) 3 ) 3 \07 % . % 6 % 2 0 2 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 10 10 10 00 10 10 00 10 10 10 10 10 10 00 00 00 00 00 <- bit 0x40 00 11 11 11 11 11 11 11 00 11 11 11 11 11 11 11 11 11 11 11 00 00 11 00 00 11 00 00 00 00 00 11 00 00 11 11 11 11 00 11 11 00 00 11 00 00 00 00 11 00 00 00 00 00 00 00 00 11 00 00 00 00 00 00 00 11 11 11 11 11 11 00 00 00 00 00 00 00 00 11 00 00 11 00 11 00 11 00 11 00 00 11 00 11 00 00 00 11 11 00 11 11 00 11 11 00 11 00 11 00 00 00 00 00 ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ 57 6f 75 6c 64 20 79 6f 75 20 6c 69 6b 65 20 74 6f 20 70 6c 61 79 20 61 20 67 61 6d 65 3f 57 67 75 64 64 20 71 67 75 20 64 61 63 65 20 74 67 20 70 64 61 71 20 61 20 67 61 65 65 37 W o u l d y o u l i k e t o p l a y a g a m e ? W g u d d q g u d a c e t g p d a q a g a e e 7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 11 11 11 11 00 11 11 11 00 11 11 11 11 00 11 11 00 11 11 11 11 00 11 00 11 11 11 11 00 00 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 00 11 00 00 00 11 00 11 00 00 00 00 00 00 11 00 00 11 00 00 11 00 00 00 00 00 00 00 11 00 10 00 10 00 00 10 10 00 00 10 10 10 00 00 00 10 00 00 10 00 10 00 00 00 00 00 10 00 10 <- bit 0x08 11 11 11 11 11 00 00 11 11 00 11 00 00 11 00 11 11 00 00 11 00 00 00 00 00 11 00 11 11 11 11 11 00 00 00 00 00 11 00 00 00 00 11 00 00 00 11 00 00 00 00 00 00 00 00 11 00 00 00 11 11 11 11 00 00 00 11 11 11 00 00 11 11 11 00 00 11 00 00 00 11 11 00 11 00 11 11 11 11 11 ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ 4f 70 65 6e 69 6e 67 20 74 68 65 20 73 6d 61 6c 6c 20 6d 61 69 6c 62 6f 78 20 72 65 76 65 61 6c 73 20 61 20 6c 65 61 66 6c 65 74 2e 4f 70 65 66 61 66 67 20 74 60 65 20 73 65 61 64 64 20 65 61 61 64 62 67 70 20 72 65 76 65 61 64 73 20 61 20 64 65 61 66 64 65 74 26 O p e n i n g t h e s m a l l m a i l b o x r e v e a l s a l e a f l e t . O p e f a f g t ` e s e a d d e a a d b g p r e v e a d s a d e a f d e t & 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 11 11 11 11 11 11 00 11 11 11 00 11 11 11 11 11 00 11 11 11 11 11 11 11 00 11 11 11 11 11 11 11 00 11 00 11 11 11 11 11 11 11 00 00 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 00 11 00 00 00 00 00 00 11 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 11 00 11 00 11 00 00 00 11 00 00 00 00 00 00 00 00 00 11 00 11 00 00 10 10 10 00 00 00 10 00 00 00 10 00 10 10 00 10 00 10 10 00 10 10 00 00 00 00 00 00 10 00 00 00 00 10 00 00 00 10 00 00 10 <- bit 0x08 11 00 11 11 00 11 11 00 11 00 11 00 00 11 00 11 11 00 11 00 00 11 00 11 00 00 00 11 11 11 00 11 00 00 00 00 11 11 00 11 11 11 11 11 11 00 00 11 00 11 11 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 11 11 00 00 11 00 11 00 00 00 11 00 00 00 00 00 00 11 00 00 00 11 11 00 11 00 11 00 11 00 00 00 11 00 11 11 11 00 00 00 11 11 11 00 00 11 00 00 00 11 00 11 11 00 11 00 11 00 00 11 11 00 00 11 00 00 ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ Little C program that output the above: Spoiler #include <stdio.h> #include <string.h> #include <ctype.h> void decode(const char* in, const char* out) { int n = strlen(in); // hex for (int i=0; i<n; ++i) { printf(" %02x", in[i]); } printf("\n"); for (int i=0; i<n; ++i) { // there are some widechars copied out of the terminal buffer unsigned char c = out[i] & 0xff; printf(" %02x", c); } printf("\n"); // ascii for (int i=0; i<n; ++i) { printf(" %2c", in[i]); } printf("\n"); for (int i=0; i<n; ++i) { unsigned char c = out[i]; if (iscntrl(c)) { printf("\\%02x", c); } else { printf(" %2c", c); } } printf("\n"); // binary for (int i=7; i>=0; --i) { int match = 1; for (int j=0; j<n; ++j) { int b1 = (in[j] >> i) & 0x1; int b2 = (out[j] >> i) & 0x1; printf(" %d%d", b1, b2); if (b1 != b2) { match = 0; } } if (!match) { printf(" <- bit 0x%02x", 1<<i); } printf("\n"); } // error columns for (int i=0; i<n; ++i) { printf(" %2s", (in[i] == out[i]) ? " " : "^^"); } printf("\n\n"); } int main() { const char *in, *out; char buf[80]; in = "This is Geneve 2020"; strcpy(buf, "T()3 )3 G%.%6% 2020" ); // guessed buf[0] = 0x14; buf[8] = 0x07; decode(in, buf); in = "Would you like to play a game?"; out = "Wgudd qgu dace tg pdaq a gaee7"; decode(in, out); in = "Opening the small mailbox reveals a leaflet."; out = "?pefafg t`e se dd eaadbgp reveads a deafdet&"; strcpy(buf, out); // guessed buf[0] = 'O'; buf[14] = 'a'; decode(in, buf); } 1 Quote Link to comment Share on other sites More sharing options...
Stuart Posted August 24, 2021 Share Posted August 24, 2021 Were you going to post your code as well? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 25, 2021 Author Share Posted August 25, 2021 (edited) 20 hours ago, Stuart said: Were you going to post your code as well? Yeah, I was in a hurry! whole test program including STROUT writes a null terminated string. TXRX writes a null terminated string, while buffering up to 80 chars input. When output is complete, the input is then echoed until input is complete (CR or 80 chars.) Returns only after input is echoed back plus CRLF. tiny5.lst tiny5.a99 Edited August 25, 2021 by FarmerPotato 1 Quote Link to comment Share on other sites More sharing options...
Stuart Posted August 25, 2021 Share Posted August 25, 2021 (edited) 19 hours ago, FarmerPotato said: Yeah, I was in a hurry! whole test program including STROUT writes a null terminated string. TXRX writes a null terminated string, while buffering up to 80 chars input. When output is complete, the input is then echoed until input is complete (CR or 80 chars.) Returns only after input is echoed back plus CRLF. tiny5.lst 23.39 kB · 2 downloads tiny5.a99 11.26 kB · 1 download A few observations comparing your code to the code in TIBUG. May make no difference whatsoever but maybe worth a try! -- Instead of [ldcr @intvl,8], try [SBZ 13] to disable loading of the interval register. -- In strout, after transmitting the character, test bit 22 again and loop until it indicates that the transmit buffer register is empty, then test bit 23 and loop until it indicates that the transmit shift register is empty, and *then* loop round to look at the next character in the text string. -- In strout, you test for the CTS pin to become active. I get the impression from the data manual that this is handled in the 9902 hardware - transmission won't begin until CTS becomes active. Is your 9902 an original TI one, rather than from China? Do you see the same errors if you increase the Baud rate? Edited August 25, 2021 by Stuart 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 26, 2021 Author Share Posted August 26, 2021 (edited) On 8/25/2021 at 3:52 PM, Stuart said: A few observations comparing your code to the code in TIBUG. May make no difference whatsoever but maybe worth a try! -- Instead of [ldcr @intvl,8], try [SBZ 13] to disable loading of the interval register. -- In strout, after transmitting the character, test bit 22 again and loop until it indicates that the transmit buffer register is empty, then test bit 23 and loop until it indicates that the transmit shift register is empty, and *then* loop round to look at the next character in the text string. -- In strout, you test for the CTS pin to become active. I get the impression from the data manual that this is handled in the 9902 hardware - transmission won't begin until CTS becomes active. Is your 9902 an original TI one, rather than from China? Do you see the same errors if you increase the Baud rate? I’ll try these things tonight. Different 9902s, the 9902s are China, eBay polida2008 ( gets cred for pulling counterfeit 2612s and refunding) but I will test the batch, plus try to find one from a known good RS232 card. Indeed, the 9902 manual says on p.15 "When RTSON is set by the CPU, the RTS* output becomes active and the transmitter becomes active when CTS* goes low." I misunderstood that, by overlooking the "when CTS" part. So I can skip checking for CTS* active. Edited August 27, 2021 by FarmerPotato 3 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 27, 2021 Author Share Posted August 27, 2021 On 8/25/2021 at 3:52 PM, Stuart said: A few observations comparing your code to the code in TIBUG. May make no difference whatsoever but maybe worth a try! -- Instead of [ldcr @intvl,8], try [SBZ 13] to disable loading of the interval register. -- In strout, after transmitting the character, test bit 22 again and loop until it indicates that the transmit buffer register is empty, then test bit 23 and loop until it indicates that the transmit shift register is empty, and *then* loop round to look at the next character in the text string. -- In strout, you test for the CTS pin to become active. I get the impression from the data manual that this is handled in the 9902 hardware - transmission won't begin until CTS becomes active. Is your 9902 an original TI one, rather than from China? Do you see the same errors if you increase the Baud rate? I removed the CTS checks and added wait for XBRE and XSRE. About the same outcome. Different bit errors. The 9902 from polida2008 has been through accidents in my proto, so I pulled it. I tried 3 more 9902s from polida2008. All showed worse errors. Going to take 9902s from dead CF7s or Nanos next. Then find a known good RS232 card. (I think must be desoldered.) Scope. At high sampling rate, I see little glitches in both digital and analog probe 3MHz CLKOUT from the backplane. Correlated to ALATCH edges. They’re on the order of 1ns spike but 0-4.5V. Clock glitches cross over into TX as shown in analog and digital probes. So I have a hypothesis that the 9902 gets its clock counter messed up, or the TX line noise is a problem for the FTDI Friend listening to it. (FTDI Friend set to 5V signal level.) Seems unlikely that 1ns spikes would register anywhere though. I have a 0.1uF ceramic cap right on the 9902 socket. Lots more .1uF caps, and two 10uF where power enters the wire wrap board. I believe nothing will come close to filtering those 1ns spikes except SMT caps with very low ESR. And I kinda think the noise is just on my scope probes…(similar junk on AD lines but the CPU runs smoothly for hours.) there are some ridiculous ground loops with the scope probes adding up to 6 ground leads (and the common signal ground at the serial port makes me wonder if I’m ignorant of something re: serial cables.) I hope all this confusion is down to sketchy 9902s. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted August 27, 2021 Share Posted August 27, 2021 I may have one or two old stock 9902s in one of my boxes of parts. I'll look to see if they are accessible/actually there and let you know, @FarmerPotato. Quote Link to comment Share on other sites More sharing options...
Stuart Posted August 27, 2021 Share Posted August 27, 2021 Are you able to isolate CLKOUT near the CPU to see if it's picking up interference from the backplane? Does adding terminating resistors to the CLKOUT at the 'end' of the backplane make any difference? 220Ω to +5V and 330Ω to GND. Are you using a TMS9902NL or TMS9902ANL? Might be best to use the latter version just in case the change to the "A" revision helped address your problem ... Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 27, 2021 Author Share Posted August 27, 2021 1 hour ago, Stuart said: Are you able to isolate CLKOUT near the CPU to see if it's picking up interference from the backplane? Does adding terminating resistors to the CLKOUT at the 'end' of the backplane make any difference? 220Ω to +5V and 330Ω to GND. Are you using a TMS9902NL or TMS9902ANL? Might be best to use the latter version just in case the change to the "A" revision helped address your problem ... by isolate, do you mean sever it from the backplane? I will test the CPU card in isolation—power supply pins directly to it. Was thinking of inserting a buffer chip, though the CLKOUT does have very crisp edges.. (I do need a ‘74 to divide 6MHz to 3MHz. Also considering putting a separate 3 MHz oscillator just for the UARTs so they don’t depend on bus speed.) I don’t have termination. I see 220+330 termination in my S-Bus Altair 8800 backplane, which is comparable. but the retro club guys said it doesn’t matter at 3MHz. I did get a quantity of 220+330 resistor network SIPs for this purpose. my chips are 88 date codes, Phillipines. I think they are ANL, but my brain got fuzzy 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 27, 2021 Author Share Posted August 27, 2021 2 hours ago, Ksarul said: I may have one or two old stock 9902s in one of my boxes of parts. I'll look to see if they are accessible/actually there and let you know, Thanks! Have any economical sources for 9902s? (I know I last asked about 9903s) If anyone it would be you. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.