| |
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....
|
| |
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* |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
