
Learn Multi Platform 6502 Assembly Programming for Monsters - ingve
http://www.chibiakumas.com/6502/
======
userbinator
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.

Speaking of monsters.... [https://monster6502.com/](https://monster6502.com/)
(discussed previously at
[https://news.ycombinator.com/item?id=17969472](https://news.ycombinator.com/item?id=17969472)
)

~~~
morenoh149
css is also a single file, 106 lines, mostly color definitions.

------
rixrax
This was a nice blast from the past! :)

Another great resource on 6502 in my opinion have been David Wheelers write-
ups on 6502[0].

[0] [https://dwheeler.com/6502/](https://dwheeler.com/6502/)

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.

~~~
zozbot123
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.

~~~
chongli
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.

[1] [https://forums.nesdev.com/](https://forums.nesdev.com/)

~~~
userbinator
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.

------
danellis
"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?

~~~
Narishma
> 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.

~~~
0xcde4c3db
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.

