I have updated the archive file with better instructions for installing and using. Thanks to Dajgoro for helping in finding the "holes" in my instructions.

It will take a lot of research to learn how the entire package works, but this will at least get someone started.

Daryl

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

I will try to figure out how it all works while modifying the compiler to fit in my sbc. If i manage to get it working, i could write a quick tutorial on what have i modified...
Has anyone tried to use that patched editor that i posted in my last post?

Where are the document that describe the configuration files, i can't find them...

I don't think they exist. I never found them either.

I am having trouble moving the DATA segment into rom.
It is marked as rw, and if i move it in rom, it complains that it must be writable. If i leave it in ram then it won't compile the subroutines(or whatever), resulting that the jmp instructions to jump at 0000.
And if i set the rom as rw in some cases i get 00 instead of Hello world! when i run the simulation...

I peaked in the Apple II and Commodore files and it seems as if everything works in ram, and there is no rom??

Edit: How does the cc65 work on your sbc3, does it load the code into ram and executes if from there?

Programs on my SBC-3 and SBC-4 all run from RAM. You can call system routines that are in ROM by placing their addresses in the target.inc (sim.inc) file.

That requires a bootloader, and a startup sequence, that i wish to avoid.
It kinda complicates thing when programming the eeprom...
I sent an email to the cc65, lets hope i get some answers from them...

No reply...
Is there any target device that stores the program in rom and not in ram?

Not that I can remember.

That explains a lot...
But why use that small amount of ram that it is available when you can simply have the program in rom?

Nobody replayed on my email, is there someone else that i could contact?

This makes sense to me. First, it evidently works. Second, it's just telling the tool not to care about read-write versus read-only - look after it yourself. If you try to write to ROM in your code, you will find that it won't work in real life.

Cheers
Ed

I didn't mean i want it all in rom, i just want the program code in rom, so i don't need to boot it every time, and if i boot it i would spend 2x time the memory that it is needed to store the program code, one copy in ram, and the source in rom. The variables, arrays, stack, ect... , they of course should be in ram, that is what i am trying to do. But when i set the program code to be at the location C000 and data, bss, heap in ram(from location 0200 to 8000) i can't get it to work, the jmp instructions are set to jump to 0000. When i try to move the data section close to the rom range instead of the Hello world! message i get 00.
So i am bit unclear what is happening here, and i only want to move the program code into rom, and leave everything else into ram.

What I'm thinking is that the tool only has to get the addresses right, it shouldn't have to care about any complex memory map or any distinction between RAM and ROM. So making everything RAM seems like a viable choice, as a tool configuration, even if the board isn't like that.

I am of course guessing.

Cheers
Ed

Here are some scenarios that i tested:

Everything is in RAM. Result "Hello world!".




Everything is in ROM,but the rom is actuarially writable here. Result " 00".


Code read only section is in ROM. It doesn't work at all, jmp instruction set to 0000.


The HEADER segment doesn't seem to affect the result.