All information herein is the view of the author. Use at your own risk, no warenty of any kind is provided.
December 30th : "Magic Numbers" in code:

One thing that has always caused me to wonder how others view code is the tendancy to avoid using direct constant values by some. Many will define named constants for use in code where the actual numeric value is more useful to the meaning of the code. Some will even look at code written by someone that sees the benifit of having numeric constants in place for many purposes and put the coder down for using "Magic Numbers".

There are a few places where using defined named constants does make good sense, like for the offsets in a library called in AmigaOS, or the SWI name instead of number, etc. Though for bitfeilds, or default coordinates, or default color value, or many other things, it makes the code harder to read when you use named constants in place of the numeric value. I do not like having to dig through includes (often recursively up the chain) to find out what value is being used when named constants are used where the numeric value is more informative in that place in the code.

This is a bit of a pet peave of mine. Why do people go out of there way to use defined constants when it makes the code less readable?

Yea todays entry is kind of a rant, though some good stuff is bolow the horizonatl seperator below this paragraph.

Splitting Some Off to Documentation:

Some of the longer posts currently on this page are going to get split off into individule pages in the documentation section of the site, with reference linkss provided where the posts currently are. This is so that it can be relicensed to be more usable to more people. This will likely take a little bit of time.

December 26th : Thinking Simplified OSes.

This post is about the possibility of what kinds of OS one may look at implementing for fun, as well as thoughts on how to make progress in implementing a new OS. The part many forget is that it works best if you Keep It Simple Silly (KISS) and have fun at it, do not overthink things it will just slow you down. Also avoid feature creap at all costs, at least until the first completely stable and complete version is finished.

At its core any OS is just a somewhat modular program that runs on the bare metal, with no other OS to help out. An OS is just the bare metal program that is intended to make life easier for programs running within its confines.

Modern Operating Systems have a tendancy to be a lot larger than they need to be for what they actually do. This makes for a large code base, and an increased risk of unknown bugs. For example the bash shell had a bug that was not discovered until 2014, the 'shellshock' bug as it is known had been in a shell from 1989 to 2014 (about 25 years) that is used so widely. Of course many of the security bugs being possible make one wonder who designed certain software (why would the command shell be involved in any way by a web server? Why would a servers software make possible unchecked file access, or even have such functionality? Why would you write software that allows remote control of a personal computer or server, over the internet? etc, etc). Or in some cases the security bug is on the user (who would put personal / private information on a computer that is attached to the internet at all? Who would put a computer that has a remote access protocal server software [X11, VNC, SSH, etc] on a network that is connected to the internet?, etc, etc).

Got a little off topic there. Though still things to keep in mind above, so I am leaving it.

The main point is that we need an operating that is of a KISS design and implementation. RISC OS is a good step in this direction. I am thinking that if someone could strip back RISC OS 5.2x to be functionally equivlant to RISC OS 3.6, though with the updates in place and new HW support left in place, we would have the beginning of a very good OS. Then it would just be the task of better modularising the kernel, making each component contain less code to make debugging easier. Stick with Assembly Language, this is an OS and thus should not rely on any HLL Shared libs of any form, as that is outside code that can potentially introduce bugs. Remember that there have been seen many a bug introduced do to unknown bugs in language specific shared libraries, so be cautious. Actually an HLL would work well, just avoid the standard library completely.

Something even simpler than RISC OS may be better, though RISC OS can be made fairly simple and keep the important functionality. In the interest of increasing the simplicity of the system, it would be interesting to find out what OS calls are actually used by any software at all. I would bet that there are likely a good number of calls that noone uses whatsoever, it is possible that pruning some could reduce the size of the codebase.

How to KISS a new OS:

With the overwhelming amount of information available today, and the knowledge of those that came before, it is easy to get carried away with the 'correct' concepts, and the concepts of all that went before you. It is also easy to get carried away with the 'research before design' as well as 'research of the best wat to do n'. As such it is important to remember in all cases it is more important to KISS (Keep It Simple Silly [other version well known]), getting it working is more important than any additional feature that you may feel is missing, or getting the best of the best methods the first time. You can always improve the code later, though if you never get around to writing it there is nothing to improve on.

