Spectrum Computing

Does anyone have any suggestions for a short machine code routine that crashes the Speccy in a visually and/or audibly impressive way, and returns it to a NEW state?

(and if yes, can I rip it off in my next game? )

Bunging a paper clip on the expansion port usually works a treat!

MatGubbins wrote: ↑Sun Jul 22, 2018 8:44 pm Bunging a paper clip on the expansion port usually works a treat!

Heh. Another Speccy to add to eBay's 'not tested but working' pile.

The best I can managed so far is a lazy border effect LDing down from the top of memory.



It might have to do, argh, in which case I should have kept it to myself

R-Tape wrote: ↑Sun Jul 22, 2018 8:05 pm Does anyone have any suggestions for a short machine code routine that crashes the Speccy in a visually and/or audibly impressive way, and returns it to a NEW state?

(and if yes, can I rip it off in my next game? )

Darn it. If I know you collected artsy Speccy crashes, I would have save a few for you. Just a few days ago I was making a fix for a game (don’t even remember which one), and it crashed just the way you want it: a few seconds of loading/saving sounds with the usual border animation followed by some random patterns on the screen and a reset.

The first year that I got my hands on a Speccy, when I had got my head around the normal BASIC commands and functions, I started playing with POKE and USR. I tried many combinations in the search for useful or interesting effects. But I did not keep much in the way of notes. And what I did keep, were typed up on said ZX Spectrum and printed on thermal paper. Paper that has not aged well...

Mark

1024MAK wrote: ↑Mon Jul 23, 2018 6:50 am The first year that I got my hands on a Speccy, when I had got my head around the normal BASIC commands and functions, I started playing with POKE and USR. I tried many combinations in the search for useful or interesting effects.

I used to do the same thing. I still have "RANDOMISE USR 2272" committed to memory after all these years. But it doesn't end in a reset so it's not what the OP wants.

You might get some interesting effects by messing around with the I and R registers, for example setting I to point to contended memory.

I think Tomahawk also has some screen corruption effects for when you crash.

djnzx48 wrote: ↑Mon Jul 23, 2018 9:12 am You might get some interesting effects by messing around with the I and R registers, for example setting I to point to contended memory.

The problem is that altering the I register would only crash the 128K machines IIRC, whereas the 16K/48K models continue to work (albeit with the screen snow still).

Changing R would probably only cause real Spectrums to crash, I don't know of any emulator that simulates DRAM leakage.

PROSM wrote: ↑Mon Jul 23, 2018 9:33 am The problem is that altering the I register would only crash the 128K machines IIRC, whereas the 16K/48K models continue to work (albeit with the screen snow still).

I did extensive testing some time ago to verify this hypothesis (I documented in on WoS), and I was unable to crash the 128K Speccy no matter how hard I tried. So there’s little substance to this notion.

That is not to say you can’t crash any Spectrum “the regular” way by messing with the interrupt vector register. Quite the opposite.

Maybe: Change the JP 26000 to JP 0 to reset obviously! I left it at self as it then generates some slightly different patterns, just break/space a few times:



I did try a few other variations on this such as DI and/or doing something like LD A,R as well as playing with the Call address a bit, without a great deal of other effects really. I thought about more detailed border effects but it seemed a bit o.t.t.

Slightly off-topic, but there was a game that simulated a 48K Speccy reset just for fun. No vertical red lines, but it was enough to trick my friends back then.

zxbruno wrote: ↑Fri Aug 30, 2019 1:57 pm Slightly off-topic, but there was a game that simulated a 48K Speccy reset just for fun. No vertical red lines, but it was enough to trick my friends back then.

Brian Bloodaxe