Well, to be fair, I think I'm making it do things it's not designed to do!

But I just thought I'd mention...



When I compiled that I expected to get a small file 2k in size all 0's with just the four bytes at the end. What I got instead was a 32k file all blank all the way up except for the four bytes at the end.

Like I say, clearly I'm twisting it and making it do something pretty unreasonable for an assembler but it seemed to me like a nice easy way of getting a ROM that only contained the interrupt / reset vectors

Obviously when I thought about it, I realised it was a bit dumb, changed my 1st ORG to 0, my 2nd ORG to $7FC and I got my file as I expected.

The problem is you've defined your first label before the ORG!

If not set, it defaults to an ORG of 0, and the label is set to whatever the current value is.

Try this instead:



To be honest, one of my big influences in designing BeebAsm was to have absolute control over what is saved, so the sort of thing you're doing there is completely what I had in mind.

I have no idea what a different assembler would output given that source code (whether it would concatenate the two blocks to give a 5 byte file, whether it would output 2048 bytes, or do something else). That's why I liked the use of the SAVE directive inside the source code to specify exactly which it should output!

Just an addendum to this: presumably if you were wishing to create a ROM containing some code and the 6502 hardware vectors, the addresses you actually need are $F800 and $FFFC? (or maybe does this hardware only use 15 address lines, and mirror the 32k block?)

Yes, A15 at the CPU just floats and the A15 input to the address decoding circuit is tie low so it's mirroring of sorts! Had me going for a while when I first started this wondering how on earth I was meant to get the vectors into FFFC, etc when the ROM space only went up as far as &7FFF