6502: hardware & software

[froggit9000]

This thread is for anyone who remembers the venerable 6502 processor, the computers that used it and writing code in 6502 assembly language.
Add your thoughts / memories here.

I'll kick off with:

I had several 6502-based computers:
Commodore VIC 20
Commodore 64
Commodore PET
Atari 800

I learned BASIC first, then one day I saw the speed of machine code and started learning 6502 assembly language from then on.
I got interested in the special extender chips for the Commodore PET, like the 'PIC chip' and started exploring how to extend the BASIC interpreter, whose hook code was copied down to 'page zero' on boot by the KERNEL ROM - the so-called CHRGET routine ($0073 in RAM from memory???).

I went on to write hobby code for a game, word processor, comms code, interpreter, etc all in 6502 assembly language.

Then I had to get a real job...

I think the C64 was the best-selling home computer if I'm not mistaken, and I am pleased to see a lot of retro computing activity going on, especially new C64 computers appearing, one using an FPGA and improvements like faster USB-based solid state storage, adapted to mimic the old 1541 disk format etc, plus HDMI output etc - see:

https://www.commodore.net/category/all-products

I also built a simple Z80-based SBC on blue 'eurocard' which I still have in the attic somewhere.

 

[tingo]

ORIC-1. I still have it.

 

[bvdw78]

As a kid I got a second hand C64. It came with a manual that showed me how to code in BASIC. Man that was slow. Then at a local computer club some greybeard showed me machine code and gave me a book. Fast forward a few decades and I do security architecture at an ISP. I got a MiSTerFPGA board a few years ago that runs all sorts of retro classic computers and I'm now looking at what those folks over at commodore.net pulled off.

 

[froggit9000]

As a kid I got a second hand C64. It came with a manual that showed me how to code in BASIC. Man that was slow. Then at a local computer club some greybeard showed me machine code and gave me a book. Fast forward a few decades and I do security architecture at an ISP. I got a MiSTerFPGA board a few years ago that runs all sorts of retro classic computers and I'm now looking at what those folks over at commodore.net pulled off.

Yes the BASIC ran really slowly on the C64!
If I recall correctly, the standard MOS 6502 CPU ran at 1MHz, but the C64 had a modified 6502 called the 6510 that allowed memory bank switching (RAM & ROM at the same address space, selectable with a register in page zero memory), and this ran at less than 1MHz - 0.985 MHz for the european PAL versions according to wiki:

Commodore 64 - Wikipedia

en.wikipedia.org

What was your reaction at seeing the speed of machine code compared to BASIC for the first time?

Good to see you made a career out of your early computing experiences.

I don't know that MiSTerFPGA board, I will take a look at it as it sounds interesting.

See what you find out about the new C64s at commodore.net, as far as I know it's implemented using an FPGA and has modern HDMI video output and file system via solid state storage, but I haven't read all the details. Sounds like it would be good to get one as they eliminate the old C64 horrors of slow & unreliable tape and floppy disk storage plus the fuzzy text and graphics on the old CRT TVs.

 

[Isoux]

I was so fascinated by the 6502 (since it was socketed in my Oric Nova 64) that I removed it from its socket — after many years of faithful use, sometime around the year 2000 — and placed it into a specially made external socket connected to my PC via the parallel port. From the PC, I was sending oscillator clock pulses, control signals, and addresses to it.

The greatest excitement came when I started generating every single clock pulse manually instead of using an oscillator. After each pulse, I would either measure how many clock cycles each instruction required, or simply observe via LEDs what was happening on the processor pins. It felt as if the CPU was running one clock cycle every few seconds.

At that moment, I realized I had absolute control over the processor — at my own rhythm, one cycle at a time. That experience deeply shaped the way I later approached both programming and electronics. It taught me to think in terms of signals, timing, and real hardware behavior, not just abstract code.

Even today, when I work with modern systems, that early hands-on understanding of how a CPU actually “breathes” internally still influences how I design, debug, and reason about machines.

 

[unitrunker]

The clock was 1MHz but each instruction took two clock cycles.

 

[richardtoohey2]

Acorn BBC B Microcomputer for me

And thanks to Dad's hoarding habits I've still got it.

Learnt how to program on it using BBC BASIC, dipped my toe in 6502 assembly (mostly learning how to transfer games from cassettes to disk drives and to learn how things worked.). And sent me on the IT career path.

Life was a lot simpler back then.

 

[froggit9000]

I was so fascinated by the 6502 (since it was socketed in my Oric Nova 64) that I removed it from its socket — after many years of faithful use, sometime around the year 2000 — and placed it into a specially made external socket connected to my PC via the parallel port. From the PC, I was sending oscillator clock pulses, control signals, and addresses to it.

Did you run code on the removed 6502, or were you more interested in observing the way pins went HI or LO when you injected clock pulses, control signals and addresses?

