But that was enough. Because the thing in question, for many CPC users, was a godsend. Loading games from tape is tedious: many games were available only on tape, or on disc at an extortionate price: many CPC users had disc drives. Ergo, why not think of an easy way of getting games from tape to disc?
Romantic Robot did. The Multiface took an exact copy of what was in memory at the present moment, and saved it to disc, ready for you to reload at your leisure. All you had to do was press a little red button then select ‘Save’ from the menu that appeared.
It was such a good idea that at least three other companies had the same plan, and brought out similar-sounding devices: Datel's Action Replay, Evesham Micros' Disc Wizard, and Mirage Imager. In one of those happy coincidences of commerce and merit, the Multiface was the best of the lot, and also the one which survived.
Strictly speaking, the device we all know as ‘the Multiface’ was in fact the Multiface Two – something that confused Amstrad Action no end. The original version (the Multiface One, if you like) was in fact a Spectrum peripheral. Romantic Robot later applied the concept to the Amiga and the ST with very little success, as games for these platforms were inevitably multi-loads. They now make their living selling classical CDs. Funny old world.
Needless to say, this concept of a ‘universal backup (oh, ok, piracy) device’ worried software houses no end, and there were no end of rumours that the Multiface and its ilk would be banned under the Copyright & Patents Act of 1990. In the end, all that happened was that Romantic Robot got the chance to run ‘Buy now! before it’s banned’ adverts, provoking lots of panic sales. They then continued to sell the Multiface. Several years later, they tried the same trick with ‘The CPC is no longer a viable platform – so we’re selling off our last Multifaces!’. This supposed last shipment lasted about two years.
To return to the subject of Amstrad Action, one (wilful?) misconception they put about was that Multifaces were serial-numbered. Thus you couldn’t run Multiface copies with anyone else’s machine. Needless to say, this was b... – er, balderdash – as the only check made (in later Multifaces) was on machine type. This meant that you couldn’t run copies made on a 464 on a 6128, or vice versa: and of course, you needed a Multiface to run them at all.
Tant pis. Enter Serge Querne, usually known as Longshot, the founder of Logon System, but in this case masquerading as Magic Software’s Merlin J Bond. His rather spiffing utility, Anti-Multiface (aka Multimag), made Multiface copies into stand-alone programs.
Suddenly, you could run Multiface copies on any CPC, from the B:-drive, without a Multiface even. You needed 128k, of course, and the original program couldn’t use extra memory. But these were small prices to pay. With this tool, the Multiface reverted from its sheep-like backup identity to its original wolf persona as Ultimate Facilitator of Mass Piracy. Except no European cracker would be seen dead using one.
How did it work?
This was really ingenious, and I’m indebted to Rob Scott for explaining it.
Any CPC program can find out what’s in memory at the moment. It’s the PEEK command in BASIC, and the very foundation of machine code. You, too, can save the contents of memory to disc just with the following line:
OPENOUT "filename" : FOR n=0 TO 65535 : PRINT#9,CHR$(PEEK(n)); : NEXT : CLOSEOUT
Needless to say, the Multiface did just that (except written in machine code). If I could get £40 for that one line of program, I’d be smiling.
But that only records what’s in memory. The CPC also has a barrage of dedicated chips to control the display (the CRTC), colours and memory configuration (the Gate Array), sound and the keyboard (the PSG), and so on. There is no equivalent of the PEEK command for these chips. So how do you find out what the settings are – what colours are in use, what size and mode the screen is in, and so on?
It works like this. The CPC sends instructions to these chips using the OUT command. Each chip has a different address. So you can send the value 1 to the CRTC with the command OUT &BC00,1; you can send the same value to the VGA with the command OUT &7F00,1; and so on.
The CPC uses the same command to send instructions to anything bolted onto the expansion port. So if you have a 464 with a DDI-1 disc drive connected, typing OUT &FA7E,1 will turn the disc motor on. (It works on a 664 and a 6128, too, proving that the CPC sees no difference between internal and external chips.)
But the instruction doesn’t magically go to the right chip: it goes to all of them. When we sent our instruction OUT &BC00,1 to the CRTC, the VGA will have seen it, as will your disc drive, your Multiface, and anything else you’ve got connected. They just think “oh, this is going to &BC00 – so it’s meant for the CRTC”, and ignore it.
At least, the disc drive and VGA ignore it. The Multiface memorises it, thereby building up a record of what you’ve told each chip to do. To change the screen mode to MODE 2, for example, you send a particular byte to the VGA. The VGA gets the byte, and changes to MODE 2: the Multiface gets it, and makes a little note “we’re in MODE 2”.
All of these settings are saved on disc as part of your backup. So when you load the Multiface-saved copy, it knows exactly how to set up each chip.
There were various revisions of the Multiface 2:
- There was a version which was visible to software all the time.
- One version had a "invisibility" switch on the front in addition to the stop and reset buttons. When switched in one direction the multiface was invisible to software and in the other it was visible. Is there a dump of the ROM from this version?
- Last revision had an automatic "invisibility" switch internally controlled by the hardware itself. After reset the multiface was visible, but when the stop button was pressed and then control was returned to the running program it would be invisible and would remain invisible until the computer was reset.
If the multiface 2 is visible you can enable/disable the ROM and RAM in the CPU's address space:
To make the ROM and RAM visible to the CPU:
- Enable lower rom using port 7fxx as normal
ld bc,&7f89 out (c),c
- Then activate the ROM and RAM:
ld bc,&fee8 out (c),c
- To deactivate the ROM and RAM:
ld bc,&feea out (c),c
Testing shows the port is decoded as: 11111110111010ex x means any value for this bit e is 0 for enable and 1 for disable.
ROM is visible in the range &0000-&1fff. (including NMI vector at 0066h). Writing to the ROM doesn't write through to CPC's RAM. RAM is visible in the range &2000-&3fff. Writing to the RAM doesn't write through to CPC's RAM. The internal ROM/RAM at 0000h-3FFFh in the CPC being disabled.
You can write to *ANY* byte of the RAM including those which store the hardware state.
The Multiface 2 listens to Gate-Array and PAL writes (port 7fxx), CRTC writes (bcxx and bdxx) and 8255 Control port writes (f7xx).
Gate-Array and PAL are decoded as 01111111xxxxxxxx, CRTC as 10111100xxxxxxxx and 10111101xxxxxxxx and 8255 writes as 11110111xxxxxxxx. When the I/O write is detected, then specific locations in the MF2 RAM are updated immediately.
Gate-Array pen index write (7fxx with bit 7=0 and bit 6=0): 3fcf Gate-Array border colour write (7fxx with bit 7=0 and bit 6=1): 3fdf Gate-Array pen colour write (7fxx with bit 7=0 and bit 6=1): 3f90-3f9f (pens 0 to 15) Gate-Array mode write (7fxx with bit 7=1 and bit 6=0): 3fef PAL write (7fxx with bit 7=1 and bit 6=1): 3fff CRTC register select write (bcxx): 3cff CRTC register data (bdxx): 1db0-1dbf (only registers 0-15, others are ignored) 8255 Control port write (f7xx): 37ff
The value that is stored is the value written.
The automatic switch version of the multiface works by monitoring opcode reads from 0064 or 0065. There is a single call to 0065 (which has a RET) before the multiface 2 returns control back to the running program. It's not possible to activate the multiface ram and rom and call it directly, the multiface 2 must be in a specific state to accept the call and make itself invisible.
When I said that the Multiface only did one thing, I was lying. It does two. Just about.
There’s a very basic memory editor built into the Multiface, which enables you to view and edit the current contents of your CPC’s memory. Er, that’s about it. Something I always found useful is that it would work in both hexadecimal and plain vanilla decimal numbers – so if I’d lost my scientific calculator (again), I still had a hex-to-decimal converter at my fingertips.
But this ability to edit the memory could be used in a very clever way to enter an assembler program and change the PC (actual executing address) to run it. The most famous use is, arguably, a BANK DUMPING PROGRAM , that dumped the first 64Kb of memory to the second bank on a CPC6128, then reset the machine. That took advantage of the fact that the second 64kb survived a RESET, so all the program was there ready to save from BASIC. The procedure was simple, just entering those bytes in any memory location (not in the 4000-7FFF range):
01 C4 7F ED 49 21 00 00 11 00 40 01 00 40 ED B0 => dump 0000-3FFF into first 16kb of second bank
01 C6 7F ED 49 21 00 80 11 00 40 01 00 40 ED B0 => dump 8000-BFFF into third 16kb of second bank
01 C7 7F ED 49 21 00 C0 11 00 40 01 00 40 ED B0 => dump C000-FFFF into fourth 16kb of second bank
01 C0 7F ED 49 21 00 40 11 00 C0 01 00 40 ED B0 => dump 4000-7FFF to screen (already saved)
01 C5 7F ED 49 21 00 C0 11 00 40 01 00 40 ED B0 => dump screen to second 16kb of second bank
01 C0 7F ED 49 C3 00 00 => reset bank status and reset the machine
Once the machine was reset, you could save all the program to basic doing:
OUT &7fc4,&c4: save "game-1",b,&4000,&3fff OUT &7fc5,&c5: save "game-2",b,&4000,&3fff OUT &7fc6,&c6: save "game-3",b,&4000,&3fff OUT &7fc7,&c7: save "game-4",b,&4000,&3fff
This trick was used to save heavily protected games to disk.
Something more people found useful was that you could change crucial parts of a game – notably the memory location that holds your current number of lives. Change it from 3 to 250, and you’re laughing. AA would print lists of such ‘Multiface pokes’ every issue.
Eat my Multiface
Many games, and even the odd demo, picked up on the presence of a Multiface. In order to stop illegal copying (or in the case of the demos, just to look smart), they would then refuse to work.
Most notorious of all was Elmsoft’s Zap't'Balls. Run it with the Multiface plugged in, press the red button, and you’d get a rather rude message. Ironically, one of the much-vaunted cracks of Zap’t’Balls was accomplished largely with the Multiface’s latterday rival – Siren Software’s Hackit. See BTL 2 for more.
To get around this, Romantic Robot put an on/off switch on the Multiface. When it was turned on, you could make copies, reload games saved with the Multiface, and use the toolkit. When it was turned off, you couldn’t. Seems fine.
But some games constantly checked for the presence of a Multiface. If you turned your Multiface on even one fiftieth of a second before pressing the red button, the game would crash. Since not even Richard Wildey has reactions that sharp, you were still lumbered.
Romantic Robot came up with a typically elegant solution. The Multiface was always off, until you pressed the red button. Then it turned itself on just in time to bring up the menu allowing you to save your game. This done, you pressed ‘R’ to return to the game, at which the Multiface turned itself off again.
There is a small flaw in this solution, of course – namely that if the Multiface is always turned off, you can’t load your saved games, which require the Multiface to be turned on before they’ll run. So Romantic Robot added a blue button. This reset your CPC and turned the Multiface on at the same time. If you wanted to run a game that objected to the presence of a Multiface, you just pressed the red button followed by ‘R’ for return.
It may all sound complicated, but it worked in almost 100% of cases.
Some programs were written to co-operate with the Multiface, rather than fight against it.
- The Insider (a Multiface II tool from Romantic Robot themselves)
- TUSS (The Ultimate Sprite Searcher)
Were all hacking programs designed to expand the capabilities of the Multiface.
TUSS and Soundhakker, by Richard Wildey and Rob Scott respectively, were particularly specialised tools. TUSS helped you to nick graphics out of other people’s games: Soundhakker helped you to nick Soundtrakker tunes from demos and fanzines. Amstrad Action (them again) once tested Tearaway against TUSS, found in favour of Tearaway, and then completely disproved their findings by using TUSS, not Tearaway, to remove the nipples from the covertape version of Stormlord.
Both Doctor Fegg and Richard ‘User:Executioner’ Wilson started work on powerful hacking programs which would work with the Multiface, titled Dr Fegg’s Hack Pack and Amigo respectively. Neither was ever finished.
Fifteen years later
The Multiface originally sold for £40 or so. These days, £15 is a fair second-hand price: any less and you’ve got a good deal.
Most CPC emulators provide equivalents of the Multiface’s two main features. Instant copies can be made with the ‘snapshots’ feature, creating files with an .SNA extension that can be easily reloaded. The toolkit, meanwhile, has been replicated with whizzy new disassemblers/monitors/what-have-you. Of course, since emulators can’t load files from tape, it’s not really the same any more.
Epilogue: AA again
The various complexities of the Multiface meant that Amstrad Action readers were always writing in with questions. It’s actually quite hard to come up with attractive illustrations in a computer magazine. So AA always used to print a picture of a Multiface.
Until one fateful day, when the usual spot was blank. The caption said it all: “We used our picture of the Multiface so much that it wore out. So this is blank until we get round to taking a new one.”
- MF2 (Jose Leandro).zip (With all the PAL decoded)
There are at least 3 firmware versions.
The year & checksum can be displayed by pressing f0 on numeric keypad (within the multiface toolkit main menu).
The checksum is calculated by XORing all bytes in the ROM with each other.
- MF2 86 ROM - (1986, chksum=86h)
- MF2 3E ROM
- MF2 0E ROM - (1988, chksum=0Eh)
- MF2 7C ROM - (1988)
- MF2 78 ROM
- MF2 8D ROM - (1988)
For the Amstrad Plus series:
The Source Code:
Differences between chk=86 and chk=0E versions are unknown.
The chk=0Eh and chk=8Bh versions are almost byte-identical, they differ only by some bytes related to the new AMSDOS version used in CPC Plus system cartridge (aside from the new AMSDOS version, there is no support for CPC Plus related features, like handling the new ASIC registers).
You can find more versions (and more info, besides) over at the Grimware site
A project was begun to remake the multiface (by Giants of cpc-hardware on 2005) :
> Interface disassemble
> First typhon
> First decoding via H/W counter the Equation Of PALs
> A lot of pictures, informations H/W
> indicate all pins connections.
Jeff(hxc) was join the projet and make a big profesional work :
> Dump 2 pals
> Dump of the EPROM.
> Decoding equations
> Writing a test tool for the verification of these equations with real pal
> Implementation of the scheme Multiface 2.
Details are here (in French).
For posterity, all the information and files from that page have been gathered and are available in this zip file:
The reverse engineering of the multiface II is not quite complete, in that two versions of one of the PAL chips are apparently in the wild, and only one has been reverse engineered, and that one not completely.
It's unclear what the newer version of the PAL chip is for, but CPC+ support would seem likely.
Until the PAL chip is decoded, there is not enough information to complete the remake.
Now, thanks to Jose Leandro, the hardware specialist of the spectrum, with his famous page :
We can know more about this hardware, all the PAL chips are decoded:
- MF2 (Jose Leandro).zip (With all the PAL decoded)