I want to learn Assembly to make games on the Apple II. What are the old books to learn 6502 Assembly and the Apple II itself (memory, screen management) ? And is it absolutely necessary to learn BASIC before Assembly ?
The Apple II Reference Manual includes assembly listings (with full comments!) for the Monitor ROM and Autostart ROM, the mini-assembler, floating point routines, and a very nice 16-bit "pseudo machine interpreter" called SWEET 16. Most of which was written by Steve Wozniak. Learned a lot from this book back in the day.
Here's a link from archive.org. It's not the best scan, but you can easily find other copies.
If you're feeling adventurous, you can find assembly listings for the AppleSoft BASIC language (though maybe only from third parties). It's pretty huge.
My running joke after showing off some amazing LLM-driven work is...
if you think this is impressive, I once opened a modal dialog on an Apple IIGS in 65C816 assembly
I don't think you need to learn BASIC, if you know concepts like conditionals and looping and indexing. It is interesting to compare the higher-level language of the time with its companion assembly. And you might find yourself writing BASIC programs to complement your assembly, if you stick to that platform.
<lore>
A friend dropped me a BASIC program that ran and wrote text to the Apple IIGS border. He asked me to figure it out, because it wasn't obvious what was going on. OG hacker puzzle... it was a BASIC program that jumped to hidden assembly after the apparent end of the text file (hidden chars maybe, I forget) and the assembly was changing the border at appropriate rate to "draw" on it. Those were the days... trying to find some reference to this and am failing.
</lore>
I certainly credit my stack-frame debugging capability to dealing with that stuff so long ago. Oddly enough, I didn't really find it helpful for computer architecture class. Just because you know registers exists and how to manipulate them, doesn't exactly map architecting modern hardware system. But being fluent in logic operations and bit-twiddling and indexing does help a lot.
I don't think online tutorials are a good ressources to learn programming. We just have to look at what juniors can do nowadays (they can't even write a simple program, and I'm from that generation). That's why I asked for books.
You don't have any programming experience, and yet hold strong opinions on good resources to learn programming? There's some wonderful book recommendations in this thread, but I wouldn't underestimate how much great long-form content and tutorials there are on the Web these days (vs just learning by copying snippets off StackExchange)
Definitely develop some capabilities to accomplish an elementary satisfying project in BASIC.
It's the language that was designed for you to learn about programming and a computer language at the same time.
Whether or not you actually "master" the language or just barely learn a few commands, before using a few commands to make a simple finished program. One approach would surely be a lot faster than the other ;)
After that then decide how much you learned about programming itself from the little project, then you can see how far that BASIC alone may be able to advance your programming abilities even after you may be very familiar with the language in detail, or not.
In that '80's generation of home computers with a 6502, most had built-in BASIC so a common progression for so many was to learn BASIC at the same time as learn programming, since nobody had ever had home computers before. This could be just fine for business applications. Assembly is not nearly as easy as BASIC to learn, but in some sense programming is programming.
Then for gaming BASIC was not nearly as fast as assembly but often BASIC performed just fine anyway for developing the logical game flow and making it a "fun" game at its core to begin with. The problem with BASIC was all the other little details like video, I/O, UI, HID, were all so dramatically slower because each BASIC command needed to be interpreted before it could be run on the hardware and that took a little extra time in between each command but it really added up when you have challenging hardware interfaces and not simply fundamental game logic (many times game logic can be so simple that it's never slow in any language).
For a plain BASIC game that is "complete" but is supposed to have quick action and low latency, the next step in the learning curve would then be to find out which part of the BASIC code is the main resource bottleneck when it comes to processing time, then replace that one function with an equivalent written in assembly. It was accepted that it was a lot more work then to introduce assembly to make the game do the same thing it was before, only quicker.
It may not be very clear looking back, but there were a number of good reference books and instructional approaches and so much of it was intertwined with "learn BASIC + programming at the same time" followed by "useful assembly language techniques" to speed up your programs.
As crowds moved along these lines together to a degree as they emerged, it might help to look at publication dates for the books of the time, and use what's found in the earlier texts to help you with later concepts.
This book specifically targets beginners that are new to 6502 assembly. The examples cover all of the 1980s-era computers including the Apple II. It's free on archive.org and the introductory chapters are worth reading.
> And is it absolutely necessary to learn BASIC before Assembly
If you don't have experience programming, learning BASIC before Assembly will be super helpful before you learn 6502.
If you only have experience programming in modern languages (Javascript, etc.), learning the Applesoft BASIC will also be super helpful before you learn 6502, as you'll learn how to get by without ...
A) the following language conveniences:
- function names (it's all line numbers),
- variables with more than 2 letters,
and
B) the following modern concepts:
- function calls (no stack other than for GOSUB, use subroutines with dedicated variables for passing parameters instead),
- scoped variables (everything is global),
- dynamic allocation (you have to DIM arrays with the max size upfront),
- anything object-like like structs or classes (hack it with multi-dimensional arrays)
- other fancy stuff like callbacks, promises, hashtables and any other data structure beyond arrays.
and that will nicely prepare you for 6502 assembly (or any kind of assembly really). The advantage in 6502 assembly is you can implement most of B) yourself if you do need it.
I believe one of the "standard works" to learn 6502 back in the day was Programming the 6502 by Rodnay Zaks. It's out of print, but it was printed in a lot of copies so you should be able to find one second-hand.
I'm seconding the recommendation to look at Rodnay Zack's books. For example, I really enjoyed Advanced 6502 Programming. It's a project-based tutorial for a custom 6502 machine. The design and schematics are in the book.
WRT advanced 6502 programming texts, allow me plug my (free) book "EOR #$FF: 6502 Ponderables and Befuddlements". It's 64 assembly snippets to ponder, with explanations for each in the 2nd-half of the book: https://archive.org/details/eor6502
Seconded. I bought the first edition of "Programming the 6502" way back in the neolithic, and I enjoyed it greatly. I even read parts of it again now and then these days too, just because I like it.
I used to write assembly on, at first, the AIM-65, and later the Apple II.
Is Programming the 6502 enough to learn Assembly on the Apple II ? But it doesn't explain the memory and screen management, right ? So how can we learn that ?
Someone can correct me if I'm wrong, but I believe the screen memory of the Commodore machines (ViC-20, Commodore 64) were the most straight-forward. As opposed to the more janky Apple II memory map.
You could do a lot worse than picking up a new Commodore 64 Ultimate [1]. They're a more or less faithful remake of the Commodore 64 but have an HDMI port, SD card instead of disk drive, etc. You could learn BASIC, should be able move to assembly as well—a quick search pulled up a YouTube course on 6502 assembly for the Commodore [2].
(I realize I am not contributing "books"—but others have done well in this regard. I did want to share what I think is a pragmatic way to learn 6502.)
Is the Apple II Reference Manual good for that ? Or anything specific to the Apple II, like "What's Where in the Apple" or "Understanding the Apple II" ?
There are a few distinct things here. Learning 6502 assembly is straightforward, and you'd be better learning about simple (not modern) assembly languages at a high level--opcodes, registers, noop, branch, jump, compare, accumulators, program counters, and clock cycles. From there, start writing 6502 in an emulator and seeing what happens. That's where you're going to learn, and the feedback will be a lot faster. Programming for an Apple II will be more about learning how to interact with devices through memory.
This is how I learned. This book is great. I have the worn paper copy sitting 6 feet behind me as I type this. It's worth getting a paper copy if that is still possible.
and it includes a link to the documented source code for Akalabeth (also known as Ultima 0)
Somewhere, there's an article discussing the assembly-language like bit-blitting used to draw the high-res graphics in a timely fashion and the variable/memory management techniques needed to drive that which I'm sure a bit of searching will turn up (or one can derive it from the source).
You don't need to learn BASIC first but it might be helpful for bootstrapping at the beginning. Since it's included in the computer you can PEEK and POKE memory locations from BASIC and get a feel for how memory and machine code works without needing to understand the whole entire hardware, bootloading process, etc. first.
In my opinion BASIC, with its line numbers and GOTO / GOSUB feels assembly-ish anyway - you'll be doing a lot of JMP / JSR to control program flow which is different to how modern high levels are normally written.
Original Apple II manuals written by Chris Espinosa and Jef Raskin are a treat to read. Would highly recommend, just to get a sense of what it was like to get onboarded on Apple II back in the day.
And then obviously Programming the 6502 by Rodnay Zaks.
They screen memory layout on the Apple II was a clever hardware hack but makes programming the machine more difficult. I think you'd be better off using a "trainer", like a KIM-1 simulator [0] to get your feet wet. (The KIM-1 was made by MOS Technologies, manufacturers of the 6502, as a demonstration and prototyping platform for the CPU.)
If you can do simple exercises on a machine like that and get comfortable with simple operations (loops, memory addressing modes) I think you'd have a better time grokking something more feature-filled.
If you aren't doing hires graphics, you don't have to mess with the screen memory directly. You can just call the ROM routines which has the nice side effect of working with 40- or 80-columns automatically. If you are doing hires graphics you are going to use a lookup table regardless as doing the multiplication to get the base address of a particular scanline is far too slow. You can, one time, either make a table manually, which you can use forever, or you can write a short routine that counts from 0 to 191, stick 0 in X and the scanline number in A and JSR $F411. It'll leave the base address of the scanline in $36 and $37. Which you can stick in your table.
As in other comments, if you are specifically interested in the Apple II line, the Assembly Lines books by Roger Wagner is fantastic.
Also, if you can find it Sandy Mossberg's Disassembly Lines articles in Nibble magazine were great too. Start with Assembly Lines, then read the Disassembly Lines and you'll be quite expert.
These two books will give you a good understanding of 6502 assembler - it is general but gives a good background and has a nice assembler with a full walk through of the code. I used these two books to learn 6502 on my Commodore 64 and they are highly recommended.
These are great books. I had them in paper, and they were great for understanding both how the 6502 worked, and metaphors for managing higher level constructs in ML.
I strongly recommend "What's Where in the Apple": https://archive.org/details/whatswhereinappl0000lueb
I loved that book back in the day. Specific, directly addressable memory locations are mapped to system devices in a way that is quite foreign and Wild West when compared to modern computer architectures.
Learning BASIC isn't essential, but the thing is, you might as well just do it. It's not complicated, and you're not under any obligation to develop a big piece of software with it. Have fun!
Check the books section and find something that compels you.
Also, don't forget the HUGE number of resources for 6502 assembly programming that are available in the https://archive.org/ magazine and book sections:
Its not absolutely necessary to learn BASIC before Assembly, but it will definitely help you understand the resources of the machine better if you can debug BASIC ROM code. My personal 6502 platform of choice, the Oric-1/Atmos machines, has a pretty great ROM disassembly available, from which a lot of great knowledge can be obtained - but it does of course first require an undersanding of BASIC.
In case you're curious, the Oric-1 ROM Disassembly:
Lance Leventhal's CPU books are pretty comprehensive and make it easy to switch from one architecture to another. Learning BASIC is definitely not a requirement.
I have fond memories from the late 1980s of trying to get the assembler contained within this book working, typing line after line of the MLX listing in. Unfortunately I never did finish it back then.
A week or so ago I got the urge to complete this project and I literally just finished getting the source in it to a point where it can be compiled online and then within an emulator: https://github.com/jlmcgraw/LADS_DOS33
The answer would depend on what programming experience you have?
Do you have any assembly language experience ? with other targets?
ie have you used an assembler ( and maybe linker ) before.
Are you familiar with hex? bytes, bits etc , You will learn this and much more ...
Id look for a book that targets Assembly programming on a Apple 2, ie not a book on general 6502 programming.
Such a book Id expect to discuss things like Apple 2 memory map , Apple 2 hardware and how they are used in assembler language.
Hopefully the book would also provide guidance using a particular assembler ( hopefully still available)
I googled phrase
Apple 2 assembly language programming for beginners?
and lots of very good looking links popped up.
You aim is a challenging task. Much to learn. Good luck. However entirely do able these days.
My background is electronics engineer, embedded programing on in assembler (some Motorola processors and others) and C for a few years before moving on to other things ....
Assembly is a type of programming that is unlike most programming languages, and as such, would be a really tough introduction to the field.
Can you explain a bit more about how you became interested in assembly and programming the Apple II? And specifically, why you want to start the journey towards programming there?
I respectfully disagree, BASIC/Java/Arduino hides too much about how the CPU works from users.
Getting a 6502 kit from Ben Eater, and walking though how the CPU works will implicitly show how languages abstracted away whats actually happening. And more importantly, the skills necessary to understand how to write efficient programs.
I second this -- I just found the Ben Eater series a month or so ago and put together his computer clock over the holidays. It really helps you understand clock cycles, logic chips, etc, and is a good foundation for the 6502 kit you build later in the course. And learning Assembly before BASIC is the right learning path IMO, if only to understand how CPU registers work at the electron level.
If one is interested in how internal PC registers work, than these build series do the classic eeprom microcode based CPU builds. Fabian's series is highly accessible, and builds a python based assembler from scratch. James series ends with a simple game design.
Starting with Assembly is simply a bad idea because the tooling is terrible, and the learning curve of the tooling is steep. Filled with arcane codes and abbreviations and workflow right out the gate.
Programming concepts are pretty much universal. Being distanced from computer architecture is not a limitation for novice programmers, Python et al succeeds for a reason.
If you're determined to start with assembly, then I hope you can find someone to help you get started with all the machinations necessary to get from LDA #0 to A9 00 with as little drama as possible. Someone to show you how to use the assembler, what the directives mean, the linker, a symbolic debugger (if you're lucky). Someone to provide you with a .DUMPREG "START OF SORT" and .DUMPMEM BUFF $80 "AFTER INPUT" macros that you can liberally scatter throughout your code so you actually progress and get some insight into what the heck you code is doing. Perhaps some way to stop your programs that doesn't include hitting the reset button on the machine.
I mention that because, again, the tooling is terrible. All of the is easier said than done. None of the assembly books address this, none of the assembly program reference guides do either. Assembly is VERY black box. It's a large step up to even get started.
It's much easier to "learn programming" first at a higher level, where you can quickly progress and succeed, before turning into the dark hole that is assembly, particularly on older machines.
At least on a KIM-1 you can hit the STOP button and cursor through memory (being conscious that the memory architecture of the KIM is quite funky), something that simple is quite difficult on an Apple ][.
In general, Assembly for a simple well documented CPU is fairly close to most familiar calculator operations, and is demonstrated as a 1 to 1 relationship in the binary firmware. If folks drop on abstractions like Scratch/Basic/Python/Java the students will develop a random notion of what Register/Stack/Heap even means.
I would recommend looking at a few random samples of Ben's build series, as he covers most first year subjects in subtle efficient ways.
Soldering kit PCB or Emulators are insufficient to demonstrate a physical bus wire harness, clock timing, and memory layout. Best of luck =3
Starting with the 6502 is going to bring you up hard against its addressing modes. Better IMHO to learn about memory and how to access it using arrays in BASIC first.
My opinion differs - learning how memory is accessed via assembly language will make it super easy to understand e.g. how C pointers actually work, something which can be surprisingly difficult for those who go directly to a high level (compared to assembly) language, but very easy if you come from machine code/assembly.
Honestly if you want to learn retro stuff for retro reasons... maybe consider using the retro materials? Here's the MOS programming manual for the original parts, it's what Woz would have used when hand-assembling Integer BASIC:
And it's really not so complicated! The chip is simple, so the docs are simple. There's more to read about the history to come later, but there's also something to be said for understanding it in the context its designers presented it.
Here's a link from archive.org. It's not the best scan, but you can easily find other copies.
https://archive.org/details/applerefjan78/page/n69/mode/2up
If you're feeling adventurous, you can find assembly listings for the AppleSoft BASIC language (though maybe only from third parties). It's pretty huge.
reply