Request for help in organising/releasing source code

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
User avatar
bakoulis
Posts: 295
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: Request for help in organising/releasing source code

Post by bakoulis » Thu Sep 20, 2018 8:24 pm

Richard Russell wrote:
Thu Sep 20, 2018 5:59 pm
bakoulis wrote:
Thu Sep 20, 2018 8:19 am
I suspect the problem is from use of bbasmb_x86_64 assembler inside makefile.
But it shouldn't be used! I've added code to the makefile (which Google found) that tests whether your platform is 32 or 64-bits and assembles the appropriate file. If your system is 32-bits, which I think you said it was, the file that it should be assembling is bbdata_x86_32.nas not bbdata_x86_64.nas:

Code: Select all

ifeq ($(LBITS),64)
bbdata.o: ../../src/bbdata_x86_64.nas
	nasm -f elf64 -s ../../src/bbdata_x86_64.nas -o bbdata.o
else
bbdata.o: ../../src/bbdata_x86_32.nas
	nasm -f elf32 -s ../../src/bbdata_x86_32.nas -o bbdata.o
endif
Maybe is something else the fault. My OS is Linux Mint 32bit.
The errors are:

Code: Select all

gcc -Wall -c -O2 ../../src/bbmain.c -o bbmain.o
gcc -Wall -c -O2 ../../src/bbexec.c -o bbexec.o
gcc -Wall -c -O2 ../../src/bbeval.c -o bbeval.o
../../src/bbeval.c: In function ‘math’:
../../src/bbeval.c:552:5: warning: implicit declaration of function ‘__builtin_saddll_overflow’ [-Wimplicit-function-declaration]
     if (! __builtin_saddll_overflow (x.i.n, y.i.n, &sum))
     ^
../../src/bbeval.c:566:5: warning: implicit declaration of function ‘__builtin_ssubll_overflow’ [-Wimplicit-function-declaration]
     if (! __builtin_ssubll_overflow (x.i.n, y.i.n, &dif))
     ^
../../src/bbeval.c:584:5: warning: implicit declaration of function ‘__builtin_smulll_overflow’ [-Wimplicit-function-declaration]
     if (! __builtin_smulll_overflow (x.i.n, y.i.n, &prod))
     ^
../../src/bbeval.c: At top level:
../../src/bbeval.c:2623:1: internal compiler error: in fold_convert_loc, at fold-const.c:1922
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cchCZUT7.out file, please attach this to your bugreport.
make: *** [bbeval.o] Error 1
and the log file is attached.
Attachments
log.zip
(27.16 KiB) Downloaded 10 times
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Thu Sep 20, 2018 9:34 pm

bakoulis wrote:
Thu Sep 20, 2018 8:24 pm
The errors are:

Code: Select all

warning: implicit declaration of function ‘__builtin_saddll_overflow’
That seems pretty clear: obviously it's not going to work if a function called by my code isn't present! If ‘__builtin_saddll_overflow’ is missing it would suggest your version of GCC is rather old. I said way back that my code is the opposite of 'plain vanilla': it uses all sorts of GCC extensions, built-ins and intrinsics; if it doesn't compile for you it's your problem not mine. :lol:

Soruk
Posts: 333
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Request for help in organising/releasing source code

Post by Soruk » Thu Sep 20, 2018 9:38 pm

Richard Russell wrote:
Thu Sep 20, 2018 9:34 pm
bakoulis wrote:
Thu Sep 20, 2018 8:24 pm
The errors are:

Code: Select all

warning: implicit declaration of function ‘__builtin_saddll_overflow’
That seems pretty clear: obviously it's not going to work if a function called by my code isn't present! If ‘__builtin_saddll_overflow’ is missing it would suggest your version of GCC is rather old. I said way back that my code is the opposite of 'plain vanilla': it uses all sorts of GCC extensions, built-ins and intrinsics; if it doesn't compile for you it's your problem not mine. :lol:
Actually, his compiler might be too new. It's using (and showing warnings with) a -W flag that isn't recognised by the gcc on any of my machines (though I can try a Fedora build tomorrow) - which picked up a few hiccups in Matrix Brandy.

