Fun with RANDOMIZE USR

[Oloturia]

When I was a child, one afternoon I tried some random numbers to call with RANDOMIZE USR. I already knew that USR 0 was total reset, but after BREAKing some loaders (to insert POKEs, ça va sans dire) I noticed that USR can accept also different numbers. So I started trying with random numbers. I wasn't really aware of what I was doing, anyway after a few resets, I found many addresses (I didn't know that they were addresses) that yielded some glitchy things, like loaders with funny colours.

When my older brother discovered that I was playing with USR he shouted that I could break the computer. I argued a little but eventually I gave up, as he was the older one and probably was right (except this time).

Anyway now I'm a grown adult (mpfaAHAHAHA lol sorry) and not afraid of breaking my emulator and with the same knowledge (none) of Spectrum's ROM I tried a few USRs.

This one is pretty, RANDOMIZE USR 9196.

[ParadigmShifter]

Pretty sure you can't damage an out of the box spectrum with a RANDOMIZE USR, it would just crash.

You may be able to damage the CRT with burn in under some circumstances I guess.

You could knacker the relay switches on an Amstrad by toggling the tape recorder motor on and off.

Some machines which you could damage with POKES and calls documented here:

https://en.wikipedia.org/wiki/Killer_poke

[Oloturia]

Well you can't in any way corrupt the ROM because, as it says, it's Read Only.

