News about Amstrad CPC, PCW, Notepad NC100 NC150 NC200, PDA600 and also Amstrad PC




Roland Radio
Click here to listen to RolandRadio:



Network, XT-IDE, adlib, 512 Kb RAM, ISA slot for Amstrad PPC 640 (internal) by Retro Theory

-

Retro Theory is showing a photo of an internal card for Amstrad PPC 640 which is replacing the internal modem to add :

  • LAN ethernet
  • XT-IDE with SD card
  • adlib sound
  • 512 Kb de RAM (8 Kb granularity)
  • ISA slot



Benediction cross ASseMbler by Krusty targetting Amstrad CPC for windows, mac and linux

-

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



Using a PS/2 keyboard on an Amstrad PC XT (1512/1640/2086/3086)

-



Bug hunting on Shinobi for Amstrad CPC by Richard Aplin

-

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.




The Basic v1.1 ROM of the Amstrad CPC 6128 unassembled by Bread80

-

After the unassembling of the Amstrad CPC 6128 firmware, Bread80 has done the same for the Basic v1.1 ROM also for the CPC 6128. He is writing about it on Il en parle sur its web site and Twitter.

Why using a commercial compiler of the Amstrad CPC basic when you can update its speed directly ?



Siemb Chronicles: Arkos the Traitor for Amstrad CPC by ESP Soft was released in September 2021

-

ESP Soft has released the sequel of Game Over for Amstrad CPC Siemb Chronicles: Arkos the Traitor the 13th September 2021. It has 2 levels : the fall of Arkos and Escape from Hypsis, it's a mix of platform, run and gun and shoot them up.

The game exists thanks to ESP Soft by the following people :

  • Artaburu (code)
  • Triste1942 (graphics)
  • McKlain (sound)
  • Litos (history, script)
  • Jesús Martínez del Vas (cover)
  • MiguelSky (ideas)
  • JGonza, Chemamstrad et BlackMores (tests)




DAAD Ready v0.5 by Uto to easily compile DAAD games as tape or disk for targeted computers

-

Si vous souhaitez créer un jeu d'aventure texte et/ou graphique alors DAAD est ce qu'il vous faut (PunyInform aussi mais sans graphiques, en pur texte).

DAAD permettant de cibler beaucoup d'ordinateurs, Uto a créé DAAD Ready qui vous permets de créer facilement des images cassettes ou disquette prêtes à l'emploi sur les ordinateurs supportés par DAAD.

Bien que DAAD ne supporte officiellement que l'anglais et l'espagnol, DAAD ready ajoute un support limité du portugais, allemand et français. Cela va permettre notamment d'avoir une version française de Tristam Island.

Vous pouvez télécharger DAAD Ready ici.




SDCC v4.1.0 (C programming for Amstrad CPC) on PC and MacOS

-

A new version of the ANSI-C compiler SDCC v4.1.0 is available since the 8th March 2021 for windows, linux and MacOS.



NOMWARS, an Amstrad CPC game written with 8BP v041 (and more)

-

Jose Javier Garcia Aranda has released a new version of NOMWARS (tape and disk) written with 8BP v41 (8bits de poder : 8bits of power), his RSX library to write Amstrad CPC games in basic and asm.

A physical edition of the game can be bought on Hobby Retro.

You can download 8bp on github.

You can also get SPEDIT v14, an utility to capture sprites from games or pictures made with an utility such as ConnvImgCPC, Martine...

And finally, he is working on a menu application for DES cartridges, to allow easy launching on games installed inside such a cartridge.




3DManiaks, an Amstrad CPC demo by the group Impact

-

3DManiaks par Impact est leur dernière production, une démo Amstrad CPC qui se laisse voir fort bien. Vous pouvez la télécharger sur Pouet ou sur CPCWiki. Vous pouvez également regarder 3DManiaks sur Youtube.

The démo has been written by :

  • Demoniak (code)
  • Kris (art)
  • CMP (design)
  • Mast/FtL (music)





CHR$(143) by Nicolas JEAN, a tribute to Amstrad CPC 464 "CHaRacter$" based games

-

CHR$(143) on Steam by Nicolas JEAN for 3,29 € is a game for windows being a tribute for the Amstrad CPC 464 (user-defined) "CHaRacter$" based games.

Guiding a small group of "agents", you will gradually discover a Lost World, the seemingly simple graphics of which conceal its hidden complexity...

You will learn to move in it, to understand its physical properties, to accumulate sufficient stocks of materials, to build structures, machines and vehicles, to engineer various types of power plants to fullfill your growing needs for energy, and to search, sometimes even in the fog of war, for the enemy that your destiny requires you to defeat...

72 built-in levels + unlockable User Level Editor and (experimental) unlockable LAN Multiplayer Mode.

You can see on Nicolas JEAN's Youtube some videos including ones about level 5 et 6 (spoiler alert).