Fluke 9010A Newbie

troxel

Well-known member

Donor 7 years: 2015-2021
Joined
Mar 19, 2006
Messages
2,084
Reaction score
104
Location
Lincoln, Nebraska
I got a Fluke a while back and read up about it, but not quite sure how to get testing a pcb. I have a Sea Wolf that is not working and would like to test it out.

Can someone walk me through the setup and process? I have watched a few videos by ajcrm125, and will rewatch those again, but thought I would ask for any input.

Thanks!
 
I got a Fluke a while back and read up about it, but not quite sure how to get testing a pcb. Can someone walk me through the setup and process?
There's not too much setup. Remove the CPU, install the pod in that socket, apply power. From there you want to check various things that might prevent the game from running:

- Bus test. I've never had this tell me anything useful, but it checks for address / data lines shorted together.

- ROM. Do the rom test and check the checksums against known values, usually from MAME. See quarterarcade (here) for a bunch of precalculated values. Depending on the value suspect a bad connection (bad socket?) between the CPU and the ROM chip, bad EPROM, or possibly bad address decoding.

- RAM. Do the short memory test to make sure you can read/write to each chip. Again you might find the memory ranges for RAM published on quarterarcade (here) but sometimes you'll need to go back to the schematic to calculate the memory range yourself.

Occasionally you'll get an active force line (like stuck reset) but more often that's a false alarm because a watchdog keeps going off because the code is not running normally. Note there's PC software to do scripting but I feel like this is a tremendous waste of time unless you're doing the same board a million times in a row. I really only use the buttons and command it to run each test manually.

Once you think you've resolved the problem, you can "Run UUT" to make it run normally (as if the CPU were reinstalled). This usually works, but not always, so also consider reinstalling the real CPU when you want to run a real test.
 
Tried doing a bus test and got an error message saying the ,"bad pwr supply-loop?". Is this a board issue or fluke issue?
 
Did you have the board powered on when you did the bus test?

If you have not already you should google the 9010a user guide and the guide for the pods you use and read them first they will give you a good introduction to what you need to know about using the fluke and the test available and how to interpret the results.

Once you understand the basics of the fluke you can ask the questions on how to use it to help diagnose your board. Which is much harder than using the tools itself.

Good luck.
 
Tried doing a bus test and got an error message saying the ,"bad pwr supply-loop?". Is this a board issue or fluke issue?
As above, consult the manual for all error messages. This one means that the fluke pod does not see good voltage on the processor pins; from its perspective the CPU is unpowered. Check that the power is turned on. Check that voltage is getting to the processor (with your DMM). On rare occasion I see this message when the voltage is slightly low, but still enough to run things in the real world.
 
As above, consult the manual for all error messages. This one means that the fluke pod does not see good voltage on the processor pins; from its perspective the CPU is unpowered. Check that the power is turned on. Check that voltage is getting to the processor (with your DMM). On rare occasion I see this message when the voltage is slightly low, but still enough to run things in the real world.

here is the manual for that Fluke 9010a..

http://tinymicros.com/mediawiki/images/2/2d/Fluke_9010A_Operater_Manual.pdf
 
Thanks for the links. Been reading quite a bit. A couple of questions that I have run into so far. When I run a bus test, I get "active force line loop?" prompt. I have "no" in the setup menu . Not sure what to do here.

Also, how do you figure out the range for a Ram test? Can someone walk me through Sea Wolf or Taito Arkanoid?

Thanks again!
 
are you sure you disabled the active force line in the setup menu?

In regards to the memory addresses you need to already know this information. Fortunately most of this info can be retrieved via the MAME documentation

go to the link below
http://mamedev.org/source/src/mame/drivers/index.html



then choose your game.

example
http://mamedev.org/source/src/mame/drivers/arkanoid.c

Keep in mind though not all games are directly mentioned in a source file of their own. as some games are all covered under one source file.
for example

the midway MCR 3 based games are all covered under the source file mcr3.c

Each source code page has lots of comments usually some more than others, some detail things very easily, others look for the "memory map" section and read that directly.

Thanks for the links. Been reading quite a bit. A couple of questions that I have run into so far. When I run a bus test, I get "active force line loop?" prompt. I have "no" in the setup menu . Not sure what to do here.

Also, how do you figure out the range for a Ram test? Can someone walk me through Sea Wolf or Taito Arkanoid?

Thanks again!
 
Last edited:
...adding a little to what brzezicki said:

Sea Wolf is a Midway 8080 game, and thus will be found in this driver:
http://mamedev.org/source/src/mame/drivers/mw8080bw.c.html

