xasm 3.1.0 released

[Xuel]

To me it's a mystery, but it only works after doing a NEW org-definition, right before the "starttune". It didn't matter when I moved or just removed the "opt h+" command.

It's because of when inserting file with opt h- it's assumed that it is binary file and it is not parsed to deduct what is the end address (you can have several segments in binary file, several "orgs") or something like that. Fox explained it to me some time ago too as I run into the same "problem" like you.

The latter sounds strange. I'd expect "INS" works the same, no matter if/which header the surounding main file has: Insert binary content as described in the manual.

It think it does always just insert the binary content, but perhaps what MaPa is alluding to is that if you disable headers then any headers inside that binary content now become visible to the loader whereas if you leave headers enabled, the binary content's headers are not interpreted as headers by the loader, but just as raw data.

 

For example, if you have this sequence:

 

  opt h-
  org $a400
  ins 'foo.bin'
  opt h+
code
  ldx #foo
  ldy #bar
  ...

Well, then the org does not produce a header due to the opt h- so the first header of the output object file will come from the binary content. And the binary content may even contain additional segments. But after all segments from the binary content have been loaded, the loader will be looking for another segment header. But instead you've just given it the bytes that represent "ldx #0" "ldy #0" which happens to be the sequence "A2 00 A0 00". So the loader will attempt to load any remaining code into the address $00A2 and will continue loading from the file until it reaches address $00A0 which would surely result in any number of errors, e.g. 1) the loader reaches the end-of-file, 2) the loader has to wrap around most of memory to get to $00A0 and would trash all of the hardware registers in the process, 3) etc.

 

So, you can strip off the first header of the binary content and make your own with "org". That works fine if there's only one header in the binary content. Otherwise, you'll need to put another org after the binary content.

 

That being said, it seems it's only possible to expose the headers of binary content to the loader if the "ins" statement comes before any "org" statement that is not hidden by "opt h-". Otherwise any previous "org" will absorb the binary content even if you precede the binary content with "opt h-", since "opt h-" only affects new orgs, it doesn't end the previous one.

 

In any case, the file byte expression that fox showed seems to be the way to go if you really want to reuse the header info in the binary content.

[fox]

Xuel, I'm impressed! I wouldn't explain it any better.

 

I admit that headers generation is somewhat messy:

- opt h- and opt h+ can switch header generation

- org $a000 is a no-op if *==$a000 (saves an unnecessary header)

- ... except when it's org a:$a000 or org f:$a000

- opt f+ inserts padding instead of a new header