I recently came across this magazine snippet; specifically this section:

Aprovechamos para avisar a los usuarios del Inves, que nos ha Ilegado el rumor de que haciendo:


se averia el ordenador. No hemos tenido aún ocasión de comprobarlo (de funcionar, supondría cargarse un ordenador) pero esperamos poderlo verificar en un futuro. En una ocasión dijimos que era imposible averiar un ordenador desde el teclado; bien, ésta sería la excepción que confirma la regla.

English translation (courtesy of mcleod_ideafix in their original answer):

We take this opportunity to warn Inves users about a rumor that states that issuing:


the computer can be damaged. We haven't tested this yet (if this works, it means we would damage a computer) but we hope to put it to the test in the future. At one time we told you that it was impossible to break a computer by issuing commands from the keyboard. Well, this would be the exception that proves the rule.

There is a rumour that the above code snippet, when run in the BASIC prompt, will cause damage to the computer. The text is in Spanish, so I presume it is referring to the Spanish version of the computer. The code doesn't appear to do much in an emulator, except print garbage to the screen.

On an actual machine, does this code cause damage?

  • 6
    I was tempted to add the malware to this question because the code (if the rumour is true) is malicious. However, it doesn't fit the tag-wiki definition. – wizzwizz4 Feb 6 '17 at 20:52

I am the author of that video. I wrote a little article about that years ago. I will copy that for you here:

Original article here: http://www.zxprojects.com/index.php/the-fix-a-spectrum-blog/29-the-oddities-of-the-inves-spectrum

The Inves Spectrum+ was a Spectrum 48K clone made by Investronica, the Spanish partner of Sinclair Research, and responsible for Sinclair distribution in Spain.

This clone has suffered from numerous incompatibilities, mainly because of its non standard ROM, altered in some ways, mostly of them to comply with Spanish regulation, that demanded that every computer with less than 64K had to be "spanished". That is: error messages had to be in Spanish, and the keyboard and screen had to be able to display some Spanish characters, like Ñ, or áéíóú.

Among the features of the Inves Spectrum, there was one that we can consider "unique" on the history of Sinclair computers: the Inves Spectrum was presumably the first Spectrum clone that could be damaged permanently by issuing instructions...

On page 32, issue #156 of the Spanish Microhobby magazine, this could be read:

Warning in spanish

The English translation says:

We take this opportunity to warn Inves users about a rumor that states that issuing:


the computer can be damaged. We haven't tested this yet (if this work, it means we would damage a computer) but we hope to put it under test in a future. Once ago we told you that it was impossible to break a computer by issuing commands from the keyboard. Well, this would be the exception that proves the rule.

It seems that, after all, they didn't do the test. Too afraid to damage one computer? Well, the Inves Spectrum is now considered "rare" as it only sold in Spain (although I've seen one or two in Britain, but they could have bought from a Spanish ebayer) and only a few months before Amstrad would take over Sinclair, so I'm not surprised that there's no news about someone having tried this "randomize of the death" to the date.

In the meanwhile, the ZXSpectr emulator had been released, and claiming that it's the only emulator that supports the Inves Spectrum+ with its oddities. Nevertheless, Spectaculator seems to work well if the Inves ROM is supplied to it (but without the side effects discussed below).

ZXSpectr would have been just another Spectrum emulator, but had a distinctive value added: its author, César Hernández Bañó, showed the results of his own research about the strange behaviour of the Inves. One of them was the following:

"...It happened that, if you poke'd certain ROM addresses (yes, ROM addresses), the border didn't respond to new BORDER commands, so the speaker to BEEP commands. After some research, we discovered that pokeing ROM addresses whose least significant byte was 254, blocked any data from entering the ULA.

To be more precise: if you POKE a value V to addresses 254, 510, 766, ..., 16382; that is, N*256+254 with N ranging from 0 to 63, that value V acts like an AND mask for any subsequent data directed to the ULA. This means that if V is 0, regardless of the value issued by the processor, the ULA sees 0 in its data bus. To recover normal operation, 255 has to be "poked" to every "privileged" ROM address.

This situation lasted as long as there were power supply to the Spectrum. A hard reset or a RAND USR 0 didn't restore the ULA to the original state. Only after a power cycle, things would come back to normal..."

It's with Spectaculator, which I tried the "randomize of the death" with. Thanks to the ability of Spectaculator being able to put breakpoints into anywhere in memory, I traced the code beginning at address 4665, checking that it couldn't do any harm to the computer: the first two/three bytes were incorrectly decoded, as the address 4665 falls in the middle of a multibyte instruction, but after that, it's merely a jump in the middle of some ROM routine. The Phillip Kendall ROM collection lists the Inves ROM, so you can download it and try in your favorite emulator.

So, what happens with the real machine? Well, see it for yourself:

The first video shows what happens if the "randomize of the death" is issued to a real Inves Spectrum+. The video starts with a power cycle to initialize the Inves. If you can, compare this with the result obtained with Spectaculator running the Inves ROM:

Link to video showing an Inves Spectrum+ executing BORDER 5: RANDOMIZE USR 4665

Well, I think that after seeing this, it's the end of the "randomize of the death" hoax. And now for the poke-ROM issues, which I find more interesting. The following video shows an Inves doing a power cycle to initialize, then a tiny BASIC program is written, that pokes a 0 to every ROM location from 0 to 63*256+254. After running the program, I do some ULA related tests. After then, I issue a RAND USR 0, and after that, a hard reset by pushing the reset button. See what happens, and how the Inves can be restored to its normal state:

Link to video showing "sticky" behaviour of border even after reset

After this last test, I've wondered if this "mask enabling mechanism" only works for memory bus cycles or if it works for I/O bus cycles too. I've changed the POKE instruction for an OUT instruction in the program showed in the video, and nothing weird has happened. So, I think that whatever this is, it's a deliberate feature, not an accidental one. The same Microhobby article showed at the beginning of this post also said that "...it seems that there's some kind of buffer between the Z80 and the peripherals, and some ports have to be written to, to allow access to the external bus..."

This feature can be used to alter the way other ports work. If I do a:

FOR n=0 TO 63: POKE n*256+p,v: NEXT n

Then, port p will be affected by mask v. That is, any value written to port p will be ANDed with v. I've tried this with even ports other than 254 and it works. It seems that port reading operations are not affected, so I cannot test if this works for odd ports too, as the only even port the Inves has is the Kempston joystick (port 223), which is a read-only port.

To end this article, I want to mention something that seems to have passed unnoticed to the people that has experimented with the Inves: some people find strange to poke to addresses that are located in ROM area, or at least, it seems so... doesn't it? It might not be that way. Just recall that the Inves Spectrum+ has 64K of RAM (two 64K x 4bit chips). Couldn't it be that the presumed ROM poke operations are indeed writing values in RAM? If so, does these RAM values act as configuration values for the ULA or some other parts of the computer? As a far as I know, there's no schematics for the Inves, and without that, further analysis is not easy.

Well... after many years, I was able to reverse engineer the Inves Spectrum. My findings, which among other things, explain the odd "sticky" behaviour, were published in another article, sadly only in spanish this time, although I digitalized it and published it in the form of a (huge) web page so you can sort of read it using Google Translate. AFAIR, there was a guy that started to do a proper translation of the text, but I haven't contacted him for a while.

Article here: http://www.zxprojects.com/inves/

  • 1
    You created that video? It's a small world. – wizzwizz4 Feb 6 '17 at 22:55
  • Yes. I was aware of that hoax since those times, and after realizing that it shouldn't damage the computer, I tried the "randomize of the death". It shouldn't because you are actually executing ROM code, code that would be executed at any time, so if there was anything harmful in that, we (and manufacturers) should have discover by then. I only traced the first instructions on an emulator, as the USR points to the middle of a multibyte instruction, so there was one or two misdecoded instructions before the original code resumes execution. – mcleod_ideafix Feb 6 '17 at 23:04
  • Yes. (at 1239, byte 4f) ld c,a and (at 123a, byte 5c) ld e,h, correct? – wizzwizz4 Feb 6 '17 at 23:11
  • 1
    Lovely answer. If you need any more background, UK computer journalist Rupert Goodwins (easy to find on twitter, possibly even active here) was a developer at Sinclair at the time of the Inves/first gen 128 development. But it looks like you've got everything relevant – scruss Dec 17 '19 at 17:03
  • 1
    Original article gives me a 404 now, here it is at archive.org – Jonathan Sep 22 '20 at 9:05

It appears that this rumour is in fact false. A video of the commands being run on a real Spanish ZX Spectrum shows that the only visible effect is garbage output.

  • 2
    What a let-down. I think an instruction by instruction breakdown would make this a more interesting answer. – wizzwizz4 Feb 6 '17 at 21:13
  • I decided against updating this answer because... well, it turns out that the author of the video is a regular here and posted a much better answer. – wizzwizz4 Dec 14 '18 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.