Jump to content

calphool

Members
  • Posts

    12
  • Joined

  • Last visited

About calphool

  • Birthday 09/25/1972

Contact / Social Media

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,582 profile views

calphool's Achievements

Space Invader

Space Invader (2/9)

0

Reputation

  1. For the good of the group, I've solved it, but I really don't know what the underlying issue was (maybe cap values, maybe aging VDP with a bad Pierce oscillator inside, maybe bad/noisy trace routing, maybe heat, not sure). The underlying cause could have been any of those things I suppose. Anyway, I've got a rock solid VDP at this point, so if someone ever struggles with a similar situation, they can follow this approach. So what I did is purchase one of those Digikey programmable oscillators (CPPT4-HT5RT-ND from Cardinal Components), had it set to the exact frequency from the TMS9918 datasheet, chose a TTL voltage level when I ordered it, and then hooked up an inverter (74HCU04) that took the output signal from the oscillator, inverted it, and then I inverted *that* signal so that I had two opposing signals, both at TTL levels, and both fairly square. I put 470 ohm pullups on the two signals coming from the inverter, put some bypass caps on both the oscillator and the inverter, and then fed the two oscillator signals into the VDP. Since this wasn't accounted for in the PCB design, I had to create a little veroboard circuit underneath the PCB with these components on it. So, who really knows what the root cause was -- could be that I was overdriving the crystals and killing them with incorrect caps, could be that the heat from the VDP was pushing the crystal out of its frequency tolerance, could be that the VDPs I'm using are old, could be that my traces were too small or laid out poorly so they were creating noise.
  2. I've got two VDPs. They both exhibit this symptom. When I say "it dies," what I mean is that the crystal stops oscillating (per oscilloscope), anywhere from 5 seconds to about 5 minutes after you start up the circuit. I thought it might be heat related, so just for giggles I put a CPU fan on top of the VDP, and it made no difference at all in terms of how long the crystal oscillated. So I'm less convinced that it's heat, though it *might* be heat in that the VDP does get warm, and the crystal is right next to it, so perhaps the VDP is pushing the crystal outside of where it can hold its frequency +-0.005% (which is what's required by this silly chip). Based on the fan behavior though, I'm not sure, since in theory that should have kept the VDP cool enough that it would have at least *lengthened* the time it took for things to go haywire. My understanding is that the VDP has its own top half of a Pierce oscillator internally (which is why the schematics often just show a crystal connected). However the VDP says you can drive the chip with an external clock source, you don't have to use the internal Pierce Oscillator half, and it shows how to configure it -- basically just like the ChromaTRS schematic shown above. So, I'm either going to build my own Pierce Oscillator like the ChromaTRS schematic, or I think I might get one of those programmable oscillator cans, get it programmed from Digikey to 10.7386 mhz, and see what that gets me. That way, I could at least break the problem in half. I'll know for sure that I've got a good quality oscillator output. I think it's possible that I'm actually damaging the crystal by over driving it, because I'm not doing anything to limit current (presumably whatever's inside the VDP should be doing that I suppose). So I'm thinking what *might* be happening is that the circuit works fine for a while, but eventually the crystal gets damaged, and after that it will only vibrate near its fundamental frequency for a short period and then drifts too far. Once it gets outside of the VDP's tolerance (+- 0.005%), the internal Pierce Oscillator stops working, and so the crystal stops. I don't have a frequency counter, so I'm not positive this is what's happening, but it seems like a reasonable theory given what I've been diving into on how to design proper crystal circuits. I'll probably order another TMS9918 somewhere just to make sure, but it seems unlikely that I've got two NOS TMS9918's that are both damaged in the same way (unless *I'm* damaging them somehow).
  3. Well, I got my new caps, tried the 47pf, and everything worked for a few minutes, then it died again. So I tried the 39pf cap, and it worked for a long time, but eventually died again. When it dies, the behavior is strange. When you first turn the circuit on, it oscillates for a short period of time, then dies. Each time you cycle it seems to be shorter. Did I mention that I really hate crystals? I think I'll build a CMOS inverter circuit (Pierce Oscillator) like the ChromaTRS schematic shows and see if that helps. I'll have to stack it under the PCB I guess, since there's no room for it on top... if it works then I guess I'll commission a new PCB. What a pain.
  4. The datasheet for the TMS9918 says that the crystals came from http://www.ndk.com/en/products/index.html. However, as far as I can tell that company no longer makes a 10.738635 crystal (which is precisely 3 times the colorburst frequency -- I guess the TMS designers didn't want to use a PLL so they could use a standard input frequency, or maybe on-chip PLLs weren't easy/cheap to construct back in the late 1970s). I strongly suspect that those crystals from NDK had a lower load capacitance than the ones I'm using (something around 25pF would be my guess, since that makes 33pF load capacitors just about right). Since the caps are there for the crystal, and not the TMS9918, the load caps are going to vary. The only supplier for the 10.738635 crystal that isn't series resonant seems to be CTS and it seems to need 32pF load capacitance. I don't know if the chip will work with a series resonant cap, but if it does, you'd get rid of the caps altogether. Stray capacitance is often quoted as being "something around 5pF" because people base it on "capacitance from the PCB itself", but it also should include chip "input capacitance". Modern chips have really low input capacitance, but this thing is 1970s tech, so we need to check. The datasheet for the TMS9918 unfortunately only says that the input capacitance is a "max" of 10pF. So, let's say we have a range of 2 - 10 pF for the PCB and an input capacitance of the chip from 1 - 10pF. That means we have a stray capacitance range from 3 - 20pF. Using those numbers, that gives me a mean load cap value of 43pF (averaging two different methods of calculating it) for this crystal. For the record, I'm using these two methods of calculating the value for the load caps: (C1*C2)/(C1+C2)+Cstray = Cload and C1,C2 = 2*Cload - 2*Cstray Where C1 and C2 are the same value, Cload is specified by the datasheet for the crystal, and Cstray is the sum of C from the PCB (from 2 - 10pF is my guess) and Cinput (specified in the chip datasheet, 0 - 10pF).
  5. Ok, for the good of the group, I think I know what's going on.... I read this document: https://blog.adafruit.com/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ and I realized that I haven't paid any attention to the load capacitance value of the crystal I'm using. Since that value (load capacitance) can be all over the place, the schematics I referenced are all over the place for cap values, which is the root issue. The other stuff (using inductors or inverters or whatever) is probably ancillary (though perhaps a good idea for some other set of reasons I don't yet understand). So, using the adafruit blog calculations, I get two different potential ranges for capacitors: 34pF to 40pF, or 48pF to 60pF (depending on stray capacitance, which I'm estimating to be between 2 and 8 pF). So, vaguely speaking, I should be using capacitors somewhere from 34pF to 60pF. I'm using 33pF caps... duh. This also explains why I seem to be right on the edge of working (either no signal at all, or a luminance only signal). When I added jumpers from the caps to the crystal, I probably introduced more stray capacitance, which lowers the needed cap value slightly, which probably got me juuuuust inside the range where the VDP could put out a usable signal -- still not good enough to produce a proper colorburst after the front porch in the NTSC signal, but good enough to at least get the levels right for the luminance portion. Sort of makes me marvel at the ingenuity of NTSC actually. I suppose if I just kept randomly soldering junk onto the traces for the caps, I'd eventually get enough extra capacitance that 33pF would work, but that's hacky. So, if I average the average of those two different approaches to calculating my capacitor values, I get 46pF, which is pretty close to a standard 47pF ceramic cap. So I'll start there. Since I don't have any of these caps on hand, I'm going to just order a couple of everything from 30pF to 60pF and work out from the middle until I get something nice and stable. I do really wonder about the Byte magazine schematic though (the one I based part of my schematic on, derp)... it makes no sense based on what I now know. It's got two 33pF caps attached to the crystal. Assuming the load capacitance for the crystal they were using was something like 24pF, those 33pF caps would be about right. However, just jamming a 5-60pF variable cap in parallel to one side of the crystal makes no sense to me. Let's say you're trying to compensate for the fact that a 5% tolerance would allow a "33pF" cap to be anything from 31 to 35 pF. Okay, add a variable cap that ranges from 0 - 4pF to both legs. Adding it to one leg is just going to cause the crystal to not oscillate properly, right? I mean it's going to be additive on one side, so you'll have a cap on one side that ranges from 38pF to 90pF. What good is that? The article talks about using it to slightly alter the color signal, but I'm not sure I follow that at all. How does screwing around with the master crystal cause just the colorburst of the NTSC output to shift? To shift the colorburst, wouldn't you have to do some kind of post processing of the composite signal? I don't see how you could screw with the input to the VDP clock to get that result, at least not without having other potentially weird effects on the VDP.
  6. HELP! I've been working on this project: http://github.com/calphool/TRS80GS I've built 4 revisions of this board for my friend's TRS-80. I've had a heck of a time keeping the VDP chip working in a stable configuration. I had everything working for a while, and then suddenly it decided that it wouldn't work any more. I screwed around with the caps on the crystal (soldering on heavier leads and stuff), and eventually it blinked back to life, but now I only have a luminance signal (or at least the TV can't interpret the color part of the NTSC signal, so I get black-and-white). What I need is a very stable clock, and unfortunately there seem to be about a half dozen different examples of how people have set up the clock on this chip. Here are a few: I need something that just always works, not something that's flaky and subject to weird transient noise. The VDP and its clock divider are basically the heart of my board now, and if I can't get the clock working right, nothing works (the sound chips and UART chip use the divided clock signal that comes out of the VDP for their own clocks). What's the best way to make sure this clock is super stable and reliable? The Texas Instruments hardware design? It's got a bunch of stuff inline (including something it calls an "SR Inductor" that has no uH rating, and I'm a little confused by). The ChromaTRS design? It's got some inverter gates attached to the crystal (though it doesn't specify the value for the resistor it's using). I've been using variations on each revision, with the most recent being the one from Byte magazine, which is flaky as all get out.
×
×
  • Create New...