Rick's b.log - 2015/11/07
It is the 21st of November 2024 You are 3.15.203.246, pleased to meet you!

Ovation - this time it'll work :-)

Anyway. Point is, the addressing range of the machine was from &0 to &3FFFFFF. As such, it was perfectly fine to manipulate pointers with any old 32 bit integer. In fact, the memory mapping was a bit mental. Each MEMC (MEMory Controller chip) could address 4MiB of memory. You could daisy-chain up to four of these (with varying degrees of success!) to provide up to 16MiB of memory. This was the maximum possible.
Well, the first 32MiB was the logically mapped RAM. The next 16MiB was the physical RAM. Following that was the hardware area containing I/O, video, the OS ROMs, and the Logical-to-Physical address translation hardware - which was communicated with by encoding information into the address lines of accesses to that area.
Both logical and physical memory was available at the same time within the same "view" of memory. The logical one changed all the time (every app believes it starts at &8000), but the physical didn't. The MEMC was... interesting, to say the least...

Fast forward a few years, the RiscPC came along. This was an interesting bodge of an old environment on a new processor. The processor was capable of addressing 4GiB, but RISC OS remained firmly in the 26 bit realm. This raised some issues, such as the maximum size that an application's slot could be. It also threw up some awkward problems when the machine started to take a speed hit due to paging in and out big application slots. A variety of workarounds were devised to work around these limitations, and one of them was the idea of Dynamic Areas. Now on the face of it, a Dynamic Area is not bad. It is a non-swapped piece of memory that is mapped in and available for an application to use. Sort of like the old fashioned "claim a bit of the RMA" for when you needed somewhere that was not paged out on task changes. Instant speed gain - an application could just pass off its data to a Dynamic Area and it itself could be small.
Problem was, Acorn specified that a DA should give a maximum size at the start (something which may not always be known in advance) and they permitted the value -1 to represent "all available memory". Again, this was no big deal. You'd likely struggle to get more than 128MiB in a RiscPC. Something between 8 and 32MiB was typical, and anyway there was so much logical addressing space that it was silly.

Fast forward a few years. The 26 bit modes (64MiB PC and flags rolled together) does not exist any more. The PC is completely 32 bit (separate flags), and typical memory sizes range from 256MiB to 2GiB.
Oh.
Crap.

Suddenly the old logic dies where it stands. Memory mapping must by necessity change. Big work has been going on with RISC OS 5 so that the machine can cope with big amounts of memory; you can't have a logical map larger than physical RAM when your physical RAM is half of the addressing capacity of the processor. The legacy ways have been thrown away. Dynamic Areas may be allocated in a mapping that is over a 2GiB boundary, and requesting to be allocated "all free memory" is a horrible idea. Acorn had the right idea with Dynamic Areas, it was just an awful half-assed implementation (somewhat akin to the many Wimp bodges that rely on specific version numbers instead of defining a flags word in the beginning....but then sticking in the magic word "TASK" is a bodge so damn old it is practically a fossil).
Today? Today we're paying the price.
Oh.
Crap.

What's so special about the 2GiB boundary? That is the boundary between the Near Shore (the living world) and the Far Shore (the spirit world). Well, not exactly. But it might as well be. The value &7FFFFFFF is the decimal number 2,147,483,647. If you add one, this makes &80000000 which is the decimal number -2,147,483,648.
Did you notice the minus prefix? A signed integer treats the most significant bit as a flag indicating negativity, and it counts backwards towards zero, such that the value &FFFFFFFF is the decimal integer -1.
Suddenly memory addressing that didn't suffer any problems at all can become hideously unstuck.

This is exactly what happened to Ovation. A combination of selfishly trying to claim "all available memory" as a potential maximum for its Dynamic Area plus an inability to cope with addresses over 2GiB.

