Windows must still work at a 640 × 480 resolution

Quote from !Paint thread in bounties:

ROOL made it clear that all the windows must still work at a 640 × 480 resolution.

This might seem unnecessarily small for modern monitors but there are two current use cases that need windows to work at low resolutions.
1. People with very poor eyesight,. We had one customer who couldn’t upgrade to RISC OS 4 because a number of programs they relied on couldn’t be used at the 440×320 resolution they had to use. In the end they’ve moved to a MAC :-(
2. Composite video monitor use. We’ve sold quite a few 3.5" and 4.3" PAL LCDs for use with Pi’s many running RISC OS. 640×480 is composite video’s limit.

Rather than try and squeeze everything into one window you can often split it up. RISC OS Six does that very effectively with !Configure → Windows

640×480 is composite video’s limit.

You can blame insular American exceptionalism for that fallacy.

The technical specification for NTSC is 720×525 at 29.97fps. Because of field flyback, blanking, sync (etc), some of the top of the frame is lost, leading to a maximum visible vertical resolution of 480 lines. Because of overscan, the visible horizontal resolution is somewhere around 650 pixels.
In essence, crappy NTSC gives you a visible area of approximately 640×480; this no doubt influenced the early video cards (base VGA, for instance), and has kept on lingering (such as YouTube’s generic 480P SD resolution).

PAL, on the other hand, is technically 720×625 at 25fps. If you do the maths, you’ll see the pixel clocking is much the same between PAL and NTSC. We lose around 5fps but gain about 20% of vertical display resolution – as visibly, PAL should be able to manage about 680×576, and on a modern display panel that doesn’t require overscan, maybe as far as 704×576 (a fair few DVDs are this frame size).

This might seem unnecessarily small for modern monitors but there are two current use cases

Embedded market too. Linux can’t work on Cortex-M processors. RISC OS could.

Linux can’t work on Cortex-M processors. RISC OS could.

Never seen an idea how to run RISC OS without an MMU. Or maybe ARM has redefined what the Cortex-M line is, again :-)

…no video, MMU optional, precious little memory…

https://en.m.wikipedia.org/wiki/STM32

…no video, MMU optional, precious little memory…

Can’t find a reference to an MMU anywhere in your linked doc.

Can’t find a reference to an MMU anywhere in your linked doc.

My mistake. I was looking at the Cortex-M series info for details of the M7 and I misread “Optional Memory Protection Unit (MPU)”.

Lesson: Don’t write forum posts while trying to push a trolley around a supermarket. ;-)

…no video, MMU optional, precious little memory…

That depends. Anyway, RISC OS 3 proved that we don’t need an MMU.
For a CLI only Basic system, memory needs should be low and graphic support isn’t necessary.

I really think that a subset of RISC OS (let’s call it MOS 5 :) ) could be very useful, and quite portable.
It could replace RISC OS Pico.

Anyway, RISC OS 3 proved that we don’t need an MMU.

Uh… You do understand how the Wimp swaps tasks and every task starts at &8000, right?

I think the last version of RISC OS that stood a chance of potentially running without some sort of MMU was Arthur – but since even the first Archimedes had an MEMC on board, plus an eccentric memory mapping with physical and logical RAM, even Arthur would have needed some way of mapping memory.
Why? Because the ARM starts executing at &0 which is the start of the ROMs. At least, until the memory is remapped and the ROM is pushed off to its higher (usual) position.
That’s how the later MMUs work. Reading the MEMC datasheet, it looks as if the MEMC hardwires ROMs to be visible from &0 until the machine performs a memory access with A24 and A25 low, then a memory access with A25 high. Basically, the first instruction should be an instruction to branch into the ROM space (from &3400000). It’s a bit of a hack, but it works.

That said, the MEMC mapping is such that:

&00000000
           Logically mapped RAM
&20000000
           Physically mapped RAM
&30000000
           I/O Space
&34000000
           ROM (read) / VIDC/MEMC/DMA (write)
&38000000
           ROM (read) / Address Translator (write)
&3FFFFFFF

