How do you use your Fluke 9010?

[Guest]

Archived from groups: rec.games.video.arcade.collecting (More info?)

I'm thinking about revisiting the Relayer project I started a couple
years back. It was essentially an FPGA that emulated Z80 R/W cycles and
displayed the results. The next step was to emulate different kinds of
processors and have it more interactive. The technology is cheap enough
now!

So my question, how do y'all use your Fluke 9010's? I have some ideas
for new features for Relayer:

* Interactive R/W in program, memory, and I/O spaces.
* Report the status of control pins at the processor (INT*, RESET*,
SO*, etc.)
* Speed up or slow down the processor clock.
* Scan through all address space and save known/good memory profiles.
* Use known/good profiles to test bad boards, noting where they fail,
and suggest parts to replace.
* Scripting, allowing the user to loop R/W access sequences.

What else do you use your Fluke 9010 for? No plans to do full-blown
emulation at this time. This is more a test fixture.

- Craig (who also needs to finish Brian's PONG board ;-)

 

[Guest]

Archived from groups: rec.games.video.arcade.collecting (More info?)

"Craig Yarbrough" <hyarbr01@harris.com> wrote in message
news:1111856699.025183.186150@g14g2000cwa.googlegroups.com...
> So my question, how do y'all use your Fluke 9010's? I have some ideas
> for new features for Relayer:
>
> * Interactive R/W in program, memory, and I/O spaces.

Yes, typically in conjunction with executing code though-- poke some bytes
into RAM and then run at the target address to execute the code in situ.
(Or doing things like writing a little display list into the vector memory
of an Atari board to get a display up on the screen-- use "repeat" to
refresh it.)

> * Report the status of control pins at the processor (INT*, RESET*,
> SO*, etc.)

Not me. (Well, only when it bitches about one of them being wrong. ;-)

> * Speed up or slow down the processor clock.

Not per se, but as a result of banging on addresses in RAM "manually" I
suppose it's sort-of the same effect.

> * Scan through all address space and save known/good memory profiles.

Yes. I find it useful for that-- "A/B" testing with a known good and bad
board.

> * Use known/good profiles to test bad boards, noting where they fail,
> and suggest parts to replace.

No so much, except in the cases of a clear RAM or EPROM failure.

> * Scripting, allowing the user to loop R/W access sequences.

Some, but I'm probably the minority there-- I'll use it with the serial port
and scripts to act something like a substitute ICE. That's where reading
and executing programs can be handy since you can stash register results in
RAM to examine using a little stub. If you had a working Z80 core and
register peeking it would be a bigger deal for me. ;-)

> What else do you use your Fluke 9010 for? No plans to do full-blown
> emulation at this time. This is more a test fixture.

I use 'repeat' a lot. It's handy if you're looking for problems to be able
to do a write to an address to trigger a strobe of some sort and just turn
the 9010 loose to repeatedly bash on it while you snoop around on the board
looking for the proper or improper reaction. I also like the data 'ramp'
feature to write all the values to a single location and the automated
RAM/ROM test are good even if you don't really use the results-- just
excercising the data/address bus and all the decoders is nice. (Since you
can also "repeat" that it makes it easy to look for bad bits on buffers or
misbehaving decoders and the like.)

The main problem I'd see with an FPGA implementation is that it's sort of an
odd solution. The FPGA gives you good speeds, but Z80's were slow anyway,
and since you're not emulating the CPU it's not a clear win to me. I'd say
that a USB pod (even just using the bit-banged mode of something like a FTDI
FT245) that provided ~40 lines of GPIO would do just as well and it would be
easy to replace Z80 timing with 8088 or 6502 or 6809 or whatever just by
changing the software on the host. (A PCI/PCMCIA/CF/ISA/whatever GPIO card
would do about the same.) Having a PC as an interface is pretty appealing
to me at least.

On the other hand, if you really want to go with the FPGA for fun, you might
get a good functionality boost by including a real Z80 in the design. Just
let the FPGA clock and halt the Z80 and share the bus... So the FPGA can do
stimulus and probing and then you can let the Z80 run code. (That
arrangement gives you lots of options with the Z80 since it's static too.
You could set the clock rate arbitrarily, single step, fire off individual
T-states, integrate a debugger, etc. Depending on if you have an attached
PC or something your could just as easily be a logic analyzer at the same
time-- maybe just realtime it back by USB since the Z80 it pretty slow.)

Of course there's probably about 20 people in the world that would need
anything like I described, but you asked. ;-)

Good luck with the project, either way it sounds like fun...

-Clay

 

[JB]

Archived from groups: rec.games.video.arcade.collecting (More info?)

Craig Yarbrough wrote:
> ...
>
> So my question, how do y'all use your Fluke 9010's? I have some ideas
> for new features for Relayer:
>
> * Interactive R/W in program, memory, and I/O spaces.

When learning a new board or narrowing down a problem, I tend to read
and write into a memory location a lot (interactively).


> * Report the status of control pins at the processor (INT*, RESET*,
> SO*, etc.)

Not usually because I usually use a scope with those problems. I
probably should use that feature more.


> * Speed up or slow down the processor clock.

No.


> * Scan through all address space and save known/good memory profiles.

RAM and ROM tests are the first tests I do. A large number of boards
can be fixed just by addressing those issues... Generally I have
scripts that I've developed to test common faults.


