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" ?
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)
Nothing wrong with internet searches (though I find Google is most useful for results from Google sites).
But HN is full of 6502 enthusiasts, so I approve of tapping their collective wisdom to discover personal favorites and recommendations.
Unlike modern computers, 8-bit systems were expected to be programmed by their owners! As a result there are many books from the 8-bit, pre-internet era explaining exactly how to do so, and many of those books are conveniently available on the modern internet (perhaps via a google or other search, or on archive.org, etc.) Many systems also came with user instruction manuals explaining how to program them.
Note how it explains everything from scratch, including how to hook the Apple II up to a TV, how to use the keyboard, and how to start up BASIC.
BASIC was designed as a simple but effective programming language that could be learned by computing novices (first year college students) in an afternoon. Here is the original Dartmouth BASIC manual (23 pages long!) from 1964:
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.
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.
