> I had an idea for a neat RISC OS UI feature...
> 
> Implement a RISC OS module that inserts a screen mode file written by
> RPCEmu
> into ResourceFS.  When the host UI receives notification that the RPCEmu
> window has been resized, write mode timings for the new screen size into
> the
> ResourceFS mode file.  Then issue a *LoadModeFile Resources:MyModeFile and
> a
> mode change (*WimpMode Xnnn Ynnn etc).  The RISC OS session will change
> mode
> to fit the new window size.  So when you want to read a big document you
> just drag for RPCEmu window and the desktop gets bigger.  
> 
> I looked into implementing it, and sadly it won't work until Allegro 5
> comes
> along (in development), because Allegro 4.2 and 4.4 don't support external
> resizing of the window.

This shouldn't be a problem for the Windows port, as that handles all window
stuff itself instead of handing it all over to Allegro. Doesn't help in Linux
much though.

> It might be possible to implement it wholly in RISC OS with RPCEmu as it
> stands by some kind of desktop widget (perhaps a filter that grabs drags on
> the Display Manager icon?) that defines a new mode file, but it wouldn't be
> as neat.  I had a play but I really don't understand mode timings and I got
> 'unsynced' modes - either I or RPCEmu got the line lengths wrong, where
> each
> line wasn't aligned with the start of the screen.  MakeModes implements
> some
> rules but I can't work them out.  Anyone got any suggestions on how to
> generate RPCEmu friendly modes or details on how to work out minimal
> timings
> (I tried setting front porch, sync width etc to zero but it was
> 'unsynced')?
> The VIDC20 datasheet isn't a huge amount of help.

You only need to set the horizontal display start and end - all other
registers are ignored. In fact, set start to 0 and end to the desired
resolution, that should hopefully give a good display.

> On an unrelated matter, has anyone tried the Sleep,ffb program in
> riscos-progs?  On Ubuntu/x86 it works well as far as cutting the CPU load,
> but seems to stop mouse clicks from getting through to the desktop.  I
> think the interrupt handler is OK - mouse movement is getting through fine,

> as is (usually) the double-click double-arrow pointer, but it's almost 
> impossible to get the desktop to respond to anything (RO Adjust).  I tried 
> reducing the nanosecond sleep time in it to 10000 (from originally 1000000)

> but it didn't seem to make much difference except taking more CPU.  Any 
> ideas?

I tried it on Windows. It caused everything to 'lurch' - essentially the
sleep function doesn't guarantee anything about how long it sleeps for, it
frequently sleeps far too long, and then RPCemu runs several frames together
to try and keep up - with the result that mouse and keyboard are almost
unusable.

> causing system timers to be upset (ISTR similar problems on Arcem with
> keyboard autorepeat because the 2MHz IOC timer was being emulated too
> fast/slow)?

Don't think that's a problem here. RPCemu always emulates the timers at the
right speed.

Tom


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html

_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Reply via email to