BeebAsm
Re: BeebAsm
I've merged those changes to get rid of the link-time warnings into proposed-updates.
Re: BeebAsm
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
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.
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
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
- Posts: 1412
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: BeebAsm
That needn't be a BeebAsm feature - you could just do something like:
...I think?
(or substitute mv for move in Unix-type environments)
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
(or substitute mv for move in Unix-type environments)
Re: BeebAsm
https://github.com/stardot/beebasm/tree ... ed-updatesPrime wrote:Also what is the currently worked upon branch of the source as I'd like to test the updates.....
Note that the EXE isn't quite up-to-date. It does include all the new features.
Re: BeebAsm
You could also probably do something like:Rich Talbot-Watkins wrote:That needn't be a BeebAsm feature - you could just do something like:...I think?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
(or substitute mv for move in Unix-type environments)
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)
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/'
Code: Select all
SAVE OUTPUTDIR$+"foo", start,end
Re: BeebAsm
Can't you just run in the directory you want to output to?
You might need to add ../ to the paths used for includes.
You might need to add ../ to the paths used for includes.
- Rich Talbot-Watkins
- Posts: 1412
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: BeebAsm
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.
Edit: as tricky already said.
Re: BeebAsm
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 directoriesRich Talbot-Watkins wrote: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.
Cheers.
Phill.
Re: BeebAsm
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.

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.
Re: BeebAsm
Consider this an early suggestion for the next release 
I sometimes find myself with code like:
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:

I sometimes find myself with code like:
Code: Select all
.function
{
;; ...
.label
;; ...
}
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
}
Re: BeebAsm
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:tricky wrote:I sometimes find myself with code like:where I would like to jump to label from outside function.Code: Select all
.function { ;; ... .label ;; ... }
What do people think about jsr function.label?
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
;; ...
}
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* badlytricky wrote:I would also find it useful to export some constants

Re: BeebAsm
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.
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.
Re: BeebAsm
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.
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.
Re: BeebAsm
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.
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.