AFAIK, all the Midway 8080 games have the same amount RAM, in the same location in memory.

If you are MAME-driver-averse, sometimes there is memory map in the game documentation (manual, schematics, etc.), esp Atari games.

Also, you can skip the MAME drivers and go straight for the schematics :) Just follow the address lines to the decoders, and work out the logic ;) Seriously, this is often how it done first, before it was documented in the MAME drivers. This method meets problems when a custom IC, or PROM, is used for address decoding.
 
When I run a bus test, I get "active force line loop?" prompt. I have "no" in the setup menu . Not sure what to do here.
This is documented in the table 4F-1 of the operating manual. Active Force Line indicates that the pod detected some error during the test. Remember it's showing you only one line of text at a time. If you hit "more" it should advance to the next line of text "STS BITS bbbb bbbb bbbb bbbb - LOOP?" which is a bit-by-bit view of which errors are active.

Look at the table written on the pod (or pod manual) to interpret which error is represented by each bit. For example on an 8080 pod if it was telling you STS BITS 1000 0000 then I'd expect that to mean "detected power fail". What you could do is:

a) Hit loop to make it keep repeating the test while you mess with the board (wiggle a connector, etc). It doesn't make sense in this situation because this is not an intermittent problem.

b) Hit stop to clear the message and drop back to the main menu.

c) Go back to the setup menu and disable specific force lines. For example you might disable the check for "power fail" but this rarely makes sense because the pod is telling you of a real problem.

Also, how do you figure out the range for a Ram test? Can someone walk me through Sea Wolf or Taito Arkanoid?
As mentioned, you could check the documents on quarterarcade or MAME. In this case Midway had a repair guide (here) that provides a lot of useful information.

Ordinarily you'd need look at the schematic, find the RAM chips, find what controls the chip enable, and work out the conditions (usually certain address lines high/low) that result in the chip being enabled. This is a rather complex circuit on Sea Wolf. I couldn't find the schematic for arkanoid. So I can't walk you through the process as easily as on other games.
 
Thanks for all the information. A lot that i need to go through. I had that same bus error with a 8080 and z80 pods. The arkanoid was just the first pcb that i found with a z80 and found it odd that i had that error with both pcbs. Mi'lldig a liitle deeper and see what i can find.

Joey--can you walk me through the process on another game of your choice? I think it would be very helpful.

Thanks again for all the help!
 
Joey--can you walk me through the process on another game of your choice? I think it would be very helpful.
Well from scratch, let's say you suspect a bad ROM on your Kickman. Check the schematic, it shows:

attachment.php


Note the 74ls138 which is a 3-to-8 decoder (here). Its inputs are {A14, A13, A12} and enabled when A15 is low. So for every combination A15=0 and:

A14=0 A13=0 A12=0 -- selects pin 15, connected to rom0 (B3)
A14=0 A13=0 A12=1 -- selects pin 14, connected to rom1 (B4)
A14=0 A13=1 A12=0 -- selects pin 13, connected to rom2 (B5)
A14=0 A13=1 A12=1 -- selects pin 12, connected to rom3 (D4)
A14=1 A13=0 A12=0 -- selects pin 11, connected to rom4 (D5)
A14=1 A13=0 A12=1 -- selects pin 10, connected to rom5 (D6)
A14=1 A13=1 A12=0 -- selects pin 9, connected to rom6 (D7)
A14=1 A13=1 A12=1 -- selects pin 7, connected to sel7 (jumps to nvram)

To make it more obvious, work out the address bits:

Code:
chip address (binary)    address range (hex)
rom0 b0000xxxxxxxxxxxx = 0x0000-0x0fff
rom1 b0001xxxxxxxxxxxx = 0x1000-0x1fff
rom2 b0010xxxxxxxxxxxx = 0x2000-0x2fff
rom3 b0011xxxxxxxxxxxx = 0x3000-0x3fff
rom4 b0100xxxxxxxxxxxx = 0x4000-0x4fff
rom5 b0101xxxxxxxxxxxx = 0x5000-0x5fff
rom6 b0110xxxxxxxxxxxx = 0x6000-0x6fff

Now that you've worked it out manually, compare against the info you get online:

Quarter Arcade (here) go down to "Rom Regions" and see the memory ranges, the names of the corresponding MAME ROMs. This is great because it also shows the expected CRC as calculated by the Fluke ROM test.

Mame mcr.c source (here) usually has some info in the comments at the top of the file, but you can go down in the code where this is defined:

