Discovering if a mode is in the MDF

I’m looking at an application that was intended to use a numbered mode (mode 13 which is 320×256) which looks fine on the Risc PC, but attempting that on the Pi gives some weird result where there’s a vertical split but overall the image fills the screen, and on a Beagleboard the (same) monitor gives a weird slurred horizontal blinds effect.

If I load a (slightly wrong, eg. AKF85) MDF for a different monitor, the Pi is happy but the Beagleboard is still weird, but maybe the OMAP video isn’t really happy that low res.

In principle with a little work everything could be scaled to use 640×512, but I’d rather not just double up all the pixels when the monitor clearly knows what to so, especially for speed reasons.

I tried calling OS_CheckModeValid but on all 3 platforms it returns carry clear saying the mode is valid.

Rummaging in the kernel I see FindOKMode will try Service_ModeExtension, but the only claimant for that is the ScreenModes module which has an upfront check to not bother with numbered modes.

When not claimed the kernel looks through its BigVIDCTable and of course locates mode 13 and that it’s OK on an SVGA-like monitor, then returns.

On the face of it it looks like the GraphicsV owner doesn’t get an opportunity to reject numbered modes. So here’s the question(s):

a) shouldn’t numbered modes be passed through the GraphicsV vet mode?
b) is there another way to find if the parameters for a numbered mode actually exist in the MDF?
c) should OMAP video reject mode 13?

Just out of interest, if you ask for the mode dimensions for mode 13, what does it return? The expected for the mode, or the “this ought to fit” closest match with whatever is in the MDF?

On the face of it it looks like the GraphicsV owner doesn’t get an opportunity to reject numbered modes.

Mode vetting and translation is a tangled mess. The bit you’ve missed (or at least one of the bits) is that OfferModeExtension actually calls Service_ModeExtension up to three times:

1. The first call is with the initial mode
2. If that call fails, and it’s a numbered mode which the kernel knows about, the kernel will generate a mode selector block and try Service_ModeExtension again using that
3. If that call fails, the kernel will try the mode selector again, but this time with the framerate field set to -1

For the 2nd & 3rd calls ScreenModes will do its stuff, including making the appropriate GraphicsV calls to make sure the driver is happy with whatever mode it’s thinking of replying to the OS with.

When not claimed the kernel looks through its BigVIDCTable and of course locates mode 13 and that it’s OK on an SVGA-like monitor, then returns.

Actually, by my reading, (assuming you’ve got monitor type 7 set) it’ll check BigVIDCTable, fail to find anything, check SubstModeTable, fail to find anything, issue Service_ModeTranslation, and then ScreenModes will jump in and spin its wheel of fortune to try and find a VGA-ish mode which it has a definition for (most likely 640×480). If ScreenModes fails then the kernel will go into its SVGA fallback mode and try picking a substitute mode from 25-28 (complete with some funny logic to try mode 0? FindSubstitute will get called with R10=original mode, which will then call PushModeInfoAnyMonitor with r10=original, r11=0, which will then call OfferModeExtension, which we know will fail, so will then cause it to check BigVIDCTable for monitor type 7 and the substitute mode (0), which will fail, which will then cause it to go into a last-minute panic and use monitor type 0 mode 0. Then FindSubstitute will check the BPP of the pushed mode (i.e. 1bpp), and ultimately ends up returning with either mode 25 or mode 28 depending on whether the driver likes 1bpp modes or not)

After all that, OS_CheckModeValid will then call OfferModeExtension again (by way of PushModeInfo), so if the above logic ended up picking something which isn’t supported then OfferModeExtension will fail and OS_CheckModeValid will return with carry set to indicate it’s a bad mode.

There’s also some equally crazy logic which goes on when you try and select a mode and the kernel has trouble finding out which one to use – typically resulting in one of modes 25-28 being used if you ask for a numbered mode which isn’t in the MDF.

c) should OMAP video reject mode 13?

