arm64

Well, you can, and he did. But don’t expect people to get on board.

Yep :)

there is no question of directly ever replacing the current RO in place.

… but to make a new 64-bit OS from scratch. Let’s call a cat a cat: if it’s new and not connected to the current RISC OS, where is the point? It’s RISC OS community here, not “another Linux clone” one.
Anyway, good luck with your project. Even if I have serious doubts with the Greenfield approach. It’s always better to reuse code than to rewrite it.

in this case ARM64 and no less

TBH if you wan’t “full control” and hardware and software with an innovative design, port Haiku to a RiscV platform.

To be more serious, to find a way to make 64-bit ARM code running under the current RISC OS would be fantastic (non breaking, and geeky). Not sure it’s possible anyway. Clive, Rick, Steve, all masters of ARM code, probably know :)

Another idea: to have a second core version of the BBC Basic interpreter.
This will attract a bunch of RISC OS users.

Hmm. I was a master of 26-bit ARM code, and wrote the manual for later versions up to v7 and understood it okay at the time. But I’ve never used 32-bit ARM code in anger, only little test routines to check my understanding, and wouldn’t call myself a master of it. I’m probably still a master of 26-bit code (for all the use that is) because I used that a lot and it’s thoroughly ingrained. I could probably get up to speed with v7 enough to convert some old stuff and maybe use a few nifty features of it, but not having used it in anger it’s rusted badly in the ten years since I retired. BBC BASIC is all I really do nowadays.

I know how Draw files, Sprite files and Font files work, and a few file formats that belong to Other Systems. That’s really my forte.

Love Win XP x64 as a relatively uncomplicated 64-bit system

Uh huh…

Thanks for all your input, guys, you sure are a bunch of boffins in my books, and you too, Clive, pleasure to be around your conversational comradie. Know that I can appear to be like a flash in the pan that dies quickly, yet am keen as hang to do something pervasively useful in software this radical invent-the-wheel way,….

…..cos my instincts say that any effort in that direction can eventually accumulate and lead to marvelous control over the whole process of software creativity as a whole efficiently like a dream to be actualized, so adamantly sticking to my conviction and steering my energy, stimulation and enthusiasm along that course.

See that the Rockchip RK3399 Pi 4 board costs $39 according to cnx-software.com, and an importer here in SA is looking into getting some in. Not expecting anyone here on this site to support an ARM64 cause now, yet that`s ok, just like and pursue the concept for my own gratification and curiosity. The RISC4ALL topic is up and in place, that I`m taking the initiative to share all 64-bit activity and coding on.

John, I’m sure that everyone here will welcome your efforts to port RISC OS to this new SoC. Have a look at the ‘Porting RISC OS’ section and first try building targetting an existing system. Please let us know how you get on.

Clive: For most things, ARM32 is the same as ARM26 with the proviso that you mess with the PSR differently. Most of my conversion work was removing things like pushing bit 28 into PC and the like.

Now, ARM64 on the other hand, is an entirely different proposition…

Rick: I understand very well what the differences are between ARM v7 and 26-bit ARM – I wrote the book on the subject! 8~) Actually doing the conversions – never done it, but unfazed by the prospect. Not likely to bother – I don’t need the stuff I wrote for academic journal publishing any more, and on the Pi BASIC can do everything I’ve wanted to do recently easily and plenty fast enough.

Taking advantage of all the extra bells and whistles that arrived at the same time as the demise of 26-bit, which I also documented and understood well at the time – a different matter. Probably more trouble than it’s worth from my point of view, but who knows what I might find I want to do in the future? I might decide to use Neon or VFP in particular, but don’t see the need at the moment. Definitely not Thumb or Thumb2.

As for ARM64 – no chance.

Clive: I too am a dyed-in-the-wool 26-bit ARM creature. To misquote Mary I of England: “When I am dead and opened, you shall find ‘TEQVCP r2, #0’ lying in my heart”

Well, looks like the importer is getting the Rock Pi 4 (model “A” for me without wifi I don`t have to switch off to avoid the radiation I`m ultra-sensitive to) in the new year, and if grabs me, may get a second wish right.

To Stuart S: Howzit. I am inviting my first dev xperience, and though sometimes don`t recognize nor understand details tossed around here from extensive knowledge and past successes, feel that I could have an advantage starting off with later advanced technology to unravel, and bypassing past pitfalls.

Just have every intention to innovate without porting, meaning that new 64-bit Risc is written totally freshly for a new day and journey, while legacy software porting won`t be necessary if the quality and content of new programs simply and naturally supercedes anything done before.

