Junky 6502 Assembly Tutorial Outline

[Lucky]

I looked through the instruction set, and tried to come up with an outline for writing a 6502 assembly tutorial. The notes are kind of slapped together, but I think you can get the idea.



Introduction - Machine Language, and the 6502 processor. Brief description of what a register is and does, and what memory is used for. Nothing remotely in depth.
Quiz.

Binary and Hexadecimal. Why and how. Conversion between decimal, binary, and hex.
Exercises

Using the 6502 Simulator. Writing and running a first program with presupplied preprocessor code, using only LDA. Get user familiar with simulator, step through, watching registers, etc.
Exercises

Writing and running the second program. LDA, LDX, LDY. More talk about registers.
Explaining why 8 bits and value ranges.
Exercises

INX, INY, DEX, DEY.
Exercises

TAX, TAY, TXA, TYA
Exercises

ADC, SBC
Exercises

STA, STX, STY
Exercises

LDA, LDX, LDY Revisited (Loading from absolute memory, not immediate)
Exercises

INC, DEC
Exercises

ASCII and output to the screen
Exercises

Explanation of code preprocessor stuff (.org $0200, .db, etc.)

More output to the screen stuff using predefined memory, Indexed addressing
Various functions and exercises revisited with output.

Flags register introduction. Carry flag, CLC, SEC
16-32 bit addition exercise

JMP
Exercise

Zero flag, branching.
Looping / revisiting inc/dec
8 bit Multiplication exercise

AND/EOR/ORA, more branching
exercises

CMP, CPX, CPY, BIT, keep on branching and looping!
exercises

ASL, LSR, ROL, ROR
exercises

Introduction to the Stack
PSA, PLA
exercises

Subroutines, JRS, RTS
exercises

More exercises (don't know yet, but more advanced stuff)

Stuff about the stack I don't fully have an application for yet (TSX, TXS, PHP, PLP)

Zero Page

More flags stuff (decimal mode, interrupts, overflow flag)

Branching with overflows and negative flags.

NMI and interrupt codes (RTI)

Throw in NOP for good measure

Final exercise/project



Towards the very end I get a little sketchy about stuff, but I'm 99.99% I can learn that part before I get to the part of writing about it. The toughest part will be designing both educational and entertaining exercises. With some readjustment of my outline, it would be possible to get people to build on previous exercises and make a finite project in the end, which could be very challenging and rewarding. That will take a lot more outlining as well. Plus more sections need to be written for advanced techniques. Which techniques I'm a little at a loss for...

What do you guys think?

[Disch]

One of these days I should check out that 6502 simulator so I can see what it does.

Anyway, the reason I posted was to suggest that you fit in a few key programming concepts. Assuming you're speaking to people with zero existing experience, it's good to talk about bare-bones fundamentals of programming. "What is a variable" kind of stuff. Branches should probably be covered earlier.... as they open the door to talking about conditionals and loops. And loops open the door to talking about arrays. And eventually you'll want to touch on pointers.

Once the concepts on how to apply the stuff is down, most of the instructions' uses will be apparent, and the tutorial won't have to go over every single one of them. Maybe a few could be touched on though.

Also, considering the complexity of ADC/SBC (they're probalby two of the most difficult instructions to completely understand 100%), they should probably be intruduced later.

But tomorrow I'll try and check out that 6502 Simulator so I can get more of an understanding. I do really like the idea of teaching 6502 without getting into any nitty-gritty NES stuff. That's just too much for a newbie to swallow at once.

[Lucky]

Thanks for the input Disch, what you said makes a lot of sense too.

I think you're absolutely right about the ADC/SBC needing to come later. And there definitely needs to be some bare-bones fundamentals stuff in there.

I'm definitely on the same track with you, but it's going to be difficult to find a balance of programming and fundamental explaining. So many tutorials suffer from 50 page fundamental primers before any programming happens, and the user is left giving up at page 30 after being overloaded with no reward to back up the concepts they're trying to understand. It will take a careful balance to keep the reader engaged and practicing while getting over that first hump.

[ManicBernard]

Did this ever get written?