| |
Trash
Registered: Jan 2002
Posts: 122 |
FLI Gray area
Hello, I've got this idea and have no real machine to test it on.
I recently read up on how FLI actually works and found out how to manipulate the gray area of a FLI-picture using a SCPU. In principle the solution is that if you use the speed of the SCPU and write to an IO-registry once for each cycle of the three cycles that value would be seen as the colors parsed as multicolors for the left three characters.
Is this only possible since the SCPU runs async with the VIC-chip or is it possible to the same thing using a REU?
Using a REU would be something like this:
Set up transfer that is 4 bytes long, burst it into $d011, $d012, $d013 and $d014 (4 writes in 8 cycles) at the right moment. Would that result in d012-d014 would be written during the first three cycles (in the gray area) or would the behaviour be like d011 triggers badlinecondition, the vic takes over for 40 cycles and then we get our dma-transfer to d012-d014 at the right edge of the screen instead? |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
AFAIK the grey comes from unconnected bus, thus not possible to manipulate. |
| |
lft
Registered: Jul 2007
Posts: 369 |
The REU stalls as soon as VIC requests the bus, so I'm afraid it won't work. In principle, the REU would be allowed to perform three write cycles, but it doesn't. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: AFAIK the grey comes from unconnected bus, thus not possible to manipulate.
True, but the SCPU solution is to force values on the BUS by writing to the IO-registry that the VIC-chip sees even though the bus is unconnected.
More in detail the SCPU-code looks like this:
...
; Wait until cycle 14 on the row
lda d011table,x
sta $d011
; Takes one cycle (8 pixels) to complete
lda #colorpair
sta $d022 ;Force colorpair on bus
; Takes one cycle (8 pixels) to complete
lda #colorpair
sta $d022 ;Force colorpair on bus
; Takes one cycle (8 pixels) to complete
lda #colorpair
sta $d022 ;Force colorpair on bus
inx
...
My idea is that a REU should be able to accomplish the same thing by doing:
; Setup REU to transfer 4 bytes to $d011, $d012, $d013 and $d014
'''
ldx #$08
stx $d018
sta $df01 ; Start DMA-transfer with correct yscroll to $d011 (triggering badline at the correct place) and force colorvalues into the bus by writing to D012-d014, the DMA takes one cycle per write and should be equal to what the SCPU does |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: The REU stalls as soon as VIC requests the bus, so I'm afraid it won't work. In principle, the REU would be allowed to perform three write cycles, but it doesn't.
Ok, so in theory my idea would have worked but in practice there is a no go since VIC hi-jacks the bus entirely?
To bad, towards new ideas then... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
too bad, scpu doom would have been better without fli bug :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Maybe i'm wrong, but i think cpu power/speed has noting to do with FLI bug.
Simply VIC try to display, for three cycles, some gfx data that it can't have, because it can't access the bus because is in idle state.
So VIC displays value readed from $3FFF (or other addresses accordingly with mem config) using last value 'on the bus' as color data.
Unless is possible to change $3FFF value for each of these 3 idle cycles, but i guess there are some colors problems then... |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Maybe i'm wrong, but i think cpu power/speed has noting to do with FLI bug.
Simply VIC try to display, for three cycles, some gfx data that it can't have, because it can't access the bus because is in idle state.
So VIC displays value readed from $3FFF (or other addresses accordingly with mem config) using last value 'on the bus' as color data.
Unless is possible to change $3FFF value for each of these 3 idle cycles, but i guess there are some colors problems then...
It's not from $3fff as it doesn't have the bus. I assume it's from the internal VIC-II bus which is $ff in idle.
If that is the case, it should be possible to manipulate the value assuming a read or write to the VIC-II can be achieved.
This is analogous to the sprite idle fetch discussed here: Sprite data fetch in sideborder |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Trash: Sorry, i can't quite make out whether you actually succeeded in overcoming the FLI bug using an SCPU. Did you, or couldn't you test this on real hardware either? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:If that is the case, it should be possible to manipulate the value assuming a read or write to the VIC-II can be achieved.
its the value that was last fetched and remains on the bus -> blackmail FLI editor |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting GroepazQuote:If that is the case, it should be possible to manipulate the value assuming a read or write to the VIC-II can be achieved.
its the value that was last fetched and remains on the bus -> blackmail FLI editor
But this value only gives colour information for the $d800-pixels, or am I wrong here?
I like the idea of forcing values on the VIC-II-Bus by means of a REU or SCPU. It breaks down to the question wether the corresponding write accesses are admitted also during blocked "="-cycles, but I guess the CPU is blocked as soon as the write cycle of the $D011-access occurs and it stays so until the end of the badline.
We badly need someone with time and hw to do the necessary tests ;)) |
... 8 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
