GitLab

Historically many commands of BBC Micro heritage were not included
in UitilyModules, but were separated out into a separate pseudo-module,
SysCommsModule, to allow for them to be terminated by any non-letter
for compatibility with the BBC Micro.

However with the introduction of `Oscli_HashedCommands` in August 1999
(and earlier in Ursula branch) this was broken except for *FX, *KEY,
*OPT and *TV, which are handled by a special case making SysCommsModule
redundant.

SysCommsModule is an obsitcle to making the kernel assemble to relocatable
AOF as it requires Module_BaseAddr to have 2 different values and therefore
be a absolute varaible instead of a section relative symbol.

This commit does not change behaviour with `Oscli_HashedCommands` enabled
which is the default, except for listing the command under UtilityModule
in *Help output. Which `Oscli_HashedCommands` disable this change removes
the special behaviour.

Version 6.53. Tagged as 'Kernel-6_53'

Currently RISCOS_AccessPhysicalAddress allows the caller to specify the
permissions/properties of the mapped memory by directly specifying some
of the L1 page table entry flags. This will complicate things when
adding support for more page table formats, so change it so that
standard RISC OS page flags are used instead (like the alternate entry
point, RISCOS_AccessPhysicalAddressUnchecked, already uses).

Also, drop the "RISCOS_" prefix from RISCOS_AccessPhysicalAddress and
RISCOS_ReleasePhysicalAddress, and remove the references to these
routines from the HAL docs. These routines have never been exposed to
the HAL, so renaming them and removing them from the docs should make
their status clearer.

Version 6.52. Tagged as 'Kernel-6_52'

Somewhere along the way, BangCam became redundant. Get rid of it.

RISCOS_LogToPhys and OS_Memory 20 (compatibility page) changed to use
suitable subroutines for reading the page tables instead of accessing
them directly.

Change the DecodeL1/L2Entry routines so that instead of accepting a page
table entry as input, they accept a (suitable-aligned) logical address
and fetch the page table entry themselves. This helps insulate the
calling code from the finer details of the page table format.

GetPageFlagsForR0IntoR6 & MoveCAMatR0toR3 changed to use
logical_to_physical & physical_to_ppn, to reduce the number of routines
which are performing direct page table access.

Reduce the number of routines which directly examine the page tables, by
changing OS_FindMemMapEntries to use logical_to_physical.

In preparation for the addition of long descriptor page table support,
start moving low-level page table routines into their own file
(s.ShortDesc) so that we can add a corresponding long descriptor
implementation in the future.

* logical_to_physical, MakePageTablesCacheable,
MakePageTablesNonCacheable, AllocateBackingLevel2, AMB_movepagesin_L2PT,
AMB_movecacheablepagesout_L2PT, AMB_moveuncacheablepagesout_L2PT
routines, and PageNumToL2PT macros, all moved to s.ShortDesc with no
changes.
* Add new UpdateL1PTForPageReplacement routine (by splitting some code
out of s.ChangeDyn)

ppn_to_physical, logical_to_physical, physical_to_ppn & ppn_to_physical
have now all been changed to accept/receive 64bit physical addresses in
R8,R9 instead of a 32bit address in R5. However, where a phys addr is
being provided as an input, they may currently only pay attention to the
bottom 32 bits of the address.

OS_EvaluateExpression is documented as applying GSTrans to any strings
within the expression, but did instead GSTrans the entire expression.

This would result in a sequence such as:

    *Set Alias$@RunType_FD1 "Basic -quit ""%0"" %*1"
    *If "<Alias$@RunType_FD1>"="" Then Set Alias$@RunType_FD1 @RunType_FFB %*0

raising a "Unknown operand" error as the quote in the variable
were interpreted as expression syntax. See
https://www.riscosopen.org/forum/forums/5/topics/16127

Unfortunately skipping the initial GSTrans breaks common code such as:

    If "<StrED_cfg$Dir>" = "" AND <Ctrl$Pressed> = 0 Then ...
    If "<Zap$OSVsn>" <> "" Then SetEval ZapFonts$OSVsn <Zap$OSVsn>

Fix by applying a GSTrans transformation over unquoted parts of the
expression, then applying GSTrans over the quoted strings.

Version 6.51. Tagged as 'Kernel-6_51'

    *BASIC
    *SetMacro Macro Test
    SYS "OS_GSTrans", """<Macro>""", &10000, &100

Would result in an erroneous "String not recognised" error as the
end of macro variable was reached before closing quote.
Fix by reordering the checks.

It's the only privileged-mode stack which doesn't have its address
exposed via OS_ReadSysInfo 6. Expose it so that software which wants to
know its address can read it instead of relying on hardcoded values.

Tested on Raspberry Pi 4

Version 6.50. Tagged as 'Kernel-6_50'

The correct amount of space is now reserved for Kbuffs, and there's no
need to have a 1MB gap where the old PhysicalAccess window was.

Tested on Raspberry Pi 4

