BeebAsm

[lovebug]

I tend to handle zp allocation something like this:

Code: Select all

ORG 0
.scrnptr  SKIP 2
.readptr  SKIP 2
.colour   SKIP 1
.posx     SKIP 1
.posy     SKIP 1

ORG &1100
.start
    ; your code here
.end

SAVE "CODE", start, end

yeah im currently doing this with ladybug

with other assemblers I also do this at the start but only for global variables, any temporary zero page variables like preserving registers in a function I like to define on the fly just before the function

its all cool though, and im happy with just putting them all at the start. thanks

I have a 90% complete BeebAsm 2.0 nearly ready for release

Well, that is the best thing I read all day!

hear hear

[Rich Talbot-Watkins]

The absolute dream would be for zp allocation to be totally automatic, according to what each subroutine needs as inputs, outputs and scratch space, and how the call graph overlaps and interacts with other subroutines.

The CRTC demo group created an assembler called Pasta which attempts to do this, and I'd love to try and get something similar into BeebAsm in the future.

[garfield]

I have a 90% complete BeebAsm 2.0 nearly ready for release

Oh nice!

I'll pitch again for the inclusion of multi-line comments feature, if possible i.e. the equivalent to /* */ in C and C++

Looking forward to the next release Rich.

[TobyLobster]

My pitch would be adding support for the equivalent of O% in the BASIC assembler (the assembly is still output at the current P%/ORG, but such that it will run at O%). I know this kind of thing is possible using the COPYBLOCK hammer, but the O% style option is a smart way too. It can preserve the order of the code in the source wrt the binary which can be elegant, it can make it easier to convert from other assemblers as they tend to have similar solutions to this, and also easier when writing cross-assembler tools like py8dis (which is where my experience is coming from).

[SteveF]

My pitch would be adding support for the equivalent of O% in the BASIC assembler

FWIW (you may have already seen it) I did have a go at implementing this: viewtopic.php?p=322539#p322539 I switched to using COPYBLOCK after someone made the suggestion and with the aid of a couple of wrapper macros it seemed to work well, so I didn't push for inclusion of my not-thoroughly-tested change, but it might be of interest and I'm not actually aware of any bugs in it...

[TobyLobster]

Interesting, I didn't see that. I see no reason why the two methods can't co-exist, giving people a choice of preferred style.

[JudgeBeeb]

Just a brief heads up to say that the current version available on the StarDot GitHub repo (v1.09) appears to compile flawlessly (and build demo.6502) on my M1 MacBook Pro running and macOS Monterey 12.5.1 and clang and produces a native arm64 command line executable. (v1.10-pre also appears to compile just fine.)

Code: Select all

file beebasm 
beebasm: Mach-O 64-bit executable arm64

[lovebug]

if a command was added (lets call it set for now) to allow changing of a value assigned to a constant you could easily make a macro to automatically assign zp variables

at start of program

Code: Select all

zpVarPtr = 0

in the macro

Code: Select all

MACRO zpVar varName, varBytes
varName = zpVarPtr
set zpVarPtr = zpVarPtr + varBytes
ENDMACRO

or something long those lines

[derek]

Hi,

I downloaded BeebASM v1.09 from Github and tried to compile it on Linux Mint 20, using the make all command, which gave some errors:

Code: Select all

commands.cpp: In member function ‘void LineParser::HandlePutFileCommon(bool)’:
commands.cpp:1757:26: error: ‘std::ios_base::streampos’ is deprecated: use 'std::streampos' instead [-Werror=deprecated-declarations]
 1757 |      ifstream::streampos p = inputFile.tellg();
      |                          ^
In file included from /usr/include/c++/9/ios:42,
                 from /usr/include/c++/9/ostream:38,
                 from /usr/include/c++/9/iostream:39,
                 from commands.cpp:25:
/usr/include/c++/9/bits/ios_base.h:481:28: note: declared here
  481 |     typedef std::streampos streampos
      |                            ^~~~~~~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile.inc:227: objects/commands.o] Error 1
make: *** [Makefile.inc:183: objs] Error 2

Can anyone help with this error?

[sweh]

See https://www.stardot.org.uk/forums/viewt ... 75#p361875

[derek]

Hi,

See https://www.stardot.org.uk/forums/viewt ... 75#p361875

Thank you for the link to the correction to beeasm, I tried the change and beebasm compiled without error.

I do know about C++, so I do not know what has changed, bu it seemed to work and has compiled the examples.

[derek]

Hi

I have sorted out the vompile problems with Linux and Beebasm, using the messgae thread that sweth recommended.

I have compiled the Hello World program and all the demo programs and ran SSD file with b-em.

I have written 2 scripts to compile the 6502 assembler file and the other to run in b-em.

