6502.org

I wrote a simple routine to be burned into a ROM that ends with the following: (I'm not really using the interrupt vectors).
When I assemble it with this command line: I get the following error: If I assemble it with the -Fsrec switch it assembles properly, and I can then use srec_cat to convert to Intel hex.

Possible bug in the intel hex module?

Or I may just use asmx instead.

I'd need to read the docs of that module carefully but it definitely looks like some behavior of that module, bug or not:

using this code:
Look at the .lst output:
and -Fbin just spits the right thing out no worries.

EDIT: vasm puts that 'FFFA-0' in the list file even for outputs where it works. When I only use one org directive in a source file it puts the actual address. I don't know vasm well enough to know if the -0 is a documented thing for a 'more than one segment case' or the oldstyle module doing something it shouldn't.

I think I've been nerd sniped. The docs say
I got this by giving it -i16hex, and by the description of the file format I'm looking at it looks first-pass fine:
but then you're effectively disabling whatever checks it has for address space.

It seems like it's adding 1 to both segment reports. "seg8000" is only 3 bytes long, not 4.

It outputs the same Section information whether the assembly succeeds (-Fbin, -Fsrec) or fails (-Fihex). I wonder if that's the point at which it fails in the Intel hex module, when calculating the ending address of the segment. I sort of doubt it but I know nothing of the internals of vasm and its modules.

I just thought vasm was a fairly widely used assembler in this community and I would have guessed this is a known issue.

I don't think too many people here use vasm, besides me. I think most folks here use ca65.

I've never used the ihex or srec output modes, though; I always use flat binary output mode. If I need ascii hex digits for some reason I use hd or xxd.

This does seem like a bug in the ihex module, though. If I try to assemble the little 90 byte testing routine I'm using this morning using ihex format I get: Well, yeah, I would say so!

I'd bet that a larger proportion of the people who landed here via Ben Eater videos are using or have used vasm at least a little bit.

I also currently see this as 'probably a bug in the ihex module', and I also don't grok at all why the address size options are what they are, but I'm sure it makes sense to whoever wrote it.

I had the thought that this could be 'the segment report is reporting start (inclusive) to end (exclusive)' - but I haven't managed to find any docs on the wide output format, yet, so who knows.

I had that thought due to not exactly remembering something from one of my youtube video binges where a C64 utility (maybe a monitor or assembler) wanted exact end address in one case and the address after in another.

(Edit: the monitor that comes with the C64 macro assembler development system wants end address + 1 when saving from memory to file, this is what I was thinking of)

output_ihex.c

It buffers the character and then increments a file-local (declared static outside any function - so "global" for any code in the file but not actually exported) addr value.

When it actually outputs, it does the check - checking against that addr value in write_data_record() - but that addr value is now actually one /after/ the address of the byte we last stuffed into the buffer, and if the check weren't there /we might not ever get to the point where we would try to buffer something for that address/.

Edit: Or to state it another way, it is treating addr as “the next address I can modify data at” except when it does the test - there it is treating it as “the highest address I have modified”.

It appears to work fine in the (very very small number) of cases I tried after I changed to: So I think, yeah, this is definitely an ihex output module bug.

More edit: I don’t really trust this to be the only bug in the little bit I’ve looked at the code, I’d be interested in seeing what Paganini might get even with this fix given the wildly large address complained about in that case.

Edit one more time: I keep thinking that it may well be a better fix to move the original test to just before addr is incremented. It’ll test more but possibly fail faster.

I was going to post a patch after testing a few things and deciding how I'd fix it - but I decided to check first ->

It looks like they've actually already fixed if if you download their daily source instead of the released source.

The change I decided to finalize on does it it slightly differently, making a #define constant for I8HEX_MAX and I16HEX_MAX (moving the test results in an error report for every single byte you exceed the limit by, rather than just reporting once and bombing out), but the above certainly should work so ....

http://sun.hasenbraten.de/vasm/index.php?view=source

Tried your fix out this evening; works just fine here!

Nice! Thank you for trying.

Just in case anyone wants a fix before they do a new release and doesn't want to run on a daily source, my final change (which is really going to end up being the same as the first in the actual binary, due to constant folding) was:

Replace the MEBIBYTE #define with and then replacing the constants in the original tests as appropriate (the board doesn't like .patch or .diff as extensions so I figure that may be an indication a full patch attach and/or paste in a code block may not be wanted; I suppose it could also be that it's hard-limited to a set of image extensions).

I16HEX_MAX is the MEBIBYTE #define with the -1 dropped, and these are both wrapped in () so use of the macro doesn't risk the macro causing different values in different expressions due to operator precedence - not much risk of that here but it's good practice.

vasm 1.9e has been released, it has the fix for this issue that was in the daily source snapshot.