BBC BASIC for Windows: A History Lesson

BBC BASIC for Windows
Developers' Area >> Future developments >> A History Lesson
http://bb4w.conforums.com/index.cgi?board=developments&action=display&num=1387583952

A History Lesson
Post by admin on Nov 11^th, 2013, 1:32pm

Those of you old enough to remember BBC BASIC (86) for MS-DOS - some of whom probably owned a copy, and perhaps still do - will be aware that it came with two different 'flavours' of BBC BASIC. One was the 'small memory model' (64K) BBCBASIC.EXE and the other was the 'large memory model' (1 Mbyte) BIGBASIC.EXE. Each had an associated run-time engine: BBCRUN.EXE and BIGRUN.EXE respectively.

BBCBASIC came first (it had originally been translated from the Z80 version) and BIGBASIC came later to take full advantage of the 640K of user memory available under MS-DOS. Unfortunately the later version wasn't fully compatible, and ran slightly more slowly, so I had to keep both available in order that older programs would continue to run without modification, and at their original speed.

Whilst this was a pragmatic solution, it was unsatisfactory for a number of reasons. It meant that I had to support two different versions, update two different versions when bugs were fixed or new features added, document two different versions etc.

I was determined that a similar situation wouldn't arise with BBC BASIC for Windows, because maintaining two different versions in parallel would be even more complex than under MS-DOS. For example it would complicate the association of a file extension with an executable, since both versions use .BBC source files. It would also affect the 'automatic upgrade' process (the MS-DOS version had no such capability).

But now I am faced with a dilemma. Version 6 of BB4W (which was developed specifically to support my Liberty BASIC clone LB Booster) has very similar issues to the old BIGBASIC - it isn't fully compatible with Version 5 and certain operations execute slightly more slowly (although others are marginally faster). If I am to avoid having to support both v5 and v6 'in parallel', which for the above reasons I would like to, I basically have the following choices open to me:

Release v6.00a, thus making v5 obsolete. A proportion (hopefully a very small one) of existing programs would require modification, and those that don't *might* run slightly more slowly (but then again they might run slightly faster). This was my original preferred option, but it attracted a considerable amount of opposition on the Yahoo group. I even received an order which stipulated 'version 5'!
Release v5.95a, to fix the few known shortcomings in v5.94a, but not version 6 (other than via the 'DIY' LBB hack). This would ensure compatibility, and not compromise execution speed, but it would deny users the new features in v6 (principally the new data types: 80-bit floats, 64-bit integers and huge strings). This would please those who objected to v6, but could alienate those who would like to make use of the new data types or are simply keen to see 'progress'.
Maintain the status quo and do nothing, keeping version v5.94a the current release. Whilst this would deny users both the bug fixes in v5.95a and the new features in v6.00a (which one could argue is the worst of all worlds) it is the 'safe' option and the only one which completely avoids the possibility of a rift between 'pro v6' and 'anti v6' factions amongst BB4W users.

As is apparent, to date I have adopted the 'do nothing' option. But it frustrates me that I have both v5.95a and v6.00a in a state where they could be released in the relatively near future, but because of the above issues they just languish on my PC.

I don't want to start a great debate, especially if it becomes heated as it did on the Yahoo group. But I thought I should at least make sure that everything is out in the open. There is a school of thought that since BBC BASIC is effectively dead, or nearly so, it's irrelevant anyway.

Richard.

Re: A History Lesson
Post by Edja on Nov 11^th, 2013, 2:48pm

As one of the people "keen to see progress" I am very much in favour of option 1 . But I won't complain if you decide to release v5.95a(option 2). Option 3 would be a dissapointment and even more so because you mentioned that the work is almost in a state to be released.

I seem to remember that the people who, some time ago, voiced their reluctance to move to v6.00a , were unable to formulate why they had objections. Are we not just not overstating the compatibility issue? For existing programs one could compile with v5.94a and "freeze" the program (and stop supporting v5.94a). For new coding one could do the effort to modify the code if at all necessary. I've seen this many times before in my career: whatever you do there will always be people who will resist to change
In the same reasoning MS would never have been able to release Win8.x (and I can think of other examples)

I hope my comments won't start a heated debate.
Let us all support the idea of releasing v6.00a and move forward ! !

A school of thought that thinks BB4W is dead anyway?
I've said this before : given the quality of this software, its support, thorough documentation, speed, absence of (relevant) bugs, consistency, price, ... As long as there will be a market for BASIC, I see no reason to prefer other Basics over BB4W. Isn't this just a matter of marketing?

Eddy

Re: A History Lesson
Post by admin on Nov 11^th, 2013, 4:55pm

on Nov 11^th, 2013, 2:48pm, Edja wrote:

whatever you do there will always be people who will resist to change

I know. A few years ago I would have had the confidence to release a new version and simply accept that a proportion of people would be unhappy about it. Indeed I did so on several occasions - in those days I trusted my own judgement!

However as I get older I find my instincts are less reliable. I have also detected a change in the way people react to decisions they are unhappy with: once upon a time they would remain polite, but now I am more likely to receive offensive personal emails.

So whilst I entirely understand that the 'do nothing' option would be a disappointment for you, there is no question in my own mind that it is the approach least likely to result in complaints and criticism. Therefore from a purely selfish perspective it is attractive.

Quote:

I see no reason to prefer other Basics over BB4W. Isn't this just a matter of marketing?

BBC BASIC is weak in certain areas, notably in its support (or lack of) for the Windows GUI and the event-driven paradigm that should ideally be used when programming Windows.

This is amenable to being solved with the creation of a new GUILIB library, and you will be aware of the extensive discussions that have taken place over the last few months on that subject. But nobody has volunteered to write it, and I cannot motivate myself to do so.

Richard.

Re: A History Lesson
Post by Richey on Nov 11^th, 2013, 11:52pm

Hi Richard

I agree with Edja - I think you should follow your instincts and go with version 6.

As regards GUILIB, I urge you to write it. I use Liberty BASIC for my GUI projects but what I would really want to use is a BBC BASIC for Windows version 6 with GUI capabilities - that would become my focus. If I had the ability I would write it but sadly I'm still a novice and what I have learnt so far is through persistence rather than talent... sad

Re: A History Lesson
Post by VBI on Nov 12^th, 2013, 1:21pm

Another vote for V6. Evolve or die.

I couldn't put it any better than Eddy has (except I may not have used Win 8 as an example wink

)

As for being a dead language - well I sincerely hope not, or a lot of hardware designs that I have been working on will have no accompanying software apps and will have to be canned.

May I venture to suggest that people who feel that they can use that level of disrespect and rudeness to another individual have the real issues, not the product, and they would almost certainly behave in the same manner whatever the product in question was, be it computer software or dog food. Best ignored.

Please, PLEASE, remember how many people use and love this product and would like to keep moving forward.

Graham.

Re: A History Lesson
Post by Michael Hutton on Nov 12^th, 2013, 4:55pm

Up to Version 6.

Existing BB4W programs would have to be 'frozen' if they specifically require 40-bit floats, but that must be a rare breed (some libraries may need re-writing).

Use a new Install folder so as not to mix versions, prehaps in the My Documents folder, or if that is not acceptable put in C:\...\BB4W.Whatever.you.decide.name (and make the @lib$ and "My Programs" or "Projects" folder in the @user$ folder?)

Michael

Re: A History Lesson
Post by admin on Nov 12^th, 2013, 6:08pm

on Nov 12^th, 2013, 4:55pm, Michael Hutton wrote:

Existing BB4W programs would have to be 'frozen' if they specifically require 40-bit floats

That's unlikely, but running out of memory as a result of float arrays doubling in size is more plausible. Indeed any program which raises HIMEM is quite likely to need to raise it some more!

Quote:

some libraries may need re-writing

Version 1.3 of SORTLIB is already compatible:

http://wiggio.com/yui/folder/stream_file.php?doc_key=eAT07+/VXBCTgwFylN26yFJTgBJc26DogHUjOFJVDic=

Richard.

Re: A History Lesson
Post by lancegary on Nov 12^th, 2013, 8:51pm

I say go for version 6!

Lance

Re: A History Lesson
Post by admin on Nov 12^th, 2013, 9:54pm

on Nov 12^th, 2013, 4:55pm, Michael Hutton wrote:

Existing BB4W programs would have to be 'frozen' if they specifically require 40-bit floats

As I said before it's unlikely, but having thought about it a bit more there would be a possible workaround even in that case. In BB4W v6, as in all previous versions, floating-point indirection (using the | operator) defaults to 40-bits, so you could simulate 40-bit float variables that way.