It is arranged so that the physical memory (up to 16MiB) maps into the 32MiB of logical pages using a complicated method where the amount of memory installed changes the page size. Most software exists within the logical mapping, and in doing so the MEMC validates that you are allowed to access that memory, and then translating it to a piece of physical memory. Wimp multitasking works on the MEMC much like it does on later MMUs – all of the addresses normally visible to the system are logical addresses, and when it is time to page out a task and page in a different task, instead of wastefully moving memory around, the memory mapping is altered so the old task is pushed out of the way and the new task thinks it is based at &8000.
Note, however, that this behaviour will extend beyond the Desktop world. Other changeable areas of memory will behave in a similar sort of way – RAMdisc, RMA, Font cache… These have fixed allocations in the logical memory map (less so now with PMP), however physical memory is not assigned to them until it is required – and when it is required, OS_ChangeDynamicArea messes with the mapping so your 88MiB RAMdisc actually points to 88MiB of memory for it to use.

In short, the ability to shuffle memory around is fundamentally important to how RISC OS works.

For a CLI only Basic system, memory needs should be low and graphic support isn’t necessary.

You’d need to devise a new way of interacting with RISC OS. Serial terminal? Reducing it to that, you might fare just as well trying to put together a quick and dirty port of the MOS yourself.

I really think that a subset of RISC OS (let’s call it MOS 5 :) ) could be very useful, and quite portable. It could replace RISC OS Pico.

Sorry – I’m thinking it’s a waste of time. I’m not a big industrial customer, but if I was going to build something that required some intelligence, I would consider developing on a Pi and then installing a Pi Zero to actually run the code. I mean, price of a Pi Zero, pretty much undercuts most of the legitimate Cortex-M boards (note, legitimate, not Chinese knock-off).

…speaking of which, Pimoroni has the Pi Zero in stock, so since it was just pay day I decided to go for it. £4 for the Zero, £4 for a bunch of cables (cheaper if bought with a Pi Zero), and £4 postage to France. An easy £12 which PayPal translated to €15,84 using an exchange rate that makes them 50p on this. Still, probably less than the bank would have charged had I used a French card with an English company…

As part of trying to work out how the older machines started up, I’ve been eyeballing parts of the RISC OS 2 source code. Hehe…some interesting comments in places.
There probably wasn’t much love loss between the hardware guys and the software guys. I’ll clip the quote to protect the guilty:

; Nevertheless, until the time Acorn can afford to employ some REAL
; hardware engineers, I shall do a delay of (about) 16*8 S-cycles,
; just to put their small minds at rest.

        MOV     R0, #16*8/5             ; delay for an unspecified period
IrqRxDelayLoop
        SUBS    R0, R0, #1              ; this breaks my heart,
        BNE     IrqRxDelayLoop          ; it really does !

ROFL

Uh… You do understand how the Wimp swaps tasks and every task starts at &8000, right?

OK OK :)
“Don’t really need an MMU”. I was thinking of memory protection.

Sorry – I’m thinking it’s a waste of time. I’m not a big industrial customer, but if I was going to build something that required some intelligence, I would consider developing on a Pi and then installing a Pi Zero to actually run the code. I mean, price of a Pi Zero, pretty much undercuts most of the legitimate Cortex-M boards (note, legitimate, not Chinese knock-off).

It’s a completely different market. Cortex-M micro-controllers cost only a few euro, can be soldier directly on your own electronic board and can last on batteries for weeks or months. ARM biggest market in term of unit shipment is Cortex-M (44%), not Classic ARM7-11 (32%) or Cortex-A (18%). That’s a market, and Linux is not present on it. BSD is.

I don’t know anyway if it would be simple to make a more portable kernel with limited drivers (serial console, I/O), that could run from ROM (without copy to RAM), with CLI, Basic and Apps in ROM. And how much RAM it would need. Without filesystems, modules, caches, wimp, etc. It could be quite low.

A good first target would be STM32.

In short, the ability to shuffle memory around is fundamentally important to how RISC OS works.

And MOS too.

If you look at Cortex-M chips, you’ll see that while there is not a full MMU, there is still ways to remap and protect memory. So perhaps it’s possible… or not. The biggest limit, IMHO, is that Cortex-M are flash based components, with flash at the beginning of the memory map. So we would need more ways to save RAM and keep it for applications (32-64 KB most of the time, enough for 1 or 2 BBC Basic sessions).

On RISC OS 4, I have 32 KB of system workspace, 132 KB of System heap/stack, 32 KB of cursor/system/sound and 1400 KB of modules. I don’t know how much of these could be saved.