There are a few things to consider when implementing an OS with the goal of getting something working without too much overhead (some of these could help even modern mega-OS implementations). These are just guidelines, nothing more, nothing written in stone.

  • Multitasking Model: It does not matter to much what multitasking model, if any, you chose. While many say that preemptive multitasking prevents a task from taking over, a zombie task can be worse than a frozen system. In either case poorly written software that does not consider frequent event checking can be a huge issue, well written software can be more responsive on a Cooperative Multitasking system. So implement which ever you wish, though stick to whichever you choose, changing this midstream can lead to issues. Also hybrid, primarily cooperative though with preemptive timeout tasking, can be simpler than pure preemptive multitasking.
  • Scheduling, Task: There are many task scheduling algorithms, the most important thing is that tasks get a time slice regardless of algorithm. Choose a task scheduling algorithm that you fully understand and are comfortable implementing, even purely round robin of tasks requiring execution is good enough. By all means do studdy more algorithms and learn from them, just do not get hung up on the implementation to the point of stalling.
  • Memory Mapping: If you choose to remap memory, to provide a consistant base address per task or for any other reason (including avoiding allocation fragmentation), use algorithms for implementation that you fully understand and are comfortable implementing, even if you have to learn the algorithm first. Also give some thought to the page size to be used, it is less work to use larger page sizes, so long as you do not need to swap memory to mass storage, so a page size of 64KB or 1MB may be a good fit depending on the needs of the OS. Remember that the Archimedes and A-Series ARM based computers from Acorn had a maximum of 512 pages total, so on newer systems with more than 256MB of RAM using 1MB pages is a logical equilivent, and 64KB pages would give 4096 pages per 256MB (8192 in 512MB). Now if you do implement swapping of memory to mass storage you will want as page sizes to be small, prefferably 4KB as this is a common HW level block size for newer mass storage devices.
  • Reentrant Calls: Even if you are doing a single tasking, or simple cooperative multitasking OS, keeping all system calls reentrant in the view of other code is important. In some cases this may require queuing the call and blocking the calling task. Also where reasonable to do so use the stack of the calling task, to keep data seperated by task. This is fairly easy to do if you give it some thought when first implementing the code, and it helps keep things simple. This can be of aid to any system, as has been proven with systems that did not do this and ended up having troubles with some user code in some conditions as a result. This is another case of KISS.
  • Disk Paged Memory: Swapping out memory to mass storage is a commonly used extension to the support of virtual address memory. This is a slowish task to perform, and unfortunately many systems use a fairly textbook LRU (Least Recently Used) memory swapping algorithm, that will use mass storage memory swapping even when there is plenty of physical memory. It is a lot more effecient, and a bit simpler in the end, to never swap memory to mass storage unless there really is not any physical memory available, and the disk / file cache has been flushed out to be as small as possible. Always reduce the memory used to cache files as the first way to achieve greater available physical RAM memory, only after that fails is it reasonable to look at what blocks are least recently used for swapping to mass storage, and then only if there is no other safe way to provide the needed memory. This simple solution would reduce many issues with existing OS implementations, as even the most polished often use too eager of page swapping algorithms. This is a case of KISS that will make your 'Hobby' OS into a huge improvement in memory management over most commonly used Operating Systems today. Idealy mass storage memory page swapping should never be needed, if you implement it please provide a user warning when it is in use, to warn them of the slow down and its reason, if you do not use it just give a well informative error to the user when all RAM is used up (always leave enough RAM reserved to provide error messages to the user and keep the system running). And this is just another case of KISS.
  • Signals: It is a fairly simple task to put a task into context and then call a registered call back function. A signal is little more than this, so keep it simple, do not overthink this one. Still a good idea to understand the concept, and how to best use it, of course. A form of signaling can be implemented even in a cooperative multitasking system, even though it is not common in a cooperative multitasking system.
  • Messages: A message is nothing more than an identifier with a block of data tied to it. The identifier is usually just an integer passed in, the block usually has a simple rule on the upper size limit to simplify copying it around as needed by the OS. The data depends on what is being communicated, look at existing systems for good examples. Again the cardinal rule here is KISS.
  • CLI: Make the CLI how you see fit. Just remember to be able to pass arguments. It is very useful to support some form of scripting. If you implement scripting, you can begin by simply having the scripts execute commands, and not worry about scripting control statement for the first get it working implementation. Again KISS.
  • FileSystem: If you are not familiar with many of them, take the time to studdy the on disk structure (or on mass storage structure, not always a disk) of the simpler filesystems. A filesystem does not need to be complex, even some of the better filesystems are prety simple extents based systems with a simple directory structure and a bitmap for freespace. A file system can be extrememly simple to implement support for, if you keep it simple silly. I would recommend fixed length file names (simplifies things) of no more than 31 characters (a file name is just that the name of a file, not an exhaustive description as some abuse it to be).
  • Device Drivers: Device drivers should be as simple in structure as possible, giving standard entry points for the device control calls per class of device, some shared by all device classes. All device dependant code should be in loadable device drivers, this will simplify life later and helps to KISS. To be clear, even a system timer, keyboard, framebuffer, even the MMU, any device should be handled by loadable device drivers without any exception. Again this comes down to KISS.
  • Devices: Devices can be implemented many ways. It is normal to have some form of file / volume level style interface for the devices where it is sensible to do so. A really good example is how Amiga OS implements many file accessable devices as 'DEVNAME:' where the trailing colon identifies it as a device (as volumes are identified this way, being just a type of block device used by filesystems). This level of abstraction is fairly simple to implement. RISC OS does similar, though the explination is longer (though the implementation just as easy).
  • Graphics Library: This is the part of the OS that controls the output to the display. It should support the well known vector drawing operations, a good range of pixel-mapped 'raster' graphics primitives, and support for native raster graphics and vector graphics formats. There should be a means of cliping output to a rectangular area (important to simplify any Window Manager using the graphics library), or alternative a line run clipping implementation if you are ambitious. It should also provide support for rendering bitmapped fonts (that are prepaired by a seperate font manager). Remember that on modern HW there is no such thing as a real text mode, everything is drawin in graphics, even the full screen text consoles in Unix like systems. Again do not get overwhelmed, take it a bit at a time and keep it simple silly.
  • Window Manager: Regardless of the rules of window management you decide to use, or the appearence the one thing that will take some experimenting with is implementing an algorithm to determine the visable (non-obstructed) rectangles for windows that are partially covered by other windows (including menus in the definition of windows here). Once you figure that part out the rest is a walk in the park, hence why there are so many simple Windowing System all over the place, including hundreds of them written as toys running on x86 DOS systems. Window management is easier than most think. You will need to keep the information about what application belongs to what window somewhere of course, and the data structures should reasonably include reference to the contents (controls, images, text-areas, etc). Scrolling is just changing the offset of the start of the windows area. The rectangle list combined with the clipping of the graphics library work together to simplify life in windowing. Again KISS, always it is easier if you remember to keep it simple.
  • Networking: There are so many good references on the various networking protocals, and how to implement them that this ends up being fairly simple in the end. Just remeber that networking stacks are always an extension, and not a feature of the OS, this will simplify life a lot for implementing an OS.
  • Look and Feel: There really is no limit here. Once you get the basics implemented the look and feel can be whatever you want it to be, within reason, without adding to the overall complexity of the system.
  • Whatever Programming Language: Some will try to push you toward particular programming languages, often they provide seemingly reasonable arguments for there pushes, do not let someone else choose the implementation programing language(s) you use in your OS. The only limit is that the language must be capable of producing executable code that will run witout an OS, beyond that use whatever programming language you are comfortable with, or want to for the project. Obviously if there are more than one developers working on the same codebase there will have to be an agreement as to what language is used, though even then so long as everyone agrees with the choice do not let outsiders change your minds. Again this comes down to KISS.
  • Have Fun: No matter what, implementing an OS will see some times that progress is slow, you have to do EVERYTHING in telling the computer what to do. As such try to keep it fun as much as possible, and always remember that you will learn something each time you implement another OS, especially if it is new OS. Always learn, have fun, and KISS.

