MDFs on the BB -xM

Is there any info on the BB, RISC OS and ‘video RAM’? I did an MDF for my Dell 1505FP using MakeModes which gives me 4 working resolutions, one of which matches the monitor’s specified ideal. I was wondering if it’s possible to do more with Aemulor in mind.

What kind of information are you interested in? MakeModes is a bit long in the tooth and I think only auto-generates modes which are VIDC20 compatible. Certainly a lot of the warnings it produces when tweaking modes manually assume you’re running on VIDC hardware.

With the BB you’ve got quite a bit more freedom, especially with the porch/blanking timings. However there are a couple of big limiting factors: 100MHz max pixel rate (86MHz acording to the docs, but we bumped it up a bit after finding that most boards can go higher), and 2048×2048 max resolution (although the limited pixel rate will be the bigger issue). Since the max pixel rate is quite low there’s no chance of hitting any memory bandwidth limit like on VIDC.

That is the sort of thing I ‘m looking for, thanks – what the BB/RISC OS combination is capable of. Using MakeModes ’cos it’s here but, yes, it’s not keen on the 3MB of video RAM it thinks I need for 1024×768 at 32bpp. Don’t think I’m going to hit limits with this monitor. Is there anything other than MakeModes that will automate the process? I’m guessing not.

The MDF should be the same irrespective of the BPP. So you should be able to turn it down and get the modes you want.

I understand the BB wouldn’t run at 1920 × 1200 (60Hz), but would probably manage 960 × 1200, which would line up the pixels. I tried making such a mode a while ago, but my iyonix really didn’t like it, to see whether a BB would be usable with my screen. Would it be hard to make RISC OS work with wide pixels? (And would the end result be worth the effort? It may look nearly as horrid as a non-native resolution.)

Update. I just tried it on my Pi, it worked, apart from not stretching to fill the screen, so I can’t tell if it would look OK.

The MDF should be the same irrespective of the BPP. So you should be able to turn it down and get the modes you want.

Oh, yes. It’s not an issue – the RAM box just glares red at me. I quite like red. I won’t be pushing things. This monitor was chosen to fit the corner left on my desk rather than resolution. or quality.

Is there anything other than MakeModes that will automate the process? I’m guessing not.

There is the EDID decode tool, but I wouldn’t expect to see a proper release of that until someone’s had a chance to tidy it up and make it more user-friendly (Integrating it into MakeModes would be the obvious choice to start with).

I’ll bait my breath.

I did an MDF for my Dell 1505FP

Any chance of getting a look at your MDF? I’m using a Dell 2405FPW so it might give me some pointers as to why I can’t get a decent mode out of it.

Don’t forget there’s a bounty associated with EDID support. Over £400 to whoever does it.

Any chance of getting a look at your MDF?

It was here

Be warned I don’t really know what I’m doing, I let MakeModes do the work. I’ve added a couple of ‘borrowed’ definitions because they seem to work. Only goes up to 1024×768 – monitor’s only 15".

Be warned I don’t really know what I’m doing

Thank you – neither do I it seems :)

Having awoken refreshed, I realise it can’t be the MDF I’m using that is causing my inability to set the required mode (1680×1050) as the same MDF works on the Iyonix with the same monitor. It must be a config issue on the BB-xM that is my problem.

Having awoken refreshed, I realise it can’t be the MDF I’m using that is causing my inability to set the required mode (1680×1050) as the same MDF works on the Iyonix with the same monitor. It must be a config issue on the BB-xM that is my problem.

You’re most likely hitting the 100MHz pixel rate limit of the BB-xM. 1680*1050*60Hz = 105MHz, and that’s without any border/sync timings taken into account.

FYI, the full checks that OMAPVideo performs are as follows:

• Pixel rate <= 100MHz
• Clock dividers are within range (hard to quantify exactly what pixel rates this check will discard, but I’d be surprised if anyone found a mode which failed this check)
• Horizontal & vertical porch/border/sync values are within range
  • Horizontal & vertical sync width must both be under 256
  • (Horizontal back porch + horizontal left border), (Horizontal front porch + horizontal right border), (Vertical back porch + vertical top border), (Vertical front porch + vertical right border) must all be under 4096
  • Note that for some models of the original BB, the limits are lower: 64 for the sync limits and 256 for the porch+border limits. I’m not sure offhand what models of BB this applies to though. (Rev C2 and below, perhaps?)
• Combined horizontal porch/sync timings (Horizontal back porch + horizontal left border + horizontal sync width + horizontal front porch + horizontal right border) must be greater than 4
• Display size must be less than or equal to 2048×2048
• Display width must be multiple of 8 pixels

Interestingly I don’t seem to be doing any checks for minimum vertical porch/sync timings. After checking the TRM I see that the following additional constraints apply:

• (Horizontal back porch + horizontal left border), horizontal sync width, (horizontal front porch + horizontal right border) must all be greater than zero
• Vertical sync width must be greater than zero
• No requirement for (vertical back porch + vertical top border), (vertical front porch + vertical bottom border) to be greater than zero?

So if your monitor is happy with bare minimum porch/sync timings, you could try tweaking the MDF to be the following:

• All border values set to zero (the BB doesn’t output a border colour anyway – the border timings just get added into the porch timings)
• Horizontal back porch, horizontal front porch set to 2
• Horizontal sync width set to 1
• Vertical back porch, vertical front porch set to 0
• Vertical sync width set to 1
• Pixel rate set to 100MHz

Which should give you a refresh rate of 56.46Hz, just within the monitor’s stated limit of 56Hz.

FYI, the full checks that OMAPVideo performs are as follows:

Wow, thank you for the detailed info. I’ll give it a go.

Thomas wrote a small tool called Vesa that reads the information from the monitor and then create a MDF from a database. The tool is not ready but on my xM and Panda it works well. The monitor must have Vesamods and it must exist something suitable in the database.