With the exception of the Zuse, the Killer Pokes listed in the page are all related to peripherals, like CRTs or disk drives (the Amiga's one is particularly lolful, "hey my drive is singing! how funn... aw crap...").

I remember anyway an allegedly killer poke that could brick the Spectrum, but it was revealed as a urban legend.
https://retrocomputing.stackexchange.co ... x-spectrum

[ParadigmShifter]

Obviously the ROM writes to the RAM though So you can mess up lots of things but again worst thing that would happen would be a crash or infinite loop.

[1024MAK]

An unexpanded ZX Spectrum (other than a +3) is very unlikely to be damaged by random pokes or random USR calls.

So feel free to play...

Mark

[Oloturia]

This one is fun, too:

Code: Select all

10 LET n=INT(RND*6144)+16384
20 LET v=INT(RND*256)
30 POKE n,v
40 GO TO 10

result:

[ParadigmShifter]

No calls there It's just poking random stuff to the screen

It does demonstrate how poor the RND function is on the speccy though (diagonal bands very noticeable).

[Oloturia]

Yes I'm quite surprised too of the bands.
When I started the program the first time for a fraction of a second I thought I saw something, like a face... it was spooky...

[ParadigmShifter]

Get rid of the banding simply by doing this



EDIT: Doing LET a = a+1 at the end of line 10 and doing LET v = USR a on line 30 probably speeds it up a bit (still slow though). EDIT2: May as well just get rid of line 30 then and do

40 POKE n,USR a

instead.

Decent RNG routine I use, thanks to Patrik Rak, Einar Sukas and Alan Albrecht.

I assembled it to where it lives in my code (address 37171) - you 'd have to assemble it manually to relocate it elsewhere. I'd already ran it a few times and messed with the seed by setting 1 byte to the R register so binary code I ripped from the debugger is going to be a little different in the table area.

Code: Select all

basic_rnd:
	call rnd
	ld b, 0
	ld c, a
	ret

; 8-bit Complementary-Multiply-With-Carry (CMWC) random number generator.
; Created by Patrik Rak in 2012, and revised in 2014/2015,
; with optimization contribution from Einar Saukas and Alan Albrecht.
; See http://www.worldofspectrum.org/forums/showthread.php?t=39632

rnd:
	IF RAND_ALWAYS_1
	ld a, 1
	ret
	ENDIF
		ld   hl, table

        ld   a, (hl) ; i = ( i & 7 ) + 1
        and  7
        inc  a
        ld   (hl), a

        inc  l      ; hl = &cy

        ld   d, h    ; de = &q[i]
        add  a, l
        ld   e, a

        ld   a, (de) ; y = q[i]
        ld   b, a
        ld   c, a
        ld   a, (hl) ; ba = 256 * y + cy

        sub  c      ; ba = 255 * y + cy
        jr   nc, $+3
        dec  b

        sub  c      ; ba = 254 * y + cy
        jr   nc, $+3
        dec  b

        sub  c      ; ba = 253 * y + cy
        jr   nc, $+3
        dec  b

        ld   (hl), b ; cy = ba >> 8, x = ba & 255
        cpl         ; x = (b-1) - x = -x - 1 = ~x + 1 - 1 = ~x
        ld   (de), a ; q[i] = x

        ret

randSeed:
table   db   0, 0, 82, 97, 120, 111, 102, 116, 20, 15

        if   (table/256)-((table+9)/256)
        error "whole table must be within single 256 byte block"
        endif

EDIT3: Final version Obvs could be speeded up if I got rid of the RND and did the modulo 6144 stuff in ASM as well (and the pokes lol). I will leave that as an exercise for the reader.

EDIT4: Remember to paste the final version here lol



EDIT5: Final final version



EDIT6: I lied about it being the final final version



INT is probably unnecessary as well And ditch LET n = INT(RND*v), just do POKE RND*v+s, USR a

EDIT7: Nope that is bugged looks like INT is necessary So POKE INT(RND*v)+s, USR a is my final answer. Does POKE really round up the first argument???

[ParadigmShifter]

Not convinced replacing numeric literals with variables is any faster tbh, a stopwatch time of filling 1 screen seemed to suggest just using the literal was faster

It's far too slow anyway runs ok at CPU speed of 100MHz on the emulator

And optimising BASIC... what's the point lol

[deanysoft]

For some reason I can remember accidentally doing RANDOMIZE USR 1331

It's probably jumping into the save bytes routine. Who knows what it's saving but it was a novelty back then due to the different border colours.

[ParadigmShifter]

If you RANDOMIZE USR 1218 that calls the proper save routine (headerless though) and it appears to be saving 23770 bytes from address 980 when I try that. 1331 is right in the middle of that routine.

https://skoolkid.github.io/rom/dec/asm/1218.html

So I guess it will probably finish once it has saved those 23770 bytes. Assuming DE and IX are always the same when called from BASIC (big assumption).

EDIT: Yup it did finish eventually.

Dunno why the border colours are messed up I thought the colours always added up to 7? (So blue+yellow = 6+1, red and cyan = 2+5). Magenta and blue only adds up to 4? That's numberwang

It's also lucky A is odd when you call 1331 cos if it wasn't it would return immediately (cos first 2 things it does is RRA and RET NC).

[Oloturia]

For some reason I can remember accidentally doing RANDOMIZE USR 1331

It's probably jumping into the save bytes routine. Who knows what it's saving but it was a novelty back then due to the different border colours.

Very cool!
With 1400 it's green/blue.

If you use PRINT USR instead of RANDOMIZE, you'll get also the return value. In this case is 20.

[ParadigmShifter]

Well there's only 16384 addresses to try that shouldn't take long

Many will depend on what is currently in registers though and I don't know enough about BASIC to know if the register contents will be consistent or not.

I thought you could do similar stuff with OUT command but I couldn't get that to do anything interesting after 2 tries

[ParadigmShifter]

Very cool!
With 1400 it's green/blue.

If you use PRINT USR instead of RANDOMIZE, you'll get also the return value. In this case is 20.

Did you wait for it to finish or did you press space or BREAK to get the return value (actually value in BC register pair)?

[Oloturia]

Did you wait for it to finish or did you press space or BREAK to get the return value (actually value in BC register pair)?

I waited. If I try to break it gives 12595.

It seems that USR 1400 isn't working anymore

[ParadigmShifter]

Fascinating We really need a spreadsheet of all 16384 results with return values if it doesn't crash.

I think only the save and load stuff and obvious things like drawing routines will do anything exciting though (and not that exciting either). Obvs some crashes will do wacky things before crashing.

Some stuff will not crash but trash the BASIC program or the SYSVARS in some way. You can probably make it jump into the RAM too so could run arbitrary code.

[ParadigmShifter]

I waited. If I try to break it gives 12595.

It seems that USR 1400 isn't working anymore

1400 does do something but it takes a while It does a load of loops until HL is 0 then calls 1507 which does some flashing of the border. Then it stops doing stuff again (then I stopped investigating).

RANDOMIZE USR 1507 on its own is much less exciting than that (no suspense waiting for something to happen! It returns straight away!). Lovely green border though when I tried it. And a very short beep.

It's waiting to hear something to load that looks like. And then 1507 is the most important part of the load or verify routine apparently.

Stuff that happens calling the save/load routines is meant to be called with the interrupts disabled (for timing porpoises) but the ISR cleans up after itself so that should only affect how long stuff takes and not make it more unpredictable.

Obvs calling the ROM at random is very sensitive to the initial values of registers and there's no way to set those to known values easily from BASIC (they aren't stored in RAM for starters).