Although storage maps are useful for allowing the fixed areas of the
memory map to be relocated, it isn't clear in the current definition
what the size of each area is, and it's hard to ensure that all the
areas are kept at the correct alignment.

Replace the current basic workspace definition with one which makes use
of the new ASpace macro, to allow addresses to be calculated
automatically based on the size & alignment of each area. Also output
the address of each area in the build log for easy
debugging/verification.

Binary unchanged.

This ensures that the debug macros may be freeley placed without
concern for if LR and CPSR contain important values, and avoid the
of code only working because the debug code changes the flags with
the effect of a bug appearing when debugging is enabled.

Version 6.49. Tagged as 'Kernel-6_49'

Previously the supervisor stack was read-only in user mode, but since
the supervisor stack is typically empty when the CPU is in user mode,
it's questionable whether any software actually makes use of this
facility.

To simplify support for the long descriptor page table format (which
doesn't support the user-RO + privileged-RW access mode), let's
try and remove usermode SVC stack access completely.

Tested on Raspberry Pi 4

Version 6.48. Tagged as 'Kernel-6_48'

Change ZeroPage calculation so that ZeroPage can be at
any 64K aligned address.


Version 6.47. Not tagged

Check now works if ROMLimit is precisely at the end
of ROM causing ROMLimit to not be a valid immediate.

Move ROM constant to KernelWS with the reset of the memory layout.
Add ASSERT to guard against workspace colliding with ROM.

Rather than specifing absolute addresses for the workspace,
use ObjASM's storage layout support.

In HandleServiceModeTranslation, make sure WsPtr is initialised
correctly before trying to use it. Fixes system heap corruption when
responding to Service_ModeTranslation (most likely overwriting part of
ChocolateMABlocks, and causing a crash when loading future modules)

Fixes issue reported on forums:
https://www.riscosopen.org/forum/forums/11/topics/15973

Version 6.47. Tagged as 'Kernel-6_47'

Detail:
RamFS now supports disc sizes up to 2GB-4KB, so raise the dynamic area limit from 508MB.

Admin:
Tested with a disc size up to 928MB

Version 6.46. Tagged as 'Kernel-6_46'

Changes in Kernel-6_44 left an undefined symbol in s.HAL in DebugTerminal_Rdch. These mods resolve that, and also add a note in s.Kernel to reflect this usage.

Version 6.45. Tagged as 'Kernel-6_45'

Previously both `RdchInkey` and `PageTest` enabled interrupts after
running callbacks before calling Portable_Idle with the result that
callback could be delayed until the next interrupt.

* Change `process_callback_chain` to leave interrupts disabled, and
  rename accordingly.
* Remove redundant check of CallBack_Flag.
* In `PageTest` move running calbacks into `CtrlShiftTest`, so that
  it is immediately before the test.
* Re-enable interrupts at appropriate locations.

Tested on StrongARM Risc PC.

Version 6.44. Tagged as 'Kernel-6_44'

This was introduced on 2002-10-07 in Kernel-5_35-4_79_2_48
the removed on 2002-11-30 in Kernel-5_35-4_79_2_51 as it
was "liable to crash".

Version 6.43. Not tagged

Multiple fixes, mostly related to error handling.

1. Ensure R1 is initialised correctly when generating BadPageNumber
errors (labels 94 & 95). Generally this involves setting it to zero to
indicate that no call to LogOp_MapOut is required. Failing to do this
would typically result in a crash.
2. When branching back to the start of the loop after calling
GetNonReservedPage, ensure R0 is reset to zero. Failing to do this would
have a performance impact on LogOp_MapOut, but shouldn't be fatal.
3. In the main routine, postpone writing back DANode_Size until after
the call to physical_to_ppn (because we may decide to abort the op
and return an error without moving a page).
4. Fix stack offset when accessing PMPLogOp_GlobalTBLFlushNeeded.
Getting this wrong could potentially result in some TLB maintenance
being skipped when moving uncacheable pages.
5. Fix stack imbalance at label 94

Version 6.43. Tagged as 'Kernel-6_43'

Move .gitignore file to root and populate with all temporary paths.
This fixes .gitignore files being deleted during a ROM build.


Version 6.42. Not tagged

This ensures that on exit from OS_ReadC / INKEY either
a character is returned or the input buffer is empty,
and that Portable_Idle is only called when the input
buffer is empty.

This avoids a 10 microsecond delay and relying on timer
interrupts to make progress and allows reliably waiting
for input and another event by:

Disable Interrupts
Repeat
  Call INKEY(0), exit loop if key pressed
  Check other event, exit loop if key pressed
  Call Portable_Idle

Version 6.42. Tagged as 'Kernel-6_42'

The current OS_Memory 7 implementation uses an address range structure
returned by HAL_PhysInfo to decide which part of the physical address
arrangement table to overwrite with RAM information. I suspect the
original intention was for OS_Memory to use this address range to avoid
marking the VRAM as DRAM (HAL_PhysInfo is expected to fill in the VRAM
itself). But by overwriting everything between the start and the end
address, OS_Memory will also overwrite any non-RAM areas which are
sandwiched between RAM banks, e.g. the VideoCore-owned RAM on Pi models
with >1GB RAM. There's also the problem that the address range returned
by the HAL is using 32bit addresses, so it won't work as-is for RAM
located above the 4GB barrier.

Fix these issues by reworking the routine so that it ignores the address
range returned by the HAL and instead detects VRAM by checking the
IsVRAM flag in the PhysRamTable entry. And for detecting if the ROM is
running from RAM, instead of using the address range we can rely on the
flag available via OS_ReadSysInfo 8 (i.e. HAL_PlatformInfo), like
OS_Memory 8 does.

Also add a simple BASIC program (Dev.PhysInfo) to allow easy checking of
HAL & OS physical address arrangement tables.

Version 6.41. Tagged as 'Kernel-6_41'

Fix GrowFreePoolFromAppSpace (i.e. appspace shrink operation) to issue
UpCall_MemoryMoving / Service_Memory when attempting to shrink PMP-based
appspace (i.e. AMBControl nodes). This fixes (e.g.) BASIC getting stuck
in an abort loop if you try and use OS_ChangeDynamicArea to grow the
free pool.

Version 6.40. Tagged as 'Kernel-6_40'

Fix AreaGrow to read appspace size correctly when appspace is a PMP
(i.e. an AMBControl node). Reading DANode_Size will only report the
amount of memory currently paged in (e.g. by lazy task swapping),
causing AreaGrow to underestimate how much it can potentially take from
the area.

Buggy since its introduction in Kernel-5_35-4_79_2_284, GrowFreePool was
attempting to grow the free pool by shrinking application space, an
operation which OS_ChangeDynamicArea doesn't support. Change it to grow
the free pool instead, and fix a couple of other issues that would have
caused it to work incorrectly (register corruption causing it to request
a size change of zero, and incorrect assumption that
OS_ChangeDynamicArea returns the amount unmoved, when really it returns
the amount moved)

When a DA tries to grow by more than the free pool size, the kernel
should try to take the necessary remaining amount from application
space. Historically this was handled as a combined "take from freepool
and appspace" operation, but with Kernel-5_35-4_79_2_284 this was
changed to use a nested call to OS_ChangeDynamicArea, so first appspace
is shrunk into the free pool and then the target DA is grown using just
the free pool.

However the code was foolishly trying to use ChangeDyn_AplSpace as the
argument to OS_ChangeDynamicArea, which that call doesn't recognise as a
valid DA number. Change it to use ChangeDyn_FreePool ("grow free pool
from appspace"), and also fix up a stack imbalance that would have
caused it to misbehave regardless of the outcome.

TryToShrinkShrinkables_Bytes expected both R1 and R2 to be byte counts,
but AreaGrow was calling with R1 as a byte count and R2 as a page count.
This would have caused it to request the first-found shrinkable to
shrink more than necessary, and also confuse the rest of AreaGrow when
the page-based R2 result of TryToShrinkShrinkables gets converted to a
byte count (when AreaGrow wants it as a page count)

Update AreaShrink so that (when shrinking appspace) CheckAppSpace is
passed the change amount as a negative number, so that Service_Memory is
issued with the correct sign.

Fixes issue reported on the forums, where BASIC was getting confused
because appspace shrinks were being reported as if they were a grow
operation:

https://www.riscosopen.org/forum/forums/4/topics/15067

It looks like this bug was introduced in Kernel-5_35-4_79_2_284
(introduction of PMPs), where the logic for appspace shrinks (which must
be performed via a grow of the free pool or some other DA) were moved
out of AreaGrow and into AreaShrink (because appspace shrinks are now
internally treated as "shrink appspace into free pool")

Despite never being properly documented in the RISC OS PRMs, there's
evidence that Acorn were recommending that third-parties used OS_Byte
166 for locating the OS_Byte variables well into the mid-1990's:

https://www.riscosopen.org/forum/forums/5/topics/14676#posts-94080

Currently OS builds which use zero page relocation will only return the
low 16 bits of the address from OS_Byte 166, most likely breaking any
third-party software which is trying to use it. Attempt to restore
compatibility by having OS_Byte 166 add the missing high address bits
into the "next location" value returned in R2, and fix OS_Byte 167 in a
similar manner (adding into R1).

Additionally, make the values read-only, because the kernel is littered
with code that uses hard-coded OsbyteVars addresses and so is unlikely
to do anything sensible if someone was to modify the OsbyteVars address
that's stored in workspace.

Version 6.39. Tagged as 'Kernel-6_39'

* Create new header file defining symbolic name for OS_AMBControl
  reason codes and flags
* Implement OS_AMBControl 9 (used to determine required size of buffer
  passed to OS_AMBControl 8 - potential thread safety issue not addressed)
* Return allocated error numbers in various failure cases

Version 6.38. Tagged as 'Kernel-6_38'