Reading color memory

adric22 · Post by **adric22** » Sun Oct 26, 2008 2:27 pm

Why do I get random numbers when trying to read back color memory?

Boray · Post by **Boray** » Sun Oct 26, 2008 2:36 pm

You do? Maybe because it's just nibbles, 4 bit memory.

adric22 · Post by **adric22** » Sun Oct 26, 2008 3:28 pm

Boray wrote:You do? Maybe because it's just nibbles, 4 bit memory.

Ah.. I think that is the answer. I tried reading it while AND'ing it with $0F and it works reliably.

I'm trying to build a little program for drawing PETSCII art on the VIC-20 and C64 and I was hoping not to have to store the color memory elsewhere, especially on the VIC since I want it to run on an unexpanded machine.

Post by **Jeff-20** » Sun Oct 26, 2008 3:30 pm

Color memory doesn't use the whole 8 bits of the location. I think only 4 bits. The higher four bits is used for something else. So you have to read it with something like PEEK(location)AND7.

adric22 · Post by **adric22** » Sun Oct 26, 2008 6:04 pm

Jeff-20 wrote:Color memory doesn't use the whole 8 bits of the location. I think only 4 bits. The higher four bits is used for something else. So you have to read it with something like PEEK(location)AND7.

Now wait a minute.. something just occurred to me. If it is only 4-bit color memory, is it not possible to display a different background color for each cell like on the C64?

Post by **Jeff-20** » Sun Oct 26, 2008 6:21 pm

Nope. I don't own a 64, but the answer is surely no.

I think the top 4 bits are either random garbage or somehow connected to the clock because it is not consistent. I'm not sure. I'll have to look it up.

Mike · Post by **Mike** » Mon Oct 27, 2008 2:56 am

Jeff-20 wrote:Color memory doesn't use the whole 8 bits of the location. I think only 4 bits. The higher four bits is used for something else. So you have to read it with something like PEEK(location)AND7.

PEEK(location)AND15 will also preserve bit 3 (value: 8), which indicates multi-colour enable. The upper 4 bits are bus noise, picking up everything that had been there in the previous cycle (i.e. essentially random).

adric22 wrote:Now wait a minute... something just occurred to me. If it is only 4-bit color memory, is it not possible to display a different background color for each cell like on the C64?

The colour-memory for text display on the C64 is also only 4 bits wide.

However, when displaying hi-res, the text screen will supply attribute data, giving 2x4 bits for back-, and foreground for a 8x8 pixel cell.

Michael

carlsson · Post by **carlsson** » Mon Oct 27, 2008 3:36 am

.. and the VIC-20 doesn't have a such bitmapped graphics mode so no, your idea to use a different combination of foreground and background at each character won't work, at least not in any easy way.

The reason why the memory is only four bits wide is because it a total of 512 bytes covering an area of 1K (37888-38911). When you change the location of the screen, the location of colour memory alternates between 37888 and 38400. If you define a larger screen area you may use bigger portion of the colour memory. I'm not sure why the VIC-20 was designed in this way, but the "hidden" half of the colour memory often can be useful to store extra data about the screen: hidden colours in puzzles etc. I've used it quite a lot for that purpose.

channelmaniac · Post by **channelmaniac** » Tue Nov 25, 2008 5:29 pm

It's using a single 2114 SRAM IC for color memory.

That IC is 1k x 4 bits in size. It takes 2 of them to get 1k x 8 bits - and the VIC-20 only has 1.

RJ

adric22 · Post by **adric22** » Tue Dec 02, 2008 9:44 am

channelmaniac wrote:It's using a single 2114 SRAM IC for color memory.

Out of curiosity, would there be any benefit to adding an additional one in there?

carlsson · Post by **carlsson** » Wed Dec 03, 2008 2:05 am

In an attempt to make the colour memory $9400-$97FF eight bits wide? No colour attribute is more than four bits anyway. The only benefit I can see is to get another place to store code or additional data, but it would be non-standard. Actually I think someone (Marko Mäkelä?) has written a program only using four lower bits op-codes, somehow clearing or setting the upper bits from bus data. It is rather a proof of concept, but quite interesting.