Which would be the best to use? Both work fine on Linux so compatibility isn't an issue for me. I'm just wondering which is the more useful program, since they both have different formats, and I wouldn't like to learn one to find out that the other is better. I see that beebasm can output directly to disks which seems quite useful.

One thing is that P65 seems to be largely unsupported these days whereas BeebASM is written by one of our Members and updates for new features are a possibility.

I think they are both good in different ways. I use P65 but that's because it supports merging with Swift and I like to keep my files logically seperate as much as possible. I know others use BeebASM, so have a go with both for a while and see which seems to fit best for you.

Our Member DaveF (who you met) uses BeebASM so he may be able to help with the procedure he uses.

I'm using P65 for the time being (albeit a much newer one than is linked to on this site - is there any reason why this ancient version is linked to?) since the game that DaveM said I should look at and try to improve (Jet Set Miner) is written for that, though I might try to port it to beebasm at some point, just for practice (shouldn't be too hard, just replace $ with & and re-write the assembler directives).

How would I package a P65 output file into a disk/tape image that I can load into BeebEm? (The Linux version of BeebEm is quite a bit worse than the Windows version; I'm not sure if the Windows one would be able to load the binary directly or not, but the Linux one sure can't).

That reminds me... is there anyone i could beg for an option to use $ for hex numbers in BeebAsm, 'cos i'm quite used to it after twenty something years...? =-)

Ha ha, it's on old version cos I've never updated the link. What release date is your version ? Also give us a link to the later version and I'll test it first before updating the link on the Wiki page.

P65 just outputs the raw binary data, all you need to do is use some sort of disk manager software, there are several listed here.

http://www.stairwaytohell.com/essentials/index.html?page=homepage

and drag your P65 outputed file into one of it's disk windows. Then load this disk into BeebEm.

This is essentially what Swift does for you unseen. It puts all the output fromP65 (or other files) onto a DFS disk that it creates on the fly and then auto launches BeebEm and makes it run (or load) this disk.

Rich Talbot-Watkins is the talented guy that writes that software, he reads here regulary and might help , although not sure if $ isn't used to store strings ? Can someone clarify as I don't use BeebASM.

Well, it's actually changed its name since then to Ophis.

The new URL is http://hkn.eecs.berkeley.edu/~mcmartin/ophis/

The download URL is http://hkn.eecs.berkeley.edu/~mcmartin/ ... 1.0.tar.gz (non-Windows) or http://hkn.eecs.berkeley.edu/~mcmartin/ ... taller.exe (Windows)

The Windows version now uses a compiled python EXE rather than .py files, so it should remove the python requirement.

However, it is still command-line compatible AFAICT

If you need proof it's the same thing, see the top of http://hkn.eecs.berkeley.edu/~mcmartin/P65/

Thanks for that, I'll look at that shortly.

I've installed it, created a new assembler entry, used the P65 profile and it all worked first time in my relatively complex project.

I'll update the Wiki, thanks for the info.

[Edit] Wiki Updated.

I've had lots of success!

At first, I couldn't get it working - I tried running quite a few GUI programs under wine, and couldn't figure out how to add files in any of them. I suspect they all use drag+drop, something that wine doesn't support (I assume because it would be ludicrously difficult because of the massive differences between the X and Windows drag and drop protocols). In the end, I found bbcim, which is natively compatible with Linux (something stairwaytohell needs to know about!) and it worked flawlessly. I extracted the INF files, as well as !BOOT and LOADER, from the old JSM disk using bbcim -e Jet\ Set\ Miner.ssd, renamed the INF file for PLAT (the actual binary) to suit my output file, and added my output file along with the !BOOT and LOADER to a new disk image using bbcim -a JSM.SSD !BOOT LOADER JSM.out

And that worked! I have now sucessfully fixed returning to the title screen on game over (previously it would crash, since the initial setup routines were being repeated without interrupts being disabled. I just added a new label after the initialisation of things like the replacement event routine, etc and modified the jump). I'm starting with small changes and hopefully I'll work my way up to big ones.

The next thing I'm after is the retro software splash screen. Is the source code for that hanging about anywhere? I'm assuming this will be pretty easy if I have the source code, just a copy and paste job (and maybe a few changing screen modes, etc). As I said, I'm starting with small and easy changes so I can get myself really familiar with the language, then I'll move onto the bigger changes.

Never one to hang around, I've put a new version of BeebAsm on the website which allows '$' as a prefix for hex numbers!

As for which to use, well, it's just a personal preference. P65 is a more traditional assembler in terms of its syntax, whilst the idea with BeebAsm was to recreate a more BBC BASIC-like environment, as this is what I was most used to. If you've never written 6502 assembler on a real Beeb using the built-in assembler, it might seem a little strange to you

One of the main reasons I decided to write BeebAsm was that I couldn't find a 6502 assembler that would let me write multiple instructions on a single line. I used to do this all the time on the Beeb, in order to naturally group instructions which belonged together to perform one operation, e.g. I found that it really aided the clarity of the code.

