Page Map for all to use

[+grafixbmp]

While working on my current project, I needed a way to keep track of the memory I used in ROM and the only way I could fore see a way to do that was with a map and I thought some of you might like this as well if you want. You can do whatever you want to with it just as long as it help anyone besides me.

 

[tokumaru]

I usually keep track of ROM and RAM usage by listing memory ranges and what they are used for, using a simple text file.

 

I'm having a hard time figuring out how one would make use of the sheet you posted. Do you mark the rectangles you've used? Do you use different colors for different kinds of data?

 

Note that I'm not trying to be rude or anything, I honestly want to know how that sheet could be of help when laying out data in a ROM.

[Wickeycolumbus]

I usually keep track of ROM and RAM usage by listing memory ranges and what they are used for, using a simple text file.

 

Don't keep track of RAM by hand when you can let the assembler do it for you! Try something like this:

 

	processor 6502
include "vcs.h"
include "macro.h"

seg.u vars
org $80

;variables go here for example:

my_var_1	 ds 1;1 byte variable
my_var_2	 ds 2;2 byte variable
my_var_3	 ds 1;another 1 byte variable...


seg code
org $F000
Start

;code and stuff

org $FFFA
.word Start
.word Start
.word Start

[+grafixbmp]

In my case, seeing endless pages of lists of numbers get me quadruplely guesing myself and then some. I need to see as much as possible at once. My real need is in arranging data across multiple pages and marking off what I have already used in the patterns I am using them in.

For example: I may have the latter of pages A through F used for storing data and diffrent parts of the program pulls from thoes areas. Marking off the ones I have used keeps me from hitting a road block when 2 separate bytes need to be in the same address as a concequence of indexed data if I just had number listings instead of a map (missreading numbers and not noticing untill it was too late). Sort of like puting a jigsaw puzzle together. The arangement maximizes cycles and data calls. This also allows me to reuse subroutines for diffrent parts of the map pulling the same pattern but from different indexes.

[SeaGtGruff]

In my case, seeing endless pages of lists of numbers get me quadruplely guesing myself and then some. I need to see as much as possible at once. My real need is in arranging data across multiple pages and marking off what I have already used in the patterns I am using them in.

For example: I may have the latter of pages A through F used for storing data and diffrent parts of the program pulls from thoes areas. Marking off the ones I have used keeps me from hitting a road block when 2 separate bytes need to be in the same address as a concequence of indexed data if I just had number listings instead of a map (missreading numbers and not noticing untill it was too late). Sort of like puting a jigsaw puzzle together. The arangement maximizes cycles and data calls. This also allows me to reuse subroutines for diffrent parts of the map pulling the same pattern but from different indexes.

Interesting idea, thanks for sharing it. I can see where it could be handy if it were magnified to fill up a printed page, so you could use colored pencils or felt pens to color in the sections you've used-- color coded, of course. And you could print multiple pages for bankswitched games-- it could be helpful to be able to see how you've filled in the sections of each bank and which sections are still available.

 

Michael

[tokumaru]

Don't keep track of RAM by hand when you can let the assembler do it for you!

Oh yeah, I declare variables like you described too! In my post I was actually talking about big arrays of data. With the 2600 we usually don't use RAM for large chunks of data, simply because there isn't enough RAM. But the NES, another platform I really like to work with, has 2BK of built-in RAM, and having an extra 8KB on carts is pretty common, so we do use large structures. When you can have entire levels in RAM, it helps to write down what part of the memory each type of data (level maps, tile maps, collision maps, object definitions, screen buffers, and so on) uses.

 

My real need is in arranging data across multiple pages and marking off what I have already used in the patterns I am using them in.

I see. It's nice that you arranged it as 16 rows of 256 bytes, but I can't avoid thinking that this might not be ideal for all kinds of data, since, unfortunately, not everything in programming uses the friendly powers of 2. Once you've marked down a few tables that are, say, 80, 68 or 136 bytes long, things will not be very well aligned, and the graphic might be difficult to read. This is only a concern though.

 

I usually start laying out memory like this:

 

$F000-$F0FF: PF1 patterns;
$F100-$F1FF: PF2 patterns;
$F200-$F17F: player graphics;
(128 free bytes)
$F300-$F33B: 60 bytes of whatever;
(196 free bytes)

Whenever I need to add new stuff I look for a place with enough free bytes. When you write everything sequentially like that you hardly make any mistakes. Anyway, this is just me. Each developer has it's own ways, and nobody can say that one approach is better than the other, they are just different. I might even give your method a try the next time! =)

[+grafixbmp]

My real need is in arranging data across multiple pages and marking off what I have already used in the patterns I am using them in.

I see. It's nice that you arranged it as 16 rows of 256 bytes, but I can't avoid thinking that this might not be ideal for all kinds of data, since, unfortunately, not everything in programming uses the friendly powers of 2. Once you've marked down a few tables that are, say, 80, 68 or 136 bytes long, things will not be very well aligned, and the graphic might be difficult to read. This is only a concern though.

 

Actualy,the way this is arranged is by the byte level. There are no powers of 2. I counted out each byte from each page so that the low bytes as they would be in HEX (but are written in decimal) are displayed by how many bytes are in each page of the ROM space and each page is by the actual hex values.

 

So 00 through FF is across the top for the lo byte of a memeory address just written in decimal and the hi byte is down the left as F0 through FF. Each individual byte is there as a block on the map.

 

Maybe this will help.