Testers wanted for BBC BASIC (Z80) version 5
Comments
-
Here's a disc image with a number of Welcome programs --> http://www.g7jjf.com/acornz80/Basic_Program_Disc.zip
Edit: And a little graphics test program from JGH that also runs --> http://www.matrixnetwork.co.uk/JGH-Graphics.zip (converted to Z80 BASIC native tokenised).0 -
It's possible - certainly GEM for the Master 512 does not require a 6502-side mouse driver, it must exist either as a DOSPlus-side driver or built into GEM itself.Hated_moron wrote: »
Thanks. What still confuses me, though, is why there's an AMX menu in BeebEm but no included driver ROM (MouseROM). Does that mean it's possible to use an AMX mouse without the ROM; do some games etc. perhaps access the mouse directly via the hardware port rather than using the software interfaces provided by the ROM?(My caveat: tested this in B-Em, though see no reason why it shouldn't also work in BeebEm if AMX support works)0 -
I'm having a go at assembling it, and it seems to be failing on the global ELLIPSE - in ACORN.Z80 (unless I'm mistaken) you have the label as ELLIPS. Changing these to ELLIPSE (as it's referred to in EXEC.Z80) it assembles and runs.Hated_moron wrote: »0 -
In the tools I'm using only the first six characters of a symbol are significant, that's why it's supposed to be ELLIPS (not ELLIPSE) throughout, like BRAKET (rather than BRACKET) etc. But that one seems to have slipped through the net, I'll change it.I'm having a go at assembling it, and it seems to be failing on the global ELLIPSE - in ACORN.Z80 (unless I'm mistaken) you have the label as ELLIPS.
1 -
Yep, that makes sense. (I'm using L80 linker, which seems not to have the 6-character label limit.)
While on the subject of ellipses, I notice the optional 5th parameter (rotation angle in radians) isn't being accepted. Is this by design?0 -
Of course: my BASICs support only axis-aligned ellipses (because the underlying OS graphics drivers also have that limitation: gdi32 in BB4W and SDL2_gfx in BBCSDL). I'm certainly not going to make BBC BASIC (Z80) an exception! Anyway, there's nothing to stop you achieving it with MOVE and PLOT.While on the subject of ellipses, I notice the optional 5th parameter (rotation angle in radians) isn't being accepted. Is this by design?
Looking at it from a more fundamental viewpoint, the new graphics keywords (ORIGIN, CIRCLE, ELLIPSE, RECTANGLE etc.) are supposed to be trivial wrappers around VDU. It's contrary to that philosophy (a) to take a floating-point parameter and (b) to need to do some non-trivial geometry to convert that parameter to an integer coordinate.
If Acorn had wanted the orientation of the ellipse to be specified by a rotation angle, that's how they should have designed the VDU/PLOT equivalent (perhaps taking an angle as an integer number of degrees). As they didn't, nor should the ELLIPSE statement.
1 -
Fixed at GitHub. If you spot any other seven (or more) character symbols let me know, as it's not my intention to rely on only the first six being significant. That sort of limitation was common in the 1980s (a bit like some BASICs recognising only the first two characters of a variable name!) but it seems a bit odd now.Hated_moron wrote: »In the tools I'm using only the first six characters of a symbol are significant, that's why it's supposed to be ELLIPS (not ELLIPSE) throughout, like BRAKET (rather than BRACKET) etc. But that one seems to have slipped through the net, I'll change it.
0 -
Does this limit also apply to EQU definitions? You've got quite a few of them in MAIN.Z80 and EXEC.Z80 - the longest seems to be TOTHERWISE.
I remember some BASICs being like that, even back then I thought it was odd that the ZX Spectrum only allowed a single-character string variable name, especially the BBC was effectively unlimited. (And, the flip side, the BBC's maximum string length which the Spectrum didn't have!)0 -
I know I go on about this incessantly, but Acorn really lost their way in some aspects of the design of ARM BBC BASIC V. ELLIPSE taking a floating-point parameter is one; how was that supposed to be implemented in a setting where the code to convert ELLIPSE to VDU codes has no access to any floating-point arithmetic (it isn't always going to be able to call trig routines in the interpreter)?Hated_moron wrote: »If Acorn had wanted the orientation of the ellipse to be specified by a rotation angle, that's how they should have designed the VDU/PLOT equivalent (perhaps taking an angle as an integer number of degrees). As they didn't, nor should the ELLIPSE statement.
Changing the palette using a SYS call (SYS "ColourTrans" or something) rather than being encoded in the VDU stream is another. The VDU stream is a fundamental aspect of the design of the graphics subsystem, it allows you to store graphics commands in a string or in a file, it allows you to run the graphics renderer remotely via an 8-bit-clean communications channel etc. All this is broken by introducing a graphics function which bypasses the VDU stream; insane!
And I suppose I should include maximum 255-character strings. On a 26-bit or 32-bit system with Megabytes of memory like an ARM, really? What was Sophie thinking?!
0 -
Ideally, yes, but if they are neither declared as GLOBAL or EXTRN - and there is no ambiguity with another symbol which has the same first six characters - no incompatibility should arise because the same result will be produced whether truncated or not.Does this limit also apply to EQU definitions? You've got quite a few of them in MAIN.Z80 and EXEC.Z80 - the longest seems to be TOTHERWISE.
I think I completely forgot about this, initially, when revisiting the code after 40 years! I hope I can be forgiven for that, especially in the context of my extremely poor memory.
I have a feeling that the 6-character limit was built into one of the object file formats of the day (evidently not .REL, given your experience) so it's symbols that get exported and resolved by a linker that are most at risk of incompatibility.
0 -
Nothing that requires forgiveness. It assembles and it runs, and neither the assembler nor linker are in any way confused, so it's all good.0
-
I willingly concede that effectively arbitrary length (e.g. 32-bit length) strings are non-trivial to implement because the concept of a 'string accumulator' (a fixed block of memory used as temporary working string storage) cannot be applied.Hated_moron wrote: »And I suppose I should include maximum 255-character strings. On a 26-bit or 32-bit system with Megabytes of memory like an ARM, really? What was Sophie thinking?!
Indeed I'm not certain there aren't situations in BB4W and BBCSDL where things might go wrong when 'huge' strings are manipulated (I don't know that there are such situations, but it wouldn't shock me if there were).
But strings up to 65535-bytes, which Brandy supports for example, really shouldn't pose any problems because a conventional string accumulator is still feasible (losing that amount of memory to a statically-allocated buffer ought not to be serious on a 26/32-bit platform).
0 -
Would it be safe to add those files to the cpmbbctest.dsd you created - it would be convenient to have them in the same place as the interpreter - or could that risk breaking the correct operation of your cpminsert.bbc program?Here's a disc image with a number of Welcome programs --> http://www.g7jjf.com/acornz80/Basic_Program_Disc.zip
0 -
It should be safe - the disc has reserved a 32K block, and as far as I know CP/M doesn't attempt to automatically defragment a disc.
I'll have a play with this once I've put my son to bed.0 -
Thanks. It's a low priority as I'm happy to leave the testing to others.I'll have a play with this once I've put my son to bed.
The original 'version 2.3' functionality from 1983 is in the main unchanged, with either no or very minor code alterations, so it's only the new (or extended) keywords that specifically need testing:
CIRCLE [FILL], DRAW BY, ELLIPSE [FILL], FILL [BY], LINE, MOVE BY, ORIGIN, PLOT BY, RECTANGLE [FILL} ... [TO], COLOUR l,p, COLOUR l,r,g,b, MOUSE x,y,b, TIME$, WAIT n, =MODE, =WIDTH.
I believe it's not possible to test COLOUR l,r,g,b in BeemEm because I don't think any of the emulated machines has that capability anyway. I don't know if PiTubeDirect does, but if not there may be no point in me supporting that option.
0 -
OK - cpminsert.zip has been updated - the disc image includes all the welcome programs, and the packaged (but not initially inlined) BBCBASIC.COM is now the BBC BASIC for Z80 Second Processor v5beta6. There is no change to cpminsert.bbc or cpminsert.txt.0
-
Regarding COLOUR l,r,g,b - while PiTubeDirect can support a frame buffer to the Pi's HDMI and BBC output is rerouted to that (so RISC OS modes are available), as far as I know this is only supported for the 6502 and Native ARM modes. Since you're sending VDU19,l,16,r,g,b then that would explain it always resolving as black as 16 loops around to 0. To be fair, COLOUR l,r,g,b does exactly the same in ARM BASIC V on B-Em and PiTubeDirect's ARM coprocessors. I'd suggest leaving it in as it's of course possible for a host-side ROM to handle this especially in conjunction with hardware modifications such as VideoNuLA (never used this but it's apparently an upgrade that increases the palette, among other things).
MOUSE x,y,b is working (with MouseROM installed and enabled).
CIRCLE [FILL], ELLIPSE [FILL], ORIGIN, COLOUR l,p, TIME$, WAIT n, =MODE all working. WIDTH <value> and =WIDTH are both working. (incidentally, while accepted and is sane on Matrix Brandy, it has no effect...yet)
Just need to test the BY forms of graphics, and the various FILL and RECTANGLE options.
My testing environments: Physical Master 128 with PiTubeDirect, B-Em in Master 128 mode (I'd expect many of these graphics functions don't work on BBC B mode without Graphics Extension ROM). B-Em and PiTubeDirect also includes an ARM co-processor with ARM BASIC V loaded, giving another point of reference.
0 -
Is BBCBASIC.COM still padded to 32K though? I'm relying on cpminsert.bbc being able to cope with a version which has grown beyond its current size, should that be necessary to fix a bug or add a feature I've forgotten.OK - cpminsert.zip has been updated - the disc image includes all the welcome programs, and the packaged (but not initially inlined) BBCBASIC.COM is now the BBC BASIC for Z80 Second Processor v5beta6. There is no change to cpminsert.bbc or cpminsert.txt.
0 -
Yes, I've made no change to that file, and the insertion code is itself limited to 32K.0
-
Further testing - RECTANGLE and RECTANGLE FILL both work as expected, but RECTANGLE x,y,w,h TO newx,newy appears to be swapping w and h.
For comparison, here's ARM BBC BASIC V doing the same thing. (ARM Co Pro on B-Em)
(I also get this result in RISC OS)
0 -
Another thing I noticed is that POINT [BY] x,y is missing. I know you have PLOT [BY] x,y as an equivalent, so probably the easiest way to implement this is to make POINT encode to the same token as PLOT as per COLOR to COLOUR (yeah, I know it would have the side effect of POINT code,x,y working, would this be an acceptable tradeoff?)0
-
(Just to note, PiTubeDirect has a little-used option of having its own framebuffer, VDU driver, and HDMI output, which would in principle (or in future) be capable of supporting COLOUR l,r,g,b,)0
-
Is that framebuffer usable from all copros or just 6502 and ARM?0
-
At present, it may well be limited to those, but it's quite possible, I think, to extend the facility to z80. All the hard work and ingenuity is in place.1
-
Thank you, that does indeed sound like a bug. I will investigate.Further testing - RECTANGLE and RECTANGLE FILL both work as expected, but RECTANGLE x,y,w,h TO newx,newy appears to be swapping w and h.
This is in the same category as the angle parameter in ELLIPSE: my BASICs are different from Sophie's BASICs, and this is one of my BASICs!!Another thing I noticed is that POINT [BY] x,y is missing. I know you have PLOT [BY] x,y as an equivalent, so probably the easiest way to implement this is to make POINT encode to the same token as PLOT
Specifically, using POINT x,y superficially sounds sensible because it handily reuses the existing keyword POINT, which is great for compatibility and so on. Except that it doesn't: POINT is one of those keywords in which the opening-parenthesis is part of the token, the token &B0 expands to POINT(!
So to implement POINT x,y in any of my BASICs (not that I have any intention of doing so) would mean introducing a brand-new keyword, with all the implications that has for compatibility with existing programs which may use that same word as a variable name.
In summary, it would be totally bonkers! PLOT [BY] x,y is much more sensible in every way, it doesn't involve an additional keyword and the meaning is much clearer, in my opinion. Suck it up.
On a more serious note, one of the problems with publishing source code at GitHub is that it allows other people to modify the code, so somebody might try to add the angle parameter to ELLIPSE and/or the POINT x,y statement. I would want to emphasise that if they were to do that they cannot call the resulting product BBC BASIC, which only I (and Acorn) have received permission from the BBC to use.0 -
This might seem an awkward work around but you could have the published source compile them labelling them as "RTR BASIC" then binary patch your release binaries as "BBC BASIC"?0
-
Now fixed, I hope (I've not changed the version number).RECTANGLE x,y,w,h TO newx,newy appears to be swapping w and h.
I don't get it, what would be the point of that? The 'Wilson' and 'Russell' strands of BBC BASIC have always been significantly different - they were even in 1981 - but they have equal status, they are both 'BBC BASIC'.This might seem an awkward work around but you could have the published source compile them labelling them as "RTR BASIC" then binary patch your release binaries as "BBC BASIC"?
The BBC BASIC (Z80) source files - of the interpreter itself anyway - all say "The name BBC BASIC is used with the permission of the British Broadcasting Corporation and is not transferrable to a forked or derived work". Not that I have to declare that, legally it's the case anyway of course, but it avoids any confusion.
The only occasion I know of when somebody failed to respect the BBC's ownership of the name was when a version for the very early Apple Mac was called 'BBC BASIC' when it shouldn't have been. It was a pretty short-lived and little-known product.
Otherwise Brandy BASIC, OWL BASIC and the rest have all recognised that they have to call it something different (or seek permission from the BBC, as I did). The Agon Light 2 has trod a bit near to the edge, in the code changes required for 24-bit addressing, but the intent was not to change the functionality as seen by the BASIC programmer at all.
0 -
Yep, that's fixed. Thank you.
I hadn't heard of a Mac version besides yours - I have heard of an Apple ][ "port" - implemented by using the BBC Micro ROM unmodified and a shim implementing the MOS calls needed.
(And regarding compatibility changes, earlier today I added PLOT BY x,y to Matrix Brandy, this is identical in function to POINT BY x,y but unlike COLOR to COLOUR it does not replace the PLOT token with the POINT token.)0 -
-
Brandy complicates things by using plain-text (.BAS) files as its preferred program-interchange format. Had it stuck with using tokenised files, as Sophie's and my BASICs do, the POINT/PLOT incompatibility would be of little consequence because it can be dealt with in the same way as the other token differences (e.g. OTHERWISE being &7F in Sophie's BASICs but &CC in my BASICs).I added PLOT BY x,y to Matrix Brandy, this is identical in function to POINT BY x,y but unlike COLOR to COLOUR it does not replace the PLOT token with the POINT token.)
0