The greatest excitement came when I started generating every single clock pulse manually instead of using an oscillator. After each pulse, I would either measure how many clock cycles each instruction required, or simply observe via LEDs what was happening on the processor pins. It felt as if the CPU was running one clock cycle every few seconds.

Is that because you slowed down the injection of clock pulses to the CPU?

At that moment, I realized I had absolute control over the processor — at my own rhythm, one cycle at a time. That experience deeply shaped the way I later approached both programming and electronics. It taught me to think in terms of signals, timing, and real hardware behavior, not just abstract code.

Even today, when I work with modern systems, that early hands-on understanding of how a CPU actually “breathes” internally still influences how I design, debug, and reason about machines.

I agree, these early experiences with hardware give a deeper understanding of what is happening within a computer: CPU, memory reads and writes, address bus, data bus etc.

 

[froggit9000]

The clock was 1MHz but each instruction took two clock cycles.

I thought, from memory, that the number of clock cycles required to execute an opcode depended on the instruction itself - implied mode (PHP, PLP, INC, DEC etc) used one clock cycle, some instructions used 2 clock cycles (relative branching with BNE, BEQ etc), and some even required 3 clock cycles for things like JMP or JSR where the CPU had to load a 16-bit address and jump to that address.

 

[froggit9000]

Acorn BBC B Microcomputer for me

And thanks to Dad's hoarding habits I've still got it.

Learnt how to program on it using BBC BASIC, dipped my toe in 6502 assembly (mostly learning how to transfer games from cassettes to disk drives and to learn how things worked.). And send me on the IT career path.

Life was a lot simpler back then.

It shows what a great influence using these early computers had on forming our careers!

 

[unitrunker]

Hitting the bookshelf ...

From the SY6500/MCS6500 Microcomputer Family Hardware Manual, August 1976, in Appendix A.

It lists a set of Single Byte Instructions. "These single byte instructions require two cycles to execute."

Other instructions require more cycles. I should have written "at least".

The upper bound on IPS will be less than half the clock frequency. Many instruction take more than a few cycles.

Oh wow, here's an online copy.

bbc-documents/ICs/6502 CPU/synertek_hardware_manual.pdf at master · bitshifters/bbc-documents

BBC Micro reference material. Contribute to bitshifters/bbc-documents development by creating an account on GitHub.

github.com

Look for Appendix A.

 

[Isoux]

Did you run code on the removed 6502, or were you more interested in observing the way pins went HI or LO when you injected clock pulses, control signals and addresses?


Is that because you slowed down the injection of clock pulses to the CPU?


I agree, these early experiences with hardware give a deeper understanding of what is happening within a computer: CPU, memory reads and writes, address bus, data bus etc.

Yes on the removed 6502. I even had simple instructions and addresses prepared, which I sent from the PC through the parallel port into 74HCxx flip-flop chips (like 74HC373 Octal D-type Transparent Latch) effectively emulating ROM and RAM. Over time, I have forgotten many of the details of what I was doing back then — but I clearly remember the feeling of building the entire system piece by piece, signal by signal.

Yes it is because I slowed down the injection of clock pulses to the CPU. I was generating the clock pulses manually, and what fascinated me most was that the CPU had no minimum clock frequency — it could run from zero Hertz up to megahertz. I could pause it between cycles and it would simply continue where it stopped.

It’s a pity that user 6502 : hasn’t joined the discussion — I’m sure he could share many valuable insights with us.

 

[froggit9000]

Hitting the bookshelf ...

From the SY6500/MCS6500 Microcomputer Family Hardware Manual, August 1976, in Appendix A.

It lists a set of Single Byte Instructions. "These single byte instructions require two cycles to execute."

Other instructions require more cycles. I should have written "at least".

I stand corrected, thank you!

In my mind I had confused 'number of bytes per instruction' with 'clock cycles per instruction'.
For example:
1 byte per instruction: PHA, PLA, PHP, PLP, SEI, BRK, TXA etc
2 bytes per instruction: BNE label (one byte for BNE instruction plus a byte for the relative offset forwards/backwards from the Program Counter Address (right terminology?))
3 bytes per instruction: JMP $XXXX (one byte for the JMP instruction plus 2 bytes for the 16-bit address to jump to)

Looking at that Appendix A, it says the lowest number of clock cycles required for an instruction is 2 cycles, and the highest is 7 cycles!

The upper bound on IPS will be less than half the clock frequency. Many instruction take more than a few cycles.

Oh wow, here's an online copy.

bbc-documents/ICs/6502 CPU/synertek_hardware_manual.pdf at master · bitshifters/bbc-documents

BBC Micro reference material. Contribute to bitshifters/bbc-documents development by creating an account on GitHub.

github.com

Look for Appendix A.

Yes, at 1MHz CPU frequency, if an instruction takes 2 clock cycles - i.e. 2 millionths of a second, you could only execute 500,000 of them in one second. But as most instructions take more than 2 clock cycles, in normal operation it's probably executing no more than about 200,000 to 250,000 instructions per second (assuming an average of 4 to 5 clock cycles per instruction). Does that sound about right?

 

