3

I am working a 6502 project in CA65, and I am having trouble understanding some of the directives.

What I want to do is have a segment defined as though it is in another part of memory, so that all of the addressing of that code is as though it was already in that segment of memory during compile, but it will be loaded with the main program and need to be moved into place after load... this is a pretty basic model for these old machines, but I am having trouble getting the DEFINE directive in the segment command to work properly.

So I have a MEMORY definition called MYMEM created in the cfg file as a location outside of where the program actually loads, say something like this:

MEMORY{
.
.
MYMEM start = $1000, size =$0200
.
}

and in I then create a segment called MYMEMSEG 

SEGMENTS{
.
.
MYMEMSEG: load=MYMEM, type =rw, define=yes;
.
.
}

I then attempt to access the _ _MYMEMSEG_LOAD__ or _ _MYMEMSEG_RUN__ or _ _MYMEMSEG_SIZE__ values that it claims it creates, but they are all undefined... the generated MAP file does not contain anything with MYMEM or MYMEMSEG in them... so what am I not understanding here?

Speckpgh
  • 3,332
  • 1
  • 28
  • 46
  • You probably have declare those symbols it creates as external, like they were defined in separate assembly source code file. – Ross Ridge Dec 18 '15 at 18:02
  • I am not quite following here... there is no code here to tell to .export, to later worry about importing/including... the _SIZE__ _LOAD__ and _RUN__ are supposed to be created by the define = yes, so how would I go about this? – Speckpgh Dec 21 '15 at 17:29
  • http://www.cc65.org/doc/ld65-5.html IN particular the SEGMENT information 5.2 – Speckpgh Dec 21 '15 at 17:32
  • It appears, based on Nick Westgate's answer, your assembler uses the `.import` pseudo-directive to "import" external symbols defined in other files. It might help to think of the linker configuration file that you define `MYMEMSEG` in as being a different assembly module that exports `__MYMEMSEG_LOAD__`. – Ross Ridge Dec 21 '15 at 17:44
  • Nope, this doesn't seem to work, while the import gets past the compilation error, the value of the _RUN__ _LOAD__ _SIZE__ appears to just be random at runtime.... – Speckpgh Dec 21 '15 at 17:55
  • Nevermind, seem to have it resolved.... the .import seems to have worked. Thanks guys. – Speckpgh Dec 21 '15 at 18:05
  • It's just like other languages where you need to know the type of an external symbol. There is a .importzp, so there are at least two types. ; - ) Another way might be to use [.global](http://www.cc65.org/doc/ca65-11.html#ss11.42) instead, which seems to import or export symbols automatically depending on whether they're defined in the source file. – Nick Westgate Dec 21 '15 at 21:32
  • @user282172 Would the new [retrocomputing.se] site interest you? Knowledge about such processors and languages would be very useful for the retrocomputing community. (Disclaimer: I am a moderator there.) – wizzwizz4 Aug 07 '16 at 16:09

1 Answers1

3

I think the linker exports them, but your code must import them:

.import __MYMEMSEG_LOAD__, __MYMEMSEG_SIZE__
Nick Westgate
  • 3,088
  • 2
  • 34
  • 41
  • I will try this, but seems a bit interesting to me that to have the map file have a reference the code must somewhere include an import directive... I would think define would all that would be needed for it to at least create it in the map file. – Speckpgh Dec 21 '15 at 16:23