Difference between revisions of "Programming:Cross Development"
(→Linux: sorted alphabetically, added CPCSDK) |
(→Cross compilers: ugbasic) |
||
(25 intermediate revisions by 9 users not shown) | |||
Line 1: | Line 1: | ||
= Introduction = | = Introduction = | ||
− | Cross development is a development method where you use another machine (the host) to develop programs for the CPC (target). This is interesting because you can make a big program | + | Cross development is a development method where you use another machine (the host) to develop programs for the CPC (target). This is interesting because you can make a big program which sourcecode does not even fit on the CPC ram. |
− | The main drawback is that transferring the compiled code to the CPC can be quite difficult. But there are pretty good emulators | + | The main drawback is that transferring the compiled code to the CPC can be quite difficult. But there are pretty good emulators which you can use for testing. |
Once you have your binary file you have two choices depending on if the game will be for [[Datacorder|cassette]] or [[Disk drives|disc]]. | Once you have your binary file you have two choices depending on if the game will be for [[Datacorder|cassette]] or [[Disk drives|disc]]. | ||
Line 11: | Line 11: | ||
*[[Atari|Atari ST]] was a common 16 bit computer actually used in cross development of games on CPC. | *[[Atari|Atari ST]] was a common 16 bit computer actually used in cross development of games on CPC. | ||
− | Of course | + | Of course nowadays cross development use far more powerful modern computers. |
*[[ZX Spectrum]] was also a source of cross development...er... let's better say [[Speccy Port|Gross Development]] indeed. | *[[ZX Spectrum]] was also a source of cross development...er... let's better say [[Speccy Port|Gross Development]] indeed. | ||
= Tools needed for cross development = | = Tools needed for cross development = | ||
+ | |||
+ | == Integrated toolchains == | ||
+ | |||
+ | An integrated cross-development toolchain is a time saver for development as it automates all necessary steps from a full set of source materials (source code, graphics, music, parameters in whatever format is practical for editing, etc) to one or several formats ready to run on the target machines. It also sometimes includes automatically launching or notifying an emulator or target device. See e.g. [http://en.wikipedia.org/wiki/Build_automation#Advantages Build Automation on wikipedia]. | ||
+ | |||
+ | Such a design has several advantage: | ||
+ | * allows the usage of any text/graphic editor of modern platforms | ||
+ | * you can change anything in one or more source files and you get an updated build quickly without error-prone manual steps | ||
+ | * allows arbitrary transform or generation of intermediary files (code or data). | ||
+ | * makes easy to have specific builds (e.g. for automated tests like to check if a different compiler produces correct code, variant build for slightly different targets) | ||
+ | * since most material are text files or small independent files, it benefits hugely from modern tools for revision control like [http://en.wikipedia.org/wiki/Git_%28software%29 Git] which makes sharing and merging code between developers much easier, increasing the time saved. | ||
+ | |||
+ | An ideal toolchain does not force its user into specific ways of doing things but is flexible enough to let the user adjust for whatever specific needs (use different languages, compilers, linkers, etc). Along with a properly designed and structured source tree, this makes projects less dependent on specific tools used to build them, and be more resilient to [http://en.wikipedia.org/wiki/Bit_rot bit rot] due to [http://en.wikipedia.org/wiki/Software_rot#Environment_change software build environment change]. | ||
+ | |||
+ | Please note that an integrated toolchain has little to do with anything visible on-screen. A good toolchain can be triggered by most flexible enough graphical environments and generally produces a text log of the work done. Nevertheless, the concept of toolchains is more natural to Linux/Unix way of thinking/doing things, and those environments are already full of reusable and combinable tools that ease the creation and maintenance of a toolchain. Windows users can generally use tools developed for Unix through the cygwin software adaptation layer but running a Linux distribution in a virtual machine may be more practical. | ||
+ | |||
+ | There are some attempts at creating toolchains targeting the CPC. | ||
+ | |||
+ | Active as of 2017-11: | ||
+ | |||
+ | * '''[[CPCtelera]]''' integrates an out-of-the-box preconfigured build system, along with a game development library and tools and extensive configuration. It is also multiplatform, working on Linux, OSX and Windows. CPCtelera is a fork of [https://github.com/cpcitor/cpc-dev-tool-chain cpc-dev-tool-chain] tuned for 2D-sprite-oriented productions and extensive documentation. ''Recommended for beginners.'' | ||
+ | * '''[https://github.com/cpcitor/cpc-dev-tool-chain cpc-dev-tool-chain]''' integrated C or ASM development toolchain for the Amstrad CPC platform (or emulator). '''Recommended for seasoned C programmers, Linux geeks, advanced users, general productions'''. Includes: | ||
+ | ** Designed for quick start on Linux (or similar) systems : '''get a copy, write a "hello_world.c", run "make dsk" and get a DSK ready to run into the emulator'''. On linux "make run" even runs the emulator! | ||
+ | ** Automatically downloads and compiles tools as needed, no interference with user account or global system, no administrator permission needed. | ||
+ | ** Tools include: | ||
+ | *** gfx2crtc (transform PNG into CPC screen data), | ||
+ | *** png2cpcsprite (turn PNG into binary data formatted as ASM source code ''with metadata including palette'', zero run-time overhead), | ||
+ | *** SDCC compiler, assembler and linker, | ||
+ | *** hex2bin, addhead (prepare CPC binaries with AMSDOS header), | ||
+ | *** cpcxfs and iDSK (prepare DSK disc image), | ||
+ | *** rasm (Roudoudou's assembler)'''. | ||
+ | *** 2cdt (transform CPC binary to tape image), | ||
+ | *** playtzx (transform tape image into audio file to play to your CPC), | ||
+ | *** caprice32 (emulator), | ||
+ | *** cpcec (emulator), | ||
+ | *** exomizer (high performance compressor, PC side), | ||
+ | *** deexo (Z80 run-time exomizer decompression), | ||
+ | ** Made for Linux, also works with Windows (via cygwin or similar), and probably Mac OS X. Most project+build-oriented features claims by CPCTelera comes from cpc-dev-tool-chain. | ||
+ | ** Call firmware routines from clean C code! [https://rawgit.com/cpcitor/cpc-dev-tool-chain/master/cpclib/cfwi/coverage.html advanced coverage of the CPC firmware] | ||
+ | ** Extensible projects structure based on GNU make | ||
+ | |||
+ | * Not an integrated toolchain, but a collection of tools that can be strung together to make one, including a DockerFile. Mentioned on [http://www.cpcwiki.eu/forum/off-topic/cpc-sdk-for-linuxunix/ CPC SDK for Linux/Unix]. Appears to have moved to https://github.com/cpcsdk | ||
+ | |||
+ | * 2012-11-12 [http://www.cpcwiki.eu/forum/programming/recommended-linux-cross-dev-tool-chain/ Recommended Linux cross-dev tool chain?] mentions a makefile-based toolchain targeting dsk images or tapes | ||
+ | * 2009-06-16 [http://www.cpcwiki.eu/forum/emulators/my-new-cross-development-kit/new/#new My new cross-development kit] explain what is basically a toolchain but link is broken as of 2013-01-08 | ||
== Linux == | == Linux == | ||
− | === | + | === Cartridge management === |
* [[buildcpr]] [http://www.cepece.info/amstrad/download/buildcpr.zip] | * [[buildcpr]] [http://www.cepece.info/amstrad/download/buildcpr.zip] | ||
=== Cross assemblers === | === Cross assemblers === | ||
+ | * [[basm|Benediction ASseMbler]] [https://cpcsdk.github.io/rust.cpclib/basm/] | ||
+ | * [[naken_asm]] [https://www.mikekohn.net/micro/naken_asm.php] | ||
+ | * [[pasmo]] | ||
+ | * [[RASM]] | ||
* [[SjasmPlus]] | * [[SjasmPlus]] | ||
* [[Sjasm|sjasm]] | * [[Sjasm|sjasm]] | ||
+ | * [[Z80asm]] [http://savannah.nongnu.org/projects/z80asm] | ||
* [[Zasm]] [http://sourceforge.net/projects/zasm] | * [[Zasm]] [http://sourceforge.net/projects/zasm] | ||
* [[ZMac]] | * [[ZMac]] | ||
* GNU Binutils for z80 (z80-unknown-coff platform) | * GNU Binutils for z80 (z80-unknown-coff platform) | ||
− | * [[ | + | |
+ | === Cross compilers === | ||
+ | * [[ZXBasic]] | ||
+ | * [[Turbo Rascal Syntax Error]] [http://turborascal.com] | ||
+ | * [[ugBASIC]] [https://ugbasic.iwashere.eu] | ||
=== Crunching === | === Crunching === | ||
Line 41: | Line 95: | ||
* [[CPCTools]] | * [[CPCTools]] | ||
− | * [[ | + | * [[iDSK]] |
+ | * [[cpcfs]] / [[cpcxfs]] | ||
* [[dsktools]] | * [[dsktools]] | ||
* [[cpmtools 2]] [http://www.moria.de/~michael/cpmtools/] | * [[cpmtools 2]] [http://www.moria.de/~michael/cpmtools/] | ||
Line 47: | Line 102: | ||
=== Editing === | === Editing === | ||
+ | * scite | ||
* pico | * pico | ||
* xemacs | * xemacs | ||
* [[How to use VIM for CrossDev|Vim]] | * [[How to use VIM for CrossDev|Vim]] | ||
+ | * pluma | ||
+ | * gedit | ||
=== Emulators === | === Emulators === | ||
− | * [[Arnold]] | + | * [[Arnold (Emulator)|Arnold]] |
* [[Caprice]] [http://sourceforge.net/projects/caprice32/] | * [[Caprice]] [http://sourceforge.net/projects/caprice32/] | ||
* [[cpcemu]] [http://www.cpc-emu.org/] | * [[cpcemu]] [http://www.cpc-emu.org/] | ||
Line 69: | Line 127: | ||
=== Useful scripts === | === Useful scripts === | ||
− | ==== | + | ==== Suppress header information of a file ==== |
<pre> | <pre> | ||
cat file_with_header | tail -c+129 > file_without_header | cat file_with_header | tail -c+129 > file_without_header | ||
Line 81: | Line 139: | ||
* a good emulator which can be integrated in other tools. (Ramlaid first try to change Caprice is a good start) | * a good emulator which can be integrated in other tools. (Ramlaid first try to change Caprice is a good start) | ||
* an integration of Ramlaid's tools with Nautilus | * an integration of Ramlaid's tools with Nautilus | ||
− | * ameliorations of Caprice in order to have | + | * ameliorations of Caprice in order to have similar functionalities than WinApe (disasm, asm, ...) |
* debug the libdsk which seems to work very bad on actual computers (writting fail a lot) | * debug the libdsk which seems to work very bad on actual computers (writting fail a lot) | ||
* a lot of macros, or libraries for SJASMPlus shared by people in order to share code | * a lot of macros, or libraries for SJASMPlus shared by people in order to share code | ||
Line 100: | Line 158: | ||
=== Cross Assemblers === | === Cross Assemblers === | ||
+ | |||
+ | * [[basm|Benediction ASseMbler]] [https://cpcsdk.github.io/rust.cpclib/basm/] | ||
+ | * [[naken_asm]] [https://www.mikekohn.net/micro/naken_asm.php] | ||
*[[Tasm|tasm]] | *[[Tasm|tasm]] | ||
*[[Pasmo|Pasmo]] | *[[Pasmo|Pasmo]] | ||
− | *[[ | + | *[[RASM]] |
− | + | ||
*[[WinApe|WinApe]]'s built in assembler | *[[WinApe|WinApe]]'s built in assembler | ||
+ | *[[ZMac|ZMac]] | ||
+ | *[http://little-bat.de/prog/ zasm] | ||
=== Cross compilers (C) === | === Cross compilers (C) === | ||
+ | |||
+ | Beginner warning: unless you want to rebuild an entire toolchain by hand, you probably don't want to just download a C cross-compiler alone. Most probably, what you're looking for is an [[#Integrated_toolchains|integrated toolchain]] instead. | ||
+ | |||
+ | For a C tutorial, see http://www.cpcmania.com/Docs/Programming/Programming.htm by Mochilote | ||
* [[Z88DK]] | * [[Z88DK]] | ||
− | * [[SDCC]] | + | * [[SDCC]], notably [[SDCC and CPC]] had hints and practical examples about the principles of writing in C for CPC. |
* [[PhrozenC]] | * [[PhrozenC]] | ||
+ | |||
+ | === Cross compilers (Java) === | ||
+ | |||
+ | WIP | ||
+ | |||
+ | * [[JavaGrinder]] | ||
+ | |||
+ | === Cross compilers (Pascal) === | ||
+ | |||
+ | * [[Turbo Rascal Syntax Error]] [http://turborascal.com] | ||
=== Graphics === | === Graphics === | ||
Line 143: | Line 219: | ||
* Then you can run the program on the emulator the same way as you would run it on a real CPC | * Then you can run the program on the emulator the same way as you would run it on a real CPC | ||
− | If your CPC has a 3.5" disc drive then the easiest method is to transfer the DSK to a 3.5" disc using | + | If your CPC has a 3.5" disc drive then the easiest method is to transfer the DSK to a 3.5" disc using a PC with a 3.5" drive (internal, not USB). |
− | + | * Then write the DSK to a 3.5" disc drive, using dsktools (Linux) or CPCDiskXP (Windows). | |
+ | * Put the disc into your CPC's 3.5" disc drive and type - |B: RUN "<gamename> | ||
== Snapshots == | == Snapshots == | ||
Line 153: | Line 230: | ||
== Web links == | == Web links == | ||
− | * [http://ramlaid.free.fr/Amstrad/English/crossDev.htm CPC Cross Development tools by Ramlaid] | + | * [http://ramlaid.free.fr/Amstrad/English/crossDev.htm CPC Cross Development tools by Ramlaid] (Link broken as 2012-01-08. If you can help, please update.) |
[[Category:Programming]] [[Category:CrossDev]] | [[Category:Programming]] [[Category:CrossDev]] |
Latest revision as of 07:53, 15 November 2023
Contents
Introduction
Cross development is a development method where you use another machine (the host) to develop programs for the CPC (target). This is interesting because you can make a big program which sourcecode does not even fit on the CPC ram.
The main drawback is that transferring the compiled code to the CPC can be quite difficult. But there are pretty good emulators which you can use for testing.
Once you have your binary file you have two choices depending on if the game will be for cassette or disc.
- Atari ST was a common 16 bit computer actually used in cross development of games on CPC.
Of course nowadays cross development use far more powerful modern computers.
- ZX Spectrum was also a source of cross development...er... let's better say Gross Development indeed.
Tools needed for cross development
Integrated toolchains
An integrated cross-development toolchain is a time saver for development as it automates all necessary steps from a full set of source materials (source code, graphics, music, parameters in whatever format is practical for editing, etc) to one or several formats ready to run on the target machines. It also sometimes includes automatically launching or notifying an emulator or target device. See e.g. Build Automation on wikipedia.
Such a design has several advantage:
- allows the usage of any text/graphic editor of modern platforms
- you can change anything in one or more source files and you get an updated build quickly without error-prone manual steps
- allows arbitrary transform or generation of intermediary files (code or data).
- makes easy to have specific builds (e.g. for automated tests like to check if a different compiler produces correct code, variant build for slightly different targets)
- since most material are text files or small independent files, it benefits hugely from modern tools for revision control like Git which makes sharing and merging code between developers much easier, increasing the time saved.
An ideal toolchain does not force its user into specific ways of doing things but is flexible enough to let the user adjust for whatever specific needs (use different languages, compilers, linkers, etc). Along with a properly designed and structured source tree, this makes projects less dependent on specific tools used to build them, and be more resilient to bit rot due to software build environment change.
Please note that an integrated toolchain has little to do with anything visible on-screen. A good toolchain can be triggered by most flexible enough graphical environments and generally produces a text log of the work done. Nevertheless, the concept of toolchains is more natural to Linux/Unix way of thinking/doing things, and those environments are already full of reusable and combinable tools that ease the creation and maintenance of a toolchain. Windows users can generally use tools developed for Unix through the cygwin software adaptation layer but running a Linux distribution in a virtual machine may be more practical.
There are some attempts at creating toolchains targeting the CPC.
Active as of 2017-11:
- CPCtelera integrates an out-of-the-box preconfigured build system, along with a game development library and tools and extensive configuration. It is also multiplatform, working on Linux, OSX and Windows. CPCtelera is a fork of cpc-dev-tool-chain tuned for 2D-sprite-oriented productions and extensive documentation. Recommended for beginners.
- cpc-dev-tool-chain integrated C or ASM development toolchain for the Amstrad CPC platform (or emulator). Recommended for seasoned C programmers, Linux geeks, advanced users, general productions. Includes:
- Designed for quick start on Linux (or similar) systems : get a copy, write a "hello_world.c", run "make dsk" and get a DSK ready to run into the emulator. On linux "make run" even runs the emulator!
- Automatically downloads and compiles tools as needed, no interference with user account or global system, no administrator permission needed.
- Tools include:
- gfx2crtc (transform PNG into CPC screen data),
- png2cpcsprite (turn PNG into binary data formatted as ASM source code with metadata including palette, zero run-time overhead),
- SDCC compiler, assembler and linker,
- hex2bin, addhead (prepare CPC binaries with AMSDOS header),
- cpcxfs and iDSK (prepare DSK disc image),
- rasm (Roudoudou's assembler).
- 2cdt (transform CPC binary to tape image),
- playtzx (transform tape image into audio file to play to your CPC),
- caprice32 (emulator),
- cpcec (emulator),
- exomizer (high performance compressor, PC side),
- deexo (Z80 run-time exomizer decompression),
- Made for Linux, also works with Windows (via cygwin or similar), and probably Mac OS X. Most project+build-oriented features claims by CPCTelera comes from cpc-dev-tool-chain.
- Call firmware routines from clean C code! advanced coverage of the CPC firmware
- Extensible projects structure based on GNU make
- Not an integrated toolchain, but a collection of tools that can be strung together to make one, including a DockerFile. Mentioned on CPC SDK for Linux/Unix. Appears to have moved to https://github.com/cpcsdk
- 2012-11-12 Recommended Linux cross-dev tool chain? mentions a makefile-based toolchain targeting dsk images or tapes
- 2009-06-16 My new cross-development kit explain what is basically a toolchain but link is broken as of 2013-01-08
Linux
Cartridge management
Cross assemblers
- Benediction ASseMbler [2]
- naken_asm [3]
- pasmo
- RASM
- SjasmPlus
- sjasm
- Z80asm [4]
- Zasm [5]
- ZMac
- GNU Binutils for z80 (z80-unknown-coff platform)
Cross compilers
Crunching
Disassemblers
Disc management
Editing
- scite
- pico
- xemacs
- Vim
- pluma
- gedit
Emulators
Tape management
Toolkits
Useful scripts
Suppress header information of a file
cat file_with_header | tail -c+129 > file_without_header
Needed Tools
These tools have to not require a lot of requirement and most of them must work in command line without GUI. This will allow to use them with Makefile scripts. They have to be fast too, it will be disappointing to wait more when doing CrossDev than when doing code on a real CPC. A good thing (like most of CPCTools) is to have a portable code which compile on most platforms.
- a good emulator which can be integrated in other tools. (Ramlaid first try to change Caprice is a good start)
- an integration of Ramlaid's tools with Nautilus
- ameliorations of Caprice in order to have similar functionalities than WinApe (disasm, asm, ...)
- debug the libdsk which seems to work very bad on actual computers (writting fail a lot)
- a lot of macros, or libraries for SJASMPlus shared by people in order to share code
- share a generic Makefile able to be use for build CPC project
- a lot of little command line utilities (could be add to CPCTools ?) really well done :
- graphics tools :
- convert images from PC to CPC, or CPC to PC (cf. tools based on ImageMagick or GD)
- equivalent of Anoine's FontCatcher
- 2 tools which work with BASIC :
- one for create BASIC AMSDOS files from ASCII or UTF-8 text files
- one for create ASCII or UTF-8 text files from BASIC AMSDOS files
- (this can already be done with manageDSK for files inside a DSK, maybe extract the code from there)
- data manipulation tools :
- ability to arrange data files for example modify bytes order in a picture file by using Gray code capabilities for changing line with modifying 1 bit
- graphics tools :
Windows
Cross Assemblers
Cross compilers (C)
Beginner warning: unless you want to rebuild an entire toolchain by hand, you probably don't want to just download a C cross-compiler alone. Most probably, what you're looking for is an integrated toolchain instead.
For a C tutorial, see http://www.cpcmania.com/Docs/Programming/Programming.htm by Mochilote
- Z88DK
- SDCC, notably SDCC and CPC had hints and practical examples about the principles of writing in C for CPC.
- PhrozenC
Cross compilers (Java)
WIP
Cross compilers (Pascal)
Graphics
- AMSprite - Sprite/Loading Screen Editor and graphics conversion tools
Sound
- WYZTracker - Music tracker / Sound effects editor
- Vortex Tracker
Testing on a real CPC
For cassette
- 2CDT to add the files to a Cassette Image File (CDT)
- Tape2WAV to convert the Cassette Image file (CDT) into a WAV file.
- Then you can run the program on the emulator the same way as you would run it on a real CPC, or
- Connect your CPC (CPC664 and CPC6128 have a cassette input) to the Line-Out output of your PC soundcard
- On the CPC type:
|TAPE:RUN"
- Start your WAV player
- Set the volume to maximum
- play the WAV file
- Wait for the program to load...
For disc
- Use CPCFS or CPCXFS to put the binary files into a Disk Image file (DSK)
- Then you can run the program on the emulator the same way as you would run it on a real CPC
If your CPC has a 3.5" disc drive then the easiest method is to transfer the DSK to a 3.5" disc using a PC with a 3.5" drive (internal, not USB).
- Then write the DSK to a 3.5" disc drive, using dsktools (Linux) or CPCDiskXP (Windows).
- Put the disc into your CPC's 3.5" disc drive and type - |B: RUN "<gamename>
Snapshots
The fastest way of testing your code on an emulator is by creating a snapshot. Use CPCSnapshot to insert your assembled code into a snapshot file. Then just load the snapshot file into the emulator. Windows users may also try WinAPE's integrated assembler which assembles the code directly into the emulated CPC's memory.
Web links
- CPC Cross Development tools by Ramlaid (Link broken as 2012-01-08. If you can help, please update.)