| |
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....
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Apparently the VIC still accesses the memory (i.e. it doesn't read what has been left on the data bus), but it can't do proper addressing. In fact, it's the address bus that gets locked. Why doesn't the same happen with the screen memory? Instead it reads $ff... It has something to do with the processor's lines I guess, since that happens during phi2. |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
-VICE shows the same behaviour as the original C64? |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Tell you what, kidnap Andreas and make him reveal everything.
Why's everyone looking at me like that? I'm just making a suggestion... For the sake of science. :)
Whether the VIC will read from RAM or from IO space, it depends on the DR ($01) register. I don't know how is this connected to the PLA, but maybe that's the reason the VIC reads the RAM (i.e. the PLA doesn't get the correct value). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Cybernator:
no, the processor port ($00/$01) has nothing to do with the VIC. the VIC will always read RAM except for $1000-$1FFF and $9000-$9FFF.
the reading of $FF reflects the reading of tristate. those bits are not actually read from the bus.
@copyfault:
why is it so puzzling? the first read cycle stops the cpu, but during that cycle the cpu still provides an adress while the VIC already told the PLA to enable VIC memory mapping. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
You guys think too much ;). Fullscreen (i)FLI == Royal Arte :D.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"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!"
colorram_data with own bus = $d800 for me, and that is read even under that strange 3 cycles. you mix up things. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
I mixed things up with $01. HCL's right afterall. :)
Ok, VIC reads the RAM, but the colorram is in the IO area. When it reads the color, it always accesses the colorram, not the RAM beneath. The puzzling thing is why doesn't the same happen during these 3 cycles.
This has to be tested in VICE. Copyfault, please send me the proggy when you can.
@Oswald: Nope, it's the bitmap that is read during those 3 cycles.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
the question is rather why it reads opcodes for foreground color at all? it is wellknown and very proveable that the VIC indeed does that, but if you look at it's 12 bit bus this should be impossible since the $D800 ram never gets accessed through the lower 8 bits which are connected to the normal ram. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: Hoogo wrote:
> Krill would say "...you guys think to much..."
I thought that was HCL. :)
No, i got the (C) (TM) on that sentence.
Well, i remember saying that sentence (i was referring to loader timing issues or so), but that does not prevent any co-incidental events like someone else (HCL) saying that same sentence, too ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
@Hoogo: yes, my code also runs under VICE; I already told you - did you forget;)?
@Graham: your explanation sounds good; the first read cycle stops the cpu, but during that cycle the adress to read the following op is already selected. Now the VIC told the PLA to switch to RAM on the half_cycle directly before. Voila, we get the colordata from RAM!
I think I am too much relying on the VIC_article; it says that the VIC would indeed try to get colorram_data over his colorram_bus! This simply seems to be wrong...
@Oswald:good point! What does the VIC actually access within those "X"_cycles? the normal g_accesses take place (it reads the bitmap), but all c_accesses seem to get lost! And the Colorram is also read during a c_access, isn't it? |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