Excuse any ignorance on my part, yet my logic says that when we control our own 64-bit whole board coding, then, providing that new info will enable porting to be performed from older programs by those wanting it, and for any special utility or game they wish to keep alive, be an rewarding challenge, or what?

I perceive that what is certain to take all coders by surprise when and if the time comes, is the more modern ease and efficiency of creating new software on this later ARM64 technology platform, that will have a positive ripple effect on everything else. Let`s take a probability gamble on progressive benefits, and give peace and RISC64 a chance, at putting this site and it`s programmers where they truly deserve to belong

David:

… but to make a new 64-bit OS from scratch.

Most people don’t. Indeed, most people don’t write operating systems from scratch. And of those that do, I can imagine you’d need quite an education (or a ton of experience) in operating system level work before attempting something of that nature. I mean, forget about race conditions in the interrupt handler and just think of something more basic – the filesystem. It needs to be solid and reliable. Microsoft did okay with NTFS, but their support of FAT was varying degrees of broken (how often did you need to use SCANDISK back in the day?).

Ages ago I made a rough specification of a 6502 based system. Like a BIOS to run an embedded application. Simple, a VIA, and ACIA, and 2K RAM. Something like RISC OS is a much more difficult concept. To be honest, I wouldn’t even attempt it. I wouldn’t try bare metal coding on anything that required an EPROM larger than ~8K.

Recall, also, that the OS we know and love has evolved over several major iterations since Arthur in 1987.

Let’s call a cat a cat: if it’s new and not connected to the current RISC OS, where is the point?

Even if it “was” RISC OS (or RISK4ALL as it seems to be called?!?), it isn’t binary compatible so…

…it’s worth pointing out that NOTHING existing will run on it.
No, not even BASIC programs. One doesn’t pass R0-R7 32 bit registers to a SWI in the 64 bit realm. The API will need to change as much as the software. And that will require either a compatibility BASIC that understands the entire old API and fakes it, or a rewrite to the new API. Assuming, that is, that we decide, in a rewritten RISC OS, to continue to make extensive use of numbered SWIs as we do now (Linux threw this away ages ago).

Remind me, what’s the use of an OS with no software?
Sorry, let me rephrase that – what’s the use of an untried OS with no software?

Let’s put it like this – I believe that making better support of current systems is a lot more useful than flights of fancy regarding 64 bit.

Another idea: to have a second core version of the BBC Basic interpreter.

Potentially “doable”? It would probably behave in a manner not unlike HiBASIC on the 65C02 co-pro.

Stuart:

and first try building targetting an existing system

On my blog is an outdated entry that walks one through building RISC OS on a Pi. https://www.heyrick.co.uk/blog/index.php?diary=20131105

If I could make a suggestion, make a full size (~512MB) RAMdisc and unpack RISC OS there. It’ll take a couple of minutes, not a couple of hours. ;-)

Clive:

I wrote the book on the subject! 8~)

I know, it was a rhetorical point. There’s not a big difference between ARM26 and ARM32 in code terms. Just certain things one doesn’t do anymore. All that old TEQP stuff, for instance.

It’s… tedious more than difficult. The “damn near impossible” thing is trying to “fix” programs written in C.

I might decide to use Neon or VFP in particular, but don’t see the need at the moment.

I think the hold up here is the lack of OS level support. For VFP one needs to mess around with contexts and such (whereas FPE is just “used” and a flag given to Wimp_Poll to get the Wimp to preserve state). Also worth considering is the level and capability of VFP support – machines differ. Also differences as to whether or not NEON is supported.

Definitely not Thumb or Thumb2.

Yikes – I’m not sure RISC OS could cope gracefully with an interrupt firing while in Thumb code. ;-)
And, again – what sort of Thumb? Such things are usually built for specific embedded devices (my drone runs an M0 core) so there’s no question of what sort of processor is being used.

Looking at the report from my cpuinfo utility…

I notice that apparently the Pi2 ARMv7 has a memory mapped debug co-processor and a memory mapped trace. I wonder if anybody (Jeffrey?) has written any code to make use of this for debugging stuff?

As for ARM64 – no chance.

Ditto. I am happy in the world of ARM32 (and sometimes 26!).

Two examples of randomly picked ARM64:

/*
  * Clear the init page tables.
  */
 adrp x0, init_pg_dir
 adrp x1, init_pg_end
 sub x1, x1, x0
1: stp xzr, xzr, [x0], #16
 stp xzr, xzr, [x0], #16
 stp xzr, xzr, [x0], #16
 stp xzr, xzr, [x0], #16
 subs x1, x1, #64
 b.ne 1b 

and:

 pre_disable_mmu_workaround
 msr sctlr_el1, x20   // disable the MMU
 isb
 bl __create_page_tables  // recreate kernel mapping
 tlbi vmalle1    // Remove any stale TLB entries
 dsb nsh
 msr sctlr_el1, x19   // re-enable the MMU
 isb
 ic iallu    // flush instructions fetched
 dsb nsh    // via old mapping
 isb

[origin: https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S]

“tlbi vmallel ic iallu dsb nsh”? I could have sworn I saw stuff like that in the subtitles of the Junior Eurovision – I think the girl was singing in Armenian…….

Stuart again:

To misquote Mary I of England: “When I am dead and opened, you shall find ‘TEQVCP r2, #0’ lying in my heart”

When I have some disposable cash, I’d like to order a black sweatshirt with the following colourised as Zap would do it:

LDMVSFD R13!,{R0-R12,PC}^

That’s my favourite ARM instruction. A complete conditional processor state restore in one freaking instruction!

Anybody used to 6502’s messing around will especially appreciate that – PHA, TXA, PHA, TYA, PHA to save a state (IRQ already pushed PC and PSR); with PLA, TAY, PLA, TAX, PLA, RTI to restore afterwards…

John again:

so, am choosing an alternative term to “downloading” over USB 2 and 3, being “uploading or backing up” to external drive storage

Well, if you wish to take recognised terms and give them alternative meanings, expect some confusion. Yes, copying between two USB3 mass storage devices will likely be faster than two USB2 equivalents for pretty much the same reason a Ferrari will somewhat outpace a Clio…

