• Please review our updated Terms and Rules here

Homebrew TVT I picked up

So what were you planning to use this with? Does your SWTPC 6800 have a serial interface?

The GI AY-3-1013 is a UART only; it has no synchronous capabilities. To add a synchronous serial interface would require some reworking of the board.

However, on the SS50 bus, pins 46-50 are UART clocks for various rates. Why not use one of those for testing?
 
My 6800s both have serial interface. I was just hesitant to hook up because if my hunch is correct, the previous owner modified his MP-S card to allow those teletype punch signals out. I'm not sure if it'll work with a standard MP-S card or if I could damage something just hooking up as is.
 
Didn't get time to test out the 6800 with this TVT.. but I did get a little bit of time to compare the pins to the ones on a known SWTPC-compatible TVT. I used my DMM just to make sure there weren't dangerous/wrong voltages. So far, they all seem to be correct. The big one is there is -9V at what would be pin R1 of the MP-S card. That is both on this TVT and on an actual CT1024. So I think we are good to test this out tomorrow for real and see what happens.
 
Okay so I hooked up the 6800 to the TVT and decided to see what would happen, after re-checking to make sure there weren't any dangerous voltages or connections being made. I first attempted it with a Corsham serial card, as those are easily replaceable, but it didn't work because the Corsham board doesn't have any connections for a clock signal. I then hooked up to a real MP-S board, and it reacted! When I turn the 6800 on, the cursor moves. Unfortunately, it doesn't produce readable responses as I type. So I thought about it for a minute, and then decided to try giving the punch tape command to the 6800. I reasoned that it'd be easy to see if the computer was reacting; even if there weren't any legible data, I'd at least have stuff going mad onscreen, because when you do the punch tape command it displays the S record as its being punched out. If that worked, then I'd know the SWTPC was receiving the correct info. Anyway:

https://www.youtube.com/watch?v=d3I6agW41Es

So, we know that sending works. We know the TVT is receiving. Also know this isn't a baud rate issue as the MPS I have is baud rate switchable and they all produced the same results, albeit at different speeds. I guess since the clock is derived from the MPS board, the TVT just runs at whatever baud rate the MPS is running at.

What we don't know is, is the onscreen data garbled because the TVT is malfunctioning somewhere, or is it simply mistranslating, because perhaps that 6800 machine it was paired with had custom firmware to handle the different character generator, etc? I note as it's displaying the punching S-records, it's repeating the same data in two columns.
 
Yes, It's not a baud clock issue as those come from the SS50 bus.

Have you tried swapping the 2102s around to see if that makes a difference in the display?
 
I've tested those pretty extensively in other machines. I could swap a complete set in from one of those and see if there's any difference.
 
It's completely in the video generation, has nothing to do with the data it is receiving, or is expecting to receive. The horizontal sweep is all wrong.
 
Okay, so it's not the memory.

I'm not convinced that it's the horizontal sweep, as I'd expect the image to be skewed considerably; in your YT demo, I can make out what appears to be zeroes being sent and they look relatively stable.
 
