Asteroids Troubles

JoeB1355

Well-known member
Joined
Dec 11, 2010
Messages
1,631
Reaction score
99
Location
Seymour, Tennessee
I picked a an asteroids last weekend supposedly working -- but not really after I got it home

so it looks like things get stretched (or blanked to a line) on the screen as they pass through certain areas

I just got cap kits from Bob for the board, ar board, monitor and installed them. I even got a new big blue -- no change....

Test passes but I only get one column of cross hatch

Here's a couple videos
http://www.youtube.com/watch?v=hbCjVymFDrk
http://www.youtube.com/watch?v=h4WuODOpD7g

and a video of the test page
http://www.youtube.com/watch?v=s9rmYHlzYEQ

Any help of what to check next?

PS I have another board that ram chip 3 always reports bad -- but I socketed and ohm'd out all the connections and tried 4 chips

any help on either or both appreciated!
 
Last edited:
Look like an issue with the X position counter circuit, to me (or perhaps the X-axis DAC).

This section changed a fair amount thru PCB revs, so it's pointless to try quoting IC locations without knowing your board's dash number.

PS- on the other board, if you've replaced all the RAM with known-good RAM, and it still reports bad, maybe check the address decoding circuitry. I think the 3rd RAM chip is in vector RAM, so it's not in the section of the schems labeled "address decoding," but rather on the sheet with the rest of the vector generator.
 
Last edited:
The PCB is marked -02, but so is my board with the ram issue and the vector section and test points are different on each board. The bad ram board has an extra 4 pos switch too

so not sure how to accurate say what I got I can surely take a pic of both though
 
Look like an issue with the X position counter circuit, to me (or perhaps the X-axis DAC).

This section changed a fair amound thru PCB revs, so it's pointless to try quoting IC locations without knowing your board's dash number.

PS- on the other board, if you've replaced all the RAM with known-good RAM, and it still reports bad, maybe check the address decoding circuitry. I think the 3rd RAM chip is in vector RAM, so it's not in the section of the schems labeled "address decoding," but rather on the sheet with the rest of the vector generator.

On the bad ram board I get 2 hi and 1 low tone the manual I have states M4 is bad. I only socketed M4 and the chip next to it on the left -- This was a hacked board I got for free a long time ago it had M4 socketed with a huge machine pin sock sticking up and inch -- some trace damage and jumpers -- it didn't work so I took of the bad socket off and cleaned up the damage and corrosion for age old flux and socketed the chip next to it so I could put jumpers on the back for the bad traces

I cleaned it all took pics of the traces and checked them vs my unhacked board -- I wonder though if this is the troubles whomever had before since this chips always reports bad probably some decoding circuit
 
Last edited:
The PCB is marked -02, but so is my board with the ram issue and the vector section and test points are different on each board. The bad ram board has an extra 4 pos switch too

so not sure how to accurate say what I got I can surely take a pic of both though

