Testers wanted for BBC BASIC (Z80) version 5
Comments
-
I noticed you included the speed test SPEED.BBC - but as TIME isn't working the program just hangs. (It works in the Acorn-specific version.) Or, is there a timer in the Z80 which is failing in PiTubeDirect's emulation?
0 -
TIME works fine, so long as you run it using the supplied runcpm emulator. I drew attention to INKEY not working if you choose to run it on a different platform, TIME is in the same category (they both require a source of accurate 100 Hz ticks, which is not generally available in CP/M).I noticed you included the speed test SPEED.BBC - but as TIME isn't working
0 -
I have updated BBCZ80V5.zip to fix an issue with string allocation. Please download a new version from the same place as before.0
-
For my own interest I have searched what archived files I have from the 1980s (it's a miracle I still have anything, really, because it was all on 8" floppy disk back then). Although I have found source files related to the Cambridge Z88 and Amstrad NC100/150/200 versions of BBC BASIC, there is nothing related to the Acorn Z80 Second Processor version.Hated_moron wrote: »I don't remember ever having used, or possibly even having seen, a Z80 Second Processor.
Along with having no recollection of ever having used a Z80 Second Processor, and my preference at the time for customising to be done by the recipient, that makes me think the various interfaces between BBC BASIC and the Tube etc. were written by Acorn, or somebody they subcontracted. I probably had nothing to do with it.
So if the source files are not in what's left of Acorn's own archives, they have probably been lost. Therefore if somebody wanted to create a custom Z80 Second Processor version of BBC BASIC (Z80) v5.00 they would have to start from scratch. I will be releasing the source of the generic interpreter on GitHub if anybody wants to attempt it.
I have updated the README.TXT in the Zip to mention TIME as well as INKEY as unlikely to work if run outside the RunCPM environment (I call BDOS function 248 to read the clock, but I suspect that is RunCPM-specific).
0 -
Thanks for the updated zip file Richard! Very interesting possibility that the original Z80 MOS shim (if I can call it that) might have been written in-house by Acorn. But great to hear that you plan to share the source to this new V5 in due course. I'm sure there are people who could do the adaptation - and given the popularity of PiTubeDirect, it will surely be done.0
-
I'm quite busy this weekend, but a possible direction for testing is to see if many of the 200 Rosetta Code examples of BBC Basic can run in this textual environment and with this dialect - and if they run correctly, of course.
https://rosettacode.org/wiki/Category:BBC_BASIC
0 -
I think it's highly likely, or at least subcontracted to a third party due to lack of in-house Z80 experience at Acorn. Either way it's a moot point, because I don't have it!Very interesting possibility that the original Z80 MOS shim (if I can call it that) might have been written in-house by Acorn.
Have archives survived from that era which might possibly contain the source files? Is it possible that Jonathan Harston has come across them in his years of gathering information (I have no way of contacting him)?
In the absence of the original file(s), would reverse-engineering (i.e. disassembling) be practical? Or if the best approach is to rewrite it from scratch, who might do that? It would need to be a Z80 programmer with some understanding of the Tube interfaces.
0 -
I'm quite sure a new shim could be rustled up, even without original source - Dave and Dominic have done this kind of thing several times and I'm sure others have too.
It's still possible the sources are out there, in some person's collection of bits. I'll ask.0 -
Do we even know the architecture? Presumably file I/O is all done via standard CP/M BDOS calls so I could easily supply that element myself (if it just involves taking the existing CP/M code and stripping out everything not related to files).I'm quite sure a new shim could be rustled up, even without original source
What about OSCLI though, how does that currently work in the Acorn edition? I imagine some OSCLI calls are file-related, and therefore need to 'talk to' CP/M, but others are probably MOS-related. Does it first check for the former and then forward unrecognised OSCLI calls across the Tube? Do we even know?
Then how are the remaining (non-file I/O) functions handled? In the CP/M edition this is split between two modules: a fixed-size module from &100-&1FF intended to be patched by the end-user for simple things like moving and reading-back the text cursor (caret) position, and a separate module which must be assembled and linked to support graphics, sound and so on.
Do we have any idea whether the Acorn Z80 Second Processor edition follows this same architecture or not? I can look in the User Guide and see what that says, but we may have to probe the binary module to get more insight.
0 -
MOS calls are available - this is from your new BBC BASIC 5 for CP/M:
(updated with an OSCLI call)0 -
Well, I have the answer - and it's not really the one I wanted. Seemingly I did do it, because I've found this 8" floppy in the loft. But of course I can't read it (even if I had a working drive, it's a Zelda-format disk, not a CP/M disk; it would have to be dumped as raw sectors).Hated_moron wrote: »For my own interest I have searched what archived files I have from the 1980s (it's a miracle I still have anything, really, because it was all on 8" floppy disk back then).
0 -
Wow! What a find! I'm sure there's a way, although I personally don't have the equipment for it.0
-
Hopefully this isn't the daftest thing I've ever posted on the internet, but I wonder if the Centre for Computing History or the National Museum of Computing might be able to assist in copying the data on it to someting slightly more modern (and archivable).0
-
Not worth it though, is it? I'm thinking that as it looks like it's my code (albeit that I have zero recollection of writing it) maybe disassembly isn't so silly because I might recognise my 'style' and be able to make more sense of it than I would of code written by somebody else.Wow! What a find! I'm sure there's a way, although I personally don't have the equipment for it.
Where can I obtain a copy of the BBCBASIC.COM supplied with the Acorn Z80 Second Processor?0 -
I've put it here - http://www.matrixnetwork.co.uk/BBCBASIC-AcornZ80.zip0
-
Thanks.I've put it here - http://www.matrixnetwork.co.uk/BBCBASIC-AcornZ80.zip
I have found a UK company who can still recover data from 8" floppies, if they are in good condition (I have no reason to think that the disk in question is damaged, but it was written more than 40 years ago!). They charge £90 for one disk, which doesn't seem unreasonable, but I'm not personally inclined to fork out that sum from my own resources.
So do you think there would be enough interest from users of the Z80 Second Processor (if only emulated) for them collectively to come up with this sum, or at least a proportion? It would certainly make the exercise of creating a v5.00 BASIC for that platform far easier than either disassembling or starting from scratch.
I have no feel for the amount of enthusiasm out there for what seems a very niche interest.
0 -
I should add that the Zelda floppy format was one I devised myself (and used in various items of BBC equipment, such as the HF Automation VDUs at transmitting sites like Daventry, Woofferton, Rampisham, Hong Kong, Seychelles) so once I had a raw dump I should have no trouble recovering meaningful files from it.Hated_moron wrote: »it's a Zelda-format disk, not a CP/M disk; it would have to be dumped as raw sectors.pg[/img]
0 -
Sounds fairly promising. I'll put out some feelers about a funding drive. It turns out I posted a thread elsewhere about Zelda - hope there's nothing there which needs to be corrected.
https://retrocomputingforum.com/t/zelda-and-zeus-z80-at-the-bbc-late-70s/1624
0 -
(BTW there's a bit of a problem with museums, either holding onto stuff forever or even mis-handling it. Going there and using their expertise would be one thing, but sending them something might be a mistake.)1
-
It's no good asking me, my memory is too poor and (as we found today) too unreliable.I posted a thread elsewhere about Zelda - hope there's nothing there which needs to be corrected.
It does make me nostalgic for happier times though. Little did I know then how awful my life was to become.0 -
-
I've updated BBCZ80V5.zip again, this time to fix a bug which could result in writing to memory above HIMEM in the case of certain errors occurring (such as 'No GOSUB').
Although this is now fixed, in systems with interrupts running, which is likely, there is still a small statistical risk of memory above HIMEM being corrupted if an interrupt were to occur at an unfortunate time.
Realistically I cannot fix this, and I'm sure the old version 3.00 suffered from the same weakness. It could be mitigated by initialising HIMEM to a few bytes below the true top of available CP/M memory, although I've not done that in this version.
0 -
Thanks for the update! Would it be a workaround for a program to adjust HIMEM downward by say 100 when it starts?0
-
One problem with that suggestion is that "adjusting HIMEM downwards" is cumulative: every time you run the program HIMEM will be lowered again. If you run it enough times you will run out of memory, and even if there's enough left for that particular program there might not be for another program that you want to run in the same 'session'.Thanks for the update! Would it be a workaround for a program to adjust HIMEM downward by say 100 when it starts?
BBC BASIC (in general, discounting the availability of OS-specific functions to do so) has no way of finding out what the value of HIMEM was originally in order to be able to reset it to that value after having lowered it. The only 'universal' way of doing that is to quit BBC BASIC and restart it - not necessarily that onerous, but not something that a user will necessarily expect to have to do.
Only the designer of a particular platform and OS will know whether corrupting a few bytes of memory above HIMEM will be dangerous or not. On a BBC Micro it will likely be screen memory, and therefore the worst that might happen is a graphical glitch, which if it happens as the result of an error isn't important. But on some platforms there might be critical OS memory immediately above HIMEM, when the consequences could be much more serious.
So it seems to me that the most appropriate mitigation is for whoever originally configures the system (including the custom interface to BBC BASIC) to deliberately lower HIMEM a little during initialisation if corrupting memory above HIMEM might be dangerous, or not it if isn't.
0 -
Interesting point, and yes, that sounds like an appropriate mitigation.
(Perhaps rounding HIMEM down to, say, 128 more than a 256 byte boundary would in most cases allow for some space and at the same time be idempotent.)0 -
That seems excessively wasteful, on an 8-bit system where every byte is valuable. I'd be more inclined to round it down by, say, 8 or 16 bytes which should be more than sufficient. I think in BBC BASIC for Windows, which potentially suffers from a similar issue, I reduce it by 4 bytes.Perhaps rounding HIMEM down to, say, 128 more than a 256 byte boundary
0 -
ah, understood, the margin of potential overlap is a bit smaller than I imagined0
-
Having received no further reports of bugs (of course I have no idea how much testing has actually been done!) I have created a repository on GitHub here. This version currently announces itself as 5beta2; hopefully at some point, when I have more confidence in it, I will update it to Version 5.00.
Please continue to do as much testing as you have the time and inclination for. Some of the new features are hopefully simple enough that the likelihood of a bug is small (for example the address-of operator ^ ought either to work or not). But others, for example the whole-array operations, have a myriad of possible subtle and obscure failure modes.
Arguably one of the most valuable post-v5 additions, especially in the context of an 8-bit CPU with limited address space, is the 'byte' (char) array array&(). I think I remarked in my Stardot Zoom presentation that it has always surprised me that despite having 'byte indirection' Acorn's BASICs have never had byte variables or arrays.
1 -
Many thanks for sharing the code and giving it a nice unique version number!
It does feel good to me to have these improvements to hand.1 -
Thank you very much for sharing - I saw the source for v3.00 elsewhere on git but couldn't get it to assemble on any Linux tools. I see you actually build within CP/M so if I can track the tools down I should be able to replicate the build process.0
