Big Resolutions

And for the benefit of anyone else trying to do this, this is the config.txt file that’s done the trick:

disable_overscan=1
hdmi_group=2
hdmi_drive=2
fake_vsync_isr=1
gpu_mem=128
init_emmc_clock=100000000
kernel=RISCOS.IMG
hdmi_mode=87
hdmi_cvt=3840 2160 25 3 0 0 1
max_framebuffer_width=3840
max_framebuffer_height=2160
hdmi_pixel_freq_limit=400000000

And this is the mode definition file:

file_format:1
monitor_title:Philips 4K
DPMS_state:3

startmode
mode_name:1600 × 1200
x_res:1600
y_res:1200
pixel_rate:121000
h_timings:0,0,0,1600,0,0
v_timings:0,0,0,1200,0,0
sync_pol:0
endmode

startmode
mode_name:1920 × 1080
x_res:1920
y_res:1080
pixel_rate:154000
h_timings:0,0,0,1920,0,0
v_timings:0,0,0,1080,0,0
sync_pol:1
endmode

startmode
mode_name:1920 × 1200
x_res:1920
y_res:1200
pixel_rate:154000
h_timings:0,0,0,1920,0,0
v_timings:0,0,0,1200,0,0
sync_pol:1
endmode

startmode
mode_name:2048 × 1536
x_res:2048
y_res:1536
pixel_rate:217000
h_timings:0,0,0,2048,0,0
v_timings:0,0,0,1536,0,0
sync_pol:0
endmode

startmode
mode_name:2560 × 1440
x_res:2560
y_res:1440
pixel_rate:242000
h_timings:0,0,0,2560,0,0
v_timings:0,0,0,1440,0,0
sync_pol:0
endmode

startmode
mode_name:3200 × 1800
x_res:3200
y_res:1800
pixel_rate:242000
h_timings:0,0,0,3200,0,0
v_timings:0,0,0,1800,0,0
sync_pol:0
endmode

startmode
mode_name:3840 × 2160
x_res:3840
y_res:2160
pixel_rate:244000
h_timings:0,0,0,3840,0,0
v_timings:0,0,0,2160,0,0
sync_pol:0
endmode

All these modes work beautifully on my Philips 43put4900/12 4K TV/monitor (that I got from Argos for £299 a year ago), except that the 3840×2160 is slightly dodgy* at 64k or 16M colours. The picture otherwise is stable and clear.

The monitor reports all these modes – even the 1920×1080 – as 3840×2160 at 24 Hz. Is the GPU actually delivering that, with the screens scaled in the GPU, based on what it says in CONFIG.TXT? The frame rate that RISC OS is reporting are much higher in most cases, but are they just calculated on the basis of pixel rates from the MDF that are not actually being used? The monitor reports what it gets from the Mac as 3840×2160 at 30 Hz.

If I put “hdmi_cvt=3840 2160 30 3 0 0 1” in CONFIG.TXT then the Pi won’t boot, or at least, it won’t display anything whether it’s booting or not.

• Slightly dodgy: mostly lovely and sharp and stable, but with occasional horizontal lines flashing across the screen. I used to see a similar effect on RiscPCs if I pushed the VIDC to the limit. I worry about causing damage. I think it wise not to use this mode with 64k or 16M colours.

… then the Pi won’t boot, or at least, it won’t display anything whether it’s booting or not.

If you want to see if a RISC OS computer has booted when there is no display, share the computer hard drive.

e.g. on a Pi create an obey file of:
Share SDFS::0.$ PiSD

You can even edit your config.txt file remotely, so saving having to take the SD card out and edit it via a reader.

Should I then be able to see it and edit it on my Mac? That would be good. I’ve got a second Pi (Thanks, David Feugey!) but I don’t really want to put a second monitor back on my desk now I’ve manage to get the Pi driving the same monitor as the Mac – and I prefer taking SD cards in and out to taking HDMI leads in and out! (The monitor has two HDMI inputs, so I’ve got the Mac and one Pi both connected.)

If it’s booted up in a mode that the monitor can’t handle, all I have to do is f12, wimpmode 16, return twice – but that didn’t work.

The monitor reports all these modes – even the 1920×1080 – as 3840×2160 at 24 Hz. Is the GPU actually delivering that, with the screens scaled in the GPU, based on what it says in CONFIG.TXT? The frame rate that RISC OS is reporting are much higher in most cases, but are they just calculated on the basis of pixel rates from the MDF that are not actually being used? The monitor reports what it gets from the Mac as 3840×2160 at 30 Hz.

Yes, the GPU will always be delivering whatever mode is listed in the config.txt. It scales the image that RISC OS gives it, and the framerate that RISC OS reports is effectively rubbish.

Getting the GPU to change mode on demand is one of the things on my todo list.

Don’t worry about it on my account (although obviously for others it’s probably another matter!) – I’m perfectly happy with the status quo now!

Screenwise, that is.

FontEd doesn’t seem to work with the new build – possibly to do with HiVectors? It’s not something I’m expecting to use in the near future, possibly never again, I don’t know, anyway. I can always put the old build SD card back in and use 1920×1200 if FontEd won’t work on the new build.

And it’d be nice to get the Pi talking to the Mac on the network, too, but maybe I’ll manage that, and it’s not a big deal for me anyway. I might have been able to do that on the old build, but never got round to it in the last three years. Both talking to the internet okay!

FontEd doesn’t seem to work with the new build – possibly to do with HiVectors?

Try the copy in the bonus binaries archive – that will have been built from the latest ROOL sources.

However it is possible that version is broken on high vector ROMs – I don’t think any of the developers have tested it yet.

8~) Thanks – will try.

My XP1FontEd works okay, but it’s designed to complement FontEd, not replace it. Not surprising it works – iirc it’s entirely in BASIC 8~)

re sharing a Pi’s SD card (drive)

Should I then be able to see it and edit it on my Mac?

No I should have mentioned the *share command is for ShareFS (also called Acorn Access) which is RISC OS peer to peer networking. So you will need another RISC OS computer with ‘Access enabled’. Another Pi would do nicely or even anything with a suitable network interface even if only running RISC OS 3.1

I thought so. I vaguely remember using it way back in the day, but we moved on to using a fileserver (running on a Risc PC). I no longer have any RISC OS machines apart from the Pis, and it’s not convenient to have both of them running at once unfortunately. I don’t want a second monitor on my desk.

But I’m not really bothered about knowing whether the Pi has failed to boot or is merely not displaying anything – if I can’t make it display something by changing mode, then it’s useless to me anyway. With the frame rate set at 25 in CONFIG.TXT all is hunky-dory anyway.

What I would really like is a way to access the NAS drive that the whole family uses with our Macs and PCs, or to access the (shared) hard drive on my Mac. Couldn’t do that with the old (2013) build, but maybe it’ll be possible with the new one. I’ve not looked into it yet.

It will be OK with a SMB or Windows share. But you probably need to open it fully, from a security point of view.
Here, a connection between ROS5 and Windows 7 or 10 works.

SMB is knackered with El Capitan, isn’t it? But we do now have a Windoze 10 laptop in the house. The NAS may be SMB, I’m not sure. Will be investigating.

… if I can’t make it display something by changing mode, then it’s useless to me anyway

You can often remotely get it to correctly display:
Create an obey file say called “SetPiMode” with a load mode file and wimpmode command that you then save to the no displaying Pi’s root directory, then on that Pi press F12 type setpimode and bob should be your uncle!

I used to often end up typing blind wimpmode 31, with later machines including a pi you have to do more e.g. wimpmode X1920 Y1080 C16M
And on the very latest systems
wimpmode X1920 Y1080 C16M LTRGB

You do have to know which modes are available with the currently loaded MDF hence also including the load mode file command.

There were no modes available at all, regardless of which MDF was loaded, because of the “hdmi_cvt=3840 2160 30 3 0 0 1” line in CONFIG.TXT.

But the whole question doesn’t arise anyway, because I don’t have another RISC OS machine on the network, and it would be a real pain to put another one on – whereas switching an SD card in and out is no trouble at all.

There were no modes available at all, regardless of which MDF was loaded, because of the “hdmi_cvt=3840 2160 30 3 0 0 1” line in CONFIG.TXT.
But the whole question doesn’t arise anyway, because I don’t have another RISC OS machine on the network.

Just in case anyone else reads this thread and does have other RISC OS computers on their network that can see a ‘headless’ Pi, you can edit the CONFIG.TXT remotely, then reboot it. We’ve done this more than once and find it much more convenient than removing the SD card and editing it on another computer.

Now that’s fair enough! :-)

You do have to know which modes are available with the currently loaded MDF hence also including the load mode file command.

Doesn’t AnyMode help here? :@)

Personally I put my mode files in !Boot.Library so I can just run it I usually have a ‘SafeMode’ file in there

No mode is “safe” when there’s a mode specified in CONFIG.TXT that the GPU can’t display, or your monitor can’t display, which was the original problem.

OK. Status report.

Pi (B2) is now hooked up permanently to the 4K monitor, and the 1600×1200 monitor is gone (oh the relief – desk space!)

I’ve got two SD cards I can switch between: (1) R14 (08-Jul-13) and (2) Overnight build (12-Sep-16) with the config.txt and MDF I posted earlier.

(2) Works in 4K, is absolutely great for !Draw, and runs all the apps I wrote myself happily. FontEd doesn’t work. Netsurf works for some sites, but crashes on many, including Google and ROOL. I can’t see my Mac or my NAS. All those issues might be possible to sort, or not, I don’t know, but I can see the local hard drive, which means I can transfer stuff to and from Pi running (1), so none of them are a big deal. It’s !Draw I really want the big resolution for. This is all without doing anything with ZeroPain.

(1) Works in 1920×1200 (but nothing more than that in either direction works properly at all afaics). This is fine for everything except !Draw so far as I’m concerned. I can’t see the Mac or NAS, but NetSurf works beautifully, and I can email myself back and forth between the Mac and the Pi.

So I’m switching between the two SD cards as necessary, and am fairly happy. Suggestions about how to get either or both (1) and (2) talking to the Mac and/or the NAS would be welcome, or to get NetSurf working better on (2), but they’re not a big deal and I myself wouldn’t go to a lot of trouble to achieve them.

An 8GB USB memory stick I have that used to talk to either the Mac or the Pi now won’t do so, since I formatted it on the Pi to try to use it as my Boot drive.

The Pi wouldn’t boot from it anyway – it said it was waiting for the boot drive to be ready, and sat there saying that forever. When I shifted the boot drive to the SD card, all was happy, but I couldn’t see the memory stick until I removed it and re-inserted it, after which it functions perfectly. This behaviour is repeatable, so I now boot from the SD card.

I can now format that memory stick on the Pi and use it on the Pi, but the Mac says it’s unformatted; or I can format it on the Mac and use it on the Mac, and then the Pi says it’s unformatted. Not a big deal, but interesting.

An 8GB USB memory stick I have that used to talk to either the Mac or the Pi now won’t do so, since I formatted it on the Pi to try to use it as my Boot drive.

As a boot disc it would need to have been formatted as SCSI which the Mac would know nothing about.

The Pi wouldn’t boot from it anyway

The drive number of the SCSI stick needs to be configured. Escape terminates the startup and an unconfigured desktop starts. It would be 0 if there is only the one stick.

*co. FileSystem SCSI
*co. SCSIFSDrive n

Just to confirm there is no need to have anything other than the five files on the FAT SD card. That card can be read and written to in the Mac, the RISC OS formatted boot pen cannot.

I can’t see my Mac or my NAS.

It is what it is, neither LanManFS or LanMan98 can see Apple’s samba. I have also seen reports that they fail with some makes of NAS. I used ShareFS to VRPC on the Mac which outperforms the Pi but is not without its entaining little foibles. VRPC on the Mac does support 2560×1440 in fullscreen mode but full screen mode is one of those foibles, 2560×1280 in a window is good although only at 32k colours.

HTH.

As a boot disc it would need to have been formatted as SCSI which the Mac would know nothing about.

I understand that. That part didn’t surprise me. What did surprise me slightly was that later, after I’d given up trying to use it as a boot drive (it worked fine as a SCSI drive on the Pi after being unplugged and plugged back in), I reformatted it FAT on the Mac, and then the Pi couldn’t see it although the Mac was perfectly happy with it.

*co. FileSystem SCSI
*co. SCSIFSDrive n

Yes, did that. But the stick wasn’t there at all as far as Pi was concerned – not until I unplugged it and plugged it back in. I’ve got the stick (SCSI) and a hard drive (FAT) on USB. The stick is SCSI::0 and the hard drive is SCSI::4 – I didn’t do anything to set them thus, it’s presumably a default somewhere.

Just to confirm there is no need to have anything other than the five files on the FAT SD card.

Not if you’ve got another drive to boot from, no, I understand that. But evidently no harm having !Boot on the FAT SD card, since that’s working perfectly well.

I don’t want to reformat the hard drive as SCSI (although that’s what RISC OS reports it as on the icon bar of course) because there’s a ton of stuff on it, and I can put that on the Mac and could potentially use it to transfer stuff between the systems (although email is usually less trouble unless I’ve got a huge amount to transfer). If I can format a memory stick in such a way that both Mac and Pi can use it (as this one used to be) then that would be good.

I can’t see my Mac or my NAS.
It is what it is

I was afraid that was probably the case. So be it.

Thanks anyway! :-)

I reformatted it FAT on the Mac, and then the Pi couldn’t see it although the Mac was perfectly happy with it.

To see a FAT stick or drive on the Pi Fat32FS is required which is not part of ROOL’s beta !Boot though it probably is in RCxx. It goes in PreDesk. OTOH SDFS can see the Fat32 SD card.

The stick is SCSI::0 and the hard drive is SCSI::4 – I didn’t do anything to set them thus, it’s presumably a default somewhere.

It is, 0 – 3 removable sticks, 4 – 7 fixed hard drives, except that a USB hard drive is not quite as fixed as all that.

A FAT drive cannot be booted from directly as the module required is itself in !Boot. To use such a disc as the main disc then !Boot on the SD card should be good, except it crashed when I tried it.

A FAT drive cannot be booted from directly as the module required is itself in !Boot.

Yes, I understood that. When I was trying to boot off it, it was formatted SCSI.

To use such a disc as the main disc then !Boot on the SD card should be good, except it crashed when I tried it.

It’s odd what works for one person and not for someone else, and vice-versa. That works for me absolutely fine, but putting !Boot on SCSI::0 doesn’t. I think the latter is possibly a hardware issue with my particular memory stick (?) but any of these things could be software differences if we’re using different nightly builds (?)

It’s odd what works for one person and not for someone else

It is almost as if our worlds are inverted relative to each other.

For the avoidance of typos this is what I have configured to boot from SCSI::0

*st. Filesystem
FileSystem SCSI
*st. SCSIFSDrive
SCSIFSDrive 0
*

Why !Boot on the FAT SD card crashed remains a mystery but I can’t delete things from that card either, so it is not just a boot issue. The crash is at offset B518 in DOSFS, now is that my fault for using an 8GB card. It’s not a real problem, booting SCSI is just fine, but it is a mystery and therefore has to be solved.

P.S. The items I can’t delete on the FAT SD Card under SDFS in the RPi3 aren’t anywhere to be seen on the Mac with the card plugged into the Mac’s card socket. Disk Utility on the Mac shows the capacity of the card to be 7.96GB, but used space is -12.22GB making the total available as 20.19GB. Wish I could do that with money!

*st. Filesystem
FileSystem SCSI
*st. SCSIFSDrive
SCSIFSDrive 0
*

Yup. That’s exactly what I had. The only problem was that so far as the Pi was concerned the memory stick wasn’t there until I unplugged it and plugged it back in. If I did that while it said it was waiting for the drive to be ready, it would boot. But I don’t want to have to unplug the stick and plug it back in every time!

My old SD card (with the 2013 R14 on it) is 4GB, but the new one’s 8GB (our local Wilko doesn’t sell anything smaller) – but it works fine.

Well – I say “fine” but if you edit a file on it on the Pi, it often leaves the unedited version and ignores the edits. You can close the file (in !Edit) and re-open it in !Edit, and it shows the edited version – but shut the machine down and restart, and it’s back to the old version. You can work round this by copying the file with a new name, and hey presto, the copy is the edited version. Then rename the old version to ****X or somesuch, rename the new version to the old name, and all is fine. Weird. Is this a !Edit error, or a file system error, or what? Doesn’t happen on the old card, with the old R14 image, and !Zap – but I’ve not dug deeper to investigate.

but is a mystery and therefore has to be solved.

Ah now. There’s a difference twixt thee and me. I like solving mysteries, but I’m prepared to leave them alone to get on with other things if they’re not actually interfering with what I’m trying to achieve! :-)

The only problem was that so far as the Pi was concerned the memory stick wasn’t there until I unplugged it and plugged it back in.

I don’t have that for a problem, the sticks are present immediately on power up.

I do now have !Boot running on SDFS, I reformatted the card with the Mac’s Disk Utility which did not show the size anomaly, but it is very slow.

While writing the HD4 disc image to the SD card a little red thermometer icon popped up near the top right of the screen. That’s a new one. I think I can guess what it meant!