|RISC OS Asm / BASIC Fun : LOG
All information herein is the view of the author. Use at your own risk, no warenty of any kind is provided.
|Aug 16th, 2022:|
I have spent a lot of time reading what people find easy to use in Windowing Systems, as well as preexisting research in this area, over the last few years. Likely having read thousands of articles, I present a crude small paper on this topic here: A look At WIMP's.
The end result is that the Macintosh System Software is overall the easiest to use and program for.
Despite learning why Macintosh System Software is the easiest and most liked of all the WIMP systems around, I am still primarily a RISC OS user. This brings forth the question of why at its core. This also brings to mind reasons that I have used Macintosh System Software, and the question of if I will use it more in the future.
I just like using and programming on RISC OS. My old statement of thinking it was the easiest overall is not true as it turns out. So the only reason I can give as a good hard reason is that I personally like RISC OS.
While not covered in the above document it is even so that programmers report enjoying programming for Macintosh System Software beyond most others. So the ease of programming argument does not fit my usage of RISC OS any more either.
This does raise some questions. How can we create a brand new WIMP for RISC OS that has most of what people like about the Macintosh System Software, and would it be worth it (likely not do to lack of software). Should some focus more on the 'Classic' Macintsoh System Software, probably so. These are questions as they apply to extreme long term usability of Desktop Computing.
|Aug 15th 2022 : Focus Focus Focus.|
Getting to more purely RISC OS, again. I will be using much of the code from the YASDOE project for RISC OS related projects, as the reason for YASDOE existing at all is that I like RISC OS. I had thought that maybe another Operating System would do good, though in retrospect it is better to directly promote the Operating System we already have that is good.
As such the code of YASDOE will be used to create a RISC OS ROM image for the RPi, and some other systems, that is 100% assembly and BASIC V, has a version of !Edit and !Paint that work like RISC OS programs (unlike the updated versions now in the ROOL ROM Images), and reverts the API to pure RISC OS (while still allowing for large address space). This will also get rid of the need for having any form of C Library in the ROM Image. This is a bit of a long term project, as a lot of code must be modified to achieve it.
In the current time I will focus on working on RISC OS related projects directly, while keeping to pure RISC OS.
I am also making some modifications to this Web Site to ease maintaining it, and encourage me to post more code related articles as well as downloads
|May 27th 2022|
Line inversion point Clipping can be very effecient for many applications, and has been known since at least 1976, likely further back. This has no limits on the shape of the clipping area, and takes advantage of the fact that raster graphics are by there nature line oriented first. Unfortunately many people avoided using this method for a long time do to a patent that defined one method of implementing line clipping in a more space effecient way, this patent did not cover raster inversion point clipping (and could not cover such), though just how to save memory in one method of implementation.
A common method of implementing Line Clipping with inversion points is to have a list of inversion points for every raster line of the clipping area. Then you just need to test the output against the inversion points to be sure it is within the visable area. This is extremely simple, and has nothing to do with the afore mentioned patent, and thus can, and always could, be used by all.
The patent that scared so many, largely do to lack of understanding, was that of Apple Computers Regions as implemented in the Lisa, Macintosh, and Apple IIgs system software. This pattent was only able to cover the means of saving space, as there was a lot of prior usage of the inversion point clipping on a raster line basis already in use by many.
Many early software sprite implementations took advantage of raster line inversion point clipping, as it is fairly fast and can cover arbitrary and non-continous areas. This makes the method ideal for things like sprites. It turns out that it also simplifies life when working with overlapping windows in a graphical windowing system.
It is easy to work with this kind of clipping area by doing operations of combining multiple areas defined by raster line inversion point clipping. This goes for having the visiable areas of multiple definitions ORed, Exclusive ORed, ANDed, etc, as the inversion point method simplifies this greatly. This also means that if you implement routines to plot outlined and filled area definitions you can do some amaizing, and very fast, graphics operations. Plotting the outline of an area defined as lines of inversion points is very fast, filling said definition with a solid color, pattern, or Raster Image is very fast as well (which is also why it is so good for clipping).
While the patent is long expired now, it is still too bad that so many did not really understand it. Had more realized what they could still do without the patent ever getting in the way, we could have seen some much better graphics systems than were/are common place for 2D raster graphics (as well as 2D vector graphics on a raster display).
Remember always look for the best, most effecient, algorithm you can find or figure out in implementing any peice of code. Raster Line Inversion Point clipping is a good example of this, and one I have personally used since I first learned how to do it in the early 1990's.
Forever learning, forever improving, forever rewriting code to be better than before. This is the mantra of a Computer Programmer and Software Engineer that works for there own enjoyment. This is the way to better software in all areas.
|May 26th 2022|
Four computer companies, each made a good line of 32bit systems, each has contributed to my use of computers today and my thinking on many things. All four also contribute to my love of RISC OS.
Atari and Amiga were my first 32-bitters, using a 32bit CPU with a 16bit data bus and a 16bit ALU. Amiga had the OS that was so far ahead of anything else of the time, and in some ways still has an edge now (37 years later). Atari was the most open of all systems.
Acorn gave the taste of good pipelined RISC computing, at a very affordable price for the time. With RISC OS, an OS that has many concepts that are different from others, and some that are still being copied for there usefulness. The IconBar of RISC OS, that dates back to 1987, has very visible influence on many others. Others have tried to copy, and always fall short of, the universal level of drag and drop that we know well in RISC OS. And today we see many different systems attempting to put application code and resources into directories that apear to be a single program (application Directories), though RISC OS has done this for over 3 decades.
Apple gave us the Macintosh line, a line of computers that had some very inovative concepts in its System Software. It is to bad that everything inovative in the Macintosh System Software was lost with the NeXT OS for Apple Inc (Mac OS X / macOS). The Machintosh System Software had a very robust system for graphics drawing and clipping (regions) that is better than any other line clipping implementation, and as with all line clipping implementations is much better than any rect clipping implementation. Then the Macintosh gave us the Resource Fork and resource manager, this has so many advantages and inovative concepts that it could be a long article by itself.
Every one of these has influenced how I use RISC OS today, how I designed YASDOE-Core, and how I intend to move forward in computing. Every one of these systems has advanced features not seen in any other still to this day.
I am very thankful to those that were involved in writing these other Operating Systems, as without there inovations it would have taken a lot longer to develop YASDOE-Core. They figured out the ways to do it, saving all today a lot of work when desinging something new.
|May 26th 2022|
It is no secret that I do not see most Unix like OS's as usable for desktop computing. There is an exception, one that has always been good for desktop computing do to its design (and it is a single user at a time OS). This is Atari MiNT (originally recursive for MiNT is Not TOS, changed to MiNT is Now TOS).
While nowhere near as advanced as RISC OS or Amiga OS from a technical point of view, MiNT is technically way more advanced than M$-Windows 3.x and 4.x (95/98/98SE/Me) that some people use/used.
MiNT is a single user at a time, preemptive multitasking, monolithic kernel, OS that was designed to replace GEMDOS and provide a *n*x like API to programs. MiNT has one big dissadvantage over other TOS Multitasking Systems (like MagiC or Geneva) in that it is slow, very noticably slow. For the most part though (other than being slow) MiNT is a very good Desktop Operating System that provides a *n*x like API to applications.
The reason for mentioning this OS is that it was the inspiration for one of the earlier test alternate API's for YASDOE, one that has not been kept up very well, though one none the less.
|May 25th 2022|
One area of RISC OS that has always been a potential issue is the static nature of SWI Chunks. For some things this makes good sense, especially those things that are core to the OS. For user / extension / etc modules this does not make sense so much. RISC OS already provides a means of finding the chunk number, so why not add the ability to dynamically assign the chunk number (then only the chunk name needs to be unique)?
As such I have previously proposed, and am again proposing, that a module be written that dynamically assigns chunk numbers when loading other modules. Then programs that use the SWI chunk provided by these modules need not be an issue, they just request the SWI number of the first SWI provided by the chunk and use relitive values for the other calls. This is a very simple solution to a widely known issue.
This also gives us American RISC OS users a bit more comfort. Historically we never Allocated any of our modules or applications, as this is not the way we do things. We looked at the Acorn request for things to be allocated in the same light as we saw the similar request of Apple to allocate System Extensions in the Classic Macintosh System Software. That is to say we never did either one, hence the well known extension conflict catchers on the Classic Macintosh System Software. Now I propose a means of avoiding conflict on RISC OS without having to Allocate what we create.
In concept the allocation module would check for a free chunk in the user SWI range, load the module into memory, patch the modules chunk number, and call OS_Module 11 (Insert Module from Memory and move to RMA). It does not get much easier than that.
I recommend calling the chunk name for this dynamic module SWI chunk allocation module "DyMod" for Dynamic Module. Thus its star commands would also begin with "DyMod_". Being what it is, this module should dynamically allocate its own SWI chunk as part of its initialisation, this will reqire embedding it in an Absolute that is run to load the module.
When loaded the DyMod would allocate itself the highest available SWI Chunk number, and set the starting point for searching to the next lower chunk number. It would keep two lists, one of already used chunks below the starting point and above the lowest it allocated so far, the other of the chunks it has allocated. Then the procedure when loading a module is:
As I have made this proposal at least 8 times now, I may just end up writing the module myself. I do not understand why people are not interested in making life easier on all RISC OS users in some cases.
As Modules are the RISC OS native library functionality method, and SWI calls are the cannocal way of calling Module Library code, this seems an obvious way to proceed forward. There are only at most 8192 available SWI chunks total (some of which are reserved for RISC OS itself), and if every module ever made needs to be unique then we will run out of SWI Chunks eventually. If we use dynamic allocation, then only what is being used is actually taking chunks, and there is no need for static never changing allocations of chunk numbers (other than those that are a core part of the OS).
|May 23rd 2022|
There has been a lot of debate about shared libraries on RISC OS over the years. The original method is providing SWI services (yes it is still a library, just the chosen means of calling). The current solution used is to do dynamic linking, I dissagree with this method.
The problem to overcome is that with most newer ARM CPUs the decision was made to use a split cache, seperating the D-Cache and I-Cache in the CPU L1 Cache. This was and is NOT the only solution to better cache access, and it is arguable which method is best, though what is done is done. This split cache means that to fetch the SWI opcode as data contaminates the D-Cache (and ARM chose not to add a register to the system cooprocessor to hold the last SWI value, despite it being recommended before we ever had a split cache).
The solutions include using the dynamic linking (increasing the startup time of applications a little), or using a more direct call type of library. The more direct call method seems the better solution, as there is no load time fixup needed, and it is fast and simple (much faster than SWI calls). If we remember that the ARM has always had some form of MMU, and indeed RISC OS needs this to operate at all, then we can take advantage of the abort handlers to switch into a privledged mode when needed in a system call without needing an SWI.
Four RISC OS users that were at the time also Amiga Users sent the recommendation for the direct call table shared libraries to Acorn in early 1991, including how to implement memory protection around this system more comprehensively than is done with Modules. Acorn ignored us, and shipped shared libraries for programming languages that use run-time patching (dynamic linking) and use an SWI to trigger the linking.
Fast forward to 2012, and I am beginning work on an OS concept, largely modeled after RISC OS in the API, though being MicroKernel based and using table direct call libraries instead of SWI handlers (largely inspired by Amiga Exec). Then in 2016 I write a quick library implementation for RISC OS, with the intent of distributing it as an option and alternative to ELF libraries and old style Acorn shared libraries, though the RISC OS maintainers and core group of programmers reject it outright without even seeing it, so it stays confined to my drive never yet shared.
Now as I am getting close to releasing the Operating System project that prompted me to implement the RISC OS Shared Library Manager that is clean, fast, and robust in nature, I am considering releasing the RISC OS Library Manager (as it will also allow for running some YASDOE-Core native programs on RISC OS). All I need to do is tell myself that those that said they do not want to see it can ignore it while it benifits others.
The only SWI provided by this library manager is used to find the base address of the Core library (modeled after part of the MicroKernel (ALiMiKern) of the YASDOE project). Once that address is available to the application, all other library calls can be made without ever calling another SWI (as the Core library manages the libraries). It would be nice to see a future version of RISC OS where the SWI handlers are just wrappers to call shared libraries of this kind, and the native API is 100% implemented in Libraries that are a lot faster to call SWI's (the overhead is a lot less), and largely run in user mode with per task data areas.
SIMPLE USAGE EXAMPLE: The following is a very simple example of using the OS Shared Library (which provides library call versions of most OS SWI's) to use OS_Write0 to output a string (example in BASIC):
While not the most effecient in BASIC, it should be obvious how much better this is in C, Pascal, or Assembly Language. You could also just get the library base using the call 7 (-28 bytes from base) "Core_LbStr2Addr" and use the known function call offsets for the library being used.
While not shown, as not needed for the example, it should be obvious that libraries need to be loaded before used (just as modules do). The two mentioned name lookup routines automatically check if the current task has initialized the library, and performs the initialization if needed.
By default when loading the Library Manager the following shared libraries are loaded:
If any of these libraries are missing or otherwise can not be found, the Library Manager will refuse to load returning an error.
For the libraries that implement functionality of the OS, the call table offsets for SWI Chunk+Call are (LibBase-(Call<<2)-16). The minus 16 is do to the first 4 calls being reserved for standard needs of all libraries.
Information on how to write libraries will be coming as well, this is just a log post giving a bit of a quick overview of what is to come in the downloads here.
|May 18th 2022|
Even as I am nearing the release of another OS, I am still focused on RISC OS and continuing to use and promote one of the best ARM Operating Systems to date. In part this includes the decision to only release the RISC OS hosted versions of the YASDOE Project Operating Systems, as we can always get out to the host OS.
I will attempt to remember to put a few things more on this site, I know it is a bit bare at this time. I am hopeful to help show some of what I see as good about RISC OS on the ARM Based Computers.
|May 17th 2022|
Three notes updating the status of YASDOE:
The three OS's developed as part of the YASDOE project are (all called YASDOE):
Over time more will be said about all three of these, and how the threee can be ran together in a single OS under the ALiMiKern MicroKernel. (with some limits). Each of these implement features that are not of the OS they imitate, and thus make for a more complete experience.
All three Operating systems support both 68K native and ARM native executables, in a transparrent manner. Also all three have support for running modern 32-bit R15 ARM code as well as support for running ARMv2/ARMv3/ARMv4 code that relies on the 26-bit address with Status bits combined in R15 (a little less transparrent in some cases than the 68K and ARM code combo).
|April 16th 2022|
YASDOE (Yet Another Simple Desktop Operating Environment) Pre Announcement posted at:
This is one of my huge projects, finally nearing release. This project is also the inspiration for some of my other large projects (including some for RISC OS specifically).
I am writing YASDOE as much for my own enjoyment and education as to provide something that others may find usable.
|March 05th 2022|
OOPS, Talking about Unix on a RISC OS Site?. Yep, we talk about some strange things around here.
Have a look here: Talking Unix.
|January 17th 2022|
There exists code in production Operating Systems, as well as many utilities that does not bother to implement reasonable bounds checking. I have been finding this kind of code all over the sources of programs that are with 4 Operating System I have been studying. This seems unrealistic to me. There are many examples of utilities reading a string from standard input that are nearly identical (just different naming) and are like:
Is it realy that difficult to remember to check bounds? When I was learning to program as a kid, I likely did some of these. Though once I started really coding, the concept of always manually tripple check all code for out of bounds and always manually tripple check all code for off by one errors became so drilled into my mind, in any programming lanaguage, that it seems unreasonable that release quality code would include such extreme errors. Those many cases of code like above could easily be done like:
Wow look at that, code that never overflows the buffer, and simple enough to implement that there is no reason not to do so. Also note that it will not allow i to reach element 159, as that is the last element and needs to be used for the null at the end of the string (would be easy to overlook that off by one if you are dead enough to your code to miss a bounds check).
Bounds checking is easy. Manually checking each function for needed bounds checking is easy (regardless where or how the buffer is declared). Manually checking for off by one errors is easy.
As an exersize to the readers, there is a well known BASIC text game, called Hunt The Wumpas. In the version widely published in books of the late 1970s and early 1980s there is an off by one error in the code that makes a significant difference in proper operation. Find that and enter the corrected version in a compatible BASIC interpreter. This is a bug that was very much overlooked, even though some of us saw it as obvious do to our strictness on ourselves about catching the two most common kinds of functional bug in code (overruns, and off by ones).
I am not mentioning the names of the 4 Operating Systems whose code containes thousands of examples of forgetting bounds checking, as I do not wish to embaras there programmers. Hopefully some of them will see this and work to correct there code. After all we all make mistakes, we are human.
I have been spending a lot of time researching what it will take to produce a branch of RISC OS (under a new name) that supports preemptive multitasking, and more complete memory protection. In the process I have been writing code in moving towards the goal of achieving this new OS branch, and it looks prommising.
I make no prommises, though I have learned a few things, that may be of aid to others that may wish to try to do similar extensions to RISC OS:
A bit of a side note: RISC OS has a very good thing going for it, that it inherited from the BBC Micro. That is VDU streams, esecentially a terminal protocal that has quite good graphics support and a lot of extras. Terminals working on streams of bytes are usually limited to text, requiring complex protocals for anything more. RISC OS has always had support for byte streams to standard output that can do quite good graphics.
|Jan 15th 2021|
How do you make system calls? What about caling other functions in the system? I have added a page to the documents about this question, see  Shared Libraries Many Methods.
Starting with todays Log entries, I have updated the format of posts, as can be seen. Now the seperator bar just has the date, with the title being at the head of the sections. This simplifies life when having multiple posts on a given day.
|Jan 11th : Algorithm Note & Coding Guidelines:|
In writing a few new routines for my OS kernel today, I ran into an interesting example of the implementation of an algorithm. This one do to the limits of the C programming language, you see on ARM we have the CLZ instruction, at least since ARMv5, so it is easier to implemnt the algorithm in Assembly.
The algorithm is a simple task priority schedular that takes advantage of the fact that when counting in binary, only one bit will ever flip from 0 to 1 on any given count, and all higher bits will remain untuched, and all lower bits become 0. Thus we can find the bit value while counting by ZtoOneBit=(~Count & ++Count). Now in arm assembly we could use CLZ to simply get a number, that when subtracted from 32 would be the bit position of the bit that whent from zero to one. In C we have to use a switch case statement (thus the C code is actually longer than the assembly version.
To help illistrate this concept, here is a link to the C source code TaskSch.c , this file contains 16 lines of code (in entire file), implementing a single function (in 13 lines of code) that handles priority of next task, and is called durring the control timer inturrupt. The function itsel is:
|Where in assembly this can be done by simply:|
Now that is not 100% optimal assembly, though already a lot better than what that C code would give.
The point is that even when you have a good algorithm, it is possible that the programming langauge being used may put limits on the implementtion of the algorithm in question. If I were being strict about sticking with C, I would have had to live with the less effecient implementation of the very good algorithm.
Yes, do try to find the best algorithms for your purpose, yes do try to figure out the best implementation you can. Though always realize that the most optimal you can do in a given program language can depend on language features.
In the process of doing some research working on my compiler as well as my simple kernel, I came accross some old documentation on programming guidelines that are interesting for what they said and what they are.
MACINTOSH 1984 & 85: Apple provided a number of guidelines on how to write software for the then new Macintosh computer. Among these guidelines are a few tht Apple did not follow. One is that no code should use the upper 8 bits of an address as flags, because someday computers would use those bits as real addresses. Another was the advice to use the Operating System for all graphics and sound output, as well as other things. Apple broke both of these guidelines with a lot of there software up until the early 1990s.
AMIGA 1985: Amiga also provided guidelines about not using the upper 8bits of addresses as flags, and using the OS as much as possible. Everything I know of from Amiga followed there guidelines completely. One third party program broke the bit flag rule early on, that was AmigaBASIC from Microsoft. Of all the systems I am aware of, Amiga is the one that did best about having a reasonable set of guidelines, as well as following there own guidelines.
ATARI 1985: As far as I know Atari did not provide any limiting guidelines for there Atari ST series of computers. Ironically there is a lot of well behaved software from the original ST days that runs unmodified on everything up to Atari TT and Falcon machines, and with up to 68060 CPUs.
Acorn Archimedes: It is interesting that Acorn provided a lot of guidelines on how things should be done on RISC OS computers. Though yet they did not mention the potential problems if one day R15 becomes a 32-bit address for the program pointer. They actually recommended writing code that would break with larger PC address spaces. This is ironic, as other systems had recommendations to avoid such damage potential, while Acorn tried to provide extreme sets of rules on how to write code that uses legal means and is thus likely to continue to work on future computers.
In Summery: While I may prefer RISC OS (though still like Amiga OS), we see yet another reason that Amiga usage and updates have stayed strong after all these years, while the others are just kind of holding on. The Amiga had many things correct, and thus it is loyaly followed. The biggest negitive for amiga is the use of things like Standard File Selectors instead of the more intuitive drag and drop as in RiSC OS, though as that is a later Acorn Inovation that did not exist when Amiga came out, we can not fault Amiga for this.
I have long said that a perfect OS would be an implementation of Amiga OS with some of the best features of RISC OS. That is to say have the Drag and Drop file operations as in RISC OS, an equivelent to the IconBar, Draw, DrawFile, !Draw, SpriteUtile, SpriteExtend, !Paint and BBC BASIC V. Though implement these in an Amiga OS API compatible OS on the ARM CPU, and the perfect OS is born. Remember this is just looking at the OS, not the extended hardware.
We are all aware of the issues with Amiga OS using code from TripOS for its DOS.LIBRARY. This ended up making the updated implementations of DOS in AmigaOS even better, as overcoming the limits pushed the best possible code.
This is going to have some influence on my OS project as time moves forward. As I would like to at least be able to see what could have been had the good concepts from RISC OS had been merged with the structure of AmigaOS all those years ago.
As a bit of a footnote; There are a few that seem to believe that the way AmigaOS libraries work would not work in a procted memory environment. This is a wrong view. The way AmigaOS libraries work is quite well suited to a protected memory environment, as they keep per task data spaces seperate, and use appropriate global data spaces. The method by which AmigaOS libries work is extrememly well oriented to protected memory. Unfortunately the same can not be said of RISC OS Modules, and hence part of the reason they are used in a privledged CPU mode almost universally. AmigaOS is one of the best examples of a future proof OS design we have, it is true that some features are not ideal (mostly do only to HW limits), though there is not as yet a better example.
I have also been looking at other information, including on modern OS and Compiler implementations. Some of these brag about having a huge number of lines of code, which seems to be a brag that they will always be buggy. The less code in a system the easier it is to debug and maintain. A compiler that is too large in code size is a huge liability, as unknown bugs in the compiler could be having an adverse effect on many programs that are compiled with said compiler. If a compiler (including optimizing routines) exceeds 50000 (fifty-thousand) lines of code it becomes junk, and I am not alone in that view. Remember with the important software, most code tends to, in its original form, have about 1 bug per hundred lines of code, and the larger the code base the greater the chances of a bug fix causing new bug.
And I end with a standards RANT : I have looked at the C standards as they have changed over time, and it becomes obvious that the latest usable version is that of C99. When you begin requiring language features in C that make it less portable by design you have stepped over the line in a reasonable persons view. As such adding things related to threading and such to the language standard is a huge no-go and a reason to never use a newer standard than C99. That said C89 really covers all needed usage cases. Threading is not the domain of the language, the system calls should be used if needed. C is trying to get as bad off as C++ has become for a long time.
|January 6th 2022 : Hopeful:|
I am prepairing some information for addition to the documents, as well as some small bits of code, in the hope of helping to further the use of computers, and the continuing use of older HW. There is also more and more interest in how to cause a new design to be such as to be able to last for long periods of time, as such it is important to note what fails and under what conditions in existing older HW (as well as newer when it does fail).
Let us see a future that makes long term usage of a computer a reality. Let us see a future where there is less waste in our landfills. Let us see a future where it is possible to use a personal computer long enough to cope with deep space missions, and other explorations that will prevent upgrading for decades or centuries.
RISC OS being an OS that can run on low enough spec HW to have low enough energy density to be able to last extreme periods of time. Once we figure out the HW design the OS and Software will still be needed. As such, it is hoped that any reader herein will take the time to think about the software they write. Try to get it running well on as low end of hardware as you can, as this will help its future usability in extreme long term personal computers. The need for lower energy density IC design in long term applications makes it so that the HW is likely to be quite a bit lower spec than what we use today.
|January 6th 2022 : BASIC Coding.|
I am working on a couple of side projects in BASIC to see what can be done. I am seeing if I can get a CDP1802 COSMAC VIP Emulator to run at realistic speed written 100% in BASIC V and running on the RPi SBC.
Of course still hoping to get the BasC Compiler to a usable point soon.
It is also of note that I am no longer using Horizontal Risers to seperate different posts within a single heading, instead using table background colors.
|Jan 4th 2021 : Added Two Docs:|
I have reorginized part of the site, and added two documents relating to thoughts on the future of RISC OS. One more general rant about not abandoning software compatibility, and one thought about a potential fork of RISC OS 5.26 or newer.
|January-2nd 2022 : Multitasking Comparison:|
As RISC OS is a strong focus of this site, and it is a Cooperative Multitasking system, it seems a good idea to look at the positive and negitive sides of both Cooperative Multitasking and Preemptive Multitasking.
It is common place to see people put down Cooperative Multitasking, even though in reality the multitasking model is just as good as preemptive multitasking. Some of the positives are different, some of the negitives are different, in the end it balances out well.
As such I am adding a document of my thoughts on comparing the two methods of multitasking. As with all the little documents I write it is linked in the Docs page. You can find the Multitasking Comparison Document at:
|January-2nd 2022 : 2021 Log Backed up:|
It is a new year and thus time for a clean Log page. The previous Log Page can be found at 2021-Log
I am also adding a post at the bottom of the Log page that will have links to older versions. Thus as the years progress from here it will reamain simple to find the older posts.
|Jan 1st 2022 : Split and Info Added.|
Today I have split off the Security information from the post of December 26th of 2021. I have also added information about why encryption is not secure, especially when relying on Public Key Private Key encryption to exchange the primary keys used. Further I have added information on how to securely exchange data over the internet, in ways that should remain secure for a while longer (before compputing speed gets fast enough to brute force attack the more secure encryption algorithms outputs for a key). As such I am hopeful that people will take consideration to the security of there information. Unfortunately these methods of maintaining security are still of no help for online commerce, so still have to take extra measures of security of your information there (like purchasing one time use disposable VISA gift cards for online purchases).
This new document to replace part of the log here is at:Information Security Online.
|MMM DD YYYY|
Here is a section to point to past log pages, will be updated anytime a log page is backed off the main log page: