Low resolution screen modes

I have been trying run the 32bit version of MicroDrive-32M with not much success. It was installed using PackMan. It does not appear need ADFFS to run.
It fails at first saying it needs a 1024K sprite area to be configured. Then fails again wanting Sassoon font to be installed.
When these requirements are met it flashes up some golf-like graphics and then fails at line 22330.
22330 MODE"X480 Y352 C16M EX1 EY1
with “screen mode not available”.

Looking at the display manager shows that the lowest resolution available on both the monitors I have tried is 640 × 480.

Creating MDFs is a black art that as often as not has left my machine inoperable whenever I have messed with it.

The question is – is it possible that a modern 1080p monitor can be made to work at the low resolutions required by MicrDrive and other old games? Or should I get a life and get out on the golf course for real?

Anymode is the solution.
And, of course, with ‘disable mode change’ option activated on your Pi.

Creating MDFs is a black art

On a Pi, just add the resolution with all the other values = 0.

On a Pi, just add the resolution with all the other values = 0.

Assuming you have disable_mode_changes enabled. If you don’t, they need to be real mode timings which your monitor can support.

The big problem with low resolutions modes is that most/many DVI or HDMI-based video outputs have a lower limit on the clocking of 25Mhz (and max of 160-250 depending on device). The DVI spec has a lower limit of 25Mhz according to Ti website that I just checked, and this carries over to many digital devices.

For resolutions significantly below 640×480, it is hard (even with high timings!) to make the mode reach that pixel clock rate, so you often end up with an undisplayable mode. I added as many as I could into the ARMX6 MDF, but had to give up in the end with the lowest resolutions, because I simply couldn’t create anything that would display correctly.

I know StrongGuard/GameOn on RiscPC used 100hz modes to circumvent such issues, but those don’t usually work on modern LCD monitors.

Really the only solution, as David said, is to use the Pi’s “fixed resolution” mode where the graphics chip detects a fixed resolution (before RISC OS starts) and then scales everything to that resolution. It doesn’t work on every monitor, but when it does, it allows more-or-less any mode to be used (via “AnyMode” module). This is how we pre-configured RISC OS Direct, for example, as we expect games to be a popular use for that.

Of course, this doesn’t help on more “heavy duty” RISC OS machines like ARMX6 or Titanium, as that is relying on a special feature of Pi (essentially Pi is a big GPU with a small (but growing) ARM CPU connected, which is the opposite arrangement of most system-on-chip designs).

I have suggested to a few people that perhaps a scaling module could be created to allow software-scaling of modes, but it is quite a complex task, especially when you consider that most old games weren’t exactly well behaved!

Really the only solution, as David said, is to use the Pi’s “fixed resolution” mode where the graphics chip detects a fixed resolution (before RISC OS starts) and then scales everything to that resolution. It doesn’t work on every monitor, but when it does, it allows more-or-less any mode to be used (via “AnyMode” module).

If EDID discovery does not work on the Pi, you can easily configure a fixed HDMI screen mode forcing any resolution you like. This is necessary for the old Pis and higher-res-than-officially-supported screen modes (QHD, 4K) anyway.

However, this must be done individually, and cannot of course be part of a default distribution. I always have a selection of sensible standard modes inside config.txt that are commented out for possibly misbehaving screens. Especially TVs are sometimes “interesting”, but are nearly always happy when forced to 1080p@60Hz.

Anymode is the solution.
And, of course, with ‘disable mode change’ option activated on your Pi.

Thanks – done that and MicrDrive-32M now working on the Pi.
I have uninstalled it from the ARMX6

Question for those that have played around with screen modes… I can’t help feeling that one solution would be to use timings for a higher resolution mode, but with larger blank spaces on sides/top/bottom, with the goal of a pillar/letter-boxed mode. Whilst not ideal, this would at least allow display of small modes. However, I’ve not had much success with this method. It seems logical to me, but either the monitors or the timings elude me…

I can’t help feeling that one solution would be to use timings for a higher resolution mode, but with larger blank spaces on sides/top/bottom, with the goal of a pillar/letter-boxed mode.

I am currently following a group of experts trying to do more or less what you describe in the context of MISTer (an FPGA-based solution to simulate old computers and consoles and arcade machines). The current results are “interesting”. It seems extremely difficult to produce modes that run on a measingful number of screens – and the screens where those non-standard modes work didn’t have the problems that the workaround addresses in the first place!

Question for those that have played around with screen modes… I can’t help feeling that one solution would be to use timings for a higher resolution mode, but with larger blank spaces on sides/top/bottom, with the goal of a pillar/letter-boxed mode. Whilst not ideal, this would at least allow display of small modes.

That is what I did on the RISC PC with the help of a little module I wrote for myself. All I know is that it worked for my monitor. I still have the code and put it here . Not sure how it fares on other machines/monitors.