Without FS, GFX, Sound, Wimp and network, a lot of modules will disappear, as some system workspace/stack. In fact, almost no module is required. Should be needed: SharedCLibrary, ShellCLI, SerialDevice, ResourceFiler, Obey, IRQUtils, IIC, FPEmulator, Filer & FileCore (if needed for ResourceFS), DMAManager, DeviceFS, BufferManager (not really needed), Basic, BasicTrans, ARM, UtilityModule. Probably not a lot of flash, and not so much RAM space.

A Pi or RPCEmu could be a good solution to try to shrink RISC OS, for example for a new smaller RISC OS Pico that could be deployed on Compute Module, or a smaller SD Card-less device with only a few MB of Flash and less than 1 MB of memory. Probably the specs of future micro-controllers. Today, STM32-F7 can embed up to 2 MB of Flash and 512 KB of RAM. Almost enough.

Two good boards to start:
http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/9173775/
http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/8820278/

Cortex-M micro-controllers cost only a few euro, can be soldier directly on your own electronic board and can last on batteries for weeks or months. ARM biggest market in term of unit shipment is Cortex-M (44%), not Classic ARM7-11 (32%) or Cortex-A (18%). That’s a market, and Linux is not present on it.

But only if you ignore uClinux. Combined with BusyBox, it gives you a working minimal environment now – while RISC OS on a non-MMU system is still a wet dream. Alternatively, there are numerous real time OSes for Cortex-M available, both free and proprietary. It is difficult to see a niche for RISC OS here.

Hi Steffen. Good point, yes. uClinux could work on this hardware, but it does not yet :)

while RISC OS on a non-MMU

Not really non-MMU. All modern ARM processors have memory management, limited (PMU) or full (MMU).

It is difficult to see a niche for RISC OS here.

My point was that there is still a market here for RISC OS. And probably nowhere else unfortunately.

As you say, there are both free proprietary and free OS for Cortex-M. For desktop and server, there is one proprietary offer (Windows) and all the others must be free to succeed.

Anyway, it could be possible to do it. There is no obligation :)

It could be possible too to adapt RISC OS 5 for ARM2 and get support of the retrocomputing community (purists who avoid RISC OS 5, included this forum). But there is no obligation either :)

Just ideas…

uClinux could work on this hardware, but it does not yet :)

Don’t know what you mean. uClinux works just fine on various Cortex-M SoCs. Including STM32 variants. Now.

Ah sorry. This is not referenced on the official website. So I took a quick and wrong short cut :)

uClinux could work on this hardware, but it does not yet :)

Yes, it does. http://www.emcraft.com/

Note that, hardware permitting, it can also manage networking and framebuffer.

Not really non-MMU. All modern ARM processors have memory management, limited (PMU) or full (MMU).

You mean MPU (Memory Protection Unit).

And, no.

All ARM-A series processors contain an MMU (Memory Management Unit). This provides memory protection (is this task permitted to access this memory?) plus memory management for virtual memory, logical to physical address translation, and the associated remapping facilities that this implies.

Many (although it appears to be optional) ARM-M series processors contain an MPU. This provides memory protection (is this task permitted to access this memory?) and that’s it.

In terms of a crappy analogy: If an MMU is a car, an MPU is a bicycle.

My point was that there is still a market here for RISC OS.

I doubt it. The more that you strip from RISC OS, the less useful it becomes. To quote from your earlier message:

Without FS, GFX, Sound, Wimp and network, […] Filer & FileCore (if needed for ResourceFS),

I can understand getting rid of sound and Wimp; but you can destroy a lot of functionality by getting rid of networking and any sort of filesystem.

And probably nowhere else unfortunately.

Calling a SWI while in SVC mode without having stacked R14 will bring the machine down. I have done this – it is easy to oops forget. :-)

However how do you plan to fire a watchdog to reboot the machine? You can’t hook it to Wimp polling or it would risk firing as soon as you drop to the command line (or if indeed you don’t even have a Wimp) and you can’t hook it to CallEvery or TickerV as they are still working (a frozen machine still responds to mouse movements and pressing Caps Lock). Silly little things like that can become estremely important if your embedded device is switching kilowatt loads that heat and/or control motors.

It could be possible too to adapt RISC OS 5 for ARM2

In theory, yes. In practice, unlikely. The benefit of a RiscPC running RISC OS 5 is that most systems will have enough RAM installed to allow it to be softloaded. I’m not sure the MEMC is actually capable of supporting such behaviour, plus the majority of machines max out at a mere 4MiB. Development would likely require an EPROM emulator to replace the installed ROMS.
That’s not even starting to discuss the fact that the older ARM processors simply do not support any form of 32 bit operation. So in essence the result would be a slightly nicer looking version of RISC OS 3.
For the time likely to be invested in this (is is even possible to build a 26 bit version of RISC OS?), I can’t really see the point.

