Is this during attract mode?

I think it just sits in a loop if a test fails, but I'd have to check the code to be sure. I could see it never hitting certain addresses in an infinite loop.

In order to reduce overall chip count, creative things were done with the memory map / addressing. Sometime, an address line was used only to select PIAs etc. Therefore, while you may see what look like normal waveforms on most of the address lines, others may look totally dead if your scope can't catch and display a single fast change (a single read or write to a port).

And, as others stated, while in a repeating loop, the code may not cause lower address lines to change until it jumps outside the loop.

Interesting discussion. A few things to add/reiterate:

(1) I think for at least some platforms (Data East I think), there may be custom unofficial test ROMs that cycle more predictably through the address lines. At least with the Data East MPU, the ROMs sit in the upper 48K which should be safe to traverse and still excercise all 16 address lines.

(2) Because of the nature of memory-mapped I/O, you would want to be careful if you wrote your own code to cycle address / data lines. Depending on the circuit design, a lot of memory-mapped I/O is read/write line agnostic and treats reads and writes identically. The danger is energizing a coil accidentally and not turning it off in time. You'd also have to make sure you tickled the watchdog circuit often enough.

Yes, that would help. At that point it should be in attract mode, even if it's not visible, flashing all the lights and doing different reads from the rom.

Also, what roms are you using?

Hey oldschoolbob, interesting thread! You inspired me to crank up my old oscilloscope (Tektronix 5440) and mess around with it. I don't have a passive probe so I kinda had to wing it to make sure the oscope works. It does! So, now I'm trying to figure out how to get my hands on a probe. Looking to buy or build a P6028 probe. A few old ones out there on ebay, but I am also reading that you can make one. BNC connector, 1Mohm, 24pF. Spec sheet says it is 33mhz, x1, 600v passive. I found a couple of videos on making your own probe and it looks not too difficult. Anyone have suggestions on how I can get this done? (need resistors, etc.)
Thanks!
(Don't mean to hijack your thread but I'm eager to learn about oscopes as well.)

Why would you bother to kludge one together when new, professional ones can be had for $10-$15 including shipping. You don't want something questionable when it comes to troubleshooting tools.

https://www.rakuten.com/shop/unique-bargains/product/a12101000ux0332/?scid=pla_google_unique-bargains&rmatt=tsid:1012713|cid:1470376742|agid:57068148695|tid:pla-457960328848|crid:281246121294|nw:g|rnd:14506633228190968654|dvc:m|adp:1o16|mt:|loc:9031539&gclid=EAIaIQobChMIop2Ihrq13AIV

I would get one if I could find one at 33mhz specification. I have not found one of them yet. And from what I read at Tektronix, they are not interchangeable.

I could obviously be wrong but I would expect that the 100MHz will work just fine.

Every few of my scopes were rated at 100Mhz and I have always purchased 100's as replacements.

Wow! That P6028 is kind of old (1963-1966). I don't see any sign of a cap on the manual. Many probes you buy today have a trim cap at the base so you can fine tune the probe to the scope (scopes often have a square wave output for this purpose).

I wonder how old my Dad's Vacuum Tube 1MHz Tektronix is I have under my bench? Talk about boat anchors!

I don't have any tech info to add but I love that statement! Some people would just look at an o-scope and say "nope" but not you, nicely done

They made for a fine opening for the original B/W The Outer Limits!

