I don't think of retro-computing as an activity limited solely to the hardware and software that existed at a given time, that's far too restrictive for me.
6502 is an architecture, not a specific machine, nor even the set of machines that supported that architecture in the past. The architecture is and remains interesting on its own! (6502 assembly remains a really good intro to assembly, for instance, even for people that have never even seen a C64.)
There is absolutely scope for people to do fun things with 6502 that could never run on a C64 or an Apple II. The vast majority of 6502 code today runs in emulation, so there's really no reason to artificially gimp it to ape the limitations of any given machine. (Unless emulating that specific machine of course!)
> The vast majority of 6502 code today runs in emulation
Emulating a 6502 isn’t that popular, so _if_ there’s even a single commercial product still using a 6502, I would guess that could easily run more 6502 cycles in total than are getting emulated.
- It was true during the Tamagotchi craze (https://hackaday.com/2013/05/24/tamagotchi-rom-dump-and-reve...: “it was a huge chore just to figure out what processor this uses. It turned out to be a 6502 core with a few other things built in”), but that’s over 20 years ago.
So, where, if anywhere, are these things being used?
> 6502 assembly remains a really good intro to assembly
It... really is not, though. It doesn't teach you macro assemblers as they exist in the modern world. It doesn't teach you interaction with the linker except in the simplest ways.
And while the instruction set is "simple" in the sense that it can be understood on a page of paper, lots of critically important ideas don't exist in a meaningful way. Modern techniques like register assignment aren't possible given the limitations and non-orthogonality of the CPU state. There's no "ABI" equivalent you can use to call a standard function, and even something as foundational as "passing arguments" to a function isn't directly expressible, because the "stack pointer" isn't actually a pointer. In point (heh) of fact, no pointers are pointers because the 6502 doesn't actually have an abstraction for a memory address!
Everyone should learn to hack on an Apple II (and good grief, not a Commodore unless you are trying to learn VIC-II or SID hardware), but not to teach themselves "assembly" as a skill they might apply elsewhere.
In fact it's almost the same argument used for why we teach new kids Python and not BASIC. The latter just isn't a useful tool for expressing the concepts you need to learn.
I was almost with you, because much as I love the 6502, it is kind of weird by modern "standards". But then: the Apple II? Like, wtf man. C'mon. The Apple II is shit. Is it just because you like that sweet double density disk throughput? Well, fair enough, but then why not go for the BBC Micro. 2 MHz, plus 80 columns. OK, so it only has 32 KB RAM... meanwhile, you are still American.
In summary, please tell us how many shades of mucky greyish brown you get with the Apple II. Because with the C64, you get 13.
> Well, fair enough, but then why not go for the BBC Micro
Because the Apple shipped four years earlier? The question isn't what machine is better. Obviously later hardware builds on the advances of its ancestors. The idea behind valuing history is understanding where the changes happened.
Acorn (and Commodore) shipped an excellent machine given the constraints of the time. Both devices were worth purchasing.
Apple shipped an absolutely groundbreaking work of genius that no one had forseen and that no one would duplicate for years. AAA games were shipping in 1988 (c.f. Ultima V and Prince of Persia) designed directly to a framebuffer design architected in the spring of 1977.
If you can't see the difference there and perceive which device is more important to understand and study, I don't know what to say.
> It... really is not, though. It doesn't teach you macro assemblers as they exist in the modern world. It doesn't teach you interaction with the linker except in the simplest ways.
What does the processor/instruction set have to do with the available tooling?!
FYI back in the day much of Acorn's (BBC Micro = 6502) software was written using a very capable macro assembler (source: I worked there).
Yes! I learned 6502 assembly from the Apple ][ system manual. You got the op code tables, the schematics and Woz‘s monitor incl. listing and a disassembler. It motivated me to learn English, forced me to carefully calculate relative jumps and taught me to think first then code. Two of the three still useful skills.
> Wow you really are into telling people what they should do.
Saying "6502 is not a good platform for learning assembly" is simply not the same thing as saying "you should not learn assembly language with a 6502 assembler", and I don't understand how you're interpreting it that way.
It's just giving you my opinion and advice. By your own logic, you are now trying to censor my ability to give that opinion and advice. That's bad too, right? Why are you "telling me what to do"?
Chill. Opinions are OK. If you don't agree, that's fine. But a better response is a reasoned counter argument and not "don't say that".
6502 is an architecture, not a specific machine, nor even the set of machines that supported that architecture in the past. The architecture is and remains interesting on its own! (6502 assembly remains a really good intro to assembly, for instance, even for people that have never even seen a C64.)
There is absolutely scope for people to do fun things with 6502 that could never run on a C64 or an Apple II. The vast majority of 6502 code today runs in emulation, so there's really no reason to artificially gimp it to ape the limitations of any given machine. (Unless emulating that specific machine of course!)