Can't change mode pre-desktop

I’m wondering if this is a bug. If I stop the boot sequence pre-desktop – I’m testing on a Beagleboard – then drop into BASIC and check out what mode I’m in, it’s 640×480×256 colours. Now, if I try:

I get a “Screen mode not available”. In fact, I think this is just calling OS_ScreenMode – so I tried using that with a mode descriptor block instead. Same result. Even if I ask for 640×480×256 I get the same error! I’m already in that mode…

I tried manually loading the same MDF that the boot sequence does and this made no difference. How do I change into a 16 or 32 bpp mode – or indeed any mode when pre-desktop? I’m sure it shouldn’t be this hard.

Does numbered modes also fail? e.g. MODE 31
& after a *desktop
Wimpmode 31

Hi Chris. Yes, the numbered modes work but unfortunately this isn’t all that helpful because a) there are no 16bpp or 32bpp numbered modes and b) I specifically wanted to change mode pre-desktop e.g. at the start of the boot sequence.

So, something about going into the desktop seems to be making a change which allows OS_ScreenMode to work when you use a mode descriptor block rather than an old-style mode number.

Hmm. Maybe it’s not a bug. I just tried at the very end of the pre-desktop boot sequence, just before it enters the desktop and the mode change worked. So there’s something important happening during the boot sequence itself (aside from loading an MDF) which somehow enables mode changes to things beyond the traditional numbered modes. I’ll keep digging…

Is it the evil forces of VIDCBandWidthLimit at play? That’s somewhere in predesktop. And you want to be after LoadModeFile obviously.

I’m fairly certain the default bandwidth limit is 100MB/s, which should be enough for 640×480×32bpp @ 60Hz.

It’s possible that it’s BASIC which is stopping you from changing mode – see the 1.26 change notes for details of when BASIC will/won’t surrender application space (as would be required for growing screen memory). But from what’s said there, it sounds like what you’re doing should work (especially since attempting to change to the current mode is failing).

It was bleedin’ VIDCBandWidthLimit – I tracked it down in the end. Ta.