Both of those scope images are worthless. I just realized the timebase is at 2mS/div on signals that are running in the uS range. Not sure if that "scope" you have can get down to that range on the time base but a 2mS you are averaging several thousand pulses so there's no way to tell if the signals are bad or good or even what voltage they are getting to. Do you know what the max sample rate of your scope is?
-
Please post all monitor technical topics in the Technical - Videogames - Monitors section, not in the General Help section.
asteriods troubleshooting vg watchdog
- Thread starter wugly
- Start date
HudsonArcade
Well-known member
Hah... good eye....
Looks the the DSO5200 goes up to 200MHz, so it should be more than capable.
Looks the the DSO5200 goes up to 200MHz, so it should be more than capable.
wugly
Well-known member
load 5 is still flat line. snipped pin 9 h6 and the chip had an output but from schematics h4 or h5 should be pulling it down unless I am missing something and both h4 and h5 were replaced.
wugly
Well-known member
been looking at state machine. halt and invert halt was changeing but I discabled watchdog and realized the watch dog was causing that, the state machine was freezing not triggering the halt strobe. beleive the state machine part that triggers latches strobe and push is functioning properly. currently going through al lthe connections from vector generator counter to vector memory generator latches and testing through sockets to make sure I have good connections. Have removed roms from sockets and verified them. I believe the vector generator program counter is generating incorrect information and messing up the calls to the generator ram and rom.
I have data coming intothe 367 driver chips but on a few the output gets grounded by the bus it is connected too. I believe that the feed back from the counters to the register chips and possibly how the register chips are controlled is causing the load signals to be grounded. the two chips I have replaced are the ones that have the grounded load problems. Maybe they are not going to high impedance in the third state. still waiting for a new batch of chips. was buying motorola chips from china for cheap. thinking maybe I should bite the bullet and put an order into mouser and buy the more expensive texas instrument ones.
I have data coming intothe 367 driver chips but on a few the output gets grounded by the bus it is connected too. I believe that the feed back from the counters to the register chips and possibly how the register chips are controlled is causing the load signals to be grounded. the two chips I have replaced are the ones that have the grounded load problems. Maybe they are not going to high impedance in the third state. still waiting for a new batch of chips. was buying motorola chips from china for cheap. thinking maybe I should bite the bullet and put an order into mouser and buy the more expensive texas instrument ones.
Yea, I would reccomend Digikey or Mouser for TTL parts (if they have them). I kind of gave up helping you since it doesn't seem you are interested in learning to use the scope or posting pics of what you are seeing. Shot gunning things tends to create more problems than you fix, good luck!
wugly
Well-known member
I did use the settings you said and the readings I got was that load 5 was still flatlined. I nipped the pin9 on h6 to be easily repairable to test if signal was going through h6 which it was but something in the load 5 buss was dragging it down. Why I have no idea but I do know if I left a pin in the feedback back into the reg chip it will allow activity on load5 but I am sure the feedback is necessary but something is a little wrong with it or the control signal for it are wonky. the reason I didn't post new pictures at the duration you suggested is because load 5 had no change.
wugly
Well-known member
well I have confirmed its not the chip causing the problem but that it has to be something is causing the reg chip to overwrite the data coming in
wugly
Well-known member
resurecting this board problem. I am currently haveing problems with board watchdogging. It can pass the ram tests and I have verified the roms. It can draw a good test pattern but resets after its drawn so I think the vector timer might be good and also the state machine. drawing on the game does not resemble asteroids at all nor anything. looks to not be accessing proper data. load 11 appears to be reading low then it translates to a low adma11 and then a low am11 which I know is causing acess to the vector generator ram to be bad which is why my display is going horrible. anytime I lift a pin anywhere along the path for this address 11 as it converts to different address styles all of a sudden it pulses and looks good which means in the program is forcing it to be low because once it breaks any of this loop I see activity. Lifting pins on j6 11 makes it pulse on j6. lifting pin 10 j5 makes it pulse in j4 and j6. lifting pin 6 j5 makes pin 6 pulse and all behind it
HudsonArcade
Well-known member
If it can draw simple vectors, but fails on more complex displays, I'd suspect the vector stack (74ls670s).
wugly
Well-known member
I thought of that and replaced it already. I wasn't sure about the replacement chip and got more from a reputable source and it still didn't help. its socketed so that it why its easy to lift a pin. j4 j5 and j6 were replaced. even on the test it stil watchdogs but can at least finish the image
Last edited:
wugly
Well-known member
still have not figured out why adma is stuck on gnd. k3 has a pulsing signal coming in from the cpu on pin 2 pin 3 is gnd and select pin 1 is pulsing. output to am11 pin 4 stays gnd. I have replaced k3 and L3 I am running out of ideas. vgr and vgdb should be good because it passes mem test.vg rom has been verified and I traced the connections as good. F7 on the vector generator memory latches was changed but I saw no problem and I have pulsing on pin 17 and 16 which means data is going through to be converted into address 11 in the vector genarator program counter. Input on J6 pin 12 pulses, output on pin 11 is gnd. J6 was replaced J5 was replaced and J4 were replaced. I figure my only choice for where I might have a problem is k5 just because I have run out of ideas. I figure anything outside of the vector generator program counter is probably good because it can make the test pattern ok even though it resets. I am guessing that maybe it doesn't rely on the vgp until it gets more complicated. Any comments?
Attachments
wugly
Well-known member
Still no joy. Pulled the K5 chip which tested bad but it could have died by my pulling it out. replaceing it changed nothing
wugly
Well-known member
I am an idiot and have focused on the wrong thing. I thought the load 11 being the problem was wrong as far as I can determine it is normal. connected a working board and checked it and the working board has load 11 being grounded during attract mode so I believe I wasted time and effort on fixing a problem that wasn't.
andrewb
Well-known member
Yes, that's normal.
(Sorry I haven't been keeping up with this thread, I could have saved you that one. But you learned it the same way I did.)
That's a semi-common thing with these. Some signals can look stuck under some circumstances but not be. That's why one of the things I did was take a working board, put it in test mode, then map out (or just learn) how the outputs of major sections of the VG should normally behave (and sound, if you have an audio probe). That allows you to quickly scan an unknown board, which often can give you clues to help narrow down where issues are. It's just another tool to have in the toolbox.
I call it a 'poor man's signature analyzer', since the VG is hard to do proper SA on.
wugly
Well-known member
I found the problem and its going through a two hour burn in. Thanks to everyone that has contributed to my under standing of this tricky board problem. thanks so much Goodbye!!
Ahem!! You didn't think I would leave out the end of the story now did you?
The problem turned out to be J4. It seems that a logic probe will not be of much help to you finding a bad 670 chip since it reported activity on all the pins but reported in activity on pins in a good chip in which I spent over 5 months off and on trying to figure out why it had data going in and no data going out which was the way it should have been. (for anyone following this there is no activity on load 11 in attract mode nor is the lack of activity on dmacnt I problem in attract mode.
Debugging logic Verified and cleaned all socketed chips and roms on board. Replaced bad rams that showed up in self test. Because the game got through self test and would run blind when pin 1 of L6 was lifted I was reasonably sure almost all of the circuits on the mpu schematics were functional. The only ones I had to verify as I went were E4 L3 and L6 by checking for actvity though my wdclr would fail when I allowed the game to try to generate vectors again.
Because it could ruin and pass the memory test I had a high certainty that vector generator memory selector was functional and able to pass information to the ram for testing and move back through the vector generator buffer back to the mpu. Onto the vector memory data latches A quick look to make sure E8 in the state machine is sending out control signals which some of which will control the memory latches and and the state machine. Basically I was checking to see if the ck inputs on the latches were toggling and I had data going in and out. the test screen was able to draw the test pattern before it went into a watchdog reset and fortunately for me the lines looked good eliminating everything from the position counters to the monitor. The Vector timer could be considered mostly good since the lines looked good but could not be fully evaluated until we had a running game to check scaling of asteroids and saucers. A9 was toggling both halts but it appeared to be caused by the resets and when watchdog was disabled it was stuck with halt being gnd so it was not telling the mpu that it had completed its task and timed out the mpu. I eventually figured enough of the state machine was functional enough to draw the test screen. I guessed that my problem had to be with the vector generator program counter which was my down fall by getting involved with seeing dead data on a few 670 chips and buffers and counters. The chips are all in a feedback loop and load previous data that it is very confusing what is bad. What looked good was bad and what looked bad was good and I originally replaced a few chips that I thought were bad that improved a data line. I hate replacing any chip I don't have too because it is too easy to wreck a board. You really should have a comparator to test this section of the board. I finally used a technique that I have almost never had work before and that is I piggy backed spare chips onto all the unreplaced chips in the vector counter program and was surprised that the image had changed in game mode. I removed the piggy backed chips one by one until I found out it was the only 670 chip I had not replaced because I thought it was good.
As Kirk said "Spock its two hours"
Ahem!! You didn't think I would leave out the end of the story now did you?
The problem turned out to be J4. It seems that a logic probe will not be of much help to you finding a bad 670 chip since it reported activity on all the pins but reported in activity on pins in a good chip in which I spent over 5 months off and on trying to figure out why it had data going in and no data going out which was the way it should have been. (for anyone following this there is no activity on load 11 in attract mode nor is the lack of activity on dmacnt I problem in attract mode.
Debugging logic Verified and cleaned all socketed chips and roms on board. Replaced bad rams that showed up in self test. Because the game got through self test and would run blind when pin 1 of L6 was lifted I was reasonably sure almost all of the circuits on the mpu schematics were functional. The only ones I had to verify as I went were E4 L3 and L6 by checking for actvity though my wdclr would fail when I allowed the game to try to generate vectors again.
Because it could ruin and pass the memory test I had a high certainty that vector generator memory selector was functional and able to pass information to the ram for testing and move back through the vector generator buffer back to the mpu. Onto the vector memory data latches A quick look to make sure E8 in the state machine is sending out control signals which some of which will control the memory latches and and the state machine. Basically I was checking to see if the ck inputs on the latches were toggling and I had data going in and out. the test screen was able to draw the test pattern before it went into a watchdog reset and fortunately for me the lines looked good eliminating everything from the position counters to the monitor. The Vector timer could be considered mostly good since the lines looked good but could not be fully evaluated until we had a running game to check scaling of asteroids and saucers. A9 was toggling both halts but it appeared to be caused by the resets and when watchdog was disabled it was stuck with halt being gnd so it was not telling the mpu that it had completed its task and timed out the mpu. I eventually figured enough of the state machine was functional enough to draw the test screen. I guessed that my problem had to be with the vector generator program counter which was my down fall by getting involved with seeing dead data on a few 670 chips and buffers and counters. The chips are all in a feedback loop and load previous data that it is very confusing what is bad. What looked good was bad and what looked bad was good and I originally replaced a few chips that I thought were bad that improved a data line. I hate replacing any chip I don't have too because it is too easy to wreck a board. You really should have a comparator to test this section of the board. I finally used a technique that I have almost never had work before and that is I piggy backed spare chips onto all the unreplaced chips in the vector counter program and was surprised that the image had changed in game mode. I removed the piggy backed chips one by one until I found out it was the only 670 chip I had not replaced because I thought it was good.
As Kirk said "Spock its two hours"
