| |
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 ;)) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:But this value only gives colour information for the $d800-pixels, or am I wrong here?
you are correct :=)
Quote:We badly need someone with time and hw to do the necessary tests ;))
making a test program has been on my todo list for a while now... oh well :)
edit: here is the routine from blackmails editor. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: 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?
Krill: It has been done, just not by me ( http://unusedino.de/ec64/technical/c=hacking/ch21.html ).
It was only the base of my idea on how to do it with a REU. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: 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 ;))
I understand like this:
Since the bus is 12 bits, the gray cant be manipulated (its the upper 4 bits out of theese 12) but the lower value kan be manipulated either by writing stuff to the bus or by using different op-codes (thus placing them on the bus for the vic to see). So what is accomplished in the scpu-solution is that you get gray, d021 and two multicolors to choose from on each of the three bytes, d021 and 2 multicolors for all three bytes. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Quoting Oswaldtoo bad, scpu doom would have been better without fli bug :)
Scpu doom has the fli bug because of a limitation in VICE. See bug 545. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting TrashKrill: It has been done, just not by me ( http://unusedino.de/ec64/technical/c=hacking/ch21.html ).
It was only the base of my idea on how to do it with a REU. Okay... but how about Chameleon? It is both actually available and surpasses SCPU in many regards. IF it chickens out as early as REU, i'm pretty sure its makers would be willing to provide a firmware (= FPGA image) fix so it could make fullscreen FLI just as well as SCPU. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Quoting TrashI understand like this:
Since the bus is 12 bits, the gray cant be manipulated (its the upper 4 bits out of theese 12) but the lower value kan be manipulated either by writing stuff to the bus or by using different op-codes (thus placing them on the bus for the vic to see). So what is accomplished in the scpu-solution is that you get gray, d021 and two multicolors to choose from on each of the three bytes, d021 and 2 multicolors for all three bytes.
With a SCPU you get d021 and 2 multicolors. The color-RAM color will be the same as the low nibble of the byte you force onto the bus.
See this thread.
Quote:Either way, AEC is always high during these first three cycles (the CPU half thereof) and so the 4066 analogue switch must always be enabled, making D11 - D8 the same as D3 - D0. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Quoting KrillQuoting TrashKrill: It has been done, just not by me ( http://unusedino.de/ec64/technical/c=hacking/ch21.html ).
It was only the base of my idea on how to do it with a REU. Okay... but how about Chameleon? It is both actually available and surpasses SCPU in many regards. IF it chickens out as early as REU, i'm pretty sure its makers would be willing to provide a firmware (= FPGA image) fix so it could make fullscreen FLI just as well as SCPU.
Since the Chameleon apparently makes use of an undocumented PLA mode in order to have the VIC fetch all graphics data from external memory, to avoid ever having to write to the C64 memory, it should be much easier to fix for the Chameleon since it just need to put whatever it likes on the bus for the VIC to see. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes, it would be relatively easy to do on chameleon - on the other hand that is completely out of the focus of what we want it to be, and thus wont be done (at least not until we fixed every other bug). |
