You can download a linux virtual machine by Francisco Gallego to develop Amstrad CPC programs including :

• CPCTelera 1.5/dev
• RVM
• WinAPE
• Visual Studio Code
• Terminator
• Gimp

Turbo Rascal SE (TRSE) v0.14 is out. It's a complete suite (IDE, compiler, programming language, image sprite level resource editor) intended for developing games/demos for 8 / 16-bit line of computers, with a focus on the MOS 6502, the Motorola 68000, the (GB)Z80 and the X86. TRSE currently supports application development for the C64, C128, VIC-20, PLUS4, NES, Gameboy, PET, ZX Spectrum, TIKI 100, Amstrad CPC 464, Atari 2600, 8086AT, Amiga 500 and the Atari ST 520 (complete list here). With the benefits of a modern IDE (error messages, code completion, syntax highlighting etc) and a bunch of fast built-in tools, it has never been easier to program for your favorite obsolete system !

Join TRSE on Facebook !

PunyInform v3.4 by Fredrik Ramsberg and Johan Berntsson is a library written in Inform 6 to create adventure game (pure text, no graphic support contrary to DAAD) using the Z-machine virtual machine which will run on 8bit computers (or more recent computers too). PunyInform has a parser, knowing of common verbs and a framework to write adventure games.

PunyInform is based on the Inform 6 library written by Graham Nelson. Its goal is to make easily adventure games in Inform 6, with a manual describing the differences between the official library and PunyInform..

Games using PunyInform can be compiled in z3, z5 and z8 format (z3 being the best format for 8bit computers, other formats have more features). Compared to the Inform 6 library, it means that there is no support for the Glulx virtual machine but z3 format is important as Inform 6 doesnt support it.

To compile games written with PunyInform, you should use the Inform 6 compiler maintained by David Kinder. Binaries are available on if-archive. PunyInform needs Inform v6.35 (or more).

They are tutorials to write adventure game with PunyInform (end of the page) and all the documentation including a 8 page cheat sheet (quick reference)..

To try your game after compilation, you can use WinFrotz by David Kinder, to create map easily you can use Trizbort.

And finally, to create an Amstrad CPC and PCW disk image, you will have to use the Puddle BuildTools.

The Quigs IDE is a suite of tools and editors to help developers create applications and other media for SymbOS.

Its creator and developer TrebMint aka Rob Buckley started to develop it at the end of 2004, when the SymbOS project has been continued. Together with the appearance of the SYMBiFACE in 2004 Quigs (ex-SymStudio) made the first HD-based full screen videos possible ever seen on CPC. With Quigs you can create forms, code, graphics and even video and export it to the CPC, MSX, PCW and Elan Enterprise version of SymbOS.

To resume, Quigs is a :

• Powerful form construction kit
• Code editor and assembler/compiler
• Graphic and video manager
• HTML and Richtext converter

in a comfortable PC-based integrated development environment!

There is an updated documentation in english of Symbos 3.1.

Tetris DotBAS is the latest WIP project by Francesc ALCAUCER after these two programs also written in Locomotive Basic :

• CPCRetroDev 2020 : CPC Invaders, updated less than a month ago
• CPCRetroDev 2021 : Wrecking Ball (breakout style game)

The version 3 of the english adventure game Tristam Island by Hugo Labrande is available for 3,99 dollars (25% cheaper starting 20th december). The demo version is limited to the first chapter of the game for a game time estimated to 1 to 1h30 hour which will let you discover the game before buying it if you are interested at this low price.

This adventure game is using the framework used by Infocom's games, the Z-Machine, which was reversed-engineered and documented in the 90s and implemented on dozens of platforms. This is how "Tristam Island" is able to be released on 36 computers (8, 16, 32 and 64 bits), including the Amstrad CPC and PCW. The game uses a library optimized for speed and size, PunyInform by Fredrik Rasmberg and Johan Berntsson.

A french version will be available this coming monday 20th december 2021 with as usual a french demo version.

If you buy either the english of french version, Itch.IO cannot permit to get the other version freely. But with the low price you can buy both : a traduction needs a lot of work and all work merits some payment. But Hugo Labrande will give you a key of the version you didnt buy if you ask him.

PunyInform v3.3 by Fredrik Ramsberg and Johan Berntsson is a library written in Inform 6 to create adventure game (pure text, no graphic support contrary to DAAD) using the Z-machine virtual machine which will run on 8bit computers (or more recent computers too). PunyInform has a parser, knowing of common verbs and a framework to write adventure games.

PunyInform is based on the Inform 6 library written by Graham Nelson. Its goal is to make easily adventure games in Inform 6, with a manual describing the differences between the official library and PunyInform..

Games using PunyInform can be compiled in z3, z5 and z8 format (z3 being the best format for 8bit computers, other formats have more features). Compared to the Inform 6 library, it means that there is no support for the Glulx virtual machine but z3 format is important as Inform 6 doesnt support it.

To compile games written with PunyInform, you should use the Inform 6 compiler maintained by David Kinder. Binaries are available on if-archive. PunyInform needs Inform v6.35 (or more).

They are tutorials to write adventure game with PunyInform (end of the page) and all the documentation including a 8 page cheat sheet (quick reference)..

To try your game after compilation, you can use WinFrotz by David Kinder, to create map easily you can use Trizbort.

And finally, to create an Amstrad CPC and PCW disk image, you will have to use the Puddle BuildTools.

Uto has written a tutorial to write adventure games with DAAD. This tutorial has been translated in french by Hugo Labrande who is the author of the game l'Ile de Tristam actually in english but soon with a french version.

Reidrac (Juan Martinez) is actually working on two projects : a RPG (Ultima like) and Hyperdrive which is a shoot them up, which reminds me of of the excellent Light Force.

You can check Reidrac's Twitter for more informations too.

I invite you to list the last posts of Reidrac's blog about several subjects including to create the games with cartridges in mind, thanks to the Plus2CPC, upcoming Play2CPC, DES and Dandanator.

CPC Bullet is a game for CPCRetroDev 2021 contest, but which couldn't be accounted due to a delay in time limit for . It is programmed by Cyrille Gouret, music by Mr Lou and graphism by Titan.

You can download the WIP v2 of CPC Bullet knowing that an enhanced v3 will come (gameplay, graphism).

Gamemplay is simple, eliminate your adversary, without shooting yourself due to a bad ricochet.

A video is available of CPC Bullet on the Amstradiens channel.

PunyInform v3.2 by Fredrik Ramsberg and Johan Berntsson is a library written in Inform 6 to create adventure game (pure text, no graphic support contrary to DAAD) using the Z-machine virtual machine which will run on 8bit computers (or more recent computers too). PunyInform has a parser, knowing of common verbs and a framework to write adventure games.

PunyInform is based on the Inform 6 library written by Graham Nelson. Its goal is to make easily adventure games in Inform 6, with a manual describing the differences between the official library and PunyInform..

Games using PunyInform can be compiled in z3, z5 and z8 format (z3 being the best format for 8bit computers, other formats have more features). Compared to the Inform 6 library, it means that there is no support for the Glulx virtual machine but z3 format is important as Inform 6 doesnt support it.

To compile games written with PunyInform, you should use the Inform 6 compiler maintained by David Kinder. Binaries are available on if-archive. PunyInform needs Inform v6.35 (or more).

They are tutorials to write adventure game with PunyInform (end of the page) and all the documentation including a 8 page cheat sheet (quick reference)..

To try your game after compilation, you can use WinFrotz by David Kinder, to create map easily you can use Trizbort.

And finally, to create an Amstrad CPC and PCW disk image, you will have to use the Puddle BuildTools.

Announced by 64Nops, the Benediction Coding partie #1 organized by Eliot took place last week-end. You can read the report and see the photos.

This article by Krusty on 64Nops is a reflexion on Z80 assemblers for programming for an Amstrad CPC. I know nothing of Z80 assembly, but I found this article interesting to read (english).

Krusty (Benediction) is developping at the moment Benediction cross ASseMbler (BASM) which you can get in his github depot.

I will let Krusty present himself hit utility : these last months, I have worked on the Benediction cross ASseMbler that will be used in our next production.I have not yet tested it in real-world conditions, so ATM I have truly no idea of its efficiency/usability.

I write this message to let anyone give it some try and provide me feedback to fix potential bugs and eventually bring more features for its real official release.I guess the official release will be accompanied by a graphic version of basm for those that are not yet ready to use command line tools.

Its aim is not to replace rasm that is a really fast and good assembler. But it can be used in contexts where rasm cannot play. BTW it is not 100%compatible with rasm code.

