CC65 and display list

[danwinslow]

Yaron - I was in exactly the same place as you a couple of years ago. Then I decided to get over my config phobia and I just started working with it and learning. It makes sense once you get used to it, and it makes serious development MUCH easier in the long run. Well worth the effort. I wound up using it to define overlays and EXT ram loadable stuff and all kinds of things. Well worth the time investment.

Edited September 24, 2018 by danwinslow

[sanny]

Well said, Dan.

 

I'd suggest getting a cup of coffee or bottle of beer (depending on your preferences) and read the documentation at https://cc65.github.io/doc. For this discussion, ld65.html and atari.html are the most interesting parts.

 

regards,

chris

[sanny]

how can one use __RESERVED_MEMORY__ in CC65 code?

 

can you post an example?

 

See the documentation, in atari.html.

 

It reserves some memory space at the top of memory so that the cc65 runtime doesn't use it. There you can place whatever you want (DL, screen buffer, font data, etc) at fixed addresses.

Note that if someone doesn't have a machine with 48K, but less, your fixed addresses maybe don't work. It's probably an academic problem since anyone now has 48/64k at least now, but the the cc65 runtime is built to also work on "lesser" machines.

 

A good way to check what memory your cc65 program is going to use, is to create a map file when linking and looking at the locations of the segments.

 

regards,

chris

Edited September 24, 2018 by sanny

[dmsc]

Hi!

 

Yes, it requires some learning. But if one knows what memory is, what addresses are, and so, it's no rocket science.

 

See https://cc65.github.io/doc/ld65.html#s5for documentation.

IMHO, I think the mayor complication is that LD65 does not have native support for the XEX (Atari binary) format. So, you must implement the headers by hand, for each section that you want to place in the linker script.

 

Adding support for XEX file format would make the config files easier to edit, as you could add new sections at any address and the linker would produce the appropriate header.

[dmsc]

Hi again,

 

...

See my initial try at adding XEX file format support at: https://github.com/dmsc/cc65/commit/21e849fdff834fa0ab27f1e4b086c2f56e560562

[Yaron Nir]

Hi again,

 

 

See my initial try at adding XEX file format support at: https://github.com/dmsc/cc65/commit/21e849fdff834fa0ab27f1e4b086c2f56e560562

 

Hi dmsc,

this looks interesting, what would be excellent is to create an API to handle the cfg withint the code of CC65

for example, methods like:

setSegmentAddr(char* name, void* addr....)

etc...

[Yaron Nir]

 

See the documentation, in atari.html.

 

It reserves some memory space at the top of memory so that the cc65 runtime doesn't use it. There you can place whatever you want (DL, screen buffer, font data, etc) at fixed addresses.

Note that if someone doesn't have a machine with 48K, but less, your fixed addresses maybe don't work. It's probably an academic problem since anyone now has 48/64k at least now, but the the cc65 runtime is built to also work on "lesser" machines.

 

A good way to check what memory your cc65 program is going to use, is to create a map file when linking and looking at the locations of the segments.

 

regards,

chris

 

chris i have a quick question,

in the documentation it is stated not to use -c together with -t

so use the linker but don't state to which system you are compiling the code to.

 

1) i find this to be very odd

2) in all the games examples with code posted i have seen, there was always -c and -t in the build.bat file..... so i am not sure how it is exactly being validated nor work....

[sanny]

ld65 (I think) doesn't accept both -t and -C.

cl65 does (use -t before -C)

[Irgendwer]

See my initial try at adding XEX file format support at: https://github.com/dmsc/cc65/commit/21e849fdff834fa0ab27f1e4b086c2f56e560562

 

 

That's really great! What is missing, so that you abstained from a pull request yet?

[Irgendwer]

this looks interesting, what would be excellent is to create an API to handle the cfg withint the code of CC65

for example, methods like:

setSegmentAddr(char* name, void* addr....)

 

No really. For most cases something like a

#pragma align VALUE

would be sufficient and very practical (no need to care about extra segments and their size).

Unfortunately even in assembler there are some restrictions using the ".align" statement and the linker is not intelligent enough yet to reduce unnecessary gaps introduced by an alignment.

[Yaron Nir]

Irgendwer,

 

does this:

 

#pragma align VALUE

 

applies on the variable that comes after it, or applies on all the definitions below it?

 

for example:

 

#pragma align 0x100

const char* PMGBase = 0x1000;

const char* DLAddr = 0x2400;

const char* MemScr = 0x2500;

 

does the align will affect all 3 variables or just the first?

if yes is to answer all 3,

is there a way to align only a specific one?

 

do i use the pup & pop?

 

help?

[dmsc]

Hi!

 

Hi dmsc,

this looks interesting, what would be excellent is to create an API to handle the cfg withint the code of CC65

for example, methods like:

setSegmentAddr(char* name, void* addr....)

etc...

I don't understand, where you want that API?

 

The segment addresses are unknown to the compiler (CC65) or the assembler (CA65), they are only meaningful for the linker (LD65). The linker reads the linker configuration file, and you can pass values in the command line to set parameters in the configuration file. Then, the linker fixes all addresses to the ones computed.

[Yaron Nir]

Hi!

 

 

I don't understand, where you want that API?

 

The segment addresses are unknown to the compiler (CC65) or the assembler (CA65), they are only meaningful for the linker (LD65). The linker reads the linker configuration file, and you can pass values in the command line to set parameters in the configuration file. Then, the linker fixes all addresses to the ones computed.

 

i actually didn't explain myself very well above... after reading Irgendwer response, it made my question irrelevant.....

 

thanks!

[sanny]

Hi Daniel,

 