Note the results from running this simple program:

Code:

      DIM V% 4
      p# = PI  : REM 64-bits
      |V% = PI : REM 40-bits
      PRINT PI - p#
      PRINT PI - |V%

What it prints is this:

Code:

1.22514845E-16
1.2154201E-10

You can see the difference in accuracy between the 64-bit and 40-bit 'variables'.

Richard.

Re: A History Lesson
Post by jack on Nov 12^th, 2013, 11:50pm

I vote for version 6 also.

Re: A History Lesson
Post by Michael Hutton on Nov 13^th, 2013, 2:25pm

on Nov 12^th, 2013, 9:54pm, Richard Russell wrote:

floating-point indirection (using the | operator) defaults to 40-bits

I had never thought of that, but that is no surprise! I think I have only really used it in conjunction with a *float 64 when coding ASM routines.

I saw you had updated SORTLIB. I need to update SORTSALIB to make it compatible.

Michael

Re: A History Lesson
Post by admin on Nov 13^th, 2013, 3:02pm

on Nov 13^th, 2013, 2:25pm, Michael Hutton wrote:

I saw you had updated SORTLIB. I need to update SORTSALIB to make it compatible.

And indeed SORTLIB still needs to be able to handle 40-bit floats with BB4W v6, because you can create and sort an 'array' of them using indirection:

Code:

      INSTALL @lib$+"SORTLIB"
      sort% = FN_sortinit(0,0)

      n% = 10
      DIM f40arr% n%*5

      PRINT "Unsorted array:"
      FOR V% = f40arr% TO f40arr%+(n%-1)*5 STEP 5
        |V% = RND(1)
        PRINT |V%
      NEXT

      C% = n%
      CALL sort%, |f40arr%

      PRINT '"Sorted array:"
      FOR V% = f40arr% TO f40arr%+(n%-1)*5 STEP 5
        PRINT |V%
      NEXT

Richard.

Re: A History Lesson
Post by Matt on Nov 15^th, 2013, 05:16am

My vote would ususally be for a backwards compatible version, but, hey, I've got 5.94 here, so that's fine. If there's another version that's around that's not what I want, I'll stick with this one. Most of what I do would probably be covered in v6 anyway. How about making v6 the normal download, and v5x available on request, but not with software upgrade support. (I think that makes sense. undecided

) Would you be able to install v6 alongside v5x?

Matt

Re: A History Lesson
Post by admin on Nov 15^th, 2013, 08:52am

on Nov 15^th, 2013, 05:16am, Matt wrote:

I've got 5.94 here, so that's fine. If there's another version that's around that's not what I want, I'll stick with this one.

That may be fine for you, but it's not for me! Can you try to explain what it is about v6 that might make it "not what you want"?

Quote:

How about making v6 the normal download, and v5x available on request, but not with software upgrade support.

It's not an option I'm afraid; I tried to explain why I am not prepared to support two versions in parallel. In any case I don't really understand what you mean by "not with software upgrade support": are you suggesting that I break my promise that a purchase of BB4W is 'for life'?

I'm pleased that one of the 'anti v6' people has spoken up, because I was beginning to wonder where they had gone!

Richard.

Re: A History Lesson
Post by ady on Nov 15^th, 2013, 1:17pm

It's not always a case of being anti-anything, it can be a case of being pro-something else

I run WinXP because it does what I need

Just because a new car comes out doesn't mean everyone will want to dump the perfectly capable previous model
(unless they're an ipad user !

)

Re: A History Lesson
Post by admin on Nov 15^th, 2013, 5:32pm

on Nov 15^th, 2013, 1:17pm, ady wrote:

It's not always a case of being anti-anything, it can be a case of being pro-something else.

All very philosophical, but what does it mean?! As I've stated that I want to avoid supporting both v5.95a and v6.00a, I can't really see how being 'pro v5.95a' is different from being 'anti v6.00a' as far as my options are concerned. Perhaps you can elucidate.

Richard.

Re: A History Lesson
Post by Malvern on Nov 15^th, 2013, 5:39pm

You only want to support one version.
Version 6 is part of LBB which I assume is supported.
So the aim of only supporting one version can only be satisfied by issuing BB4W in a V6 flavour, n'est pas?

Re: A History Lesson
Post by Matt on Nov 15^th, 2013, 7:54pm

on Nov 15^th, 2013, 08:52am, Richard Russell wrote:

Can you try to explain what it is about v6 that might make it "not what you want"?

Not really, except that through the various messages here, it does sound as though it might include various upgrades that mean editing an old version of code might require more work than with v5x. - 'A proportion (hopefully a very small one) of existing programs would require modification, and those that don't *might* run slightly more slowly...'

Quote:

I tried to explain why I am not prepared to support two versions in parallel. In any case I don't really understand what you mean by "not with software upgrade support"

What I mean is not producing v5.95 alongside v6, but continuing with 'message' help for any concerns peculiar to v5x.

Quote:

...are you suggesting that I break my promise that a purchase of BB4W is 'for life'?

I would suggest no such thing! I'm not sure where that suggestion came from.

Quote:

I'm pleased that one of the 'anti v6' people has spoken up, because I was beginning to wonder where they had gone!

I agree with Ady on this one. I'm certainly not against v6, but if it's changed too much (and I certainly don't know that it will be) I might decide to stick with v5.94. But then again, I might conclude that v6 is far better for me.

My main point was really that I prefer upgrades to be backward compatible. But if that's not practical, I'm not going to throw my dummy out of my pram grin

.

You didn't answer my question about running both versions in parallel.

Matt

Re: A History Lesson
Post by admin on Nov 15^th, 2013, 7:59pm

on Nov 15^th, 2013, 5:39pm, Malvern wrote:

You only want to support one version.
Version 6 is part of LBB which I assume is supported.
So the aim of only supporting one version can only be satisfied by issuing BB4W in a V6 flavour, n'est pas?

Interesting theory! But it doesn't really hold up because LBB doesn't use the BB4W v6 IDE or compiler, so those don't need any support. Also, LBB uses only a small subset of the features of BBC BASIC so the support needed for the run-time engine is limited as well. In any case LBB is freeware so the support provided is rather more informal.

All things considered I don't think LBB really impacts on the decision.

Richard.

Re: A History Lesson
Post by admin on Nov 15^th, 2013, 8:21pm

on Nov 15^th, 2013, 7:54pm, Matt wrote:

Not really, except that through the various messages here, it does sound as though it might include various upgrades that mean editing an old version of code might require more work than with v5x.

But exactly the same applies to those who are enthusiastically encouraging me to dump v5 and release v6. What it comes down to, I suppose, is whether you are a 'glass half empty' or 'glass half full' person.

Quote:

if it's changed too much (and I certainly don't know that it will be) I might decide to stick with v5.94.

Why don't you know? I've explained what's been added, I've explained what's been removed, and I've explained what program features might result in an incompatibility. I've also made the BB4W v6 run-time engine available to anybody who wants to try it, via the LBB 'hack'. Doesn't that allow you to decide now whether or not you'll want to stick with v5?

Quote:

You didn't answer my question about running both versions in parallel.

It's been discussed before. The main issue is that both versions will be sharing the same registry keys. So for example the InstallPath key will point to whichever was installed last. Configuration settings will be shared, so for example you can't set v5 to have 1 Mbyte of memory and v6 to have 2 Mbytes of memory (which are the default settings).

So it's certainly possible to have both versions installed, but they won't be entirely independent and you need to keep your wits about you to avoid potential conflicts and confusion.

Richard.

Re: A History Lesson
Post by dje4816 on Nov 16^th, 2013, 08:33am

Richard,

I also vote for v6. I want those bigger floats, but I also believe you have to move forward. A language will eventually atrophy and die if it doesn't evolve.

Best regards,

Dave.

Re: A History Lesson
Post by admin on Nov 16^th, 2013, 1:43pm

on Nov 16^th, 2013, 08:33am, dje4816 wrote:

A language will eventually atrophy and die if it doesn't evolve.

I couldn't disagree more! One of the great strengths of the original BBC Micro BASIC was that it was programmed into a masked ROM, and was therefore 'frozen'. A stable, bug-free, language is in my opinion far superior to a language which keeps "evolving" - i.e. acquiring more and more spurious features that hardly anybody needs, and at the same time more and more bugs!

As I've said countless times before, BBC BASIC is a traditional interpreted language; every 'compiled' executable has to contain a full copy of the interpreter. Adding new features to the 'core language' means that everybody's executables get bigger, and slower (because of less efficient cache usage), even if they don't make any use of the new features.

