| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Colorram access within FLI_Bug_area
Quite some time ago it was Hoogo who came up with the following idea: why not try to activate the colorram access in the FLI_bug_area?
How does one have such an idea? Well, the VIC_article tells us that the colordata is not read because the chip_select input of the colorram is not active - unless the processor doesn't _by chance_ want to read the next opcode from the colorram!
Hm, this was interesting enough to give it a try! So I made a routine that causes a badline on the correct cycles, but the opcode that does this write_access to $D011 is placed at $D7FE - yes, in an area normally occupied by SID_mirrors (this works with a little tweaking, at least on the machines I tested)! So the 6510 does read the next opcode from $D800... on purpose ;))
Unfortunatly I got a result that I do not really understand! The colorram access was not activated by this hack, but the VIC rather read the data for the color from RAM! This means in my code the lownibble of $D800 of the C64's RAM is responsible for the color, and the VIC always reads it from this position. I made further examinations and found out that WHENEVER your Opcode that causes the BL lies in the IO-area (e.g. by misusing the Sprite X/Y-Pos_regs for your code;)), the colordata is always read from the adress that follows after the write_opcode - but from the RAM!
Can anyone here explain this... "feature"? |
|
... 40 posts hidden. Click here to view all posts....
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
You can use the first three chars quite easily. The $D800 (bits 11) color is copied from the opcode which directly follows the $D011 write access. Colors 01 and 10 stay light grey and 00 is $D021 background color. Together with some sprites and some rasterbars you can do "almost FLI" in that area. I remember some old FLI editor which did that. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Quote: You can use the first three chars quite easily. The $D800 (bits 11) color is copied from the opcode which directly follows the $D011 write access. Colors 01 and 10 stay light grey and 00 is $D021 background color. Together with some sprites and some rasterbars you can do "almost FLI" in that area. I remember some old FLI editor which did that.
Well, after reading Copyfault's original post, you can easily see that he aims for something different (same goes for the HCL's "Royal Arte" comment). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
So what? You can use any $D800 color already by choosing the right opcode after the $D011 write access, and you can choose a $D800 color every rasterline. Now add some sprites and some rasterbars - voila, looks like FLI. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
You know, that if he succeeds, we'll have not one color for the 3 chars, but 3 different ones. But in any case, we learnt something about our commie. And that's the main thing behind it... |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: You know, that if he succeeds, we'll have not one color for the 3 chars, but 3 different ones. But in any case, we learnt something about our commie. And that's the main thing behind it...
I think Graham got it, but just like HCL he means that _enough_ sprites upon the FLI_bug area help out to make it look like there are independant colors for every char...
remember our brainstorming about how one can have _all_ 16 colors in this FLI_bug area (statistical crap)... better won't say too much here *smile* |
| |
Dane
Registered: May 2002
Posts: 423 |
Cover the FLI-bug with 4 sprites. Set your D800-colours of choice on every line. Be creative when setting the background colour of the picture.
This gives you...
6 spritecolors
1 D800
1 D021
1 Color $0f
Now, if you can't make 3 chars look like FLI something's wrong... |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
An easy and very practical way to get the fli-look is to turn down the resolution of your PC to 640*480*16, looks like geos in FLI. But it's more about explaining the bug-effect itself. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
A thought which crossed my mind while reading Mapping the 128. If it was possible to force VIC to read colors from RAM (all the time), we could make color-memory double-buffering. Who'd need a 128 then!? :P |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@ninja: Nopes there won't be 3 different char colors since the VIC is not putting an address on the address lines these cycles. But that's already known since we have this "next opcode access" during all 3 of these cycles. |
| |
Bastet
Registered: Jul 2005
Posts: 88 |
Hmm, how fast does the VIC react on page changes?
Dont know if it would be practicable but why dont use more than one page for more colors?
(I hope my english isnt that bad that nobody understands my idea....) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
