Reading color memory
Moderator: Moderators
Reading color memory
Why do I get random numbers when trying to read back color memory?
You do? Maybe because it's just nibbles, 4 bit memory.
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
Ah.. I think that is the answer. I tried reading it while AND'ing it with $0F and it works reliably.Boray wrote:You do? Maybe because it's just nibbles, 4 bit memory.
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.
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?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.
- Mike
- Herr VC
- Posts: 4890
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
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).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.
The colour-memory for text display on the C64 is also only 4 bits wide.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?
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
.. 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.
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.
Anders Carlsson
-
- Vic 20 Hobbyist
- Posts: 105
- Joined: Tue Jun 17, 2008 8:21 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
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
Call me a cheap bastard... I learned to fix things to save money... even surface mount soldering...
Visit my website: http://www.arcadecomponents.com
Visit my website: http://www.arcadecomponents.com
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.
Anders Carlsson