It is the 1746th of March 2020 (aka the 10th of December 2024)
You are 18.97.9.171,
pleased to meet you!
mailto:blog-at-heyrick-dot-eu
RISC OS source mods - 2016
I posted a while back about RISC OS source code modifications. Well, as it has come time to build a new incarnation of RISC OS, I thought it might be a good idea to update the source code modifications for the current set of patches. So...
Turn off ZPP and use RISC OS the old-fashioned way
In the old days (anything before 2016), Page Zero and the processor vectors, and a shedload of kernel workspace was located at address &0. This was generally "okay" as writing to &0 was disallowed from RISC OS 3.5 onwards; so C programs that use uninitialised pointers couldn't do too much damage. Reading from this address was permitted.
Recently, in a bid to "improve system stability", it was decided that Page Zero and all the vectors would move to a high address, namely &FCxxxxxx and that the first 32K of the memory map would cease to exist. As some badly written software (yup, including some of mine! ☺) inadvertently read from this address (usually due to a pointer not being initialised, or being used after being NULLed), the application would crash. In response to this, the ZeroPain module was created. This allows (and logs) accesses to Page Zero and fakes certain behaviour that might be expected by badly written programs (such as directly reading MetroGnome instead of calling OS_ReadMonotonicTime).
While it is up to each individual to choose how they want their machine to operate, I prefer to do my development on a low vector system, given that using the DDE itself generates Pain. I have the ability to turn ZPP off, so I have chosen to do so.
Open the file ..xxx.BuildSys.Components.ROOL.xxx where 'xxx' (both times) is the one relative to your build, OMAP3, BCM2835, or whatever.
A little ways down in the file, you will see this:
Change this to specify HiProcVecs as FALSE. Note that this will probably be wrapped on your browser so it fits, the first line begins #Kernel and is a commented out version of the original (above). The second line begins "Kernel" and is the one the build process will be using.
As with the Kernel entry, the original FPEmulator entry is kept, but is prefixed '#' to comment it out. This is in case you want to build a ZPP version of RISC OS. Simply load this file, switch which entries are commented, and rebuild FPEmulator and the Kernel (and probably the HAL just in case), then make a new ROM.
RISC OS aborts, freezes, or otherwise dies horribly as it initialises? Ensure that FPEANCHOR=High is specified for the ZPP build, and that it is not for the Page Zero build. Getting FPEmulator out of sync with the kernel will cause system initialisation to fail.
Add CET/CEST to UK territory
Those of us living in Europe who are native English speakers might like to have European timezones supported without the stupid necessity of changing to another territory, as this is liable to carry the side effects of changing other settings (such as France using ',' as a decimal separator instead of thousands grouping like the anglophones) and may result in territory-aware programs speaking to you in the local language.
Fundamentally, the Territory system is horribly broken in numerous ways, but this isn't the time for that argument...
Here's how to add CET and CEST. For other anglophones (Japan, New Zealand, etc), feel free to replace CET and CEST with your own timezone names and offsets.
In the file ...castle.RiscOS.Sources.Internat.Territory.Module.s.UK, change line 55 from:
As previously described, the localtime() function uses the SWI Territory_ReadTimeZones to determine the current timezone offset from GMT. This was, unfortunately, the wrong call to make so will only ever return the offset of the first timezone in a multi-timezone setting. In other words, if you apply the above patch and select CET/CEST as your timezone, localtime() will just blindly go ahead and return values for GMT/BST.
I find it amusing that ROOL decide to implement ZPP which risks compatibility issues with (buggy) software that may never be updated again, yet something so obviously broken as this requires a bunch of regression tests to be performed on systems that aren't even capable of correctly dealing with timezones in user loaded territories. I have not (yet) performed such testing as I'm not entirely certain what I'm supposed to be testing... Anyway, we can do something about this:
Starting from line 257 of ...castle.RiscOS.Sources.Lib.RISC_OSLib.c.time, change:
territory = __locales[N_LC_TIME];
if (!territory) {
r.r[0] = -1; /* If C locale use current configured territory */
} else {
r.r[0] = TERRITORY_EXTRACT(territory);
r.r[1] = TERRITORY_TZ_EXTRACT(territory);
r.r[4] = TERRITORY_TZ_API_EXT; /* If not supported, never mind */
}
if (_kernel_swi(Territory_ReadTimeZones, &r, &r) == NULL) {
v = (dst == 0x8000) ? r.r[3] : r.r[2];
t += v / 100; /* centiseconds -> seconds */
}
to be:
territory = __locales[N_LC_TIME];
if ( !territory )
{
// If C locale, use the currently configured timezone
// of the currently configured territory
r.r[2] = 0; // make sure it does not say "ZONE"
_kernel_swi(Territory_ReadCurrentTimeZone, &r, &r); // ##TODO## Should check for errors! ;-)
t += (r.r[1] / 100); // centiseconds -> seconds
}
else
{
// Custom locale - work it out from the specified
// timezone and DST setting
r.r[0] = TERRITORY_EXTRACT(territory);
r.r[1] = TERRITORY_TZ_EXTRACT(territory);
r.r[4] = TERRITORY_TZ_API_EXT; /* If not supported, never mind */
if (_kernel_swi(Territory_ReadTimeZones, &r, &r) == NULL)
{
v = (dst == 0x8000) ? r.r[3] : r.r[2];
t += v / 100; /* centiseconds -> seconds */
}
}
Adjust-click on Switcher icon opens system configuration
In ...castle.RiscOS.Sources.Desktop.Switcher.s.Switcher, from line 4332, delete the code between click_select and power_click (checking for h_powerdown, h_shutdown, h_savedbox, h_switcher and iconbar_handle) and place the following code there instead:
click_select
LDR R0,[R1,#b_window]
CMP R0,#iconbar_whandle
BEQ openswitcher
BNE click_common
click_adjust
LDR R0,[R1,#b_window]
CMP R0,#iconbar_whandle
BEQ goconfig
; it's not a click on the iconbar icon so try our windows
; for this we treat select and adjust click the same
click_common
LDR R14,h_powerdown ; was it the power down dialogue
TEQ R0,R14
BEQ power_click
LDR R14,h_shutdown ; click in restart dialogue?
TEQ R0,R14
BEQ restart
LDR R14,h_savedbox
TEQ R0,R14
BEQ dbox_click
LDR R14,h_switcher ; click in task window?
TEQ R0,R14 ; no => assume iconbar icon
BEQ switcher_click
Pull "PC" ; ignore it if none of these
Original hack by Rick Murray, optimised by Fred Graute.
Larger RAMdisc?
On more modern (PMP capable) versions of RISC OS, the RAMdisc is no longer limited to 128MiB. But note that attempting to allocate all memory to the RAMdisc is liable to mess up the machine - you'll see an error "Memory cannot be moved" and something may or may not crash. The memory that you were trying to allocate to the RAMdisc will... cease to exist. So be careful.
You can get the memory back if you have the DebugTools module, just enter the following command:
RemoveDA "RAM disc"
RAMFS will still be 'dead' (potentially moreso once you've deleted it's Dynamic Area!), but it's better than having hundreds of megabytes vanish. You'll still need to reboot, but at least your system now ought to be usable until you do so.
Run IIC at a decent speed
By default, RISC OS runs its IIC bus at 100kHz. This means approximately 12.5KiB/sec. This is early '80s tech. This is sloooow.
Given that the IIC bus runs at 3.3V, if you are using 3.3V hardware, then that hardware is going to be new enough that it'll run happily at the faster 400kHz speed (~50KiB/sec). Compatibility problems ought to be minimal since the Fast Mode was introduced in 1992 - that's twenty four years ago.
To do this on a RaspberryPi, go to ...mixed.RiscOS.Sources.HAL.BCM2836.s.IIC and change lines 54 and 55 from:
; IIC divider to give 100 kHz
IICDivider * 2496
to:
; IIC divider to give ~400 kHz
IICDivider * 624
For the OMAP3 hardware (Beagle boards), you will want to look at the relevant HAL code. OMAP3 sets the speed around line 127, though I've not looked to see what values are required.
You don't need to modify OMAP4 (Panda) hardware, it already runs at 400kHz.
You should leave Iyonix and IOMD hardware running at 100kHz. If any machine is likely to interface with old (slow) hardware, it's the RiscPC... moreso given that there is no hardware IIC controller on either device, it's all done by directly bashing two lines on the IOMD (RiscPC) and whatever the I/O chip in the Iyonix is - about as technically advanced as the original Archimedes!
FullHD sucks if you are recycling a normal analogue monitor
I'm sure it really shows off the Pi well to boot RISC OS in a FullHD 1920×1080 display. However the Pi works equally well with a generic analogue flat panel display via an HDMI to VGA adaptor. The only problem... it boots with ridiculously tiny text as the Pi knows the dimensions of your monitor, either by probing the EDID or it is hardwired into your CONFIG.TXT file...yet RISC OS is asking for a FullHD display. The Pi's GPU obligingly scales it down. It still looks horrible.
But we can fix that. Of course we can.
Go to ...mixed.RiscOS.Sources.Video.HWSupport.BCMVideo.Resources.RPIMon. This is the "default" built-in MDF.
You'll see a list of modes being defined. 1080P basic, then 720P basic. After those, insert your own mode. The Pi's GPU generates its own timings, so you set all of these to zero and basically just fill in the pixel rate and the screen dimensions. To work out the appropriate pixel rate for a given screen frequency, add 32 to the horizontal size, then multiply by the frequency that you want. It's a rough and ready way to do it, but it seems to get approximately correct values. The Pi does this by itself anyway, I just think it would be useful for RISC OS to be think it's using the same sort of frame rate to what is actually being used!
Armed with this information, after the two HD definitions, add your own, like this, change the numbers as necessary:
# Mode: 1280x1024 at 75Hz
startmode
mode_name:1280 x 1024
x_res:1280
y_res:1024
pixel_rate:98400
h_timings:0,0,0,1280,0,0
v_timings:0,0,0,1024,0,0
sync_pol:0
endmode
Now to tell RISC OS to actually use this mode. Open ...mixed.RiscOS.Sources.Video.HWSupport.BCMVideo.s.BCMVideo and around line 348, you will see a little block of data labelled startupmode. Amend this to match the mode that you have just defined in the MDF, like this:
Even if your machine boots at the resolution of your display, the BootFX module (that does the pretty intro) doesn't pay attention to it. So let's tweak that too. Though, note, this is optional and purely a visual thing.
The default image is 1920×1080. It should be possible to change this, but when I tried it made the thing crashy. As it didn't seem terribly important (it just appears a bit squished), I never looked to see what was going on.
If you want to play, it is a JPEG file at ...bsd.RiscOS.Sources.Video.UserI.BootFX.Resources.Raspberry.UK.1920x1080.
Of more importance is the placement of the bars and text window are wrong. This, I'm afraid, you will have to determine by trial and error by building a softload version of the module, loading it, and calling the commands to get the bar and window to appear on-screen.
Around line 201 of ...bsd.RiscOS.Sources.Video.UserI.BootFX.c.bootfx, you will see this:
The default Next slot is 640KiB. While this can be changed by using some commands at runtime, since we're messing with the source we might as well allow for a Next slot that reflects 21st century use and means we can run a compile in a TaskWindow without fiddling stuff in Switcher.
At the end of ...castle.RiscOS.Sources.Desktop.Wimp.Options.s.!Default, you will see the line to tweak. I suggest the following:
You don't need to perform a full build of RISC OS after making these modifications. Simply double-click on the relevant MkClean, then MkExport, then MkROM files (in that order).
Then, when you're done, simply use !Builder to perform the Install ROM and Join ROM phases. On an original Pi with slow media, it takes about eight minutes to run the Install phase, and about fifteen seconds to Join the ROM.
The final touch
Once you have copied the ROM image (as RISCOS/IMG) into the $.!Boot.Loader directory, you should know that all your CMOS RAM settings have been trashed, because they're written into the ROM image.
But this is fixable. The SDCMOS file writes the settings to the RISCOS/IMG file, so run !Boot and then work your way clicking into each screenful of options, then clicking the Set button to write the options.
Once you've done that, reboot (shutdown properly, don't hit Ctrl-Break or press the reset button) and your options should be preserved.
Your comments:
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.