Partially working Warlords PCB

Franklin

Well-known member
Joined
May 25, 2006
Messages
1,629
Reaction score
113
Location
Caledonia, Wisconsin
I picked up a Warlords, and initially I'm getting a screen that looks very much like the test screen (I have toggled back and forth, no clear errors indicated on the test screen).

Anyone have an idea if there is a likely chip/culprit? I don't have much on hand for chips/swapping so I'm either going to have to order some parts or send the board out for repair. I'd rather not shotgun a parts order without trying to narrow it down, and if it's just one chip I'd rather not send out for repair.

Here's a pic of what I'm getting:
 

Attachments

  • warlords.jpg
    warlords.jpg
    96.2 KB · Views: 68
Any beeps?

One thing to try is cleaning the graphics eprom(s) and re-inserting them.

Bill
 
Most likely a bad ram; they fail often on these causing these sorts of patterns. Sometimes you can't even see the words "BAD RAM" on the test screen because of the garbage characters.
 
Most likely a bad ram; they fail often on these causing these sorts of patterns. Sometimes you can't even see the words "BAD RAM" on the test screen because of the garbage characters.

If you get some ram chips, you can piggy back one ontop of suspect bad one for testing.
 
Watching the thread! I have a board with similar symptoms that I need to fix. Have to make a jamma adapter first.
 
Watching the thread! I have a board with similar symptoms that I need to fix. Have to make a jamma adapter first.


I made one awhile ago - I used a single 5K pot and a set of dip switches to choose which Pokey input the pot would be connected to.

Also added a switch to select between upright and cocktail.

Bill
 
Made a simple jamma adapter to work on my Warlords board. Here's what I'm getting. Haven't wired up test mode yet, and I hard-wired it for cocktail mode since that's all I really care about:

http://www.youtube.com/watch?v=JeVeJGON-lU

Someone else already verified the ROMs and they are fine. Is interesting that the background is consistently the same wrong thing. I wonder if a bit is getting stuck somewhere in addressing or RAM?
 
I would bet bad ram (2102 or 2101 if I recall).

If you're looking for a "chip at location x-y is bad" answer, you're not going to get it; not even the internal test mode will give u that. It needs to be troubleshot with a logic probe/pulser.

I can fix these boards but wouldn't be able to get to it til after the holidays.
 
ImageUploadedByTapatalk1322103023.630460.jpg

Looks like bad RAM as far as the test mode is concerned. Will get a logic probe/pulser and figure out how to debug this. I have a junker board that I need to practice replacing chips with sockets on before I try to fix his

Excellent!
 
View attachment 90741

Looks like bad RAM as far as the test mode is concerned. Will get a logic probe/pulser and figure out how to debug this. I have a junker board that I need to practice replacing chips with sockets on before I try to fix his

Excellent!

Wow, the uploaded/down-res'd image is unreadable! Anyways, I'm getting BAD RAM in test mode.

For the thread-starter, what does your screen look like in test mode? I suspect that you'll be able to make sense of it even with what you are seeing now. I think you'll only get one line of text ("BAD RAM") if you have bad RAM and it won't say a thing about ROM. if I run test mode in Mame, you get a line about RAM being okay, and a line about ROM being okay.
 
For the thread-starter, what does your screen look like in test mode? I suspect that you'll be able to make sense of it even with what you are seeing now. I think you'll only get one line of text ("BAD RAM") if you have bad RAM and it won't say a thing about ROM. if I run test mode in Mame, you get a line about RAM being okay, and a line about ROM being okay.

Nevermind. I only see one of the test result lines because of my own RAM problem.

Looks like in my case the video RAM reads may be wrong based on the address: 16 bytes of corruption, 32 bytes of goodness, 16 bytes of corruption, repeat. . .
 
From Mame (Warlords is in centiped.c), looks like tile RAM is at 0x0400:

0400-07BF Screen RAM (8x8 TILES, 32x32 SCREEN)

I have a USB logic analyzer. . . I could hook that up and see what reads to the known addresses are returning. Can see in Mame what is supposed to be there with "mame -debug -window warlords" in a memory window.

I'm unclear about how memory gets mapped to particular regions in hardware. I know some example addresses that may be returning incorrect data (0x0400 for instance). . how do I map that to a particular chip?
 
Looks like the upper 4 bits are stuck on for addresses that are the first 16 bytes of a 64 byte chunk. I can manually replace the upper nibble of each byte with all ones in Mame in the memory window and get the same results as I get on the broken hardware. I'm guessing that a chip is bad and the memory is paged such that this is the result.
 
I picked up a Warlords, and initially I'm getting a screen that looks very much like the test screen (I have toggled back and forth, no clear errors indicated on the test screen).

Anyone have an idea if there is a likely chip/culprit? I don't have much on hand for chips/swapping so I'm either going to have to order some parts or send the board out for repair. I'd rather not shotgun a parts order without trying to narrow it down, and if it's just one chip I'd rather not send out for repair.

Here's a pic of what I'm getting:

Have a ROM burner? Verified the ROMs yet? Is the fireball clear? Curious if it is background graphics only or sprites too.
 
I got the board from Larry and FIVE, yes five, of the 2101s were bad. They were AMD 2101A-2s. I pulled and socketed the remaining three "good" ones as well and will send Larry three 2101s as spares in case he has a similar problem in the future with the remaining three or one of the replacements.

A purist repair guy would pull out his favorite troubleshooting tools, fire 'em up and run testscripts, etc.

But a very easy quick and dirty test is (OK Spaeth and a few other "purist" repair guys should not read the rest of this) to piggyback a couple of 2101s over the board mounted ones and see if the picture improves. Then replace the offenders. This does not always work depending upon the failure mode of the ram and you may get mixed results but after working on my share of Atari boards, I can tell if the PB is effective in most cases. If not, then I crack out the "heavy artillery" test equipment. 2101s are a failure point in the Atari boards - Centipedes and Millipedes use 2101s as well. I have a healthy stock of 2101s and the .4" sockets for these RAMs as you should always socket the replacements.

I also find the EPROM sockets used on the run of the Warlords boards were very prone to being intermittent so I automatically replace all eight of the 24 pin EPROM sockets with dual wipes on any Warlords PCB that comes across my repair bench.

At least for Larry, Case closed.

I think I earned the right to partially hijack this thread - I am looking for a Warlords PCB, untested or non working, and will trade repair work or pay cash - see my WTB post

Bill
 
Turned out that one of my 2101 rams is spitting out 0xF all the time. I figured that was the case since I could type in 0xF directly into the high nibble of video ram addresses in Mame and reproduce my problem. I suspect that another RAM is bad since it looks like 1/4 of the nibbles in VRAM are 0xF.

I'll run over to Vetco today to see if they have some 2101 chips.
 
Just noticed I never followed up. Two rams were bad. Fixed!

Glad you got it working. I recommend replacing the rom sockets before they become a problem. Most of the warlords that I have repaired had intermittent ROM sockets. I replace all of them as a preventative on any Warlords boards that I repair.

Bill
 
From Mame (Warlords is in centiped.c), looks like tile RAM is at 0x0400:

0400-07BF Screen RAM (8x8 TILES, 32x32 SCREEN)

I have a USB logic analyzer. . . I could hook that up and see what reads to the known addresses are returning. Can see in Mame what is supposed to be there with "mame -debug -window warlords" in a memory window.

I'm unclear about how memory gets mapped to particular regions in hardware. I know some example addresses that may be returning incorrect data (0x0400 for instance). . how do I map that to a particular chip?

could you school me on this a bit more?

I am trying to reproduce some errors on other boards that I am working on and would like to simulate a hardware problem and how it affects the program. Also I don't really understand the addressing magic of these boards so, I need some good reads on this as well.
 
Back
Top Bottom