Testers wanted for BBC BASIC (Z80) version 5

123578

Comments

  • Last call for reports of bugs or other issues in BBC BASIC (Z80) version 5, if nothing further is reported I'll call it a day and change the version number to 5.00.

    I would want to emphasise, again, that I have done virtually no testing myself. Although writing the code was a form of therapy, in that it exercised my brain without being too affected by my ever-worsening short term memory, testing is quite the opposite.

    I do have a few test programs which I use to check for regressions in BB4W and BBCSDL but these generally don't run in BBC BASIC (Z80) because they rely on non-implemented features (structures, PRIVATE, line continuation, @ variables, long strings, RESTORE LOCAL etc.).

    So anybody who thinks "Richard is bound to have tested it thoroughly himself, so I don't need to" is wrong!
  • (Forwarding this to Stardot)
  • I happened, by pure chance, to notice today that, despite being one of the advertised new features, DIM var LOCAL size was not working at all in BBC BASIC (Z80) v5. Not a subtle fault, not an edge case, but simply not working. :blush:

    I've fixed it now, but it leaves me with a dilemma. Clearly not even the most primitive tests have been carried out, not even a cursory check that each of the features on the list actually works in its simplest and most straightforward way. :o

    I don't want to be associated with a software product (it does after all have my name attached to it) which has undergone so little testing that it may well have dozens of catastrophic bugs.

    So I'm tempted to withdraw BBC BASIC (Z80) v5 completely and delete the GitHub repository. But before I do that I would welcome comments from others.
  • I have been doing some testing - certainly not all the new items are covered but a fair chunk is, with this program that tries to use as much as possible (where I know what the constructs are!)... I don't make any claims about how pretty or otherwise this is.
       10 REM>BBC5Test
       20 ON ERROR PRINT "Oops, caught error ";REPORT$;" (ERR=";ERR;")": IF ERR=17 THEN END ELSE GOTO 310
       30 a=0
       40 b=7
       50 WHILE a<10
       60   IF a==5 EXIT WHILE
       70   a+=1
       80 ENDWHILE
       90 IF a > 4 THEN
      100   PRINT "a=";a
      110 ENDIF
      120 SWAP a,b
      130 CASE a OF
      140   WHEN 5: PRINT "Not swapped"
      150   WHEN 7: PRINT "Swapped, a=";a
      160   OTHERWISE: PRINT "That's odd."
      170 ENDCASE
      180 f%=OPENOUT"bputtest"
      190 BPUT#f%,"Test without newline>";
      200 BPUT#f%,"Another bput with newline"
      210 BPUT#f%,"Another to show above newline."
      220 CLOSE#f%
      230 *TYPE bputtest
      240 PRINT "Testing GET$#file..."
      250 f%=OPENIN("bputtest")
      260 PRINT GET$#f%
      270 PRINT"(that should be just the first line from above...)"
      280 CLOSE#f%
      290 PROClocalerr
      300 This is a mistake.
      310 REM Continue after above error via GOTO in ON ERROR line
      320 PROCmembits
      330 PRINT"Binary %101010 is ";%101010
      340 T$="Test string"
      350 PRINT"T$=";T$
      360 PRINT"LEFT$(T$)=";LEFT$(T$)
      370 PRINT"RIGHT$(T%)=";RIGHT$(T$)
      380 PRINT "Doing LEFT$(T$)=""B"""
      390 LEFT$(T$)="B"
      400 PRINT "T$=";T$
      410 PRINT "Doing RIGHT$(T$,2)=""ke"""
      420 RIGHT$(T$,2)="ke"
      430 PRINT "T$=";T$
      440 PRINT "Doing MID$(T$,9,1)=""o"""
      450 MID$(T$,9,1)="o"
      460 PRINT "T$=";T$
      470 PRINT "T$ is located at &";~^T$
      480 PROCarraybits
      490 PRINT "Shift: -1 >> 3 = &";~-1 >> 3
      500 PRINT "Shift: -1 >>> 3 = &";~-1 >>> 3
      510 PRINT "Shift: &2A << 4 = &";~(&2A << 4)
      520 a&=42
      530 PRINT "Start: a&=";a&
      540 PRINT "a&+=220"
      550 a&+=220
      560 PRINT "Finish: a&=";a&
      570 PRINT"End of program."
      580 END
      590 DEFPROClocalerr
      600 ON ERROR LOCAL PRINT "Error caught ";REPORT$;" (ERR=";ERR;")": ENDPROC
      610 ERROR 42,"Testing"
      620 ENDPROC
      630 DEFPROCmembits
      640 DIM mem% LOCAL 256
      650 PRINT "Locally reserved 256 bytes of memory at &";~mem%
      660 |mem%=PI
      670 PRINT |mem%
      680 PRINT "END=&";~END
      690 ENDPROC
      700 DEFPROCarraybits
      710 LOCAL arr(), arr$(), tmp()
      720 DIM arr(5)
      730 arr()=1,2,3,4,5,6
      740 FOR i%=0 TO 5: PRINT arr(i%);:NEXT:PRINT
      750 PRINT "MOD(arr())=";MOD(arr())
      760 PRINT "SUM(arr())=";SUM(arr())
      770 PRINT "DIM(arr())=";DIM(arr())
      780 DIM tmp(5)
      790 tmp()=2*arr()
      800 FOR i%=0 TO 5: PRINT tmp(i%);:NEXT:PRINT
      810 DIM arr$(5)
      820 FOR i%=0 TO 5: arr$(i%)=STR$(tmp(i%)):NEXT
      830 PRINT "SUMLEN(arr$())=";SUMLEN(arr$())
      840 ENDPROC
    
  • Soruk wrote: »
    I have been doing some testing - certainly not all the new items are covered but a fair chunk is
    Thank you. That's encouraging, especially if it means that the DIM var LOCAL failure was an unlucky example of something that you hadn't got around to testing, rather than an indication that hardly anything had been tested as I assumed.

    I shouldn't have published the source at GitHub as soon as I did, I should have waited until I'd received confirmation of a certain degree of test coverage. Unfortunately one aspect of dementia is a feeling of 'needing to get things done', because although I have good days and bad days the one certainty is that it will inexorably get worse.

    I wonder if I was interrupted when working on DIM var LOCAL, because it looks as though I wrote the code but never checked it. Normally the very first thing I'd do after writing a chunk of Z80 code would of course be to check that it worked, superficially at least.

    But one unfortunate consequence of my very poor short-term memory is that if I'm interrupted in a task, I sometimes never get back to it because I've forgotten what I was doing!

    That possibly conspired with the fact that when I do use DIM LOCAL for testing purposes it's usually just to find where the stack pointer has reached (for example to check that EXIT didn't leave anything on the stack) so then it's DIM S% LOCAL -1 which did work!

    (P.S. The 'Not responding' issue is really bad today, to post this I had to open a new tab).
  • Soruk
    edited June 11
    One thing I have found is DIM var LOCAL size "works" (as in it doesn't report an error) when not run within a procedure - or indeed, at immediate mode. But I'm guessing the memory is immediately freed?
    >DIM a% LOCAL 256: P.~a%
          FBFF
    >DIM b% LOCAL 256: P.~b%
          FBFF
    >
    
    Acorn BBC BASIC complains (with ERR=12) "Items can only be made local in a function or procedure". Matrix Brandy also (same ERR, different wording in the error). Similarly BBCSDL and BBCTTY ("Not in a FN or PROC").
  • Hated_moron
    edited June 11
    Soruk wrote: »
    One thing I have found is DIM var LOCAL size "works" (as in it doesn't report an error) when not run within a procedure - or indeed, at immediate mode.
    That's an example of a shortcut I've taken throughout the recent work on the Z80 version - which is that I've often not bothered with error reporting.

    You'll know, because I've discussed it before, that errors are most importantly reported when the interpreter cannot continue execution. In those circumstances doing something exceptional is unavoidable, and that is most usefully to report an error to the user.

    But in the case of errors which don't actually stop the interpreter running, and are really only of value to the programmer in letting him know he's done something wrong, reporting them can be costly both in respect of code size and execution speed.

    Generally, in BB4W and BBCSDL, I've erred on the side of reporting the error at the expense of size and speed. But with the Z80 version, which is both inevitably very slow - in comparison with modern versions - and (arbitrarily) limited to 16 Kbytes, I've erred on the side of not reporting the error.

    You'll find several examples of this in BBC BASIC (Z80) v5, of which this is one, and for which I make no apology!
    But I'm guessing the memory is immediately freed?
    It's not, no. But really it's no different from the normal (heap) variety of DIM var size because if you accidentally include that in a loop you will eventually run out of memory and receive a 'No room' error or similar. Looked at logically, why should reserving memory on the stack be any different? It too will report a 'No room' error if accidentally done in a loop, so not reporting an error immediately seems entirely sensible to me.

    [Bloody Not responding.. Not responding... Not responding.. it drives me mad].

    Anyway, all versions of BBC BASIC should accept the following, because it's a legitimate way of finding the current value of the stack pointer, even outside a FN/PROC, but whilst all my versions do, neither ARM BASIC nor Brandy does:
          DIM stack%% LOCAL -1
    
  • Soruk
    edited June 12
    An aside - I've implemented DIM var LOCAL -1 in Matrix Brandy, it was just a matter of moving the check slightly then complaining if not in FN/PROC and size != -1.
  • Soruk wrote: »
    An aside - I've implemented DIM var LOCAL -1 in Matrix Brandy, it was just a matter of moving the check slightly then complaining if not in FN/PROC and size != -1.
    Thank you. I find it useful, especially in test programs, to check that there has been no stack leakage. For example to confirm that EXIT doesn't leave anything on the stack I can compare the values assigned to var before and after the loop.

  • Can somebody please give me some guidance on running the Z80 Second Processor emulator in BeebEm (not B-Em, which I find to be unusable in Windows because of incorrect keyboard mapping)?

    If I select 'Acorn Z80 Second Processor' from the Hardware menu, it starts up but reports Disc fault, despite me having (as far as I know) all the right disc image files in Documents... BeebEm... DiscIms.

    1g2khjer634s.png
  • Soruk
    edited June 13
    (Content replaced)
    I initially had the same error after selecting the 2nd Processor. However, after manually attaching the disc image (File -> Load Disc 0...) and select CPM_Utilities_Disc.dsd) then CTRL-F12 (aka CTRL-Break), CP/M booted up.
    pqfymiejmgs9.png
  • Soruk wrote: »
    I initially had the same error after selecting the 2nd Processor. However, after manually attaching the disc image (File -> Load Disc 0...) and select CPM_Utilities_Disc.dsd) then CTRL-F12 (aka CTRL-Break), CP/M booted up.
    Ah, I had no idea I had to do that. Two ancillary questions:
    1. Where is Z80 BBC BASIC? It doesn't seem to be on that disc (at least, not as BBCBASIC.COM or anything that looks promising).
    2. How can I replace it with my new version? I see a menu item Edit.. Import files to disc but I'm guessing that won't work with a CP/M-format disc (or perhaps it will). Anyway, won't I need a 'blank' disc image first to put it on?
    Sorry that these are probably terribly naïve questions, but I'm neither familiar with BeebEm nor with a real Z80 Second Processor.
  • Soruk
    edited June 13
    When I get home from my son's concert I'll set you up with a DSD bootable CP/M disc with your BBCBASIC.COM (renamed BBCTUBE.COM) and your READDFS.BBC utility.

    Then you'd use a blank DFS image in drive 1, import that then use your READDFS util to import into CP/M.
  • Soruk wrote: »
    When I get home from my son's concert I'll set you up with a DSD bootable CP/M disc with your BBCBASIC.COM (renamed BBCTUBE.COM) and your READDFS.BBC utility.
    Not sure what you mean by 'my' READDFS utility, I've never heard of it. What does it do?

    On the original CP/M Utilities disc which comes with BeebEm you can run CRC which will check all the files which should be on that disc and report whether they are intact. BBCBASIC.COM and a load of .BBC files from the Welcome disc are missing, according to that utility!

    Did Acorn perhaps decide not to ship my BASIC with the Z80 Second Processor after all, but forget to alter the CRCKLIST file at the same time? All a bit strange, if you ask me.
  • This is why I said it's your utility.... (attempting to remote control my machine from my phone....)
    nwnat2vbp3m3.png
  • Soruk wrote: »
    This is why I said it's your utility....
    Hmm, that's more than 40 years ago! Even if it did have something to do with me, which I'm doubtful of, I have no recollection of it so it might as well not have. :neutral:

    More importantly, I don't have a copy (I noted earlier that there are no .BBC files on the Acorn CP/M Utilities Disc) so if it's something I will need in order to copy the new version of BBC BASIC (Z80) onto a BeebEm disc I'm stuffed.
  • Here you go --> http://www.matrixnetwork.co.uk/temp/CPMBASICTUBE.zip

    That's a bootable CP/M disc with BBCBASIC for Z80 (not renamed) and the READDFS utility. However, as that disc is completely full (STAT claims 0K free) you might want to delete some items you don't care about from it, so copied files have somewhere to go.
  • Soruk wrote: »
    That's a bootable CP/M disc with BBCBASIC for Z80 (not renamed) and the READDFS utility.
    Thanks, I'll take a look at it tomorrow and try to figure out what to do with it. This is all way outside my comfort zone.

    It's a shame that BeebEm doesn't have the capability - which RunCPM, RedSquirrel and RPCEmu all do have - of mapping a directory in the host filesystem (Windows in my case) so it appears as a disc to the emulator.
  • B-Em has this - VDFS, its equivalent to RPCEmu's HostFS. Unfortunately I couldn't find a precompiled Windows version less than 12 years old..

    Your transfer tool didn't work for VDFS (unsurprisingly, as it reads the *INFO output and is written specifically for DFS) but it did give me the hints I needed to write an alternative (though excruciatingly slow) file copier that also didn't have a 32K file size limit - byte... by... byte.
  • Soruk wrote: »
    B-Em has this - VDFS, its equivalent to RPCEmu's HostFS. Unfortunately I couldn't find a precompiled Windows version less than 12 years old.
    Perhaps that's also why the keyboard mapping is broken in Windows. I couldn't even issue 'star' commands in B-Em: pressing the * key (Shift+8) resulted in the ( character being produced! There was a 'redefine keyboard' menu option but it didn't seem to help, at least I failed.

    So if I was to try to create a 'BBC BASIC (Z80) v5' for the Acorn Z80 Second Processor testing it (and fixing faults) could be a real pain, because of all the steps needed to get the BBCBASIC.COM file from the RunCPM build environment to the BeebEm emulator environment.

    If you or anybody else can come up with any shortcuts or automations to make this easier, I would be interested.
  • Here's a bootable CP/M disc image with BBC BASIC for Z80SP (renamed to BBCTUBE.COM), BBC BASIC for CP/M v3.00 (BBCCPM.COM), the latest BBCBASIC.COM v5beta5, along with the latest copy of the source Z80 files, Z80ASM.COM, L80.COM and a slightly reworked MAKE.SUB to use L80 instead of LINK, and call all the assembles on one line so it doesn't have to reload Z80ASM from disc each time. It also includes READDFS.BBC to copy files from DFS discs (use drive 1), and my BEEBCOPY.BBC that can use any host filesystem but is insanely slow. It's also got that BBC5TEST.BBC I included earlier in the thread.
    http://www.matrixnetwork.co.uk/CPM-BBCBASIC5.zip
  • Thanks for building and sharing that image! Works for me in B-em (2015 Windows version running in WINE)

    It seems to be the case that B-em uses the BBC Micro keyboard layout, which works well if you have the muscle memory or a picture of an old keyboard to work with. On my keyboard, the two keys to the right of L are the semicolon/colon and the quote/double quote. In B-em they give me semicolon/plus and colon/asterisk. This is not terribly convenient but I can work with it!
  • Soruk wrote: »
    Here's a bootable CP/M disc image
    Thanks, but I'm not too sure what I would do with that. There's no way I would attempt to develop BBC BASIC (Z80) v5 in a Z80 Second Processor emulator, not least because I can't edit the source files, run diff, backup to OneDrive and/or dropbox, update the GitHub repository etc., all of which are vital tools and often called from Windows batch files.

    So inevitably if I try to build a BBCBASIC.COM configured for the Z80 Second processor it's going to end up as a regular file in a Windows directory. What I ideally want is some automated or semi-automated way of getting that file into the Z80 Second Processor emulator for testing.
  • BigEd wrote: »
    It seems to be the case that B-em uses the BBC Micro keyboard layout
    That's insane, though, isn't it? The only advantage I can think of is for games which use keys clustered together in a specific pattern (left-right-up-down or whatever) but I doubt that games like that ever use shifted keys like parentheses.

    P.S. How is this forum behaving for you? The 'Not responding' issue is now far worse than it has ever been before, making it close to unusable here. I have to open a new tab at least once for every paragraph to get any kind of responsiveness. Three times in this post so far.

    Why Michael sticks with it I have no idea. My advice would be to switch to phpBB.
  • A Google search suggested that the utility I need to transfer a regular Windows file to a CP/M disk image suitable for the (emulated) Z80 Second Processor is CPMFiler at Jonathan's site here. I've downloaded that, but all I can see is a way to copy in the other direction (from the CP/M disk image to a regular file).

    Is that right? Does that utility not also Copy windows files to the disk image? How can I do that, preferably with a command-line tool that I can automate using a batch file? There must be a way, but so far I haven't found it.
  • Soruk
    edited June 15
    I've seen that tool - it is indeed one-way, and can only read CP/M discs (and itself runs on a BBC.) I used it back when I thought I had hit a bug with the delete stuff, to SAVE the file to disc, then extract it and compare with your original binary.

    As far as I can tell, there is no tool to directly write to a CP/M disc image from Windows. However, while a bit manual, I have successfully, in BeebEm in Windows, booted into CP/M, with a blank DFS disc image in drive 1, then used Edit -> Import Files to Disc -> Disc 1 to drop a file on that image, then used your READDFS to copy the file on to the CP/M disc. Still beats trying to edit and build the code within the emulator! While there is a VDFS for BeebEm here https://mdfs.net/Apps/Filing/ the import file option to a blank DFS image is far faster.
  • Soruk wrote: »
    I've seen that tool - it is indeed one-way, and can only read CP/M discs (and itself runs on a BBC.)
    When you say "itself runs on a BBC" the file I downloaded from Jonathan's site was CPMFiler.exe which I assumed was a Windows executable, and certainly it seems to run in that environment (but by the sound of it isn't useful for my purposes anyway).
    Still beats trying to edit and build the code within the emulator!
    Maybe, but I need a method that I can automate, or at least run just with a few clicks or keypresses. One effect of my Alzheimer's is that any code I write is invariably full of errors, if I was ever able to write code which had a chance of working 'first time' I certainly can't now! So I will be needing to run the edit-build-test cycle at least dozens of times.

    Is there at least a Windows command-line tool which will copy a native file into a DFS-style disk image, so that I can avoid the faff of having to run commands from BeebEm's menus? Then at least I should be able to use the 'command history' in a Windows CMD window to reduce the amount of typing and mousing.

    Failing that, if I was to attempt to build B-Em from source rather than using the pre-compiled Windows executable, do you think it might fix the keyboard mapping stupidity?
  • Probably, the dirtiest of hacks - I can make a test disc image, no fragmentation, that you can use a BBCSDL program to *LOAD the image in, then *LOAD your test file to a pre-determined point in the image, *SAVE it back out then run the disc in the emulator. I'll do some tests on that approach.
  • Beebasm has a way to copy local files to SSD images: see
    https://github.com/stardot/beebasm/
    and particularly PUTTEXT and PUTFILE. It's also an assembler (of 6502 code) but that's not the important point in this case.

    (MMB_Utils is my usual tool of choice for scripted operations on disk images, but it requires perl and feels like it would be second choice in this case.)
  • Soruk wrote: »
    Probably, the dirtiest of hacks - I can make a test disc image, no fragmentation...
    I did wonder whether it might be possible to hack Jonathan's CPMFiler utility to copy in the direction I want, with the proviso that one is copying into an existing non-fragmented file of at least the same length as the source file. That's similar to the approach you suggest, but might be easier to achieve.