Date   : Tue, 03 Mar 2009 01:08:14 +0100
From   : kortink@... (John Kortink)
Subject: Fwd: New Screen Modes with ARM7 Co-Processor?

On Mon, 2 Mar 2009 20:42:05 +0000 (GMT), tommowalker@...
wrote:

>
>> But that hardly constitutes 'hardware support'. And it is far more 
>> complex and far more sensitive to timing than what I suggested. You 
>> only need to switch banks every frame (in the vblank period) if you 
>> leave the CRTC in 'interlace sync' mode.
>
>But this method gives a more logical memory map.

They're both pretty nuts. Which one is more 'logical'
depends on what you want to draw.

>And gives no chance of getting the fields the wrong way round -
>requiring user intervention is bad!

That I agree with. Assuming the frame type really is
impossible to determine or force by software.

>And it's not that sensitive to timing

Nonsense. It's very sensitive. It's not like you have
several line times of leeway. You have none. It must
be a seamless transition, pretty much exactly within
the horizontal blanking period.

Which is clearly demonstrated by your little program.
There's no way to remove the 'shear' around the bank
transition by whatever finetuning.

And your disabling of all other interrupts is pretty
misleading. If they are properly relayed to the old
vector, the lines around the transition point start
juddering quite heavily, even though the vsync and
timer interrupts are the first serviced.

Unusable except in specific situations (e.g. games)
where you can mask these effects.

My solution has none of those problems.

>- unless you're insistant on not running your beeb on a 50hz
>312-line display.
>
>> No, just insistent that you can't change the CRTC start address mid-
>> frame (as in : the appropriate registers in the CRTC).
>
>You need to read up on the vertical splitting or 'rupture' trick, which
lets you do exactly this.

Either the CRTC picks up changes to its start address
registers mid-frame, or it doesn't. No 'trick' should
be needed to change that.

My own experiments reveal no pick up whatsoever. Changes
only become relevant at the start of the next frame. As
predicted.

>> Using the wraparound instead is a neat trick, but it doesn't change the 
>> CRTC's start address.
>
>That's not needed for what we're talking about!

So don't say it's 'entirely possible' a few messages
back and only now explain how you intended to do it
in quite a different way. Saves us all time.


John Kortink

-- 

Email    : kortink@...         
Homepage : http://www.inter.nl.net/users/J.Kortink

GoMMC, the ultimate BBC B/Master/Electron storage system :
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc