| |
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"? |
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
interesting... i've never heard of these features/bugs b4. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
that is because the VIC does not read any data from memory at that cycle, but it reads the data which has been on the bus the cycle before which always is the next opcode fetched. sorry to break your dreams, but it is indeed impossible to read $D800. the only thing you can do is use different opcodes and get different colors that way. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Graham wrote:
> but it is indeed impossible to read $D800
Even the magic word fails after all these years. :)
@Copyfault: Ever considered writing an emulator? God knows what features you'll come up with if you start the project. :)
|
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
I'm not too involved into copyfaults experiments, but I am a welcome victim to his bla $d011-tortures ;-)
If there are no stupid program-bugs in his routines, it seems that the "...color from last fetched opcode..." is not correct...
After the sid-thing he did a more simple test within the sprite-positions of the vic, that means he used the vic-registers like RAM and placed part of his FLI-Routine there. The routine worked, that means the processor fetched his opcodes from the VIC. But the color of the bug was taken from RAM beneath the VIC. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
i dont believe in this mysterious ram access, because that would mean that VIC and 6510 use the same bus at the same time.
but i don't see the problem anyway: just generate the FLI-code according to the color required in the FLI-bug area that line and you're done.
http://www.oxyron.de/html/opcodes02.html
you find a fitting opcode for all 16 colors :) |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Well, you can still hope for a bug in copyfaults code until you try it yourself :-)
I did such a more colorful FLI about 10 years ago, so it's not a practical problem. Krill would say "...you guys think to much..." |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@copyfault: my guess is that the value is fetched with PLA mapping for VIC:
$0000-$0FFF = RAM
$1000-$1FFF = CharROM
$2000-$8FFF = RAM
$9000-$9FFF = CharROM
$A000-$FFFF = RAM |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Hoogo wrote:
> Krill would say "...you guys think to much..."
I thought that was HCL. :) |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Maybe it was HCL... :-) At least I remembered that there was somebody who said something. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Graham, you are the master of not-believing-things-that-are-not-understood-yet;))
My "dream" was not to write a FLI_routine with different colorram_values for every line, but to activate the_whole area_, meaning to have a colorram_access every 8 pixels. This has been proven impossible now - unfortunatly!
The only confusing thing is that the colornibble is taken from RAM(I can send sources,or feel free to test on your own!). The VIC_article indeed tells us that within the (BA=low & AEC=high)-phase, the 6510 is still considered the bus master! Only due to this line in the article I started the tests!
When I showed my results to Hoogo, his next guess was that after writing to $D011, the VIC would disturb the bus in a way so that also the processor reads from RAM, even if it should continue within the IO_area! This guess was very quickly proven wrong - so it must be due to the VIC's inner workings!
But what does the VIC prevent from reading the colorram_data? It has an own bus for accessing the colorram, and with this hack I made, even the chip select input of the colorram is active! So I don't see why it does not work... |
... 40 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
