CPCTelera is a multi platform (Windows with Cygwin, OS X and Linux) development framework for creating Amstrad CPC games in C and also assembly programmers. Click to see the news of CPCTelera on Github.
Retro Game Asset Studio (RGAS) v1.1.1 by Lachlank is the next evolution of Amsprite (now defunct). Using .NET, you can create graphics, sound/music levels for Amstrad CPC, ZX Spectrum and Commodore 64.
The last version of the C compilator for PC Z88dk v1.99a is out since December 2015.
One of the new feature is the possibility to use the SDCC engine.
The library CPCRSLIB for the SDCC compiler has been update. It allows to program in C on PC for Amstrad CPC. The CPCRSLIB version for the Z88dk compiler is still from February2015.
This new version is smaller, faster and benefit from the new version (v3.5) of SDCC. There is a new scroll code.
Also you will find an interview of ESP Soft on RetroManiac and another interview of ESP Soft on Video Juegos Retro.
After iMPdraw (download link), here is a new version of the Claudia Converter utility by Eliot.
it can load .BMP and .SCR created with the ConvIMG CPC utility, to show and modify them with the zoom tool. It manages fullscreen and CPC+ palette.
Symbos v3.0 beta is available, with ethernet network support.
Lachlank (author of Retro Game Asset Studio) just showed a preview of Minecraft for Amstrad CPC : Amscraft on Youtube.
It is written mainly in C using SDCC and the framwework CPCTelera, but with assembler to draw blocks. He is looking for help (music for example).
CPCTelera is a multi platform (Windows with Cygwin, OS X and Linux) development framework for creating Amstrad CPC games in C and also assembly programmers. For all features check CPCWiki, for short :
Low-level programming API fonctionnalitiesProject creation, management and integrated build system with tools (SDCC compilator...)
autoring tools and command line tools for format conversions (Arkos Tracker, RGAS...)
Retro Game Asset Studio (RGAS) by Lachlank is the next evolution of Amsprite (now defunct). Using .NET, you can create graphics, sound/music levels for Amstrad CPC, ZX Spectrum and Commodore 64.
A new release candidate of the ANSI-C compiler SDCC v3.5.0 is available for download.
Prodatron is working on network support for SymbOS avec with Wiznet W5100 ethernet controller (used on MSX and ZX SPectrum). There is also a W5100 project for the Amstrad CPC.
SymbOS is already able to load a web page, full TCP/IP support done. Still lacking UDP support to be able to use DNS and DHCP.
After the first Athanor, Eric Safar is working on Athanor 2 this time with bitmaps graphics. You can already see a WIP screenshot of the game on CPCRulez (see source below).
The Elan Enterprise is a new computer which can use Symbos. See the youtube video about this subject made during the Nijmegen MSX fair 2015.
A new version of Puzznic is available for Amstrad CPC+ thanks to Arnoldemu and BDCIron.
This version runs on GX4000. Instead of pressing R for menu, press pause. Also, an update to the "boot" process, the new overscan title screen now fades in and out, and a CPC+ palette is used.
The following lines are directly taken from the Amstrad CPC Contiki port on Github.
Contiki is a small operating system for embedded devices. While version 2 of the system is designed to run on embedded devices and has an IP and IPv6 stack as the main feature, the 1.x version of the system is better known for being ported to several 8-bit and 16-bit home computers.
Contiki 1.x features a GUI, dynamic loading of executables with runtime relocation, and a cooperative multitasking event-driven kernel. It also includes an IPv4 network stack and a few other things.
This fork is focused on improving the Amstrad CPC port of Contiki. This version was done by Kevin Thacker, but he didn't get it much further than showing the desktop. At the time, problems with the SDCC compiler and lack of proper optimization support led to a Contiki kernel too big and slow to be useful for serious use.
Fast forward some years, and SDCC has improved a lot. While it's still not very good at generating fast code, at least the size is down a bit and we now can run several programs without running out of memory. The linker scripts you will find here were modified to work properly with the current version of SDCC.
However, the dynamic relocatable executables are generated with a patched version of the SDCC linker, as the existing linker doesn't allow output in a suitable format.
Compared to the binaries released by Kevin Thacker, this version has much improved drawing routines. While still using the CPC firmware, the following changes allow for a much better experience :
You will need a patched version of SDCC. The linker was modified to generate relocation information, so the PRG executables can be loaded anywhere in memory and relocated at runtime before starting them. Running Contiki without that on the CPC would be much less interesting, because it is nearly impossible to write position independant z80 code.
A patch for SDCC 3.4.1 (from the current SVN sources) is provided. Get the sources using SVN or a nightly snapshot and apply the patch, then configure SDCC as usual.
You can still use the generated version of SDCC for other projects. The only difference is the addition of the -h flag to the linker. When this flag is set, executables are generated with relocation information.
You will also need cpcgs from the cpctools project.
Once the patched SDCC is installed, the process is rather simple :
cd contiki-cpc make clean make cpc make programs
This will generate a dsk image with contiki and the various programs.
Be careful to always do things in this order. The "cpc" target compiles the contiki core, and generate a defines file which is then used to have the apps call contiki routines.
However, when contiki is recompiled, stuff move in memory and all programs must be recompiled. This means you should always do a "make clean", until the dependencies are properly defined in the makefiles.
Boot your CPC or emulator and insert the disk in drive A (drive B is currently not supported). Then from the BASIC prompt type
run"contiki
The Contiki desktop will start, and will load the "Welcome" program which shows a window with some hints about how to use the system. Once there, you can :
Using either Directory or the "Run program" menu, you can start more applications, such as the calculator, the command line shel, the about box, etc. You can start multiple instances of each application, and navigate between their windows using the "Desktop" menu.
This port of Contiki is running fairly well, but we can make it more awesome !
Contiki currently relies on the CPC firmware for screen drawing and on AMSDOS for disc access. It runs entirely in the 64K base memory and doesn't use the banks or other expansion ROMs.
Contiki uses the space usually reserved to BASIC, from &100 to &3700, for its kernel. Since the Firmware and AMSDOS reserve all memory from &A700 up, this leaves about 28K of free RAM for applications. Not bad, but we can do better.
The screen driver is using the standard "conio" driver from Contiki. This is a textmode based driver which is easily portable between different terminal types. However, the interface of this driver with the CPC firmware results in rather slow screen drawing. The main reason is that some operations (such as erasing or scrolling part of the screen) are done character by character, instead of using the firmware functions which are much faster. Moreover, the portable conio code is written in C, and replacing it with an assembler version would provide another speed boost.
Some extra features such as bitmap icons, a custom character set and more can be implemented here.
We can put Contiki in bank C7 and map it in C1 mode. This would free all the low memory for apps. When calling the firmware, we can either use "far calls" so the bank can be unmapped while drawing, or use mode C3 and tell the firmware to draw at address 4000.
Note that the firmware calls are designed not to take direct memory pointers most of the time (eg you can print a single character, not a whole string) to make such schemes workable: The firmware would never need to directly access application memory in the range 4000-7fff. This would leave about 42K of RAM free for apps.
The next step is to completely remove the dependency on the firmware, and instead write our own screen drawing routines. A 4x8 or 6x8 font could be used, as the "80 column" version of Contiki for C64 is doing.
This could further speedup the screen display and allow for a nicer look.
A nice feature on the CPC is the ability to allocate 32K of RAM for the display and have a quite high resolution screen (380x272 or so). However, with the scheme exposed above this would lead to having only 32K of RAM free for applications.
To avoid this, we would run Contiki in C2 banking mode (all memory is mapped in banks) and have the application heap there. Contiki would still be in bank C7 leaving 48K of RAM for apps. When drawing to the screen is needed, Contiki can switch to mode C1 or C3 to access the main memory. A scheme similar to the one used by the firmware needs to be used here: the screen drawing routines must not do direct access to applications.
Pages 0 and 1 in main RAM would be used for the screen. Page 2 will have the screen drawing code. Page 3 can be used for the filesystem, and use the C4-C7 mapping mode to access the banks. When using these modes, converting a pointer to page number + pointer in 4000-7fff is easy. It may be a good idea to tweak malloc so it never allocates a chunk that crosses two banks. But that would mean we can't load apps bigger than 16K. So the disk system will probably have to figure out how to handle allocations that spans two or more banks.
Going even further, Contiki should all be in main RAM, and leave the banks almost completely free for apps. This would need to use an RST (far call or so) to call Contiki methods from apps. Can SDCC handle this? We may need to generate syscall inlines or maybe we can do dirty tricks using the peephole to replace "CALL address" with "RST farcall ; dw address". This could leave 63+K of RAM for apps, and 32K of RAM for Contiki + screen drawing + FS. If space is scarce, it's probably time we try putting Contiki in one or two ROMs instead.
This is similar to the scheme used by CP/M+.
The amstrad PCW has a similar, but more flexible, RAM bank system. However, it comes with 256 or 512K of memory, and we must support this!. This means reworking Contiki to handle apps in the different banks, which is not an easy task and may need compiler specific support. But then again, it could be useful for a Thomson MO6/TO8 port...
Notepad++ is a well known text editor on PC. Thanks to Syx, there is now a language file to add Z80 syntax highlighting for notepad++.
The Computer History Museum let you download 4 versions of CP/M for a non commercial use : v1.1 (1975), v1.3 (1976), v1.4 (1978) and v2.0 (1979), but it was v2.2 which was available for Amstrad CPC.
Gary Kildall, the creator of CP/M is sadly not anymore with us since 1994.
For more news, Go to home page