What output do you get from:

Code: Select all

gcc --version
Last edited by Soruk on Thu Sep 20, 2018 9:39 pm, edited 1 time in total.

User avatar
bakoulis
Posts: 295
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: Request for help in organising/releasing source code

Post by bakoulis » Thu Sep 20, 2018 9:43 pm

Code: Select all

 ~ $ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Mint 17.3 is old now but not obsolete, so I think is a compatibility problem here.
I will test on Mint 18 64bit soon and I post the results for both BBCSDL and Matrix.
Last edited by bakoulis on Thu Sep 20, 2018 9:49 pm, edited 2 times in total.
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Thu Sep 20, 2018 9:54 pm

Soruk wrote:
Thu Sep 20, 2018 9:38 pm
Actually, his compiler might be too new
If a "too new" version of GCC has removed ‘__builtin_saddll_overflow’ I'm screwed, because I make heavy use of that and other similar built-ins (it is possible to predict an overflow by examining the operands, but it's much slower than simply testing the CPU's hardware overflow flag which is what the function does). But why would it be removed? Clang implements it too.

User avatar
dhg2
Posts: 120
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

Re: Request for help in organising/releasing source code

Post by dhg2 » Thu Sep 20, 2018 11:14 pm

Richard Russell wrote:
Thu Sep 20, 2018 9:34 pm
If ‘__builtin_saddll_overflow’ is missing it would suggest your version of GCC is rather old.
That is definitely the problem. I tried compiling on my desktop computer with Debian oldstable (Debian version 8 with gcc (Debian 4.9.2-10+deb8u1) 4.9.2 ) and got a few 'undefined reference' errors including __builtin_saddll_overflow. It compiles and runs on my laptop with Debian stable (Debian version 9)

bakoulis, I would recommend that you update to a newer distro. I'll eventually be doing the same on my desktop.
Last edited by dhg2 on Thu Sep 20, 2018 11:16 pm, edited 3 times in total.
Regards,
- Patrick

User avatar
bakoulis
Posts: 295
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece
Contact:

Re: Request for help in organising/releasing source code

Post by bakoulis » Fri Sep 21, 2018 8:43 am

I thought the problem was something on code.
If the problem is the old compiler, is not a problem at all.
I can always to use the precompiled BBCSDL file from Richard's homepage, which it runs perfect on my distro.
Last edited by bakoulis on Fri Sep 21, 2018 8:48 am, edited 4 times in total.
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 21, 2018 8:54 am

bakoulis wrote:
Thu Sep 20, 2018 9:43 pm
Mint 17.3 is old now but not obsolete, so I think is a compatibility problem here.
I'm not prepared to compromise performance just so it will compile on old distros. In any case, as I've said before, you are far better off running the downloadable 32-bit Linux executable (with the D-Bus workaround if necessary) because it's about twice as fast as what you can compile from the C sources, and has an embedded x86 assembler.

Soruk
Posts: 333
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Request for help in organising/releasing source code

Post by Soruk » Fri Sep 21, 2018 9:34 am

Richard Russell wrote:
Thu Sep 20, 2018 9:54 pm
Soruk wrote:
Thu Sep 20, 2018 9:38 pm
Actually, his compiler might be too new
If a "too new" version of GCC has removed ‘__builtin_saddll_overflow’ I'm screwed, because I make heavy use of that and other similar built-ins (it is possible to predict an overflow by examining the operands, but it's much slower than simply testing the CPU's hardware overflow flag which is what the function does). But why would it be removed? Clang implements it too.
Seems like I got it totally wrong - Sorry Richard.

