TBAFS 32bit 1.03 Released

A new version of TBAFS 32bit has been released for download.   This fixes a bug in the TBA (Fast) decompression code that was introduced when it was converted to 32bit.

Bristol RISC OS Users Group

I've just got back from an enjoyable evening with a few members of the Bristol RISC OS Users Group at the King William in King St.  A short 2 mins walk from my Bristol flat it was a most convenient location.  It was an evening of talking about everything computing, and lots of interesting opinions about what is good and bad about RISC OS, Windows, Linux, Printers, Nuclear power (!), and much more...

While my work as an IT Director has lead me to use Windows and Microsoft .NET for systems development, it was great to hear some enthusiasm for RISC OS and the simplicity of the Acorn computer.   The pragmatist in me knows that RISC OS is unlikely to get the kind of development it needs to bring it up to date, but we can all dream a bit and think what could or might have been...

Some thoughts....

RISC OS occupies a fairly unique space in that it is a native ARM operating system, and isn't Linux.  It has the potential to attract many developers and enthusiasts from the Open Source community who would like to work on something with a lot more potential for improvement.  Regular sustained publicity is the key to this and nobody would suggest its an easy thing to achieve.

From a development perspective my view is pretty clear on the main thing that is needed for RISC OS.  In my opinion this surpasses all others as it is critical for using modern hardware and porting applications.

The kernel needs a pre-emptive multi-tasking system, allowing a typical mix of processes, threads, synchronisation objects, memory management, and security.  This is the "new world" that is essential for dealing with modern multi-core ARM hardware.  The "old world" would then run in a single thread bound to a single processor core with interfaces to communicate with the "new world".   After initial fixes have been made to the core OS code (SWI handler, interrupt handlers, WIMP task and memory management, etc), each module would be flagged as "new world" when it has been re-written (preferably in a higher level language such as C++) and is thread-safe.  The result is RISC OS initially still running largely from existing code, allowing the subsequent re-engineering process to take place piece by piece.

Writing the multi-tasking Kernel code and APIs is something I could do myself with a bit of technical assistance relating to the latest ARM hardware.  I have a lot of experience in writing multi-threaded code at a Win32 level in C, and in the managed environment of .NET.   However, making the existing RISC OS code work with it would require a major team effort, and unless that team approach is organised properly it just won't get off the ground.

As with everything of this kind, it's a massive job and one that is likely to need more highly skilled developers then we currently have to complete it.  Right now many other people will have other development priorities, may not agree with me (!!), and will flag up all manner of headaches in the workings of the OS that would make this difficult.

Just my thoughts after an interesting evening of discussions.   I'm as outspoken as usual, no doubt.. :-)

TBAFS 26bit Version Released

At the request of a number of people, we've released the original 26bit version of TBAFS for download.

This is version 1.01 as released in 1996.  It has been tested up to RISC OS 3.7 only, although should work on any 26bit version of RISC OS.  The only pre-requisite for older versions of RISC OS is the Acorn toolbox modules.

BASIC VFP Assembler 0.06

An updated release of the BASIC VFP assembler with fixes for bugs reported by Jeffrey Lee:

• Fixed VLDM/VSTM 16 double register limit
• Fixed VLD1/VST1 offset options incorrect
• Fixed VADD.<integer> double word register support
• Fixed corrupt VFPLib in TBAFS archive
• Fixed VLDx/VSTx offsets not applied to instruction

Back online

After a couple of months off we're finally back to it...    and I have started with a problem.   The "hard disc" on the BB XM that is a USB flash drive has suddenly started corrupting files when saving.  Thankfully I have a backup of most things (and more are being taken!)   My first thought is to switch to a more traditional external USB laptop hard disc instead of the pen drive, but I don't know if this will help as the drivers would be the same.

The last release of the assembler was affected with VFPLib (the basic source for generating the lookup tables) corrupted within the TBAFS archive.

Hopefully I can figure out what is going on as this is the worst kind of problem to have.  I guess it's just a side-effect of running a development version of an operating system and drivers...

BASIC VFP Assembler 0.05

Version 0.05 of the BASIC VFP/SIMD assembler has been released for download

• Fixed VLDM/VSTM register list size

BASIC VFP Assembler 0.04

Version 0.04 of the BASIC VFP/SIMD assembler has been released for download