> * Use known/good profiles to test bad boards, noting where they fail,
> and suggest parts to replace.
> * Scripting, allowing the user to loop R/W access sequences.

On a board I repair a lot of, I have scripts that will tend to narrow
down the easy fixes. I.e. a particular nibble is bad in a 2114 pair, so
I know it's chip "X". You have to write code to get to that level of
chip isolation because the 9010 doesn't provide built in functionality
to do that. The 9100 does... but you're generally writing scripts for
that anyways.


> What else do you use your Fluke 9010 for? No plans to do full-blown
> emulation at this time. This is more a test fixture.

One of the things I use A LOT is the ability to test with a probe that
is sync'ed with the address or data cycle. That allows you to test a
lot of components that aren't always "visible" to the CPU. For example,
you can't test a character ROM chip in a Centipede board because there
is no way to read that memory. But you can test CS lines to a lot of
those chips with the probe (interactively).


--
JB
(james at you know what arcade dot com)


--James Bright
http://www.QuarterArcade.com
Restored Arcade Games for your Home


http://tech.QuarterArcade.com
Reference & debug material. WIP

 

[JB]

Archived from groups: rec.games.video.arcade.collecting (More info?)

Craig Yarbrough wrote:
> ...
>
> So my question, how do y'all use your Fluke 9010's? I have some ideas
> for new features for Relayer:
>
> * Interactive R/W in program, memory, and I/O spaces.

When learning a new board or narrowing down a problem, I tend to read
and write into a memory location a lot (interactively).


> * Report the status of control pins at the processor (INT*, RESET*,
> SO*, etc.)

Not usually because I usually use a scope with those problems. I
probably should use that feature more.


> * Speed up or slow down the processor clock.

No.


> * Scan through all address space and save known/good memory profiles.

RAM and ROM tests are the first tests I do. A large number of boards
can be fixed just by addressing those issues... Generally I have
scripts that I've developed to test common faults.


> * Use known/good profiles to test bad boards, noting where they fail,
> and suggest parts to replace.
> * Scripting, allowing the user to loop R/W access sequences.

On a board I repair a lot of, I have scripts that will tend to narrow
down the easy fixes. I.e. a particular nibble is bad in a 2114 pair, so
I know it's chip "X". You have to write code to get to that level of
chip isolation because the 9010 doesn't provide built in functionality
to do that. The 9100 does... but you're generally writing scripts for
that anyways.


> What else do you use your Fluke 9010 for? No plans to do full-blown
> emulation at this time. This is more a test fixture.

One of the things I use A LOT is the ability to test with a probe that
is sync'ed with the address or data cycle. That allows you to test a
lot of components that aren't always "visible" to the CPU. For example,
you can't test a character ROM chip in a Centipede board because there
is no way to read that memory. But you can test CS lines to a lot of
those chips with the probe (interactively).


--
JB
(james at you know what arcade dot com)


--James Bright
http://www.QuarterArcade.com
Restored Arcade Games for your Home


http://tech.QuarterArcade.com
Reference & debug material. WIP

 

[Guest]

Archived from groups: rec.games.video.arcade.collecting (More info?)

Clay,

Thanks for the feedback! I'm definitely looking at a PC interface. The
FTDI modules look interesting, much like I'd imagine a PIC might work.
Unfortunately I know just enough about software to fill a thimble ;-)
so most of the 'smarts' would have to be with the hardware. That and I
have easy access to all the sythesis/targeting firepower you could ever
want. The PC interface would likely start off as a Hyperterm monitor.
Then possibly graduate to Visual Basic or something.

I had thought about including some processor cores and having some
measure of emulation, and being able to dump registers and so forth.
The problem I have with that is the amount of potential support it
would need if this thing ever went to market! Cores may not be perfect,
even the licensed ones! Bit-banging an interface is easy, but emulation
adds a facet that may make it cost-prohibitive. Having a real processor
on-board might work. I'd still have to think about that one.

I like the idea about implementing a quickie logic analyzer! At low
speeds that would be very easy to do.

- Craig

 

[mark]

Archived from groups: rec.games.video.arcade.collecting (More info?)

I like to broil mine with butter.But i like Flounder much better.
"Craig Yarbrough" <hyarbr01@harris.com> wrote in message
news:1111856699.025183.186150@g14g2000cwa.googlegroups.com...
> I'm thinking about revisiting the Relayer project I started a couple
> years back. It was essentially an FPGA that emulated Z80 R/W cycles and
> displayed the results. The next step was to emulate different kinds of
> processors and have it more interactive. The technology is cheap enough
> now!
>
> So my question, how do y'all use your Fluke 9010's? I have some ideas
> for new features for Relayer:
>
> * Interactive R/W in program, memory, and I/O spaces.
> * Report the status of control pins at the processor (INT*, RESET*,
> SO*, etc.)
> * Speed up or slow down the processor clock.
> * Scan through all address space and save known/good memory profiles.
> * Use known/good profiles to test bad boards, noting where they fail,
> and suggest parts to replace.
> * Scripting, allowing the user to loop R/W access sequences.
>
> What else do you use your Fluke 9010 for? No plans to do full-blown
> emulation at this time. This is more a test fixture.
>
> - Craig (who also needs to finish Brian's PONG board ;-)
>