Microprocessor Tutorial?

[westfw]

The old computers (Altair, COSMAC Elf) (which I've mentioned before) were REALLY GOOD for learning some of this stuff, because those famous "front panels" with all the switches and lights - those were essentially connected directly to the microprocessor buses.  To load a program into memory, you'd set some switches to the address, and some to the data you wanted to put there, and then flip a momentary switch to activate the "write" and chip-select lines of the memory (all while holding the CPU chip itself in a "don't access the bus" state.)

Good front panels had the address lines on counters, so you could just do "next address" instead of loading more switches.

Modern "simulations" may have things that LOOK like front panels, but they usually just interface to software, and you don't learn as much

[Electro Fan]

The old computers (Altair, COSMAC Elf) (which I've mentioned before) were REALLY GOOD for learning some of this stuff, because those famous "front panels" with all the switches and lights - those were essentially connected directly to the microprocessor buses.  To load a program into memory, you'd set some switches to the address, and some to the data you wanted to put there, and then flip a momentary switch to activate the "write" and chip-select lines of the memory (all while holding the CPU chip itself in a "don't access the bus" state.)

Good front panels had the address lines on counters, so you could just do "next address" instead of loading more switches.

Modern "simulations" may have things that LOOK like front panels, but they usually just interface to software, and you don't learn as much

Somewhat off topic but it might be cool if someone marketed a current day kit version of what you describe - with the parts and educational instructions - sort of as a next step up or a diagonal step up from Ben Eater’s breadboard kits.  Or maybe it’s something Ben might offer.  Might be hard for some enthusiasts to turn down a chance to learn while playing with a front panel full of switches and lights - might make learning computer architecture more interesting and fun than using a keyboard. 

[brucehoult]

The old computers (Altair, COSMAC Elf) (which I've mentioned before) were REALLY GOOD for learning some of this stuff, because those famous "front panels" with all the switches and lights - those were essentially connected directly to the microprocessor buses.  To load a program into memory, you'd set some switches to the address, and some to the data you wanted to put there, and then flip a momentary switch to activate the "write" and chip-select lines of the memory (all while holding the CPU chip itself in a "don't access the bus" state.)

Good front panels had the address lines on counters, so you could just do "next address" instead of loading more switches.

Modern "simulations" may have things that LOOK like front panels, but they usually just interface to software, and you don't learn as much

Somewhat off topic but it might be cool if someone marketed a current day kit version of what you describe - with the parts and educational instructions - sort of as a next step up or a diagonal step up from Ben Eater’s breadboard kits.  Or maybe it’s something Ben might offer.  Might be hard for some enthusiasts to turn down a chance to learn while playing with a front panel full of switches and lights - might make learning computer architecture more interesting and fun than using a keyboard. 

It's very very boring entering things using front panel switches. I've done it to enter the initial bootstrap for a Burroughs B1700. Fortunately it was only a couple of instructions. I don't know what they were! We only had the binary values for them. I want to say those instructions were enough to read the next stage bootloader from cassette, but that seems improbable. More likely there was a small punched card deck that had code to read the cassette. The code on the cassette for sure then allowed reading from a 5 MB removable disk pack and loading code from there.

It was possible to halt or single-step the CPU and use a big rotary knob to choose which register was displayed on the lights.

All this kind of thing went away with the development of cheap and large and fast semiconductor PROM and EPROM to boot from.

[Electro Fan]

Ok, fair point.  Maybe it would be less nostalgic but more useful to start somewhere about here.

[bostonman]

A logic analyzer is more or less the ultimate tool for the job, the biggest hammer in the toolbox, but I don't think you'll have much fun with one if you have no understanding of the opcodes and memory map of the system you're working on.

I'll admit, my mind goes into a loop when I being reading extensively about the opcodes and memory map. It's quite a bit to process because it's hard to visualize what's going on.

I'd learn better if I could (as it's been suggested) see changes on individual clock cycles. Once I put a logic analyzer on, I expect that I'll gain a much better understanding of whether a chip is functioning correctly.

As for being able to clip onto the ICs, I have those IC clips (although I've never liked them because I feel they apply too much clamping force).

As far as I know, manually cycling the C64 can't be done unless I do things like remove the crystal - but I'm obviously inexperienced, else I wouldn't have needed to start this thread.

I can just swap ICs until I fix the unit, however, just about all of them are soldered, and, the only donors I have are perfectly good working units (I have some spare questionable spares). So I somewhat need to be correct in finding a bad IC before I go through the trouble of unsoldering them.

[Electro Fan]

bostonman do you have a link to your new logic analyzer?

[bostonman]

I got the LA2016 (description is below in case Amazon link doesn't work).

https://www.amazon.com/Inno-Maker-Analyzer-Channels-KingstVIS-Instrument/dp/B07D21GG6J/ref=sr_1_3?dchild=1&keywords=LA1010+USB+Logic+Analyzer&qid=1634010344&sr=8-3


LA1010 USB Logic Analyzer 16 Input Channels 100MHz with The English PC Software Handheld Instrument,Support Windows (32bit/64bit),Mac OS,Linux

[james_s]

Memory map is not a difficult concept, it all boils down to the address decoder logic. Are you familiar with how a decoder works? If you aren't, read up on it, once you've seen one you've seen them all. The 74LS47 is a simple one, it's designed to drive a 7 segment display from a 4 bit binary input but the concept is the same. The simpler 74LS138 is a common part used in real world address decoders. In a nutshell the decoder will assert (make active) one enable line for each range of address values. If you have a 2k ROM chip that you want to connect to the microprocessor you would wire up a decoder chip that activates the output connected to the ROM whenever any one of a block of 2048 consecutive values are present on the address bus.

Part of the address bus feeds directly to the address inputs on the ROM itself, and the rest of the address bus is used to determine which of several chips on the bus is active at a time. The ROM can be said to be "mapped" at any arbitrary place within the 16 bit address space,  which ranges from x0000 to xFFFF, 65,536 possible addresses.

[brucehoult]

I got the LA2016 (description is below in case Amazon link doesn't work).

https://www.amazon.com/Inno-Maker-Analyzer-Channels-KingstVIS-Instrument/dp/B07D21GG6J/ref=sr_1_3?dchild=1&keywords=LA1010+USB+Logic+Analyzer&qid=1634010344&sr=8-3


LA1010 USB Logic Analyzer 16 Input Channels 100MHz with The English PC Software Handheld Instrument,Support Windows (32bit/64bit),Mac OS,Linux

Not expensive, but also frustratingly limited! 16 channels seems like not really enough -- ideally for poking around in a C64 etc you'd want to capture 16 address plus 8 data plus R/W and a few other control signals. 32 inputs would be perfect.

Also, when using all 16 inputs it's only 16 MHz. Which to be fair is more than enough for the 8 bit micros.

It seems this one doesn't have any significant internal storage, but has to stream everything to the PC in real time. Which USB3 is more than fast enough for.

Is there a way to synchronise two or more of them?

[Ian.M]

In practice, the 16 channels isn't as much of a limitation as you would think.  Eight for the data bus, R/W, ø2, SYNC, and RDY is sufficient to fully trace 6502 instruction execution^* leaving you four for <whatever>, e.g. decoded enable signals of one or more memory mapped chips, latched port output bits, or even if you must, address lines.

* See: http://forum.6502.org/viewtopic.php?f=4&t=4963

[bostonman]

I found this online. Although this is a 'microprocessor' thread, thought I'd share the block diagram.

[james_s]

Unfortunately that doesn't really tell you a whole lot, it's pretty much like any other 8 bit computer at that level, save for a few special chips.

The address decoder in the case of the C64 is a PLA, so it can be considered a black box that activates one of a number of enable lines depending on the state of the address bus, that diagram doesn't show which addresses activate which chips, although that information is available elsewhere in the form of the memory map.

[bostonman]

I agree, but at my level, this colorful visual is a nice help to see the actual flow.

[james_s]

The important thing to remember is that all of the addressable parts are connected to the address bus which the CPU drives, and to the data bus which is either an input or output depending on what the CPU has set it to, and this will be indicated by the state of the R/W line. One device can be active on the data bus at any given time and the address decoder determines which device this is. To write to anything the CPU sets the address bus to an address within that device, sets the R/W line to write, and then puts the data on the data bus. When the next clock transition occurs this data is latched into the device and the CPU moves on to execute the next instruction.

[bostonman]

I'm uncertain how deep I should go with this before it turns into a C64 repair thread, so I'll try remaining on track with the origin of how this thread began.

Something isn't clicking with me or maybe I'm making too much out of this, but I feel I'm chasing my tail with looking at the bus with a logic analyzer because I'm jumping from chip to chip and constantly changing the wire configuration on the analyzer. So far I've confirmed the address bus is basically not moving, or, if activity does exist, it's sporadic/random/seldom.

Stop me if I'm going off track and deviating towards a C64 repair discussion. Although the PLA seems to be a main interface between the other chips and the address bus, I've replaced this sometime ago.

Besides not seeing activity on the address bus, I noticed (with an oscilloscope) that the CS (chip select) on the Character ROM has very little activity. The activity I saw was a few 200ns pulses compared to a good one that is 50ns pulses occurring every 100ns.

The Character ROM chip has an address of D000-DFFF.

My first question: this is decimal 53248 - 57343 or binary 1101000000000000 - 1101111111111111

This is two bytes long, but the address bus for this ROM chip is 12 bits. If the address bus was (for simplicity) one byte, how does two bytes get fed in? To use the ideal issue, how does 16 bits get fed into a 12 bit address bus?

I assume this address is what is placed onto the address line to access this particular IC, and, from there, data is placed onto the data bus.

Obviously the address lines don't exist at the moment, but figured I'd start with one (hopefully) easier question.

If the CPU drives the whole address bus, and the address bus isn't working, although this seems too easy, why would the issue not be the obvious (the CPU)?

[brucehoult]

The Character ROM chip has an address of D000-DFFF.

My first question: this is decimal 53248 - 57343 or binary 1101000000000000 - 1101111111111111

This is two bytes long, but the address bus for this ROM chip is 12 bits. If the address bus was (for simplicity) one byte, how does two bytes get fed in? To use the ideal issue, how does 16 bits get fed into a 12 bit address bus?

There will be a circuit that detects when the top 4 bits of the address are 1101 and set the CS for the character ROM chip to 0, or to 1 otherwise. (I'm assume the CS is active low, which is often the case) The remaining address lines are connected to the character ROM as is.

Let's call the top address bits a15, a14, a13, a12, a11, a10. There will often be a "hex inverter" chip that takes those and creates ~a15, ~a14, ~a13, ~a12, ~a11, ~a10. Then a 4-input NAND gate fed with a15, a14, ~a13, a12 will produce the proper (active low) CS for the ROM.

CS signals for the various other ROM, RAM, and IO chips are created similarly.

[bostonman]

Makes a bit more sense because A12 to A15 go into the PLA, and the pin labeled CHARROM of the PLA goes into the CS of the Character ROM.

The two other chips utilize A15 as part of the address bus, but assume the PLA handles the other three bits.

It's not to say I would be wrong, but I considered un-soldering the Character ROM thinking it's pulling down the CS pin, but, if the address line isn't working, then neither is the PLA.

Guess I'll stop looking at the ROM chips on the Logic Analyzer and move onto another chip.

[james_s]

The Character ROM chip has an address of D000-DFFF.

My first question: this is decimal 53248 - 57343 or binary 1101000000000000 - 1101111111111111

This is two bytes long, but the address bus for this ROM chip is 12 bits. If the address bus was (for simplicity) one byte, how does two bytes get fed in? To use the ideal issue, how does 16 bits get fed into a 12 bit address bus?

Since we're talking about hardware, everything is fundamentally binary. Typically it would be represented in hex for human readability but you could use decimal or octal or anything else you wanted, it's still binary at the hardware level. When discussing memory addresses, you're always describing the state of those 16 address lines and each of those lines can have exactly one of two states, ie binary. The address bus is 16 bits wide, the lower 12 bits address the specific cell in the ROM whenever the ROM is enabled, the remaining address bits are what get decoded to activate the ROM. If you were to pull out the CPU and hardwire the address bus to xD111 (1101000100010001) the top 4 bits (1101) are going to cause the enable line on the ROM to go active, the lower 12 bits are then what the ROM uses to select the specific byte stored in it. Any time bits 16 downto 13 of the address bus are 1101 the ROM will be enabled. Any other combination of those top 4 lines is going to enable something else.

For example if you added another ROM, you'd connect bits 12 downto 0 to the new ROM, it would be wired in parallel with the one you have. You could then decode the top four address lines so that whenever they are 1111 it would enable that ROM, and you have now mapped a ROM to xF000 to xFFFF. Any time the microprocessor jumps to an address in that range it's going to be reading from that new ROM because that ROM is enabled any time the top four address lines are all high.

[james_s]

It's not to say I would be wrong, but I considered un-soldering the Character ROM thinking it's pulling down the CS pin, but, if the address line isn't working, then neither is the PLA.

Guess I'll stop looking at the ROM chips on the Logic Analyzer and move onto another chip.

If the address line is not working, it's probably because the CPU is not trying to access that address. As I mentioned before, when the CPU resets it jumps to the reset vector which is a specific memory address and it executes the instruction that it finds there. The reset vector normally points to a location in ROM, this is determined by the way the hardware is designed, and the ROM needs to contain code that will instruct the CPU to do a sensible sequence of events. This will typically be something like zero out all of the locations in RAM, initialize some peripheral chips, and then start trying to load the operating system, which may be a disk operating system or something like BASIC in ROM. Now what can happen is there can be a fault, say a bad ROM, or a bad RAM or some other fault that causes the wrong instruction to be executed, maybe even an invalid instruction (illegal opcode) that does something that isn't useful. What happens then is instead of following the path and executing the desired sequence of instructions, the CPU runs off the road into the weeds and starts executing garbage. Sometimes it will just lock up, other times it will end up stuck in a loop, what the address bus does at this point depends on what instructions the CPU happens to be executing. It's possible it will only be a small number of addresses leaving most of the address bus dead. Not because there's anything wrong with the address line, but because the CPU is confused and not trying to access anything mapped to locations that use those address lines.

This is why I've said that when looking at this level, hardware and software (in the form of ROM) are intimately intertwined. To separate them you would need to remove or disable the CPU and then you could use a row of switches (or an ardruino or something) to manually drive the address bus and confirm that the expected chip goes active when you access its address range.

[bostonman]

Will I harm anything if I pull the 6510 (MPU as marked on the schematic) and place 0s and 1s on the address bus only?

If so, I think using less than 5v, maybe 3.5v would be safer.

[james_s]

No, and no it won't make any difference. It is not a bad idea to use a resistor to drive each line, anything from around 100 ohms to a few k ought to be fine. Then if you accidentally connect to a line that is driven by something else you won't damage anything.

[bostonman]

I might be fairly lucky because the MPU is in a socket.

Which other chips drive an address line?

[james_s]

Nothing else drives an address line, but it's easy to attach something to the wrong pin.

[bostonman]

This is a valuable suggestion. The MPU is in a socket, and I'll be able to use my 16 channel Logic Analyzer to look at all the pins on an IC without occupying the majority for the address bus because I'll know their state since they won't be moving (after I confirm my address bus settings are present).

I don't have an Ardruino, all I have is a Raspberry Pi (and obviously a laptop to run the Logic Analyzer), so I'll probably end up making one with manual switches since I don't know programming to create a program for either.

I'll look in my stash of parts, however, I doubt I have sixteen switches or a dip switch, so I won't be able to provide an update for some time.

[james_s]

Dip switches are cheap, and if you don't have switches you can just poke wires into a breadboard. An arduino mega is only around $20 and programming some IO pins to a specific state is trivial. I saw at some point someone had developed a CPU simulator for this kind of work but I don't remember where I saw it.