The "dash number" (i.e. -02) indicates the type or layout of the PCB. -01 thru -04 were all very similar, with the odd numbers for PCBs populated with PROMs and the -02 & -04 for PCBs with the ROMs. (I've never actually seen an Asteroids with the PROMs.) I also cannot discern any difference between the -02 and -04. However, the -05 and -06 do have a rather different layout. They can be identified by the fact that the IC columns are numbered 2-13 (vice 1-12 for the -01 thru -04 boards).

In addion to the dash number, there were PCB revisions. The -01 thru -04 board types had revisions A thru H.

The 4-position switch was added at Rev C. So your board w/o it must be a Rev A or B. (incidentially, it won't support video inversion for cocktail mode, which was also added in Rev C).

BTW, the 4-pos switch is for additional credit options. Only 2 of the switches are used. Their functions can also be accomplished with Rev A or B boards (which lack the switch) with split pads.

Some high-resolution pics of your PCB(s) would be nice.
 
Last edited:
On the bad ram board I get 2 hi and 1 low tone the manual I have states M4 is bad. I only socketed M4 and the chip next to it on the left -- This was a hacked board I got for free a long time ago it had M4 socketed with a huge machine pin sock sticking up and inch -- some trace damage and jumpers -- it didn't work so I took of the bad socket off and cleaned up the damage and corrosion for age old flux and socketed the chip next to it so I could put jumpers on the back for the bad traces

I cleaned it all took pics of the traces and checked them vs my unhacked board -- I wonder though if this is the troubles whomever had before since this chips always reports bad probably some decoding circuit

OK, since it was hacked up a little...

Double/triple check that all of the data and address lines are connected to the bus (buzz them out with the legs of the other RAM ICs or better still to the appropriate data and address lines of a vector ROM. Do the same with the write-enable line. Also make sure the +5 and GND on all the RAMs is good. All this is to make sure the hack job has been fully repaired, and no traces are broken (and not jumpered).

Make sure that you have a good 2114 (try a couple or few in there if you can).

Once you're confident that the 2114 is good, and the PCB traces/wiring is good... see if it still gives an error. If so, it's time to break out a logic probe and start working thru the chip-select path. Get sheet 02A of the schematic (4th printing) and look in the top middle for "VECTOR GENERATOR RAM." At the bottom of that box, you'll see that each RAM has a "CS" line. They're connected to a couple of gates in the 74LS32 @ M5. Then thru an inverter in the 74LS04 @ L5. Then they "disappear" as the "\VRAM" and "AM10" lines. Go one box to the left, "VECTOR GENERATOR MEMORY ADDRESS SELECTOR," and you'll see where both of these lines originate. \VRAM comes out of the 74LS139 @ L3, and AM10 out of the 74LS157 @ J3. It's also possible that any of the LS157s that allow sharing of the address lines between the 6502 and vector generator could prevent the RAM test from passing (F3, H3, J3 & K3). Or the buffer that connects the vector generator data bus to the MPU data bus ("VECTOR GENERATOR DATA BUFFER").
 
Last edited:
The PCB is marked -02

OK, getting back to your original post/problem. If that PCB is a -02 w/o a 4-pos dip switch, that would seem to make it pre-Rev C. The 1st printing schems would seem to be the right ones to look at for the X and Y position counters.

Looking at your video, it appears that the screen is horizontally divided up in to 8 sections: 4 which look "good" and 4 which look "bad", alternating (bad/OK/bad/OK/bad/OK/bad/OK). Screen coords are 10-bit (0-1023), so this would imply a problem with the 8th-least-significant bit. This would normally be called "bit 7", but Atari numbered the lines 1-8 in this case (not 0-7), so it's the DACX8 line that I'd guess is stuck high.

If you have a logic probe or scope, check pin 7 of the LS399 @ E10 (or pin 11 on the DAC @ D11) and see if it's pulsing or constantly high.

Following that upstream... if my theory is correct, it could be: the X DAC (AD561J @ D11), the multiplexer (LS399@ E10), or the counter (LS191 @ D9). Further probing could narrow it down.
 
Last edited:
OK, getting back to your original post/problem. If that PCB is a -02 w/o a 4-pos dip switch, that would seem to make it pre-Rev C. The 1st printing schems would seem to be the right ones to look at for the X and Y position counters.

Looking at your video, it appears that the screen is horizontally divided up in to 8 sections: 4 which look "good" and 4 which look "bad", alternating (bad/OK/bad/OK/bad/OK/bad/OK). Screen coords are 10-bit (0-1023), so this would imply a problem with the 8th-least-significant bit. This would normally be called "bit 7", but Atari numbered the lines 1-8 in this case (not 0-7), so it's the DACX8 line that I'd guess is stuck high.

If you have a logic probe or scope, check pin 7 of the LS399 @ E10 (or pin 11 on the DAC @ D11) and see if it's pulsing or constantly high.

Following that upstream... if my theory is correct, it could be: the X DAC (AD561J @ D11), the multiplexer (LS399@ E10), or the counter (LS191 @ D9). Further probing could narrow it down.

Thanks -- you definitely got me in the right direction X counter circuit and you were right on for line 8

I had a bunch of trouble with my crappy old scope -- still not resolved but worked enough for me to get some probes

Grabbed a schematic and tested all the DAC lines tracking them to the counter at D9 all the other lines coming our at c9, d9, and e9 looked good except pin 7 on D9 all the inputs looks good to the 3 chips so I pulled D9 and put in a socket and reinstalled with pin 7 out pin 7 was still bad so I did have to go to the 399 --

I didn't have any spares so I robbed it from bad ram board

Viola it works great now!!!

Thanks for getting me right exact right spot with just a video!
 
Last edited:
Still having trouble here though -- I tried many 2114's so I pretty sure thats not the issue.

Again I'm using my crappy scope so hard to get any timings, but I did see strobes on the chip selects ech ram chip even M4

I think something bigger may be a foot as there is no action on the data lines or address lines after start up the 2 cpu ram chips have lots of activity. Maybe this is normal since the game is not working

So I read how its supposed to enable cpu access to the VG RAM -- I think maybe somethings bad here? Not sure I check all the VMEM VG etc and all appear to get some strobes on reset -- I'll have to test further. Could be bad pulses -- but some acticity -- I gotta get this stupid scope working right again....

Do you think I should see activty on the data lines or address lines to any of the 4 VG RAM chips if self test fails?


I wasn't getting anywhere so I work on the other board and found something just like you said and its fixed! so now I have to find something here ;>


OK, since it was hacked up a little...

Double/triple check that all of the data and address lines are connected to the bus (buzz them out with the legs of the other RAM ICs or better still to the appropriate data and address lines of a vector ROM. Do the same with the write-enable line. Also make sure the +5 and GND on all the RAMs is good. All this is to make sure the hack job has been fully repaired, and no traces are broken (and not jumpered).

Make sure that you have a good 2114 (try a couple or few in there if you can).

Once you're confident that the 2114 is good, and the PCB traces/wiring is good... see if it still gives an error. If so, it's time to break out a logic probe and start working thru the chip-select path. Get sheet 02A of the schematic (4th printing) and look in the top middle for "VECTOR GENERATOR RAM." At the bottom of that box, you'll see that each RAM has a "CS" line. They're connected to a couple of gates in the 74LS32 @ M5. Then thru an inverter in the 74LS04 @ L5. Then they "disappear" as the "\VRAM" and "AM10" lines. Go one box to the left, "VECTOR GENERATOR MEMORY ADDRESS SELECTOR," and you'll see where both of these lines originate. \VRAM comes out of the 74LS139 @ L3, and AM10 out of the 74LS157 @ J3. It's also possible that any of the LS157s that allow sharing of the address lines between the 6502 and vector generator could prevent the RAM test from passing (F3, H3, J3 & K3). Or the buffer that connects the vector generator data bus to the MPU data bus ("VECTOR GENERATOR DATA BUFFER").
 
Last edited:
Thanks -- you definitely got me in the right direction X counter circuit and you were right on for line 8

Viola it works great now!!!

Thanks for getting me right exact right spot with just a video!

Glad you got it working. Thank you for posting a follow-up with the outcome. And for posting a video from the outset; people would be surprised what information can (sometimes) be gleaned from a video of the problem.

Good to hear it wasn't the DAC. Those things are pricey.
 
I think something bigger may be a foot as there is no action on the data lines or address lines after start up the 2 cpu ram chips have lots of activity. Maybe this is normal since the game is not working

So I read how its supposed to enable cpu access to the VG RAM -- I think maybe somethings bad here? Not sure I check all the VMEM VG etc and all appear to get some strobes on reset -- I'll have to test further. Could be bad pulses -- but some acticity -- I gotta get this stupid scope working right again....

Do you think I should see activty on the data lines or address lines to any of the 4 VG RAM chips if self test fails?

I think you're onto something here. The CS on the VG RAM appears to be working, and you're confident that your RAM is good, but you're not seeing activity on the address or data lines... (esp. when you switch out of test mode and into game mode). Is the \VMEM line (sheet 1B in "Address decoding" section) stuck high (pin 10 on the LS139 @ E4)?? That's the control line that allows the MPU side to access the VG's RAM; if it doesn't go low, the 6502 can never get to the address lines of the VG RAM.

I'll pull out the logic probe and see what activity I see on the VG RAM add'y & data lines, but there's gotta be something going on there (esp the low bits of the address bus). The 6502 has to put stuff in the VG RAM in order to draw ANYTHING on the screen...
 
Back
Top Bottom