Re: [Rpcemu] MDF query

In message <55f842f852.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> On 3 Dec 2012, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
>> In article <03f62cf852.Matthew@sinenomine.freeserve.co.uk>, Matthew
>> Phillips <spam2011m@yahoo.co.uk> wrote:
>>
>> > If you modify an existing mode definition to make the resolution
>> > smaller, you should not have any trouble. If you enlarge the
>> > resolution you may hit issues with the VRAM limits and with the
>> > pixel rate, which must be high enough to deliver the pixels to the
>> > screen. I do not know how much RPCEmu is affected by these limits.
>>
>> I ran into the default VRAM rate limit when I was trying to get a
>> bigger screen mode. I was told that it doesn't matter to RPCEmu and to
>> just make the value ten times bigger. I did so, and the result works
>> fine.
>
> I believe that RPCEmu089/RO5.xx recognises increased BandLimit values,
> so large emulated modes are possible, but RPCEmu089/RO4.xx does not, so
> its modes are limited by the notional capaciy of VIDIC/VRAM.
>

I've also found RPCEmu089/5.17 accepts a mode (1824 x 1026 x 16M x
58Hz) that RPCEmu089/4.02 does not: 1680 x 1050 x 16M x 60Hz is the
best that the latter would do. The same (modified) monitor def file
was tested in each case (modified using the procedure suggested by
Matthew Phillips earlier). 1680 x 1050 x 16M x 60Hz is the best that
the latter would do. But as this is well beyond the notional VIDC
bandwidth limits, surely the increased bandwidth limits (in my case
380000 760000 1520000 800000) /are/ being recognised...?

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu