Rick's b.log - 2016/03/26
You are 18.116.20.108, pleased to meet you!
|
Rick's b.log - 2016/03/26 |
| It is the 21st of November 2024 You are 18.116.20.108, pleased to meet you! |
|
mailto: blog -at- heyrick -dot- eu
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.
That again, in tiny text just so it's clear that this is only two lines:
Then a little further down you will see:
Change this to:
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.
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:
Then change from line 61 from:
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:
You can get the memory back if you have the DebugTools module, just enter the following command:
To do this on a RaspberryPi, go to ...mixed.RiscOS.Sources.HAL.BCM2836.s.IIC and change lines 54 and 55 from:
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.
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!
The calculation again:
Armed with this information, after the two HD definitions, add your own, like this, change the numbers as necessary:
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
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.
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:
Here are the settings that look good on a 1280x1024 display:
At the end of ...castle.RiscOS.Sources.Desktop.Wimp.Options.s.!Default, you will see the line to tweak. I suggest the following:
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.
Once you've done that, reboot (shutdown properly, don't hit Ctrl-Break or press the reset button) and your options should be preserved.
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.
Kernel -at 0xFFC010000 -options ASFLAGS="-PD \"CMOS_Override SETS \\\"= FileLangCMOS,fsnumber_SDFS,CDROMFSCMOS,&C0\\\"\""
#Kernel -at 0xFFC010000 -options ASFLAGS="-PD \"CMOS_Override SETS \\\"= FileLangCMOS,fsnumber_SDFS,CDROMFSCMOS,&C0\\\"\""
Kernel -at 0xFFC010000 -options ASFLAGS="-PD \"HiProcVecs SETL {FALSE}\" -PD \"CMOS_Override SETS \\\"= FileLangCMOS,fsnumber_SDFS,CDROMFSCMOS,&C0\\\"\""
#Kernel -at 0xFFC010000 -options ASFLAGS="-PD \"CMOS_Override SETS \\\"= FileLangCMOS,fsnumber_SDFS,CDROMFSCMOS,&C0\\\"\""
Kernel -at 0xFFC010000 -options ASFLAGS="-PD \"HiProcVecs SETL {FALSE}\" -PD \"CMOS_Override SETS \\\"= FileLangCMOS,fsnumber_SDFS,CDROMFSCMOS,&C0\\\"\""
FPEmulator -options FPE_APCS=3/32bit FPEANCHOR=High
#FPEmulator -options FPE_APCS=3/32bit FPEANCHOR=High
FPEmulator -options FPE_APCS=3/32bit
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...
MaxTZLength * 3 ; "GMT"
to:
MaxTZLength * 4 ; "CEST"
NumberOfTZ * 1
GBLS NODST0
NODST0 SETS "GMT"
GBLS DST0
DST0 SETS "BST"
NODSTOffset0 * 100*60*60*0 ; Zero hours
DSTOffset0 * 100*60*60*1
to:
NumberOfTZ * 2
GBLS NODST0
NODST0 SETS "GMT"
GBLS DST0
DST0 SETS "BST"
NODSTOffset0 * 100*60*60*0 ; Zero hours
DSTOffset0 * 100*60*60*1
GBLS NODST1
NODST1 SETS "CET"
GBLS DST1
DST1 SETS "CEST"
NODSTOffset1 * 100*60*60*1
DSTOffset1 * 100*60*60*2
Fix CLib's broken localtime()
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.
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.
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.
; IIC divider to give 100 kHz
IICDivider * 2496
to:
; IIC divider to give ~400 kHz
IICDivider * 624
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.
( screen_width + 32 ) * desired_refresh_rate
( 1280 + 32 ) * 75 = 98400
# 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
startupmode. Amend this to match the mode that you have just defined in the MDF, like this:
startupmode
DCD 1
DCD 1280
DCD 1024
DCD 5
DCD -1
DCD -1
Optional: Make BootFX tidier
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.
If you want to play, it is a JPEG file at ...bsd.RiscOS.Sources.Video.UserI.BootFX.Resources.Raspberry.UK.1920x1080.
#if (defined UserIF_Raspberry)
#define BAR_X (1280)
#define BAR_Y (786)
static tclip_t text_window = { 28, 80, 125, 159, 94 };
#else
#if (defined UserIF_Raspberry)
#define BAR_X (650)
#define BAR_Y (850)
static tclip_t text_window = { 28, 40, 110, 120, 76 };
#else
Bake in a better Next slot
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.
GBLA DefaultNextSlot
DefaultNextSlot SETA 4096*1024
Speedier building
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).
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.
No comments yet...
| © 2016 Rick Murray |
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. |