Linzino wrote:Thanks a lot!
I am trying to understand more now how the CFG works.
I did not know that one should use pragmas to specify the segment.
I thought it was done automatically by the linker.
So, I need to figure out which part of the code should go to which segment.
I guess I can do this by looking at the size of the object files.
Well, the linker is pretty good at that. The reason to put code in a specific spot is for applications that do banking. Putting concise, shared pieces of code in an appropriately sized chunk of RAM is a big help and one of the great features of the linker in cc65.
The goal of my personal project is to write a little fun game for nearly all 8 bit computers (+ TI/994a which technically is 16 bit)
Whatever makefile solution I decide to use,
should work with CC65 (6502), SDCC (Z80), ZSDCC (Z80), SCCZ80 (Z80) and CMOC (6809), GCC for TI (TMS9900), C99C (TMS9900).
For the moment I am only compiling with CC65 (6502), ZSDCC (Z80), SCCZ80 (Z80).
Linzino wrote:The goal of my personal project is to write a little fun game for nearly all 8 bit computers (+ TI/994a which technically is 16 bit)
Whatever makefile solution I decide to use,
should work with CC65 (6502), SDCC (Z80), ZSDCC (Z80), SCCZ80 (Z80) and CMOC (6809), GCC for TI (TMS9900), C99C (TMS9900).
For the moment I am only compiling with CC65 (6502), ZSDCC (Z80), SCCZ80 (Z80).
I don't think you'll find an out-of-the-box Makefile, but you can definitely make one. (see what I did there?)
Linzino wrote: The reason to put code in a specific spot is for applications that do banking. Putting concise, shared pieces of code in an appropriately sized chunk of RAM is a big help and one of the great features of the linker in cc65.
Not only banking, but anywhere a non-contiguous memory layout is required or where specific segments must reside at specific memory locations (i.e. vic-20).
Linzino wrote:So, I need to figure out which part of the code should go to which segment.
I guess I can do this by looking at the size of the object files.
The linker will tell you if you overflow and by how much. You can look at the segment list in the .map file to see segments which can be rearranged to fill any gaps
I have (almost) been able to add UDG to the Vic 20 versions by using a slightly modified version of @beamrider's CFG for the Vic20 + 8k and Vic20 + 16k versions of my game.
What is broken when using this configutation is that the stack is placed somewhere in memory where it conflicts with graphics memory. Some characters are corrupted as if code or the stack itself were lying on the graphics memory area.
I have never had any such problem with the default cfg's because the stack position in those cases is somehow implied.
This is no longer the case and I need to place the stack (a very small you) where it causes no harm.
SEGMENTS {
ZEROPAGE: load = ZP, type = zp;
LOADADDR: load = LOADADDR, type = ro;
EXEHDR: load = HEADER, type = ro;
STARTUP: load = MAIN, type = ro;
LOWCODE: load = MAIN, type = ro, optional = yes;
ONCE: load = MAIN, type = ro, optional = yes;
CODE: load = RAM1, type = ro;
RODATA: load = MAIN, type = ro;
DATA: load = MAIN, type = rw;
INIT: load = MAIN, type = bss;
BSS: load = MAIN, type = bss, define = yes;
UDCCHAR: load = CHARMEM, type = ro, define = yes, optional = no;
}
FEATURES {...
...
where value = $0104; is a value that, by chance, seems to place the stack at a location where no immediate disaster is visible on the screen but it is clearly not a solution (just a hack).
If I use
MAIN: file = %O, define = yes, start = $120D, fill = yes, size = $1C00 - $120D - __STACKSIZE__;
@beamrider Thanks for sharing the template! I got a small beginning of a game up and running with it over the last couple of weeks (yay!) I'm not such a technical person but I'm slowly learning more about C64/Vic-20/C16/Plus4 programming, and I love it!
Hi guys, I wanted to have 256 user defined characters instead of 128 using beamriders template / 16k cfg, so I tried to make CHARMEM $0800 instead of $0400 in the cfg file, but then I realized VIC can only see the chars if they're in the internal memory. It seems the cfg is set up exactly for 128 characters since everything above that spills over above $2000.
I don't understand how to make MAIN memory smaller in the cfg to fit 2K of chars i.e. 256 chars "in a row" in internal memory. Is it possible to move over some of these: STARTUP, LOWCODE, ONCE, RODATA, INIT or BSS from MAIN to RAM1 and then check the map file how much memory I can remove/save from MAIN? Or are those stuff that also always need to be in internal memory? I moved CODE and DATA segments to RAM1 earlier and that seems to be working fine.
I thought I tried that already! However big thanks for helping out again! It does compile and start the game now, but the screen is empty (I can hear the sfx when I run around in the game), I was thinking that maybe the characters got "displaced". I tried and tried to find the issue last night but couldn't pinpoint it. If I make the charmem size $0600 and main size to $1600 - $120D instead I can see some of my characters on the screen (but the wrong ones).
I stared thinking maybe this code snippet from the sample is the issue, if it initializes the char memory for 128 chars and not for 256 chars. Unfortunately I can't understand the code at all. I googled so apparently tilde inverts the bits but I still have no idea what this code does. I tried looking for clues in the cc65 folder and in vic20.h what VIC.addr would be doing but to no avail. Sorry for not being such a knowledgeable programmer, but getting the "base"/code-template down the first time around for a new system is always the hardest.