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)