Beginners cc65

[8BIT]

I use the uIP suite for the TCP/IP stack. It takes care of all the session/connection details. To try to do it manually would take a lot of research. That was one reason I started using cc65. I tried writing the support drivers for an RTL8019AS. I got as far as ping responses and a serving a single web page. I gave up after that as it was getting too complex too quickly.

Daryl

[8BIT]

I have just updated the support file on my website:

http://sbc.rictor.org/support/CC65forSim.zip

It now contains an additional target that builds the code into a bootable ROM image.

By default, it is set up as a 32k ROM, from $8000-$FFFF. The size can be changed. The IO area on the simulator is set to $7Fxx. Use the load code command to load the compiled *.65b rom images. Set the load address to 0x8000.

The reset vector will point to the proper starting point. A brk opcode will end the program.

I have added a few comment files and the original demo files now have a makerom.bat file included to make the rom version of the program. Note the file size of the *.65b files are always 32,768 bytes.

The three main files (located in the \cc65\simrom folder) that control how cc65 works are simrom.cfg, crt0.s, and simrom.inc

I hope this will help others to create a ROM image from C and/or assembly source code using the cc65 suite.

Daryl

[enso]

I am curious about what it would take to set up a cc65 build environment for an absolute minimal system, with a serial port interface. I've been looking over the docs and this thread (most informative), but am not sure about what is the minimal setup. Daryl has done a lot of work, and his download contains a lot more than what I would need to port (I think?).

At the absolute minimum, it looks like I would need a .cfg file and a minimal library. How much would it take to get printf to work?

[enso]

I managed to get the compiler to sort of work, following the instructions for the custom target. My test program just outputs a character to the serial port. I had to make some changes to the proposed cfg file (instructions out of date?) and in the end the following symbols were missing:
__DATA_LOAD__, _DATA_RUN__ and __DATA_SIZE__. These are referenced by copydata in the initialization code, presumably to pass pointers around. I defined them in my test file making sure they are 16-bits wide like this:
unsigned char * _DATA_LOAD__;
unsigned char * _DATA_RUN__;
unsigned char * _DATA_SIZE__;
At this point my program compiled. I am a little out of my depth and don't have a disassembler handy to look at the code, so if anyone has thoughts about this I would appreciate it

[8BIT]

Are looking to compile C code to load and run from RAM, or from ROM. There are different methods for doing both. I am going to be pressed for time this weekend, but can try to help out as I find time.

Daryl

[enso]

I am looking to compile C to run from RAM, so it should be simpler. Thank you. Whenever you get a chance.

I am not clear on the really low-level C initialization sequence in this environment. I've done it with a bare-metal ARM toolchain a few years back, with gcc. As I mentioned before, I am compiling something, but it would be nice to do it in a cleaner way, and I am not sure about who sets __DATA_LOAD__, _DATA_RUN__ and __DATA_SIZE__.

[Arlet]

enso wrote:

I managed to get the compiler to sort of work, following the instructions for the custom target. My test program just outputs a character to the serial port. I had to make some changes to the proposed cfg file (instructions out of date?) and in the end the following symbols were missing:
__DATA_LOAD__, _DATA_RUN__ and __DATA_SIZE__. These are referenced by copydata in the initialization code, presumably to pass pointers around. I defined them in my test file making sure they are 16-bits wide like this:
unsigned char * _DATA_LOAD__;
unsigned char * _DATA_RUN__;
unsigned char * _DATA_SIZE__;

These are linker-defined variables. The linker defines these based on the place/size of the DATA section defined in the config file. The startup code can then use these to initialize the DATA section by copying the data from the load address to the run address. You should not define them locally, but import the symbols.

[enso]

Arlet wrote:

You should not define them locally, but import the symbols.

That makes sense. Does it matter where the import happens? I couldn't find how it's done with other targets by grepping, but I didn't look hard enough

[Arlet]

You only need to import them in the source file where they are used to do the initialization. Unfortunately, I don't have a working example anymore. I had something running in cc65 a few years ago, but the memory consumption was a bit too much for my project, so I rewrote it in asm.

[8BIT]

I have just updated the support file on my website:

http://sbc.rictor.org/support/CC65forSim.zip

It now support's printf.

As far as working with CC65 from Linux, I cannot really help you. I have it running on my windows 7 box and the included batch files work. The sim target is really a minimally supported target. You could remove some of the support files, but that will only take away features from the library. If you don't use them, they won't get loaded into your executable code anyway.

if you can edit each of these files to fit your target, it should be easy to create your own. If your target does not support a feature, just set it up to return 0, if it returns a value. You do have to mind the stack operations, however.

The best way to see what is being loaded is to view the sim.map output file. It will give addresses to various sections, including those for library routines. To see a particular library routine, just move into the libsrc folder, go into the sim folder, and you can view the .lst files for each file. Also, I modified the makesim.bat files to provide the lst files for the common, runtime, dbg, and conio folders. After a while, you begin to see how the object file gets populated.

Hope this helps

Daryl

[enso]

Daryl, no problem. It should be the same for linux or windows except for the makefiles.

[8BIT]

Forgot to mention, in sim.inc, change .PC02 to .P02 to remove the CMOS opcodes. I did that while testing to ensure the sim code was 6502 pure, but didn't change it for the published sim version.

Daryl