Graphic RAM is confusing

[itoshkov]

Using Graphic RAM is quite confusing and the documentation isn't very helpful. It took me looking at the source + some experimentation to finally understand how it works.

Here are the things that I found strange:

1. Each pixel is controlled individually, so the number of addresses you have corresponds to the number of pixels you can control. For example 8-bit address means that you can control 256 pixels.
2. It's up to the user to make sure that the number of pixels correspond to the number of addressable pixels.
3. The data bits control the color. 1 bit mean you have just black and white pixels. 2 bits - 4 colors and so on. The individual colors are hard-coded in the source and cannot be changed (as far as I know).
4. The double buffering really confused me for awhile. To use it, you just need to have twice as much addressable pixels as the pixels on the screen. You can then write in the higher half of this address space, while B input is 0. When you're ready, you switch B to 1 and you see what you've drawn.

Here are some suggestions:

1. Add the ability to read and write multi-bit values, like the other RAM chips.
2. Keep the pixel depth (number of bits per pixel), but make it clearer.
3. The double buffering is a good idea, just needs better explanation
4. Ability to assign individual colors or color schemes.

[itoshkov]

One way to present the above is: the user specifies the number of pixels (W x H), bits per pixel, color-scheme, whether they want double buffering and the data width and the system computes the address width.

[hneemann]

Each pixel is controlled individually, so the number of addresses you have corresponds to the number of pixels you can control. For example 8-bit address means that you can control 256 pixels. It's up to the user to make sure that the number of pixels correspond to the number of addressable pixels.

This way you can hook the RAM to the address and data buses you have. You don't need splitters to reduce the bit width for the graphic RAM. Maybe this is confusing.

The data bits control the color. 1 bit mean you have just black and white pixels. 2 bits - 4 colors and so on. The individual colors are hard-coded in the source and cannot be changed (as far as I know).

You are right: A fixed color palette is used containing about 100 colors.

The double buffering really confused me for awhile. To use it, you just need to have twice as much addressable pixels as the pixels on the screen. You can then write in the higher half of this address space, while B input is 0. When you're ready, you switch B to 1 and you see what you've drawn.

This is how double buffering works. ;-)

Here are some suggestions:

Add the ability to read and write multi-bit values, like the other RAM chips.

I'm not sure what you mean. You can write multi bit-values to the RAM. It works exactly like the other RAM chips.

The double buffering is a good idea, just needs better explanation

This is really a good idea. But the idea dates back to the late 80s. See Page flipping.

Ability to assign individual colors or color schemes.

Can you explain your use case in more detail. I'm surprised that someone wants to use a more powerful graphics interface in a such a simulator.

[hneemann]

One way to present the above is: the user specifies the number of pixels (W x H), bits per pixel, color-scheme, whether they want double buffering and the data width and the system computes the address width. This is a good idea: I have removed the address bits settings. Now the width of the address bus is calculated from the size of the screen.

[itoshkov]

I know that double buffering is a old idea. I just haven't seen it implemented in a chip like that, though it makes sense because it is the RAM and the display simultaneously. What I found confusing is, that it's not described almost at all in the docs and, combined with the other things I found odd in this chip, it took me awhile to understand it. So just a bit more documentation should be enough :)

Here is my use case: I want to implement the HACK computer described in http://nand2tetris.org/. It uses 16-bit words and thus controls 16 1-bit pixels with a single write in the video RAM. Also it can read 16 pixels with a single read. If I want to implement this with the current Graphic RAM, I have to do some serious hacks (or maybe there is an easy way to do that, which I just don't see?)

Another use case would be to implement some existing computer, e.g. Apple ][. It has a somewhat peculiar interface, so I guess you'll have to put the line somewhere. Maybe the whole thing can be better solved through issue #59?

[hneemann]

Now a simple mechanism is available to use custom components implemented in java. See #59.