I am currently using BeebAsm version 0.06 to write my Z-Machine interpreter.

After a few days of serious use, there are a few funnies I have found and some features which if added, would help me out with my current project.

I have just noticed that version 1.0 is now available so maybe some of the following may not be valid anymore.

First, using the -di and -do commands to add a file to a disc image. If the file already exists in the di image, it will be added again to the do image, rather than overwritten.

I am converting some existing BBC Basic code to 6502 and have some variable names like status and decode. I can't use these as variable/labels in BeebAsm as it thinks I am trying to STA tus or DEC ode. Can anything be done about this ?

I tend to write in lower case but the assembler doesn't appear to like ,y or ,x. For example sta &100,x complains about a syntax error at the ,x bit.

I also tried to use an expression with brackets in a statement but it didn't like this. For example STA (pc + 1) * 256,X (which I intended to be STA &1A00,X) wouldn't assemble.

As for extra features, I would dearly like to be able to declare local variables within a routine and pass parameters to routines. These variables would be stored in the normal page 1 stack and the assembler would automatically generate the necessary code when the variables or parameters were used. I am trying to convert numerous DEFPROC's and DEFFN's to 6502 and trying to handle the parameters and local variables is quite tricky.

Perhaps an option to report all assembler errors rather than stop at the first one.

Macros would also be useful.

Other than that, I am finding BeebAsm a very useful development tool and I hope some of the ideas above can be taken on board.

Jon.

Hi Jon,

Thanks for your comments! I guess I should've waited a little longer before upping the version number to 1.0; seems like there are still a few problems here and there...


Hmmm... this is curious, as it should generate an error if you do that. I didn't want to handle overwriting existing files, as I didn't want to effectively reimplement DFS! The idea was that the template disc image specified by -di should contain none of the files which are subsequently written by BeebAsm, and then the output image (-do) should have a different filename. Anyway, I'll look into this and see what's going on.


Dave Footitt mentioned this too. I know how I'm going to fix it; I'll try and get it out there as soon as poss.


OK, thanks. Sounds like an easy problem to fix.


Yes - this will look like a malformed STA (ind,X) or STA (ind),Y instruction, and it would be kinda involved to get the parser to recognise this as a valid non-indirect instruction. But there are two possibilities:


The square brackets are always available as expression parentheses, to avoid exactly this kind of parsing ambiguity.


Hmmm... do you mean creating a stack frame like modern compilers, and generating code like:The problem I see with this is that there are so many ways to code such a thing, and I just think it's too high-level for an assembler. e.g. every local variable access needs to corrupt X, so how do you generate code to preserve X? What if the stack runs out (wraps around)? The problem with hiding the implementation underneath high-level stuff like this is that it distances you from what is actually happening, which I think defeats the point in coding directly in 6502 in the first place.

That said, there are local symbols, so you could make this a little clearer with:


Then I guess a macro could come in useful (though see my comments below!).

Do you need these local variables because of recursion or re-entrancy? If not, I'd suggest just assigning different zp locations for every routine parameter, and the code will be much better. If you do need recursion, why not just push the affected variables to the stack before calling the rouine, and then pull them back and store them afterwards?


I can have a go!


Hmmm... I never wanted to implement macros for two reasons - firstly, because they just sounded like a pain to code (!), but also because I don't really like to hide the actual generated code behind high-level type constructs, as you can lose valuable optimisations, e.g. a macro like
You could use add16 a,b everywhere in the code without giving it any thought, and, yes, it looks tidier and easy-to-read, but every time there are valuable optimisations which are being forgotten... e.g.

* what if you know that carry flag is already clear at the start?
* what if a+1 or b+1 are known to be zero?

I understand that this is just my personal preference though (I personally would not use macros), so if I can find time to add them, I will do.


Thanks...hopefully I can get some of these fixes in quickly, and will release a new version as soon as possible.

Good to see planned progress on this. With regard to 'Swift' IDE, I'd much prefer to use BeebAsm (a 'native' style for Acornheads like me) rather than P65 (a somewhat alien style of markup).