• Fixed VLDx/VSTx syntax error due to missing comma
• Fixed register type case-sensitivity
• Fixed listing missing final character
• Fixed optional 'ignored' data-type on data-processing instructions
• Fixed condition codes

Holiday Time

Things are a bit delayed at the moment as the holiday season takes over.   There has been some great feedback on the assembler and I hope to get another version out soon.   Like everyone else I'm away for quite a lot of August and also September, so it's slowing development right down.   We'll be back with an update as soon as there is something to report.

VFP Assembler 0.03

Another update to the VFP Assembler today with release 0.03.

* Fixed optional data-type variations - ARM p285
   (Note the use of multiple data-types is still not supported)
* Removed need to set sz in internal tables for F64/F32 variations)
* Fixed use of register lists in VTBL
* Other minor improvements to code and documentation

VFP Assembler Update

Shortly after 0.01 comes version 0.02 of the VFP/SIMD assembler with a number of bug fixes:

* Fixed VLDR/VSTR <reg>,<expr> not supported
* Fixed SP,LR,PC ARM register names
* Fixed user integer without R# prefix for ARM register numbers
* Other minor fixes
* Updates to documentation and release notes

Tested with the TestVFP script and a manual scan of output created by ObjAsm / DecAof

(Note the BASIC version in VFPLib supports the VLDR fix but not the ARM register names)

VFP assembler known bug list

Testing has thrown up some bugs that we are working on fixing:

* SP,PC,LR not supported as ARM core register names

* "R" prefix should be optional for an ARM core register, supporting existing syntax
   (We are verifying this doesn't cause other issues with similar pattern variations, leading to syntax errors)
   (The pattern table order will have to be updated to ensure bad-register errors occur at the correct time)

* LDR reg,<expr> not working due to missing pattern variation
   (<lbl> will be a new op name in the pattern tables to support an R15 based offset matching <#+-10>)

I suspect there will be more as there are a lot of (perfectly necessary) assembler directives that add complexity to the otherwise fairly simple syntax.

Using Functions within VFP/SIMD instructions

Having reviewed the documentation supplied with the 0.01 release, one thing that isn't clear is the way in which expressions are supported within the VFP/SIMD syntax.   This will be corrected in the next release.

Register Numbers
<type>#<expression>
Register numbers are a special case where the register type must be specified.   So where an ARM register can be simply specified as a number from 0-15, a Single/Double/Quad register must be prefixed by S,D or Q, and then a # followed by the expression.    For example Q#FNregister or D#(A%+B%)

Immediate constants
#<expression>
The same as for the standard ARM assembler, subject to encoding limitations as specified in ARM.   For a full 32bit or 64bit number, an 8bit constant can be shifted around and duplicated in 9 different ways.   For example #&FF, #&FF00, and #&FF00FF00  will encode for VMOV where as #&10F will not.

Immediate floating point or 64bit integers
#F32.<expression>
#F64.<expression>
#I64.<expression>
The special constructors take a number from 0-255 from <expression> and pass it through in raw form to the instruction encoding.   This is not particularly useful but completes the syntax.  We would recommend using other methods to define constants of these types.

Scalar Offsets
[<expression>]

Hopefully that helps to explain how things work.   Good luck to anyone who is testing the assembler and we look forward to some feedback in due course.

BBC BASIC with VFP/SIMD Assembler Released

Release 0.01 of BBC BASIC with the VFP/NEON (SIMD) assembler is now available to download

This is an Alpha release and is for some initial testing prior to inclusion in the official ROOL source code.   It is supplied in a TBAFS archive (naturally) so you'll need !TBAFS to extract it.  Documentation is included so please refer to that for further information.

After loading the new BBC BASIC module, to use it you simply write VFP/SIMD instructions like you would any other.  You will need to set-up a VFP context using the VFPSupport module before VFP/SIMD instructions will run.  We have included an example of this via a BASIC support library that simplifies this process.

We are just starting to use the VFP/SIMD instruction set to re-write part of TAG.  Our testing of the assembler will continue as this development progresses.

BASIC Assembler with VFP/SIMD (finally)

The VFP and SIMD extensions to the BBC BASIC assembler are working!  All of the instructions assemble from the test script.  Significantly more testing is required before a first release but I hope to publish something to the TBA downloads area in the not too distant future.

There are a few alterations to the official ARM syntax in order to accommodate the legacy BBC BASIC tokens and language syntax

1) In order to use an expression for a register number you have to specify the type followed by # and then an expression - for example Q#FNregister specifies a Quadword type register with a number returned from FNregister.

2) VDUP is currently renamed to VDPL as VDU is a keyword and VDUP.16 will get tokenized as VDUPRINT16 due to existing tokens.