[equinox]

When I was a child, one afternoon I tried some random numbers to call with RANDOMIZE USR. [...] When my older brother discovered that I was playing with USR he shouted that I could break the computer.

God, how did I not see this EXCELLENT thread previously?
Mate, for me, it was OUT, which is much more mysterious -- because we know what USR does, that's just saying "run a piece of code that I put at this address" (and if there is no code, then keep cycling through the zero 0...0...0... until you find some. Even if it's USR 0 reboot.)
OUT is much more subtle and bizarre. I used to mess with random numbers there, as a kid, and I will never forget the time when I managed to create the "opening menu" (Tape loader, BASIC, Calculator...) but all broken and crazy and green. Thing is, you can't do it twice. Even if you remembered the numbers. It's all connected to what the hell was going on at that millisecond. OUT is magic.

OUTing is also a good way to generate the "pyjama stripes". If you don't know what I'm saying then you haven't OUTed enough.

Later I graduated to "deleting every file I didn't personally like" and I screwed up the Windows 95 PC pretty bad. (I didn't like DLLs much.) I remember having to call some ATI hotline "please help, how do we get back from 16 colours to 256 colours again"...

[equinox]

For some reason I can remember accidentally doing RANDOMIZE USR 1331
It's probably jumping into the save bytes routine. Who knows what it's saving but it was a novelty back then due to the different border colours.

Speccy experts know that USR 1300, 1301, 1302... through 1307 will produce pseudo loading stripes in different colours. Truly each one is a different colour. But beware, I dunno if it's corrupting anything.

[equinox]

This one is pretty, RANDOMIZE USR 9196.

Load the game "Xcel" (no fastloader, no emulator bullsh*t), you will enjoy it.

[equinox]

You could knacker the relay switches on an Amstrad by toggling the tape recorder motor on and off.

You could also do this on the BBC Micro, although if you owned a BBC Micro you were either a teacher, or a beardy prog rocker, so you'd never do it. For purely theoretical reasons I reproduce a program below (DO NOT RUN THIS)

1 *MOTOR1
2 *MOTOR0
3 GOTO 1
4 REM OSCLIOSCLIOSCLIOSCLIOSCLI

Reminds me of someone who wrote a ZX Spectrum "virus" that politely asked you to insert a tape and hit REC. Well Chris Pile you deserved your jail time.

[equinox]

You could also do this on the BBC Micro, although if you owned a BBC Micro you were either a teacher, or a beardy prog rocker, so you'd never do it.

alerted the craft beer experts
https://www.stardot.org.uk/forums/viewt ... p?p=405837

[equinox]

It's probably jumping into the save bytes routine. Who knows what it's saving

You never put a tape in? It's a great space invaders game called VAXNSUZ.$$$

[WhatHoSnorkers]

Load the game "Xcel" (no fastloader, no emulator bullsh*t), you will enjoy it.

I bought Xcel as I wanted to play it, and it's "distribution denied". I played it once in 1990 or so and it intrigued me. Of course, the tape doesn't work...