In message <[email protected]> on 30 Nov 2012 Stuart wrote:
> In article <[email protected]>, > Matthew Phillips <[email protected]> wrote: > > > I used to use RPCEmu on an Eee notebook with a 1024 by 600 screen. I > > made an MDF with resolution something like 1016 by 528 which allowed me > > to use the window maximised (not in full screen mode) and still have > > access to the Linux windowing system's toolbar. > > I use an EeePC too, any chance of you emailing the MDF to me? Sorry, I no longer have that machine, and although I kept some files off it, I cannot locate them at present (they may be on a backup disc somewhere). But really, there was nothing to creating the MDF, it was very simple to do. I have dug out the instructions which come with MakeModes, and it looks like it is slightly more complicated than what I said in my original posting, but only *slightly*. Here is a quick run-down. The typical MDF will look like this: # 800 x 600 (75Hz) startmode mode_name:800 x 600 x_res:800 y_res:600 pixel_rate:49500 h_timings:80,46,42,800,42,46 v_timings:3,21,0,600,0,1 sync_pol:0 endmode The first line is a comment. You do not have to alter it at all, but it can confuse you later if you don't. mode_name. Up to 19 characters. Used in Display Manager's menu. You'd probably best alter this. x_res and y_res. Number of pixels in each direction. Alter as you wish, but I am pretty sure you need to keep x to a multiple of 8. The other two that need altering are the h_timings and v_timings lines. You will see that the x and y resolutions also appear here as the fourth parameters. That should be all you need to alter. 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. N.B. if you are using a real RISC PC, rather than an emulator, you are not advised to edit mode files by hand, as you are meddling with hardware settings and could upset the video circuitry in the computer or the monitor (I imagine). But with RPCEmu it's fine. The MakeModes help file goes on to explain h_timings and v_timings more. Here is an edited extract: h_timings: hsync, hbpch, hlbdr,hdisp,hrbdr,hfpch v_timings: vsync, vbpch, vtbdr, vdisp. vbbdr, vfpch hsync: is the width of the horizontal sync pulse hbpch: is the width of the horizontal back porch hlbdr: is the width of the left border hdisp: is the number of pixels displayed horizontally (which is normally the same as the x-resolution) hrbdr: is the width of the right border hfpch: is the width of the horizontal front porch vsync: is the width of the vertical sync pulse vbpch: is the width of the vertical back porch vtbdr: is the width of the top border vdisp: is the number of rasters displayed vertically (pixels) vbbdr: is the width of the bottom border vfpch: is the width of the vertical front porch All values on the h_timings line are in units of pixels, and all values on the v_timings line are in units of raster lines. Note: VIDC20 imposes restrictions on these parameters. In particular, all the horizontal timing values must be in multiples of 2, and the horizontal total (hsync + hbpch + hlbdr + hdisp + hrbdr + hfpch) must be a multiple of 4. ----- End of extract. Hope that helps! -- Matthew Phillips Durham _______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
