User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

UK OS on UK Computer

Wed Nov 06, 2013 10:44 pm

After giving it a two day burn in I have switched over to my newest Raspberry Pi. It is the first one that I have recieved that is Made in UK (the other 5 are made in china), and I am happy. I switched over to this Raspberry Pi Made in the UK about two minutes ago, and am now running RISC OS Made In UK on a Raspberry Pi Made in UK :) .

All of the best computers that I have had in my life have been made in the UK. Starting with the Acorn Archimedes, through the RiscPC systems, and now the Raspberry Pi.

Is this sentement shared by others?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 2:11 am

I share your sentiment, i am so pleased that the PI was born, its very rare these days for a product to be announced with a fan fair and make it to market and at the price it was announced at, the team need to be given a lot of credit.
And the RISC OS is a perfect match.
And both are from the UK, is just icing on the cake 8-).
Last edited by DexOS on Thu Nov 07, 2013 3:21 am, edited 1 time in total.
Batteries not included, Some assembly required.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 3:14 am

Yes it is unfortunate that there is not a good assembler easily available, and that you have to do some searching for information on programming. Many just say use the BBC BASIC V assembler (Which as I have shown does work, though why when much better are available).

I share your concerns. Especialy as msny on the ROOL Forums (ROOL is the orginization that manages the source of RISC OS 5.x) are advocating C, and even trying to get everything to assemble with Asasm (included with GCC [It is a good assembler, though written in C :( ]) and compile with GCC in the few cases where C is used.

I think that there will eventualy need to be a fork that replaces the propriatarily licensed components with open source equivlents licensed under a BSD or MIT license, and written entirely in assembly. This is much easier to look toward now as many components are now BSD Licensed, though there is still a large chunk under Castles propriatary license. Maybe if we just begin writing modules to replace the inbuilt we can eventualy come up with something that can remain in assembly and be somewhat controled outside of ROOL.

I have always liked RISC OS, ever since I first used it back in 1988 (Then named ARTHUR OS).

Just today I was reading the new issue of Archive Magazine (A RISC OS Mag), and they have two major articles about programming in C, and one on programming in Charm, though only a very small one paragraph endpeice that talks about ARM Assembly. I am writing cleaned up more complete versions of the tutorials that I post here to be published in future issues of Archive with the hope of turning more people to ARM Assembly, especialy as RISC OS goes.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 3:34 am

If RISC OS does go the C way, what do you think about doing what freedos did with dos, but we would do it for RISC OS.
Maybe call it "FreeRISCOS".
That's why when i program on RISC OS i am using alot of my own functions.
I think we need to come up with a type of portable assembler, maybe using macros.
Batteries not included, Some assembly required.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 3:54 am

DexOS wrote:If RISC OS does go the C way, what do you think about doing what freedos did with dos, but we would do it for RISC OS.
Maybe call it "FreeRISCOS".
Sounds good to me.

Though we would need to figure out an plan. For example I thing that putting a HAL under the kernel is a bad idea (Only RISC OS 5 ever did this), I think it would be better to use regular ROM Modules to handle the HW (Or even disk loaded modules), this is why we have software Vectors to start with (like the GraphicsV for example is designed to allow a module to handle graphics functions).

And I think that the kernel should be implemented as multiple modules, with only the Memory Management, Vector assignment, SWI management, and module starting related functions in the Kernel proper.
That's why when i program on RISC OS i am using alot of my own functions.
Well that does give a bit of a jump on writing replacement modules.
I think we need to come up with a type of portable assembler, maybe using macros.
Why portable? RISC OS is designed for the Acorn/Advanced RISC Machine (ARM) CPU hence its name. And now the ARM CPU is the most used CPU on the planet.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 4:12 am

@Craig (DexOS):

Is there a way to contact you by E-Mail? (Feel free to PM me).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: UK OS on UK Computer

Thu Nov 07, 2013 9:51 pm

DavidS wrote:Yes it is unfortunate that there is not a good assembler easily available, and that you have to do some searching for information on programming. Many just say use the BBC BASIC V assembler (Which as I have shown does work, though why when much better are available).
You can achieve many things with the BBC BASIC ARM Inline assembler and you still have full access to the BASIC functions and you can also code blocks (macros if you will) using strategically placed user defined functions (i.e., DEF FN). Ok for very large projects BBC BASIC ARM Inline assembler might be less desirable - but for individual Relocatable Module or App compilation it would be fine.
DavidS wrote:I share your (DexOS') concerns. Especialy as many on the ROOL Forums (ROOL is the orginization that manages the source of RISC OS 5.x) are advocating C, and even trying to get everything to assemble with Asasm (included with GCC [It is a good assembler, though written in C :( ]) and compile with GCC in the few cases where C is used.
The fact that the assembler is written in C doesn't matter a jot (IMHO), it's probably easier to maintain and debug. The compile time will be longer - but again how often are you going to compile something so big/complex that the delay will be irritating ? Personally I wish they'd stick (if it is physically possible) to maintaining the DDE rather than jumping over to GCC.

Regarding the OS I think the old maxim "if it ain't broke don't fix it..." applies I think, as much of the OS should be left as ARM Assembler as possible (i.e., it is already so just leave it).

That having been said in some cases complex protocols are being used - the sources of these are frequently in C - (I imagine implementing a USB stack in pure ARM Assembler would be painful). For me so long as more than 50% of RISC OS is in ARM assembler is acceptable, if the whole thing were ported to C I'd be less enthusiastic (code would bloat, speed would drop).

I'll admit my restriction is one subject to personal taste - so please feel free to disagree :)
Last edited by AMcS on Thu Nov 07, 2013 10:22 pm, edited 1 time in total.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: UK OS on UK Computer

Thu Nov 07, 2013 10:18 pm

DavidS wrote:
DexOS wrote:If RISC OS does go the C way, what do you think about doing what freedos did with dos, but we would do it for RISC OS.
Maybe call it "FreeRISCOS".
Sounds good to me

Though we would need to figure out an plan. For example I thing that putting a HAL under the kernel is a bad idea (Only RISC OS 5 ever did this), I think it would be better to use regular ROM Modules to handle the HW (Or even disk loaded modules), this is why we have software Vectors to start with (like the GraphicsV for example is designed to allow a module to handle graphics functions).
Well just compare RISC OS 5.xx (shared source, HAL based) and RISC OS 6.xx (closed source, non-HAL) the former has been ported to various ARMv6/v7 platforms and also the Iyonix - while RO6.xx has only ever run on machines based on legacy hardware (IOMD - such as the RISC PC and the exceedingly rare Microdigital Omega) or under PC emulation of such machines but only once on a newer architecture - the A9Home.

The concept of the HAL is that you produce a HAL for each target hardware - the rest of the OS remains unaltered - and you can quickly get RISC OS up and running on new hardware (as has happened with RO5). It's a division of concerns thing....

RO5 runs on all current hardware (and most of the legacy stuff or emulated systems like RPCEmu), but RO6 can only run under PC emulation and on old hardware. The HAL approach seems to deliver - any alternative might work too - but only at the expense of enormous effort and (arguably) with a version control problem that would drive any sane person quickly mad (think of all those various refactored RMs one for each different hardware platform - painful isn't it ?).

I'd humbly suggest all the effort would be better expended getting the OS stuff ready for the changes to hardware that are coming (it would be nice if - in part at least - the OS could take advantage of multiple core systems - and newer ARM cores). That's a better use (IMHO) of peoples time than trying to implement RO5.xx in a form where, if all went well, the user of the one specific hardware type it runs on would not notice the difference..... but your time is your own so fire ahead knock yourself out :D

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 10:44 pm

AMcS wrote:
DavidS wrote:Yes it is unfortunate that there is not a good assembler easily available, and that you have to do some searching for information on programming. Many just say use the BBC BASIC V assembler (Which as I have shown does work, though why when much better are available).
You can achieve many things with the BBC BASIC ARM Inline assembler and you still have full access to the BASIC functions and you can also code blocks (macros if you will) using strategically placed user defined functions (i.e., DEF FN). Ok for very large projects BBC BASIC ARM Inline assembler might be less desirable - but for individual Relocatable Module or App compilation it would be fine.
Yes the BBC BASIC V inline assembler is quite good for many smaller projects, and I have used it many times (it is currently the most up to date assembler).
DavidS wrote:I share your (DexOS') concerns. Especialy as many on the ROOL Forums (ROOL is the orginization that manages the source of RISC OS 5.x) are advocating C, and even trying to get everything to assemble with Asasm (included with GCC [It is a good assembler, though written in C :( ]) and compile with GCC in the few cases where C is used.
The fact that the assembler is written in C doesn't matter a jot (IMHO), it's probably easier to maintain and debug. The compile time will be longer - but again how often are you going to compile something so big/complex that the delay will be irritating ? Personally I wish they'd stick (if it is physically possible) to maintaining the DDE rather than jumping over to GCC.
Now I must agree with you completely. The DDE is a much better development enviroment, and ObjAsm is a greate assembler, LINK a greate linker, and I have even found use of !ABC from time to time.
Regarding the OS I think the old maxim "if it ain't broke don't fix it..." applies I think, as much of the OS should be left as ARM Assembler as possible (i.e., it is already so just leave it).
I agreee that it should be left mostly ARM assembly. I do not understand this push for C.
That having been said in some cases complex protocols are being used - the sources of these are frequently in C - (I imagine implementing a USB stack in pure ARM Assembler would be painful). For me so long as more than 50% of RISC OS is in ARM assembler is acceptable, if the whole thing were ported to C I'd be less enthusiastic (code would bloat, speed would drop).

I'll admit my restriction is one subject to personal taste - so please feel free to disagree :)
I do not agree about using C for the complex parts, I think that it would be easier to deal with the more complex stuff in assembler.

I do agree that it should remain as much as possible ARM Assembly. I understand the use of BBC BASIC V for some things as BBC BASIC V is as much to the nature of RISC OS as is assembly language.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 11:02 pm

AMcS wrote:
DavidS wrote:
DexOS wrote:If RISC OS does go the C way, what do you think about doing what freedos did with dos, but we would do it for RISC OS.
Maybe call it "FreeRISCOS".
Sounds good to me

Though we would need to figure out an plan. For example I thing that putting a HAL under the kernel is a bad idea (Only RISC OS 5 ever did this), I think it would be better to use regular ROM Modules to handle the HW (Or even disk loaded modules), this is why we have software Vectors to start with (like the GraphicsV for example is designed to allow a module to handle graphics functions).
Well just compare RISC OS 5.xx (shared source, HAL based) and RISC OS 6.xx (closed source, non-HAL) the former has been ported to various ARMv6/v7 platforms and also the Iyonix - while RO6.xx has only ever run on machines based on legacy hardware (IOMD - such as the RISC PC and the exceedingly rare Microdigital Omega) or under PC emulation of such machines but only once on a newer architecture - the A9Home.
Many have attempted this argument. You are overlooking one detail in your own statement, and that is that we have access to the source for RISC OS 5.xx and we do not have access to the source for RISC OS 6.xx. Thus we can not make a clean comparison as to which method is more portable. Though if ALL hardware dependant code were provided by modules (neither 5 or 6 go so far) and external to the kernel then porting would be replacing a few modules instead of working wiht an archain HAL.
The concept of the HAL is that you produce a HAL for each target hardware - the rest of the OS remains unaltered - and you can quickly get RISC OS up and running on new hardware (as has happened with RO5). It's a division of concerns thing....
And if you redo the kernel so that it relies entirely on external modules for supporting Hardware Devices then you write the modules, and some can easaly be reused with different systems that use the same one peice of HW. And writing modules to support HW is a lot easier than modifying the HAL. Ok there would need to be a very small init section to set up the MMU at the begining of the kernel that would be specific to the system due to differing memory maps requiring different load addresses for the ROM. Though you see 99% of the system would be able to be compiled and then only the HW modules selected and the ROM linked and done.

Now there is the issue that this would require some one to do a complete ground up rewrite of the kernel :), and write the needed HW support modules for the first target system, though as long as we have 32bit ARMs the end result would be such a dream.

For an example look at GraphicsV and the few other HW specific portions of the Graphics system, how easy would it be to write complete support for those functions on the RPi with the simple Mailbox system for accessing the graphics settings?
RO5 runs on all current hardware (and most of the legacy stuff or emulated systems like RPCEmu), but RO6 can only run under PC emulation and on old hardware. The HAL approach seems to deliver - any alternative might work too - but only at the expense of enormous effort and (arguably) with a version control problem that would drive any sane person quickly mad (think of all those various refactored RMs one for each different hardware platform - painful isn't it ?).
We do not know which method is more portable as it has no way to compare because RO6 is closed source. And the method that I speak of is mush more complete than that used by RO6.

It is true that there would be a period of transision in order to implement such a system. Though the PRMs would finily be consistant FOR ALL HW SUPPORTED for the first time. This would make it easier to maintain the PRMs. And very little would need to change in the PRMs, just a few notes on supporting HW.
I'd humbly suggest all the effort would be better expended getting the OS stuff ready for the changes to hardware that are coming (it would be nice if - in part at least - the OS could take advantage of multiple core systems - and newer ARM cores). That's a better use (IMHO) of peoples time than trying to implement RO5.xx in a form where, if all went well, the user of the one specific hardware type it runs on would not notice the difference..... but your time is your own so fire ahead knock yourself out :D
Now that is exactly part of the issue. We need a simpler to extend system with easier portability than the current HAL centric model provides, so we can support more boards easier, and add features with less effort. All with out any change to 99% of the system unlike the current way of doing things.


Also you missed that we said: IF THE SYSTEM GOES OVER TO C.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Thu Nov 07, 2013 11:32 pm

@AMcS:
I have given this much thought and even done a little bit of experimenting. It would most deffinitely be possible to implement a system where the kernel is 100% HW independant so long as the system uses a 32Bit ARM CPU (Or even an ARMv8 for that matter), and HW would be supported by modules claiming vectors and in some cases SWI chunks. In order to do this I would propose that a small bit of code that runs before the kernel be used to provide the initial enviroment with a correct memory map, and then require that the very first loaded module be the MMU module (and add an MMU Vector), then require that with in the first 16 modules after that loaded are modules to provide support for (In no particular order):
1: Keyboard (KeyV, RdchV and related)
2: CLI (CLIV)
3: Display (GraphicsV, PalletteV, WrchV, and related)
4: Enviroment (ChangeEnviromentV)
5: Clock (TickerV, FastTickerV and related).
6: Power Management (Would have to create a new Vector or use an SWI block).
7: Mouse (MouseV and related)
: : ETC.

I say in the first 16 as some of these may require extra support, like USB for KB and Mouse. As you can see I have given this a greate deal of thought, and I truely do believe that this would improve things significantly as far as portabality is conserned as well as supporting new technologies (like multi core, and 64Bit apps [These two would belong to MMUV]).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: UK OS on UK Computer

Fri Nov 08, 2013 12:09 am

DavidS wrote:
AMcS wrote:That having been said in some cases complex protocols are being used - the sources of these are frequently in C - (I imagine implementing a USB stack in pure ARM Assembler would be painful). For me so long as more than 50% of RISC OS is in ARM assembler is acceptable, if the whole thing were ported to C I'd be less enthusiastic (code would bloat, speed would drop).

I'll admit my restriction is one subject to personal taste - so please feel free to disagree :)
I do not agree about using C for the complex parts, I think that it would be easier to deal with the more complex stuff in assembler.
That depends on the skill of the programmer, the quality of the documentation (if any) describing the complex stuff and if there is a known/good implementation with an appropriate license (say BSD) written in C that could more easily be ported to RISC OS (ideally just by a quick recompile...).

The real quandary for RISC OS is in is that there are too few programmers to do the work necessary in C (never mind Assembler). The pool of people who can effectively code Assembler is small - those who can code C are more numerous.

It's time to "box clever", use the available programming talent and resources in the most effective way - to get the most "wins" with the least "effort" that (I think) will give the best results for all. The key objective, I feel, is that as much as possible of RISC OS should be/stay in ARM assembly - it's what gives RISC OS it's performance and responsiveness. In some instances we may need to compromise a little and use another language (such as C) - but that should, I feel, be kept to an absolute minimum.

I'll preface all that by saying as I am not the one doing the coding of the OS I am not going to (or am going to be cautious about) second guessing the people who are.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: UK OS on UK Computer

Fri Nov 08, 2013 1:05 am

DavidS wrote:
AMcS wrote: Well just compare RISC OS 5.xx (shared source, HAL based) and RISC OS 6.xx (closed source, non-HAL) the former has been ported to various ARMv6/v7 platforms and also the Iyonix - while RO6.xx has only ever run on machines based on legacy hardware (IOMD - such as the RISC PC and the exceedingly rare Microdigital Omega) or under PC emulation of such machines but only once on a newer architecture - the A9Home.
Many have attempted this argument. You are overlooking one detail in your own statement, and that is that we have access to the source for RISC OS 5.xx and we do not have access to the source for RISC OS 6.xx. Thus we can not make a clean comparison as to which method is more portable.
While I'd agree there is some truth in that point, the real proof (as we can't compare sources) is what the results were. There ARE more systems using more varied hardware using RO 5.xx than are using RO6.xx. It seems to me interesting that the HAL based OS got onto more systems quicker and with less effort than RO6.xx. If the refactored kernel approach of RO6.xx had advantages in terms of porting to other systems it was not exhibited in the number of different platforms it was put on !
DavidS wrote:Though if ALL hardware dependant code were provided by modules (neither 5 or 6 go so far) and external to the kernel then porting would be replacing a few modules instead of working wiht an archain HAL
By making things a little abstract though you make the task of maintaining the OS (which should be as hardware agnostic as possible IMHO) easier.
DavidS wrote:Though the PRMs would finily be consistant FOR ALL HW SUPPORTED for the first time. This would make it easier to maintain the PRMs. And very little would need to change in the PRMs, just a few notes on supporting HW.
<Humour Mode>
So it's a benefit to refactor the OS kernel and modify dozens of modules rather than just update the PRM documents ???? :)
</Humour Mode>

Anyone can type, not everyone can program, so updating the PRMs is always easier !!!!
AMcS wrote:I'd humbly suggest all the effort would be better expended getting the OS stuff ready for the changes to hardware that are coming (it would be nice if - in part at least - the OS could take advantage of multiple core systems - and newer ARM cores). That's a better use (IMHO) of peoples time than trying to implement RO5.xx in a form where, if all went well, the user of the one specific hardware type it runs on would not notice the difference..... but your time is your own so fire ahead knock yourself out :D
DavidS wrote:Now that is exactly part of the issue. We need a simpler to extend system with easier portability than the current HAL centric model provides, so we can support more boards easier, and add features with less effort. All with out any change to 99% of the system unlike the current way of doing things.

Also you missed that we said: IF THE SYSTEM GOES OVER TO C.
I am not sure that fragmenting the kernel into numerous modules exactly amounts to making the system easier to extend, but I'll have a look at the proposals you make in your later (interesting looking) contribution before commenting on them.

If the system goes purely over to C I'll take my hat and walk off into the sunset nodding solemnly with profound disappointment !

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: UK OS on UK Computer

Fri Nov 08, 2013 1:08 am

I think that as the subject as turned to the rights and wrongs of the direction of RISC OS.
That maybe its time do a rethink about the way RISC OS does things.
For example there is no way that RISC OS is going to be a desktop OS without turning it in linux.

But that's the way it's going, any assembly coder know that it's no harder to code a driver in asm than C.
But 99% of the time, it not a case of coding in C or asm, its a case of coding in asm or recompiling it, and recompiling it is easier.
But if you coded a fat module in asm for example, it would be very little work to get it to work on all ARM types.

I have done a lot of work in bare metal and i have not found a single good reason why there are so many layers :? .
To me RISC OS need to be fast and simple.
Its needs to be module and need to be able to load and run app and have a set of good function to help coders, code things.
That's it, its not a desktop OS, it should be single tasking as in the "i-pad".
We need to think out of the box, there's so many people that want to use the pi for example to do a single task, as fast as possible and has simple as possible.

Example, its harder to do stuff under RISC OS than it is under bare metal, the OS just gets in the way and you need to fight it to do stuff.
I can understand that under a desktop OS like linux, but not in a OS like RISC OS, there's no need, so if there where to be a redesign it need to be to the bare bone.
Batteries not included, Some assembly required.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: UK OS on UK Computer

Fri Nov 08, 2013 1:24 am

DexOS wrote:We need to think out of the box, there's so many people that want to use the pi for example to do a single task, as fast as possible and has simple as possible.

Example, its harder to do stuff under RISC OS than it is under bare metal, the OS just gets in the way and you need to fight it to do stuff. I can understand that under a desktop OS like linux, but not in a OS like RISC OS, there's no need, so if there were to be a redesign it need to be to the bare bone.
You could *UNPLUG modules you don't need, configure the starting language NOT to call the desktop, if that's still not sufficiently frugal then by all means look at what's needed to implement a "lite" version of RISC OS for that specific niche (I suspect though most RISC OS users would like to keep a non-lobotomised version for their use - people (incredibly perhaps) still use this OS for sending emails, designing graphics, writing software and much more besides) - if a "lite" version can coexist for specialists like yourself and the "common or garden" RISC OS remain available for others that's fine IMHO.

Perhaps in optimising a "cut down" RISC OS lessions can be learned that might allow the "full fat" version to be improved too.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Fri Nov 08, 2013 1:26 am

@AMcS:

I do see the point of quick porting of some things being helpfull in some situations (especialy where the documentation is lacking at best).

And I would say that it deffinitely helps to have an OS written mostly in assembly. And I would love to see more of it brought back to assembly. This is part of the reasoning behind the series of tutorials that I am posting to teach ARM assembly for RISC OS by example.

Though I do not like how long it takes to compile a complete ROM image (though this is largely do to the components written in C and/or C++). I feel that it would be a significant improvement to have everything in Assembly from this point of view as well, as it would decrease the total compile time by a lot.

Unfortunately there is a lot to recreate before I can build a ROM that does not use the HAL at all, though I have managed to do a few builds that do not use the HAL for graphics, and perform slightly better than the HAL based verient (at least on the RPi) (although still not complete enough to be usable for day to day stuff). As for the HW support modules in my testing I am also writing versions for the BBB, as I intend to get one and see if I can port RISC OS to it (maybe). If that is a success I will present my idea to the ROOL Forum (again).

========================================================================

Since moving to the RPi and RISC OS 5.xx I have been looking at the verious assemblers that run in 32Bit mode attempting to decide which to use for continued usage. This is because the assembler that I had previously used only ran in 26bit addressing mode, and is closed source. Now I have a copy of ObjAsm though it is comercial and closed source (I would prefer something open source).

I do like AsAsm for its likeness to ObjAsm/AASM. Though I do not like the fact that it is written in C (Call me a purist when it comes to tools). I also like extASM, though its lack of a command line interface is conserning as is its relience on extAOF to preprocess in order to produce AOF objects (extASM actually still produces a flat binary, extAOF just inserts code to produce the AOF structures). I realy realy like ASM, though it is closed source (as far as I know anyway), and does not support VFP/NEON instructions (Minor limit as I rarely use these and can use BBC BASIC V to assemble those parts of a program into a binary and include the binary in the final product).

Though in sum I have not yet settled on an assembler. I may attempt to contact Nick Roberts to see if the source for ASM is available, if so that would be my assembler of choice.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Fri Nov 08, 2013 2:01 am

DexOS wrote:I think that as the subject as turned to the rights and wrongs of the direction of RISC OS.
That maybe its time do a rethink about the way RISC OS does things.
For example there is no way that RISC OS is going to be a desktop OS without turning it in linux.
I guess it depends on your definition of Desktop OS. For me RISC OS has been my main desktop OS for 25 years, and continues to be. For me it is far ahead of any of the Unix like systems that all seem to be attempting to go backwards faster than forward. Admitidly it would be nice to have a good fast 100% HTML5 complient Web Browser, though that is fust a matter of time.
But that's the way it's going, any assembly coder know that it's no harder to code a driver in asm than C.
But 99% of the time, it not a case of coding in C or asm, its a case of coding in asm or recompiling it, and recompiling it is easier.
But if you coded a fat module in asm for example, it would be very little work to get it to work on all ARM types.
And it is possible to code it to be completely neutral with out having to code a FAT module. This is the beuty of the ARM, true Neutral code is possible (for all ARM CPUs anyway.

I have delt with coding FAT binaries for verious systems, the most difficult being for GEM applications that would run on both the 680x0 and the x86 versions of GEM.
I have done a lot of work in bare metal and i have not found a single good reason why there are so many layers :? .
To me RISC OS need to be fast and simple.
Its needs to be module and need to be able to load and run app and have a set of good function to help coders, code things.
And RISC OS provides just that. Even in the desktop enviroment there are only two layers (unless you use the DDE stuff or other C targeted extensions [like UnixLib]).
That's it, its not a desktop OS, it should be single tasking as in the "i-pad".
We need to think out of the box, there's so many people that want to use the pi for example to do a single task, as fast as possible and has simple as possible.
And therin is the beuty of RISC OS, it is both. It can run multitasking, or single tasking. Its feature set is very complete, though yet so simple that any one person can understand every little bit of the system.
Example, its harder to do stuff under RISC OS than it is under bare metal, the OS just gets in the way and you need to fight it to do stuff.
This may be just years of experience with RISC OS speaking, though: I dissagree I can easily do much more with much less in RISC OS than on the bare metal.
I can understand that under a desktop OS like linux, but not in a OS like RISC OS, there's no need, so if there where to be a redesign it need to be to the bare bone.
Thankfully RISC OS does not have extra layers of abstraction if you do not have a HAL. And therin is the problem, the HAL is in the way.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: UK OS on UK Computer

Fri Nov 08, 2013 2:38 am

Note: when i say its not a good desktop OS, i am talking the for the masses here, i could easy use it everyday, but i mostly only code or browse the internet.
Most users need protection from them self's .
Batteries not included, Some assembly required.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: UK OS on UK Computer

Fri Nov 08, 2013 2:17 pm

DexOS wrote:Note: when i say its not a good desktop OS, i am talking the for the masses here, i could easy use it everyday, but i mostly only code or browse the internet.
Most users need protection from them self's .
I see this point. Though I think it is because of how they learned to use a computer. If people learn with an OS that lets you get away with anything then they would be better off with computing all around.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “RISCOS”