My Fedora netbook has gcc 7.3.1. While I haven't tried to compile your BASIC on it (it's a 32-bit only machine) I very much doubt now that gcc 4.8 could be classed as "too new". One again, my apologies.

Coeus
Posts: 1230
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Fri Sep 21, 2018 11:01 am

Richard Russell wrote:
Sun Sep 16, 2018 4:11 pm
scruss wrote:
Sun Sep 16, 2018 3:14 pm
While an assembler might be part of the 198x BBC BASIC specification, I think it has outlived its usefulness.
I can't agree. It may be that you didn't realise this, but the debugging features (List Variables, Single Step, Profiler etc.) which are part of the BBCSDL IDE currently rely on it, and don't work in the 64-bit editions. So do some of the libraries (e.g. TIMERLIB) which again aren't available in the 64-bit editions.
I am guessing the fact that no-one has, at least yet, volunteered to provide the missing assembler is part of the reason for your comment that history has not found contributors/collaborators to be forthcoming.

I did have a quick look at the 32 bit ARM assembler to see how it interfaces to the rest of BBCSDL. Then I looked to see what else was out there in the way of X86 assemblers that can handle 64 bit code. I found fasm, yasm and nasm, the latter of which you already use in the build process. Looking specifically at nasm, and counting only the lexical analyser (scanner), parser, and code generator, and excluding compile-time constant expression evaluation and table management which get done by the rest of BASIC, it looks like adding a 64 bit assembler would be adding about 4,500 lines of code and would probably make it the single biggest module.

I also have to trust that the developers of nasm know a lot more about this than I do as I have not studied the X86 instruction set in any detail. I know 6502 assembler well, did Z80 BITD, and could probably pick it up again, but only ever did a tiny amount of 8086 assembler back in the 1980s on DOS. I have never written any assembler for Windows or Unix machines and never followed the evolution of these processors at the instruction set level.

You mentioned that people with an interest in BBC BASIC may be of a certain age but I also think it is comparatively rare to have kept up an interest in assembler programming on modern platforms.

Addressing scruss's point, I think BITD, including an assembler in BBC BASIC was a masterstroke. Assembler was the only language that had a significant improvement in performance over BASIC and the included assembler allowed just performance-critical parts to be written in it. It could also be implemented with not much extra code as the 6502 instruction set is simple and the table management and expression evaluation could be shared with BASIC. I don't think being easy to implement really applies any more.

Then, doing back the point about modern programmers writing assembler, I suspect few people would want to. If someone wanted to write a critical few subroutines in something other than BASIC for performance reasons wouldn't they want to have a choice of compiled languages? For that, surely the ability to call out to code in external libraries is what is needed? Doesn't that already exist with the SYS keyword?

So, maybe the only difficulty is that the IDE depends on assembler. Might the effort to provide the missing assemblers be better spend changing the mechanism by which the IDE does the things it currently depends on assembler for? I am thinking, for example, of the BCPL implementation where the CINTCODE interpreter has two copies of most of the variables that defined its state so it could implement a "run" state and a "trap" state. That allowed the debugger, written in BCPL too, to debug the user program without its own execution disturbing the program being debugged.

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 21, 2018 11:06 am

Soruk wrote:
Fri Sep 21, 2018 9:34 am
While I haven't tried to compile your BASIC on it (it's a 32-bit only machine)
It should compile now I've modified the makefile so that it automatically adapts to 32 or 64 bits.

User avatar
BigEd
Posts: 2488
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Request for help in organising/releasing source code

Post by BigEd » Fri Sep 21, 2018 11:16 am

I think having an assembler embedded in a high level language should still be a big win - not for very many people, perhaps, but for those who find it useful, or want to dabble in assembly, the practice of first writing a program and then porting critical sections to assembly should still be compelling.

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 21, 2018 11:34 am

