Ovation - this time it'll work :-)
One of the oddities that has come to light with the use of ancient code on modern systems is that things can go a bit screwy with the memory pointers with really big addresses. You see, back in the Mesolithic, the ARM processor could only address a maximum of 64MiB of RAM. Memory was scary-expensive back then - one of the things that killed the ARX project, other than perpetual lateness, is that it required a lot of memory. I have a scan of Acorn's Retail Price List, September 1989 which lists an Archimdes A440/1 as coming in at a mere £2499 (without monitor).
By contrast, my first RISC OS computer was an A3000, which retailed for £744.10. It had no harddisc and only 1MiB RAM, but it could run RISC OS. And Ovation.
Unbelievably, the Master 128 was still on sale, a snip at £503.35. Yeah, going for the ARM machine makes a lot more sense!
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.
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.
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
[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
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!
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! ☺
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.
|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
Japanese Red Cross
Earthquake relief donations have closed.
Read about the JRC
Make a general donation
List all b.log entries
Return to the site index
Last read at 05:28 on 2017/11/18.
© 2015 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.