See my initial try at adding XEX file format support at: https://github.com/dmsc/cc65/commit/21e849fdff834fa0ab27f1e4b086c2f56e560562

 

I have to admit that I don't know whether I like that. It might be convenient sometimes (hmm, maybe even many times), but if one wants to have complete control of how the output file is generated, it appears to stand in the way.

This opinion is just from browsing through the changes. I haven't really run it. Do the existing atari*.cfg files still work with that change?

 

OTOH, it might be a good addition if it could be selected at compile-time. For users to have "simpler" cfg files.

I have to dig into it more deeply...

 

regards,

chris

[dmsc]

Hi!

 

Hi Daniel,

 

 

I have to admit that I don't know whether I like that. It might be convenient sometimes (hmm, maybe even many times), but if one wants to have complete control of how the output file is generated, it appears to stand in the way.

This opinion is just from browsing through the changes. I haven't really run it. Do the existing atari*.cfg files still work with that change?

Yes, for this to make any change, you need to explicitly set the file type. This is my test config file (modified from the one in FastBasic):

FEATURES {
    STARTADDRESS: default = $2000;
}
MEMORY {
    ZP:      file = "", define = yes, start = $0094, size = $0040;
# "main program" load chunk
    MAIN:    file = %O, define = yes, start = %S,    size = $BC20 - %S;
# code in zero page!
    INTERP:  file = %O, define = yes, start = $0082, size = $0012;
}
FILES {
    %O: format = xex;   # Specify XEX file format
}
FORMATS {
    xex: runad = start; # This symbol address will be written at RUNA
}
SEGMENTS {
    ZEROPAGE: load = ZP,      type = zp,  optional = yes;
    JUMPTAB:  load = MAIN,    type = ro,                  define = yes, align = $100;
    RUNTIME:  load = MAIN,    type = rw,                  define = yes;
    CODE:     load = MAIN,    type = rw,                  define = yes;
    DATA:     load = MAIN,    type = rw   optional = yes, define = yes;
    BSS:      load = MAIN,    type = bss, optional = yes, define = yes;
    INTERP:   load = INTERP,  type = rw;
}

The main difference is the removal of the XEX headers, and the automatic inclusion of a RUNAD segment, if specified, so you have 3 less sections. Compare with the original at https://github.com/dmsc/fastbasic/blob/master/compiler/fastbasic.cfg#L22

 

 

OTOH, it might be a good addition if it could be selected at compile-time. For users to have "simpler" cfg files.

 

I have to dig into it more deeply...

My current branch (4 commits) is at: https://github.com/dmsc/cc65

 

Regards,

 

Daniel.

[dmsc]

Hi!

 

That's really great! What is missing, so that you abstained from a pull request yet?

It was a simple hack, I need to do more testing. I already added the skipping of extra "$FF $FF" when not in the first memory area and the automatic writing of RUNAD.

[Irgendwer]

does this:

 

applies on the variable that comes after it, or applies on all the definitions below it?

 

for example:

...

 

Maybe this was unclear, but there is no such "#pragma align" in cc65 yet. (But it would be IMHO much more useful than defining segments out of the code.)

But if such pragma would exists. it could be created in a way that consecutive variables with matching size would not break the alignment.

 

Edit:

As you already put fixed addresses into your sample, it doesn't make any sense to me to put a (yet fictive) alignment pragma in front. It would only make sense in a scenario where the linker decides where to put the memory but to fulfil the memory alignment like:

 

#prama align 0x400 // this doesn't exists now!

char MyFont[] = { 0x00, 0x01 ....

etc.

Edited September 26, 2018 by Irgendwer

[Yaron Nir]

Yes I was looking for something like that....

 

To use a pragma directive for alignment can be good

It should work exactly as asm .align work.

 

Well maybe someone from AA will accept the challenge ?

[mellis]

Yes I was looking for something like that....

 

To use a pragma directive for alignment can be good

It should work exactly as asm .align work.

 

Well maybe someone from AA will accept the challenge ?

 

 

Reading all of this leads me to surmise that you have elected use cc65 because you perceive 6502 assembly language as being too hard to learn. I've also read your comments suggesting the cc65 tools (specifically ld65) are too hard to learn, and you suggest that somebody should change them for you.

 

If you want to write software, you're going to have to do some learning. I have been writing software for 35 years, and I can assure you that the learning requirement never goes away -- there's always another technique, technology, or tool you will need to study.

 

If I were you, I would read Compute's Machine Language for Beginners and get started that way. You can easily write C code for any other computer in the word, but the 6502 married to the Atari custom chips is what makes this machine special.

[Yaron Nir]

Developing on 8Bit in the 21st century is amazing to me

And a challenge at the same time

As I find the more current language like C language

I prefer to explore the possibilities around this

I have something to compare my personal project to so I will be able to tell if and what is the difference comparing to assembly

I strongly believe I will be able to accomplish what I need in CC65.

And if not a tweak in asm will do the trick ?

[funkheld]

is not turned off.

all memory which you think you need to deduct from CFFF.

PM usw...

greeting

Edited September 26, 2018 by funkheld

[funkheld]

hello, I have the same with 70 years ago.

I prefer now fastbasic. fastbasic also uses the cc65 atari.lib

I also like the 8bit languages and the atari with altirra and the mist-fpga.

greeting.

[sanny]

Daniel's (dmsc's) XEX changes to cc65 had been incorporated into cc65 some days/weeks ago. They are not the default, so read the documentation.

 

But it should be simpler now for newbies to create multi-segment Atari executables. Don't know, Daniel, if you'd like to elaboarate a bit more on that...

 

regards,
chris