With this in mind, I have modified Ovation such that it will continue to use the Dynamic Area on older class hardware (RISC OS 3.xx and 4.xx). Newer hardware (RISC OS 5.xx and RISC OS SIX under emulation) will revert to using application space. Task paging is better handled, the Pi's processor is like 17× faster in raw speed (moreso in instruction throughput) than an ARM710, the Beagles and Pandas faster still. Plus RISC OS 5 doesn't limit the application slot size (unless you're running Aemulor).

There have been some other modifications. So please allow me to present the all new Ovation v1.51RM:

2015/11/07 v1.51RM *released*

* Version suffix changed to "RM" so you know who to blame. ;-)

* Changed the copyright line in Templates to "(c) APDL and ProAction 2001" to
  match that shown in Raik's picture. This is because my Templates said
  Beebug, and that's only fifteen years out of date...
  
* Ovation doesn't support draggable slots, so why was its memory bar being
  shown in red? It no longer blindly Acks the message so the memory bar is
  green like it ought to be.
  
* Got rid of the dumb crash message that said "Save all open documents with
  new names!, and start Ovation again.". The app is dying, there is no
  possibility of saving anything.
  Now it says "Please report this bug so it can be fixed!".

* The curse of the Type5 on loading certain documents (most likely those
  with linked text frames) seems to come down to signed integer calculations
  with Dynamic Areas that cross the 2GiB boundary. That's when it all goes
  bang. Additionally, the DA is created with the maximum size being specified
  as "all available memory" which might have been reasonable when you may have
  had up to 128MiB installed, but on a machine with a GiB, it can be really
  unfriendly to the logical memory mapping.
  As such, on RISC OS versions 5 or later, Ovation will revert to using the
  application WimpSlot for memory instead of a Dynamic Area.
  
* WimpSlot requirements revised to 576KiB as this is the minimum that Ovation
  will require when using application space for document data.
  
* The default font for new documents is now Trinity, instead of SwissB or
  Homerton (depending on what's in your !Fonts). It is more pleasant reading a
  serif font than a sans-serif one in *print* media, as a desktop publisher
  surely is.
  See: http://www.urbanfonts.com/blog/2013/02/serif-vs-sans-the-final-battle/
  [and plenty more on Google]

* Note - if you don't like my decision, or if you don't like Ovation's other
  defaults (page size, margins, etc); then set Ovation up as you would like it
  and then save a StyleSheet as ".Default". This will then be
  used as the default styles (including custom paragraph styles, if you like)
  for when Ovation is next loaded.

* Minor change so the menu "Modify frame...   Sh^M" and "Modify line...    Sh^M"
  (Object submenu) appears like that, instead of "Modify frame...me" and
  "Modify line....me".
  This was because Ovation pastes the applicable data into the menu structure,
  and the original menu text read "Modify text frame...", but this distinction
  is not actually made in the code (or the Messages file).

* "Ovation", the module "Ovation" (and the SWI chunk), and the various commands
  are now officially registered with ROOL. Only twenty six years late, eh?

Here are the all-important downloads:

• The application! (342KiB, zip) - unzip it, run it, enjoy it.
  (this should be a complete, self contained, version of Ovation; tested on my Pi...)

• The source code! (408KiB, zip) - this is one for the geeks.
  (note that this version of the source builds as a DDE application from a MakeFile; it is a bit different to David's original code)

One final thing - I have had an offer of improved sprites and tidied-up Templates - so there's that to look forward to. Yay!

Your comments:

Thai P O Grapher, 10th November 2015, 22:23

Re the serif v sans-serif comments, the article you linked to was quite interesting. Times Roman on the web looks messy, but good in print. Arial looks clean and modern (both on-screen and in print) but is hard to read.    There is a compromise. There are a few fonts around which are "semi-serif". Verdana is one. It was actually designed to be readable on-screen without anti-aliasing (which of course RISC OS has had for over 25 years). Windows has had proper anti-aliasing since XP, but it's only been "on by default" since Vista.    There's also Calibri, which is also a clean-looking semi-serif font. Looks good on-screen, but looks a lot better than Verdana when printed.    For web pages I tend to use Verdana for body text and Arial for headings. Printed, I like Garamond. It's like a nicer looking modernised version of Times Roman. It also uses less ink/toner than Times Roman.

Mike Buckland, 6th December 2015, 22:47

Great I am so glad that Ovation is going to be updated and should work on future machines like titanium