Swift supports BeebASM (well roughly tested with version 0.6), are you using it with Swift ? That would be handy as it's lacked heavier testing.

Not in a serious way any time soon, but it would be an ideal setup for my amateur dabblings down the line.

Ok, hey presto, one idle lunchtime later and the bugs are gone, I think.

BeebAsm 1.01 for Windows is available here, and should fix these few bugs:

* Complains if the SAVE file already exists on the output disc image
* Now correctly allows a lower-case x or y in indexed addressing
* When assigning a variable, its name may now begin with a reserved word, so for example, 'player = 2' is allowed (begins with PLA).

I've been having a think about the macro thing. What would be your preferred syntax for declaring and invoking them?

Also, while I'm about it, would anyone like more 'standardised' directive names added (e.g. DB as an alias for EQUB, etc) and, if so, which?

I have just grabbed a copy of the new 1.01 (which compiled and ran with no problems on my Mac) and the changes are looking good !

Something I forgot in my first post is that I had two variables called HIGH_STRING and LOW_STRING. These get parsed as HI(GH_STRING) and LO(W_STRING) which is not what I intended. Perhaps a similar mod can be applied here as per the mnemonic mod which now works OK.

Replying to the query on my requirements for local variables ....

I have some DEFPROC's which are recursive and use local variables. These variables therefore need to put put on the stack as I can't used fixed memory locations for them. I have written some stack manipulation routines but it looks a bit messy and I just thought the use of local variables with hidden auto code generation would make the code a bit more readable. But I understand your concerns about making the assembler too 'high level' so I will stick with my current code.

As for macros, I don't have any particular construction in mind. Just something like :

MACRO VDU (A) with multiple parameters as well
LDA #A
JSR oswrch
ENDM

which can then be called with VDU 7, for example, in the code.

As for using standardised directive names, I am happy with EQUB etc. You could always add a #define directive so people could redefine any command to something else.

Jon.

Nice to hear it, Jon!


Hmmm... the problem here is this: in the case of the symbol/mnemonic clash, there's no ambiguity - if it's a symbol assignment, it has to be a valid symbol name, optionally followed by whitespace, followed by an '=' sign. If this is not the case, then we parse it to see if it's maybe an opcode or a command.

However, there are two possibilities with HIGH_STRING: either it's a symbol called 'HIGH_STRING', or equally validly, it's the expression HI(GH_STRING). Because BASIC allows you to write things like SINX*50, I wanted BeebAsm to interpret this in the same way, i.e. the sine of X, multiplied by 50, rather than a symbol called 'SINX'. Similarly, should SINRAD30 be interpreted as the name of a symbol, or as the constant 0.5 (sin(30º))? BASIC would say the latter, and I want BeebAsm to agree.

So, I don't really know what we can do about this! I noticed this issue a while ago, and the best I could do was to remove the case-insensitivity for functions/operators, so that you could write lower-case symbols without the fear of a clash, just like BASIC. If you can think of a better resolution, I'm really open to ideas!


I see. I've handled recursive functions with locals before by implementing my own stack in 6502. The main reason for this is simply that the 6502 stack is far too small for any degree of recursion (it fills up in no time). If you implement your own stack using a 16-bit stack pointer, you can fill a custom stack frame really easily using (ind),Y addressing and hopefully still have readable code.


OK, I'll have a play with the idea in days to come and see if anything sticks quickly.


Could be a plan!

Thanks for all your comments!

Really? Doh, I was waiting for RichTW to announce the '1.0' release before I uploaded my RISC OS port. I didn't realise he'd released it as soon as he'd said he'd be changing the version number

Obviously this isn't quite the correct thread to mention it, but I'll try and get the v1.01 RISC OS port up tonight (unless RichTW beats me to it and releases a 1.02!)

Now done.

RichTW - the Windows zipfile doesn't contain any mention of what license BeebAsm is under! So for the RISC OS zipfile I've included a copy of the GPL v3 'COPYING' file and a note in the readme to say that it's under the GPL.

Yes, good point Jeffrey, I'll add the appropriate notices in the help file and the source code, ready for the next release.

Thanks for adding your RISC OS port to the wiki!