Ok, bug first...

I'm attempting to assemble a copy of the rom from the 6502 second processor, this rom has it's code from F800-FFFF. The rom is assembling fine however when trying to generate the output file I'm using :-

SAVE "Client6502.rom",&F800,&FFFF

However this seems to miss off the last byte at FFFF, which is not saved to the output file. I tried specifying 10000 as the end address, but this as expected gave me an error message.

Next a request, would it be possible to have a simple way of declaring/filling a block of bytes with a single value ?

Finally what environment do I need to use to try and re-compile the assembler source code ? (under windows), I presume the standard unix tools can be used on Linux etc.

Cheers.

Phill.

Hi Phill,

Thanks for the feedback. That is indeed a bug! I will release a new version which accepts an end address of &10000 - as per *SAVE on the Beeb, the block is saved up to, but not including, the end address. (As an aside, does *SAVE accept an end address of 10000, I wonder...?)

As for filling a block with a single value - for now, is the following convenient?:



I could create a special keyword to do this, but it seems slightly obscure.

Cheers,
Rich

Oh, re compiling in Windows - yes, it's not as simple as opening a solution in Visual Studio as I wanted to keep the environment very neutral, using Makefiles as the build system, so that it would be as portable as possible.

I use MinGW (http://www.mingw.org), which is a Windows port of GCC, and GNU Make 3.81. Also install Cygwin in order to get some handy Unix-style executables, like rm, sed, etc. Don't use the Cygwin version of GCC though, as it carries a bit of extra baggage with it, and isn't so much designed for Windows as MinGW.

Then, provided you add MinGW and Cygwin to your Windows path, BeebAsm should just compile straight away as-is.

HTH!

That said, it is fairly trivial to get it building in Visual Studio if you want to...

Humm I have those installed, but, looks like my mingw install might be borked, when I try and compile I get :-



And so on.

I'll do a re-install later and see if that fixes it, odd it worked for compiling Mess last time I did that (couple of weeks back).

Cheers.

Phill.

A couple of thoughts:

First of all, try compiling with

make code VERBOSE=1

so you can see what commands are being issued. (Perhaps you could paste the output here?)

Could it be that the space in your source path (Utility source) is causing trouble?

Also check that the MinGW\bin directory is higher up in your path than any other possible GCC version - just in case the wrong compiler's being invoked.

The makefile should work well with GNU Make 3.80 and 3.81 - so I doubt that's the problem.

Curious...

hmmm a quick Google does seem to suggest that the problem would go away if you just reinstalled MinGW. Perhaps this is the most painless way to go!

That said, if you have Visual Studio, I'm sure you could probably just drop the source files into a new solution, and it would just work!

Doing proper install from the Mingw distribution fixed it ! Seems that what the Mame/Mess team distribute is only a partial install.

Anway patched commands.cpp and changed the line :-


And that seems to fix the can't save the last byte bug BTW I can't remember if the documentation says so, but I think "end" is a little mis-leading as it's the first byte beyond the last to be saved, whereas I interpreted it as the last to be saved.

As for padding code then your sugestion of using a small for loop worked, the reason I asked was that in other assemblers that I have used you can do something like :-

DB $FF DUP $80

And get $80 bytes of $FF, maybe you should implement a FILLTO keyword used as
FILLTO &Addr,&Value.

Cheers.

Phill.

Hi Phill

Perhaps I can put in a FILL or FILLTO if it'll be useful.

I don't know if you noticed but I released a new version of BeebAsm yesterday afternoon which fixes the bug you mentioned (and a similar one in CLEAR), as well as adding a bit of extra functionality to SAVE.

I can clarify the documentation regarding the end address... the behaviour is exactly the same as *SAVE on the Beeb - I just had a look in the AUG and noticed that its explanation of the meaning of the end address is just as vague as mine... I think the intention was that you could write:



and it would save exactly the right amount of code.

Anyway cheers for the comments, and good luck with the project!