Author |
Topic: A History Lesson (Read 683 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
A History Lesson
« Thread started on: Nov 11th, 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.
|
|
 Logged
|
|
|
|
Edja
Developer
member is offline
Posts: 60
|
|
Re: A History Lesson
« Reply #1 on: Nov 11th, 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #2 on: Nov 11th, 2013, 4:55pm » |
|
on Nov 11th, 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.
|
|
Logged
|
|
|
|
Richey
New Member
member is offline
Gender: 
Posts: 35
|
|
Re: A History Lesson
« Reply #3 on: Nov 11th, 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... 
|
|
Logged
|
|
|
|
VBI
Guest
|
|
Re: A History Lesson
« Reply #4 on: Nov 12th, 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  )
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.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: A History Lesson
« Reply #5 on: Nov 12th, 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #6 on: Nov 12th, 2013, 6:08pm » |
|
on Nov 12th, 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.
|
|
Logged
|
|
|
|
lancegary
New Member
member is offline
Posts: 4
|
|
Re: A History Lesson
« Reply #7 on: Nov 12th, 2013, 8:51pm » |
|
I say go for version 6!
Lance
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #8 on: Nov 12th, 2013, 9:54pm » |
|
on Nov 12th, 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.
|
|
Logged
|
|
|
|
jack
New Member
member is offline
Posts: 2
|
|
Re: A History Lesson
« Reply #9 on: Nov 12th, 2013, 11:50pm » |
|
I vote for version 6 also. 
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: A History Lesson
« Reply #10 on: Nov 13th, 2013, 2:25pm » |
|
on Nov 12th, 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
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #11 on: Nov 13th, 2013, 3:02pm » |
|
on Nov 13th, 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.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: A History Lesson
« Reply #12 on: Nov 15th, 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.  ) Would you be able to install v6 alongside v5x?
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: A History Lesson
« Reply #13 on: Nov 15th, 2013, 08:52am » |
|
on Nov 15th, 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.
|
|
Logged
|
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: A History Lesson
« Reply #14 on: Nov 15th, 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 ! )
|
|
Logged
|
|
|
|
|
