Pi4 cooling fan

I used that BASIC sample. The result is C03115. It shows in the Raspberry Pi tables as a pi4B 4gb, rev 1.5

Re: ScrHelp…

It gives “Object to big for group”.

I have the same Pi4B 4GB rev 5 C03115 … and ScrHelp v1.74 works fine here.

I have the same Pi4B 4GB rev 5 C03115 … and ScrHelp v1.74 works fine here.

I have the same version of ScrHelp.

So just for completeness, I tried rebooting the existing RO 5.28 version – problem persisted. Then I installed the 5.29 image from Jan-9-2024, and still got the same failure. While I don’t suppose it makes a difference, internet is standard (5.66), not ROD.

The Drawfile_Render call is in the screen redraw, and looks up various parameters of the screen size. I’m using 1024 × 760, 66Hz, 16 million colours. Could this make a difference? Just tried 1280×768, which still produces the error.

The only drawfile in the application is the template for displaying the results, so I guess it’s being extended (in memory?) and displayed.

I’m using 1024 × 760, 66Hz, 16 million colours. Could this make a difference?

I don’t think so: I think it’s complaining that one of the draw objects in the file is too big for the group that it’s in. So it’s something to do with the composition of the image.

I did add a bit of reporting to the code, and all I could see was that the in-memory object being rendered didn’t come close to overflowing the buffer.
I guess the additions to the drawfile, which are the various bits of text displayed, will depend on the system being reported on. Which doesn’t explain why it works for Martyn on what seems to be an identical system, and crashes for me.

Looking again, I see that there’s one error reported before the drawfile_render call. It’s error F7, with no explanation. However that error is also reported when the program runs successfully, on another rpi.

Reporter 2.72 (15 Aug 2020)     List              Thu 1st Feb 2024  19:39  

19:39:08.87 ** Clear ** from Menu
19:39:14.56 ** Error **
  Error  : &000000F7

  Message: RISC OS 5.29 (09 Jan 2024)
19:39:14.61 ** Error **
  Error  : &00020C06
  Message: Object size too big for group (location &1FF12C in file)

19:39:14.61 ** WimpError ** from ScrHelp
  Error  : &00000000
  Message: Object size too big for group (location &1FF12C in file)  (error at line 12310 ). Select 'OK' to continue.

19:39:16.90 ** Error **
  Error  : &00020C06
  Message: Object size too big for group (location &1FF12C in file) 

I edited the draw file. I ungrouped the main object, and ungrouped the object which held the long text at the bottom and enlarged it. The error changed to “Object size too big for file”. It does look as though it’s related to trying to replace text in the drawfile.

So it’s something to do with the composition of the image.

I tried dumping “BoatyMcBoatface” (sorry, first thing that came to mind) after just about every output string, but couldn’t get it to screw up on my Pi2Bv1.

However, reverting to a fresh copy, I put this just before the call to DrawFile_Render:

x% = OPENOUT("$._testdraw")
SYS "OS_GBPB", 2, x%, bufmd%, ddEDraw%-bufmd%
CLOSE#x%

(note if you try this, it’s inside the redraw loop so be warned…)

This made a file that I settyped to &AFF and tossed at Draw.

Which refused to load the file, for the following reasons:

Bad character in string at location 16_FFA84
Bad character in string at location 16_FFCA8
Bad character in string at location 16_2FEC6C
Bad character in string at location 16_2FECC4

The first and second? Both a word set to &FF7D7D7D.
The second and third? Both a word set to &00000000.

I think pointers have gone astray.

I tried DrawPlus and it said “Draw error 106 at offset 3140831 in drawing: Data larger than object size” which is what the OP’s Draw module is saying, so…
That address, by the way, is &2FECDF, which is in a block of null bytes. So if it thinks there should be an object here, it’s declaring itself as all nulls and, yeah… oops. ;)

I think elsewhere a pointer has gotten a bit borked.
I’m not going to delve any further into this as I’m not familiar with the Draw format, but for anybody who is, the OS_GBPB stuff above will drop a file on disc that can be played with … and it is HUGE – the three images are 630×402 16M with mask, a megabyte each.

Just as a quick test, I extracted the three images, removed the mask, tossed them to ChangeFSI to make a 90% quality JPEG, and reimported them back into the “ScrnDrw” file with a scale of 0.35 which seemed “about right”. It didn’t work in the program (because, obviously, all the object offsets are different now), however the resultant file is something that ought to work on RISC OS 3.7 upwards and it’s only ~120K. Much more manageable!

Something that I did do was fix the iconbar icon. The app uses a solid background colour so it doesn’t look right (even moreso with Pinboard2’s partial transparency).

Line 29720 (DEFPROCbuildhollowicon):

!block%=-1:block%!20=&1700312B

Change this to be:

!block%=-1:block%!20=&1700310B

and the iconbar icon will no longer have a filled background and won’t look so naff. It’ll still look weird, given it seems to be modelling itself on the devices on the left while being an app on the right. <shrug>

I did add a bit of reporting to the code, and all I could see was that the in-memory object being rendered didn’t come close to overflowing the buffer.

No, not buffers. Draw groups. Either the specified memory sizes are wrong for the objects (IIRC grouped objects are nested within the group, so the group size offset must be more than the total of the child object size offsets all added together), or the physical coordinates on the page are wrong (the group object’s bounding box must encompass all of the bounding boxes of the children). I’m not familiar enough with the draw module’s error messages to be able to narrow it down without reading the PRMs to remind myself¹.

¹ And if I’m reading any PRMs this evening, it’s the section on sprites and sprite areas, I’m afraid. :-)

Alan, are you using an unusual MDF? If you are, can you mail it to me so I can try on my RPi4B?
I have a feeling the error is associated with modes.

The error was due to EDID decoding where a string longer than the space available was poked into a text draw object, overflowing into the next object.

As a stop gap, I have truncated the string before poking (at lines 8690 to 8710). Version 1.76 should solve this (and sort out the icon).

Careless of me!

The screen is set up to allow headless booting. The confix/txt is set to

[pi4]
enable_gic=1
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=18


The mdf selected is Acer AL2416, 1024×768.

VNC server is running.

If I boot with the monitor connected, ScrHelp crashes when opening the window.
If I boot with no monitor, and access using Avalanche, ScrHelp works.
If I then hotplug the monitor, and re-run ScrHelp, it crashes.

The monitor is an HP 1530. I don’t know how to see the EDID information.

Version 1.76 should solve this (and sort out the icon).

It does.

The truncated bit from the EDID has a5$ contains “1024 × 768 60Hz/72Hz/75Hz.” It’s displayed truncated after “72”.

The OS5.28 (10-Feb-22) ROM should be good to go an RPi4 rev5. A quick look here shows the GPIO module to be active….There is no actual fan on my RPi4 rev5 so this suggestion is not fully tested.

I can confirm that the 10-Feb-22 5.28 stable release ROM does allow an Armor lite heatsink/pwm fan combo to be switched on and off by CPUClock according to user temp settings. *Rommodules shows GPIO 1.00’s status as Active.