----- Original Message -----
From: "MagerValp" <MagerValp@cling.gu.se>
TE> I have finally cracked that tough VIC-II nut wide open, coaxing it
TE> in displaying a *full-screen* FLI mode, including the first three
TE> columns.
MV>Great! Glad to see it worked out. I guess the SuperCPU buffer doesn't
MV>block for those three cycles then? Can't wait to hear more about the
MV>discovery :) Unfortunately I'm away from my CBM setup for a few more
MV>days, but if you send me the source I should be able to PAL fix it.
MV>Actually, are you sure that it needs it? If you're using one irq per
MV>line it should work on both PAL and NTSC -- another first :)
Hello, MagerValp-
I can send the source code file to you for PAL fixing. It's in Turbo Macro
Pro format. I can create an ASCII file if you wish.
I do have some questions, though. The high resolution FLI mode works fine
full-screen. It's the multicolor mode that's a problem. It still isn't
perfected. So, I'm asking a general question here to CBM Hackers emailing
list. Maybe some VIC-II guru knows.
I can force the VIC-II to fetch video matrix data to fill the %01 and %10
bitpairs in the first three columns of the FLI screen under the SuperCPU.
But, what about the %11 bitpair? How do I force the VIC-II to fetch colorram
data to fill this bitpair? From my analysis, the video matrix data that is
forced onto the first three columns of the FLI screen under the SuperCPU
will also fill in the %11 bitpair and that is not the intention.
Does the VIC-II chip only fetch colorram data every eight scanlines, i.e.,
buffering it like it does with sprite data?
In a normal VIC-II DMA, does the VIC-II chip fetch videomatrix data first,
then colorram data second, and alternate between the two in filling out the
graphics display for the entire scanline? Or vice versa? Or they are not
alternated, but fetched in one continuous fashion, i.e., videomatrix fetches
follow, and then colorram fetches?
Currently, the full-screen high resolution FLI screen is a reality under the
SuperCPU because videomatrix data can be fetched in the first three columns
by the VIC-II chip in filling out the bitmap. It is the multicolor mode that
worries me, the %11 bitpair as I'm trying to look for answers in how to
force the VIC-II chip to fetch colorram data and fill in those bitpairs in
the first three columns of the bitmap in FLI mode.
At any rate, if I am not able to solve the colorram riddle of the fullscreen
multicolor FLI mode of the SuperCPU, it is still significant that a full
screen multicolor FLI mode is now a reality. A graphician or a conversion
utility like GoDot just needs to be aware of the %11 colorram limitation in
the first three columns of the bitmap, a limitation that can be acceptable.
I will post the full details of my full-screen FLI work under the SuperCPU
to C=Hacking, unless that publication can't publish it soon enough. If that
publication isn't possible, I will then publish such work to the SuperCPU
home maintained by Milo Mundt.
One benefit of the full-screen multicolor FLI mode is that $d020 can now be
manipulated at every scanline for a greater degree of color freedom and
selection. I know that $d020 manipulation has been made available for
regular multicolor FLI modes, but the results of the $d020 changing in every
scanline was visible in the first three columns unless they were somehow
covered up. Now, no coverup needs to be made. :)
Already, I can hear graphicians groaning, 'What?!? I have to paint the first
three columns! Aargh!" Maybe not. :) GoDot also would need a FLI saver
module which will allow bitmaps that maximizes the color freedom and
resolution that a full-screen FLI mode now offers along with the $d020
feature. Not to mention a new IFLI saver module, as well. :) (Does $d020
work well for IFLI's?)
Enjoy.
-Todd Elliott
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.