[froggit9000]

Yes on the removed 6502. I even had simple instructions and addresses prepared, which I sent from the PC through the parallel port into 74HCxx flip-flop chips (like 74HC373 Octal D-type Transparent Latch) effectively emulating ROM and RAM. Over time, I have forgotten many of the details of what I was doing back then — but I clearly remember the feeling of building the entire system piece by piece, signal by signal.

My memory from my hardware dabbling days was that with these TI 74xx-series latch chips you set a HI or LO to each of the data input pins and then the chip would retain the written value until you told it not to (like a memory register) - is that correct? So in that way you could write bytes to these 8-bit latch chips and then the CPU would act on this injected byte in some way?

Yes it is because I slowed down the injection of clock pulses to the CPU. I was generating the clock pulses manually, and what fascinated me most was that the CPU had no minimum clock frequency — it could run from zero Hertz up to megahertz. I could pause it between cycles and it would simply continue where it stopped.

It’s a pity that user 6502 : hasn’t joined the discussion — I’m sure he could share many valuable insights with us.

Got you. That's interesting you could totally control the clock frequency and the CPU would run at any speed, or pause and then continue execution.

 

[Isoux]

My memory from my hardware dabbling days was that with these TI 74xx-series latch chips you set a HI or LO to each of the data input pins and then the chip would retain the written value until you told it not to (like a memory register) - is that correct? So in that way you could write bytes to these 8-bit latch chips and then the CPU would act on this injected byte in some way?

Exactly!

 

[6502]

Even the Terminator T-800 is using 6502.

 

[SirDice]

I have a C64 (original breadbox model), C64c (the redesigned model), SX-64 ('portable' C64), C128d, Ultimate 64 II cartridge (highly recommend it; it's awesome). Apple ][gs (the 65816 has a 6502 mode). Oh, and I bought Ben Eater's 6502 kit. Yes, you can still buy brand new 6502 chips, they are still being produced.

I had to restrain myself from buying the "new" C64.

 

[bvdw78]

My C64 development workflow nowadays centers around KickAssembler (remind me to create a FreeBSD port for that!) and VICE on top FreeBSD. Unfortunately I don't own any vintage C64 hardware anymore. The one I grew up with broke down, so I donated it to the local computer museum for parts. They have a lot more use for it than I do.

 

[SirDice]

but the C64 had a modified 6502 called the 6510

The 6510 is a 6502 with an added 8 bit I/O port (you'd call them GPIO nowadays) at address 0000 and 0001. Some of those I/O ports were indeed used to bank switch, the C64 had 64K ram, you could switch off all the custom chips and ROMs to access the full 64K of memory. Other bits were used to control the tape drive.

 

[unitrunker]

The 6510 is a 6502 with an added 8 bit I/O port (you'd call them GPIO nowadays) at address 0000 and 0001. Some of those I/O ports were indeed used to bank switch, the C64 had 64K ram, you could switch off all the custom chips and ROMs to access the full 64K of memory. Other bits were used to control the tape drive.

Never worked with a 6510. Was this a separate address space or displaced two bytes from page zero?

 

[unitrunker]

I even had simple instructions and addresses prepared, which I sent from the PC through the parallel port into 74HCxx flip-flop

You built your own ICE (In-Circuit Emulator). That's impressive.

 

[trev]

Ahh, the Commodore VIC-20. My first computer. I ran a BBS on it for three years from 1983-1986. Learned BASIC and 6502 machine code. Fun times.

 

[SirDice]

Never worked with a 6510. Was this a separate address space or displaced two bytes from page zero?

6502 (and thus the 6510 too) uses memory-mapped I/O, the two registers for the I/O port were the first two bytes from page 0 (address $0000 and $0001). It has some other minor differences and the pinout got shuffled a bit, but other than that it's the same as a 6502.

 

[froggit9000]

The 6510 is a 6502 with an added 8 bit I/O port (you'd call them GPIO nowadays) at address 0000 and 0001. Some of those I/O ports were indeed used to bank switch, the C64 had 64K ram, you could switch off all the custom chips and ROMs to access the full 64K of memory. Other bits were used to control the tape drive.

Yes that's right. The programmer could do funny things like copy the kernel/BASIC ROMs to RAM at the same address space and mod the code so you could customise things if you should so wish, or use the RAM for other purposes.

Here are a few pics of the relevant parts of the C64 Programmer's Reference Guide.

Pics all got rotated, can I get them the right way round?

 

[SirDice]

The programmer could do funny things like copy the kernel/BASIC ROMs to RAM at the same address space and mod the code so you could customise things if you should so wish, or use the RAM for other purposes.

Yep. The character ROM also overlaps with the register addresses of the CIAs (they're both in the 4K $D000-$DFFF range). Games typically turned off the BASIC and KERNEL ROMs (you don't need any of it and have more RAM available for code/data)

Bank Switching - C64-Wiki