For desktop and server, there is one proprietary offer (Windows) and all the others must be free to succeed.

Hmm, there are others that people haven’t heard of. The process control systems at work run on embedded x86 based SoCs. And they run neither Windows nor Linux. A proprietary system aimed at doing exactly what is required.

For servers there are many propriertary offers and they succeed very well.
Remember there is no such thing as a Linux OS, it’s a Linux based OS.
MAC OS, RHEL, SLES (is it still called that), VMWare, AIX, HP-UX, z/OS as well as many, many others.
Windows as an operating system, I would guess is actually in the minority.
Not that it doesn’t do well, it does.

[ all off topic ;) ]

Remember there is no such thing as a Linux OS, it’s a Linux based OS.

Speaking of which, I’m currently installing Ubuntu 10.4 on my P4 machine. Got myself a SATA cable in town today, so I swapped out the floppy drive for the 80GB harddisc (hope the casing still closes!).
As a safety measure, I unplugged the XP drive. Can’t cock it up and format the wrong drive if is isn’t plugged in! ;-)

Mmm, downloading language packs. I hope it’ll speak British English and not be like stupid Google+ and decide the language based upon IP address (leading me to shove…what was it, &hl=en or something, into the URL to force English). Consequently I only deal with G+ when necessary for use with Yahoo.

I remember in the early ‘90s it was possible to boot to a command line version of Slackware off a CD-ROM on an old 486. However it was awful – the first chapter in the book didn’t bother to introduce Linux, it started with how to build your own kernel with loads of complicated instructions and you just know something was going to go wrong. The graphics card in the machine wasn’t supported. The S3 in my Presario wasn’t supported either. I think I finally managed to get X running in monochrome bare VGA long enough to put a dot pattern background and a crummy looking watch shape hourglass before everything went black on me and the machine obviously crashed (no drive activity).

In comparison, this installation seems to have been relatively painless. Tell it my keyboard, my WiFi password, which drive to nuke¹, and let it get on with it.

¹ Small comment – it should list the drive size somewhere. I have no friggin’ idea if it is sda or sdb or what. I know it’s the 80GB (less if using real gigabytes) drive. Okay, I can’t go wrong as I unplugged the other one, but still…

BTW – is there something like WinSCP for Ubuntu? Needs to be able to do SFTP with shared key login. And, of course, be pointy-clicky. My memories of the command line are MS-DOS and I’d like to keep them that way. ;-)

Standard filers/fs access tools usually support SCP/FTP/SFTP/whatever, e.g. Konqueror.

and that’s it.

Not really. I saw some messages on forums about people saying they have implemented memory relocation routines. How? That’s a good question, but the talk of the cut down MMU unit.

I can understand getting rid of sound and Wimp; but you can destroy a lot of functionality by getting rid of networking and any sort of filesystem.

On simple micro-controllers, most of the time, there is only one application, embedded with the OS. So no need for a filesystem (except perhaps resourcefs). Of course, if you want to add one, or networking, why not. The idea would be to have a better/complete interface to manage what you want to get in the kernel, what application you want to add (a la draw/edit), and a memory optimized build could be generated.

For the time likely to be invested in this (is is even possible to build a 26 bit version of RISC OS?), I can’t really see the point.

Let’s face it. With the number of users active on RISC OS today (from ROS3 to ROS5), I can see no point to still using it :( I can’t even find 20 or 30 people with ideas (just ideas, no need for code or complete projects. I accept even pies or funny things :) ) to give them a free Pi.

The process control systems at work run on embedded x86 based SoCs

I said: for desktop and server. Still at the supermarket? :)

The point of RISC OS from my point of view is: (1) !Draw – a better engineering/architecture drawing package than anything affordable on the Mac or PC, and will be even better when I get round to hooking it up to the 4K monitor; (2) BBC BASIC (& the embedded assembler) as a dead easy to use general purpose file manipulation tool.

I used to love Impression Pro Publisher Plus, but its files aren’t easily transferable to Mac (or PC), and Libre Office is fine for anything I’m doing now anyway. I used to love Acorn font & keyboard handling, and am still nostalgic about them, but I can live without them.

I used to love Impression Pro

Is this a hybrid software combining Impression Publisher and Ovation Pro :-)