Yes In theory, global state refers to all RAM, ROM and I/O devices that can be read from and/or written to by the microprocessor. In practice, it refers to the subset of addresses referenced in the scope of your program's execution. With no pesky memory management hardware to get in your way, you are pretty much free to do whatever you want.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Among the great leaps forward in computer programming are type safety, data encapsulation, and data hiding. And we don't get any of that when working at assembly level. I think some of us who enjoy working at a low level like the feeling that we're dealing with things as they are, with the minimum of abstraction. But I think everyone would agree that the assembly language programmer will be less productive: everything is more difficult. There are potential advantages in performance, density, efficiency, which rarely make it worthwhile in the commercial world.

I agree. One of the things I'm unlearning is the tendency to group related things together, like a class in a high language.
That being said... I am having a blast learning C64 assembly. It's bringing back very fond memories.

Yes, it's fun to do! And there's an immediate reward in fixing a bug, or getting something working.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

DanielS: Functional abstraction, modularity, and such is absolutely possible in assembly language, even with just a light layer of macros to manage things. But, given that the context is the Commodore 64 and not some 14-100MHz newer variant, 1MHz is not a lot (~15k-18k cycles available per frame, visible using raster bars for profiling), and 64KB is not a lot when you start writing code in such a fashion. You hit walls very quickly after you get such a framework bootstrapped.

Hence, things trended to the shortest and fastest way in competitive development (commercial, demoscene, etc), which is to directly access known memory locations in a static layout, using only up to 1 level of indirection through static-location vectors, as the baseline development style. Venturing further than that comes at noticeable cost, but that tradeoff certainly can be appropriate for the higher-complexity end of things. Just don't start there, build up to it.

IMO, the best way to get into the mindset of the time is to read source code listings & dive into disassemblies. All the C64 ROMs sources/disassemblies are commented online in various forms, and you can see some of the static layout techniques in play.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

These are the same thing, really. If you declare HEAPBASE to be locations $20-$21, you can consider that a "global variable" that everything in your system has access to and many things may use; there'd typically be no point in making copies of that and passing it around. If you declare TMP0 to be locations $30-$31, you might consider that to be something for temporary internal use by any routine that declares it does so, and you must be careful that one routine that uses it doesn't call another routine that uses it without saving its own copy of the data there first, if it still needs it after the call. This isn't something you'd think of as a "global variable," but of course, being just memory locations, it's still something that any code has access to.

Assembly is a bit like BASIC in a way: there's no such thing as a truly "local" variable except what you push on the stack (and you need to make sure you pull those data off before you execute a RET).

_________________
Curt J. Sampson - github.com/0cjs