Negative. The mode is within the hardware limits, it’s more likely to be the monitor that doesn’t like the mode rather than the OMAP.

Mode vetting and translation is a tangled mess. The bit you’ve missed (or at least one of the bits) is that OfferModeExtension actually calls Service_ModeExtension up to three times

Very tangled it seems, I did only read through it once not thrice. The problem is that doesn’t seem to match the empirical test I did on the Pi. First I loaded “Iiyama Vision Master 1451” (not actually my monitor, but it’s on the standard disc image) then

  *BASIC
  VDU 22,13
  PRINT MODE  <— returns 28
  SYS"OS_CheckModeValid",13 TO;flags
  PRINT flags <— returns 4, ie. C clear

c) should OMAP video reject mode 13?

Negative. The mode is within the hardware limits, it’s more likely to be the monitor that doesn’t like the mode rather than the OMAP

In each case it’s the same monitor being used, with the same MDF as in the working case. With Risc PC it’s fine (via analogue in), with Pi (via HDMI) it’s just dodgy OS_CheckModeValid, with OMAP the picture is weird as mentioned. I’d look at the syncs, except it’s not analogue so I’m not going to see much on a scope.

Just out of interest, if you ask for the mode dimensions for mode 13, what does it return?

The X size was 319 (via OS_ReadModeVariable) so it seemed to know about the mode.

Very tangled it seems, I did only read through it once not thrice. The problem is that doesn’t seem to match the empirical test I did on the Pi.

Hmm, interesting. How old is your ROM? I’ve just repeated your test with one from the 27th and mode 13 worked fine after loading the Vision Master MDF.

with Pi (via HDMI) it’s just dodgy OS_CheckModeValid

Remember that with the Pi we aren’t actually in control of the mode timings; instead the GPU just scales whatever we give it to whatever output resolution it picks on startup.

I’ve just done some experimentation myself, and discovered the following:

• Using the AKF85 MDF, the HDMI input of my main monitor will correctly detect the dimensions & framerate of all the modes I throw at it (checked via the OSD), even crazy things like the 9.4MHz 240×352 mode. However none of the modes with a pixel rate below 25MHz will produce an image – just the blue screen the monitor gives when it doesn’t like the mode.
• My other monitor, with the AKF84 MDF via DVI, has a bit more luck with the lower resolution modes. Mode 47 (360×480, 16.7MHz) works, but anything with a lower pixel rate (e.g. 320×480 15.7MHz) doesn’t. Unfortunately this monitor goes into standby if it doesn’t like the mode, so there’s no way of checking the OSD to see if it’s being detected at all (actually it even goes as far as saying that there’s no signal detected – even though the other monitor was able to detect the signal fine). 480×352 and 384×288 also work fine (both 18.8MHz) – two modes that didn’t work with the first monitor.
• The second monitor, being fed via VGA from my RiscPC, appears to work with all the modes (although it will typically incorrectly detect the resolution and consequently the size/positioning is wrong).
• The first monitor, connected to my Iyonix via VGA, also appears to “work” with all the modes. Some modes are mostly OK (mode 47 gets detected as 640×480, but is mostly centered/scaled OK), while others are completely broken (320×256, 240×352, etc. all end up very letterboxed, with the picture offset 50% to the right so that only the left half is visible).
• I’ve also taken a peek at the TFP410 datasheet (the DVI framer chip used on the BB), and that claims the minimum supported pixel rate is 25MHz. But it’s clearly capable of working much lower, as it was working fine at 16.7MHz.

So although I can’t prove that 320×256 works, I am fairly confident that the OMAP is generating the correct signals, judging by the OSD information from the first monitor. And I’m also fairly certain that just because a monitor “works” with a given signal over VGA, it doesn’t mean the same signal will work correctly over DVI/HDMI. But I guess the only way to prove these things for certain would be for someone with a HDMI/DVI-D to VGA adapter to confirm that the modes work correctly!

The problem is that doesn’t seem to match the empirical test I did on the Pi.

