Am I correct on how the 6502's buses work?

[ieatsoupwithafork]

Hi y'all,

I'm completely new to the 6502. However, I have some experience with Arduinos, AVRs, etc. I saw Ben Eater's videos and I think I understand about 60% of it. I'm still confused about the difference between the data bus and the address bus. So excuse me if I confuse between the two here. I would love an explanation on their difference.

The way I understand it, the 6502 reads from/writes to the data bus and other chips like the ROM, RAM and VIA react accordingly. Then, would this idea of mine work?

I am thinking of building a "programmer" of sorts. It will consist of 7-seg displays, a hex keypad, and logic. It will read whatever's on the data/adress buses, show it on the display, read my hex instructions from the keypad, and send it back to the 6502. I want it to work so that I can simply hook it up to the data bus and input some hex code. That way, I can do a kind of "live coding" thing. Sorry if my explanation sounds confusing. Again, I have no xp with the 6502!

Will my idea work? I'm not necessarily asking about how to build the module, but if whether I can simply "inject" data into the address bus with my "imaginary keypad module". I want to know if my understanding of the data/address bus is correct. I don't have any of the parts necessary to run this experiment myself.

Again, sorry if my question sounds confusing, and thanks for bearing with me. Cheers!

[BigEd]

Welcome!

Yes, there will be ways of hooking up a keyboard and simple display, either as a peripheral (which is usual) or as a front-panel, which is more like what you're asking about. The difference is that with a front panel the CPU needs to be able to wait for some action on the keyboard - it's going to be single-stepped or single-cycled. The newer and contemporary CMOS 6502s can do that happily; the historical NMOS ones cannot, in general.

It's worth trying to get your head around the way the busses work. Garth's primer might help.

The crucial difference as I'd put it, off the top of my head:
- the address bus is always controlled by the CPU, and gives the location to be accessed
- the data bus is used to carry the data from that location (for a read) or for that location (for a write) and is therefore controlled by the device (for a read) or by the CPU (for a write.)

If you're not yet familiar with the idea of memory locations, we'd need to take another step back.

[ieatsoupwithafork]

Thanks for the reply! I understand memory locations, or at least most of it. I will be using the WDC6502 which I believe is one of the newer CMOS versions of the 6502.

I know how to build a single-step clock, so with that and a 6502 computer, I can connect my keypad interface and it will work fine?

[BigEd]

I'd say that something will be possible - I think it's more complicated than just connecting things. I don't quite have the time to launch into a detailed explanation. It would probably be useful for you to try to understand bus timings: there are causes and effects within each clock cycle, which any peripheral has to conform to.

See also, perhaps, the super-minimal OSI-300:
viewtopic.php?f=3&t=3558

I would recommend searching this forum, for front panels, keypads, bus timings, and so on. There's a wealth of experience here already captured.

[drogon]

You may want to read through this blog: https://commodorez.com/cactus.html as it describes using key-switches and LEDs to single step a 6502 to enter data and display results.

-Gordon

[BillO]

ieatsoupwithafork wrote:

I am thinking of building a "programmer" of sorts. It will consist of 7-seg displays, a hex keypad, and logic. It will read whatever's on the data/adress buses, show it on the display, read my hex instructions from the keypad, and send it back to the 6502. I want it to work so that I can simply hook it up to the data bus and input some hex code. That way, I can do a kind of "live coding" thing. Sorry if my explanation sounds confusing. Again, I have no xp with the 6502!

Something like this?


It might be possible to build something like this into a front panel but I think it might get complicated hardware wise. The item in the picture above is a HEX terminal, but it requires a piece of software called a monitor to do the job you want. Writing or adapting an existing simple monitor might be easier than designing the hardware to accomplish a HEX front panel. At least in my mind.

[BigEd]

Indeed, that's a distinction worth making. If you have a monitor program, which you have somehow already loaded or programmed into a ROM, then that program can interrogate a keypad and update a display - the keypad and display will be peripherals, accessed over the bus like any other.

But if you have a RAM-only machine, you need a keypad which acts more like RAM, and a way to slow down the machine to human timescales. (The display is an easier problem than the keypad.) This is what the OSI-300, and the Cactus, have arranged. A bank of switches is easier to sort out for this role than a keypad, I suspect.

[GARTHWILSON]

BigEd wrote:

It's worth trying to get your head around the way the busses work. Garth's primer might help.

It's at http://wilsonminesco.com/6502primer/ "6502 PRIMER: Building your own 6502 computer"

There are various things to consider. Although you're not clear on them, it's a little difficult so far to tell how much you do know; so keep the details of your ideas coming.

It partly sounds like you're thinking of a dead-start panel. We have a topic on that at viewtopic.php?f=4&t=4341 . The dead-start panel lets you punch in a bootstrap loader from a keypad, putting the minimal program into RAM by hand after power-up (before letting the processor out of reset), so you don't need any ROM at all in the computer, nor any microcontroller or other logic to load the bootstrap loader into RAM. This topic turned into a similar thing, and another topic starting deep into it approximately here discusses using a diode matrix as a boot ROM so you don't need a programmer.

[cjs]

BillO wrote:

The item in the picture above is a HEX terminal, but it requires a piece of software called a monitor to do the job you want. Writing or adapting an existing simple monitor might be easier than designing the hardware to accomplish a HEX front panel. At least in my mind.

Probably much easier.

I've spent some time thinking about front panel systems (whether a keypad/display or just switches and LEDs) for my various microcomputers, SBCs (single-board computers) and breadboarded systems. There seem to be three basic ways of going about this.

• A keypad and display as peripherals, just as an ACIA/UART/serial interface or PIAs (parallel interface adapters) would be, with a ROM monitor driving them. This seems to be the most common techinque used on "trainer" SBCs.
• Use the CPU to do reads from and writes to memory (and peripherals), by "jamming" instructions and their opcodes on to the data bus. I.e., when you request "show location $1234" from the panel, it puts an LDA or similar instruction on the data bus (making sure that no memory or peripheral chips are selected while doing this), steps the CPU, does the same for the address bytes, and then reads the data placed on the data bus by the memory as it steps the CPU through the read cycle. This technique, while complex, lets you also modify the CPU's registers, allowing you to do things like load the program counter so you can start the CPU running at a specific location.
• Have the panel itself do reads and writes directly to memory and peripherals, taking the CPU off the buses to do so. For the 6502 this requires extra circuitry to disconnect the CPU from the bus (unless you're using a modern version of a 6502, such as the W65C02, which has the ability built-in) and also doesn't let you modify the registers, so you need to start the CPU running via a reset or interrupt. But this would also work without a CPU at all, allowing you to do things like directly program, by hand, a modern EEPROM such as a 28C256.

For a beginner, the first option is probably the easiest if your main focus is just on getting a keyboard and panel working. But exploring the third option without a CPU (at least to start with) would also be quite educational.

[Michael]

Good assessment, Curt.

May I recommend looking at the classic KIM-1 Single Board Computer? It's about the closest thing I can think of to "bare metal" programming using a small Monitor program along with a reasonably intuitive HEX keypad and 7-segment display. Also, look at the Elektor Junior computer. It's similar to the KIM-1 in function but uses more common parts (a 6532 RIOT and a standard ROM instead of the unobtainable 6530 chips).

I've been brain-storming front panel designs, too. I prefer using a microcontroller "loader" (ROM Emulator?) and RAM-only system designs where the microcontroller loads a ROM image into RAM at startup and provides the system clocks afterwards.

Good luck... Cheerful regards...

ps: the current layout for a 5-chip "trainer" concept...

[BillG]

Michael wrote:

May I recommend looking at the classic KIM-1 Single Board Computer? It's about the closest thing I can think of to "bare metal" programming using a small Monitor program along with a reasonably intuitive HEX keypad and 7-segment display. Also, look at the Elektor Junior computer. It's similar to the KIM-1 in function but uses more common parts (a 6532 RIOT and a standard ROM instead of the unobtainable 6530 chips).

If someone just wants a functional KIM-1 and does not care about authenticity, there is this:

https://www.corshamtech.com/product/kim ... placement/

Contrary to the URL, this is a 6530 replacement.

[gbm]

Some time ago I described here my SDC_Zero design. It does what the Author of the thread wants to achieve, and a lot more. Plus: one may assemble it in less than 1 hour at the cost of approx. $7.
viewtopic.php?f=4&t=5371&hilit=SDC_65
With SDC_Zero You may single-step, inject data into any bus cycle, load a .hex file into memory, etc.