Code:
 ROM_START( kickman )
    ROM_REGION( 0x10000, "maincpu", 0 )
    ROM_LOAD( "1200-a-ur.b3",  0x0000, 0x1000, CRC(d8cd9f0f) SHA1(a55f4423d57510256fb9b20b1bded06636c7bd05) )
    ROM_LOAD( "1300-b-ur.b4",  0x1000, 0x1000, CRC(4dee27bb) SHA1(b411d0c05339ae92732c89a4d0b7038d6b360475) )
    ROM_LOAD( "1400-c-ur.b5",  0x2000, 0x1000, CRC(06f070c9) SHA1(02eb19296e6c32544041ab5bf3dbb5a4f20c8ace) )
    ROM_LOAD( "1500-d-ur.d4",  0x3000, 0x1000, CRC(8d95b740) SHA1(93287324b599ec50dd84cc2dc70e82ccd8314a8a) )
    ROM_LOAD( "1600-e-ur.d5",  0x4000, 0x1000, CRC(f24bc0d7) SHA1(31dc996898c01f3427403e396a47444732904674) )
    ROM_LOAD( "1700-f-ur.d6",  0x5000, 0x1000, CRC(672361fc) SHA1(010029460c25935f2156eb64c9109c26ce40b752) )
 ...and so on

To see it in action you can try reading memory locations, put your oscilloscope probe on the chip enable line, and see it toggle with each read.
 

Attachments

  • Screen Shot 2012-12-26 at 11.52.15 PM.jpg
    Screen Shot 2012-12-26 at 11.52.15 PM.jpg
    77.8 KB · Views: 257
Well from scratch, let's say you suspect a bad ROM on your Kickman. Check the schematic, it shows:

attachment.php


Note the 74ls138 which is a 3-to-8 decoder (here). Its inputs are {A14, A13, A12} and enabled when A15 is low. So for every combination A15=0 and:

A14=0 A13=0 A12=0 -- selects pin 15, connected to rom0 (B3)
A14=0 A13=0 A12=1 -- selects pin 14, connected to rom1 (B4)
A14=0 A13=1 A12=0 -- selects pin 13, connected to rom2 (B5)
A14=0 A13=1 A12=1 -- selects pin 12, connected to rom3 (D4)
A14=1 A13=0 A12=0 -- selects pin 11, connected to rom4 (D5)
A14=1 A13=0 A12=1 -- selects pin 10, connected to rom5 (D6)
A14=1 A13=1 A12=0 -- selects pin 9, connected to rom6 (D7)
A14=1 A13=1 A12=1 -- selects pin 7, connected to sel7 (jumps to nvram)

To make it more obvious, work out the address bits:

Code:
chip address (binary)    address range (hex)
rom0 b0000xxxxxxxxxxxx = 0x0000-0x0fff
rom1 b0001xxxxxxxxxxxx = 0x1000-0x1fff
rom2 b0010xxxxxxxxxxxx = 0x2000-0x2fff
rom3 b0011xxxxxxxxxxxx = 0x3000-0x3fff
rom4 b0100xxxxxxxxxxxx = 0x4000-0x4fff
rom5 b0101xxxxxxxxxxxx = 0x5000-0x5fff
rom6 b0110xxxxxxxxxxxx = 0x6000-0x6fff

Now that you've worked it out manually, compare against the info you get online:

Quarter Arcade (here) go down to "Rom Regions" and see the memory ranges, the names of the corresponding MAME ROMs. This is great because it also shows the expected CRC as calculated by the Fluke ROM test.

Mame mcr.c source (here) usually has some info in the comments at the top of the file, but you can go down in the code where this is defined:

Code:
 ROM_START( kickman )
    ROM_REGION( 0x10000, "maincpu", 0 )
    ROM_LOAD( "1200-a-ur.b3",  0x0000, 0x1000, CRC(d8cd9f0f) SHA1(a55f4423d57510256fb9b20b1bded06636c7bd05) )
    ROM_LOAD( "1300-b-ur.b4",  0x1000, 0x1000, CRC(4dee27bb) SHA1(b411d0c05339ae92732c89a4d0b7038d6b360475) )
    ROM_LOAD( "1400-c-ur.b5",  0x2000, 0x1000, CRC(06f070c9) SHA1(02eb19296e6c32544041ab5bf3dbb5a4f20c8ace) )
    ROM_LOAD( "1500-d-ur.d4",  0x3000, 0x1000, CRC(8d95b740) SHA1(93287324b599ec50dd84cc2dc70e82ccd8314a8a) )
    ROM_LOAD( "1600-e-ur.d5",  0x4000, 0x1000, CRC(f24bc0d7) SHA1(31dc996898c01f3427403e396a47444732904674) )
    ROM_LOAD( "1700-f-ur.d6",  0x5000, 0x1000, CRC(672361fc) SHA1(010029460c25935f2156eb64c9109c26ce40b752) )
 ...and so on

