Testers wanted for BBC BASIC (Z80) version 5

123468

Comments

  • Hated_moron
    edited June 15
    BigEd wrote: »
    (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.)
    Does MMB_Utils by any chance work with CP/M disk images as well as DFS disk images? If it does, I might well be prepared to put up with it needing Perl, because it would be an ideal solution.
  • BigEd wrote: »
    (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.)
    Does MMB_Utils by any chance work with CP/M disk images as well as DFS disk images? If it does, I might well be prepared to put up with it needing Perl, because it would be an ideal solution.
  • BigEd
    edited June 15
    (I don't think MMB_Utils will do that)

    I think I'd recommend a look at http://www.moria.de/~michael/cpmtools/ - I think it might even be included in some linux distributions, but I gather it's portable C.
  • BigEd wrote: »
    Beebasm has a way to copy local files to SSD images: see
    https://github.com/stardot/beebasm/
    and particularly PUTTEXT and PUTFILE.
    Sorry if I'm being particularly thick here, but from a very quick scan of the README it looks as though PUTFILE is an Assembler Directive that one uses within a 6502 source file, rather than something that can be specified at a command prompt. Does that mean I'd have to write a contrived source file, with no actual 6502 code, and 'assemble' it to do what I want? I've probably completely misunderstood.
  • BigEd
    edited June 15
    Yes, I'm thinking a do-nothing source file with just PUTFILE might do the trick. I haven't tried it in that fashion.

    BTW cpmtools is also found here https://github.com/lipro-cpm4l/cpmtools
    and it says one can build for Windows.

    (For future reference, here's an article setting up a full z80 cross-build environment using cpmtools)
  • I notice there's a story on stardot for doing this:
    Creating your own CP/M disks

  • Hated_moron
    edited June 15
    BigEd wrote: »
    (I don't think MMB_Utils will do that)
    Blast!
    I think I'd recommend a look at http://www.moria.de/~michael/cpmtools/ - I think it might even be included in some linux distributions, but I gather it's portable C.
    Is the Acorn CP/M disk format sufficiently 'standard' for it to work, and does it work with .dsd disk image files? There's very little information at the link you gave to help determine either.
  • Soruk
    edited June 15
    Here you go --> http://www.matrixnetwork.co.uk/cpminsert.zip

    Filenames are hardcoded - feel free to amend as required. Tested in both BBCTTY and Matrix Brandy. This inserts "BBCBASIC.COM" into "cpmbbctest.dsd" that can be attached to drive 1 / B. The placeholder file is 32K in size so will work fine unless your modified BBCBASIC.COM exceeds that. For testing / example purpose the BBCBASIC.COM included is your Beta5.

    (Don't try to run BBCBASIC.COM without running the insert first - it's just placeholder data I used to figure out how to insert the file!)

    It's a bit more complicated than a straight *LOAD into place as CPM's allocation is a bit odd at the best of times and a double-sided image file is interleaved.
  • BigEd wrote: »
    I notice there's a story on stardot for doing this:
    Creating your own CP/M disks
    My head well and truly hurts after skimming through that!

    I'm currently thinking that something based on Michael's suggestion of overwriting an existing non-fragmented file is the way to go; I'm unlikely to be adding enough to the BBC BASIC code to change the file length (once rounded up to a multiple of sectors).

    So if I can transfer my file once the hard way (via an intermediate DFS disk image, using BeebEm's 'Import files from disk' menu option and READDFS.BBC) perhaps we can devise an easier way of updating that file when required by simply overwriting the sectors.

    One possibility might be to modify Jonathan's CPMFiler utility to do that (it already works in the opposite direction).
  • Ah, looks like Michael has saved the day - thanks for that new zip file Michael!
  • BigEd wrote: »
    (I don't think MMB_Utils will do that)

    I think I'd recommend a look at http://www.moria.de/~michael/cpmtools/ - I think it might even be included in some linux distributions, but I gather it's portable C.
    Just tried it - it doesn't like the CP/M-on-DFS interleaved layout that the BBC uses.
  • Soruk wrote: »
    I'm getting 'Address out of range at line 20' when I try to run it in BBCTTY; in Matrix Brandy I just get a 'flash' of a window opening and closing again, but cpmbbctest.dsd doesn't appear to have been modified.

    Is it possible the program isn't '64-bit clean', for example might it need a *HEX 64 (or whatever the Brandy equivalent is) but not have one?
  • Is it possible the program isn't '64-bit clean', for example might it need a *HEX 64 (or whatever the Brandy equivalent is) but not have one?
    Adding a *HEX 64 does indeed seem to make it run in BBCTTY.
  • Soruk
    edited June 15
    It definitely should be 64-bit clean - you've got the text-form program there too (cpminsert.txt).
       10 DIM mem%% 409600
       20 OSCLI"LOAD cpmbbctest.dsd "+STR$~mem%%
    
    Anyhow, I've updated the zip, adding the line
    5 IF INKEY(-256)=77 THEN SYS"Brandy_Hex64",1 ELSE OSCLI"HEX 64"
    
    which should fix any 64-bit issues on ~mem%% should the workspace not be in 32-bit clean space. It worked fine without it on my Linux box.
  • Soruk wrote: »
    It definitely should be 64-bit clean - you've got the text-form program there too (cpminsert.txt).
       10 DIM mem%% 409600
    
    On my Windows 11 laptop mem%% is &20F42B71314 - definitely not in a 32-bit-addressable range!
    It worked fine without it on my Linux box.
    Luck, I imagine.

    But after that 'false start' it does seem to be working, and it's going to make a huge difference to my ability to make a Z80 Second Processor edition of BBC BASIC (Z80) v5. Thank you! :smiley:
  • You're welcome, glad I was able to help.
  • Hated_moron
    edited June 16
    It's looking like there is a bug in the Tube interface of the (emulated) Z80 Second Processor. If I attempt to read the TIME$ string using OSWORD 14 I'm getting back only 16 characters, not the full 25. See the screenshot below, I can't see how it could be something I'm doing wrong:

    bzfver1eq97z.png
  • Soruk
    edited June 16
    Looks like a BeebEm bug, it's fine in B-Em. You're not doing anything wrong.
    (This screenshot is from V2.2 for Z80SP and generic 5Beta5)
    y6zqtnvbpu7f.png

    Edit: Just to make sure, you are running with a machine type of Master 128?
  • Soruk wrote: »
    Looks like a BeebEm bug
    Oh, that's a pain (from a testing perspective). I seem to be running the latest version (4.19, 1st May 2023), do you believe the developers are aware of this bug?
    Just to make sure, you are running with a machine type of Master 128?
    Hmm, I didn't think any of the earlier models had an RTC chip (hence TIME$ wouldn't be able to return even the current date, which my screenshot shows it doing). On a quick check TIME$ returns nothing at all on a standard Model B.
  • Soruk
    edited June 16
    Seems like it's a Z80 Tube ROM bug, and B-Em has JGH's bugfixed ROM. I'm out for the day with my kid doing Father's Day stuff, but will take a closer look later at seeing if the fixed ROM can be added to BeebEm (and testing PiTubeDirect too).

    It's likely people with a real Z80SP will also run into this. So, it's not your program at fault.

    https://mdfs.net/Software/Tube/Z80/Patch121.txt
  • Soruk wrote: »
    Seems like it's a Z80 Tube ROM bug, and B-Em has JGH's bugfixed ROM.
    Except that at the Stardot link you gave it also says this: "You'll get the same problem with the 6502 second processor" but you don't, that's one of the first things I checked! If you select "65C02 Second Processor" (the only 6502 Second Processor listed in BeebEm) it works perfectly, returning all 25 characters.

    So either the analysis is incorrect, or BeebEm has JGH's fix for the 65C02 but not for the Z80, which wouldn't make much sense. So I'd say the jury's still out on this one.
  • Soruk
    edited June 16
    This evening I'll do some tests across B-Em and PiTubeDirect. Unfortunately I don't have a real physical Z80SP to test with.
    (And I'll see if it's just a case of dropping the new ROM in place for BeebEm).
  • Soruk wrote: »
    (And I'll see if it's just a case of dropping the new ROM in place for BeebEm).
    I got the impression from the comments at Stardot that there was no easy way to change the Z80 Second Processor ROM in BeebEm (the I/O processor ROMs are easily configurable but the 2nd Processor ROMs not, which makes no sense to me, but that's often the case!).

  • If I enable AMX Mouse emulation in BeebEm how do I read the mouse position and buttons in BASIC? I had expected that ADVAL(7), ADVAL(8) and ADVAL(9) would work, but they don't.
  • I think it needs a support ROM. Again, something I haven't played with in detail.
  • Soruk
    edited June 16
    Back to the OSWORD 14 issue, I note that both B-Em and PiTubeDirect both have ROM v1.21, which includes JGH's bugfixes. To install the fixed ROM in BeebEm, backup your Z80.rom in Documents/BeebEm/BeebFile and replace it with the file from https://mdfs.net/Software/Tube/Z80/TubeZ80, naming it Z80.rom.

    Then when you start up the Z80 Tube emulation in BeebEm you'll see the "Acorn TUBE z80 64K 1.21" message instead of "... 1.20", and the test program in the screenshots above both run correctly. So yes, not a BeebEm bug but a Tube ROM bug.

    Edit: BeebEm maintainer is going to update the ROM in the next release.
  • Soruk
    edited June 16
    If I enable AMX Mouse emulation in BeebEm how do I read the mouse position and buttons in BASIC? I had expected that ADVAL(7), ADVAL(8) and ADVAL(9) would work, but they don't.
    My hunch was right - install MouseROM from https://mdfs.net/Software/BBC/Modules/ then after *MOUSE ON the ADVAL calls work correctly (at least in 6502 BASIC, including 6502 Second Processor). No pointer is drawn on screen unlike RISC OS, however.
    (My caveat: tested this in B-Em, though see no reason why it shouldn't also work in BeebEm if AMX support works)
  • Soruk wrote: »
    (My caveat: tested this in B-Em, though see no reason why it shouldn't also work in BeebEm if AMX support works)
    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?
  • I've released an updated version of BBC BASIC (Z80) - v5beta6 - which includes a binary for the Acorn Z80 Second Processor (BBCTUBE.COM in the zip, bin/acorn/BBCBASIC.COM at GitHub).

    The sound and graphics etc. features which should work in this version are almost totally untested, because I have no test programs to run. I cannot even find the Welcome programs, which would normally have come with the Z80 Second Processor, on any of the BeebEm .dsd disc images.