2017-12-06 23:23:30 +00:00
# Target platforms
2018-03-03 00:21:57 +00:00
Currently, Millfork supports creating disk- or tape-based programs for Commodore, Apple and Atari 8-bit computers,
2017-12-06 23:23:30 +00:00
but it may be expanded to support other 6502-based platforms in the future.
## Supported platforms
The following platforms are currently supported:
* `c64` – Commodore 64
2018-03-03 20:41:49 +00:00
* `c64_scpu` – Commodore 64 with SuperCPU in emulation mode
* `c64_scpu16` – Commodore 64 with SuperCPU in native, 16-bit mode (very buggy)
2018-03-03 00:21:57 +00:00
2017-12-06 23:23:30 +00:00
* `c16` – Commodore 16
* `plus4` – Commodore Plus/4
* `vic20` – Commodore VIC-20 without memory expansion
* `vic20_3k` – Commodore VIC-20 with 3K memory expansion
* `vic20_8k` – Commodore VIC-20 with 8K or 16K memory expansion
* `c128` – Commodore 128 in its native mode
* `pet` – Commodore PET
2018-03-15 22:46:16 +00:00
* `nes_small` – a tiny 32K PRGROM + 8K CHRROM Famicom/NES program
For more complex programs, you need to create your own "platform" definition.
Read [the NES programming guide ](./famicom-programming-guide.md ) for more info.
2017-12-06 23:23:30 +00:00
* `a8` – Atari 8-bit computers
2018-01-23 12:37:03 +00:00
* `apple2` – Apple II+/IIe/Enhanced IIe
2017-12-06 23:23:30 +00:00
The primary and most tested platform is Commodore 64.
2018-03-15 22:46:16 +00:00
Currently, targets that assume that the program will be loaded from disk or tape are better tested.
Cartridge targets may exhibit unexpected bugs.
2017-12-06 23:23:30 +00:00
2018-01-23 12:37:03 +00:00
### A note about Apple II
2018-02-27 12:26:56 +00:00
Apple II variants other than II+/IIe/Enhanced IIe are untested;
this includes the original II, IIc and IIc+, but also later compatible computers (Apple III and IIgs).
2018-01-23 12:37:03 +00:00
They may or may not work.
The compiler output is a raw machine code file, which then has to be put on a disk.
You can do it using [CiderPress ](http://a2ciderpress.com/ ),
[AppleCommander ](https://applecommander.github.io/ ),
or some other tool.
The file has to be loaded from $0C00. An example how to put such file onto a disk using AppleCommander:
java -jar AppleCommander-1.3.5.jar -p disk_image.dsk FILENAME B 0xc00 < compiler_output.a2
Creating a bootable disk is beyond the scope of this document.
2017-12-06 23:23:30 +00:00
## Adding a custom platform
Every platform is defined in an `.ini` file with an appropriate name.
#### `[compilation]` section
* `arch` – CPU architecture. It defines which instructions are available. Available values:
2018-03-03 00:21:57 +00:00
* `nmos` (original 6502)
* `strict` (NMOS without illegal instructions)
* `ricoh` (Ricoh 2A03/2A07, NMOS without decimal mode)
2017-12-06 23:23:30 +00:00
2018-03-03 00:21:57 +00:00
* `strictricoh` (Ricoh 2A03/2A07 without illegal instructions)
2017-12-06 23:23:30 +00:00
2018-03-03 00:21:57 +00:00
* `cmos` (WDC 65C02 or 65SC02)
2017-12-06 23:23:30 +00:00
2018-03-03 00:21:57 +00:00
* `65ce02` (CSG 65CE02; experimental)
2017-12-06 23:23:30 +00:00
2018-03-03 00:21:57 +00:00
* `huc6280` (Hudson HuC6280; experimental)
* `65816` (WDC 65816/65802; experimental; currently only programs that use only 16-bit addressing are supported)
2017-12-06 23:23:30 +00:00
* `modules` – comma-separated list of modules that will be automatically imported
* other compilation options (they can be overridden using commandline options):
* `emit_illegals` – whether the compiler should emit illegal instructions, default `false`
2018-03-03 00:21:57 +00:00
* `emit_cmos` – whether the compiler should emit CMOS instructions, default is `true` on compatible processors and `false` elsewhere
* `emit_65816` – which 65816 instructions should the compiler emit, either `no` , `emulation` or `native`
2017-12-06 23:23:30 +00:00
* `decimal_mode` – whether the compiler should emit decimal instructions, default is `false` on `ricoh` and `strictricoh` and `true` elsewhere
* `ro_arrays` – whether the compiler should warn upon array writes, default is `false`
2018-03-03 00:21:57 +00:00
* `prevent_jmp_indirect_bug` – whether the compiler should try to avoid the indirect JMP bug,
default is `false` on 65C02-compatible processors and `true` elsewhere
2018-03-15 22:46:16 +00:00
* `compact_dispatch_params` – whether parameter values in return dispatch statements may overlap other objects, default is `true`
This may cause problems if the parameter table is stored next to a hardware register that has side effects when reading.
2017-12-06 23:23:30 +00:00
#### `[allocation]` section
* `zp_pointers` – either a list of comma separated zeropage addresses that can be used by the program as zeropage pointers, or `all` for all. Each value should be the address of the first of two free bytes in the zeropage.
2018-03-15 22:09:19 +00:00
* `segments` – a comma-separated list of segment names.
A segment named `default` is always required.
Default: `default` . In all options below, `NAME` refers to a segment name.
* `default_code_segment` – the default segment for code and initialized arrays.
Note that the default segment for uninitialized arrays and variables is always `default` .
Default: `default`
* `segment_NAME_start` – the first address used for automatic allocation in the segment.
Note that the `default` segment shouldn't start before $200, as the $0-$1FF range is reserved for the zeropage and the stack.
The `main` function will be placed as close to the beginning of its segment as possible, but not necessarily at `segment_NAME_start`
* `segment_NAME_end` – the last address in the segment
2017-12-06 23:23:30 +00:00
2018-03-15 22:09:19 +00:00
* `segment_NAME_codeend` – the last address in the segment for code and initialized arrays.
Only uninitialized variables are allowed between `segment_NAME_codeend` and `segment_NAME_end` .
Default: the same as `segment_NAME_end` .
2017-12-06 23:23:30 +00:00
2018-03-15 22:09:19 +00:00
* `segment_NAME_datastart` – the first address used for non-zeropage variables, or `after_code` if the variables should be allocated after the code.
Default: `after_code` .
2017-12-06 23:23:30 +00:00
#### `[output]` section
2018-03-15 22:09:19 +00:00
* `style` – how multi-segment programs should be output:
* `single` – output a single file, based mostly, but not necessarily only on data in the `default` segment (the default)
* `per_segment` – generate a separate file with each segment
2017-12-06 23:23:30 +00:00
* `format` – output file format; a comma-separated list of tokens:
* literal byte values
2018-03-15 22:09:19 +00:00
* `startaddr` – little-endian 16-bit address of the first used byte of the compiled output (not necessarily the segment start)
2017-12-06 23:23:30 +00:00
2018-03-15 22:09:19 +00:00
* `endaddr` – little-endian 16-bit address of the last used byte of the compiled output (usually not the segment end)
2017-12-06 23:23:30 +00:00
* `allocated` – all used bytes
* `<addr>:<addr>` - inclusive range of bytes
2018-03-15 22:09:19 +00:00
* `<segment>:<addr>:<addr>` - inclusive range of bytes in a given segment
2017-12-06 23:23:30 +00:00
* `extension` – target file extension, with or without the dot