Then it just kinda grew from there. I always used to build lookup tables in BBC BASIC within the assembler code, so I decided I'd implement all the floating point functions available in BASIC too, so I could trivially generate a sine table or whatever inside the assembler source code itself.

But, SWIFT provides a lot of this wrapping too, so as Steve says, just try them and see which comes more naturally.

Just to add that this is possible with BeebAsm too - you can write source code in separate files, and then just create a 'core' source file which INCLUDEs all the other files in the appropriate order.

Well, I can't use swift; I don't have Windows installed, and I get an access violation every time I click a button under wine.

Merging is a term Swift uses to differentiate with 'including'. With Including files the scope of the two linking files is the same with P65 and I thought it was with BeebASM (apologies if I've got that wrong).

Including usually (in P65 anyway) brings all the files together prior to assembly and assembles them, so global variables (aliases, call them what you will) cannot have the same name in both files or they will clash (clashes in P65 anyway).

With Merging Swift actually assembles the merged files separately and then builds the final binary together from these parts. In this way you can have same variable names in different files and they don't clash. It uses an extended syntax within your source to access routines.

But when I was working on the BeebASM support I don't think I could implement merging with BeebASM, but I can't remember exactly why, might have been because I couldn't assemble a file to a discreet file (that I could build into a single binary) rather than a DFS disk.

Oh no! Well, without the warm cosy layer of Swift hiding all the disc image manipulation, if you were to use P65, you'd need to figure out some kind of build process to remove all the hard work. I guess you could use a makefile to assemble the code and then call bbcim to generate a disc image from it - it's not really so hard.

But have a look at BeebAsm too. There's an example source file included in the package, and some resaonably thorough documentation on the wiki with a few other examples. If you have any feature requests or cries for help, give me a shout, and I may be able to add it.

Ahh yes, I see the distinction now... actually now I think we already had this conversation about a year and a half ago

Out of interest, what is that? How do you access the symbol from one file inside another? Is this a P65 feature or a Swift feature?

In theory in BeebAsm, it would be possible to make all symbols in an include file local to it by enclosing its entire contents in braces {}. But the problem with this is that you wouldn't be able to access these symbols from outside of the braces, so then it'd need a new directive, GLOBAL or EXPORT or somesuch - and then it's all starting to get a little bit complicated...

BeebAsm can output a straight binary, but I've just realised that the problem is probably that you can't specify its filename on the command line (because it comes from the SAVE directive in the source code). However, I could trivially add this if it'd make it easy for you to write a BeebAsm profile for Swift. (I already added a command line switch yonks ago which dumps out all the symbols, which was intended for use with Swift).

It's a Swift feature. Say your project item source to merge is called "Sprites" and you've a routine within it called "PlotSprites". You are merging Sprites with your project "Main" file. To call the PlotSprites routine you'd have in your "Main" source code;

JSR Sprites.PlotSprites

So Swift knows you are referring to the PlotSprites routine within the Sprites source file. When it comes to building your project it can work out what the address of PlotSprites would be in your complete built code if the Sprites file was merged with your Main file. And replaces this line with a JSR XXXX. Where XXXX is the address that Swift has worked out for your PlotSprites routine when merged with your Main code. Obviously there's a bit more detail in how it works out the actual address

That sounds like that might have been the reason, I probably didn't ask you as I think you'd done loads for me at the time So if you can specify a binary out file to disk that'd probably give BeebASM the same functionality as P65 has within Swift. Yes I used the symbol dump out you did, this allows me to show the value of all call address labels which can make debugging in BeebEm a lot easier

Clever! Well, I'd like to add saving out a straight binary in BeebAsm, but I have a question - what is the behaviour of P65 (or indeed most assemblers) if you change the ORG address several times inside one file? Do they just save out the biggest, most inclusive block, or is it more clever? I ask because often I write things like:

but I wouldn't want it to save the entire block from address 0... Do you pass any special parameters to P65 to tell it what to save, or are there some kind of directives in the assembler source itself, specifying what is to be saved?

I'd never thought of it and only ever used one .org. An experiment with this code


created a file of 31 bytes but of course it failed to run properly as it put the Hello straight after the RTS and the code actually tries to access it at $3000.

In P65 you can force it to pad out to a particular address (although I've never used it).

As far as I'm aware it won't save particular parts of a file out. For this I'd just use a separate file that is assembled and saved and that would do the same thing. So your separate file would be



and you can get it to assemble and save it as part of your overall project with a simple makefile (or Swift of course !)

Yay! Ta very much. (Please don't expect anything from me in quite the same time scale, anyone! =-)

Excellent, I love BeebASM myself, it's very easy to use, 'we' have the source, and it's easy to integrate with an Emacs/Makefile system I use to write the code on Mountain Panic.

Great with the new % for binary, been keen to see that one myself