BeebAsm

[SteveF]

I've merged those changes to get rid of the link-time warnings into proposed-updates.

[Prime]

Something I'd currently find useful, would be the ability to specify an output folder for the SAVE command on the command line.

So you could do something like

Code: Select all

mkdir beeb
mkdir elk
mkdir master

beebasm somecode.asm -DMACHINE=0 -OD=beeb
beebasm somecode.asm -DMACHINE=1 -OD=elk
beebasm somecode.asm -DMACHINE=2 -OD=master

For example, I know this can be done with an if inside the asm file, but this gets tedious for more than a couple of output dirs, and more than a couple of asm files. Also it allows you to move things around in the filesystem without having to manually edit each and every asm file to point at the new folder.

If it can currently do this, I don't know the correct syntax for it.......

Also what is the currently worked upon branch of the source as I'd like to test the updates.....

Cheers.

Phill.

[Rich Talbot-Watkins]

That needn't be a BeebAsm feature - you could just do something like:

Code: Select all

mkdir beeb
mkdir elk
mkdir master

beebasm somecode.asm -DMACHINE=0 && move output.ssd beeb
beebasm somecode.asm -DMACHINE=1 && move output.ssd elk
beebasm somecode.asm -DMACHINE=2 && move output.ssd master

...I think?

(or substitute mv for move in Unix-type environments)

[ctr]

Also what is the currently worked upon branch of the source as I'd like to test the updates.....

https://github.com/stardot/beebasm/tree ... ed-updates

Note that the EXE isn't quite up-to-date. It does include all the new features.

[SteveF]

That needn't be a BeebAsm feature - you could just do something like:

Code: Select all

mkdir beeb
mkdir elk
mkdir master

beebasm somecode.asm -DMACHINE=0 && move output.ssd beeb
beebasm somecode.asm -DMACHINE=1 && move output.ssd elk
beebasm somecode.asm -DMACHINE=2 && move output.ssd master

...I think?

(or substitute mv for move in Unix-type environments)

You could also probably do something like:

Code: Select all

mkdir beeb
mkdir elk
mkdir master
(cd beeb; beebasm -i ../somecode.asm -D MACHINE=0)
(cd elk; beebasm -i ../somecode.asm -D MACHINE=1)
(cd master; beebasm -i ../somecode.asm -D MACHINE=2)

Incidentally, note that you must have a space between -D and the variable to define.

I guess it would also be possible to handle this by adding support for string variables. You could then do:

Code: Select all

beebasm -i somecode.asm -D MACHINE=0 -D 'OUTPUTDIR$=beeb/'

and have the souce code contain:

Code: Select all

SAVE OUTPUTDIR$+"foo", start,end

That is probably quite a bit of implementation effort though, and may not fit will with the existing internals.

[tricky]

Can't you just run in the directory you want to output to?
You might need to add ../ to the paths used for includes.

[Rich Talbot-Watkins]

It would probably INCLUDE/INCBIN from the wrong place though. I originally planned on making them relative to the file being assembled, but it was a bit of a pain to do and I never got round to it. It'd need to maintain the base directory (everything up to the final slash) and pass that to subsequent INCLUDEs.

Edit: as tricky already said.

[Prime]

It would probably INCLUDE/INCBIN from the wrong place though. I originally planned on making them relative to the file being assembled, but it was a bit of a pain to do and I never got round to it. It'd need to maintain the base directory (everything up to the final slash) and pass that to subsequent INCLUDEs.

I guess one thing that would be useful, would be being able to specify an include directory on the command line like gcc's -I and have the assembler search the current source file's directory followed by any -I directories

Cheers.

Phill.

[SteveF]

It's been fairly quiet here lately - I guess everyone's busily coding away with the new proposed-updates version of BeebAsm, right?

I'm thinking it's probably time to call proposed-updates v1.09 and merge it to master. Any objections? I think all we need to do is add the release date into README.md and then merge. If someone else wants to do this then go ahead, otherwise I'll do it this coming weekend if no one objects first.

Cheers.

Steve

ETA: Is the Windows executable slightly out of date? I don't think it matters that much - as ctr says above, it has all the features - but if someone could rebuild it that would be nice.

[tricky]

Consider this an early suggestion for the next release
I sometimes find myself with code like:

Code: Select all

.function
{
	;; ...
.label
	;; ...
}

where I would like to jump to label from outside function.
What do people think about jsr function.label?
I would also like to export function.label when exporting symbols to use in beebem (as I described before).
I know .function isn't related to {}, but it could be considered if it is the address of the start of {}.
I would also find it useful to export some constants, although these are often of the form:

Code: Select all

.func : func_sub = func + 100
{
	;; ...
.sub
	;; ...
IF func_sub <> sub
	ERROR
ENDIF
}

[SteveF]

I sometimes find myself with code like:

Code: Select all

.function
{
	;; ...
.label
	;; ...
}

where I would like to jump to label from outside function.
What do people think about jsr function.label?

I'm not saying this is a bad idea - I quite like it - but at the risk of stating the obvious, I think you can already achieve something similar (if not quite as good) by writing:

Code: Select all

.function
{
	;; ...
.^function.label
.label ;; this line is optional unless you want to able to just use '.label within this scope as shorthand
	;; ...
}

Though I haven't tested this, and maybe you can't use "." in a label, in which case you'd have to use "_" or similar.

I would also find it useful to export some constants

I have wanted this on occasion myself, and I don't think there is any straightforward way to do it at the moment. A symbol defined with = is always restricted to the current scope and I don't think there's any way around that. Apart from not needing it *that* badly , what put me off trying to implement it was the question of syntax - 'export symbol'? 'symbol *= 42'? '*symbol = 42'? Something else?

[tricky]

Sorry, I had forgotten that was added.
I will add the export symbols with dots to there enclosing scope locally and see how it feels. I like having beebem showing the labels as I step and adjusting breakpoint and watch addresses automatically from one run to the next.

[SteveF]

Only a week later than promised: proposed-updates has been merged to master and tagged as v1.09: https://github.com/stardot/beebasm/releases/tag/v1.09 Thanks to everyone who helped out with this!

What's the next step? Should we do new development on the existing proposed-updates branch or create a new branch (called v1.10-proposed-updates?)? I don't personally have any immediate development planned, though there are plenty of good suggestions already, and I have some half-baked features knocking around in various threads which could in principle be tidied up and pulled into a release eventually, so I'd like to get this right.

[ctr]

No, thank you! That's brilliant.

I've committed a new Windows exe. We might as well carry on in proposed-updates, it's easier to type and you've tagged the release if anyone wants to go back to that particular version. Though I committed the exe to master so that would have to be merged back in to proposed-updates.

[SteveF]

I was browsing idly and noticed BeebAsm was listed on 6502.org's tools page, but pointing to RetroSoftware and Tom Seddon's repo: http://6502.org/tools/asm/

Shall I drop them a mail asking them to update the link to the stardot github page (https://github.com/stardot/beebasm)? That in turns has a link to this forum so I don't think we need 6502.org to point directly here, but if anyone feels differently let me know.

[BigEd]

I've just updated it... I think I notice that the wiki, linked to from the repo, doesn't link back to the repo, or the github issues, or have any recent changes listed. Perhaps a good time for a wiki update?

[SteveF]

Great, thanks for doing that!

My inclination is to delete everything on the wiki page from "Command line options" (inclusive) down to the end, though retaining the "Demo" section as it has a nice screenshot. This would avoid duplicating too much of the information from the README.md on github and creating maintenance burden while leaving the wiki page with some information. I could then look at updating the rest of the page with the newer version.

How does this sound to everyone?