Posted By
IstvanV
on 2008-02-08
08:12:40
|  Re: plus4emu 1.2.5.1
Hi, sorry for the lack of any greetings, I did not intend to offend anyone, I am just not used to including them  As far as the improved FLI routines are concerned, I will show my planned next version first (which has the same color resolution as your one), and then the theoretical full resolution non-overscan version. I did not test these yet, so there may be errors in the idea, but I think it should work. The following are just timing diagrams, and not actual assembler code, but the implementation should be obvious:
FF14 FF07 FF15
| | |
*****---************XXXXX
FF07/FF15
|
FF16 | FF1D FF16
| | | |
*****+--*****************
Each column is a CPU cycle, those marked with '*' are always available, '-' are cycles before DMA (when the BA line is pulled low by the TED) not used by the CPU, and '+' are the same but used by the CPU for writing. 'X' cycles are reserved (normally dummy) for the purpose of JMP instructions (when splitting the unrolled display code) and changing FF12 when needed (with the STA nnnn, X instruction which takes 5 cycles to execute). The FF1D value is a fixed 0A and is preloaded to register X. The FF12 value is also preloaded, to register A, before the beginning of the long unrolled code. The other writes (FF14, FF07, FF15, and FF16) just use LDY #nn, STY nnnn pairs. Before the last FF1D write, CA is loaded to the X register. The FF14 lines are the odd ones (with (FF06) = 3B), and the FF1D lines are even, taking advantage of the fact that most of the effects of FF1D writing only occur in the next line, since the register is internally latched by the TED. Using FF1D for FLI also implies an easier overscan effect.
Now the full resolution routine:
FF14
FF16 | FF07 FF15
| | | |
*****++-*****************
FF1D
|
FF16| FF07 FF15
| | | |
*****---*****************
Here the important change is the way in which FF14 is changed: the use of an INC instruction makes it possible to avoid 2 cycles for register loading, and the two extra cycles of the INC instruction are free, since they take place when BA is low. Incrementing FF14 advances to the next bank of video memory, since the lowest three bits are always forced to 1 by the TED. One of four FF14 writes is a simple 4-cycle STA instruction that writes a preloaded register value (i.e. the first bank of attributes).
There are some obvious problems that interfere with the implementation of overscan: first, the attribute banks must be placed sequentially in memory to make the INC $FF14 trick work. There is also no time left for inserting any JMP or STA $FF12 instructions, and all registers are already used. Additionally, there may be some minor issues with cleanly ending the display area.
I have an updated conversion that tries to fix the clipping/hue distortion problem, but still uses the old video mode: http://www.sharemation.com/IstvanV/tarnsman_m_2.prg. I have just started to implement the new code which uses the first described method, so I obviously do not have any example of that.
|
