| Posted By
Luca
on 2011-07-04
05:59:24
 |  FLD and $FFFF
I coded a simple FLD routine working in bitmap, in order to move a whole bitmap from nowhere into the screen in a very cheap way. The bitmap enters from the bottom, bounces a bit and stop at its place.
While the process is running (hence we have the entering bitmap in the lower part of the screen), the higher slice of the screen is clearly affected by $FFFF byte's value. Of course, if, e.g., a music is playing by IRQ, dirt occurs in that area because the $FFFF value is displayed as graphics.
How can I mask/force another value/manage this by better solution than stopping the IRQs? Is it similar to $3FFF gfx garbage on VIC-II?
|
|
Posted By
IstvanV
on 2011-07-04
06:41:06
| Re: FLD and $FFFF
Some random ideas:
- use a JMP instruction on the zero page to implement the IRQ routine, this way the $FFFF value can be zero (at the expense of 3 bytes of zero page and 3 cycles in the IRQ routine)
- make the garbage invisible by setting a special graphics mode or palette while the $FFFF would be displayed; if you want to use black as the filler color, then setting both bits 6 and 5 of $FF06 during the FLD will switch to the "invalid", all-black video mode, and once the FLD effect is to be stopped, just write the normal $FF06 value
|
|
Posted By
IstvanV
on 2011-07-04
06:53:23
| Re: FLD and $FFFF
When using the second method, you need to set the "correct" $FF06 video mode with a separate write after the FLD is completed, though, and not with the last $FF06 write of the FLD that would start the first DMA, because for that single line the garbage would still be visible. So, unless ROM paging or a lot of zeropage space is needed, the first method is probably still more efficient.
|
|
Posted By
IstvanV
on 2011-07-04
07:02:46
| Re: FLD and $FFFF
Another trick to scroll the entire screen in 24-row mode: use $FF1D writes to delay the start of the screen by any number of whole character rows, and combine this with simple $FF06 vertical scrolling to get the lowest 3 bits of the screen position.
|
|
Posted By
Luca
on 2011-07-04
08:22:01
| Re: FLD and $FFFF
Heh, probably I should use a weird version of your first hint: I'll keep the 2x music with a couple of simple $FF1D checks, and when the FLD ends, the IRQs will be performed instead of those simple checks (in order to keep the 2x perfectly equidistant by 312/2 lines).
Of course i've just tried to force $FF06 with the blank screen's bit 4 turned off, but incredible to say it does still show the $FFFF value. I used values like #$2B.
And then, the miracle: I used ORA #$78 for $FF06 FLD (even though it work also with #$68 of course) and a simple AND #$BF in order to reset the bitmap at the end of the FLD itself. Yes, #$78. screen on!
Dunno if YAPE is cheating me or not, I wanna test it on Istvan's emulator too and on the real iron once at home, but the result is perfect! ECM is the answer, but I dunno why. Moreover, the upper screen is black, even if I fill the $FF14-corresponding color infos, even if I change $FF15/16/17/18/19 toward other different colors! Maybe I cutoff badlines by FLD keeping the first charline's color for all the upper area?
Waiting for a verify of all this, here come some questions:
- why $FFFF value is displayed as gfx during a bitmap FLD?
- why ECM+blank mask it and not blankscreen only?
- where has that black color been assigned? (Sort of) DMA delay?
|
|
Posted By
IstvanV
on 2011-07-04
08:44:47
| Re: FLD and $FFFF
The $FFFF value is read and displayed as bitmap data during FLD because the TED does not enable its address bus output for bitmap reading outside the "active" screen area. If I recall correctly, this is enabled with the first "second" DMA (i.e. reading of character codes, or color bytes in bitmap modes), and disabled at line 204. There is also a horizontal condition for enabling the address output that is active for 40 characters.
The enable/blank screen bit ($FF06 & $10) has an effect only at the beginning of the screen (lines 0, and 4 or 8), you cannot continuously toggle the enabled/blank state mid-screen with it.
Setting either ECM+bitmap, or ECM+MCM mode will result in a black screen. The black color is constant, it does not seem to depend on any other data that is read from memory. It is a sort of "hardware bug" in the TED. I think the VIC-II has this same effect, too.
|
|
Posted By
IstvanV
on 2011-07-04
08:59:09
| Re: FLD and $FFFF
The "invalid" bitmap reads from $FFFF have an additional interesting feature: the ROM/RAM memory paging is not determined by $FF12 like it normally is, but rather uses the $FF3E/$FF3F paging like the CPU and DMA/bad lines.
|
|
Posted By
Luca
on 2011-07-04
10:04:30
| Re: FLD and $FFFF
True! I played with ROM/RAM a bit and it changed! I love all this crap! 
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
