Saturday, 21 May 2022

Amstrad Odyssey

This Amstrad CPC6128 has been with me for many years. I didn't have an Amstrad CPC in the 1980s, I don't think I ever even saw one back then. But certainly I felt the presence of the brand in many advertisements and magazine articles. 

As Amstrad bought Sinclair, I have had somewhat mixed feelings towards a company that both rescued the Sinclair line but perhaps didn't do as much as could have been done to move it forward.

As a later entry to the 8-bit game, the CPC and especially the 6128 tried to improve the earlier home computers:

  • A decent keyboard with cursor keys at the right place
  • Variety of graphic modes for both utility and games
  • Flexible BASIC with graphics and sound commands
  • Disk drive as standard
  • Good display options

The 6128 is perhaps one of the more better thought out 128K 8-bitters, not suffering from the Frankenstein nature of Spectrum 128 and Commodore 128. The Finnish Mikrobitti magazine even declared the Amstrad 6128 as a computer of the year as late as January 1987.

However, the market was drying out that point so there were not that many models to compare it with. It's even debatable if the CPC6128 is a better deal than the Commodore 64 from 1982!

Yet I can imagine that with the 640-wide resolution and the disk drive, text editing could be rather nice. The specs also helped it run the ageing CP/M.

Anyway, around this time it started to look like a dead end to the whole 8-bit generation. The Z80 processor was struggling to move around all those graphics, and the memory had to be banked. And even if they had put in even more memory, the contents would have to be loaded. Slowly.

Faster Z80 processors and better storage devices might have extended the lifespan of these machines, much like with the eastern bloc Spectrum clones. But at this point Europeans had switched their attention to the increasingly affordable Atari ST and Amiga models.

The Amstrad video chip has been proven to be quite capable, at least for various demoscene tricks, but without sprites the games couldn't hope to be very fast.

Compared to Spectrum and C64, it has been somewhat painful to get software up and running on a real machine!

There are a couple of good Amstrad emulators around.

The CPCBox even works online:

Here's a list of emulators:

Arnold is a name that comes up, but for some reason I've used Caprice locally. Possibly it was the first I got running on my Linux and did what was needed, that is I can feed in an automatic Amstrad command line when running the emulator from the Linux command line. For example:

cap32 mydisk.dsk -a 'run "picture.bin'

...would attach the mydisk.dsk image and feed in the basic command to run the file picture.bin.

The Real Amstrad

This one has been modded to output the 5V regulated power to an external HxC Floppy Emulator. However, it would need the 12V in to the floppy cable dangling out.

The computer itself takes 5V, the plug is core negative, pin positive.

The dangling floppy cable has 12V core positive, pin negative.

I've sometimes taken the 5V for the HxC from an Arduino. This worked when using the HxC device for QL. But I somewhat fear the Arduino isn't able to provide the suggested 400mA minimum for running HxC with a card.

If there's no display, pressing the CLR key should give a beep from the internal speaker. If there's no sound then possibly there's something with the Amstrad or at least the keyboard... or the speaker. Remember to turn the volume up.

I had some problems with some of the keys working. I saw nothing wrong with the membrane keyboard connectors, just shuffled them around a bit and reconnected them. Fortunately this helped and my keyboard worked again. Possibly the connector had come loose at some previous time when I had opened and closed the case for some other reason.

As with Sinclair computers, the video mode is always a bitmap, meaning that text and graphics can be combined in BASIC easily. But it also means there are no fast character modes.

A mono-display composite video cable is easy enough to make by using the Luminance and Ground pins from the Amstrad monitor connector. This should be enough for testing if the Amstrad and the keyboard works more fully. The RGB cable is more complex and obviously requires an RGB-compatible display.

5-Ground --- connect
6-Luminance --- connect

And wham, it doesn't play games or demos that well but at least the CPC can be tested:

When in BASIC, the command CAT gives the Catalogue (i.e. Directory) of the floppy.

RUN is used for loading files, e.g. if there's a file called PICTURE.BIN in the catalogue, use RUN"PICTURE to run and execute the program.

A fun thing out of the luma video cable is that the 80-column mode 2 becomes usable (via MODE 2 of course) and it's not at all bad on my 1084S display. Hopefully I have some time to play with it in the future.

Multipaint and Amstrad

With my very own Multipaint, it's possible to export Amstrad graphics images in mode 0 or mode 1, and get them running on a real computer. However, there are a few steps needed to make this happen.

  • The output binary file from Multipaint, easy enough
  • iDSK program is needed to dump the file to an Amstrad disk image
  • With HxC floppy emulator, the dsk image has to be converted to HFE
With Multipaint, you have to export the file as an Amstrad .bin, not as Multipaint .bin. Confusing! I could have chosen a better file extension for the Multipaint project files.

The iDSK can be found from for example here:

The given archive can be extracted with

tar -xvf iDSK.0.13-src.tgz

Use make in the folder, this gives warnings but should result with the functioning binary at the src folder. It of course makes sense to move the binary to usr/local/bin/ for example.

(I edited away the mention I was not previously lucky in compiling the iDSK source.)

23.5.2022 note: sector-cpc looks like a good alternative to iDSK.

With Caprice running, I could use the following bash script to both generate a new disk image, enter the chosen file to the disk image and run Caprice with that. This was helpful for testing the image display code for various modes without having to cycle through past commands again.

# showimage filename
# (without extension)

iDSK mydisk.dsk -n

iDSK mydisk.dsk -i $1.bin -t 1 -e 6000 -c 6000

~/amstrad/caprice32/./cap32 mydisk.dsk -a 'run "'$1'.bin'

(Supposing the caprice emulator is located in that folder.)

That's enough to get the exported file working in an Amstrad emulator, but what about the real computer?

I have a Lotharek's version of the HxC Floppy Emulator to run programs from an SD card. This also presupposes the cable is correct for the CPC. 

The HxC jumpers need to be set, and the array of jumpers may be positioned differently in other versions of the HxC. 

Looking from back at the Lotharek HxC, the two rightmost pins at the top are connected, here marked with x:


Different HxC models might have the pin array in different orientation. 

Sadly I don't know how the Amstrad has been modded, apparently the internal drive is disabled so the HxC can act as drive A, because that's how it works currently.

The disk images need to be converted to the HFE format used by the floppy emulator.

Again, the converter needs to be compiled. Marq discusses it here (in Finnish)

When all is finally in place, the converter can be run from the command line:

hxcfloppyemulator_convert pics.dsk -HFE

After this has been done, the hfe file can be copied onto the SD card. The HxC can mount the image and the disk can be accessed from Amstrad BASIC with the CAT and RUN commands mentioned above.

Edit: I did try that text editing thing.

No comments:

Post a Comment