Coeus wrote:
Fri Sep 21, 2018 11:01 am
it looks like adding a 64 bit assembler would be adding about 4,500 lines of code and would probably make it the single biggest module.
Needless to say I'm not looking to provide an assembler with comprehensive coverage of the instruction set: neither the existing 32-bit x86 nor ARM assemblers achieve that (although the x86 assembler isn't bad).
I also think it is comparatively rare to have kept up an interest in assembler programming on modern platforms.
As I explained, the main beneficiaries of the assembler are supplied libraries and system tools (such as the debugger and profiler) which are almost invariably written by me! Since 32-bit assembler code already exists for both x86 and ARM, translating it for 64-bits would be substantially trivial, especially for x86_64.
Might the effort to provide the missing assemblers be better spend changing the mechanism by which the IDE does the things it currently depends on assembler for?
The main issue is that my BBC BASIC interpreters are inherently single-threaded, whilst both the debugger (e.g. the List Variables feature) and the profiler rely on running code in a separate thread. As things stand it is simply impossible to run another thread in the context of the BBC BASIC interpreter without machine code. In principle it could be a position-independent binary blob (created by a compiler) rather than from an integral assembler, but it's not such an attractive (nor so easily debugged) solution.

I should probably also remind you that one of the main reasons for releasing the source code of BBCSDL now is that my deteriorating health, especially in respect of my mental faculties, means that I am unlikely to be in a position to do further development work myself before very long. Some kind of radical reworking of, or addition to, BBC BASIC to support the IDE is not an option that will be available to me. :(

User avatar
davidb
Posts: 2398
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Request for help in organising/releasing source code

Post by davidb » Fri Sep 21, 2018 12:07 pm

Richard Russell wrote:
Fri Sep 21, 2018 11:34 am
I should probably also remind you that one of the main reasons for releasing the source code of BBCSDL now is that my deteriorating health, especially in respect of my mental faculties, means that I am unlikely to be in a position to do further development work myself before very long. Some kind of radical reworking of, or addition to, BBC BASIC to support the IDE is not an option that will be available to me. :(
I'm sorry to hear that. :(

Do you have a roadmap, or even just a set of ideas, for how BBCSDL development should progress. What it needs in terms of maintenance or new features that would be desirable?

User avatar
BigEd
Posts: 2488
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Request for help in organising/releasing source code

Post by BigEd » Fri Sep 21, 2018 12:18 pm

(Just to say, Richard, while it's always pity to hear about deteriorating health, it's excellent that you are opening the software and handing over the reins to posterity, even if not to a specific person or team.)

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 21, 2018 1:20 pm

davidb wrote:
Fri Sep 21, 2018 12:07 pm
Do you have a roadmap, or even just a set of ideas, for how BBCSDL development should progress. What it needs in terms of maintenance or new features that would be desirable?
To the extent to which I have thought about it, my reference for comparison is 'BBC BASIC for Windows' (BB4W) which is a mature and stable product that has remained pretty much unchanged for nearly four years, and whose users are not clamouring for new features. The main respects in which BBCSDL falls short of the spec of BB4W (putting to one side the assembler issue) are support for any kind of hardcopy output (e.g. printer), support for playing sound files in various formats (MP3 etc), the ability to create standalone executables and some specific 2D graphics capabilities.

I've had a few thoughts on how progress could be made on all those fronts (for example one possible solution to the hardcopy output issue would be for BBC BASIC to create a PDF file; there is an Open Source library Haru which could in principle be used) but it may well be that other potential users don't see them as a high priority and have other ideas.

User avatar
davidb
Posts: 2398
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Request for help in organising/releasing source code

Post by davidb » Fri Sep 21, 2018 2:50 pm

Richard Russell wrote:
Fri Sep 21, 2018 1:20 pm
To the extent to which I have thought about it, my reference for comparison is 'BBC BASIC for Windows' (BB4W) which is a mature and stable product that has remained pretty much unchanged for nearly four years, and whose users are not clamouring for new features. The main respects in which BBCSDL falls short of the spec of BB4W (putting to one side the assembler issue) are support for any kind of hardcopy output (e.g. printer), support for playing sound files in various formats (MP3 etc), the ability to create standalone executables and some specific 2D graphics capabilities.
I suppose it should be possible to support sound playback with SDL without having to resort to integrating other libraries.
Richard Russell wrote:
Fri Sep 21, 2018 1:20 pm
I've had a few thoughts on how progress could be made on all those fronts (for example one possible solution to the hardcopy output issue would be for BBC BASIC to create a PDF file; there is an Open Source library Haru which could in principle be used) but it may well be that other potential users don't see them as a high priority and have other ideas.
Maybe printing is not as useful for people these days. The Haru website indicates that the project needs a new maintainer, but it is supplied in the current stable version of Debian so it may be a reasonable foundation for PDF support. This is where I wonder if someone has already written a PDF generator in BBC BASIC that could be used as a library. :)

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 21, 2018 3:32 pm

davidb wrote:
Fri Sep 21, 2018 2:50 pm
I suppose it should be possible to support sound playback with SDL without having to resort to integrating other libraries.
Playback of WAV files using SDL's audio functions works fine, and that is what is currently used in games for example, but there's no built-in support for compressed audio formats. The add-on SDL_mixer library provides that support, but it has many dependencies and I'm not confident it would be easy to deploy on the full set of platforms supported by BBCSDL. My current thinking is to use the third-party SDL_sound library which has recently been reworked as a header-only library (similar to the SDL_stbimage library I currently use to support compressed image formats like GIF/JPG/PNG).
I wonder if someone has already written a PDF generator in BBC BASIC that could be used as a library. :)
I think that's highly unlikely, but perhaps I'll be surprised!

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 21, 2018 3:55 pm