3) Full encoding of floating point or 64bit immediate constants isn't supported, so there is a workaround where you can specify the immediate byte with a I64. F64. or F32. prefix.  This assumes you have encoded the value in a suitable way yourself which is better than nothing.  It must be said these immediate values are not exactly useful anyway.

4) The optional AL condition isn't supported on the unconditional SIMD instructions, and additional register type specifiers following the data-type are also not supported.

There are probably a few more options in the ARM syntax that are not supported - I'll have a go at reading through it all again to create some releases notes.

The to-do list

Error handling is still not integrated fully although this will be looked at next.  The current error numbers need evaluation to see how to include some additional VFP related messages.  I also expect there to be bugs (or undefined results) relating to use of incorrect syntax, and bugs relating to validation as it isn't possible to test every single invalid combination.  The current known bug list includes small things like optional brackets with a single register in a list, and specifying D0-D3 instead of D0,D1,D2,D3 on the VLDx/VSTx instructions.   Nothing major.

The final task is updating the help messages and creating some documentation so that the new instructions appear on the various help commands such as HELP [.   I'm also looking at adding a new command to display the VFP/SIMD assembler version and some debugging data to help with bug reporting.    The documentation will describe how the assembler and pattern tables work, along with how the BASIC version works that generates the optimized pattern tables for the assembler version.

It is quite easy to add additional non VFP/SIMD instructions to the pattern tables although I haven't started to look at what is currently missing.

BASIC Assembler Update

Work continues on the BASIC assembler enhancements.   After spending some time learning how to use ObjAsm and the ROOL build tools effectively, the past week I've been suffering with a virus (of the human kind) which has slowed development to a crawl.

So far I've created a new optimised and assembler friendly version of all the pattern and lookup tables via ObjAsm macros in an automated fashion from the BASIC code.  This makes it easy to update them as I simply re-run the BASIC application.  The pains with the existing Acorn BASIC source code persist, so the plan is to add a branch from the existing code when a potential instruction begins with a "V" and branch back if no valid instruction is found.   All the new code is in several new source files to avoid creating problems in the existing code.  What remains then is to copy some code for storing the instruction into the correct location, and to figure out expression parsing to support the assembler syntax / notation discussed in the ROOL forums recently.

Unfortunately life is taking over for a while and it's going to slow down development.  It make take a little more time than expected get this one finished but it remains the highest priority task we are working on.

BASIC frustration

Another week has gone and this one has been quite frustrating.  While some assistance from the ROOL forum's sorted out some bugs in the assembler (and I even found one in !DecAOF so it's not all my fault!), work on the BASIC source hasn't really progressed.

The BASIC source code is like a bowl of noodles - it's all tangled up and it's hard to see where something stops and something else starts.   It reminds me of a BASIC program full of GOTO statements where you can't follow the flow, but in assembler it's worse as there is stack and flag management plus register preservation to consider.   Reading this code is not only draining my enthusiasm it's also making me think seriously about a re-write.  When you only have a few hours a day to work on something you don't need to waste most of that time trying to figure out what a bunch of crazy branch and magic numbers operations are trying to do.  The memory management isn't suitable for what we need in TAG either, and it's missing key data-types as previously posted.

We've already internally had an informal correspondence about a JIT compiler written in a a higher level language instead of an interpreter written in assembler.  I'm mulling over the consequences of all this at the moment while trying not to get any more stressed about the whole thing.  Time for a deep breath...

Handlers and BBC BASIC

As I work through creating a test script for all these VFP and SIMD instructions, my mind is wandering a bit to one of the next challenges for TAG.   TAG uses what we call Handlers to develop code for an application.  The handlers respond to events thrown by TAG for all the useful things you might need in a game.   These go from starting up and closing down, to rendering, and collisions.   The events are comprehensive enough to deal with all the major things a game such as BHP requires.

Handlers are developed in assembler through a support library linked into the BASIC assembler.  They are saved as a simple binary file with two entry points at the start, similar to a RISC OS module, one for frame events, and one for IRQ events.  For us technical developers this is great, but for most people this is beyond their capabilities.

We considered writing a C interface, but ultimately for the average-Joe this isn't really much easier than writing in ARM assembler.  You also need a whole load of compilers and stuff to get started and the Acorn PRM documentation is all aimed at assembly programming.

Acorn computers were always the easiest to use and to program.   BBC BASIC was famous for it's no fuss approach to programming, and for being interpreted - making it much easier to understand what was going on.   However over the years the language has become outdated.  It lacks object orientation and Unicode, plus it can not be used outside of an "application" to create Modules or class libraries, nor can it easily be used within another application such as TAG.

Visual BASIC .NET has become the ultimate version of BASIC available today as it is a complete language.  You can do everything that you can do in C/ C++/C# with a much more friendly syntax.   My development teams of nearly 20 people created vast web applications, data-processing systems, and real-time shop floor manufacturing systems with it.  Recently a customer who is into mathematics was dabbling in some programming, and no prizes for guessing he was using VB to write some code.   I asked him about C/C++ and he said it was far to much hassle for what he wanted to do and BASIC was much simpler to use.

Sticking to the Acorn roots I'm contemplating a new version of BBC BASIC.  Simple, interpreted, and as easy to use as always, but modern and powerful in it's capabilities.  Backwards compatible with existing code, but forward thinking as it can be used to develop anything.  Pulling the best bits of VB.NET as a language and syntax it would allow a framework for creating a class library that interfaces with RISC OS, Toolbox, and all the other things required for building applications rapidly.

A debugger is essential and the interpreter could be written with one in mind.  An interpreter makes it possible to change the code in-line whilst debugging rather than having to have vastly complex compiler technology.

Perhaps it's biting off too much, I'm not sure.  All I know is that it's taken a week part time to write an assembler from scratch using BBC BASIC and I'm back in love with the language that started off computing for me in 1984 on the BBC B.  It would be great for RISC OS to maintain the Acorn tradition of being the easiest to use and program operating system bar none.

VFPv3/SIMD Assembler Progressing

The last couple of days have been spent full-time on the VFPv3 / SIMD assembler for BASIC.  It's now approaching a first complete version as I've been through a lot of tidying up and commenting.  Some SIMD instructions remain to add as it's a very large instruction set but all the major ones are there now.

The exercise in writing an assembler has been fantastic in getting an understanding of the instructions and their uses.  I've had to read through the variations of each instruction and the associated encoding formats.  The only headache has been errors and inconsistencies in the ARM reference manual.   I guess with everyone using C compilers these days few people delve into raw machine code.

The reason for all this work on VFP is to create a new 3D calculations library for TAG.  This has to run using hardware floating point to achieve the performance and accuracy we require.  We've decided not to go with Mesa Open GL now as it won't run fast enough and will take significant effort to get running.  However we will revisit it in future if time permits.  An open source driver for the PowerVR/SGX hardware may well end up in the Mesa code-base.

Today I also downloaded the RISC OS source and took a look at the BASIC source code.   The idea is to add the VFP and SIMD instructions to the BASIC assembler while learning about how it works to add language extensions.  Sadly the code appears poorly structured and documented.  Thankfully it isn't that large so it should be possible to digest what is going on.  I'll try and get my head around it after I've completed the VFP library.

BASIC VFP and a decision on OpenGL

The re-write of TAG as TAG32 continues.   Having completed a load of code relating to the structure of everything, we move on to the 3D library.    There are two options on the table:
1) Write a new version of the TAG calculation and rendering code based on VFPv3 and SIMD.   This will bring maximum performance.   All the various methods would be exposed through the TAG32 SWI calls.  This method fits with the RISC OS legacy in that there is assembler code at the core of the operating system.  The down-side is a lack of standards implementation, making it RISC OS only code.   That said the Windows/Airplay version of TAG wouldn't require this code, so it's not necessarily that much of a limitation.

2) Use OpenGL as the 3D library.  This requires reviving the port of Mesa, and may open up hardware acceleration in the future. While this is an attractive option in many ways, the problem is a lack of performance.   In order to squeeze high quality 3D graphics in a higher resolutions and colour depths out of the Cortex A8 it is essential to optimise the code.  The Mesa code from the old RISC OS port is C code full of floating point and non-optimised functions and methods.

For now I've started work on adding VFPv3 and SIMD into the BASIC assembler.   The ARM 'ARM' manual is a bit tricky to read, but after a couple of days of studying I now understand VFPv3 and at least some of the ideas behind SIMD.

The first version is a BASIC library which implements FNvfp("instruction") to assemble the instruction.  All of the logic is based on lookup tables and a small amount of string processing code so it can be incorporated into the BASIC source in assembler at a later date.    It uses EVAL so that expressions can be used with variables as with other instructions.

So far I've tested VMOV, VCVT, VSQRT, VDIV, and VMRS/VMSR and it works very nicely.

The VFPSupport module in RISC OS 5.17 is used to first make a context and enable VFP/SIMD operation as it's switched off by default.

I hope to put up a getting started with VFPv3 post in due course once I've completed work on the library and carried out some more testing.

Threading and TBAFS64

TBA Software is not all about TAG and I've been reading through Forum posts and giving some thought to two areas in particular.   Threading and a 64bit file system.

Pre-emptive multi-tasking

A few people have had a go at implementing threads over the years but all have been an add on, rather than being in the OS code.   To make it work properly I think it has to be in the task control system of RISC OS, and it has to provide backwards compatibility for old code.

A new type of task is needed that is managed by a new process manager that has the common process, thread, local storage and synchronisation objects that are present in other systems such as Win32.   My idea is that a single threaded process would be created to deal with all the co-operative stuff, and communicate with the "new world" through synchronisation objects.  The SWI despatcher would need to understand what is thread safe and what isn't, and block if more than one call is pending to non 'safe' code (from outside the co-op thread).  Modules / SWI calls would need a flag to say they are thread safe.  WIMP poll would glue into the new process management.  Memory protection should be implemented as standard, even if in a basic form, so that thread safe code expects memory protection from the outset.

There is of course a lot more to it technically than this, but I think it important to get a structure in place before more effort is spent on code that ultimately doesn't achieve what is required.

TBAFS64

Following a short discussion on the ROOL forums I have drafted a spec for a 64bit version of TBAFS which I've dubbed TBAFS64.   TBAFS is an image file system so requires 64bit enhancements to Fileswitch, Filecore, and ADFS, before it could be implemented.  However it could provide the new disc format that RISC OS needs to handle large disc - the Filecore formats use some quite traditional methods and seem to require quite a large amount of RAM.

TBAFS quite simply turns disc space into a heap into which it allocates blocks.  It uses a single layer indexed directory structure and free block structure, plus a tree-indexed file data structure.   The tree index gives very high performance when random accessing compressed files as it only has to work with the blocks in question.  When files are not compressed they are still treated in blocks for simplicity.

Rather than tying the TBAFS format to the hardware disc layout in some way (as has been traditional with some file systems) TBAFS simply uses caching to limit the amount of I/O that is required.

The TBAFS64 spec includes an option for a journal, and dual copies of all the index data at each end of the disc.  The idea with the journal is to keep the file structures intact in the event of a power loss.  All writes for a particular "operation" are comitted to the journal before being committed elsewhere, and are only marked as complete when the journal has been flushed.  In the event a power loss the journal will still contain entries that still require committing to disc.  Of course care has to be taken in the underlying hardware design to avoid lazy write back caches that can defeat the integrity of the journal.   One design note is to provide an option to put the journal on a separate disc, greatly improving potential I/O throughput.

It is possible to extend the journal to provide fully transaction safe operations such as those used by a database.   This requires the addition of "transaction begin" and "transaction commit / roll-back" calls into the TBAFS API.   This would cause headaches with blocking (locking in database terms) if a second attempt was made to alter structure (typically file table data) already modified by an open transaction.

As it stands someone needs to look at the 64bit code for Fileswitch and Filecore before this can get off the ground.   I might be brave enough to take a look if time allows over the coming months but a lot needs to happen before then! :-)

Steady Progress

TAG Development Update

