Testers wanted for BBC BASIC (Z80) version 5

Hated_moron

(I have temporarily re-joined the forum in order to make this announcement; don't worry, I have no intention of staying. I also appreciate that this section is described as being for Acorn 8-bit BASICs, but as there was an Acorn Z80 Second Processor which came with my BASIC hopefully it qualifies).

Since, for various reasons, I have had to abandon 'BBC BASIC for Windows' and 'BBC BASIC for SDL 2.0' (and, believe me, it is extremely disconcerting not to be able to develop or support one's own software products) I have been trying to keep my brain exercised by extending 'BBC BASIC (Z80)' to something close to the version 5 specification!

This might seem an odd choice of project, but I reasoned that working on code I wrote more than 40 years ago might be less compromised by my extremely poor short-term memory and cognitive decline, compared with code which I have written more recently. That was indeed my experience, I found I could remember the Z80 instruction set quite easily.

I have made a self-contained package for testing this new version of BBC BASIC (Z80), in Windows, available for download from here. If you'd rather not use Windows you can extract the BBCBASIC.COM file from the archive and run it either on a genuine Z80 CP/M system or in a CP/M emulator on your preferred platform. The file WHATSNEW.TXT in subdirectory B/0/ lists the new features.

I would greatly appreciate this new version being tested as thoroughly as possible; please report any bugs discovered or crashes experienced at this forum (or send them to me by private email if you prefer). It would also be helpful if you could forward this announcement to anywhere that you think some interest in an updated BBC BASIC (Z80) might be found.

Soruk

Running in B-Em's Z80SP emulation, I ran into this....

Also, is it intentional that MODE and the various graphics commands don't work, and fail with "Sorry"?

BigEd

Thanks for the offering Richard! I had a quick go in a rather nested way - the runcpm program emulates a z80, I ran it in WINE which acts like Windows, but is an Intel-flavour binary which runs on my ARM-based Mac using Rosetta translation.

I noticed that the ESC key didn't do anything in this environment, so I can't use AUTO, but that is probably expected.

(I'm not too surprised that graphics commands give Sorry - it's surely a console-mode Basic.)

Hated_moron

Soruk wrote: »

Running in B-Em's Z80SP emulation, I ran into this....

I can't reproduce that here. This is what I get on entering an identical sequence of commands:



If there's any further investigation you can do to pin this down it would be greatly appreciated. What do you get from version 3.00 in the same circumstances? I've not (deliberately) changed anything in 5.00 that should affect the commands you entered.

Also, is it intentional that MODE and the various graphics commands don't work, and fail with "Sorry"?

What would you expect them to do on a generic CP/M machine? Obviously they can't display graphics (CP/M systems rarely have any graphics at all, and if they do they are not standardised in any way) so other than an error message I'm not sure what you were hoping for.

Hated_moron

BigEd wrote: »

I noticed that the ESC key didn't do anything in this environment, so I can't use AUTO, but that is probably expected.

When you say the ESCape key doesn't do anything, do you mean it *never* does anything, or it is specifically in the AUTO command that it's failing? If it never does anything, that's almost certainly a fault your end rather than mine, I would expect. As I responded to Michael, try the same thing with version 3.00, I've not deliberately changed anything that should affect the ESCape key at all so it would be interesting to know if version 3.00 does the same.

This is the code used to poll the ESCape key:

;
;TEST - Sample for ESCape and CTRL/S. If ESCape
;       pressed set ESCAPE flag and return.
; Destroys: A,F
;
TEST20:	LD	(HL),20
TEST:	PUSH	DE
	LD	A,6
	LD	E,0FFH
	CALL	BDOS0
	POP	DE
	OR	A
	RET	Z
	CP	'S' AND 1FH	;PAUSE DISPLAY?
	JR	Z,OSRDCH
	CP	ESC
	JR	Z,ESCSET
	LD	(INKEY),A
	RET
;

Hated_moron

I should add that if graphics - albeit that they are impossible - and even, say, POS and VPOS worked (which they don't, because again that's not standardised in CP/M) that would surely be a distraction from the object of the exercise, which is to test the version 5 features.

These are the features that I would like to be 'tested to death'. Although of course I would be interested to know if I've broken any of the pre-version 5 features that worked correctly previously, spending time on testing them would not be a worthwhile exercise.

New features in BBC BASIC (Z80) version 5.00, May 2024:

1. BASIC V statements

1.1 WHILE...ENDWHILE
1.2 Multi-line IF...THEN...ELSE...ENDIF
1.3 CASE...WHEN...OTHERWISE...ENDCASE
1.4 LOCAL DATA / RESTORE DATA
1.5 ON ERROR LOCAL / RESTORE ERROR
1.6 DIM var LOCAL size
1.7 ERROR err, message$
1.8 RESTORE +n
1.9 SWAP var1,var2
1.10 BPUT #file,string$[;]
1.11 QUIT

2. BASIC V functions

2.1 DIM(array()[,sub])
2.2 END (pointer to free space)
2.3 REPORT$
2.4 Binary constants
2.5 LEFT$ & RIGHT$ with last parameter omitted
2.6 MOD(array)
2.7 SUM(array)
2.8 SUMLEN(array)
2.9 GET$#file

3. BASIC V whole array operations

3.1 Pass a whole array to a FN/PROC
3.2 Pass a whole array to CALL
3.3 Whole array assignment
3.4 Whole array arithmetic *
3.5 Array dot-product operator
3.6 Array initialisation lists
3.7 Make a whole array LOCAL
3.8 DIM a LOCAL array (on the stack) +

* String array expressions A$() = B$() + C$() are not currently supported.
+ LOCAL string arrays should be initialised to their maximum needed length
to eliminate the risk of a memory leak each time the PROC/FN is called.

4. Miscellaneous BASIC V features

4.1 Bit-shifts <<, >>, >>>
4.2 Floating-point indirection (|)
4.3 RETURNed parameters from FN/PROC
4.4 Compound assignment (+=, -=, *=, /= etc.)
4.5 Assigning to a sub-string: LEFT$()=, MID$()= , RIGHT$()=
4.6 Hooks for CIRCLE,ELLIPSE,FILL,LINE,MOUSE,ORIGIN,RECTANGLE,TINT,SYS,WAIT
4.7 Hooks for WIDTH function, TINT function, MODE function

5. Extensions to Acorn's BASIC V, compatible with BB4W, BBCSDL and BBCTTY.

5.1 EXIT REPEAT / WHILE / FOR [var]
5.2 Address-of operator ^
5.3 Byte variables and arrays (& suffix)
5.4 'BY len' and 'TO term' qualifiers to GET$#file
5.5 ELSE IF <condition> THEN; (trailing semicolon)
5.6 == synonymous with = in comparisons
5.7 DIM a global array inside a FN/PROC (use RETURN)

Note: The token for PUT has changed from &CE in version 3 to &0E in version 5.
If this token is present in existing programs it will list as ENDWHILE rather
than PUT, and the programs will need to be modified to restore functionality.

BigEd

There's every chance it's my Mac or runcpm which is swallowing the ESC key events - PRINT GET won't respond to it, or indeed to control-[ which ought to be the same thing. V3 and V5 are the same in this respect.

Hated_moron

BigEd wrote: »

There's every chance it's my Mac or runcpm which is swallowing the ESC key events.

It does sound like it. Unfortunately that would make it almost impossible to do the kind of testing I am hoping for, so my suggestion - if you don't mind - would be to build runcpm natively for your Mac. As far as I know it's highly portable C code and should compile on almost any platform without problems: https://github.com/MockbaTheBorg/RunCPM

Incidentally are you able to ask for help on my behalf at Stardot? I will fully understand if they are still banning any contributions from me, but that was some time ago now and maybe their attitude has softened (then again, maybe not!).

BigEd

Michael has already put a companion thread up on Stardot, and I've added to a comment with the WHATSNEW info. It's an impressive list! Especially as the program seems still to be only 19kbytes.

Good idea to build a native RunCPM - I've done that, and can report that the escape key works as it should! However, the delete/backspace key doesn't work - PRINT GET shows it is 127. (Whereas, with runcpm in WINE, it works and shows as key 8.)

Soruk

Here's the BBC BASIC for CP/M that's included on the system disc:

I think I've got a better idea for those apparent random failures. In version 3.00 the backspace key stops at the > prompt, whereas in 5.xx the prompt itself is erased! I'm guessing it's adding 0x08 or 0x7F into the command buffer so, with my typical atrocious typing the failed "P.~HIMEM" might actually be something on the lines of "P,(08).~HIMEM".

Hated_moron

Hated_moron wrote: »

If there's any further investigation you can do to pin this down it would be greatly appreciated.

The symptom you experienced is possibly indicative of memory corruption, so something you could try is to *SAVE the interpreter (&100 to &4AFF) - assuming the *SAVE command hasn't also been broken of course - and compare the file you saved with BBCBASIC.COM.

Soruk

There is a strange difference, in two bytes, and to check that it wasn't the import or export tools corrupting the files, I checked the same bytes on the .dsd floppy image, and found both the original set (most likely associated with BBCBAS5.com (I called it that to differentiate with the supplied BBCBASIC.COM) and the modified one associated with the *SAVEd output BBCTEST.BBC

As well as B-Em, I have it running on my Master with Acorn Z80 Tube emulations versions 1.20 and 2.30, with the same results.

Relative to the start of BBCBAS5.COM, the bytes changed are at offset &49AE that gets &0A changed to &09, and &49C2 where &00 gets changed to &4B. Indeed, DUMP shows the correct bytes in BBCBAS5.COM - but when I run it, P.?&4AAE gives 9, and P.?&4AC2 gives 75. Does the program intentionally modify itself?

Hated_moron

Soruk wrote: »

Here's the BBC BASIC for CP/M that's included on the system disc:

What's the point you are trying to make here? That's not 'BBC BASIC (Z80) for CP/M' it's 'BBC BASIC (Z80) for the Acorn Z80 Second Processor'. They are totally different products: the first designed to run on any Z80 CP/M system and the second is customised for a particular Acorn system which happens to have a graphics capability.

In version 3.00 the backspace key stops at the > prompt, whereas in 5.xx the prompt itself is erased!

There's no difference here, neither 3.00 nor 5.00 backspaces past the prompt. When you refer to version 3.00 is that really what you mean (version 3.00 for generic CP/M downloaded from my web site)? Or do you perhaps mean the customised Second Processor version 2.20 which you showed the output from above?

As I'm sure you appreciate, the console I/O they use is totally different, the Acorn version will probably be calling OSWORD over the Tube for console I/O, whereas the generic versions are making the appropriate CP/M BDOS calls.

Soruk

The version 3.00 I was running is the generic CP/M version downloaded from your website. To be fair, I downloaded this after taking that screenshot with 2.20.

Hated_moron

Soruk wrote: »

Does the program intentionally modify itself?

No, but I'm pretty sure the bytes you mention are data, not code, and therefore changes are to be expected and are not significant (remember that CP/M files are always an exact multiple of 128 bytes so you can't determine the size of the code from the size of the file).

So that suggests the code is not being corrupted. Can you confirm whether version 3.00 (not the Acorn version 2.20 which is entirely different) has the same behaviour as 5.00, or not?

Soruk

I can confirm that the generic v3.00 allows me to delete (using the delete key on my Master 128) and correct my abominable typing. v5 on the other hand does not. This is both on B-Em and my physical M128 (with PiTubeDirect emulating the Acorn Z80SP).

Hated_moron

BigEd wrote: »

Especially as the program seems still to be only 19kbytes.

The interpreter is 16 Kbytes, as it would need to be to fit in a ROM for example (the version 3.00 interpreter is about 12 Kbytes); the features I added and those I didn't were determined to some extent by that consideration. The remaining 3 Kbytes are the CP/M specific interface code, in a ROM environment they would be 'MOS' code, not 'language' code.

However, the delete/backspace key doesn't work - PRINT GET shows it is 127. (Whereas, with runcpm in WINE, it works and shows as key 8.)

It's 8 in Windows (Ctrl+backspace is 127). Perhaps I should accept both. Are you able to backspace past the prompt as Michael is?

Hated_moron

Hated_moron wrote: »

It's 8 in Windows (Ctrl+backspace is 127). Perhaps I should accept both.

I've updated BBCZ80V5.zip to accept both BS (8) and DEL (127) when editing at the BASIC prompt (it should work in INPUT too). Hopefully that will allow you to do some proper testing without the 'environment' getting in the way.

Hated_moron

Soruk wrote: »

The version 3.00 I was running is the generic CP/M version downloaded from your website. To be fair, I downloaded this after taking that screenshot with 2.20.

Try the new version I've just uploaded for BigEd which accepts both BS (8) and DEL (127) as the 'backspace-and-delete' code. Can you still backspace past the prompt using that?

Soruk

A quick test in B-Em indicates this problem is fixed for me. I will do some more testing on physical hardware later.

Hated_moron

Soruk wrote: »

A quick test in B-Em indicates this problem is fixed for me. I will do some more testing on physical hardware later.

I'm not sure whether there's any standardisation in CP/M as to whether 'backspace-and-delete' should be BS or DEL, the fact that 'runcpm' returns a different code in Windows and MacOS (when built natively for both) would suggest not.

So accepting either in BBC BASIC is probably sensible, although I don't remember it being an issue previously (version 3.00 reports as Copyright 1987, 37 years ago!).

I understand from BigEd that there's a thread at Stardot, is it possible to provide a link? I'm not sure whether I'll be able to see it, that depends on whether there's still an IP-address-based ban in place (I know I could probably see it via a proxy anyway, although that's a hassle, and maybe even in a mobile browser connected via 4G rather than WiFi).

Soruk

I made a thread on Stardot here - https://stardot.org.uk/forums/viewtopic.php?t=29193
I put your announcement almost verbatim, just a slight tweak to redirect reports back to this thread here.

Hated_moron

Soruk wrote: »

I made a thread on Stardot here - https://stardot.org.uk/forums/viewtopic.php?t=29193
I put your announcement almost verbatim, just a slight tweak to redirect reports back to this thread here.

Thanks. I expect some people there would also like a version customised for the Z80 Second Processor, but I've no recollection after all this time of how that was achieved. If it was done by Acorn, I won't have any record of it.

Mind you, as I said earlier, I do think that could be a distraction from the version 5 features I want tested.

Soruk

Since VDU works (e.g. VDU 22,3 to select MODE 3) it shouldn't be much more than sending the appropriate VDU codes for MODE, DRAW, MOVE and PLOT. Sound is probably a bit more involved, at a guess it's a case of making the appropriate OSWORD calls.

Hated_moron

Soruk wrote: »

Since VDU works (e.g. VDU 22,3 to select MODE 3) it shouldn't be much more than sending the appropriate VDU codes for MODE, DRAW, MOVE and PLOT. Sound is probably a bit more involved, at a guess it's a case of making the appropriate OSWORD calls.

Even if VDU seems to work it's being routed through the CP/M BDOS, which will be a big performance hit; on a Z80 Second Processor it ought to call OSWRCH directly via the Tube.

Then there's SOUND, ENVELOPE, ADVAL, POINT, TIME and TIME$ (L & R) which presumably need to work over the Tube somehow. Plus there's all the console I/O stuff (OSRDCH, OSWORD for the line editing features such as the Copy key etc., testing the ESCape flag and so on).

I don't know the first thing about how to do Tube I/O from the Z80, so this is all well beyond my abilities. And I remain convinced that it would be a distraction: none of the version 5 features that I am so keen to be tested have anything to do with I/O.

Soruk

Calling the MOS looks reasonably straightforward (but then again I haven't written any Z80 code since the 1990s as a kid). The calls are listed about halfway down this page https://beebwiki.mdfs.net/CALL and each call link includes how to call across the various co-processors. You don't have to do Tube I/O yourself.

Oh, and cursor editing in the traditional BBC Micro way already works.

BigEd

Hated_moron wrote: »

BigEd wrote: »

Especially as the program seems still to be only 19kbytes.

The interpreter is 16 Kbytes, as it would need to be to fit in a ROM for example (the version 3.00 interpreter is about 12 Kbytes); the features I added and those I didn't were determined to some extent by that consideration. The remaining 3 Kbytes are the CP/M specific interface code, in a ROM environment they would be 'MOS' code, not 'language' code.

Ah, just 16k, thanks for the explanation. Even better.

However, the delete/backspace key doesn't work - PRINT GET shows it is 127. (Whereas, with runcpm in WINE, it works and shows as key 8.)

It's 8 in Windows (Ctrl+backspace is 127). Perhaps I should accept both. Are you able to backspace past the prompt as Michael is?

Thanks - the new V5 is working for me. It backspaces as it should, and doesn't go past the prompt.

Hated_moron

BigEd wrote: »

Ah, just 16k, thanks for the explanation. Even better.

It's exactly 16K, there's no headroom for expansion, so whether it remains that way depends on what bugs you might find! I have taken a few liberties to fit it in, for example error reporting isn't what it might be (definitely no extended messages of the kind ARM BASIC V has!).

Hated_moron

Soruk wrote: »

I haven't written any Z80 code since the 1990s as a kid

I'd not written any Z80 code since 1987, until about three weeks ago.

I won't be adding any Tube interface code, since it isn't relevant to the testing I want done.

I wonder whether you and BigEd might want to divvy-up the various v5 features between you, so you don't end up testing the same ones.

Soruk

Soruk wrote: »

A quick test in B-Em indicates this problem is fixed for me. I will do some more testing on physical hardware later.

It's working on my M128 too.

Hated_moron

I don't remember ever having used, or possibly even having seen, a Z80 Second Processor. I knew they existed, and came with a version of my BASIC, but I don't think I realised that it was possible to use graphics. Since the principal purpose of the Z80 Second Processor was supposedly to run 'business' software, I imagine that was an extremely minority interest.

And I certainly hadn't a clue that there was a Z80 Second Processor emulator available. Weird.