Asteroids Cabaret Restore
- Thread starter Equites
- Start date
Right - Yes had a look at the schemes and you're right as always, the PCB does indeed accept 74LS245 logic instead of 8304.
For vector side, the location is R2 (P2 for 8304) and for MPU the location stays at E3 but is staggered slightly out by a few mm away from the 6502A CPU. I already have a socket installed at E3 (for 8304 logic) so I unsocketed the 8304 at P2 instead and tried a 74LS245 at R2, did not like my 74LS245!
Mind you, I did not solder in the 74LS245, I just pushed the pins into the holes. I had assumed the tension in the IC legs would be sufficient contact to the PCB for testing purposes??
This is the 74LS245 I used at R4;
http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn74ls245&fileType=pdf&track=no
Equites2011-01-23 17:20:50
For vector side, the location is R2 (P2 for 8304) and for MPU the location stays at E3 but is staggered slightly out by a few mm away from the 6502A CPU. I already have a socket installed at E3 (for 8304 logic) so I unsocketed the 8304 at P2 instead and tried a 74LS245 at R2, did not like my 74LS245!
Mind you, I did not solder in the 74LS245, I just pushed the pins into the holes. I had assumed the tension in the IC legs would be sufficient contact to the PCB for testing purposes??
This is the 74LS245 I used at R4;
http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn74ls245&fileType=pdf&track=no
Equites2011-01-23 17:20:50
Hmm, well, for sure you'll need to solder your 245 in properly or solder a socket in properly. You can't just push it in the holes and hope that it's making good contact. It may, but it's unlikely. Other than that, any LS245, as long as it's a worker should be fine, it shouldn't be fussy.
I think you've made a typo above though as you've said P3 and not P4 (or P2 as it is on some later revision PCBs). The other thing is that you have removed the 8304 completely, haven't you? You can't have both in at once, that won't work. But hopefully that should be very obvious!
I think you've made a typo above though as you've said P3 and not P4 (or P2 as it is on some later revision PCBs). The other thing is that you have removed the 8304 completely, haven't you? You can't have both in at once, that won't work. But hopefully that should be very obvious!
Yes, sorry typo!
Should have read P2 & R2! Anyway, I put in a socket in R2 and popped in a 74LS245, removed the faulty 8304 from P2, game then ran blind with DMAG0 disabled. So, I tried to renable DMAG0 and PCB went into TEST mode fine and ran in game for a few seconds, then crashed with PCB reseting rapidly.
LESSON: an IC must be either soldered in or socketed even for testing! I had assumed it would still make contact due to the solder holes being plated.
Now I cannot get TEST or game back up without disabling DMAG0.
On the scope all I see is a dot shifting quickly from left to right with each reset.
So, MPU is now fine need to work on Vector stage.
Equites2011-01-23 17:21:50
Should have read P2 & R2! Anyway, I put in a socket in R2 and popped in a 74LS245, removed the faulty 8304 from P2, game then ran blind with DMAG0 disabled. So, I tried to renable DMAG0 and PCB went into TEST mode fine and ran in game for a few seconds, then crashed with PCB reseting rapidly.
LESSON: an IC must be either soldered in or socketed even for testing! I had assumed it would still make contact due to the solder holes being plated.
Now I cannot get TEST or game back up without disabling DMAG0.
On the scope all I see is a dot shifting quickly from left to right with each reset.
So, MPU is now fine need to work on Vector stage.
Equites2011-01-23 17:21:50
guddler said:
Doh!
Okay, so I first eliminated the C8 PROM as being the problem, replaced it with a known good PROM, problem persists!
If I remove one of the RAMs, the PCB stops reseting and reports the bad RAM correctly. I read somewhere this indicates that the problem is in the vector drawing circuitry stage, any clues of where to try first dude?
Ok, I don't normally like trying to remotely debug these things but you're doing well so far so we'll give it a go. Next we want to see if we can narrow down the area of the problem since the DVG section takes up an entire side of the schematics so we'll be looking for a needle in a haystack if we don't.
If you look at the wiring diagram on the first page you'll see a pin called "Diag Step" at 'K'. Ground that. On my test rig I've got a wire soldered to that pin with a croc clip on the other end.
What that's going to do is put the board into a special test mode. First it will try to draw a single diagonal line across the screen. Then you hit hyperspace and it will do another step and another, and another. If we're lucky it'll do some of this before crashing. Depending on where it gets to before crashing will help us to know where to focus our efforts.
Rig it up like that and let me know if you get anywhere with this test at all. I don't think you need to ground the watchdog but I can't honestly remember.
If you look at the wiring diagram on the first page you'll see a pin called "Diag Step" at 'K'. Ground that. On my test rig I've got a wire soldered to that pin with a croc clip on the other end.
What that's going to do is put the board into a special test mode. First it will try to draw a single diagonal line across the screen. Then you hit hyperspace and it will do another step and another, and another. If we're lucky it'll do some of this before crashing. Depending on where it gets to before crashing will help us to know where to focus our efforts.
Rig it up like that and let me know if you get anywhere with this test at all. I don't think you need to ground the watchdog but I can't honestly remember.
Yup, that's the right pin. I don't think I stipulated but just to be sure - you need to permanently ground the pin with a jumper lead or something, not just momentarily like a switch. Just checking. You may also need to hit the reset switch and potentially ground / disable the watchdog. Can't honestly remember on that one.
Alright, well anyway, that does help us narrow it but not really by much.
To be able to draw a single line which is what the board tries to do in the first step the program counter needs to work, the state machine needs to work as does the ROM, RAM, buffer and latches, plus the vector timer. So unfortunately all you can really skip, for now is the section of the schems marked X & Y position counters. Even then, if that's faulty you still can't get a good display it won't look right but it shouldn't crash.
So now, you get to the point where I really can't talk you through much more without me sitting down with it on the bench and hooking it up to a Fluke 9100 or a logic analyser and writing some debugging test routines. Which I never got to over xmas - I got sidetracked into my project of writing some custom code for the PCB to run.
But I won't just leave it hanging there! I'll explain why I'm saying that
The state machine part of the circuit is basically the CPU and I/O of the customer processor. If any part that I previously described isn't functioning correctly the processor will lock up (disable the watchdog and try it!). So you only get a split second to make any kind of measurements before the lock up occurs. And that's not enough when you just have a manual approach. To have it constantly resetting won't help you.
This has been an issue for DIY repair for donkey's years. And the investment in both time and money that's needed to write the routines and have the hardware means that people who have done the repair routines for commercial purposes, understandably keep it close to their chests, it's not a small task
I think all you can do at this point is see if you're able to get any sense out of the glue logic around the prom. Are you getting activity, albeit briefly on HALT, /HALT, /DMAGO, /DMACNT, /GOSTROBE, /HALTSTROBE and so on. See if you can spot anything obviously suspicious.
But then it could just as easily be that the counters in the program counter section are not working correctly, or perhaps that one of the latches isn't letting the data out at the other end, or not letting the right data out and the right times? There really is a lot of things it could be now I'm afraid.
Alright, well anyway, that does help us narrow it but not really by much.
To be able to draw a single line which is what the board tries to do in the first step the program counter needs to work, the state machine needs to work as does the ROM, RAM, buffer and latches, plus the vector timer. So unfortunately all you can really skip, for now is the section of the schems marked X & Y position counters. Even then, if that's faulty you still can't get a good display it won't look right but it shouldn't crash.
So now, you get to the point where I really can't talk you through much more without me sitting down with it on the bench and hooking it up to a Fluke 9100 or a logic analyser and writing some debugging test routines. Which I never got to over xmas - I got sidetracked into my project of writing some custom code for the PCB to run.
But I won't just leave it hanging there! I'll explain why I'm saying that
The state machine part of the circuit is basically the CPU and I/O of the customer processor. If any part that I previously described isn't functioning correctly the processor will lock up (disable the watchdog and try it!). So you only get a split second to make any kind of measurements before the lock up occurs. And that's not enough when you just have a manual approach. To have it constantly resetting won't help you.
This has been an issue for DIY repair for donkey's years. And the investment in both time and money that's needed to write the routines and have the hardware means that people who have done the repair routines for commercial purposes, understandably keep it close to their chests, it's not a small task
I think all you can do at this point is see if you're able to get any sense out of the glue logic around the prom. Are you getting activity, albeit briefly on HALT, /HALT, /DMAGO, /DMACNT, /GOSTROBE, /HALTSTROBE and so on. See if you can spot anything obviously suspicious.
But then it could just as easily be that the counters in the program counter section are not working correctly, or perhaps that one of the latches isn't letting the data out at the other end, or not letting the right data out and the right times? There really is a lot of things it could be now I'm afraid.
guddler said:Yup, that's the right pin. I don't think I stipulated but just to be sure - you need to permanently ground the pin with a jumper lead or something, not just momentarily like a switch. Just checking. You may also need to hit the reset switch and potentially ground / disable the watchdog. Can't honestly remember on that one.
Alright, well anyway, that does help us narrow it but not really by much.
To be able to draw a single line which is what the board tries to do in the first step the program counter needs to work, the state machine needs to work as does the ROM, RAM, buffer and latches, plus the vector timer. So unfortunately all you can really skip, for now is the section of the schems marked X & Y position counters. Even then, if that's faulty you still can't get a good display it won't look right but it shouldn't crash.
So now, you get to the point where I really can't talk you through much more without me sitting down with it on the bench and hooking it up to a Fluke 9100 or a logic analyser and writing some debugging test routines. Which I never got to over xmas - I got sidetracked into my project of writing some custom code for the PCB to run.
But I won't just leave it hanging there! I'll explain why I'm saying that
The state machine part of the circuit is basically the CPU and I/O of the customer processor. If any part that I previously described isn't functioning correctly the processor will lock up (disable the watchdog and try it!). So you only get a split second to make any kind of measurements before the lock up occurs. And that's not enough when you just have a manual approach. To have it constantly resetting won't help you.
This has been an issue for DIY repair for donkey's years. And the investment in both time and money that's needed to write the routines and have the hardware means that people who have done the repair routines for commercial purposes, understandably keep it close to their chests, it's not a small task
I think all you can do at this point is see if you're able to get any sense out of the glue logic around the prom. Are you getting activity, albeit briefly on HALT, /HALT, /DMAGO, /DMACNT, /GOSTROBE, /HALTSTROBE and so on. See if you can spot anything obviously suspicious.
But then it could just as easily be that the counters in the program counter section are not working correctly, or perhaps that one of the latches isn't letting the data out at the other end, or not letting the right data out and the right times? There really is a lot of things it could be now I'm afraid.
Thanks Martin
I realise that at this stage I am out of my depth, although I know I have made some progress with the PCB.
As I said, the DIAG STEP had no effect, I had soldered a wire to the DIAG STEP and put a croc clip on the other end which was grounded to the PCB.
I did however, disable the WATCHDOG too, this did stop the resetting, and displayed what looked like a series of diagonal lines running from top to bottom, and what looked like some digits in the middle section. Looks as though it is trying to draw the TEST pattern.
This shows my lack of understanding, but what do you mean by getting some sense out of the logic around the PROM? How would I do that? I understand that HALT, /HALT, /DMAG0 etc... are low level commands but not sure what they do. I could do with some reading up on those.
Equites2011-01-24 12:54:43
Hmm, if it was still trying to draw the standard test pattern then that's not right. When you ground the diag step pin it's meant to go into a more debug type test routine. The first step of which is to just draw a single diagonal line from one corner to the other (can't remember which direction).
If it didn't do that then something's up there. I'll fire up the board that I have on the bench later to make sure I've got that right. And if I can find a PCB that works then I can show you what it's meant to do.
As for the other signals. The full description of what they do and what they are is on the schematics, though I confess to reading it for years before I really understood it! Essentially what I mean is to test for the usual things, stuck lines etc. on those pins. But you're getting into the realms of stuff that you can't really do with just a logic probe and / or scope now due to the fatc the state machine will lock up.
If it didn't do that then something's up there. I'll fire up the board that I have on the bench later to make sure I've got that right. And if I can find a PCB that works then I can show you what it's meant to do.
As for the other signals. The full description of what they do and what they are is on the schematics, though I confess to reading it for years before I really understood it! Essentially what I mean is to test for the usual things, stuck lines etc. on those pins. But you're getting into the realms of stuff that you can't really do with just a logic probe and / or scope now due to the fatc the state machine will lock up.
Dudes
Spent a fair bit of time with the PCB over the weekend, I resorted to using the piggy-backing method to see if I could stop the PCB reseting.
Since the PCB had run without disabling DMAG0 for a few seconds initially when I solved the RAM shorting and buffer issue, I thought it was probably just one IC that had failed.
I struck lucky as I found a bad LS193 counter at H5, so I desoldered the bad LS193 and put in a socket and a fresh LS193. PCB now ran without disabling the DMAG0!
So I got the scope out again and hooked it up to the XY on the PCB, all i got was a thin vertical line in the middle of the scopes screen. However, when I looked carefully I could see the there was varying levels of brightness in the line and things appeared to be moving along the thin line. Switching to TEST presented me with a static line. Again, moving to the game mode the line appeared to have activity, I could see what looked like bullets moving quickly along the line when I fired in a game.
Looked like I was looking at a squashed screen, I had no X deflection. So I de-soldered the DACs for X and Y and placed some sockets on the PCB. I then swapped the DACs and I now had a thin horizontal line, Y deflection gone but X was now present.
I knew at that point that the DAC originally for X was bad, so I swapped it out and got this image in TEST;
A TEST pattern! Looked a bit fuzzy though, this is the sharpest I could get it using the FOCUS knob on the scope. I then switched to game mode and got this;
ASTEROIDS!!!!
However, the screen still looked fuzzy, I could not see the ATARI copyright at the bottom or the scores at the top, the Asteroid ship appeared to be a bright dot. I adjusted the X and Y pots and did see some improvement in scaling but still no scores or ATARI copright message at the bottom.
Also, the screen in attract mode appears to be bouncing by about 5mm up and down every second, not sure why.
So, I replaced all the ICs in the Output stage, which were the TL081's, TL082's and the 4016's;
The noisy fuzzy image is now replaced with a much sharper image;
Game mode;
Much better, but screen is still bouncing in attract mode (did'nt try actual game play) and still cannot see the Asteroid ship which appears to be a dot, and no scores or ATARI copyright message either.
I was not sure if this was due to the limitations of the scope, so decided to go for it and fire up the monitor for the first time.
I expected to hear a crackle but heared nothing, the screen appeared to be dead, no life at all. Looking at the deflection board I saw no LED (Spot Killer) lit. No chatter from the deflection (not that I know what it sounds like) but the neck on the tube was glowing.
At this point, I called it a day, I really did have enough.
Any suggestions on the monitor dudes?
Equites2011-01-27 09:50:50
Spent a fair bit of time with the PCB over the weekend, I resorted to using the piggy-backing method to see if I could stop the PCB reseting.
Since the PCB had run without disabling DMAG0 for a few seconds initially when I solved the RAM shorting and buffer issue, I thought it was probably just one IC that had failed.
I struck lucky as I found a bad LS193 counter at H5, so I desoldered the bad LS193 and put in a socket and a fresh LS193. PCB now ran without disabling the DMAG0!
So I got the scope out again and hooked it up to the XY on the PCB, all i got was a thin vertical line in the middle of the scopes screen. However, when I looked carefully I could see the there was varying levels of brightness in the line and things appeared to be moving along the thin line. Switching to TEST presented me with a static line. Again, moving to the game mode the line appeared to have activity, I could see what looked like bullets moving quickly along the line when I fired in a game.
Looked like I was looking at a squashed screen, I had no X deflection. So I de-soldered the DACs for X and Y and placed some sockets on the PCB. I then swapped the DACs and I now had a thin horizontal line, Y deflection gone but X was now present.
I knew at that point that the DAC originally for X was bad, so I swapped it out and got this image in TEST;
A TEST pattern! Looked a bit fuzzy though, this is the sharpest I could get it using the FOCUS knob on the scope. I then switched to game mode and got this;
ASTEROIDS!!!!
However, the screen still looked fuzzy, I could not see the ATARI copyright at the bottom or the scores at the top, the Asteroid ship appeared to be a bright dot. I adjusted the X and Y pots and did see some improvement in scaling but still no scores or ATARI copright message at the bottom.
Also, the screen in attract mode appears to be bouncing by about 5mm up and down every second, not sure why.
So, I replaced all the ICs in the Output stage, which were the TL081's, TL082's and the 4016's;
The noisy fuzzy image is now replaced with a much sharper image;
Game mode;
Much better, but screen is still bouncing in attract mode (did'nt try actual game play) and still cannot see the Asteroid ship which appears to be a dot, and no scores or ATARI copyright message either.
I was not sure if this was due to the limitations of the scope, so decided to go for it and fire up the monitor for the first time.
I expected to hear a crackle but heared nothing, the screen appeared to be dead, no life at all. Looking at the deflection board I saw no LED (Spot Killer) lit. No chatter from the deflection (not that I know what it sounds like) but the neck on the tube was glowing.
At this point, I called it a day, I really did have enough.
Any suggestions on the monitor dudes?
Equites2011-01-27 09:50:50
Excellent - always nice to strike it lucky like that
As far as the picture on your scope is concerned it just looks to me like you have your volts per division set wrong in the Y axis. Doesn't look to be anything more than that.
Haven't played about with a vector monitor in ages I'm afraid. Other people on here have though.
As far as the picture on your scope is concerned it just looks to me like you have your volts per division set wrong in the Y axis. Doesn't look to be anything more than that.
Haven't played about with a vector monitor in ages I'm afraid. Other people on here have though.
guddler said:Excellent - always nice to strike it lucky like that
As far as the picture on your scope is concerned it just looks to me like you have your volts per division set wrong in the Y axis. Doesn't look to be anything more than that.
Haven't played about with a vector monitor in ages I'm afraid. Other people on here have though.
Thanks dude, the scope was still connected so I ran back and fired her up, and played with the VOLTS per DIV for both channels and got the pictiure looking 100% like Asteroids, bouncing has now gone, hitting the THRUST button the Asteroid ship emerged from behind the bright dot in the centre of the scopes screen. So, the dot is being generated by the scope, I assume this is due to lack of Z input?
So PCB is working for now, roll on the monitor fix.
Equites2011-01-27 00:34:00
yes, monitor shrouds are stapled in place, carefulyl remove the staples, try not to rip any of it. once removed you'll see the bolts holding the frame in place.
From your earlier post, some notes:
1) you wont hear any crackle from the HV, b/w tubes don't create much, especially not little ones.
2) neck glow is not an indicator of good HV, the heater element voltage is derived from the power brick unlike a raster monitor where it comes from the HV transformer.
Does your scope not have a Z input on the rear? can you disconnect the game video signal as it is and post a photo of what you see on the Z signal? you should set your scope to 2v/div and 1 or 2ms/dv.
From your earlier post, some notes:
1) you wont hear any crackle from the HV, b/w tubes don't create much, especially not little ones.
2) neck glow is not an indicator of good HV, the heater element voltage is derived from the power brick unlike a raster monitor where it comes from the HV transformer.
Does your scope not have a Z input on the rear? can you disconnect the game video signal as it is and post a photo of what you see on the Z signal? you should set your scope to 2v/div and 1 or 2ms/dv.
P-Man said:
Hi Andy
Thanks for the feedback, you got me thinking now and I know what you are getting at. If the monitor is not receiving a Z input the screen will appear dead. So, potentially still a PCB problem here. Still, if I turn the brightness up all the way on the monitor I should still see something on the monitor even with bad Z input right??
I will hook up the scope later tonight as you suggested and let you know what I find, Im not sure if the scope has a Z input, do not recall seeing one to be honest but will check.