[hatari-devel] Videl changes

[Laurent Sallafranque]

Hi,

I'm not that sure to agree with all of this :

Videl part :

The Falcon is not an STe or ST : It has no Shifter but a Videl, and not 
a DMA with LM192 but a crossbar.

There's no need to try to implement ST's Shifter specific code.
In "STe compatibility mode", the Falcon Behave like a STe, but it's only 
""""emulation"""".

In Ste graphical mode, Videl is given some frequencies, width and height 
of pixels to generate a 320x200 screen.
If you want to remove the borders in this mode, you have to play with 
Videl registers (Border begin, border end, ...)

There's not special "tricks" used in STe to remove the borders.
I'm nearly sure that none of the ST overscan demos would run natively on 
the Falcon.

Another proves : nearly all Falcon specific demos and programs are 
running well by only copying the full screen (as done actually in videl.c).

Falcon plasmas are all running well (from what I know), which mean they 
don't use video tricks but colors "rotations" or something else.

Only a few programs are playing with the "border color (color 0)" like 
Reeking Rubber, or with the video pointer (like pinball dream).

The best doc to understand the Videl is to read Mikro's videl documentation.
Everything is explained.

The main problem is the VBL/HBL timers that are dependant of all the 
Videl's hardware registers (horizontal and vertical registers) + BPP + 
frequency + monitor + ST palette or Falcon Palette.

If we use the "Shifter" HBL, as it is done actually, we've got wrong 
timers in the Falcon emulation.
The same for the VBL.

(Another program that have a strange display I can't explain for now is 
UFO_WAR.
It's using all the Videl registers to use Overscan mode.

Last point : I haven't found a program that changes the palette except 
in the left border. If you know one...


So, what I want to do is :

- computing the correct border begin, border end and display them
- compute HBL and VBL accordingly to Videl registers
- take into account the video position registers (like in pinball dream).
- take into account the half frame (videl works with half frame, not 
full frame).

I think I've got at least one example of program for each of these problems.
But if you encounter any graphical problem  with a falcon programm, 
please tell me, I'll have a look and see if it's because of a known 
problem or a new one.



Falcon "ST compatible mode".

This mode is not magic ;)
It only involve running the 68030 at 8 Mhz without cache, running the 
blitter at 8 Mhz and playing the sound in crossbar Ste compatibility mode.

Everything is in register $ffff8007.b

(It's a TODO in stMemory.c), but it should be somewhere else, as one can 
change from 16 to 8 Mhz when he wants in a program.

This doesn't mean shifter or anything else.


Best regards

Laurent





Le 04/02/2011 23:31, Nicolas Pomarède a écrit :
> Le 04/02/2011 23:02, Eero Tamminen a écrit :
>
>>>> And what about the existing shifter stuff that Nicolas has in video.c,
>>>> doesn't Videl have same tricks as ST shifter?  I mean, what happens if
>>>> one runs ST program using these tricks on Falcon?
>>>
>>> I think all the shifter stuff Nicolas included in Video.c musn't be
>>> keeped for Falcon. Here, we emulate a Videl componant, not a Shifter 
>>> one.
>>>
>>> Shifter and Videl are not working the same way (from what I understand
>>> of them).
>>
>> Ok.
>>
>> One tricky thing will be the spec512 HBL palette switching emulation for
>> Falcon ST/e screen modes, for that I think it's simpler just to use 
>> the ST
>> emulation stuff.
>>
>> I don't think palette switching is that common on Falcon games&  demos
>> though, only program I'm sure to use it is Nibe2.  Pinball Dreams&  
>> Pingo98
>> &  Chosneck Supplement could be doing that too.  They're mentioned in
>> the compatibility list.
>
> Hello,
>
> honestly I don't really know anything about videl ; but regarding 
> shifter<->videl common points, I think only a very low percentage of 
> demos/programs will need a working shifter mode under falcon, so 
> better leave it aside for now (I'm not even sure the falcon can do 
> border removal in shifter mode as does the ST)
>
> 68030 has a cache, which means the same program will not always take 
> the same time, so doing plasma and effect synchronized with the video 
> beam will certainly be very unstable on a real falcon (it's possible 
> to disable the cache).
>
> I think that having the possibility to change the palette once per 
> line should be enough for now (same mode than the less precise palette 
> mode for STF when spec512 is off).
>
> In video.c, I tried to define a shifter structure that defines a whole 
> screen and all the possible raster line ; I think we should have some 
> kind of videl_screen structure as well to define the screen in a 
> flexible way (to easily add one palette to each line for example)
>
> But most of all, we should also collect as many representative demos 
> before starting to code, in order to get a good view of what the 
> falcon does and adapt Hatari's code to this (for example, focusing on 
> cycle precise palette change like in STF spec512 would be pointless).
> From what I understand, none of us ever coded on the falcon's videl, 
> so it's hard to get a vision of how things should be modeled.
>
> Same as for 68030 and the new winuae cpu : let's just focus on the 
> falcon and its specialties, let's forget (for now) all compatibility 
> modes that the falcon can have to run old 68000 STF/STE programs (8 
> Mhz mode and so on).
>
> If someone wants to run a STF/STE program, then the recommended way is 
> to use Hatari in STF/STE mode, not in falcon mode by telling the 
> falcon to behave like a STF/STE.
>
> We want to run Falcon's specific code for now, IMO thinking about 
> compatibilty mode will just give us an average falcon. Once falcon 
> works "perfect" for 68030+videl+dsp, we can think about merging old 
> and new cpu core, as well as merging shifter in the falcon.
>
>
> Nicolas
>
>