In sumation: Do it how you want it done. If implementing an Operating System, have fun, keep it simple, and learn from the experience. If you happen to be trying to implement a RISC OS compatible OS I would love to see it, even while it is still a WIP.

Other than the recommendation to modularize the OS design, the guidelines above are intended to be as general as it can be. It is just a set of guidelines from one programmer that has learned most of it the hard way, take it or leave it.

This is a reminder for any software project to KISS. It is easy to get carried away, and overdo it, sometimes we just need to step back and look it what we are overthinking. If you learn or figure out a more optimal algorithm than what you knew when implementing something, you can always go back and beter optimize your existing implementations, by replacing the old with the newly figured out or learned algorithm.

As many of the posts in news tend to be bloggish I am debating changing the title of the page to LOG instead of NEWS. This would better cover the fact that it is both thought logging (weB Logging = Blogging) and news about what I am working in the background.

Even though some posts may cover other topics, the primary goals of the entries here are to further the use of RISC OS, give information about whatever I may be dooing, to help others with whatever they may be working on, and to have fun. And always KISS.

KISS Security.
This section moved: Information Security Online.

SITE Being Reworked:

Looking at a reword and recolor of much of the site. Needs to be less focused and more open in nature. I tend to overwealm myself from time to time, need to watch that. Instead of doing a subsite on retro and long term topics I will fold that into the main site over the next few months.

December 25th A fun thought for the holiday of today.

As today is a day for fun, I figured a good time to add a bit of a comparison between the Amiga 1200 with the Acorn A3020. These are computers released about the same time, both being the low end versions of there respective lines with full feature sets. As the Amiga was known for a few advanced features, and the A Series was the ARM RISC OS computer of the time, these being compared I feel makes some interesting points. I chose the Amiga 1200 instead of the Amiga 600 so that the perfomance abilities are not as much below the Acorn A3020. There are some areas where the Amiga has the upper hand, as I hope to show as well.

The Hardware:

CPU: The Amiga 1200 uses a 680EC20 CPU clocked at 14MHz, for a perfomance of about 2.8 MIPS. The A3020 has an ARM250 clocked at 12MHz for a perfomance of about 8MIPS.

Blitter: Area for area the ARM CPU can outperform the blitter abilities of the AGA, and do so with less than half its time (thus still outperforming the Amiga 1200 while soft blitting). This is why the Archimedes did not have these custom chips, they would have held no advantage at all, the CPU was already able to take full RAM bandwidth, so soft implementations could outperform others hardware.

SOUND: The Amiga 1200 has the well known 4 hardware channels of 8bit PCM sound, with each two channels fixed to a sterio channel (2 for left 2 for right) with up to 56KHz sample rate. The Acorn A3020 has 8 hardware channels of 8-bit logarithmic sound (sounds better than 14-bit PCM at same sample rate) with up to 96KHz sample rates, each channel can be set to whatever stario position you want (not tied to a sterio channel)..

GRAPHICS: For effects and blitter type stuff the Amiga 1200 has hardware, though the ARM CPU can still outperform the AGA + 680EC20 for any task (sometimes a single faster memory master is the fastest choice). The Amiga 1200 does have the advantage of HAM-8 mode allowing up to 262,144 colors on screen with limits. The Acorn A3020 is capable of up to 800x600 in 256 colors at SVGA refresh rates. The Amiga 1200 can do 640x480 at VGA refresh rates or 800x600 using flickering interlace mode, again in 256 colors.

MEMORY: The Amiga 1200 supports up to 8MB of FastRAM and 2MB of Chip-Mem. The A3020 is limited to 4MB without adding MEMCs (only has one MEMC). So a small favor of the Amiga here. Also note that you have to know the computer well to configure support of more than 2MB on the A3020. To note there are other A-Series Acorn machines that are of the same time and can support up to 16MB of RAM.

HDD: Both machines support a 2.5 inch ATA/IDE HDD, and commonly have either a 20MB or 40MB unit fitted.

Floppy Both machines have one builtin 3.5 inch high density floppy drive, and both could support up to 4 total floppy drives. The formatted capacity of the Amiga was slightly higher than that of the A3020.

Core OS Features:

Ok let us look at the core features of the OS. This is just what can reasonably be considered the core of the two OSes, that is what makes them the OS they are. Extensions that are normally included in these OSes will be covered in the following section. The OS versions being compared are RISC OS 3.11 to Amiga OS 3.1 (it is an interesting irony how these two versions line up in time).

OS Style: Amiga OS is a microkernel OS that uses shared library type calling. RISC OS is a monolithic kernel OS that uses modules to add functionality, and is called via software inturrupts .

Memory Protection: Amiga OS does not provide any form of memory protection at all. RISC OS provides some application level only memory protection.

Multitasking: Amiga OS is a Preemptive Multitasking system from the core up. RISC OS does not support any form of multitasking, except for WIMP programs, then it is Cooperative Multitasking that is managed by the WIMP. Both have there advantages, neither is good or bad. Remember that both forms of multitasking began as hacks, preemptive as a hack to allow multiple simultainous users on a system through terminals, cooperative to allow single user systems to perform background execution. The memory protection model or multitasking model do not magically solve problems of poor programming like many seem to think it will.

Inter Process Communication: In RISC OS IPC is accomplished by sending messages through the builin system in the WIMP, these messages are numerically identified and delivered at the return from WIMP_Poll calls. In Amiga OS you have true message passing, as well as the ability to raise a signal to another process. Signals are used where responce time should be minimal (like Intuition events for an application [intuition is the Window Manager]).

File I/O: On the Amiga OS file I/O is handled by AmigaDOS, and on RISC OS it is handled by ADFS and FileCore. The AmigaDOS File IO is fairly standard in nature for a preemptive multitasking system, though with the ability to easily extend (as with most of Amiga OS). On RISC OS on the other hand we have a file I/O system that is quite unique, and primarily works at the block level for most operations. It multiplexes read/write/modification calls to the OS through a couple of calls, and is not as effecient as most of the OS is.

Default File System: The on disk File System that is the default for the OS tells volumes about the OSes file handling. FFS is the default for Amiga OS, ADFS is the default for RISC OS. FFS is a reasonably layed out file system, with a significant number of flags for access and usage management per file, difficult to fragment files, 31 character filename support, and clear usage. ADFS on RISC OS 3.1 is a very simple filesystem, supporting up to 512MB volumes, allowing 10 character filenames, and able to store filetype metadata seperate from the file name. As a note, RISC OS does not have any native support for disk partitions, though Amiga OS has support for unlimited numbers of disk partitions.

WIMP: Windows, Icons, Menus, and Pointers, let us look at the Window Managers of these two. Both of these support having window depth be independant of what window is active, both are intuitive to use. RISC OS does not need standard file dialogs, instead using the main file manager windows as drag targets (and eliminating the well known complaints about standard file dialogs on all systems), Amiga OS does use standard file dialogs for saving and opening files.

Default WIMP Shell: In RISC OS it is a combination, called the Desktop, consisting of the IconBar, TaskManager, Pinboard, and Filer(s), mounted volumes are on the IconBar. On Amiga OS we have the Workbench which provides the desktop environment including a spacial file manager with mounted volumes on the desktop.

CLI: RISC OS has a CLI that is a bit difficult to explain in little space, it is quite different from any other OS you are likely to have used, though it is fairly intuitive once learned, scripting is a bit limmited though. Amiga OS has a CLI that has many similarities with well known shells, though is unique in a few ways and well suited to the OS, also supporting some fairly advanced scripting tricks. Realy can not give a good comparison in a small statement.

Included With OS Extras:

Extras included with the OS, that are not a core part of the OS. These include things like the standard applications, network stacks, network applications, visual enhancements, programming languages, etc.

TCP/IP: Neither RISC OS 3.11 or Amiga OS 3.1 originally came with any form of TCP/IP. That said later systems sold with RISC OS 3.11 as well as Amiga OS 3.1 included TCP/IP stacks and some standard networking software. Amiga OS implements the TCP/IP using a Berkeley sockets type implementation. RISC OS uses a Socket like API accessed through the normal SWI OS/module call mechinism.

Standard Bundled Applications: BOTH HAVE: A Text Editor, A Clock, Debugger, Preference tools, Calculator, Memory Usage monitors, Disk Formating and Checking tools. ONLY RISC OS Has: Paint program, Vector Drawing Program, Screen Magnifier, x86 PC Emulator, BASIC Interpreter. ONLY AMIGA OS Has: Line Editor, Installer, Icon Editor (RISC OS uses Paint instead), Mouse Cursor Editor, AmigaGuide (a hypertext help system).

Extra Applications Often Included: Both have comparible sets of extra applications bundled with different computers running these OSes, or later different distribuitions of the OSes. So not a lot to say here. In both cases these include FTP Clients, Web Browsers, Programming tools, Better Text Editors, Games of various kinds, Terminal Emulation software, Graphics editing programs, Sound Programs, etc.

Included OS Extensions: Libraries on Amiga OS and Modules on RISC OS, those that are above and beyond the core OS and not mentioned in other paragraphs. For RISC OS these include SharedCLib, Econet, SharedSound, NewLook, ToolKit. For Amiga OS these include Datatypes, BOOPSI, MultiView.

Common Third Party OS Enhancements:

WIMP SHELL REPLACEMENTS: RISC OS is the only OS I know that does not have any that I can find. AMIGA OS on the other hand has a few, best known is Scalos.

DESKTOP ENHANCEMENTS: On RISC OS we have NewerLook, IconZ, verious Icon packs, FilerPlus, Thump. On Amiga OS there are many, including MagicWB, NewIcons, GlowIcons, MUI (MUI is also a programming API), and a lot I am forgetting at the moment.

Applications available.

In this section I will give a very breif overview of the types of applications available on the two systems. This is just a quick overview, to go into depth would take months for each system, and would create a document of many MB in size (if plain text).

Raytracing: Both have some really good Raytracers. It is arguable which are better, though there is no question that there are many more for the Amiga than for A-Series RISC OS machines. Maybe a bit different if we included later RISC OS computers, though then later Amigas also have more.

Vector Drawing: There are a few on Amiga OS, none near the quality of what RISC OS comes with standard. RISC OS has a very strong point here, having many diverse and extremely high quality Vector Drawing programs. Though as RISC OS comes with a very high quality Vector Drawing program this is to be expected, the others have to be better than what comes with the OS.

Programmers Text Editors: There are maybe 5 of these for RISC OS, 2 that are well known (StrongED and !Zap), !Zap is fairly well featured without being to big, StrongED is a beast. On Amiga OS there are hundreds, of varying quality. The Amiga OS ones I know personally are no where near the quality of !Zap, though I only have direct experience with a few on the Amiga.

Word Processing: It seems like RISC OS has a better variety of Word Processors. Though this is a somewhat subjective statement, as it is hard to do well with comparing. The early ones put RISC OS ahead in abilities, though later Word Processors on Amiga OS surpass what RISC OS has.

Spreadsheets: By the numbers Amiga OS has more Spreadsheet programs than RISC OS. There is not much to improve on in a Spreadsheet program, so realy there is not any contest here.

Math Graphing: This is an area that the A-Series RISC OS machines have a huge advantage over the Amiga systems, especially when graphing in 3D. This is likely a side effect of the early use of 3D flat shaded graphics on the Archimedes / A-Series machines combined with the enjoyment of playing with 3D-Graphics in BBC BASIC and then converting to ARM Assembly, that is my take anyway.

CAD/CAM: In some areas RISC OS has a slight advantage on the A-Series machines here. Though the Amiga has more software in this area, and better support for industry standards.

Movie Software: Obviously the A-Series RISC OS machines have a huge advantage here do to the power of the ARM. That said there is more available for the Amiga 1200 than for the A-Series machines, and much of the Amiga stuff is quite a bit higher quality.

Electronic Design: Both machines have a lot of software available in this area. In both cases there is a lot that follows industry standards in this area. I personally feel that using the A-Series for this is easier, largely do to the faster evalution of simulations of Spice definitions.

Programming Tools: Beyond the included BASIC and Assembler, there is not a whole lot avalibe for the A-Series machines, which is a bit of a surprise. The Amiga on the other hand has an unbelievably huge library of programming tools of all kinds, from many language compilers, to debuggers, to resource tools, etc.

Games: While I have found that a lot of people seem to use Games as a system metric, it really is not for the geeks that were in the group I know and knew when these machines were somehat popular. For us it was much more likely for us to play games coded by each other and openly traded than to play commercial games. That said for commercial games both systems have a library large enough that it is unlikely you will ever play all of them in either system. The Amiga library of commercial games is without question a lot larger than that of the A-Sereis RISC OS machines.


Both systems have there pros and cons. From the standpoint of the Hardware Capabilities the A3020 wins hands down. Though from the standpoint of total available software (if that is your strange metric) the Amiga wins hands down.

From the standpoint of the merits of the OS: The Amiga has the technical side hands down. RISC OS has the user interface side hands down.

Even if you are using one of these older computers, it is likely that your main RISC OS or Amiga OS computer is much newer than either of these, and it is likely that the HW comparisons are near meaningless when we get to modern RISC OS and Amiga OS OS compatible Computers (Amiga OS Comatible OSes include WarpUP, AROS, MorphOS).

For some reason that makes no sense to me, RISC OS never had many third party replacement components, unlike just about every other OS I know of (including Amiga OS), much less a full clone OS. As RISC OS was a highly hackable and easy to understand OS it makes little sense that noone wanted to code replacement components for any significant part of the OS, not as surprising that there are not any clones.

I would say that in the end, whichever OS you prefer to use and code on is the one that works best for you. There are a number of other things that could be compared, though for a quick Christmass fun post in the news page, this is quite enough.

December 20th @ 14:00 News of ARM.

Timing, ARM is possible. Less than an hour after making the entry for December 18th (removed the entry from the 18th, as this replaces it) I was sent some information from another interested in pushing forward extreme long term computing. That information was about a project in progress to create a 500 nanometer (0.5 micrometer / micron) implementation of a CPU that implements the ARMv2a ISA (ARM3/250) without cache as well as some support ICs, including a functional clone of the MEMC, and VIDC1a (not the IOC though). So ARM is back on the list.

Curtis tells me that the project is going to implement a 7-stage pipeline version of the ARMv2, that is significantly faster than the original at the same clock. As it has no cache and only a 32-bit data bus it is still limited to executing no more than one instruction per cycle. Though it is supposed to be a completely static CMOS implementation of all ICs, and is intended to have an operating clock of up to 75MHz within the power density requirments for extreme long term computing.

One notable difference in the extended chipset is that the MEMC assumes the use of a full 16MB usable address space, and does not provide for refresh, being designed to take advantage of the fact that we have fast enough CMOS SRAM available now that is affordable. If I understand correctly there is also a provision for paging in more memory with a set of 64 base registers for each 256KB chunk, if I understand correctly.

The ARMv2a implementation also provides a full 32-bit address bus. Being ARMv2a ISA it is required that any code be mapped into the first 64MB of address space do to the limit of R15 being combined with the Status Register. That said data can be fetched from anywhere in the 4GB address space without any problems at all.

While it is great that the MEMC (basically as 4 of them in one die) is part of the spec for software compatibility. Though even if we keep the MEMC a secondary MMU is something that seems should be considered as well.

The VIDC implementation is supposed to be 100% compatible with the original, while adding higer bandwidth and clock abilities. That is to say it should support much higher resolutions, thogh still limited to 8bpp and 8-bit logarithmic sound.

As such we also need to port RISC OS 5 back to the 26-bit R15 world all over again (it was ported to the 32-bit R15 world from the 26-bit). RISC OS 5 as that is the only current open source version of the OS. This is great, and I am hopeful they or someone will end up updating the VIDC to output well to devices other than just analog RGB monitors (like MultiSync, VGA, NTSC-RGB, etc), as we still do not know for sure what kind of display will end up being practical for extreme long term usage.

It is going to be interesting to see the updated RISC OS running as a 100% compatible to RISC OS 3.11 again. It is interesting how things circle, is it not? It will also likely be a challenge to get everything back into a 2MB ROM image again, as RISC OS 5 has not had this limit in its life (last RISC OS to be 2MB ROM is RISC OS 3.5). The removed HW support, getting rid of the HAL, and reimplementing the HWsupport needed for the ARMv2 setup will likely save a lot of space. There are a lot of ROM Modules in RISC OS 5 that would not serve any purpose in a 26-bit R15 system with 8bpp graphics, 8bpp logarithmic sound, none of the USB crud, a simpler set of filing system modules, etc.

Based on what I am told they do not see any issues from ARM, though they are working on trying to get in contact with the correct people at ARM to verify that there will be no issues there.

It is much simpler a matter to include the needed BASIC implementations, as a BBC BASIC V interpreter is part of RISC OS, and it is a lot easier to implement others on a RISC OS system than on a lower end system. Further the compiled languages are a simpler task, as C is already available, and there are a number of others. Unfortunately there does not seem to be available a decent Extended Pascal compiler (the closest being an ISO Pascal that lacks most of the features of Extended Pascal). There are also many assemblers available, simplifying that task. Not to mention that for a machine language monitor, that is built into RISC OS as part of the debugging commands.

NOTE: For more details, wait for my retro / experimental computing sub-site to come into being. That section will focus on both the long term computing goal (the experimental part) as well as the current usability of the lower end systems (the retro computing part). There will be information there on this project as well as CDP1802 based stuff, 65C02 based stuff, and even a little DLX based stuff. Of course it apears there will also be additional RISC OS and ARMbased information there, as an addition to the RISC OS and ARM stuff on the main site.

As a bit of a note, it is sometimes frusterating that the laws of the country in which I live prevent me from getting into any in deapth information on encryption and my usage thereof. I have developed a few simple, though highly secure, encryption algorithms that I personally use. I can not share any of them, as they were developed by a resident of the USA, and do not have approval for being shared internationaly.

I do strongly encourage everyone to studdy encryption, especially modern 'Strong Encryption'. It is a lot simpler than most give it credit for, and a very worthwhile area of studdy. It is also fun to play with encryption algorithms, not to mention that slightly modified versions of these algorithms often make good random number generation algorithms (a lot better than the standard language builtin random number generators), so useful for more than just keeping data secure.

December 17th @ 19:00 A few quick items.


I very much like the overal structure of RISC OS, as well as the User Interface (both CLI and GUI). The calling convention is very much tied to the ARM CPU. These things combine to make one wonder what an OS that is modeled after RISC OS, though targetting CISC CPUs would look like.

The issue comes down to the study of long term computing. There is no longer a very low end ARM that has very low power density available, so no ARM for RISC OS on a very long term use computer. I am hoping to still find something ARM to use in the research towards very long term computing, though I must be realistic at the same time, as the low power density ARMs available are all THUMB Only, at least that I can find. Will someone produce custom silicon of the ARMv2 again, at the same or lower power density to the original?

Of the low enough power density CPUs available on the current market, and being well enough known to be widely easy to develop for, we have:

  • The WDC65C816S : This is the high end of the qualifying CPUs.
  • The CDP1802 (COSMAC) : This is the low end of the qualifying CPUs, though having many other advantages for the application at hand.
  • The Z80 (in CMOS) : There are a few varients of this one, though the higher end ones are off the list.
  • The WDC65C02S : A very realistic possibility.
  • The MC68SEC000 : Technacaly low enough power density, likely to stand the test of time, though some implementation dificulties.
Yes that is really all I can find for desktop CPUs that meet the needed qualifications to be of consideration, and are still produced. There are pros and cons to each and every one on the list. In any event, they are all CISC CPUs, no RISC on the list, so it is time to consider a CISC OS modeled after RISC OS as much as reasonable (at least in the most important regards, not complete by any means).

Regardless of what CPU from the list we end up with there will be a need for some bank switching to extend the address range. Of those available the most capable provide for 16MB address space, and the most useful only has a 64KB (16bit) address space [the CDP1802]. Of course there are the other HW considerations still to look at, though this gives a starting point, good enough to write a good part of the OS.

It is worth looking at the different APIs for calling Acorn MOS from different CPUs, as many different CPUs were used on the TUBE in BBC Micro computers, all of which could make calls to MOS. As the RISC OS API evolved from the MOS API this will give a decent starting point in figuring out how to implement a RISC OS like API in a low end CISC CPU. At minimal beyond the normal MOS we will need:

  • OS_SpriteOp functions.
  • WIMP, and Desktop implementation.
  • OS_Mouse and related.
  • The sound system.
  • Extended Screen OS_ Functions.
  • Filer(s).
So the list is small enough to be doable, noting that that is just what normal MOS does not have (as a complete MOS implementation is a given). The API can change a little from the original as needed for the HW difference.

It is likely that the WIMP API will be based more on the Windowing System for the BBC called the "Acorn User Windowing System". With some additions from the WIMP this API will allow for a reduced size implementation, thus saving space on systems that have a smaller address space.

BASIC Compilers.

In a way I slowed myself down in working on the BASIC Compiler (BasC). This is largely do to now needing to target more than just one CPU, as well as some issues getting it to run fast enough when compiling on lower end HW. So I mus apologise for not being able to have it done by the end of the year.

The biggest issue is attempting to get the compiler to fit into small memory systems while still maintaining performance. Unfortunately Compilers take a bit of RAM by there nature (as they need some form of stack, the space for the source, the space for the object code, and some work space) unless you want extremely slow by using file storage for intermediate parts of the compile.

My hat is off to Wilson for the best BASIC interpreters of there time, and the ability she has in there implementation.

Long Term Computing.

As noted above, the best canidate for CPU is still the CDP1802, though others are potentials as well with much more added HW to allow support for loading without a ROM and such.

There is also the possibility of using a custom TTL CPU implemented in 74HCxx logic. This would be likely to make the time span as well, so long as it is not clocked to high. This is another option I am looking into, and I have also mentioned to others involved in this research line.

For myself I am taking some time each day to code in CDP1802 machine language, as good practice for the CDP1802 version of the project. Though I am also playing a little with the other ISAs, including two designed to be easy to implement in 74HCxx logic (one 8-bit one 16-bit). So we shall see what potentials come up as time rolls on.

Another area that there is still a lot of questions around is that of the display device. A relitively low voltage oil-film CRT projection devices looks the most promising. This uses a seperate light source, and the CRTs electron beam tunnels through an opaque oil film to allow the light through the screen, then it is usually projected onto a secondary screen. This is a good solution for Black and White or Grey Scale, and can be used for color if 3 CRTs are used together and projected onto the same screen. The biggest known disadvantages are keeping the device low enough power also limits the clear resolution available, and it is a tube (though one that can be maintained, re-evacuated, and resealed if needed) with the heater issues known from other vacuume tubes. The issue of resolution is easy to deal with, just put a significant limit on the maximum resolution of the display, this will also simplify the issue of making a video controler.

Another likely possible technology for display is to use very small descrete LEDs on a specially designed board, with one LED per pixel color element (3 per pixel), and either rely on POV and quickly count through them or have a flipflop each. This is a definite potential tech for the job, though more research on long term reliability is needed, and it is also limited in potential resolution, so again keep the resolution down.

Then there is the issue that the entire system should be implemented as 100% static core in nature. There are a good number of reasons for this, though the most basic is the lack of any need for ROM code and the ability to keep the system in an active state when in 'power down' mode. There will need to be a storage capacitor that is suffecient to keep the system state intact with the clock paused for at least one decade. The capacitor for storage is fairly easy to do, without using any electrolitic or super capacitors, so long as the physical size being fairly large is not a consern (a wax film coiled capacitor measuring 4-inches diameter and 12 inches length and having a capacity of 20 Farads is fairly easy to accomplish). As such all CMOS components, and all static components will be of extreme importance to the design of the computer itself.

The mechanical components will just have to be made to the best ability of the designers, with an eye on how easy repair is even without any of the parts still being available (either no longer made, or not able to be delivered in the case of manned space flight or other extreme isolation). This makes very simple ball mouse designs very much the way to go for a pointing device, and it makes a keyboard design that uses very simple direct contact shorting instead of actual swithces prefered (think membrain/chicklet keyboards, though improved [and idealy with decent key caps on top] in design).

Sound is an open question. how do you make a speaker that will not fail for centuries of potentially continous use, and is easy to repair if it does fail?

There are still many questions to be answered in the quest for a multi-century usable personal computer. Traditionally manufactures do not attempt to make things last more than a few decades, as it is not usually considered practical. We are looking at a new concept that MUST BE SOLVED before we take flight through the stars, and while manufacture of the needed components is still available to make the many needed units.

It should be noted that there has been interest outside of just computing applications in this goal. It is needed to make all systems on a long term isolated craft to meet these goals. That is everything from simple plumbing to life support systems, to waste recycling systems, to gardening, to lighting, etc, etc. These are the challenges that we face the need to solve for the first time in the history of our time in existance, or at very least the time humans have been on earth (some think we originated on another plannet, who knows).

Also remember that the use of what we learn for very long term computing can help here on earth as well. It can give a way to move forward in developing technologies that will be useful by generations for centuries to come, thus reducing the polution from desposing of what we use so often. Just imagine a world where we upgrade our computer when application need is the reason, and then unlikely to happen more than once in 2 centuries, a lot less polution.

COSMAC Computing

I intend to create a page about COSMAC CDP1802/CDP1801 computing in the near future, just need to make sure I get the information correct. Said page will also cover the RCA System-00 by Joseph Weisbecker, as that is the first implementation of the COSMAC ISA (also known as the FRED [Flexible Recreational Educational Device] Computer), as the early System-00 implementation includes other concepts that are helpful for long term computing (such as an optical punch card reader).

Needless to say the idea of the section related to COSMAC Computing is three fold, being to look at one of the most fun of the 8-bit CPUs to work with, for RetroComputing application, and for Long Term Computing. There is little question that playing with the CDP1802 and related HW is fun in many ways, it is also well known that it is relitively easy to bring up a COSMAC CDP1802 system without any need of ROM code at all. The CDP1802 is well known for being reliable as well, including multiple deep space applications already under its belt as it were.

Nov 30th @ 06:00 Update of Methods 2.

The BasC compiler is making progress, other projects not as much so.

I have been looking at many things, in how to move into the future. There are some interesting questions I am asking myself in the process of this, to best do what is needed. I have been doing a lot of studdy, including to an area people do not think about. RISC OS is the vehicle of choice for me in computing, still I add the following questions into the mix.

  • What does a multi century usable personal computer look like?
  • What does an OS that is simple enough not to have any serious bugs when done, to run for centuries without maintainence look like?
  • Why have we not considered long term use designs in the world of personal computing?
  • What kind of persistant storage can be reliable for centuries without concern?
  • What components would we need to make a multi century use computer reliable?
  • When maintainence is needed, how can we help assure it is easy, no matter what is available at the time (possibly centuries in the future)?
  • Can the OS be as great as RISC OS?

These are difficult questions, though they are also important questions. We are looking at the possibility of deep space travel as a real thing, this could include the need to have systems without waste for centuries at a time. We are also busy messing up the earth by constantly going for newer computers, so if we can reduce this by using multi century personal computers where they fit in, then this would help us survive as a species, as well as all the others on earth. These questions require a look at what we have seen work/fail in the last 50 years of personal computing.

In this mission I am not alone. Indeed my interest was peeked by questions by others in the need for extremely long term maintainable systems for space travel, as well as some related concerns for our little space ship called earth. There are many interesting ideas and questions in this area. It is quite interesting that the question is tied into Space Travel, an area of human endevour that is as new as single user at a time computing, and has been aided by the evolution of small computing technology.

A reliable system for multi century use would have to use a CPU that does not produce much heat in operation, as that is what kills CPUs most often. So it would be a low end CPU. Minimizing possible ESD issues to a more extreme extent than what we normaly do is yet another concern. for RAM Memory is an area that I am not sure we have a long term option available, though for IC based memories the best option apears to be Static RAM. Long term storage, that remains available at all times, is another thing, we definitely have a problem here to which the answer is not yet known. Back up storage, designed to stand the test of time, all we have is Paper Tape and printed output, nothing else is known to be that reliable. Then there is the question of capacitors, someting quite important to the design of a computer, to last centuries they can NOT BE Electrolitics of any kind, otherwise research is needed. For human input, we may be stuck with less comfortable keyboards, and other devices that can be easily repaired regardless of available manufactured parts (membrain keyboards, with a durable membrain design, are easily repaired or recreated even in extreme limit of material), same for mouse/joystick type devices. For real time output, this is still somewhat an open question, many think that it is possible to produce a kind of CRT that could stand the test of centuries in use, almsot everyone agrees that an LCD would fail long before then, noone knows for sure how the integrated circuit purely LED displays could hold up to time. For persistant output (printed), we would need to figure out a printer design that is easily repaired even without replacement parts made, as this is a device for which ware is the biggest issue.

As this area of studdy has my attention very strongly, and to a point has for a few years now (I just have not said anything till now), it has built to the point that much of my software work will have something to do with this question. I will likely create simple computer emulators to test out software side ideas for this issue. I will also be recreating a simple digital logic simulation program suite that I used in school, I still have the source for the version that I used in shcool it is just a matter of porting it to RISC OS (originally ran on bare HW on a Z80 computer with a lower resolution black and white display).

Do to the requirements of a multi-century computer I am looking closely at the COSMAC CPU design from RCA, as well as the various PDP-1/7 and PDP-11 concepts. I will also be looking at others, though many are already off the list because they do not easily meet certain requirments, or they have already proven not to last long enough in regular daily continous use.

Sept 27th @ 17:30 Update of Methods.

Do to !Zap crashing and taking out three HTML documents of my Assembly language tutorial with it (not frequent enough backups), by messing up the contents in strange ways:

I have switched to using a bit older version of !SrcEdit for all my text editing. This includes HTML, BASIC, Assembly, Text files, etc.