Another week has gone.   Time seems to slip away when undertaking large development work on a part-time basis.   Progress on TAG32 continues.   The code that provides structure is coming on well - applications are initialising, and starting and stopping.   The IRQ handlers are up and running along with the generation of events.

A few headaches remain in the structure of the old code.   Particularly the use of data storage within the code through the EQUx instructions.  While this was common practice way back when, and is OK for static values, it's not the way things should be done for variables and is unsafe for future use of threading and data execution protection.  Common register use is in place for the necessary structures - R12 is global data, R11 application handle, R10 package, R9 a live resource header.    Having data in a heap within a dynamic area per application gives much better control of memory usage, reduces fragmentation, reduces the chances of pollution, ensures everything is killed when an application exits, and reduces the use of the RMA to an absolute minimum.

I've had a few questions about software development on RISC OS and have asked a few as well.  StrongED is my preferred way to edit BASIC code.   TAG32 is pure assembler as ARM is by far the easiest CPU to write assembler for, and RISC OS is designed for assembler code throughout.   It takes a bit of effort but sometimes it's worth it and it is what makes RISC OS a bit different.

The PC by comparison is a much more complex instruction set and nothing in is aimed at assembler code any more with C#, VB.NET, and C++ used for almost everything.   This makes development faster on Windows but in many cases there is a total lack of understanding of what is going on.  Too many applications ignore the lazy garbage collector (one of the most stupid optimisations ever dreamt up) and create vast structures of objects and use hundreds of megabytes of RAM as a result.

RISC OS lacks a decent debugger so it's a case of structuring and commenting code, testing one thing at a time, using the console, and even reverting to reading code out to make sure it makes sense.  The only frustration with debugging assembler is that you can trash the machine very easily so it's good that RISC OS reboots very quickly.   BASIC gives a huge amount of power to develop functions, and I have for example functions to define structures and write the variable names and offsets into a file for debug assistance.  Use of LIBRARY replicates include and each file has a procedure to initialise it.

Use of StrongED, BASIC structures and defines, and heavily commented code

TBAFS 32bit Beta Released

We've released a free beta version of 32bit only TBAFS on the downloads page.

This version will not work on 26bit RISC OS and has only been tested on RISC OS 5.17.

TBAFS is a high performance image file system, with optional squash compression, particularly useful for backups.   Features include long file name support, unlimited files per directory, fast indexed directory structure, and lazy write-back caching.

This version does not include journalling or any kind of internal resilience - so we would not recommend you store anything particularly valuable in it.   It's also a beta version as it's only had limited testing on RISC OS 5.17 and is likely to contain a bug or two.

The write-back cache is great for performance, but bad for resilience if your machine crashes in the middle of writing.  You have been warned!

(!TBAFSFix which can recover files from corrupt images is not currently up to scratch so won't be released until we get some time to test it further)

BHP Worlds

A short follow up to the last post.   The BHP (Brutal Horse Power) worlds are now rendering in Open GL on Windows.   A nice piece of work by Mr Piper far far away :-)   I'm hoping we'll get some nice high quality screen-shots of BHP on the BB XM in the near future (using a software renderer for now of course), although plenty of code still needs writing for that to happen...

BHP Track 3 in Open GL on Windows

Starting at the start

It's been an interesting week.  Starting again on RISC OS programming after a 12 year gap has meant going back into the PRMs and re-learning a lot of the nuts and bolts.  However it is now coming back - I'm starting to remember the SWI calls and my way around things.  RISC OS is the easiest and most logical operating system out there to work with, and the quality of the Acorn PRM manuals is quite extraordinary. Having spent 10 years almost exclusively working with VB.NET and Visual Studio it's a pleasant change to find intuition and some clear instructions pointing me in the right direction, rather than some cryptic MSDN pages.

I'm still waiting for the tools CD from ROOL so I'm writing code with StrongEd and the BASIC assembler.  While perhaps unusually I'm not a fan of C/C++ code, I am a fan of having a modern IDE and debugger to fix bugs up front - VS.NET IntelliSense and 'compile as you type' is second to none.  That said, I am getting back into the old methods of debugging, particularly using the screen, console, and  even using the OS debugger to examine registers if everything else fails.   Having put together a new assembler code library for file handing, string handing and dynamic area/heap management, plus importing a lot of old shared code, everything is starting to come together and development is speeding up.

