Posted By
gerliczer
on 2012-08-08
12:46:38
|  Re: Combing Text and freely placeable bitmaps on screen
Hi George,
I took a short try with Csabo's excellent programmers' graphics editor Csabo's Gfx Edit to see what causes your problem. If you save your picture as a program file, it will contain a full graphic screen, which is a waste of space in your case. The difference in colours comes from the fact that the colour memory loaded with the file is not at the place where it is used in COMMODORE BASIC. You should copy the contents of memory between $1800 and $1F40 to $0800..$0F40 to get your intended colours. Not too many years ago there was a thread in the forum about the possibilities of fast memory copying in BASIC. Look it up and use what we came up with back then.
Now about the possibilities of more efficient storage. As Csabo already said, you should try to save the pictures as source code. Draw or convert your picture, save as source, copy the text into Plus4IDE, write before the text in the first line ORG $1800-2 and DW $1800 in the next (the previously inserted text must start in the third line now - but this is obvious), save it, and finally build the "program". Now you have a file that contains only the graphic and colour data that you need. When loading the file it will be residing in the memory from $1800. You should be careful not to make too large pictures, because the graphic screen already starts at $2000. The file will contain first the graphic data, next the luminance data, and finally the colour data. Observe, that the breakdown of the data gives you hint where the contiguous graphic data blocks start and end.
Then comes the hardest part, putting the picture into its place. This is the part where we welcome you to the wonderfully fucked up world of the Commodore graphic screen. Let's start with the memory organization of the actual graphic screen. The sequential bytes of the graphic screen memory are mapped to the actual displayed screen not in a horizontal sequence of one screen line followed by the next one. They are following the display order of the character data, therefore the first byte is displayed at the top left corner. It represents the first 4 or 8 pixels counting from left of the top screen line. The next byte is displayed below the previous, therefore it represents the first 4 or 8 pixels (0..3 or 0..7) counting from left of the second screen line, the one below the top. This goes 8 times, so the 8th byte is the left 4 or 8 pixel of the 8th screen line. The 9th byte then is right beside the 1st one of the screen memory. It represents the second 4 or 8 pixels (4..7 or 8..15) of the first line, and this goes on 40 times. The 321st byte will represent the leftmost 4 or 8 pixels of the 9th line. And this carries on along the whole screen. Then come the colour and luminance matrices. The luminance starts at $0800 and the colour at $0C00, but maybe I mixed them up. These are following the usual linear layout of the character screen and are equal with those in size, therefore you colours will be the same in every 8*8 or 4*8 pixel area.
Now all you have to do is calculating the addresses of the screen memory where the contiguous blocks of graphic data must be copied, and what are the corresponding addresses in the colour and luminance matrices. I know that all this is very frightening at first, but give it a try.
|