In High School Physics, the Teacher got the use of an O-Scope and Played through the entire song of Free Bird one day for us to "Watch". I guess it was his way of trying to somehow make the class more interesting (late 70's). Either than, or he was nursing a Hang Over that day.

Was thinking the exact same thing ... some guys just take the plunge Good for you!

I found an adjustable probe that I think will work for me and the old oscope that may just be older than me!
https://www.digikey.com/product-detail/en/digilent-inc/460-004/1286-1075-ND/4840870

Thanks for the input!

The CPU doesn't have any storage, it has to read each instruction for the ROM one byte at a time as it runs. Even in a loop it'd be continually reading. You could even write code that writes an infinite loop into ram, jumps to it, and then later on alters the code from an interrupt while the CPU is running it.

I think you're not understanding how all the lines work quote right.

If you were in an endless loop, maybe you could, but not during normal operation. Each address line is combining to do so many things. The ROM data isn't changing, but it has be be grabbing thousands of bytes from the ROM just to run attract mode, I doubt your scope can record them all.

I once made test ROM where every single byte was just repeated instructions saying 'jump to this same address', creating infinite loops, so that I could decode the address on the lines with a logic probe and find where the mpu was hanging. Even in that case, the lowest bits of the address lines were still moving though, as the 'BRA' instruction I used was two bytes in size.

For that, you can make a NOP test cpu (6800). You lift all data bit lines (D0-D7) on a 6800 chip and tie them high or low to form a data byte of $01 (hexidecimal). 01 is the NOP (no operation) command for a 6800.

The Cpu resets, goes to address FFFE and pulls the first half of the 16 bit POR jump address. Increments to FFFF and pulls 2nd half. Jumps to $0101 and pulls the first command byte which will be a $01. 01 says do nothing except increment program counter and get next byte. Which will again be 01. Repeats forever. So, you end up with a 16 bit counter as it counts from 0000 to FFFF and rolls over.

That will give you a steady waveform.

Technically, the CPU would request the word 'cat' from the rom via the address lines. The ROM sends it back via the data lines. But yeah, your central point is correct. Too much going on normally to hope to capture it via the scope

It really sounds like you need to get an old book from the late 70's about Programming Micro computers.

It sounds like you are thinking along the lines of a "program" that is running in a higher language. The 6800 is using what is referred to as machine language. The "C" in cat, exists in memory as an ASCII byte. It takes many line of code to go fetch that byte and then transfer it to an external device, usually through some kind of an I/O port. If it needs to go out to a serial device (a single transmission wire), it has to shift it out one "bit" at a time, which would require a loop of code.

Almost no way to see a fixed pattern with a scope. Read up on signature analyzers to see how a tech would trouble shoot a running circuit. And even then, it requires you lock the program into a know mode or condition so you know what "should" be happening as opposed to what actually is happening.

A0 through A16 form a 16 bit address word which is used to point to one specific byte in memory. D0 through D7 contain the data byte that is either going to be written or read from that memory location.

It'll also be important to understand how binary numbers work - that's essentially how a group of address and data lines represent numbers.

As we did on one of your previous threads using the oscilloscope, removing the ROMs from these Stern/Bally boards pretty much makes the CPU cycle through every address from lowest to highest address, and this shows the address lines double in frequency as you measure up each address line number. This doubling in frequency will make sense when you understand binary. It can give you some reference as to whether the address lines are working.

An oscilloscope will let you see fixed frequency generators that produce a repeating waveform - such as the pin 3 output of the 555 timer at U12 (around 320Hz), the Zero Crossing detector at pin 4 of U14 (120Hz), Clock signals on the CPU at pin 3 and pin 37 (not sure if you're oscilloscope is fast enough to read these), etc.
An oscilloscope can let you see chip outputs that are weak (not fully swinging one way or another when it should).

It's very useful in audio circuits as you can see what audio waveforms look like on sound boards when you need to diagnose volume issues, noise issues and no sound issues. Something a multimeter and logic probe can't/aren't designed to do.

Data lines can be either way. The R/W pin on the CPU tells whether it's reading or writing. If you write to ram then the CPU sends them, etc. Address lines are always being set by the CPU. If it were to change them while reading, the data being read would change.

Looking at a serial stream from a single address line isn't super useful.

The real secret sauce is finding the chip enable decodes. A PIA for instance has 3 chip enables CS0, CS1 and CS2 which has a line drawn over it.

A line means active low, no line means active high. So in order to access the PIA the address lines go through some logic to set CS0 and CS1 high, CS2 low and boom! The PIA now accepts I/O.

This is how any IC is selected on the bus. Anything that's not active goes "tristate" meaning its pins aren't affected (and can't affect) the rest of the bus.

Depending on how many channels your scope has you can set logic triggers to look for these states. IE, if channel 1 is high and channels 2 and 3 are low then trigger. This would allow you to pause the scope when a PIA access takes place for instance.

If you lack the channels you can go super dorky and use glue logic to make an edge detector. In the case of the PIA you'd put CS1 and CS0 through an AND gate, CS2 through an inverter, then both of those outputs through another AND gate. This would create a signal that goes high whenever CPU is trying to access PIA. You could use this as an external trigger for the scope and probe signals to see what's happening when the PIA is pinged.

So R/W pins on the other chips are the inputs the CPU's R/W pin is writing to. The PIA is configured internally by the CPU as the whether each PA/B pin is an input or an output, and then the CPU reads and writes to the PIA to access those pins.

Check out
https://www.dropbox.com/s/b3irqsneg9s54c9/MC6820.pdf?dl=0 for a good overview of how the pia works

PiA has two 8 bit data ports, which can output or input data.

So if you wanted to use one to drive an 8x8 switch matrix you'd set one to output (to drive columns) and one to input (to read switch rows)

The CPU would then need to change the column at a certain frequency and then read the result of the rows (one byte at a time) to determine what switch was closed. Thus a complete scan of switches would require 16 accesses to the PIA. (eight writes interlaced with eight reads)

Really good topic. I didn't consider owning a scope until now,very interesting stuff here.
-Mike

For the sort of analysis going on here a logic analyzer would probably be better

These work well: https://www.saleae.com/?gclid=CjwKCAjwhevaBRApEiwA7aT535j4nwaTiWniKlFB6iKtHb_jkmWK9RNTkCj3JUNadIhpOQW17H2ZNRoCjz8QAvD_BwE

and have more bits of resolution than low end oscilloscopes.

If you're just looking for logic levels an analyzer can be all you need!

I think you are seeing the U10 PA5-PA7 and CB2 port come back through closed dip switches. The CPU reads the dip switches by sending strobes through those PA ports and then reading back the PB ports just like it does when it scans the switch matrix. The return PB ports are in common to both dip switches and normal switch returns, but different PA ports (and CB2) are used for the strobes. PA0-PA4 is normal switch matrix strobes and PA5-PA7+CB2 are the dip switch strobes.

You will also notice U10 PA ports also handle the lamp driver board and display latching (with the help of u20). So when the dip switch is closed and the PIA is controlling the lamp board and displays those PB will show data like you see. The CPU does not care about those PB ports at this point, so it is just ignored. U10 is very busy in Bally games. Has a hand in lamps, switches, and displays.

If you read the theory of operation PDF it talks more about the interrupt routines, switch matrix, and dip switches.

Irqs are being generated by the 120hz zero crossing detector and the 555 timer for the displays

And you realize this is what you are looking at:

Address line:
76543210

00000000
00000001
00000010
00000011
00000100
00000101
00000110
00000111
00001000

http://www.techdose.com/projects/Stern-Pinball-SB100-Sound-Board/346/page1.html. Mostly just need to find where the signals are disappearing

Arghh, sorry had my wires crossed there, yes as you go up address line number the frequency will halve the previous line.

No problem - there's probably lots of useful stuff in that Magic sound board thread we worked on nearly a year ago:
https://pinside.com/pinball/forum/topic/stern-magic-no-sound
.
.
Coming back to binary, the MPU board communicates with the solenoid driver board for momentary solenoids in 4 bits. It also communicates the "number to display" (BCD binary coded decimal) to the displays. And also 4 bits to the lamp driver board decoder chips.
These groups of bits come from the PIA chips output on the MPU board.

Below are 4 binary bits on the left. Grouped together they can represent 16 different numbers based on their logic levels - a 0 is Lo, 1 is Hi: Can you see the pattern in the binary numbering? For every binary bit you add to the left, you double the amount of numbers that can be represented. 8 bits are usually referred to as a 'byte' and can represent one of 256 different numbers.

BIT
3210
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = 10
1011 = 11
1100 = 12
1101 = 13
1110 = 14
1111 = 15

Understanding these can help you pinpoint communication issues between the MPU board and the peripheral boards.

Pages from Dolly Manual Complete-2 (resized).png