BeagleBoard: Superb 1280 * 1024 display

I’ve created an MDF for my Xerox 17” monitor by the crudest possible modification from one that was posted here recently. I have no idea whether it is valid according to the proper rules for MDFs, but it works…

...and it produces the crispest, most gorgeous display on my monitor.

Of course, being a digital feed, there are two advantages:

1) the monitor’s pixels are perfectly synchronised to the pixels of the display data stream;

2) any reflections due to poor cable impedance termination have absolutely no effect; there is zero ghosting in the picture.

And this is at native resolution, so there’s no interpolation going on.

Gorgeous.

Great! care to share? Is there anybody who might know if i would be able to trick the board in to doing mode15? He automaticly goes in mode 28 everytime I try.

There’s a list of MDF entries on the video driver page here. There’s already my 57Hz 1280×1024 definition, along with a few standard modes, and now also Chris’s 45Hz 1600×1000 mode.

Thomas: Make sure that you’ve got a 640×256 entry in your MDF. There should be plenty of examples to copy from in the hard disc image – although you’ll probably have to try a few until you find one that works with your monitor.

Thomas: Jeffrey’s 1280×1024 is probably better than mine – the frame rate is 57 Hz against 54 Hz on mine. I will adopt his as soon as I can.

The real clever trick would be to find a way for everybody to be able to get the BeagleBoard to boot up with its user’s chosen monitor resolution, rather than being fixed at 640×480. It would only need a few bytes of storage for the definition. There must be a way to do it. It should ideally have wider applicability to other RISC OS platforms. Ideas, anyone?

Dave, I am a bit baffled. The configuration utility in !Boot should already be able to set your desired desktop monitor resolution. If the MDF file is stored in the Monitors dir you can select that and choose a default desktop of 1280×1024x32bit with ease.

Presumably, Dave means the resolution at boot, as opposed to when you enter the desktop? I’m not sure of the wisdom, though, as if you lose your monitor (metaphorically, speaking – you’d have to be a bit careless otherwise!), you could end up with an unbootable system perhaps? Unless you reset the CMOS, or wherever this setting was stored.

Yes, absolutely I mean at boot.

Booting up at a resolution from the 1980s, and that isn’t even supported by some of today’s monitors, is an anachronism. We really ought to get away from it.

I have a 1680×1050 monitor at home that won’t display the output of my Risc PC until after the desktop boot sequence is well under way.

WPB, you suggest that a system could be unbootable. I would suggest that it is like that already, precisely because monitors can’t display what is happening during the early stages of booting. If an error occurs there, you can’t see anything.

I would agree, though, that care is necessary when storing the proposed new settings.

Perhaps I should put this on the Wish List.

Booting up at a resolution from the 1980s, and that isn’t even supported by some of today’s monitors, is an anachronism. We really ought to get away from it.

This is the first I’ve heard of any modern monitor not supporting 640×480! What version of RISC OS is your RiscPC using? Viewfinder, Vpod or standard VIDC? What’s the configured monitor type?

As I understand it, until the point that an MDF is loaded, RISC OS will limit the available modes to just the numbered modes that are supported by the configured monitor type (see here and here). The boot mode is chosen automatically as well, based around the configured monitor type. If the monitor type is set to auto then RISC OS will attempt to determine the type by reading the values of some of the pins in the monitor lead – but this technique doesn’t work with monitors that support EDID (i.e. pretty much any monitor from the mid-90’s onward), causing RISC OS to read the incorrect monitor type.

So if the monitor type isn’t set correctly, or is set to auto, then it could explain why you’re not getting any picture on boot. If it’s configured properly then you should be able to boot into mode 28 using the standard VGA/VESA timigs, which I would be very surprised if your monitor doesn’t support.

Also note that it’s only VIDC-based machines that are able to detect the monitor type in this manner. VIDC is also incapable of reading EDID data from a monitor. So the RiscPC is really the odd one out with regards to selecting a safe video mode on boot – all other video hardware (viewfinder, Vpod, Iyonix GeForce cards, OMAP) can read the EDID data and use that to select a safe mode (with the possible exception of the pre-revision 3.1 OMAPs, where the limited range of the timing registers means VESA standard timings can’t be used, and “reduced blanking” ones must be used instead – in reality this will be OK for LCD/TFT displays but may cause problems with CRTs)

So although the RiscPC can’t be helped much (I doubt you’d find enough space in CMOS RAM to store a full set of mode timings), there are a few bits that can be done to help the Iyonix/OMAP (At the moment the RISC OS 5 graphics initialisation is very much based on the VIDC-era system, and doesn’t make any attempt to read/use EDID data).

And most x86 PCs, even today, have the BIOS come up in 640×480 or 720×400.

Is this some Mac monitor or something?

Many monitors don’t like the 50Hz 640×480 mode or 640×512 modes. They expect 60Hz.

Tool to generate MDFs from EDID data (e.g. get a hold of the "Decode EDID" tool that Castle used to generate various Iyonix MDF’s)

I’ve just emailed Jack Lillingston and John Ballance, politely asking if this tool is available and can be supplied. If someone else has already done this, I don’t think my extra email will do any harm.