Display resolution on Pi

Small bug noticed

Many thanks. Version 1.02 now updated.

Your monitor has quite a few resolutions available, enough to exceed the 256 byte message size limit for !help messages (where the details are made available).

Supported mini list: 1024×768, 1280×720, 1920×1080i.

You need to look at !Help (from the Apps folder) which gives context-sensitive help: hover over each of the three in turn to get a full list of (i) 2-byte ‘low res’ modes; (ii) ‘standard display modes’ and (iii) the four most preferred detailed timing descriptors. There are other (optional) fields that I don’t (at present) decode like the EIA/CEA-861 extension block which give DTV formats.

Perhaps that info could/should be included in the ReadMe or !Help? The displayed message ‘This is for the rapsberry Pi’ is little help!

The interactive !Help gives a bit more information now.

Or…find which SWI is returning an error and fix the underlying issue.

Version 1.03 now flags any error from VCHIQ in R6 allowing the interactive !Help over the GPU output resolution text block (which then says something like ??? x ??? C16M) to indicate what went wrong and meant that the GPU output resolution could not be determined.

I am finding that after a dozen or so error-free clicks over the icon bar icon to refresh the window, VCHIQ initialises and connects but VCHIQ_ServiceOpen fails. After a reboot it starts working again.

As to solving the underlying issue, Err …

Still gives error ‘Memory cannot be moved’ after a shutdown/restart on a Pi with a real time clock widget fitted.

I’ve noticed the Firmware version also toggles between the date and nothing, so there’s possibly an issue in the firmware detection.

I have changed the method completely – it used

OSCLI("Info Boot:Loader.START/ELF { > Pipe:$.sysin }")
sys%=OPENIN("Pipe:$.sysin")
a9$=GET$#sys%
a9$="Firmware: "+MID$(a9$,41)
CLOSE#sys%

 4740hbf11%=hh%
 4750hh%+=20
 4760q$="The firmware version is obtained by examining the files Boot:Loader.START/ELF or MLO.|M"
 4770$hh%=q$
 4780hh%+=LEN(q$)
 4790SYS "XOS_GBPB",11,"Boot:Loader",binf%,70,0,1500,"START/ELF" TO ,,,nr%,fin% ; flag%
 4800IF fin%=-1 AND nr%=1 AND (flag% AND 1)=0 THEN
 4810  IF binf%!24=0 AND binf%?28=0 THEN
 4820    a9$="Firmware undated."
 4830    q$="START/ELF found but file is undated."
 4840    $hh%=q$
 4850    hh%?(LEN(q$)+1)=0
 4860    hh%+=LEN(q$)
 4870    hh%+=4-(hh% MOD 4)
 4880  ELSE
 4890    SYS "OS_ConvertDateAndTime",binf%+24,binf%+200,100,"%DY-%M3-%CE%YR"+CHR$0 TO ,qq%
 4900    ?qq%=13
 4910    binf%?38=13
 4920    a9$="Firmware: "+$(binf%+200)
 4930    q$="START/ELF found."
 4940    $hh%=q$
 4950    hh%?(LEN(q$)+1)=0
 4960    hh%+=LEN(q$)
 4970    hh%+=4-(hh% MOD 4)
 4980  ENDIF
 4990ELSE
 5000  SYS "XOS_GBPB",11,"Boot:Loader",binf%,70,0,1500,"MLO" TO ,,,nr%,fin% ; flag%
 5010  IF fin%=-1 AND nr%=1 AND (flag% AND 1)=0 THEN
 5020    IF binf%!24=0 AND binf%?28=0 THEN
 5030      a9$="MLO undated."
 5040      q$="START/ELF not found, MLO found but undated."
 5050      $hh%=q$
 5060      hh%?(LEN(q$)+1)=0
 5070      hh%+=LEN(q$)
 5080      hh%+=4-(hh% MOD 4)
 5090    ELSE
 5100      SYS "OS_ConvertDateAndTime",binf%+24,binf%+200,100,"%DY-%M3-%CE%YR"+CHR$0 TO ,qq%
 5110      ?qq%=13
 5120      binf%?38=13
 5130      a9$="MLO: "+$(binf%+200)
 5140      q$="START/ELF not found, MLO found."
 5150      $hh%=q$
 5160      hh%?(LEN(q$)+1)=0
 5170      hh%+=LEN(q$)
 5180      hh%+=4-(hh% MOD 4)
 5190    ENDIF
 5200  ELSE
 5210    a9$="No firmware found"
 5220    q$="Neither START/ELF nor MLO was found"
 5230    $hh%=q$
 5240    hh%?(LEN(q$)+1)=0
 5250    hh%+=LEN(q$)
 5260    hh%+=4-(hh% MOD 4)
 5270  ENDIF
 5280ENDIF

Version 1.05 uploaded.

It now recognises machines (i.e. non-Raspberry Pi or Raspberry Pi with firmware/ROM before April 2016) from their unique identifier (the manufacturer-specific bit of the MAC address) as well as from OS_Hardware. So far I have included:
B8-27-EB-xx-xx-xx – Raspberry Pi
2E-04-5F-xx-xx-xx – IGEPv5
00-C0-32-xx-xx-xx – Risc PC
00-09-95-xx-xx-xx – Iyonix
00-1F-7B-xx-xx-xx – i.MX6
70-B3-D5-xx-xx-xx – Titanium
02-95-xx-xx-xx-xx – Pandaboard
My sample size is limited so I’d like to know if there are versions of those boards which have a different manufacturer-specific MAC address than shown above.

The Beagleboard seems to return a unique ID from OS_ReadSysInfo that does not correspond to the MAC address and so that is not included. The help message over the board type explains what it found and gives the unique machine ID.

It also looks for firmware at Boot:Loader.START/ELF (for the Pi) and also at the following:
Boot:Loader.MLO (IGEPv5, Pandaboard, Beagleboard if booting from eMMC/SD card)
SDFS::4.$.!Boot.Loader.MLO (eMMc on IGEPv5)
SDFS::0.$.!Boot.Loader.MLO (SD card on IGEPv5, Pandaboard and Beagleboard)
before giving up.

Version 1.05 uploaded.

Error – Missing " at line 2430.

Used Zap to look at this as it preserves line numbers just like StrongED doesn’t..

Used Zap to look at this as it preserves line numbers just like StrongED doesn’t..

At the risk of opening up a can of worms again, if you’re editing a BASIC file you can use StrongED to chase down errors at given lines. If you set it to strip line numbers on loading and then re-save them from line 1 with an increment of 1, then any error reports using something like STR$ERL can then be tracked down using the Goto function (F5).

If you don’t fancy that, you can set the global option in StrongED not to strip the BASIC file’s own line numbers, and then manually scroll down to find it.

Can of worms: lid replaced.

Version 1.06 – bug squashed. Many thanks.

the manufacturer-specific bit of the MAC address […] so far I have included:
B8-27-EB-xx-xx-xx – Raspberry Pi
2E-04-5F-xx-xx-xx – IGEPv5
00-C0-32-xx-xx-xx – Risc PC
00-09-95-xx-xx-xx – Iyonix
00-1F-7B-xx-xx-xx – i.MX6
70-B3-D5-xx-xx-xx – Titanium
02-95-xx-xx-xx-xx – Pandaboard

Using an IEEE OUI is pretty nonsensical because it’s a weak relationship to the machine. For example, 00-C0-32 is the allocation for i-Cubed because presumably you have an i-Cubed NIC? Acorn’s allocation was 00-00-A4, but then they used that for machines from A3000 era onwards (including the Risc PC).

02-95-xx-xx-xx-xx can’t be valid, because OUI’s are 24 bit, unless there are 1 billion Pandaboards out there and they genuinely bought up all 64 MA-L ranges. 2E-04-5F is unregistered.

Using an IEEE OUI is pretty nonsensical

I agree it is a weak relationship and I hang my head with shame.

I have two Pandaboards and they have MAC addresses of 02-95-10-xx-xx-xx and 02-95-48-xx-xx-xx. Unfortunately the unique ID reported by OS_ReadSysInfo,2 bears no relationship to this (20-04-40-xx-xx-xx on the surviving machine).

Beagleboards are said to return a different unique ID each time they boot up.

My IGEPv5 returns 2E-04-5F-xx-xx-xx every time from OS_ReadSysInfo,2 but has a MAC of the form 02-98-4D-xx-xx-xx. So no joy there either.

Raspberry Pi return the MAC address via OS_ReadSysInfo,2 but with the bytes in the opposite order.

Risc PC (and other non-HAL Acorn machines) is moot as it is never recognised (by ScrHelp) by its unique ID anyway.

More thought needed…

Is there a defined relationship between unique machine ID (as returned by OS_ReadSysInfo,2) and MAC address? On some machines they are equivalent, whether low endian or high endian. On others they are not. The utility on spellings.net to read the machine’s MAC address just uses OS_ReadSysInfo,2 (and works on the Pi and Iyonix from which it needs this information).

Also what call does the internet stack use to read the MAC address (configure/network/internet/interfaces/status)? This might not help as the ‘status’ information was not available on earlier machines.

Using an IEEE OUI is pretty nonsensical because it’s a weak relationship to the machine.

But would it ever give a false result? The only possibility I can think of is if the manufacturer also made a supported USB network adaptor, and someone used that on a Pi Model A (etc.).

But would it ever give a false result?

Yes, unfortunately. Because I use OS_ReadSysInfo,2 to get the unique ID I ought to exclude several classes of machine first: Pandaboard and Beagleboard which return a random ID (not the MAC) for example. Also it would return the same code where a manufacturer makes an Ethernet adaptor fitted to more than one type of machine. There’s also no guarantee that the Pi (which returns the manufacturer-specific bit of the MAC in the low 24 bits) might be confused with another machine (that returns the manufacturer-specific bit in the high 24 bits, as expected) with a coincident serial number. Actually the Pi model A returns a unique ID in the same series as the ones with Ethernet and ignores the USB dongle MAC (for OS_ReadSysInfo purposes).

So it’s not perfect, it will only work for the first 16 million Raspberry Pis, but it seems to work.

Now updated to version 1.12 which now reads EDID data on non-Pi machines as well, with thanks for all the help I’ve received.

Using an IEEE OUI is pretty nonsensical because it’s a weak relationship to the machine. For example, 00-C0-32 is the allocation for i-Cubed because presumably you have an i-Cubed NIC? Acorn’s allocation was 00-00-A4, but then they used that for machines from A3000 era onwards (including the Risc PC).

02-95-xx-xx-xx-xx can’t be valid, because OUI’s are 24 bit, unless there are 1 billion Pandaboards out there and they genuinely bought up all 64 MA-L ranges. 2E-04-5F is unregistered.

Yes, I am only using the IEEE OUI now to identify:
B8-27-EB-xx-xx-xx – Raspberry Pi
00-09-95-xx-xx-xx – Iyonix (Castle Tech.)
00-1F-7B-xx-xx-xx – i.MX6 (TechNexion)
70-B3-D5-xx-xx-xx – Titanium (70-B3-D5-03-Fx-xx is Elesar Ltd)
and I have realised that
2E-04-5F-xx-xx-xx – IGEPv5 (MAC address 02-98-xx-xx-xx-xx)
xx-xx-xx-xx-xx-xx – Beagleboard/Pandaboard (MAC 02-xx-xx-xx-xx-xx)
are locally adminstered MAC addresses (bit 41 set) and bits 0 to 39 could be anything.