Of course, there is no documentation ready yet, but you can get most of its possibilities in the files named good_xxx.asm in this directory of the github depot.

Among what is not (yet) available for rasm you can check the section, basic, or iterate examples.

Note that basm uses two assembling passes by default, but can stop at the first pass if there is no need to do another one or add additional ones if necessary (which makes the ifused example compatible with basm but not rasm).

Richard Aplin is the coder of the Amstrad CPC port (1989) of the arcade game Shinobi (1987). While programming it, he searched for two weeks a rare bug of Shinobi, which he is writing about it on Twitter. With his agreement, here is all the text and screens present on Twitter (screens coming a bit later : more work to do).

Back in the days of 8-bit micros, in this case the Amstrad CPC (a popular - in Europe - Z80-based home computer). I worked for a games company, I was doing a conversion [i.e. rewrite] of Sega's "Shinobi" arcade machine onto this machine.

There were all sorts of geeky, tweaky technical tricks to make it run fast and look nice (coded in assembly language), and all went well, game turned out pretty nice, ran fast and played pretty well, until one day, when nearly done, play testers reported that it occasionally - crashed on one level. Boom! Reset. It was really hard to reproduce.

Nobody could come up with anything they actually _did_ to make it crash (or not); was about one in ~20 times(IIRC), when fighting a boss.

I had nothing fancy like a logic analyzer or in-circuit-emulator or other hardware debugging tools, just a regular retail computer. So it just crashed, once in a while, when playing one specific part of the game.

Sure, just some coding bug, like any other, not uncommon. But WHERE and WHY and HOW!? ..and why so hard to reproduce? You could play for hours and no problem, but just when it seemed like it was a ghost or maybe fixed for no known reason.... BOOM reset.

This went ON and ON and I was utterly mystified. I just could _not_ induce this bug to happen more often [the key to find/fixing it], no matter what I tried, I could not find even a way to reproduce reliably, let alone the root cause.

I started doing stuff like checksumming the RAM every frame, looking for some sort of random corruption, putting all sorts of checks in there that slowed it down to a crawl, and still nothing. The bug seemingly came and went as it pleased, never in quite the same place.

Until one day I got lucky. I caught it in the act! One single byte in the middle of my program code got trashed - and this time I caught it _before_ the whole thing blew up. But how?! What on earth was causing this? [OH for a hardware logic analyzer !

Finally, _finally_, after probably two weeks of solid bug-hunting and hair-tearing I found it.

So back in those days, it was customary for the game's music to be written by someone else, and provided as a binary blob of code plus data (e.g. 4Kbytes) that you would just call once a frame, and it took care of controlling the sound chip and playing whatever music tracks.

And it turned out that the music player (I didn't have source code) had a bug in it. Not a big bug. A teeeeeny little bug. It didn't audibly affect the music at all, but one _single_ note, on one channel, in one of the tunes on one of the levels, used a wrong data byte.

And normally, when that single duff musical note played, nothing bad happened, it was a fairly harmless bug, however it caused music player to read wrong byte of RAM; not just off by one byte, but off by tens of KBytes... in fact, it ended up reading a byte of the display ram.

If I recall correctly, it ended up - at that instant - reading a single byte of the display right around where this green circle is, in the upper left corner.

And when that single bad musical note in the tune played - IF the top bit (and only the top bit) of that pixel was a 1, it would then take that as a memory address ELSEWHERE in RAM and increment that location which corrupted a single byte inside of my program code, leading to a subsequent - but not quite immediate; a couple of seconds later, when a baddie was decided to shoot at you - crash.

This was a 2D scrolling game of course, so you were constantly jumping around and doing stuff fighting ninjas- the crash only happened if ONE pixel of the display was a certain color at the instant that one single note of ONE background tune played, and it wasn't in my code.

I vividly remember finally discovering the root cause (disassembling and patching the music player, and finally catching it 'in the act', and figuring out the long chain of events..) .. To this day I have never had a bug as hard as that one.. was SO rewarding to find.

I've had a bunch of equally obscure bugs in the decades since then, but the tools got so much better - protected memory, logic analyzers, CPUs that don't just explode on contact with bad data - nothing has ever been as difficult to track down as that one. Was a great lesson which is that if you persevere for long enough you will win in the end against a computer - bugs can't hide forever. Ever since then I've known it's just a matter of time, and patience. Nowadays I relish a good bug, I rub my hands and chuckle - the game is ON! ;-).