Hmm, interesting. How old is your ROM? I’ve just repeated your test with one from the 27th and mode 13 worked fine after loading the Vision Master MDF.

Now this morning it’s not doing it any more having changed nothing, so I’ll have to keep an eye out for it. Maybe it’s the order I was testing it in, but in general after a power cycle it’s OK? Dunno. Aside: the Pi ROM was from 08-Apr-2014 and I’ve now tried 01-May-2014 too.

So although I can’t prove that 320×256 works, I am fairly confident that the OMAP is generating the correct signals, judging by the OSD information from the first monitor.

Back to the Beagleboard:

On my Hyundai monitor the OSD says 320×256 31.4kHz/70.1Hz but the display is weird banding in columns and horizontal stripes with a net slant. I suppose it might be trying to auto scale it, and maybe it doesn’t try to autoscale the VGA port?

I dug out a Viewsonic monitor and its HDMI input OSD says 720×400 31.5kHz/70.1Hz 28.2MHz pixel clock but it’s not locked horizontally (shaking left/right quite badly).

I seem to have lost the lead that fits the plug on the telly – will buy another and try that later.

It seems for now OS_CheckModeValid might be behaving as I want, so I’ll add a call to that to the application, and will try to be a bit more methodical with the Pi testing. Beagleboard still has a question mark over it for now.

Both of you know vastly more than I’ll ever know about RISC OS so I hesitate to mention it.
But could the difference in the modes defined in the OS before the MDF is loaded have any relevance?

In the past I’ve had systems that worked fine with a configured MODE 28 but not with WIMPMODE 28 which seemingly was the same.

Back to the Beagleboard
I seem to have lost the lead that fits the plug on the telly – will buy another and try that later.

Got a replacement HDMI cable, but the (Sanyo) TV wouldn’t do 320×256 either. That makes 0% digital success from the Beagleboard on 3 monitors. I’ll see if there’s anything else I can deduce without buying any more monitors.

In the past I’ve had systems that worked fine with a configured MODE 28 but not with WIMPMODE 28 which seemingly was the same.

That might be that the configured mode uses a table of timings in the kernel during early initialisation, by the time you need a wimpmode you’ve loaded a (possibly wrong timing) MDF.

Just throwing this out there – it’s probably not relevant but useful to other readers who stumble across this thread – don’t hotplug DVI/HDMI on a BeagleBoard, unless you want to kill it!

Yes, the manual is quite specific about that. HDMI before power connection.

I can’t prove that 320×256 works, I am fairly confident that the OMAP is generating the correct signals […] I guess the only way to prove these things for certain would be for someone with a HDMI/DVI-D to VGA adapter to confirm that the modes work correctly!

I splashed out on just such an adapter, having prised it open it’s based on a EP94Z1E which from the block diagram (and the size of the chip) doesn’t look to contain a framestore of any sort so should pass everything through faithfully.

The first hurdle was it’s quite thirsty: approx 250mA, and that was enough to trip the PTC resistor (RT1) on the Beagleboard xM. As I’m powering from a bench power supply I just selected a more appropriately sized nail for the job.

To its credit, it passes through the EDID data, so I was able to read the monitor personality via the HDMI to VGA adapter from RISC OS.

Looking on the scope, the H+V sync timings were spot on compared with the AKF85 MDF I selected, and behold – an image was formed at 320×256! However, the image kept blanking during periods of high activity, while an idling desktop (320×256, quite lo res) was solid/stable.

During busy sprite plotting the screen blanked for exactly 35 vertical syncs (0.5s), I tried *AUDIO OFF just incase the sound DMA was in a bad mood but that didn’t help, and looking on the scope the syncs remained rock solid it’s definitely the R/G/B image that is set black. So this leads me to wonder
a) Is it the HDMI to VGA converter losing the plot? The syncs keep going so I don’t think so since they’d be interleaved on the digital data lines, but I can borrow a different brand of converter over the bank holiday
b) Is high CPU burn starving the video DMA, then that DMA underrun code is kicking in to blank the screen until it clears? This is my favourite theory.
c) How come these monitors don’t like 320×256 via their digital inputs? I’ll probably never know.