In the past few days I've read through all the TAG code and have designed the framework for a new 32bit version which I've dubbed (with no imagination) TAG32.  This consists of a module 'TAGMod' that allows multiple applications to simultaneously use the wide range of TAG capabilities - from the various plotting routines, through to complete management of a game runtime.   The new module will allow TAG applications to run in a desktop window, and even multi-task with other applications.    Currently the new module fires up and loads compiled TAG application package files.   Plenty more is still to be done on the structure before we get to 32bit rendering and use of VFPv3 / SIMD.

The TAG runtime for RISC OS will remain pure assembler - so the core code segments will comfortably sit in the CPU cache.  It's hard work at times, but in the end I think it's worth it as it makes the result particularly impressive.  Some simple tests show the BB XM is comfortable rendering in 640x512 in software at 60FPS (even indirecting via a framestore and copying to the display) which is encouraging.

My early impression of RISC OS 5 (on the BB XM at least) is that more work needs to be done on getting core applications running easily and reliably.  NetSurf has potential as a browser but suffers from a certificate error which makes it near impossible to view many websites.   FTPc hangs on start-up, Omniclient needs something I don't have, and this is the story with many other applications.  Currently it's making it near impossible to communicate with the PC I use to update this page without going via the RISC PC.

Over in Singapore work has begun on prototyping a system for running TAG applications through Open GL on Windows and ultimately Airplay.  One of the old TAG demo objects looks rather nice with a modern graphics engine.   Sadly at the moment Open GL for RISC OS remains little more than a dream as the SGX Power VR driver software and hardware documentation is all closed source.   While I could have plenty to say about this - for now lets just keep believing that one of the Linux groups attempting to make an open source driver makes some progress.

TAG Objects running under Open GL on Windows

Hopefully there will be a few shots of the familiar Brutal Horse Power 'worlds' in the next week or two.

We are back

It's been a long time away, 12 years or more, but TBA Software has returned to the Acorn RISC OS scene.  While this will probably go unnoticed (!) to the majority of the people in the computing world, as the former Lead Developer and Owner of the business in the 1990s its certainly something that I'm enjoying!

At the moment the plan is to get the old TBA Software titles running on RISC OS 5 and to then take a look at expanding Holograph (game editor) and TAG (game runtime) into parts of the operating system.   Longer term there are many things RISC OS requires (decent web browser, threading, BASIC enhancements) to make it attractive for more users that we hope to play a part with.

For the developers out there, we plan to open all the source code and make it part of the open source community for everyone to use.  Tentatively we are looking at creating a TAG runtime for iPhone to create some kind of income stream from the millions of iPhone users out there.

In the past few weeks I've spent a lot of time reviewing the progress of RISC OS Open and have successfully acquired, assembled, and configured, a BeagleBoard XM.   In due course I'll set-up a page on getting RISC OS up and running, as there is quite a bit involved.   Once running the performance is impressive.  RISC OS is a tiny operating system and was designed for 8 MHz ARM 2 processors, so it absolutely flies on the latest Cortex A8 hardware and DDR RAM.

BB XM - tiny when compared with a RISC PC 600

TBA has some boxed stock from the 1990s that will go on sale shortly.  For all the collectors of Acorn games in original packaging - these are genuine left over stock from the final Acorn World show.  I'll put up a post with a link to an eBay shop in the weeks to come.

The TBA titles include Dragonball, Axis, Formula Two Thousand (FTT), Cyber Ape, Cobalt Seed, Command Ship, Merp/Mirror Image, Brutal Horse Power, and TBAFS.  Many thanks to Peter who has put up some videos of our titles on You Tube.

Original TBA Stock let over from Acorn World1997

So far, TBAFS - the fastest compressed image file system for RISC OS with lazy writing and a tree indexed directory structure - is running on RISC OS 5.  It runs like a rocket on my 16GB USB flash drive.  Additionally Holograph using the TAG 3D runtime is tentatively up and running...

Holograph running in RISC OS 5

All I can say is that it's good to be back.   I'd love to get back in touch with Mark (Cyber Ape author) and anyone else that remembers us from days gone past.  Email me: alan at tbasoftware.co.uk

(Legal note - TBA Software is a trading name of Applet Technology Ltd, a limited company registered in England - and is not legally related to the previous partnership that was in place during the 1990's)