| |
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... |
| |
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? |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
> And the Colorram is also read during a c_access, isn't it?
Yes, thru the upper 4 bits (out of 12), which CANNOT access the RAM! (read Graham's post again). The whole discussion now takes another direction. How come VIC uses the lower 4 bits to read the colordata?
> Voila, we get the colordata from RAM!
No voila yet. :)
|
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Another suggestion:
If it would only be a matter of the data currently on the bus, why is the color stable for whole 3 chars? AFAIK the VIC keeps reading graphics-data within the 3 chars, and so the available data on the bus should change. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
We assumed that VIC reads from the location the CPU addressed just before the bus-takeover. So if VIC cannot set new data on the address bus in the first cycle, it can't do that in the rest 2 cycles either, thus reads the same thing 3 times. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
there might be a simple explanation how those 8 bits mysteriously get into the upper 4 bits. some time ago i had a look at the TED in the plus/4 and found that it's graphical circuitry is obviously a modified VIC-II (sprites removed, colors added). now the problem with those additional bits needed for the colors was solved by having two badlines per charline instead of one.
now how does this relate to the $D800 issue? quite simple: when experimenting with FLI on that machine there was something weird which is kinda unexpected. it seemed that instead of reading the data of the first badline directly into it's buffer and the data of the 2nd badline directly into another, there was some kind of "forwarding" mechanism which would read the data of both badlines into the same buffer, and while reading the data it would forward the contents of that input buffer into the 2nd buffer. my guess is that this is done to save transistors or maybe even that almost the same circuitry already existed inside the VIC-II.
so instead of directly writing $D800 and screen ram into their buffers directly, both will first be read into the same buffer and forwarded when the next data is read. this would explain how those values from the lower 8 bits suddenly appear in the higher 4 bits: the forwarding mechanism is disabled during those 3 fli-bug cycles. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Hoogo: remember that in those 3 cycles of the FLI-bug, the cpu is already stopped. nothing is happening on the bus anymore. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Yes, why does the VIC read the lownibble from ram for the colorram_info? Again I'd like to quote the VIC_article - and this time I'll paste the whole section, so that everyone knows where the source of my inspiration comes from;))
<quote>
"The VIC will then set BA to low immediately in the next cycle, switch to display state and start reading from the video matrix (the processor is now stopped because BA is low and it wants to read the next opcode). However, AEC still follows ø2 for three cycles before also staying at low state. This behavior (AEC not until three cycles after BA) is hardwired in the VIC and cannot be avoided.
Nevertheless, the VIC accesses the video matrix, or at least it tries, because as long as AEC is still high in the second clock phase, the address and data bus drivers D0-D7 of the VIC are in tri-state and the VIC reads the value $ff from D0-D7 instead of the data from the video matrix in the first three cycles. The data lines D8-D13 of the VIC however don't have tri-state drivers and are always set to input. But the VIC doesn't get valid Color RAM data from there either, because as AEC is high, the 6510 is still considered the bus master and unless it doesn't by chance want to read the next opcode from the Color RAM, the chip select input of the Color RAM is not active. Instead, a 4 bit analog (!) switch, U16, connects the data bits D0-D3 of the processor with the data bits D8-D13. This connection is always in place when AEC is high and should allow the processor to access the Color RAM if desired. To make a long story short: In the first three cycles after BA went low, the VIC reads $ff as character pointers and as color information the lower 4 bits of the opcode after the access to $d011. Not until then, regular video matrix data is read."
<\quote>
So this U16-switch brings the lownibble of the following byte to D8-D11 of the VIC_data_bus! But it seems to be wrong that the chip_select input of the colorram plays a central role here - this U16 _always_ makes the VIC read the lownibble of the following byte on D8-D11 - but from RAM! This shows that the VIC switches the PLA to RAM within the first halfcycle of the first "X"_cycle; at least it sounds like a good model;))
@Hoogo:the VIC has different DATA_lines for its g_ and c_accesses!As the g_acesses always take place in the first halfcycle, and the c_accesses only in the second (which are usually used by the 6510), it makes sense that only the c_accesses are disturbed - obviously in the way we discussed here! |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
It's me again...
I had another go with this stuff here; I placed my code somewhere at $1000 (and also at $9000), the area where the VIC should see the Charset_mirror. If Grahams model was right, we should get the colorram_data from the charset (as we assumed that the VIC makes the PLA switch to RAM-Charset-RAM-Charset-RAM at the wellknown mem_areas). This was not the case - the lownibble for the %11-color was read from RAM! So it seems that this lownibble is _always_ taken from RAM, and this is still to be explained!
@Graham:this "buffer-forwarding-technique" may be correct, but it also does not explain the RAM_acess! Also this "model" cannot be validated, or can it? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
another possible explanation is that the processor port is disabled during cpu halt. now that i look at this it may even make sense: devices like the REU want to access ram during cpu halt... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
just was bored, and was reading old topics. I have found the solution why vic reads from ram the d800 color at the fli bug.
"a 4 bit analog (!) switch, U16, connects the data bits D0-D3 of the processor with the data bits D8-D13. "
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Isn't this exactly what copyfault said and qouted 2005-02-15 17:56 in this forum? =D |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Yes, it's one line of the quotations I put here some time ago... but why should this U16-thing be enough to explain RAM_access??? Could you give us more details of your thoughts, Oswald?
Maybe someone already verified Grahams idea of the processor port being disabled during CPU_HALT. IF this is right, it should be possible to write to $00 and $01 during some "X"-cycles (e.g., within the three initial cycles of a BL) without affecting the processor port. Have to test this, maybe tonight... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
the second half of this topic deals with the question, that why does d800 colors come from opcode, and I think to that this is the explanation.
according to the vic article, at the exact moment cpu is considered to be the busmaster, and data bits D0-D3 of the processor with the data bits D8-D13 of vic are connected.
So the CPU reads its next opcode, the vic reads that aswell from the bus, but as d0-d3 of cpu and d8-d13 of vic are connnected, vic reads opcode instead of d800. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
just a question that fits here, if vic reads on the badline screen ram, and d800, when does it read the bitmap info ? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Since the line is BAD it reads color+screen on one phase and bitmap/char data on the other phase, simple as that. I.e. the CPU is completly blocked. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so the vic reads 1 byte and 4 bit every 2nd "2mhz" cycle. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Yes, every second cycle it does a c-access (12 bits where the top 4 comes from $d800, and 8 comes from the selected screen) and every other second cycle it does a g-access to fetch bitmap och char data from the selected bitmap/charset. |
| |
Bastet
Registered: Jul 2005
Posts: 88 |
Could anyone tell me a practical application for this? Just curious ;) |
| |
Twynn
Account closed
Registered: Nov 2005
Posts: 9 |
Quote: Could anyone tell me a practical application for this? Just curious ;)
Fullscreen FLI :)
(Trying to find out if it is in some way possible to get rid of those first 3 unusable chars in a fli picture). |
| |
HCL
Registered: Feb 2003
Posts: 728 |
..and while you're waiting on the scientists, you can just have a look at Royal Arte to see how it may look like ;). |
| |
Bastet
Registered: Jul 2005
Posts: 88 |
First three chars... havent watched it, but i think most times i have seen a picture they are filled with something and if its just three blocks of color.
You mean these flickering representations of a picture? ;)
/me wants a SuperVIC that outputs 640x480x8bit@75hz VGA in his c128d *g*
This would give you all a new toy to play with *g* |
| |
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....) |
