As most of you probably know, Makefiles are the way to build projects on non-Windows systems. Well, to help me and any other Mac/Linux users, I'm making a program in C++ to make BBC Makefiles (this is the reason why I asked about compiling BASIC programs, by the way).


It will support the two major assemblers (ophis (aka P65) and beebasm). It will be able to generate INF files (I need help with this though - see below). You will need to obviously have the needed programs in your PATH (no problem for non-Windows users, maybe more of a problem for Windows but that's not my target system anyway (though I'm trying to make it compatible - I might end up hardcoding the default Windows paths as fallbacks)). It will use bbcim to generate disk images, and INF2UEF to generate tape images. Finally, typing make run will run it with beebem. All of these will need to be installed by the person who is making the project. All of these are multi-platform.

If there are any other programs that can work on the command line that you would like me to include support for, tell me. I don't care if they are Windows-only (Makefiles can still be used on Windows if you install the correct programs), I'd just like to have as much support as possible.


Windows users will need:
The common GNU coreutils in their PATH (cp, mv, rm)
GNU Make in their path (obviously)
The common BBC command-line development tools in their PATH (bbcim, ophis, beebasm)
Python in their path
INF2UEF.py (for tape image generation) in the current directory, or somewhere that the command "python INF2UEF.py" will find it (not sure if the Windows python has some kind of python path that it looks in first)


Linux users will need pretty much the same, but INF2UEF.py can be set to executable and put into the PATH (since they start with #! /usr/bin/python)


As for the INF files. I've made a few assumptions, can someone verify these?

* The CRCs aren't checked by the BBC, so they can be safely set to 0000 (if this isn't true, does anyone have the algorithm? They don't appear to use crc16 or crc8)
* For BASIC programs and !BOOT, the load and exec addresses can safely be set to 0
* For most assembly programs, the load and exec addresses are set to the hex number after .org (ophis) or ORG (beebasm)



Finally, if there are any feature requests, feel free to ask.

I'm obviously continuing with JSM as well (I tend to work on 2 or 3 projects at once otherwise I get bored), this is just a project to help me with future projects.

Unfortunately, I won't be able to implement merging (like Swift does) since there is no open-source or command-line program that does that (and I'm not really skilled enough yet to add the feature to either assembler).

The functionality for building assembled files into a disc image already exists in BeebAsm, so in this respect I'm not sure if it's worth supporting in your build system, as it expects you to do things in a rather different way, e.g. you cannot specify the target file on its command line.

I do use a Makefile to build my project in BeebAsm, but it just looks like this:

I don't bother with dependencies and all that kind of stuff, because BeebAsm expects that multiple files are INCLUDEd in a core file, this being the one which is passed as the input file on the command line, so everything is built every time anyway. It's such a quick process that it makes no odds.

For what it's worth, I do the same

It makes it easier to make a tape image, though.

And of course, it makes it a lot easier for ophis projects.

Is it possible at all to output a raw binary image from beebasm?

Yes, you can output a raw binary image, but the unusual thing is that its filename is specified by the SAVE command in the source, rather than on the command-line.

The reasons for this are that, if you want, you can create multiple object files from one source file, and can control very precisely the address range of each one, and optionally other file attributes too, such as the execution address. I didn't like the lack of control in regular assemblers, where (for example), if you change the ORG several times in a file, or declare space for tables, you can't be sure which range of addresses will finally get saved in the object file, whether they are padded with appropriate space, or concatenated together in a big lump, etc etc.

By putting SAVE directives into the source code itself, you can very precisely specify which blocks are to be saved, and which can be 'thrown away'. This is just like it used to be when assembling on a real Beeb, which was more or less the goal of BeebAsm.

I was thinking of adding a feature to BeebAsm to output just a regular binary file, but I felt unclear as to what it should actually save! I think that if you want these more regular assembler features, you're better off with P65 which offers a standard syntax, and more features such as macros. BeebAsm was designed from the outset to be a little different from normal!

Well, it should output the binary as if you had extracted it off the disk image.

Really the only problem I have with beebasm is that it's quite a bit harder to make tape images through something like a Makefile - you would need to compile the disk image, extract the disk image, figure out what order the files need to be in, rename the files, generate the index.txt and finally create the tape image. Whereas with ophis, you know everything else - the only thing you really need to do is copy the files into their own directory, generate the index.txt based on a known order and create the tape image.

I found a CRC algorithm in bbcim, so I am now using that to generate CRCs. I'm nearly done with the development already!

Completely finished the ophis side of things. The beebasm side is going to be slightly harder at present, but I'm always one for a challenge.

I think I've finished the beebasm code. I haven't tested it since I don't have any beebasm projects (and I'm not sure where to find them). Can someone with a beebasm project test it? The bit that's most likely to fail is tape image generation, but I think I did that right. I'm also not sure whether the actual compilation line is correct - the help page is pretty vague, and there is no manpage.

Attached C++ source file and i386 Linux build - I don't have access to a Windows box at the moment so I can't compile it for you.



EDIT: I've just realised that the whole big fuss about beebasm is that you can have multiple parts of the same source file saved as multiple files on one disk. I didn't actually realise that until now, so my program is only compatible with 1-file projects. I WILL rectify this soon. Count this version as 0.1


Also, I took some code from bbcim, which isn't quite GPL (it prohibits commercial use). I've clearly labeled it, posted a copy of the original license in that part, and gave detailed instructions on how to remove the dependancy of the non-GPL code, so hopefully I'm not doing anything illegal.

Fixed a few bugs, added multiple file support for beebasm (determined automatically from source file), added targets clean (removes binary files that can be remade), run (runs disk image in emulator), record (converts UEF to WAV and opens it in MPlayer).

I've tested it all quite a bit, but if you find any bugs or have any feature suggestions let me know.

Having been away for a week, I'm way behind on what's been going on but if you're saying what I think you're saying, then I think you are doing something illegal, technically.

I haven't looked at the license for bbcim yet, but it cannot add additional terms to the GPL (the GPL forbids it), such as "no commercial use", so it must be assumed that bbcim is not using a GPL-compatible license. In that case, you can't legally include code from it within your own GPL project, even if you explicitly mention it as being non-free. The reason Microsoft started all the FUD about the GPL being cancerous, is because the GPL requires all the code it touches to also be released as GPL.

You might find the easiest option is to contact the author of bbcim, Wouter Scholten, and ask if he would let you release those sections (I assume it's not a lot of code) under the GPL in your own project. Essentially, you'd be asking him to supply those bits of code to you under a new GPL license. As copyright holder, he's fully entitled to dual-license the code. Obviously, you'd then need to credit him in your project.

Of course, the likelyhood of anyone calling you on it, is slim - but it is bad form to advertise something as GPL when it isn't, as other projects may make use of your code and then discover way down the line that they are in violation, through no fault of their own.

Sam.

IANAL, but I've just had a look at the license for Wouter's latest bbcim, and I can't see anything about it being not for commercial use. In fact, the license explicitly allows selling of the software.

Which license are you reading?

Sam.

The one at the top of the main source file (I believe it's called bbcim.c or main.c or something)


I was using the CRC calculator from BBCim



I just found out that bbcim seems to ignore the CRC field and just calculate it itself - so maybe I can just remove it!

If I find out it is needed, there's a python version in e2tools. Probably won't be hard to port.




EDIT: I think I was using quite an old version - I didn't find that site!

If you need it, use the latest code and I don't think you've got a problem. You could always email Wouter to be absolutely sure.

Sam.

I've used makefiles on the BBC for almost 20 years now, such as http://mdfs.net/Apps/Text/SimpleEd/