b) Is high CPU burn starving the video DMA, then that DMA underrun code is kicking in to blank the screen until it clears? This is my favourite theory.

Hmm. 320×256×70Hz isn’t exactly “high bandwidth”, but I guess it’s possible that either the low resolution or low clock rate is causing it some difficulty filling the DMA FIFO in time for the frame to start.

If you’re lucky a debug build of OMAPVideo will tell you what’s going on. But the fact you say that the syncs remain solid suggests that it isn’t hitting the DISPC_IRQ_SYNCLOST handler, because that will briefly stop video output completely in order to reset the controller. Unless your scope wasn’t picking that up, of course!

But the fact you say that the syncs remain solid suggests that it isn’t hitting the DISPC_IRQ_SYNCLOST handler, because that will briefly stop video output completely in order to reset the controller. Unless your scope wasn’t picking that up, of course!

I’d dialled up the capture memory to 10Mpts so I had ~1s on screen to scroll through – it was definitely something blanking the image while the syncs continued.

Having borrowed another HDMI to VGA adapter that didn’t show any image at all, but I shalln’t break that one open as it’s not mine.

I added some counters into the OMAPVideo module in the sync lost and sync lost digital handers, and the GraphicsV set blank entry point (which is what the kernel calls if anyone uses OS_UpdateMEMC to halt video DMA), but zero calls to any of those despite seeing picture blanking a number of times.

Then I looked at the schematic and it appears the TFP410 has been wired up to use DK[3:1] pins to set the skew between clock and data from the OMAP3530. However, none of the resistors are fitted so the default is 0-0-0. If I fit R95 the blanking problem goes away.

So it would seem to be a quirk of the BBxM, either the extra screen activity is causing crosstalk that causes the TFP410 to see transitions on the floating DK pins (they have weak pull downs) or such a low pixel clock has much more skew than all the other modes and it’s a bit on edge. I could solder some wires onto the TFP410 and have a look for sure, but unless there’s some corresponding skew possible on the OMAP3530 end I doubt many people will want to get the soldering iron out for 320×256 pixels.

Having looked, clock and data are lined up to within 1ns. The following quality test program didn’t show any blanking

MODE 13
REPEAT
  FOR i = 0 TO 1000
    CIRCLE FILL RND(1000),RND(1000),100
    GCOL 0,RND(256)
  NEXT
  CLS
UNTIL 0

Workaround: If I just make MODE 13 be 15MHz pixel clock by editing the MDF (and adjust the front/back porches to soak up the spare time) it stops blanking, so in conclusion I’m pointing the finger at TFP410 and minimum clock rate supported.

Workaround: If I just make MODE 13 be 15MHz pixel clock by editing the MDF (and adjust the front/back porches to soak up the spare time) it stops blanking, so in conclusion I’m pointing the finger at TFP410 and minimum clock rate supported.

Sounds like a reasonable conclusion. Unless you have any other ideas, I’ll update OMAPVideo to enforce a minimum 15MHz clock rate.

Workaround: If I just make MODE 13 be 15MHz pixel clock

Sounds like a reasonable conclusion. Unless you have any other ideas, I’ll update OMAPVideo to enforce a minimum 15MHz clock rate.

I went in steps of 100kHz and the image stopped blanking at 14800 but had a couple of ‘scratchy’ horizontal lines, 14900 was stable but had a few scintillating pixels, 15000 was all good.

As the datasheet says 25MHz is the minimum I think 15MHz as a lower limit is a reasonable amount of slack for DVI output, and maybe 13.5MHz for the TV out?

maybe 13.5MHz for the TV out?

TV out isn’t really relevant at this point; it currently just uses hard-coded PAL or NTSC signal timings. Maybe one day I’ll get round to working out how to program it properly!