Testers wanted for BBC BASIC (Z80) version 5
Comments
-
Here's one, adjusted to use VDU instead of MODE, MOVE and PLOT, that fails with "Bad use of array at line 680". Too big to paste in here so it's at http://brandy.matrixnetwork.co.uk/testing/Craters (in text form) - it works fine in Acorn BBC BASIC 5 and Matrix Brandy. (Not working in BBCSDL - I don't think you support display bank switching via OSBYTEs 112 and 113)0
-
It will have been obvious from earlier replies, but I'm not a fan of 'testing' by running demo programs, because however impressive their output might be they rarely exercise features at all thoroughly.and would give a visual confirmation if all was not well.
After all, how many demo programs will be using the same variables as both actual and formal parameters (for a start that breaks most variable naming conventions!) but in a different order? You'd never do that 'deliberately', but it's nevertheless got to work.
I'd much prefer that you (and as many other people as possible) use your expert knowledge of BBC BASIC to devise tough tests that exercise the edge cases that 'real' programs rarely do.
Incidentally don't expect BB4W/BBCSDL programs which use array arithmetic necessarily to work in the Z80 version, because their capabilities are different. For example A() = 5 * A() + 1 works in BB4W, BBCSDL and Matrix Brandy, but it does not work in ARM BASIC 5 or BBC BASIC (Z80) v5.
0 -
That illustrates my point. It can't work in BBC BASIC (Z80) v5 by design, that kind of 'array arithmetic' simply isn't supported at all, you have to change it to:Here's one, adjusted to use VDU instead of MODE, MOVE and PLOT, that fails with "Bad use of array at line 680"temp()=vec2()*d
(in other words the array term must come first).
I'm surprised it works in ARM BASIC TBH, surely one would always 'naturally' put the array term first?
0 -
I've updated BBC BASIC (Z80) to version 5beta3 to fix an issue reported by Jonathan Harston whereby some keyword abbreviations expanded 'unexpectedly', for example E. expanded to ELLIPSE rather than to ENDPROC as it should.
This error crept in because I never use keyword abbreviations myself (BB4W and BBCSDL don't support them, by default, although they can be enabled) and I'd totally forgotten they even existed!0 -
(Deleted, overtaken..)0
-
Same issue as discussed in my earlier post, in BBC BASIC (Z80) v5 you have to write it as:This short example works in ARM BASIC 5, but not in BBC BASIC (Z80) v5beta2.40 b()=a()*d
Putting the scalar term before the vector term in an array expression seems perverse, I confess I didn't know that worked in ARM BASIC V and it's not obvious how.
My definition of bug excludes features of ARM BASIC V that I've never known about myself!
0 -
Yes, turning it around works.1
-
Our replies were overtaking each other - I deleted mine because I see you had made the point that what I was doing wouldn't work - but I hadn't seen that at the time I posted.
0 -
I have some choice in what array expressions BBC BASIC (Z80) v5 will and won't accept. For example I could make it accept a() = d * b() but at the cost of it then not accepting a() = b + c which it currently does!I see you had made the point that what I was doing wouldn't work - but I hadn't seen that at the time I posted.
Making that change might improve compatibility with ARM BASIC V (which rather surprisingly also doesn't accept a() = b + c) but would otherwise be pretty arbitrary.
So given that BBC BASIC (Z80) won't accept both, do you have a view on which of a() = d * b() and a() = b + c is the more valuable to support? BB4W, BBCSDL and Matrix Brandy are no guide as they all accept both.
0 -
Perhaps this is one for the documentation, as a note to say this way round works, that way round doesn't.0
-
True, although one has to say what documentation?! I'm not planning to write any documentation specific to BBC BASIC (Z80) v5, to go on GitHub for example, other than the existing WHATSNEW.TXT. That mentions the absence of string array expressions (not practical because of no garbage collection), because that's a significant departure from the BASIC V spec, but it doesn't lend itself to the sort of detail needed to cover this case.Perhaps this is one for the documentation, as a note to say this way round works, that way round doesn't.
I notice that in Acorn's RISC OS BASIC Reference Manual there's an explicit list of array expressions supported (below). BB4W, BBCSDL and Matrix Brandy all go much further than that limited set, but since it's not practical for BBC BASIC (Z80) to do so, one could argue that it would be better for it to support the Acorn-documented subset than a different subset as it currently does.array = array Copy all elements array =-array Copy all elements, negating array = array + array Add corresponding elements array = array- array Subtract corresponding elements array = array * array Multiply corresponding elements array = array / array Divide corresponding elements array = factor Set all elements array = factor, expression, ... Set several elements array = array + factor Increment (or concatenate) all elements array = factor + array array += expression array = array- factor Decrement all elements array = factor- array array -= expression array = array * factor Multiply all elements array = factor * array array = array / factor Divide all elements array = factor / array array = array . array Matrix multiplication
0 -
Fair enough, perhaps just refer to the Acorn/RISC OS Open document, with the exception that array = factor * array and array = factor / array are not supported.0
-
Sorry, are you misunderstanding? I said in a previous message that "I have some choice in what array expressions BBC BASIC (Z80) v5 will and won't accept. For example I could make it accept a() = d * b() but at the cost of it then not accepting a() = b + c which it currently does!".Fair enough, perhaps just refer to the Acorn/RISC OS Open document, with the exception that array = factor * array and array = factor / array are not supported.
In a later message I then said "one could argue that it would be better for it to support the Acorn-documented subset than a different subset as it currently does".
So why would I need to refer to an "exception that array = factor * array and array = factor / array are not supported" when I'm proposing that they are supported, rather than the current, different, subset of what BB4W/BBCSDL/Brandy supports?
Or are you saying, as it appears at face value you are, that you would prefer the status quo of BBC BASIC (Z80) supporting a subset different from the Acorn-documented subset. If so, why?
0 -
Yes, I misunderstood.
It would probably be best to follow the Acorn-documented subset, as that gives a documented set that can be relied upon to be supported across the widest array of platforms.0 -
In other words the opposite of what you said before! It is very confusing, especially for somebody with a brain that doesn't work properly, so it would probably be best for me to do nothing at all until somebody else chips in with a 'casting vote'.It would probably be best to follow the Acorn-documented subset, as that gives a documented set that can be relied upon to be supported across the widest array of platforms.0 -
Something else that doesn't work in BBC BASIC (Z80) is array arithmetic using EVAL:Hated_moron wrote: »Incidentally don't expect BB4W/BBCSDL programs which use array arithmetic necessarily to work in the Z80 version, because their capabilities are different.a() = EVAL("b() + c()")This will issue a 'Bad use of array' error. I could make it work, it's not technically that difficult, but I set myself an arbitrary target of fitting the interpreter into 16 Kbytes and that's completely full. I've never seen this feature of BBC BASIC used in the wild, has anybody else?
0 -
Do you happen to know: Is the documented subset all that ARM BASIC V/VI can do in respect of array arithmetic, or (like Brandy, BB4W and BBCSDL) are there extensions that aren't documented there (perhaps added in later versions)?It would probably be best to follow the Acorn-documented subset
I no longer remember why I extended BB4W's array arithmetic the way I did, no doubt at considerable extra effort. Did I already know at that stage that Brandy had extensions (I doubt it) or did Dave Daniels and I independently decide to extend it? Whilst there is some overlap, the extensions are significantly different.
Or is it possible that the RISC OS BASIC Reference Manual hadn't yet been published back then, so there was no easy reference for Brandy and BB4W to use as a guide. All a bit strange in hindsight, the extensions are sometimes useful, but not that useful, especially if ARM BASIC doesn't have any.
0 -
Given RISC OS 2 came out in 1988, and Brandy made its first appearance this side of 2000, I would say that Dave Daniels would have been at least aware of the Reference Manual, and likely familiar with its content.0
-
Hated_moron wrote: »
In other words the opposite of what you said before! It is very confusing, especially for somebody with a brain that doesn't work properly, so it would probably be best for me to do nothing at all until somebody else chips in with a 'casting vote'.It would probably be best to follow the Acorn-documented subset, as that gives a documented set that can be relied upon to be supported across the widest array of platforms.
Perhaps I can cast a vote: you should do what you feel is sensible and achievable, which I suspect is the status quo ante. If I have that phrase right.0 -
Maybe (the manual is dated 1992 in fact) but I didn't know it existed when I wrote BBC BASIC for Windows in 2000-2001, it would have been enormously helpful if I had.Given RISC OS 2 came out in 1988, and Brandy made its first appearance this side of 2000, I would say that Dave Daniels would have been at least aware of the Reference Manual.
Therefore I suspect that it was not available 'publicly', e,g, for download from the web, until much more recently. Until RISC OS itself was made Open Source I expect documentation of that sort was available only internally to Acorn or for purchase.
My guess is that BB4W having a much more extensive 'array arithmetic' capability than ARM BASIC V is simply because in the absence of the detailed information in the manual I assumed that's what it could do.
Given that Brandy's array arithmetic is also significantly more functional than Acorn's, Dave Daniels may have done the same. Otherwise why extend it, making for extra work without improving compatibility (which was always Brandy's main objective, I think)?
0 -
That doesn't really help, because both of the options are "achievable" (one is already implemented, the other requires only a relatively minor change).Perhaps I can cast a vote: you should do what you feel is sensible and achievable, which I suspect is the status quo ante. If I have that phrase right.
I also think they are both "sensible" in that they are both subsets of what BBC BASIC for Windows and BBC BASIC for SDL 2.0 (not forgetting also the Console Mode editions) currently do.
[Supporting, in the Z80 version, everything those versions do is neither sensible nor possible within the arbitrary limit of 16 Kbytes that I've set].
So it all comes down to the perceived importance of the explicit list of array arithmetic variations in the RISC OS BBC BASIC Reference Manual, which I only noticed quite recently.
If people refer to that manual as an indication of what BASIC v5 should do (and bearing in mind that there are several features of ARM BASIC V that not even BB4W and BBCSDL implement, let alone the Z80 version) then the change I have proposed is desirable.
0 -
I may have mentioned it earlier (as usual I can't remember) but the various different versions of BBC BASIC give different results from the code below:
10 DIM a(9) 20 a() = 0,1,2,3,4,5,6,7,8,9 30 a() = a(9),a(0),a(1),a(2),a(3),a(4),a(5),a(6),a(7),a(8) 40 PRINT a(0),a(1),a(2),a(3),a(4),a(5),a(6),a(7),a(8),a(9)
BB4W: 9 0 1 2 3 4 5 6 7 8 BBCSDL: 9 0 1 2 3 4 5 6 7 8 BBCZ80: 9 9 9 9 9 9 9 9 9 9 Brandy: 9 9 9 9 9 9 9 9 9 9 ARM V5: 9 9 9 9 9 9 9 9 9 9
BBC BASIC (Z80) v5 deliberately uses the same simplification as Brandy and Acorn's BASICs, even though that means it gives the 'wrong' result.
0 -
It is the same effect that always has me treading carefully when trying to move a memory block to a new location that at least partially overlaps the old. BBCSDL and BB4W (and I'd assume, BBCTTY) follow memmove() behaviour, the others memcpy().
And no, I don't recall having seen this observation in BBC BASIC before.0 -
Not really. The difference you are talking about is one of direction of copy: memmove() copies from the bottom to the top if it's moving downwards, and from the top to the bottom if it's moving upwards.BBCSDL and BB4W (and I'd assume, BBCTTY) follow memmove() behaviour, the others memcpy().
That wouldn't help in the case of BBC BASIC, because it doesn't solve the problem of:a() = a(9),a(7),a(5),a(3),a(1),a(0),a(2),a(4),a(6),a(8)
which doesn't work whether you copy top-to-bottom or bottom-to-top.
BB4W, BBCSDL and BBCTTY give the 'correct' result irrespective of the order of the list.
In ARM BASIC, Brandy and BBCZ80 the safest bet is to copy to a temporary array first:t() = a(9),a(7),a(5),a(3),a(1),a(0),a(2),a(4),a(6),a(8) a() = t()
That isn't safe in BB4W etc. because it isn't 'atomic' and the ON xxxx event 'interrupts' mean code, which might change the contents of the a() array, could be executed between the two statements. This isn't an issue for the others because they have no event interrupts.0 -
An interesting case! As you say, using a temporary array does the trick.0
-
Hated_moron wrote: »So it all comes down to the perceived importance of the explicit list of array arithmetic variations in the RISC OS BBC BASIC Reference Manual, which I only noticed quite recently.
If people refer to that manual as an indication of what BASIC v5 should do (and bearing in mind that there are several features of ARM BASIC V that not even BB4W and BBCSDL implement, let alone the Z80 version) then the change I have proposed is desirable.
It sounds to me like following that manual, so far as practical, would be a good path, so that's (presently) my vote.1 -
Yep, I agree. Apologies for being confusing earlier, that was not my intention. So far as this manual identifies a "baseline" V5 specification it would make sense, as far as is possible, to follow those.0
-
Thanks both for coming 'off the fence'. I will look at changing BBC BASIC (Z80) to be more compatible with the specific set of Array Arithmetic operations listed in the Acorn manual (although I've been distracted by a different challenge - plotting the Vampire Einstein - so it may be a couple of days).Yep, I agree.
I would still be very interested to know exactly what Matrix Brandy's Array Arithmetic capabilities are. I know it does a number of things that ARM BASIC 5 doesn't, but is there a list?
0 -
I haven't made a list, I've merely extended the upstream with additional data types (8 and 64 bit ints), and implementing unary minus by totally faking it (pulling it from the stack, putting 0 then the array back and then calling the existing array subtraction!).
I will work through the evaluate.c source to try to identify exactly what combinations are supported.0 -
The main difference I've spotted is that Brandy doesn't seem to be strictly limited to only two 'terms', this works in Matrix Brandy but does not work in ARM BASIC V:I will work through the evaluate.c source to try to identify exactly what combinations are supported.10 DIM a(9), b(9) 20 b() = PI 30 a() = b() + 2 * 3 - 4 40 PRINT a(5)
In Brandy it prints 5.14159264 (also in BB4W/BBCSDL/BBCTTY), as you might expect, but in ARM BASIC V it reports 'Syntax error in line 30' and you have to change it as follows:30 a() = b() + (2 * 3 - 4)
Matrix Brandy and BB4W/BBCSDL/BBCTTY also support this:30 a() = b() * b() + b()
But again ARM BASIC just reports 'Syntax Error' and you would have to do it in two steps.
0