The way to enhance the capabilities of BB4W is not to add to the interpreter, but instead to write new libraries. There's a real demand for them (for example the recently-discussed GUILIB), but can I persuade the user community to help with that task - no!

BB4W v6 is an aberration forced on me by the need to achieve better compatibility with Liberty BASIC. It hasn't altered my opinion on the merits of stability versus 'progress'.

Richard.

Re: A History Lesson
Post by Matt on Nov 17^th, 2013, 06:27am

on Nov 16^th, 2013, 1:43pm, Richard Russell wrote:

And yet your BBCBasic (for Windows) has 'evolved' by adding various extra key words, etc. The basic 'principal' that you always seem to aspire to might be the same, but, in it's entirety, it has definitely 'evolved', (so far, for the better, in my opinion).

Matt

Re: A History Lesson
Post by Edja on Nov 17^th, 2013, 10:10am

"The way to enhance the capabilities of BB4W is not to add to the interpreter, but instead to write new libraries."

I think the main point was clear : further enhancements to BB4W should come from libraries.
If I had the skills ...

Eddy

Re: A History Lesson
Post by admin on Nov 17^th, 2013, 10:34am

on Nov 17^th, 2013, 06:27am, Matt wrote:

I must say I'm quite confused. On the one hand you say "My vote would usually be for a backwards compatible version" yet on the other you say "it has definitely 'evolved', (so far, for the better, in my opinion)".

The trouble is that 'evolution' often involves a degree of incompatibility. It's almost impossible to add a new feature without the potential for some existing programs to be affected. Adding a new keyword may break programs that happened to use it as a variable name, or adding a new data type can break existing syntax (e.g. prior to 'byte variables' being added PRINT A&F meant 'print the value of A followed by 15, whereas now it means 'print the value of A& followed by the value of F').

Some of the major upgrades of BB4W that took place in the past, which you describe as "evolution for the better", involved incompatibilities comparable with those that v6 would cause. For example the addition of 64-bit floats in v2.00a was much the same as the introduction of 80-bit floats in v6. Or the change of maximum string length from 255 bytes to 65535 bytes in version 3.00a might have had a similar impact to the change to 'unlimited' length strings in v6.

It's true that version 6 breaks new ground in removing an existing feature: the support for legacy 40-bit float variables. However they were provided only to allow BB4W to run on a PC without a Floating Point Coprocessor - and even Windows 98 requires an FPU anyway. It's also the first time an upgrade has unavoidably increased the memory usage of programs, which is why I'm increasing the default setting of HIMEM (the trial version of v6 has 32K of memory available).

So I don't think you can have it both ways. If you favour backwards compatibility your vote should be for v5.95a, if you favour evolution it should be for v6.00a.

Richard.

Re: A History Lesson
Post by admin on Nov 20^th, 2013, 10:43am

I think I've come up with a workable, if somewhat off-the-wall, solution to the version 5/6 dilemma. My proposal is that I should release both v5.95a and v6.00a, but consecutively (with a gap of perhaps a month or two).

That way I will never need to support two versions in parallel, because when v6.00a is released it will replace v5.95a as the 'current' version. But it will provide a 'window of opportunity' for those (hopefully few) people who prefer to stick with v5 to do so. When v6.00a is released they can simply choose not to upgrade.

That does of course mean that once v6.00a is released they will strictly be using an unsupported version, but in practice I don't see that as a major issue, especially given that the v5.95a interpreter is virtually unchanged from v5.94a.

If anybody thinks this is a bad idea I can virtually guarantee that I will choose the do-nothing option (stick with v5.94a indefinitely).

Richard.

Re: A History Lesson
Post by Edja on Nov 20^th, 2013, 3:01pm

on Nov 20^th, 2013, 10:43am, Richard Russell wrote:

My proposal is that I should release both v5.95a and v6.00a, but consecutively (with a gap of perhaps a month or two).

Alea iacta est.
Excellent proposal.

Eddy

Re: A History Lesson
Post by Richey on Nov 20^th, 2013, 9:23pm

I think this is a good idea and should meet everyone's needs and wants...

Re: A History Lesson
Post by KenDown on Nov 21^st, 2013, 06:41am

Can you tell us which operations will be slower, please? Also, you mention that upgrading programs may be required. What will be necessary for this upgrading? An extra line or two of code or a complete rewrite or what?

