----- 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.