with the latter USB 3, by up to 10 times multiple improvement, that`s all.

In theory, yes. However as I pointed out before, a host with four ports will suffer contention if you connect both harddiscs to it (bandwidth shared between the two).
The bandwidth is not additive (4 ports x 450 megabytes/sec per port does not equal 1800 megabytes/sec throughput) because the next bottleneck is how fast data can get off the device and into the rest of the computer. If it’s a PCIe (rev.2) card, 500 megabytes/sec (or 1GB/sec for USB 3.1 using 10Gbps PCIe) is the absolute fastest the entire interface will go.
Assuming, of course, your machine is able to keep up without stalling doing other stuff (hello Windows!) and that you have a harddisc that is happy with a sustained throughput of those sorts of speeds – good luck with that one. Burst mode might achieve the speeds quoted on the box, but sustained reading is often slower, and writing slower yet.

development at acceptable speeds and sufficiently up-to-date facilities that USB 2 is too slow and old for

Funny. Most of my media runs slower than USB2. Copying a movie to my phone goes pretty quick, but there’s an inherent amount of time required to commit data to flash storage. It doesn’t max out the USB port, indeed it’s slower than copying to the USB harddisc.

To be honest, (and to steal David’s phrase) let’s call a cat a cat and state that a user who demands speed would not be using USB.
Protocol overheads and such mean that no incarnation of USB will match a harddisc directly connected to a motherboard controller. USB3.0 at max speed will run at 4.8 Gbits/sec (maybe double for 3.1 with 10Gbps PCIe). SATA-6 will run at 6 Gbits/sec. Serial-attached SCSI will run at up to 12 Gbits/sec. For external, Thunderbolt will run at up to 10 Gbits/sec.
http://knowledge.seagate.com/articles/en_US/FAQ/172213en

and what is truly warranted is a processor with reasonable longevity since these new boards are relatively shortlived

You’re surprised? It’s like mobile phones – the one you just bought is already obsolete…

and therefore lacking ongoing support for long enough to make creative development feasibly timeous and worthwhile

Unless you make your own board and fabricate your own silicon you are always going to be dependent upon how long others wish to support their products. I rather imagine the little Broadcom chip in the Pi1 was practically end-of-life when it was put into the Pi (old part equals cheap). The market exploded and now we’re looking at a 64 bit capable quad-core Pi which is, frankly, ridiculous. Who’d have thought that possible a few years ago?

Here – get your own processor sorted: https://developer.arm.com/products/designstart

A basic ten year old A5 class processor (ARMv7) with some extras to support it are yours for around £100,000 (triple that if you need ongoing support), plus ARM will expect royalties of around 3%. If you want a cutting edge core, expect to sign secrecy documents and cough up considerably more cash.
By the way, this is to get to “tape out” stage. If you think a few hundred grand (A5 core) or maybe a couple of (tens of?) million (modern core) is a lot, just wait until you see how much chip fabrication costs.
There’s a reason these ARM boards use off-the-shelf ARM SoCs, many of which have been recycled from a former life in media players and mobile phones.

I am personally fully prepared in all ways to welcome challenging a project of this magnitude on my own

I wish you luck. As you know RISC OS (with the exception of a couple of closed bits) is fully open source under a variety of licences (Apache, CDDL, bsd…) so you can take it and make it 64 bit on your board.

connect somewhat objectively with other true enthusiasts like myself and share inspiration in celebration of being alive

Let’s cut to the chase: RISC OS doesn’t need somebody who talks a lot (they already have me ☺), they need code or cash, or maybe both.

Are you willing to donate generously to a bounty? Have you code to share? And if you really want to mess around with 64 bit stuff, how about a hypervisor to start RISC OS in 32 bit mode while allowing access to the other cores in 64 bit mode?

Let’s see some code for that before giving any more thought to 64 bit anything.

David says “What will improve the success of the platform are evolutions (brownfield) and not an overhaul (greenfield). Greenfield is more attractive, but that never works in IT projects”. You claim to have worked a while in IT so I’m sure you are aware of (maybe experienced) companies that wither and die because they have this “clever” idea of recreating everything from scratch. The number of times that actually works is probably up there with the number of startups bought for billions by Facebook. It happens, but it’s not something most of us would be mad enough to bet our lives upon.
The curse of the “not invented here syndrome” can bring a company to its knees.

stiffy disks

tea → keyboard

what is the minimum in info and hard- and software necessary for a bare functional OS

That depends upon what you envisage doing and what you envisage the end result being.

You’re missing a trick here, you know. You might want to look at industrial computing. The machines at work use compressed air to move mechanisms, with sensors for positioning. Touchscreen devices similar to (but not the same as) this: https://www.omega.com/pptst/EZSERTOUCHPLC.html

Let me tell you the specs – it’s a 640×480 display. Colour, but probably something like 64K colour TFT. The video output looks to be 16 colour VGA. The touch panel is resistive by intent (one does not want the controller to crap itself the moment somebody washes the machine with a pressurised water hose). It’ll probably have 64MB RAM if we’re lucky. And the core will be a moderately clocked 486 clone. It will read data off a small CF card (more reliable than SD in damp environments) and it will communicate with the motors, sensors, and actuators using a SERIAL protocol.
They’re not powerful, they’re reliable but pretty much based around old technology.
And they sell for stupid money.

through throwing caution and traditional conventional wisdom and commonsense to the wind,

That’s not how you attract followers, unless you’re planning on creating a religion rather than an operating system.

That’ll do for now. I’m hungry…

I think the girl was singing in Armenian

64-bit Armenian

I am coming here with a fairly strong philosophical approach, in order to lay out a particular and far-reaching big picture before getting into details which then become clearer and more specifically logical and correct, the reason I`m talking a lot of insightful sense, by claiming that porting would be convenient in terms of current knowledge and experience,…..