This should not effect anything as far as others are concerned. Though I will be adding hidden comments in my HTML to compensate for the lack of syntax highlighting, so some pages will be a bit larger than they would have been for the same content.


Needless to say, as soon as I get things back in shape, fixing what Zap destroyed, I will have a few of the Assembly Language tutorials online. I should be uploading them next time I am online.

Sept 24th @ 3:00pm

I am going back to a lifestyle that only has internet access at certain times and days. As such any updates will only accure when I have internet access. Most of the time this will be on Sunday Mornings.

In order to make this work I will update the local copy of my site as needed, then sync the online copy when I have internet access. As such you may at times see suden bursts of information with dates as old as a week before they appear on my site.

Sept 22nd 2021 @ 08:30

Do to some modification in the spec, along with a bit of a code change that was made this morning, the a BasC Compiler is likely to progress a little faster than planned. To be on the safe side of things I am still just expecting by the end of the year, so keep an eye out.

I have also made the decision that my last ever significant C project is to be MSysLib. C is not a language for me.

Sept 21st 2021 @ 13:45

Finally got the site in order. Now in the basic format it will continue to be in for the forseeable future.

If all goes well I am anticipating getting the first 8 Assembly Tutorials up within a week.

It is looking like it will be very soon that I get the first pre-release of MSysLib up for download.

On BasC the BBC BASIC Compiler I have been working on off and on for years: It looks like something useful should be available for download by the end of the year. I ended up progressing with this project instead of just documenting and cleaning up the source.

Sept 13th @ 18:45 : A Path Forward

In the process of increasing my focus on fewer projects I have been attempting to put together a path forward over time. So that as I reach the stage of release version complete of a given project I will be able to have an idea of what to focus on next. I have a pretty good start to this path forward, and think it will work out well.

For details on my intended path forward with programming projects on RISC OS please see the document I have added at : The Path Forward:

Sept 13 2021 @ 05:00 : ROOL Site Back

As anticipated it just took a little time to see the ROOL site back online. Do not yet know whtat the problem was (will update this article once I find out), though they are back up now.

On the positive side of things, at least there was the opertunity to talk about the possibilities of the future. This including an article that I quickly typed up over two years ago, and decided to put in the documents section of my site yesterday at : Using RISC OS Puts Us in a Unique Place

I had written the above mentioned article shortly after RISC OS went Open Source. I had debated posting it a number of times, though decided to wait. A good time was when the ROOL site was down for over 24 hours, as it highlights the potential of things changing in the future. Remember in the 1990s no one expected Acorn to close shop for desktop computers, though they did. After that no one expected that the development of the other branch of RISC OS would end, it did.

Now we have one area of a future proof OS, in that it is Open Source. It is time to look at the other areas that may not be so future proof in the way things are handled, and the above article highlights one of those areas very clearly.

Sept 12th 2021 @11:00am Az std Time : Where is ROOL?

Last night when I went to ask a question on the RISC OS Open Limited forums, I found that the server was not responding. I figured it was a little hiccup, that may last an hour or two. After getting a full nights sleep I tried again, there servers still remained unresponcive. And here it is, 14 hours after the initial try, and they are still unresponsive.

I am hopeful that this is a short term issue that gets resolved. Though it does raise questions, as we have lost a lot of prominate RISC OS sites in the last couple years (many within the last year alone).

This brings to mind questions of the future of our great OS. Do we have the most recent version, never to see anohter from ROOL? If something happens to ROOL and ROD then is there enough interest to keep development going within the comunity (now that the RISC OS codebase is Open Source).

I think it likely that the ROOL servers will be back up by tomorrow. Though this prolonged outage does raise a few questions of the future.

As RISC OS users we have been on a roller coaster ride since Acorn fell. We say the rise and fall of a completion of RISC OS 4, and some follow ons. We saw many RISC OS Machines come to market, and companies dissapear, or stop producing the HW. We have watched, from the Iyonix on, the rise of the end user version of RISC OS 5.x, its extreme uptake in responce to the Raspberry Pi. We have seen both great progress and dissagreements over how to move forward and support newer HW, and provide appropriate APIs for software. We have seen many companies around RISC OS come and go, more going than coming. We have seen the dissagreements cause some of the RISC OS Greates to abandon the public forums do to dissagreeing with how thing are going. We have seen other greats return to RISC OS in a big way.

In the end any time there is a dissruption, some of us think about what could happen if the end of what we have left is seen. In the past 10 years, since getting into the 32-bit RISC OS as provided by ROOL, this is the first time I have seen there site down for more than an hour. The fact it is been down over 14 hours at the time of this writing, is a bit scary.

Sept 10th 2021 : Moving forward.

As a quick note, the page layout is a bit wider, to accomodate a larger font size. This will propogate to all pages of my site as I update them.

I am focusing on two primary projects for the time being. These are my MSysLib bindings for C and my Starting ARM Asm tutorials.

Sep 09th 2021 : A theme change in progress : UPDATED.

The site update is slightely sowed down. I found out that the combination of font size and color scheme that I was using was not very readable by some. As such I have went to a higher contrast color theme. To keep it readable to people with good vision I am doing it light text on dark background.

As to the font size issue, I realized that most that have poor vision will have there web browser (eg Netsurf) setup to display pages with a default magnification greater than 100% (like 120% or something [in the same way I have it set to default to 80% do to good vision]). As such I am sticking with the font size.

Needless to say it may take a couple days to update all the existing pages in between working on my main projects.

I am hopefull that the change in contrast is suffecient. If not another update will further increase the contrast.

Sep 08th 2021 : A Refreshed Focus Forward.

I am revising my site, and my ethos toward my projects. The revision of the site is in reflection to the change in attitude towards my coding.

I have not gotten any of my large projects complete, as I am trying to work on too many large projects at a time and thus not making good progress on any of them. This is changing now, I am learning to focus on fewer projects so I can get some of them complete, then move on to a few of the others.

New Days Entry.


This site created on RISC OS using !Zap and !SrcEdit.
Hosting for this site provided by David F
This page viewable with Any Browser