I should perhaps add that, as I see it, getting users to appreciate and use the existing capabilities is a tougher problem than adding new ones! BBCSDL is a highly capable and flexible implementation of BBC BASIC as it is, largely because of the power of the SYS statement, and some of this power has been encapsulated in libraries like those for 3D graphics and network access. But when it comes to leveraging direct SYS calls to SDL 2.0 (or the C library) from BBC BASIC programs I am pretty much the only person ever to have done so, as far as I'm aware.

One problem is the very scale of what is possible. The SDL 2 API is far simpler than the Windows API accessible from BB4W, of course, but it's still too large and complex to have any hope of writing a comprehensive tutorial describing how to use it effectively from BBC BASIC. So I resort to writing demo programs that illustrate a few specific capabilities, in the hope that potential users will be sufficiently interested to look at (and hopefully understand) the code. But there's precious little evidence of that happening.

I will plough on writing demonstration programs and adapting others (over time I have adapted four of David William's excellent graphics programs to use native SDL features rather than the assembly language code he typically relies on in BB4W). It's something I find I can still do, whereas I am increasingly struggling to cope with languages like C; that says something about BBC BASIC!

Coeus
Posts: 1230
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Sat Sep 22, 2018 12:06 pm

Richard Russell wrote:
Fri Sep 21, 2018 11:34 am
I should probably also remind you that one of the main reasons for releasing the source code of BBCSDL now is that my deteriorating health, especially in respect of my mental faculties, means that I am unlikely to be in a position to do further development work myself before very long.
That's a pity. I hope you remain capable for longer than you think but, as BigEd, said, it's great that you are at least making it possible for others to continue in your footsteps.
Last edited by Coeus on Sat Sep 22, 2018 1:13 pm, edited 1 time in total.

Soruk
Posts: 333
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Request for help in organising/releasing source code

Post by Soruk » Fri Sep 28, 2018 11:38 am

Richard Russell wrote:
Fri Sep 21, 2018 11:06 am
Soruk wrote:
Fri Sep 21, 2018 9:34 am
While I haven't tried to compile your BASIC on it (it's a 32-bit only machine)
It should compile now I've modified the makefile so that it automatically adapts to 32 or 64 bits.
I've got it compiled, it runs - but, the IDE chooser just shows the error "File or path not found" (and, since you've removed the ability to LIST a program, I can't see what it's complaining about). And, it really objects to a non-tokenised program (with a .bas suffix) - with "Bad program".