yet essentially weaken a new concept, by making the newer dependent on the older, whereas by starting afresh with creating a new OS without preconceptions and expectations based on the past, there is an exciting and open and forward-looking, not daunting, road ahead. It`s all about establishing a position of strength for anything more. Sure, no software to run, how flipping challenging to create brand new stuff.

Yes, this can be a slap in the face for those who have invested time, money, effort and blood, sweat and tears, that a newbie like me indicates apparent lack of respect and recognition for, as a snot-nosed immature adult with young spunky ideas and attitude, by proposing to start again. Well, from that radical relocated position of strength, old stuff can be converted for ARM64 based on having full new coding info.

The human solution to getting anything right is based on somehow making intelligent warm contact with people, even in business, where others show their true decency, as in bringing out the best in each other, ESPECIALLY IN DEALINGS AND NEGOTIATING. I see no obstacles in sight that cannot be side-stepped or overcome as the norm for making progress and getting somewhere, that will do us all good to embrace.

Yes, this can be a slap in the face for those who have invested time, money, effort and blood, sweat and tears, that a newbie like me indicates apparent lack of respect and recognition

Not really. I, and I believe various others here are quite capable of coming up with ideas that would take a lot of effort.
It’s pretty rare though for any of the people here to suggest that something should be done without making at least a little effort themselves.
As Rick said earlier if you take an existing 32 bit board and have a go at creating a working build from the existing 32 bit code and then alter that in some noticeable way to produce a new feature then you will understand what level of work is required to update the 32 bit code and the difficulty of making a 64bit equivalent.

So, have a go on 32 bit, let everyone know how you are doing, ask questions if you need help and then if you feel up to it you can move on to a 64 bit platform with an understanding of what you are going to base your new OS on.

So, have a go on 32 bit, let everyone know how you are doing, ask questions if you need help and then if you feel up to it you can move on to a 64 bit platform with and understanding of what you are going to base your new OS on.

Or, as this is going to take some time, why not expand your horizons and aim straight for the 128 bit option!

Morning. Get some inspiration usually when waking, as a morning persom. Of course at this stage I`m simply talking and scheming, as in personal brainstorming, without doing, yet, cos this process is exactly what suits and appeals to me, and thanks for your input, Steve P, that I`m here to ponder and respond to and take conceptually briefly further where nec. Have way back thought through 128-bit already, John W.

Just cannot get myself to go out and spend bucks on a 32-bit board just to take a glimpse of Risc OS, after having installed and looked at so many distributions for years now and rarely being impressed enough to explore them, when I can rather now wait for the new Rock Pi 4A that I`m busy ordering and importing into SA. I always start with hardware, and have acquired many machines because I like them and their features and quality as I 6th-sense and perceive them for interesting putting into action.

So, been searching for an ideal component-rich barebones motherboard system to be in a position of strength with, right from word go, for ages now, that am dying to play and be constructively creative in, and to enjoy and share any progress about with others. Sure, I have nothing concrete to offer at this planning point in time, which experienced programmers like yourself can find exasperating and pointless. Yet, am beginning with a clean slate and sparse development knowledge and exposure, cos am sure of myself.

Familiarizing with Rock Pi 4 through their site info at: https://wiki.radxa.com/RockPi4. Seems like they`re minimally installable, hopefully with GUI, from Android and Ubuntu/Debian initially mainly. Fun approach seems to be to find a possible Linux hex binary editor to boot up with like from SD card, as in Linux UBCD but for ARM, and play on an attached flashdrive with, based on having at least enough instruction set info to use, or not. You UK folks can probably obtain the board across the counter of a local tech store immediately if sufficiently curious.

Just cannot get myself to go out and spend bucks on a 32-bit board just to take a glimpse of Risc OS

The emulation of an old style machine with RPCEmu and RO5 isn’t 100% but it works well enough for the purpose of getting familiar with the OS and applications.
You can also run the DDE to compile new versions if you purchase the package from this link which will give you a full, run on any RO platform, version suitable for the RPCEmu and more.

The top link on the sales page is for the Pi only (the DDE version on NutPi won’t run on anything other than a PI) and all you need is that plus a Pi board.

Have way back thought through 128-bit already, John W.

Just cannot get myself to go out and spend bucks on a 32-bit board just to take a glimpse of Risc OS

John, how many times must we reiterate that this is a RISC OS forum?!?

Rick, is that a giant emoji for grievous aggravated face-palming?

Hey Rick M, didn`t say I took my 2-to-the-7th-power thought seriously, so please save that woman before she has no more brains intact, and seeing there`s still 256-bit to look forward to afterwards

And Steve P, thanks for empathizing…found a single-core Raspberry Pi B+ today, and have just booted up Risc OS, after installing it on an SD. Damn, it looks good and well created, just what I need and want to play with over the festive season to educate and amuse and familiarize and ground myself with, after landing my spaceship, seeing Scotty brought me back for a second chance to find intelligent life down here, and so am sticking around since discovering you Risc brainiacs, ha ha.

And Steve P, thanks for empathizing…found a single-core Raspberry Pi B+ today, and have just booted up Risc OS, after installing it on an SD. Damn, it looks good and well created, just what I need and want to play with over the festive season to educate and amuse and familiarize and ground myself with,

Amusement value:-

You play with lots of the software here at APDL you will discover some that have modules that assume the processor is in the legacy “26bit” mode rather than the RO5 standard “32bit” this means they won’t work on RO5 so…

…when you find ones that have a module that throws a “not 32 bit” error in RISC OS 5 then ARMalyser will analyse the module and provide a decompiled listing you can try to modify to make it 32 bit.
Why? Because understanding the problems that occur with relatively minor code differences between an ARM processor capable of 26 or 32 bit modes running in one mode or the other will give an insight into what would face anyone moving RISC OS to a 64 bit platform.

Oh, and of course if you’re strange enough to belong round here you will enjoy making them work :)

is that a giant emoji for grievous aggravated face-palming

Face-tabling, for when a palm just isn’t enough. Quite well drawn, I just hope it wasn’t rotoscoped…

found a single-core Raspberry Pi B+ today, and have just booted up Risc OS

Oh, finally.

it looks good and well created

That’s why we’re happy using a ~30 year old OS in preference to a fancy new-fangled thing. Three decades later, there’s stuff in RISC OS that other systems still don’t get right. And, of course, with the shift to mobile/tablet devices instead of big desktop machines, it’s as if multitasking has taken a giant leap backwards. Can iOS properly multitask yet? And I don’t mean select bits of select apps…

analyse the module and provide a decompiled listing you can try to modify to make it 32 bit.

Good idea. ☺

will give an insight into what would face anyone moving RISC OS to a 64 bit platform.

My standard response is “It’s like porting to MIPS”. I actually know very little about the MIPS architecture except it is quite different from ARM32…
…just like ARM64. ;-)

I posted some snippets earlier. Some things that seem familiar, only with weird register names, and some things that “look like Armenian” (and well done David for getting the gag!).

For a start, there are thirty registers X0 to X30 (which can apparently also be referred to as R0-R30 but I’ve yet to see this in code, maybe people don’t because it would be confusing compared to ARM32?).
These same registers can also be referred to as W0 to W30, in which case they are 32 bit values (upper 32 bits cleared or sign extended as appropriate).
X31 is a stack pointer if dealing with the stack, or a register that always returns zero (and ignores data written).

The registers are allocated as follows in Linux system calls (possibly how APCS looks in a 64 bit world):
X0-X7 are the arguments and return values (anything else goes on the stack)
X8 is the syscall number (Linux doesn’t use numbered SWIs, hasn’t for a long time)
X9-X15 are trashable temp registers (akin to R0-R3 in our APCS)
X16-X18 are reserved.
The routine called is expected to preserve X19-X28.
X29 is the frame register.
X30 is the link register (akin to our R14).
PC is not accessible.

Only a small number of conditional instructions are available (branch, add, substract, compare, and some basic data processing). Gone is the “everything can be conditional” behaviour of ARM32.
LDM/STM removed, we have LDP and STP (paired) as the best bulk transfer now. So thirty freaking registers and no way to bulk load/store them all. Hmmm – they’d probably say "VFP can do it. :-)

So as you can see, it’s going to be rather more than potentially changing a few register names. Indeed, it’s like ARM64 throws away all that was nice about ARM…

Indeed, it’s like ARM64 throws away all that was nice about ARM.

I wasn’t the only person at ARM who felt that way when v8 was first mooted. v7 is a reasonably logical progression from earlier versions, but v8 just isn’t ARM any more. I lost interest after v7, work at ARM looked bleak. That’s a lot of why I retired – and a fair few other old hands left around the same time.

Wow, informative input, and appreciate sharing, especially with rookies like myself, and understand your progress and motivation (and/or obstruction of it by “progress”). Know I live in my head and imagination, while romanticising technology as an outlet for perfection and passion.

Now, if the hardware ain`t right, either change it or look elsewhere, yet I don`t think that is any final obstacle cos other factors come into play that either suit or don`t and take precedence over our real stimulation and creative spirit. I`ve sensed this all along when and since arriving here last week.

So, after looking at the Raspberry Pi Risc OS environment last night, deduce today from both my 1. being accustomed to Windows and 2. liberated commonsense, that the whole game cries out for complete change, and thereby reinforces any conviction that nothing less than starting from scratch is totally viable…..

….cos as a reasonably normal easy-going spontaneous being, I want and warrant my human traits of intelligence and curiosity and depth of insight catered for yesterday/instantly, replacing procrastination for everything I want, that modern technology has the capacity and resources to provide fully NOW !!!!!!!