I broke BeebAsm

[marcelaj1]

Hi,
Wrote some code and compiled it with BeebASM and it ran fine. I made some changes and now the code crashes out to the OS, on examination it is hitting &00 which causes a BRK and the BRK vector takes over, so that explains that.

I have a chunk of code at &3000 and BeebASM is happy and says it has compiled ok as per screen dump

.Proc0
3000 58 CLI
3001 AD 78 7C LDA &7C78
3004 C9 4D CMP #&4D
3006 F0 71 BEQ &3079
3008 A9 4D LDA #&4D
300A 8D 78 7C STA &7C78
300D A9 69 LDA #&69
300F 8D 79 7C STA &7C79
3012 8D 7C 7C STA &7C7C
3015 8D 86 7C STA &7C86
3018 A9 6C LDA #&6C
301A 8D 7A 7C STA &7C7A
301D 8D 7B 7C STA &7C7B
3020 A9 73 LDA #&73
3022 8D 7D 7C STA &7C7D
3025 8D 83 7C STA &7C83

But for some reason everything after &2B04 is missing.

It seems that the ORG statements have to be in ascending order in the source file - I had tacked on a small sub routine at the end of the source just befor the ".end" meant to start at &2B00. This seems to have the affect of saying 'the last ORG statement of the source sets the memory top'. I moved the code along with its ORG statement up the source and the code now extends all the way to &438F.

Is this expected behaviour?

[cmorley]

Sounds like SKIPTO <addr> is what you need. I'll let others speak to the behaviour of ORG

[VectorEyes]

How does the code that you assemble get saved out to disc? Could it be something to do with where the "*" ('current' assemble-to pointer) is pointing to when you save?

Really we need more info on the source, not just the piece of assembled code, to judge what's going on.

(I've always thought of 'ORG' as just saying "change where I'm assembling to right now'.)

[marcelaj1]

I've always thought of 'ORG' as just saying "change where I'm assembling to right now'.

Thats what I thought.

I am assembling "straight to SSD"
Beebasm.exe -v -i MainBit.asm -do MainBit.ssd -boot Main
From within VSCode

The last line of the source is
SAVE "Main", start, end

On a Windows 10 machine

I am not at my Windows box at the moment but after moving the lower addressed ORG to above the higher ones it works

[VectorEyes]

And you’re absolutely sure that start and end are in the right place? Could you add some “print” statements to print out their values when you save, along with the values of the top and bottom of the two assembled segments?

[marcelaj1]

Could you add some “print” statements to print out their values when you save

I have not been using beebasm for long (mainly used bbc assembler) and I only know the bits I need to make it work, so we are straying into unknown territory from my perspective, having said that....

The .start is the first line after the first ORG statement, in this case &2000.
The .end is on the line right at the end immediately before the SAVE statement.

When this goes wrong the last ORG statement is ORG &2B00.
When I move that ORG and the subroutine that goes with it up towards the top, the last ORG is &42C0.

The listing above is the output of beebasm when it goes wrong, foolishly I thought that meant it compiled and the code was in memory when in fact it threw away everything after &2B06, the end of the subroutine I tacked on.

So is "print" a beebasm statement? if so I assume it has no impact on the code but prints the value of the labels?

Happy to litter the source with debug, its a great way to learn beebasm, and may save hours of frustration in the future.

I am away from development machine until tomorrow, shame there is not an android version of these tools, but then I would never be away from programming.

[tricky]

Did you check that the data is in the file on the .ssd?
*I.*.*

You can also add -v to the command line and it will spit out a listing like the BASIC one so that you can see which values were written to each byte.

[VectorEyes]

PRINT is indeed a BeebAsm statement. The BeebAsm documentation is really pretty good, I'd suggest having a look here:

https://github.com/stardot/beebasm

and looking for the documentation relating to how "PRINT" works.

I strongly suspect that once you've put some debug-prints in place you'll soon realise why it's assembling incorrectly.

[VectorEyes]

OK so, re-reading your description again I have some observations.

I think the key issue is that (in the case where things break) the last part of what you're doing is:

<code that assembles to high-up addresses such as &42C0>
.ORG &2B00
<some code>
.end

SAVE "MAIN", start, end

The problem with that is that what ORG does is say "Right, BeebAsm, you're now assembling to memory address &2B00, so as you assemble code start there and move the 'current assembly point' pointer forwards appropriately. Then when it sees the ".end" what that's saying is "here is a label named 'end', its value is whatever the 'current assembly pointer' is set to. In your case, presumably, &2B06. So when it then sees the SAVE directive, it does exactly what it's told, which is to save out the block of memory between start (I think you said that was &2000) and end (&2B06).

To fix that, you'd need to make sure that 'end' was declared at the highest point in all your assembled code and data. So you'd put the 'end' at the end of the code block that was highest in memory, BEFORE you had "ORG &2B00".

I hope that makes sense!

[marcelaj1]

To fix that, you'd need to make sure that 'end' was declared at the highest point in all your assembled code and data. So you'd put the 'end' at the end of the code block that was highest in memory, BEFORE you had "ORG &2B00".

That is the conclusion I arrived at but not until I had spent the best part of a day trying to debug my code which did not have a bug in it, it was the way I had laid out the code in the source file. I made incorrect assumptions based on the compiler information as opposed to what it did. I only figured it out when I did a "peek 3000 100" in the debugger which told me it was all &00. I think maybe a few "print" statements in the source could have avoided this, I will ponder on an info block on the end of the source file that gives an indicator of what is going in the SSD.