Are there any environment variables I need to set?

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 28, 2018 11:54 am

Soruk wrote:
Fri Sep 28, 2018 11:38 am
I've got it compiled, it runs - but, the IDE chooser just shows the error "File or path not found"
Just to be clear, you're running the executable in the same directory as 'bbcsdl.bbc' and the subdirectories 'lib' and 'examples' are also present there (and are populated)? You would probably get that symptom if, for example, you tried to run the executable from the build directory.
since you've removed the ability to LIST a program
Not entirely: *LIST works! :lol:
And, it really objects to a non-tokenised program (with a .bas suffix) - with "Bad program".
That's what you would expect, isn't it? To CHAIN (or INSTALL or CALL) a program it must be in tokenised format; the IDE will load a plain-text program of course, but not the interpreter.

User avatar
dhg2
Posts: 120
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

Re: Request for help in organising/releasing source code

Post by dhg2 » Fri Sep 28, 2018 11:59 am

Richard Russell wrote:
Fri Sep 28, 2018 11:54 am
And, it really objects to a non-tokenised program (with a .bas suffix) - with "Bad program".
That's what you would expect, isn't it?
Brandy and Matrix Brandy allow you to LOAD text files as programs, so maybe Soruk is used to doing that.
If I remember correctly, ARM BASIC doesn't allow you to load text file programs with LOAD, but it does let you save and load programs as text files with TEXTSAVE and TEXTLOAD.
Last edited by dhg2 on Fri Sep 28, 2018 12:00 pm, edited 2 times in total.
Regards,
- Patrick

Soruk
Posts: 333
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Request for help in organising/releasing source code

Post by Soruk » Fri Sep 28, 2018 12:31 pm

dhg2 wrote:
Fri Sep 28, 2018 11:59 am
Richard Russell wrote:
Fri Sep 28, 2018 11:54 am
And, it really objects to a non-tokenised program (with a .bas suffix) - with "Bad program".
That's what you would expect, isn't it?
Brandy and Matrix Brandy allow you to LOAD text files as programs, so maybe Soruk is used to doing that.
If I remember correctly, ARM BASIC doesn't allow you to load text file programs with LOAD, but it does let you save and load programs as text files with TEXTSAVE and TEXTLOAD.
I had tried LOAD, CHAIN and TEXTLOAD (TEXTLOAD also works in Brandy).

Soruk
Posts: 333
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Request for help in organising/releasing source code

Post by Soruk » Fri Sep 28, 2018 12:33 pm

Richard Russell wrote:
Fri Sep 28, 2018 11:54 am
Soruk wrote:
Fri Sep 28, 2018 11:38 am
I've got it compiled, it runs - but, the IDE chooser just shows the error "File or path not found"
Just to be clear, you're running the executable in the same directory as 'bbcsdl.bbc' and the subdirectories 'lib' and 'examples' are also present there (and are populated)? You would probably get that symptom if, for example, you tried to run the executable from the build directory.
since you've removed the ability to LIST a program
Not entirely: *LIST works! :lol:
I had a symlink in the top level pointing to the binary in bin/linux.

I've got it working by copying the bbcsdl binary and libstl.so to top-level. I guess it doesn't like being symlinked.

As for *LIST - didn't know that existed. Thanks for the tip!

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 28, 2018 1:30 pm