Thanks

Re: A History Lesson
Post by admin on Nov 21^st, 2013, 08:34am

on Nov 21^st, 2013, 06:41am, KenDown wrote:

Can you tell us which operations will be slower, please?

Not really, I've not attempted to find out. To put it into perspective, I would expect the speed of floating-point arithmetic operations to be somewhere between what it is currently in *FLOAT40 mode and *FLOAT64 mode.

Running this trivial program:

Code:

      TIME = 0 : FOR C% =1 TO 10000000 : A = PI*PI : NEXT : PRINT TIME

gave the following results:

v5.94a (FLOAT40): 131 cs
v6.00a: 147 cs
v5.94a (FLOAT64): 160 cs

If you are particularly interested in how the speed of your own programs will be affected, try them yourself (using BB4W_v6.bas).

Quote:

Also, you mention that upgrading programs may be required. What will be necessary for this upgrading?

I discussed that in this post. The most common cause of incompatibility, I would guess, will be programs that assume that a suffixless variant, in a program running in *FLOAT64 mode, is a 64-bit double (e.g. passing it as such to an API function). In v6 you would need to add an explicit hash (#) suffix to every occurrence of that variable in the program.

A simpler answer to your question is probably: 'if you need to ask, it's unlikely that any of your programs will be affected'!

Richard.

Re: A History Lesson
Post by Matt on Nov 22^nd, 2013, 05:46am

Missed this post before.

on Nov 17^th, 2013, 10:34am, Richard Russell wrote:

Note the word 'usually'. I have to say that I was talking generally, rather than specifically about BB4W. If a new version of an application is offered, that does not allow an old version document to be, at least, read, then generally I would have to think twice about using it. Any 'evolution' within BB4W has, in my opinion, been justified and quite accetable.

My previous statements were, I have to admit, more rambling as a general thought. My intention was to imply that I had no problem with version 6 going ahead and would probably upgrade. However, if for some reason, there was something that I didn't like and prefered version 5.x then that would be OK for me.

My intention was not to imply that I didn't think you ought to go ahead with v6, but that I had a version here that I was happy with if I didn't upgrade.

My definite opinion in this situation here and now is that you should do what you feel is right. So far, I haven't come across any alteration you've made that I honestly feel was a bad idea (even if there are some that I don't understand). So whatever you decide will no doubt turn out to be for the best, of that I'm quite confident.

Matt

Re: A History Lesson
Post by ady on Nov 22^nd, 2013, 10:50am

I can't really see how being 'pro v5.95a' is different from being 'anti v6.00a' as far as my options are concerned. Perhaps you can elucidate.

We don't all see the world in black and white
(ones and zeros!)

"If you're not with us then you're against us!" is fine if you're a political or religious zealot but for most people life is a compromise of "vive la difference"

If we were all building a single integrated BB4W project then everyone would have to be on the same V6 page but everyone is doing their own independent mini project

You could probably bring all the stragglers on board with a Windows IDE which only works in V6+ if you wanted to, lol

It's a circuitous argument unless there is real incentive to upgrade, Bill Gates grappled with it for years

Re: A History Lesson
Post by admin on Nov 22^nd, 2013, 12:21pm

on Nov 22^nd, 2013, 10:50am, ady wrote:

"If you're not with us then you're against us!" is fine if you're a political or religious zealot but for most people life is a compromise of "vive la difference"

This is a technical forum, not a philosophical society!

Quote:

You could probably bring all the stragglers on board with a Windows IDE which only works in V6+ if you wanted to, lol

Sorry, I don't understand. Isn't that exactly what I was proposing to do?

In any case I have been forced to abandon work towards an update, for the time being, for health reasons.

Richard.

Re: A History Lesson
Post by ady on Nov 22^nd, 2013, 1:11pm

Sorry to hear you've got health issues Richard, priorities change when that happens

That IDE stuff was romping along quite nicely until some genius at Yahoo decided to make those disastrous changes to the groups

So even if we're not V6 enabled yet, there's still a bunch of us hanging about

Re: A History Lesson
Post by Richey on Nov 22^nd, 2013, 10:09pm

Quote:

In any case I have been forced to abandon work towards an update, for the time being, for health reasons.

Hope you get well soon Richard.

I think the consensus so far is that your idea of releasing two versions one after the other is a good one.