DocWaluigean wrote:
-Let's say the claw is grabbing 8-ball [#$08] that's the letter A. It's in a different rooms
-The #$08 is being assigned to a specific bin which is like Address $0022
-The claw of A [Accelerator] is mobing the 8-ball to the cubical bin of Address $0022 and drops it, and it performs special actions.
The cubical bin is RAM which keeps the thing that was last dropped into. in this case the 8-ball.
Some places that the 8-ball can be dropped into are not cubical bins, but instead chutes that leads to things like a large button that flashes lights (PPU Registers).
All the while, due to strange laws of computer physics the Accumulator Claw still has a 8-ball despite the claw dropping it so many times.
DocWaluigean wrote:
Anyway, I'll try and see what each by each works as I'm re-reading my early post.
I think you got the general idea that the CPU and PPU have different address spaces which is why address $0000 can refer to two different things.
So instead lets see if we can make sense of what this piece of code is doing (which has nothing to do with differing address buses).
tldr/summary: All labels between
.enum $xxxx and
.ende goes to RAM starting at $xxxx and not ROM.
------
First remember these are instructions to the
assembler.
We are attempting to command the assembler to generate the contents of a ROM that will be later executed by a 6502 CPU in a NES machine.
By default most assembler instructions will generate 1 or more bytes in the resulting ROM. It'll also keep track of how many bytes it has written so that when a label like
MyVariable0: comes along the assembler will know what byte the label means.
This says a couple things on how the assembler should behave for the code that follows:
First
.enum says that until the assembler sees a
.ende it should not generate any bytes to the ROM, but to still track how many bytes instructions would of taken. That way labels still work.
The second part
$0000 sets what address it's label tracking byte count starts at. asm6 still keeps it's old counter which it'll revert to once it gets to the
.ende
If you remove the
; from the lines after the note, those lines will become active assembler instructions.
Normally
.dsb generates a number of filler bytes, but since the assembler is in a
enum block, it won't actually write that to ROM. It'll simply add 1 to the assembler's internal address counter (properly called the Program Counter).
The result of this instruction is that the label
MyVariable0: is $0000, and the next label (if any) will be $0001.
The Program Counter is $0001, so the label
MyVariable1: is $0001. Program Counter is increased by 3 so the next label will be $0004.
As explained above the assembler exits it's enum mode, restoring the Program Counter to whatever it was before, and generating more ROM bytes as it encounters more instructions.
So why does the assembler have this whole enum mechanism anyway? Labels that automatically add up their sizes are useful to work with, but the automatic generating of bytes into ROM becomes a hindrance when working in a area that doesn't exist in the ROM at all. Namely the RAM.
The term enum is shorten from the word enumeration which is the process of giving ordered numbers to a list of things, and that's basically the purpose this asm6 assembler mode.
The rest of that code then repeats these enum blocks for you to put more non-ROM things located at $0100 and $0200.