Well, not the sweep in the monitor, but (can't think of the right word for it) the way the horizontal image is being generated, something is overlapping or just not sequenced correctly.
 
This may go back to the EPROMs. Remember what I said about things like parity. I suspect the computer it was used with expected parity. He may have use the EPROMs to translate from ASCII to ASCII+parity. I suspect you'll see the same thing on the receive side. There would be an EPROM to translate back to straight ASCII for the display.
You might want to set it up with a loop back on the serial, rather than using the computer( keep the oscillator though ). You should then be able to look at a single data line at a time from a single key. You can then trace every data path for each bit easier.
Dwight
 
Last edited:
KC9UDX said:
Well, not the sweep in the monitor, but (can't think of the right word for it) the way the horizontal image is being generated, something is overlapping or just not sequenced correctly.
Click to expand...

This is where I'd turn to my logic analyzer, though I'd first try to dump the EPROMs. Given appropriate power supplies, it wouldn't be terribly difficult to rig something up with, say, a parallel port on a PC.
 
I actually have a logic analyzer, although in my hands it might be worse than useless.

Question: if this were a parity problem, would we expect *any* characters to be correct? I'm wondering if it'd be useful, since we know the 6800 is receiving data okay from the terminal, to input that short program that endlessly displays every character the machine can produce. That might give some hints?
 
falter said:
I actually have a logic analyzer, although in my hands it might be worse than useless.

Question: if this were a parity problem, would we expect *any* characters to be correct? I'm wondering if it'd be useful, since we know the 6800 is receiving data okay from the terminal, to input that short program that endlessly displays every character the machine can produce. That might give some hints?
Click to expand...

I'm suspecting problems in the EPROMs. A little bit loss will do strange things.
Also, you might want to look at the serial data from the keyboard side on another machine to make sure it is all OK. A PC or other computer with a terminal program might be best. That way you can receive or send a single character at a time.
I suspect the signals at the EPROMs are constant as you don't need to isolate them with a 3state bus. It isn't until you are getting to the data out to the video that you need to worry about things changing fast. You should be able to go from the serial UART all the way to the data input of the RAM with a logic probe.
Dwight
 
Also see my post in this thread for bypassing the 1702 translation by using a DIP plug. You may not get the right output, but it will have the effect of a flaky 1702 removed.
 
I think the problem may be simpler.

So if you've seen the photos, there's the board on the far right with the lone eprom on it. That's the one that's in the socket that was broken in two and that I pieced back together. I decided to check to make sure voltages were all good. On the EPROM they are, and I can see data hitting the inputs of it when the 6800 is sending data. I do not see anything leaving, although the outputs are all pulled low and I don't know what is required to overcome that - ie if there are conditions the board needs before the EPROM is actually used.

I believe this board is the cursor control board. When I remove it, not only does the cursor disappear, but the 6800 cannot send any data to the screen.

Anyway, I decided to check all voltages on all chips, and I found one discrepancy. The topmost 74193 has +5V at pin 16, like I suspect it should. But the bottom two don't. One has 0.8V, the other 0.1V. So I looked at the back of the board. Here's a pic:

https://drive.google.com/file/d/14WMUXm8sxoPDK76SGcWXKymyCDJ15yPM/view?usp=sharing

There are two rails that run beneath these ICs - one appears to have been utilized for +5V. You can see up top there is a dab of solder on that rail, and one on pin 16. I've tested continuity and there is no resistance there. That is the IC that gets +5V. Further down, though, not so much. While I could get continuity between the rail and the second 74193 IC 1 pin 16, there's much less continuity between IC 2 Pin 16 and IC 1 pin 16. It's even worse for IC 3, which doesn't seem to have any continuity between the rail and its pin 16.

Now, I note from the datasheet that the voltages for these can be varied. I'm wondering, would it be by design that these are shut off? Or is it more than likely just rust, broken solder, etc. I note the actual trace between the 5V rail and pin 16, if that's what it is, is tiny. I'm wondering if I should just patch these. Since these are counter ICs, and if they are involved with cursor movement, I wonder if having two of them disabled is causing data to be put in the wrong place on screen.
 
Yes. This is a single rail (marked +5V in the pic) running underneath all three of those 74193s, and it only has connections to pin 16 on each. There is that second rail beside it that also runs under the ICs, that may be ground.. I've not checked it. But based on what I can discern, all of the 74193s should be receiving 5V. I can see no intentional breaks in the rail.
 
I soldered in some wire and now have +5V at all three 74193's pin 16, but yeah.. not much difference. Maybe a bit more data showing up onscreen.

Might be back to the video board on this one, since it is mirroring things in two columns.
 
It sounds like there may be issues with it and possibly other pins. you might take a piece of 28 or 30 ga wire and stuff it through any of the holes that don't make contact, while heating the solder. You can then solder the wire to the pin. You can go around each of the pins with your meter until you see them all making contact.
Dwight.
 
You must log in or register to reply here.
Back
Top