To see it in action you can try reading memory locations, put your oscilloscope probe on the chip enable line, and see it toggle with each read.

good info.
 
To expand on the case of Arkanoid, where schematics are not available. And generally this is how I'd do things if I can, because workig out address decoding logic can be tedious.

1) go to google.com
2) enter the game name, as well as the terms "mame" and "drivers", then click search.
3) The majority of times, that'll find a link into mamedev.org to the driver code for the game you want. In this case, it's: http://mamedev.org/source/src/mame/drivers/arkanoid.c.html
4) Read (or at least skim) all of the comments (stuff in red) as you start scrolling down.
5) Continue utill you reach the end of the comments, at 547. Shortly after that, you'll find the following:
Code:
555  /* Memory Maps */
  556  
  557  static ADDRESS_MAP_START( arkanoid_map, AS_PROGRAM, 8, arkanoid_state )
  558      AM_RANGE(0x0000, 0xbfff) AM_ROM
  559      AM_RANGE(0xc000, 0xc7ff) AM_RAM
  560      AM_RANGE(0xd000, 0xd001) AM_DEVWRITE_LEGACY("aysnd", ay8910_address_data_w)
  561      AM_RANGE(0xd001, 0xd001) AM_DEVREAD_LEGACY("aysnd", ay8910_r)
  562      AM_RANGE(0xd008, 0xd008) AM_WRITE(arkanoid_d008_w)  /* gfx bank, flip screen etc. */
  563      AM_RANGE(0xd00c, 0xd00c) AM_READ_PORT("SYSTEM")     /* 2 bits from the 68705 */
  564      AM_RANGE(0xd010, 0xd010) AM_READ_PORT("BUTTONS") AM_WRITE(watchdog_reset_w)
  565      AM_RANGE(0xd018, 0xd018) AM_READWRITE(arkanoid_Z80_mcu_r, arkanoid_Z80_mcu_w)  /* input from the 68705 */
  566      AM_RANGE(0xe000, 0xe7ff) AM_RAM_WRITE(arkanoid_videoram_w) AM_SHARE("videoram")
  567      AM_RANGE(0xe800, 0xe83f) AM_RAM AM_SHARE("spriteram")
  568      AM_RANGE(0xe840, 0xefff) AM_RAM
  569      AM_RANGE(0xf000, 0xffff) AM_READNOP /* fixes instant death in final level */
  570  ADDRESS_MAP_END

"AM_RANGE(0x0000, 0xbfff) AM_ROM" tells you where some ROMs are mapped (see earlier post by joeyoravec describing how to see where each individual ROM is mapped).

"AM_RANGE(0xc000, 0xc7ff) AM_RAM" tells you that range is RAM. Further down you'll see at lines 566-568 there's some more RAM (primarily video RAM).

None of this tells you WHICH exact RAM ICs are mapped to which region; you'll need the schematics (or some informed guessing) to know that.
 
I simply type in the name of the game and 'Filetype:c' to narrow down the search to the .c files for MAME.

RJ
 
SUPER information, guys. Finally sat down it really went through it and think I grasped it all. I am going to go back down and look at the fluke some more. I'm sure I will have some more questions, once I get going.
 
Reread this and finally starting to understand it. Worked out some other game memory through schematics and checked with the Mame files and both agreed.

Next question...I do I tell which RAM corresponds with the Fluke? If I put in a range, how do I narrow it down to which RAM?

Thank again for the great information.
 
Depends. You have to look at the schematics. In short you have to look at what addresses the "chip select" is active for each chip.

For example on atari millipede and centipede the video ram switches ever 16 addresses
Ie 4000-400f is on one chip lets say chip 1
4010- 401f is chip 2
4020-402f chip 3
4030-403f chip 4
4040-404f back to chip 1

Then sometime a single address is made up of 2 or more chips (for example in the example above each address is really 2 chips, one has the low 4 bits the other the high4 bits...

Once you get used to reading the schematics and the basic logic gates... It will make more sense.

Also something memory errors are not the memory chips themselves but instead some chip in the supporting circuit... But that's another story.. Again once you get comfortable with the fluke and reading schematics that will start to become clearer too.
 
I just put the Fluke in discover mode and let it scan from 0000 through FFFF and see what it "finds" as RAM and ROM.

Compare that to the memory map in MAME and see what is missing. From there track down why it's missing. Bad latches, bad buffers, bad address decoding, etc...
 
Back
Top Bottom