| |
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? |
|
... 8 posts hidden. Click here to view all posts....
|
| |
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). |
| Previous - 1 | 2 - Next |
