tag:blogger.com,1999:blog-83159465446496941442024-02-14T20:55:25.040+00:00TBA Software RISC OS BlogThe official blog of TBA Software back from the dead after 12 years away from the Acorn RISC OS computing sceneHohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-8315946544649694144.post-35254112601909032082022-12-23T13:16:00.001+00:002022-12-23T13:16:53.536+00:00<p>The interview Martin and I did for abug last year on the history of TBA has finally made it up on YouTube. Enjoy!</p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="399" src="https://www.youtube.com/embed/Z0-9c-aqdKc" width="482" youtube-src-id="Z0-9c-aqdKc"></iframe></div><br /><p><br /></p>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-49968422309451024412021-04-04T21:53:00.003+01:002022-12-23T13:18:11.136+00:00Back From the Dead, Take 2!<div style="text-align: left;">After almost 9 years away TBA software has returned to life! This time as a hobby with no grand plans (!) but we are back and hope to contribute something to the RISC OS community.</div><div style="text-align: left;"><br />Yesterday I joined up with Martin to record a history of TBA Software for the ABug community, which will be published on their site in the near future. It was great fun trying to recall all of the crazy times starting in the early 1990s and thank you to everyone there for making us welcome.</div><div style="text-align: left;"><br />In the background we have been looking at getting the TBA back catalogue published in 26bit form, including one or two previously unreleased/partially-finished titles. In addition I have been working on getting the TAG games engine, that underpins many of our past titles, to run in 32bit on a RPi 4B. This is coming along, with Cobalt Seed at the time of writing making it through all the title sequences and into the game, but more pesky status register bugs (and other dodgy code) remain.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">On the ABug talk we also fielded questions about use of TAG and the associated game editor Holograph for building new games. There was a version released back in the mid 1990s as part of our attempt to create a TBA developer community which led to the 3rd party development of Mirror Image. We will need to go through the documentation in particular to see just how bad it was (!) and decide what needs doing to tidy things up.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">Hopefully we will be able to find a new home across more modern social media platforms as this Blogger based site is more than a bit tired.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">Happy Easter from Bristol, Pickering, and Singapore!</div><div style="text-align: left;"><br /></div>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.com1tag:blogger.com,1999:blog-8315946544649694144.post-74475395866552586322012-05-17T20:24:00.001+01:002021-03-29T00:50:11.914+01:00Old TimesHow can it be May already? This year is truly flying past!<br />
<br />
Sadly the TBA revival has come to a halt as we've all had other priorities - many of which have resembled a crisis' in one form or another!! Thankfully we are all still here (!) and life is moving forwards, but the time to get stuck into some ARM assembly language isn't there. I've recently moved into a serviced office in Bristol and have put the Acorn set-up in the corner attracting curious glances through the window....!<br />
<br />
Some weeks back I had a great catch up with Martin when he visited the UK, the first time we've seen each other going-back almost to the old TBA days. Some reminiscing about old times took place, all those crazy rushes before Acorn World finishing products - camped in some flat in London coding until 3am each day for a couple of weeks....<br />
<br />
It's curious we both have a Chinese wife and have followed some similar paths. It goes right back to when we attended the same pre-school but then his family moved away to different area. Some 7-8 years later at secondary school we found ourselves sat next to each other in the same tutor group - not realising we knew each other for some weeks...!....Life is just full of coincidences...<br />
<br />
As it is, Martin works leading the development of security software, based in Singapore but travelling around the world. His experience in software development and the games industry is immense, but the computer gaming industry is in such a state it's tricky to pursue it as a career any longer. <br />
<br />
My profession is as an IT Director specialising in developing software systems and intellectual property relating to business critical multi-channel communications. This year has seen a big opportunity develop in one of the worlds largest organisations, so I'm rather busy making sure that goes in the right direction and turns into something concrete.<br />
<br />
One day I'd love to apply all this experience back into the world of RISC OS but I suspect that's going to be difficult. Last year I concluded RISC OS might best be developed so it can run in some kind of Virtual Machine, using the multi-tasking engine and such like of a host Microkernel/Hypervisor. Compatibility would be achieved using the new-world/old-world piece I described before. This approach minimises having to keep developing drivers for new hardware, and also avoids getting bogged down in licensing restrictions as none of the underlying OS code has to be linked into RISC OS.<br />
<br />
This is no easy task in itself and will take considerable effort. Without some kind of commercial application or some maverick who fancies sponsoring it all (one day hey?), it's not really going to happen....<br />
<br />
All I can promise is that I'll keep an eye on the whole RISC OS world and contribute when I can...<br />
<br />
AlanHohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-21075658575811374392012-01-25T01:06:00.001+00:002021-03-29T00:50:22.922+01:00Looking ahead in 2012So here we are in 2012, and belatedly I wish everyone a Happy New Year. Indeed that should be a Happy Chinese New Year as well - celebrated in at least two of the TBA staff households!<br />
<br />
Recently life has taken over again, so there has been little time to undertake any further development. Frustrating for sure as there is so much to do, but then we all have to pay the bills, look after the family, and ensure the career is heading in the right direction. In the next few weeks I should know a little more about what the rest of this year holds as some key decisions are being made.<br />
<br />
Hopefully as the year goes on there will be a chance to get some further work done on one or two things for RISC OS. In particular I'd like to finish some work on TAG32, and get one or two of the old titles up and running again. I'd also like to spend some time refreshing my C/C++ development skills as writing code in assembler, while enjoyable, isn't ideal when you have limited time available for all sorts of reasons.<br />
<br />
Hopefully the bit of momentum built up last year will continue, and the RISC OS Open project will attract some further developers and supporters.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-4185095601567152122011-11-11T02:17:00.001+00:002021-03-29T00:50:31.081+01:00TBAFS 32bit 1.03 ReleasedA new version of TBAFS 32bit has been released for <a href="http://www.tbasoftware.co.uk/p/downloads.html">download</a>. This fixes a bug in the TBA (Fast) decompression code that was introduced when it was converted to 32bit.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-43207487081390856342011-11-10T00:31:00.002+00:002021-03-29T00:51:04.170+01:00Bristol RISC OS Users GroupI'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...<br />
<br />
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...<br />
<br />
<b>Some thoughts....</b><br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Just my thoughts after an interesting evening of discussions. I'm as outspoken as usual, no doubt.. :-)Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-47673362399814424412011-10-10T16:49:00.000+01:002016-12-20T13:23:23.266+00:00TBAFS 26bit Version ReleasedAt the request of a number of people, we've released the original 26bit version of TBAFS for <a href="http://www.tbasoftware.co.uk/p/downloads.html">download</a>.<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-48513233660194880362011-10-02T21:43:00.001+01:002021-03-29T00:51:25.900+01:00BASIC VFP Assembler 0.06An updated <a href="http://www.tbasoftware.co.uk/p/downloads.html">release</a> of the BASIC VFP assembler with fixes for bugs reported by Jeffrey Lee:<br />
<br />
<ul><li>Fixed VLDM/VSTM 16 double register limit</li>
<li>Fixed VLD1/VST1 offset options incorrect</li>
<li>Fixed VADD.<integer> double word register support</li>
<li>Fixed corrupt VFPLib in TBAFS archive</li>
<li>Fixed VLDx/VSTx offsets not applied to instruction</li>
</ul>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-52172645617310476182011-09-28T23:18:00.001+01:002021-03-29T00:51:37.023+01:00Back onlineAfter 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.<br />
<br />
The last release of the assembler was affected with VFPLib (the basic source for generating the lookup tables) corrupted within the TBAFS archive.<br />
<br />
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...Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-91220011832342028142011-08-30T15:08:00.001+01:002011-08-30T15:08:22.785+01:00BASIC VFP Assembler 0.05Version 0.05 of the BASIC VFP/SIMD assembler has been released for <a href="http://www.tbasoftware.co.uk/p/downloads.html">download</a><br />
<br />
<ul><li>Fixed VLDM/VSTM register list size</li>
</ul>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.com0tag:blogger.com,1999:blog-8315946544649694144.post-52794410396582462462011-08-04T21:51:00.000+01:002011-08-04T21:51:13.946+01:00BASIC VFP Assembler 0.04Version 0.04 of the BASIC VFP/SIMD assembler has been released for <a href="http://www.tbasoftware.co.uk/p/downloads.html">download</a><br />
<br />
<ul><li>Fixed VLDx/VSTx syntax error due to missing comma</li>
<li>Fixed register type case-sensitivity</li>
<li>Fixed listing missing final character</li>
<li>Fixed optional 'ignored' data-type on data-processing instructions</li>
<li>Fixed condition codes</li>
</ul>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.com0tag:blogger.com,1999:blog-8315946544649694144.post-23603861095616196712011-08-03T21:34:00.003+01:002021-03-29T00:51:47.308+01:00Holiday TimeThings 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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-70598373207406035812011-07-12T20:49:00.001+01:002021-03-29T00:52:05.094+01:00VFP Assembler 0.03Another update to the VFP Assembler today with release <a href="http://www.tbasoftware.co.uk/p/downloads.html">0.03</a>.<br />
<br />
* Fixed optional data-type variations - ARM p285<br />
(Note the use of multiple data-types is still not supported)<br />
* Removed need to set sz in internal tables for F64/F32 variations)<br />
* Fixed use of register lists in VTBL<br />
* Other minor improvements to code and documentationHohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-35490578963481729912011-07-11T19:45:00.002+01:002021-03-29T00:52:15.383+01:00VFP Assembler UpdateShortly after 0.01 comes version 0.02 of the VFP/SIMD assembler with a number of bug fixes:<br />
<br />
* Fixed VLDR/VSTR <reg>,<expr> not supported<br />
* Fixed SP,LR,PC ARM register names<br />
* Fixed user integer without R# prefix for ARM register numbers<br />
* Other minor fixes<br />
* Updates to documentation and release notes<br />
<br />
Tested with the TestVFP script and a manual scan of output created by ObjAsm / DecAof<br />
<br />
(Note the BASIC version in VFPLib supports the VLDR fix but not the ARM register names)Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-8969996063886809182011-07-11T13:26:00.002+01:002021-03-29T00:59:29.079+01:00VFP assembler known bug listTesting has thrown up some bugs that we are working on fixing:<br />
<br />
* SP,PC,LR not supported as ARM core register names<br />
<br />
* "R" prefix should be optional for an ARM core register, supporting existing syntax<br />
(We are verifying this doesn't cause other issues with similar pattern variations, leading to syntax errors)<br />
(The pattern table order will have to be updated to ensure bad-register errors occur at the correct time)<br />
<br />
* LDR reg,<expr> not working due to missing pattern variation<br />
(<lbl> will be a new op name in the pattern tables to support an R15 based offset matching <#+-10>)<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-32304892695271031812011-07-06T23:21:00.002+01:002021-03-29T00:59:16.867+01:00Using Functions within VFP/SIMD instructionsHaving 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.<br />
<br />
<b>Register Numbers</b><br />
<type>#<expression><br />
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%)<br />
<br />
<b>Immediate constants</b><br />
#<expression><br />
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.<br />
<br />
<b>Immediate floating point or 64bit integers</b><br />
#F32.<expression><br />
#F64.<expression><br />
#I64.<expression><br />
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.<br />
<br />
<b>Scalar Offsets</b><br />
[<expression>]<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-76294410158099619142011-07-06T18:01:00.001+01:002021-03-29T00:59:06.702+01:00BBC BASIC with VFP/SIMD Assembler ReleasedRelease 0.01 of BBC BASIC with the VFP/NEON (SIMD) assembler is now available to <a href="http://www.tbasoftware.co.uk/p/downloads.html">download</a><div><br />
</div><div>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.</div><div><br />
</div><div>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.</div><div><br />
</div><div>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.</div>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-87713835991901643092011-07-03T20:58:00.003+01:002021-03-29T00:58:31.401+01:00BASIC 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.<br />
<div><div><div><div><br />
</div><div>There are a few alterations to the official ARM syntax in order to accommodate the legacy BBC BASIC tokens and language syntax</div><div><br />
</div><div>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.</div><div><br />
</div><div>2) VDUP is currently renamed to VDPL as VDU is a keyword and VDUP.16 will get tokenized as VDUPRINT16 due to existing tokens.<br />
<br />
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.<br />
<br />
</div><div>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.</div><div><br />
</div><div>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.</div><div><br />
</div><div><b>The to-do list</b></div><div><br />
</div><div>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.</div><div><br />
</div><div>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.</div><div><br />
</div><div>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.</div></div></div></div>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-23267605701721326162011-06-23T00:27:00.001+01:002021-03-29T00:58:19.869+01:00BASIC Assembler UpdateWork 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.<br />
<br />
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.<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-14389402915904627542011-06-14T14:52:00.001+01:002021-03-29T00:57:33.507+01:00BASIC frustrationAnother 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.<br />
<br />
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.<br />
<br />
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...Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-36016327870119272262011-06-05T15:26:00.004+01:002021-03-29T00:56:55.712+01:00Handlers and BBC BASICAs 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-27140528259025759402011-06-03T00:41:00.002+01:002021-03-29T00:56:42.053+01:00VFPv3/SIMD Assembler ProgressingThe 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-28555372814737059102011-05-30T14:15:00.001+01:002021-03-29T00:56:30.958+01:00BASIC VFP and a decision on OpenGLThe 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:<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
So far I've tested VMOV, VCVT, VSQRT, VDIV, and VMRS/VMSR and it works very nicely.<br />
<br />
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.<br />
<br />
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.Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-42389335127181929312011-05-25T11:13:00.001+01:002021-03-29T00:55:44.864+01:00Threading and TBAFS64<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b></b></div><div style="font-weight: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>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.</b></div><div><b><br />
</b></div><br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>Pre-emptive multi-tasking</b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>TBAFS64</b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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! :-)</div>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.comtag:blogger.com,1999:blog-8315946544649694144.post-64270053075337688422011-05-25T10:59:00.001+01:002021-03-29T00:55:34.737+01:00Steady Progress<b>TAG Development Update</b><br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEje2KnuWieKZwJW_9vqW9xsXDsqiUfH8UNyf4DtI8k8RHYentiOvElh2oJkzSDjdEmGnNcGyh4djL_i5TYtql4fRg1eGXIMnBIpIgpuBnI82oX3vE9W1PPqwO3FxQ2chyIl0G_M5YHlNTw/s1600/editing.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEje2KnuWieKZwJW_9vqW9xsXDsqiUfH8UNyf4DtI8k8RHYentiOvElh2oJkzSDjdEmGnNcGyh4djL_i5TYtql4fRg1eGXIMnBIpIgpuBnI82oX3vE9W1PPqwO3FxQ2chyIl0G_M5YHlNTw/s320/editing.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Use of StrongED, BASIC structures and defines, and heavily commented code</td></tr>
</tbody></table><b><br />
</b>Hohumhttp://www.blogger.com/profile/09790143915321269631noreply@blogger.com