Archives of Genesis8 Amstrad Page from 1999 to 2018 about miscellaenous subject

Soon 50 years of history for the Amstrad company, related in Retro Gamer magazine


The company Amstrad (Alan Michael Sugar TRADing) has been created the 8th December 1968. So at the end of this new year 2018, it will be 50 years of history, which are told in the last issue of the Retro Gamer magazine.

Retro Gamer magazine for the 50 years of history of the Amstrad company

8-bit memoirs issue 1 by Mr_Lou, author of Sort'em (Amstrad CPC game)


Mr_Lou is active on Amstrad CPC scene, he wrote the game Sort'Em in 2009 (LuBlu Entertainment), programmed with Z88dk and cpcrslib.

Today, he finished the first issue of his 8-Bit Memoirs, a free ebook of his personal 8bit experience (about for example the Philips Videopac G7000, the Amstrad CPC and the Amiga) with more than 5 hours of video, illustrations (by Marlene "BlueAngel" Johansen), screenshots... It's free, but you can buy the physical collector edition for 17 €.

Furniture sold by Amstrad with a CT-1 radio and a MP-3 analogic TV tuner


I just discovered on Amstrad.EU's facebook group that Amstrad sold a furniture with a bundled MP-3 analogic TV tuner and CT-1 radio. With the reference to X, the article is coming from the newspaper Amstrad 100%.

A quick internet search didnt permit to find other photos of this furniture, if you have any, I am interested.

Amstrad furniture for CPC, CT-1 and MP-3

One mug of coffee/tea a day ! But choose it wisely.


May I suggest you to choose this mug to drink your coffee or tea each morning ? 10 pieces only.

A nice image by Juanito Medina which you should take a look at


Juanito Medina has drawn a nice graphic which you really should take a look at. Hint, check the bottom, no, not the girl...

The story of Roland, the Amstrad CPC mascot by Edward on Youtube (french audio)


Edward ( is talking about the Amstrad CPC mascot : Roland in a french short video (about 7 minutes and 30 seconds).

A Colecovision remake of Rick Dangerous by two dangerous unknown people


Two unknown people going with the name of Fanoplusplus64k and TotOOnTheMoon have written a remake of Rick Dangerous for the game console Colecovision : Risky Rick in dangerous traps, already showed at the RGC 2015 and almost ready at 95% for the RGC 2016 at Meaux.

The next one I see programming on something else than an Amstrad CPC, will copy with his and and pen 1000 times the following words : I must only programm on my lovely Amstrad CPC.

Coming to cinema, the cartoon Agents super zéro (Mortadelo y Filemón contra Jimmy el cachondo


Buenos noche, Cómo está ? Me gusta Mortadelo y Filemón desde mi juventud, y usted ? Hello everyone, I like Mortadelo y Filemón since I am young, a spanish comics by Francisco Ibáñez. A cartoon Agents super zéro will be out on the 2nd november 2016.

It also exists as Amstrad CPC games with youtube longplay by Jgonza :

Celebrating the 25 Years of the Amstrad GX4000 by Xyphoe on Youtube


In this 25 minutes video, Xyphoe celebrates the 25 years Of the Amstrad GX4000 (released in 1990).

A fork of Contiki v1.x (an operating system) for Amstrad CPC by Pulkomandy


The following lines are directly taken from the Amstrad CPC Contiki port on Github.

Contiki's screenshot, an operating system ported on Amstrad CPC by Pulkomandy

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 :

  • Faster screen clearing using SCR FILL BOX
  • Various optimizations all over the place
  • A better looking color palette
  • Support for bitmap icons

How to build it - Requirements

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.

How to use it

Boot your CPC or emulator and insert the disk in drive A (drive B is currently not supported). Then from the BASIC prompt type


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 :

  • Navigate the menus (press F1 then use arrow keys)
  • Run the "Processes" program to see a list of running processes
  • Run the "Directory" program to list the disc contents

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 !

Current status

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.

Firmware-based CTK driver

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.

Make use of memory banks

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.

Remove dependencies on firmware

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.

Overscan display

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.

Even more free RAM !

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+.

An Amstrad PCW port

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...

Source :

twitter  facebook  

For more news, Go to home page