6502/cc65
1
0
Fork 0
mirror of https://github.com/cc65/cc65.git synced 2024-11-02 18:06:48 +00:00
Code Issues Projects Releases Wiki Activity
4641e36f0d
cc65/cfg/sim65c02.cfg

36 lines
1.2 KiB
INI
Raw Normal View History

Added 'sim6502' and 'sim65C02' targets. The targets allow to run cc65 programs in the sim65 exection einvironment. As there are no "real" i/o facilities there's no need for header files. Paravirtualized entry points are mapped to $FFF0 ff. There's a large cc65 progam area from $0200-$FFEF. The binary format includes a one-byte header indicating the required execution environment: The value 0 means 6502 and the value 1 means 65C02. The load adress for the binary is fixed to $0200. Note: Running sim65C02 programs currently doesn't work bcause sim65 doesn't actually implement 65C02 opcodes.
2013-05-20 18:35:42 +00:00
SYMBOLS {
__EXEHDR__: type = import;
__STACKSIZE__: type = weak, value = $0800; # 2k stack
}
MEMORY {
Fix regression of #pragma bss-name Closes #409
2017-03-21 21:35:25 +00:00
ZP: file = "", start = $0000, size = $001B;
Renamed INITBSS to INIT and INIT to ONCE. The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name. Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
2016-03-06 20:26:22 +00:00
HEADER: file = %O, start = $0000, size = $0001;
Renamed RAM to MAIN for all disk based targets. The name RAM doesn't make much sense in general for a memeory area because i.e. the zero page is for sure RAM but is not part of the memory area named RAM. For disk based targets it makes sense to put the disk file more into focus and here MAIN means the main part of the file - in contrast to some header. Only for ROM based targets the name RAM is kept as it makes sense to focus on the difference between RAM and ROM.
2016-03-07 00:28:55 +00:00
MAIN: file = %O, define = yes, start = $0200, size = $FDF0 - __STACKSIZE__;
Added 'sim6502' and 'sim65C02' targets. The targets allow to run cc65 programs in the sim65 exection einvironment. As there are no "real" i/o facilities there's no need for header files. Paravirtualized entry points are mapped to $FFF0 ff. There's a large cc65 progam area from $0200-$FFEF. The binary format includes a one-byte header indicating the required execution environment: The value 0 means 6502 and the value 1 means 65C02. The load adress for the binary is fixed to $0200. Note: Running sim65C02 programs currently doesn't work bcause sim65 doesn't actually implement 65C02 opcodes.
2013-05-20 18:35:42 +00:00
}
SEGMENTS {
Renamed INITBSS to INIT and INIT to ONCE. The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name. Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
2016-03-06 20:26:22 +00:00
ZEROPAGE: load = ZP, type = zp;
EXEHDR: load = HEADER, type = ro;
Renamed RAM to MAIN for all disk based targets. The name RAM doesn't make much sense in general for a memeory area because i.e. the zero page is for sure RAM but is not part of the memory area named RAM. For disk based targets it makes sense to put the disk file more into focus and here MAIN means the main part of the file - in contrast to some header. Only for ROM based targets the name RAM is kept as it makes sense to focus on the difference between RAM and ROM.
2016-03-07 00:28:55 +00:00
STARTUP: load = MAIN, type = ro;
Consider the segment attributes 'define' and 'optional' mutually exclusive. In normal situations it isn't too useful to define symbols for optional segments as those symbols can't be presumed to be always present. I in fact suspect that most currently present combinations of 'define' and 'optional' aren't useful - apart form the overlay configurations of course.
2016-03-17 20:31:43 +00:00
LOWCODE: load = MAIN, type = ro, optional = yes;
ONCE: load = MAIN, type = ro, optional = yes;
Renamed RAM to MAIN for all disk based targets. The name RAM doesn't make much sense in general for a memeory area because i.e. the zero page is for sure RAM but is not part of the memory area named RAM. For disk based targets it makes sense to put the disk file more into focus and here MAIN means the main part of the file - in contrast to some header. Only for ROM based targets the name RAM is kept as it makes sense to focus on the difference between RAM and ROM.
2016-03-07 00:28:55 +00:00
CODE: load = MAIN, type = ro;
RODATA: load = MAIN, type = ro;
DATA: load = MAIN, type = rw;
Consider the segment attributes 'define' and 'optional' mutually exclusive. In normal situations it isn't too useful to define symbols for optional segments as those symbols can't be presumed to be always present. I in fact suspect that most currently present combinations of 'define' and 'optional' aren't useful - apart form the overlay configurations of course.
2016-03-17 20:31:43 +00:00
BSS: load = MAIN, type = bss, define = yes;
Added 'sim6502' and 'sim65C02' targets. The targets allow to run cc65 programs in the sim65 exection einvironment. As there are no "real" i/o facilities there's no need for header files. Paravirtualized entry points are mapped to $FFF0 ff. There's a large cc65 progam area from $0200-$FFEF. The binary format includes a one-byte header indicating the required execution environment: The value 0 means 6502 and the value 1 means 65C02. The load adress for the binary is fixed to $0200. Note: Running sim65C02 programs currently doesn't work bcause sim65 doesn't actually implement 65C02 opcodes.
2013-05-20 18:35:42 +00:00
}
FEATURES {
CONDES: type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__,
Renamed INITBSS to INIT and INIT to ONCE. The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name. Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
2016-03-06 20:26:22 +00:00
segment = ONCE;
Added 'sim6502' and 'sim65C02' targets. The targets allow to run cc65 programs in the sim65 exection einvironment. As there are no "real" i/o facilities there's no need for header files. Paravirtualized entry points are mapped to $FFF0 ff. There's a large cc65 progam area from $0200-$FFEF. The binary format includes a one-byte header indicating the required execution environment: The value 0 means 6502 and the value 1 means 65C02. The load adress for the binary is fixed to $0200. Note: Running sim65C02 programs currently doesn't work bcause sim65 doesn't actually implement 65C02 opcodes.
2013-05-20 18:35:42 +00:00
CONDES: type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__,
segment = RODATA;
CONDES: type = interruptor,
label = __INTERRUPTOR_TABLE__,
count = __INTERRUPTOR_COUNT__,
segment = RODATA,
import = __CALLIRQ__;
}
Reference in New Issue Copy Permalink