In message <52f6abd608Spambin@argonet.co.uk>
on 30 Nov 2012 Stuart wrote:
> In article <39c69ff652.Matthew@sinenomine.freeserve.co.uk>,
> Matthew Phillips <spam2011m@yahoo.co.uk> 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
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment