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:
The English translation says:
We take this opportunity to warn Inves users about a rumor that states
that issuing:
BORDER 5
RANDOMIZE USR 4665
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/
