Pleasingly old-school site. Minimal JavaScript (in fact, none), maximal content document (not app) that loads quickly. It's on the colourful side, but there's no lack of contrast. Judging by the source, it's probably handwritten HTML too.
Like I recall he says, I think 6502 was one of the last cpus which assembly was designed for being written by humans (in contrast to modern cpus where all the pipelining and other optimizations make it almost pointless to write most things in assembly). This and other things make it a great platform to learn assembly.
The 68000 was pretty predictable and easy to write assembly for. Even up to the 68030 Motorola was still valiantly trying to document the cycle counts of instructions, but the tables were getting pretty big and complicated and the customers pretty much stopped caring (collapsing hundreds of cases into "Okay, indexing is slower, we get it"). The compiler writers I sat next to never relied on the timings anyway, they just ran code. Against various chip revisions if they were smart.
ARM assembly was also pretty pleasant to work with, and earlier ARM CPUs were a lot more like 6502s than the modern plumber's nirvanas of speculation, multiple cache levels and cache coherency protocols.
Essentially all CISC ISA's were designed for "assembly being written by humans". But I'd still choose RISC-V as a first platform to learn assembly for, before anything else. 6502 is particularly crappy in that it only has a 256-byte, non-relocatable stack, which is not really designed for the familiar use (to us) of enabling reentrant subroutines as in C... so even before you take the limitation to a 16-bit address space into account, the most complex thing you're going to be able to "naturally" compile for the platform is some sort of old-school FORTRAN- or BASIC-like language. I can see being interested in the 6502 for the history or the simplicity on the hardware side, but it does have a lot of baggage that's frankly a bit primitive from a modern POV.
Compile into 6502? The CPU was designed to be programmed in assembly, by humans. If your first instinct is to reach for a compiler, you're using the wrong CPU.
I think one great reason to learn 6502 assembly is to write your own Nintendo games and play them on real hardware. Admittedly, that's an extremely niche thing to do, yet there's a thriving community [1] dedicated to the hobby.
The 6502 is still used today in cheap embedded devices, where they are often programmed in an HLL (some C subset is common); its architecture is more similar to that of microcontrollers, which are just as if not more "unusual" and constrained (8051, Microchip PIC) --- and for which compilers exist too.
NES/SNES, Commodore computers, Atari computers (including the 2600), BBC Micro, Acorn computers, and the Apple I-III. There's a reason the 6502 and its variants were the proc of choice for so many computers.
It's also a decent target for C, if you use cc65 (though proper reentrancy is indeed going to be a challenge). But it's hard to describe C, FORTH or PASCAL as the most "natural" high-level languages for the platform, given that the ISA doesn't really make it easy to manage a user stack.
"in computers Kilo is 1024, because four bytes is 1024 bytes"
What?
"a small game now takes 8 gigabytes, but that's 'cos modern games are sloppy, inefficient, fat and lazy..."
They include detailed models, high resolution textures and high quality sound effects and music.
"... like the basement dwelling losers who wrote them!!!"
So rarely true any more. It takes teams to create large games these days. Besides, why is a 6502 tutorial calling people who write games fat, lazy losers?
> They include detailed models, high resolution textures and high quality sound effects and music.
That may be true but the original quote isn't necessarily false either. You can't deny that modern games, like modern software in general, tend to use way more resources than they need.
Some games are clearly inefficient, but others are just making a more extreme optimization that makes one part relatively bloated. From a game development perspective, the ranking of value goes something like:
frame time > startup/load time > download/install time/space > release build time/space
Different teams have different levels of aggressiveness in pushing operations down this slope, and different projects have different demands as well. If you're not trying to render much in the first place, maybe frame time isn't actually scarce and you don't have much to gain by doing a ton of precalculation at load time. Conversely, if you're working on a AAA shooter that's struggling to hit 60 FPS and you figure out that you can shave a couple milliseconds off frame time by reorganizing the asset files in a way that makes updates 1 GB instead of 100 MB, that's an opportunity you can't afford to pass up.
But it still doesn't seem to consider that putting char data on a 40x25 screen takes one k of ram minus compression, but having a decent logo on a full color 4k screen takes a huge amount more memory. For animations/movies it obviously gets worse. Sound takes lots more, textures are huge to not get ugly at close range and so on. Stuff isn't just "twice the size" because lazy, its because 160x200 pixels isn't pretty to watch on a post-y2k monitor. I happen to like old pixels, but blaming bloat on poor code/coding is outdated.
Actually, while that might have some truth to it, game developers are very concerned about responsiveness, frame rates, and latency in a way that developers of other modern applications simply aren't, and their products tend to be much more efficient because of it. They could still probably do better in a lot of cases, but they are orders of magnitude better than webapps and electron.
Author of the site here.
The colored text next to the characters is in the personality of the 'chibiakumas' characters - Chibiko has a bad attitude and is rude, which is why she speaks like this.
The intention was to add some jokes and humor to make development seem easier for beginners and not put them off
Speaking of monsters.... https://monster6502.com/ (discussed previously at https://news.ycombinator.com/item?id=17969472 )