dhg2 wrote:
Fri Sep 28, 2018 11:59 am
it does let you save and load programs as text files with TEXTSAVE and TEXTLOAD.
Yes, but they are commands and all the commands have been stripped out of BB4W and BBCSDL because they have an IDE (in the case of BBCSDL two IDEs!) to do that kind of thing. There is still an 'immediate mode', which is useful for debugging and simple single-line calculations, but only statements (and *commands) are accepted. So CHAIN and RUN still work, because they are statements, but LOAD, SAVE, etc. do not (if you are desperate, and careful, you may be able to *LOAD and *SAVE a program but it's not recommended!).
Soruk wrote:
Fri Sep 28, 2018 12:33 pm
I've got it working by copying the bbcsdl binary and libstl.so to top-level.
Unless you've modified the makefile, its last two lines do that already.

Soruk
Posts: 333
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Request for help in organising/releasing source code

Post by Soruk » Fri Sep 28, 2018 2:54 pm

Richard Russell wrote:
Fri Sep 28, 2018 1:30 pm
Soruk wrote:
Fri Sep 28, 2018 12:33 pm
I've got it working by copying the bbcsdl binary and libstl.so to top-level.
Unless you've modified the makefile, its last two lines do that already.
That didn't happen for me. I'll have a look at the Makefile to see if it's being upset by something in Fedora.

Update: I see what happened. libSDL2main only exists in the static library - and previously on the linker error, I just attempted to complete the build without the -lSDL2main - and it linked correctly and gave me a binary. But, of course, the makefile didn't complete so the copy didn't happen. Is libSDL2main supposed to do anything? If I edit the makefile to remove that requirement, it builds and runs correctly.

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 28, 2018 3:44 pm

Soruk wrote:
Fri Sep 28, 2018 2:54 pm
Is libSDL2main supposed to do anything? If I edit the makefile to remove that requirement, it builds and runs correctly.
Google finds this so I guess not. :o

User avatar
Richard Russell
Posts: 763
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Request for help in organising/releasing source code

Post by Richard Russell » Fri Sep 28, 2018 5:08 pm

A private communication received today has reminded me that I've not provided any description of how the BBCSDL source modules are organised, which would be of value to anybody planning to make significant changes (such as to port it to something other than SDL 2.0). Here is a brief summary:
  1. bbmain.c, bbexec.c, bbeval.c and bbasmb.c (as whichever CPU variant) are the 'core BBC BASIC interpreter' and are, or at least are supposed to be, entirely machine and OS independent - although they do rely on things like unaligned memory accesses so can't run on all CPU types.
  2. bbcmos.c, bbccli.c, bbcvdu.c and bbcvtx.c are the OS- (in this case SDL-) specific interface modules which implement features like file access, VDU emulation (including MODE 7), keyboard input, sound output, star commands etc. They would have to be significantly reworked if the host 'OS' was not SDL 2.0.
  3. bbcsdl.c is the 'main program' (initialisation, rendering loop, event handling etc.) and is totally SDL 2.0-specific; it would need to be replaced in its entirety with whatever the host 'OS' requires.
  4. bbdata.nas (or bbdata.s depending on the CPU) declares shared variables using assembler directives because that way they can be placed at specific (relative) memory addresses. This is required because BBC BASIC programs often want to access interpreter internal variables using indirection operators.
Last edited by Richard Russell on Fri Sep 28, 2018 5:09 pm, edited 1 time in total.

Coeus
Posts: 1230
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Request for help in organising/releasing source code

Post by Coeus » Fri Sep 28, 2018 10:11 pm

Richard Russell wrote:
Fri Sep 28, 2018 5:08 pm
...This is required because BBC BASIC programs often want to access interpreter internal variables using indirection operators.
Richard, that reminds me; it looks like, on Linux, when running a user program from the IDE by clicking the > button the interpreter forks so there are now two interpreter processes, one running the IDE and one running the user program. Apart from the issue already noted in the need for an assembler, how would the IDE control the other process when debugging, i.e. cause it to single step etc. given that, by default, processors don't share any memory (unlike threads)?

Post Reply