I thought this is great, I can start to learn 6502 assembler in a modern environment.

I also looked at VS CODE, which is proving more of a challenge to configure the BEEBASM Plugin.

[dominicbeesley]

I don't know if this is the right place for posting issues with beebasm?

I've a project from a few years ago (https://github.com/dominicbeesley/ADFS-multi-target) that uses beebasm with makefiles to compile a number of different targets it invokes beebasm from the Makefile like:

Code: Select all

	beebasm -i xxxx -o yyyy

and invokes the SAVE command in the assembler like

Code: Select all

	SAVE "", &8000, &C000

This used to work when I made this project approximately 3 years ago but no longer works.

The readme.md file and source (commands.cpp:1150)

Code: Select all

void LineParser::HandleSave()
{
	// syntax is SAVE ["filename"], start, end [, exec [, reload] ]

	ArgListParser args(*this);

	StringArg saveParam = args.ParseString();
	int start = args.ParseInt().Range(0, 0xFFFF);
	int end = args.ParseInt().Range(0, 0x10000);
	int exec = args.ParseInt().AcceptUndef().Default(start).Range(0, 0xFFFFFF);
	int reload = args.ParseInt().Default(start).Range(0, 0xFFFFFF);
	args.CheckComplete();

	string saveFile = saveParam;

would seem to imply that

Code: Select all

	SAVE ,&8000,&C000

should work but that fails too (with an expression error).

I've made a quick bodge to get by at https://github.com/dominicbeesley/beeba ... 4840176dff but I suspect that the proper fix would be to fix the ParseString() method?

D

[dominicbeesley]

Ah, I see now the problem is that the readme and code are misleading the syntax hint should be, I think:

Code: Select all

	// syntax is SAVE ["filename", ]start, end [, exec [, reload] ]

The automated build threw a whole raft of errors with my branch which but the test-cases gave the game away!

D

[ctr]

Ah, I see now the problem is that the readme and code are misleading the syntax hint should be, I think:

Code: Select all

	// syntax is SAVE ["filename", ]start, end [, exec [, reload] ]

The automated build threw a whole raft of errors with my branch which but the test-cases gave the game away!

D

This is all my fault! Previously, the documentation for the SAVE command didn't mention that the file name was optional. When I updated this I put the comma on the wrong side of the brackets, as you've seen.

Additionally, every command used to have its own parser for its parameters. They were complicated and buggy so I replaced them all with the ArgListParser stuff, which made the code for each command much more readable. Unfortunately, I didn't notice that an empty string also worked as an omitted file name in v1.09.

I've updated the docs and the comment to put the comma in the right place and I've opened an issue for the empty string file name thing. Issues raised on github are less likely to be forgotten about.

[ctr]

The automated build threw a whole raft of errors with my branch which but the test-cases gave the game away!

I forgot to ask... do you want to work your patch up into a pull request or shall I just go ahead and do the fix?

[dominicbeesley]

Thanks for the prompt look into this.

My patch was a complete bodge based on a misunderstanding - you could probably do much better as I didn't really understand what was going on!

I'm happy if you want to disallow SAVE "",... - that's a rather confusing syntax and an easy fix for me in my repos.

D

[sweh]

I'm happy if you want to disallow SAVE "",... - that's a rather confusing syntax and an easy fix for me in my repos.

That would be a "breaking change".

I've been using this format

Code: Select all

SAVE "",start_code,end_code

in my code for years.

[ctr]

Thanks for the prompt look into this.

My patch was a complete bodge based on a misunderstanding - you could probably do much better as I didn't really understand what was going on!

I'm happy if you want to disallow SAVE "",... - that's a rather confusing syntax and an easy fix for me in my repos.

D

I suspect that SAVE "" only ever worked by mistake but there may be other people who used the same syntax and haven't upgraded yet so I'd prefer to spare them the nuisance. And Stephen's post confirms it.

So I will do a fix. It won't look much different to your bodge!

[ctr]

That's fixed and there's a test case now for SAVE "". As ever, the source code is here: https://github.com/stardot/beebasm

[dp11]

A little help please.

I'm trying to create a multi bank rom

Code: Select all

ORG &8000
.start 
	; code bank 1
	; bank swap code
ORG &8000
	; code bank 2
	; bank swap code
.end

SAVE "32Krom" start,end

I get the following error "Trying to assemble over existing code."

How should I set this up to create a single rom file?

[VectorEyes]

A little help please.

I'm trying to create a multi bank rom

Code: Select all

ORG &8000
.start 
	; code bank 1
	; bank swap code
ORG &8000
	; code bank 2
	; bank swap code
.end

SAVE "32Krom" start,end

I get the following error "Trying to assemble over existing code."

How should I set this up to create a single rom file?

You’ll have to save the two files out separately. BeebAsm doesn’t really support the concept of assembling to different “overlays” of the same memory region, so when you say “ORG &8000” you’re literally just telling beebAsm to start assembling code at memory address &8000 again. That’s why you get the error, because it knows you’ve already assembled code to that address before.

You can use the CLEAR command to “reset” regions of memory to a blank slate.

[ctr]

Additionally, you could use COPYBLOCK to copy the first bank from &8000 to &4000. Then use CLEAR and assemble the second bank. Then you can save everything from &4000-&C000 as a single 32K file. But as VectorEyes says, the support for this kind of thing isn't brilliant.

[dp11]

That's a neat trick.

[SteveF]

Is there any clever trick for assembly code to maintain some kind of mutable state while beebasm is assembling it?

A good while back (I think I posted about it on the Retro Software forum but I can't find the post anywhere now) I created a patch to add a crude stack datatype to beebasm and used it to build some structured assembly macros, so you could write things like:

Code: Select all

lda &70
xifeq
	lda #1
xendif

and that would turn into:

Code: Select all

lda &70
bne .hiddenlabel
lda #1
.hiddenlabel

Watching some of David Given's videos on Youtube has reminded me of this and while (to be scrupulously honest) I don't actually have any pet projects lined up to use this on, I still think it would be nice if I could write code like this in beebasm.

I am wondering if there's any way to abuse some other beebasm feature to allow these macros to track state, without needing a change to the beebasm code. I have a feeling there isn't anything. Strings are not mutable. Although you can write arbitrary data to a spare part of the 64K address space, I don't think you can read it back, so you can't do something like:

Code: Select all

macro inithackystack ; this works
    ; we use &F000 as the assembly time stack pointer and initialise it to itself for an empty stack
    old_P% = P%
    P%=&F000
    equw &F000
    P%=old_P%
endmacro

macro hackystackpush v ; this doesn't work - we can't read the contents of the address space from assembler code
    memory[&f000] += 2
    memory[memory[&f000]] = v
endmacro

Does anyone have any diabolically twisted ideas?

(The fact macros have to be "syntactically complete" means you can't open and close scopes inside the structured assembly macros to reflect the implicit code structure, for better or worse.)

[tricky]

I thought I had done something with for loops as they create a new scope, but may have used included instead.
Other than that, for your first example, you could have a macro jump p% + 2 .

[SteveF]

Thanks tricky, the idea of a for loop is kind of tantalising as it is one of the few places in beebasm where a variable can change its value during assembly. (Though IIRC it's a bit like just invoking the body as if it were a macro with all the different values, so internally it's not that much different than a macro parameter having different values for different invocations, I suppose.) I don't think it will go as far as I need to implement this though.

I wonder if the simplest and most generally useful way to allow structured assembly would be to add a beebasm equivalent of the C #line directive (which would require a code change to beebasm) and then I could write a simple preprocessor to do the structured assembly stuff without making it impossible painful to debug assembly failures because the line numbers would be all wrong.

I'm sure a beebasm #line-equivalent has been discussed before, I wonder if it's harder than it seems for some reason or it's just that no one has got round to it. I suspect there would be less opposition to adding this to beebasm than a stack datatype or (not that I really have much intention of even trying it) natively adding support for structured assembly instructions directly to the beebasm code.

Off the top of my head, maybe something like this:

Code: Select all

    ORG &900
    LDA #42
    SETLINE 8
    LDX #245 // this is physical line 4, but logical line 8 because of the preceding SETLINE 8
    LDY #300

would produce:

Code: Select all

test.asm:9: error: Immediate constants cannot be greater than 255.

    LDY #300
         ^

even though the LDY #300 is "really" on line 5 of the input.

Edit: I suspect macros make this harder to implement, but I haven't looked at the beebasm code to see if they would really complicate the implementation.

[tricky]

Sorry, I completely misunderstood what you wanted re structured assembly :O

[VectorEyes]

I have to be honest, this all sounds like a lot of effort to essentially do a comparison and branch-if-zero over an intermediate instruction! To my eye the “xifeq” actually obscures what’s going on under the hood (and would, for instance, make it more difficult to reason about which flags are being altered as instructions get executed). Are there any other examples you could give that demonstrate how this functionality could be useful?

[VectorEyes]

Right, having read up on the 1982 paper on structured assembly (https://dl.acm.org/doi/10.1145/800066.801367) it honestly sounds like the sort of thing that would be better handled by a preprocessor step than by building it into BeebAsm. You'd have better separation of concerns. BeebAsm could get on with being a great Beeb-focussed 6502 assembler and the preprocessor tool could be written in whatever you like, extended as you like, and son on.