why "rand usr" to call machine code?
jonnosan
for calling in to a machine code function?
I cen see the e "usr" bit is common to other BASICs, but is there any
logic behind the "rand' part?
Cheers
Jonno
Andrew Halliwell
It was a pretty harmless thing that didn't impact on registers and mempory,
probably. If you did let A=usr or print usr then you'd have a consequence.
All rand usr did was reseed the random number generator.
usr is a function, so it needed to be used in conjunction with
SOMETHING else.
--
| spi...@freenet.co.uk | |
| Andrew Halliwell BSc | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" |
| in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
| Computer Science | - Father Jack in "Father Ted" |
Ian Rawlings
> I cen see the e "usr" bit is common to other BASICs, but is there any
> logic behind the "rand' part?
I always assumed it was just because they weren't being used in that
combination for anything else, and the choices were limited by what
was on the keyboard so they had to choose something. Probably a bit
of chortle value involved given the potential for making a mess of
things! I know I used to type in random numbers and see what
entertaining messes would result.
--
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/
Paul E Collins
> I always assumed it was just because they weren't being used in that
> combination for anything else, and the choices were limited by what was on
> the keyboard so they had to choose something.
Nope. RANDOMIZE USR x is still a RANDOMIZE instruction with its usual effect
on the number generator. It just evaluates USR x first and uses that value.
Compare RANDOMIZE COS 5 or RANDOMIZE LEN "string".
Eq.
Robert Newson
Ther are 2 methods for calling machine code:
a) Function: = USR(nnn) (the meaning of nnn can vary, I've
seen it both as the address to call
and a value passed to the machine code
address of which is stored in a vector)
b) procedure: varies, but some I have met are:
CALL addr
SYS addr
The procedure method has no return whereas the function method does.
Those with only the function method require the returned value to go
somewhere and so using RAND (?) or RANDOMISE allows the return value to be
effectively thrown away. It is actually used to seed the pseudo random
number generator which would normally not have much of an effect, unless the
code always returned the same value and RND (random) numbers were being used
in which case the sequence would keep being reset.
Andrew Halliwell
> Those with only the function method require the returned value to go
> somewhere and so using RAND (?) or RANDOMISE allows the return value to be
> effectively thrown away. It is actually used to seed the pseudo random
> number generator which would normally not have much of an effect, unless the
> code always returned the same value and RND (random) numbers were being used
> in which case the sequence would keep being reset.
cases, the randomize would never receive it's seed value.
If it's a basic program that does the calling for small routines, then it
could always reseed the RNG after each USR. in this case, using the
speccy's uptime would be a good seed.
--
| spi...@freenet.co,uk | "Are you pondering what I'm pondering Pinky?" |
| Andrew Halliwell BSc | |
| in | "I think so brain, but this time, you control |
| Computer Science | the Encounter suit, and I'll do the voice..." |
Matthew Westcott
> It was a pretty harmless thing that didn't impact on registers and mempory,
> probably. If you did let A=usr or print usr then you'd have a consequence.
>
> All rand usr did was reseed the random number generator.
Unfortunately it can be a significant side effect, if you happen to be
writing a program that depends on both random numbers and machine code
subroutines... CSS Catch Phrase from one of the past CGCs comes to mind.
RANDOMIZE USR is such a force of habit that it's easy to overlook it
when you're debugging and desperately wondering why your random numbers
aren't random enough... until you realise the answer and feel very, very
stupid.
Paul E Collins
> Unfortunately it can be a significant side effect, if you happen to be
> writing a program that depends on both random numbers and machine code
> subroutines... CSS Catch Phrase from one of the past CGCs comes to mind.
> RANDOMIZE USR is such a force of habit that it's easy to overlook it when
> you're debugging and desperately wondering why your random numbers aren't
> random enough... until you realise the answer and feel very, very stupid.
A couple of strange alternatives with even less of a side effect:
BEEP 0, USR n
IF USR n THEN
Eq.
jonnosan
wrote:
> jonnosan wrote:
> > What was the reason that "rand usr <xxxx>" was the preferred syntax
> > for calling in to a machine code function?
>
> > I cen see the e "usr" bit is common to other BASICs, but is there any
> > logic behind the "rand' part?
>
> Ther are 2 methods for calling machine code:
>
> a) Function: = USR(nnn) (the meaning of nnn can vary, I've
> seen it both as the address to call
> and a value passed to the machine code
> address of which is stored in a vector)
> b) procedure: varies, but some I have met are:
> CALL addr
> SYS addr
>
I assume you mean, these 2 options were taken by different
implementors of BASIC, but whoever designed sinclair BASIC only
allowed for option a? or do mean CALL and SYS available in sinclair
BASIC?
Regards
Jonno
dott.Piergiorgio
> jonnosan <jonn...@gmail.com> wrote:
>> What was the reason that "rand usr <xxxx>" was the preferred syntax
>> for calling in to a machine code function?
>>
>> I cen see the e "usr" bit is common to other BASICs, but is there any
>> logic behind the "rand' part?
>
> It was a pretty harmless thing that didn't impact on registers and mempory,
> probably. If you did let A=usr or print usr then you'd have a consequence.
>
> All rand usr did was reseed the random number generator.
>
> usr is a function, so it needed to be used in conjunction with
> SOMETHING else.
I'm wrong or usr(x) was intended mainly for subroutines returning a
value ? for example LET a = USR(XXXXX) return in a the value in the
accumulator at the end of the machine code called.....
Was also the same for IF USR, with return value evaluated as true or
false or not ?
Best regards from Italy,
Dott. Piergiorgio.
Bohus Král
"Robert Newson" <get....@bullet3.fsnet.oc.ku> napísal v správe
news:494BC5FC...@bullet3.fsnet.oc.ku...
If USR command was supposed to jump to machine code then why I cannot use it
alone ?
10 USR x
It wouldn't affect my basic program if I don't expect any returned value. It
would be clear syntax to jump to machine code.
B
Chris Young
to MC dott.Piergiorgio:
> I'm wrong or usr(x) was intended mainly for subroutines returning a
> value ? for example LET a = USR(XXXXX) return in a the value in the
> accumulator at the end of the machine code called.....
On the Speccy, usr("a") gives the address where UDG A is stored.
Actually, that's a side question - why?
Chris
--
+-------------------------------------------+
| Unsatisfactory Software - "because it is" |
| http://www.unsatisfactorysoftware.co.uk |
| Your Sinclair: A Celebration |
+- http://www.yoursinclair.co.uk -----------+
DISCLAIMER: I may be making all this stuff up again.
Robert Newson
...
> I'm wrong or usr(x) was intended mainly for subroutines returning a
> value ? for example LET a = USR(XXXXX) return in a the value in the
> accumulator at the end of the machine code called.....
> Was also the same for IF USR, with return value evaluated as true or
> false or not ?
BASICs usually work on the basis of:
IF VALUE NOT FALSE THEN
instead of
IF VALUE IS TRUE THEN
(In fact, probably all languages I've used, both high and low work on that
basis.) To allieveate this, you could use:
IF USR(nnn) THEN REM
A. J. Moss
You could try finishing your machine-code routine with
LD BC, (23670)
just before the final RET instruction.
The function USR outputs the contents of the BC register pair.
The two-byte system variable at 23670 is "SEED", the seed value
of the random number generator.
Insertion of this four-byte instruction would mean that the
RANDOMIZE command would overwrite the random number seed value
with that same variable's current value.
Robert Newson
...
>>Ther are 2 methods for calling machine code:
>>
>> a) Function: = USR(nnn) (the meaning of nnn can vary, I've
>> seen it both as the address to call
>> and a value passed to the machine code
>> address of which is stored in a vector)
>> b) procedure: varies, but some I have met are:
>> CALL addr
>> SYS addr
>
> I assume you mean, these 2 options were taken by different
> implementors of BASIC, but whoever designed sinclair BASIC only
> allowed for option a? or do mean CALL and SYS available in sinclair
> BASIC?
CALL is available in the "Sinclair" Basic on the QL, but yes, I mean that
the ZX basics only implemented the =USR(nnn) method of accesing [a] user
written machine code [function].
CALL was used by BBC basic, Applesoft, QL SuperBasic (and probably others
I've forgotten), SYS was used by Microsoft's Basic for CBM Pets.
A. J. Moss
> If USR command was supposed to jump to machine code then
> why I cannot use it alone ?
>
> 10 USR x
>
> It wouldn't affect my basic program if I don't expect any
> returned value. It would be clear syntax to jump to
> machine code.
You'd have to patch the ROM to be able to do that.
I definitely remember a type-in program in one issue of YS
that did precisely that. It did something with the Z80
interrupts, to intercept this use of USR as a keyword
before passing control to the BASIC interpreter in ROM.
Robert Newson
...
>> Ther are 2 methods for calling machine code:
>>
>> a) Function: = USR(nnn) (the meaning of nnn can vary, I've
>> seen it both as the address to call
>> and a value passed to the machine code
>> address of which is stored in a vector)
>> b) procedure: varies, but some I have met are:
>> CALL addr
>> SYS addr
>>
>> The procedure method has no return whereas the function method does.
...
> If USR command was supposed to jump to machine code then why I cannot
> use it alone ?
>
> 10 USR x
>
> It wouldn't affect my basic program if I don't expect any returned
> value. It would be clear syntax to jump to machine code.
>
> B
Because USR is a function and is thus expected to return a value. Syntax
definition for [most if not all] BASICs require that function returns are
used and it is an error not to use it somewhere.
Your statement is like saying why can't I use SIN alone:
10 SIN x
I've calculated the value of SIN x, and then thrown away the result - a bit
of a waste of time.
jonnosan
wrote:
>
> CALL is available in the "Sinclair" Basic on the QL, but yes, I mean that
> the ZX basics only implemented the =USR(nnn) method of accesing [a] user
> written machine code [function].
>
Any idea whether the designers of ZX BASIC deliberatly left out the
"CALL" or "SYS" option, on the basis that it's absence could be worked
around, or did it just never occur to them that someone would want to
call a m/c routine withouth getting a return value? if the former, was
"RAND USR" the officially sanctioned work around? or did it just
evolve as a common practice (maybe from an early magazine listing?)
Bohus Král
"Robert Newson" <get....@bullet3.fsnet.oc.ku> napísal
>> If USR command was supposed to jump to machine code then why I cannot use
>> it alone ?
>>
>> 10 USR x
>>
>> It wouldn't affect my basic program if I don't expect any returned value.
>> It would be clear syntax to jump to machine code.
>>
>> B
>
> Because USR is a function and is thus expected to return a value. Syntax
> definition for [most if not all] BASICs require that function returns are
> used and it is an error not to use it somewhere.
>
> Your statement is like saying why can't I use SIN alone:
>
> 10 SIN x
>
> I've calculated the value of SIN x, and then thrown away the result - a
> bit of a waste of time.
>
Then most harmless usage would be :
10 GO TO USR x
I am missing in Spectrum basic some clear jump to machine code something
like
jump x
B
Andrew Halliwell
> Any idea whether the designers of ZX BASIC deliberatly left out the
> "CALL" or "SYS" option, on the basis that it's absence could be worked
> around, or did it just never occur to them that someone would want to
> call a m/c routine withouth getting a return value? if the former, was
> "RAND USR" the officially sanctioned work around? or did it just
> evolve as a common practice (maybe from an early magazine listing?)
It might've been used in the manual as an example.
But it probably just evolved as the laziest method of launching a machine
code routine with little consequence. Other ones like PRINT USR could mess
the screen up and LET A = USR took too much typing.
:)
Andrew Halliwell
> If USR command was supposed to jump to machine code then why I cannot use it
> alone ?
>
> 10 USR x
Because it is not a command.
It's a function
And the definition of a function is a routine that returns a value at the
end. There's no real difference between sin x and usr x.
And remember, the ROM in a speccy was only 16k, and they had a lot to cram
into that. Giving the USR keyword an extra twist was pointless and wasteful
of valuable bits. They only did that with a couple of keywords.
Like Screen$ and DATA being used for save/load as well as detecting
characters on screen and storing data lines.
--
| spi...@freenet.co.uk | Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell BSc | operating system originally coded for a 4 bit |
| in |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
Brian Gaff
be ultra clever to save the ram like a snapshot, forgetting I was saving
seed as well....
gulp.
Brian
--
Brian Gaff....Note, this account does not accept Bcc: email.
graphics are great, but the blind can't hear them
Email: bri...@blueyonder.co.uk
______________________________________________________________________________________________________________
"Matthew Westcott" <gas...@raww.org> wrote in message
news:6r2q12F...@mid.individual.net...
Steve Caddy
> I'm wrong or usr(x) was intended mainly for subroutines returning a
> value ? for example LET a = USR(XXXXX) return in a the value in the
> accumulator at the end of the machine code called.....
Not quite. Someone correct me if I'm wrong, but USR on the speccy returns the
value of the BC register pair. I used to use LET a=USR xxxxx a lot, because I
wrote a keyboard scanner that returned the state of 6 keys as bits 0 to 5 of
BC, thus enabling me to read more than one key at once in games written in
BASIC (so you could move diagonally, for example).
> Was also the same for IF USR, with return value evaluated as true or
> false or not ?
I'm not sure... I think there has to be an "=" because there's no boolean type
in Sinclair BASIC, however IF USR xxx = 0 THEN would probably be valid, and as
long as you put a REM or something of no consequence after the THEN, it
wouldn't matter. Of course, if the actual return value was worth testing, then
you could use the IF for something useful.
Steve
Steve Caddy
> Then most harmless usage would be :
>
> 10 GO TO USR x
Heavens no! Because if the machine code routine did end, BASIC would try to
GOTO the line number held in the BC register pair, which could be garbage, or
even invalid (greater than 9999).
As someone has already said, if the machine code routine is not intended to
end (because it's a game, rather than just a routine), then it doesn't really
matter what you do with the USR return value, even PRINT is safe. It's only
routines that terminate to return to BASIC where you have to think of what
happens to the return value. Since, in most cases, the random seed was of
little consequence, RANDOMIZE was a fair sink for the data. Other times, as in
my keyboard scanning routine, I wanted to use the number returned by USR, so I
left it in a variable.
> I am missing in Spectrum basic some clear jump to machine code something
> like
>
> jump x
I can't see why using USR, and sinking the return value somewhere that doesn't
matter, like the random seed, is a problem. If you rely on the random seed not
being damaged, then you could, just before the final RET load BC with the
seed's current value, then RANDOMIZE would set the random seed to it's present
value. Alternatively, just dump it in a variable or a dummy IF, as suggested
elsewhere.
Steve
Jules
> A couple of strange alternatives with even less of a side effect:
>
> BEEP 0, USR n
My brain just read that as "BEER 0" :(
Robert Newson
They probably didn't include a CALL option as that would require an extra
keyword, extra ROM space and another "function" on one of the keys and USR()
could be used anyway with the return value being thrown away.
No idea as to evolution of RAND USR, but someone missed out on a killing
with a software patent there... ^_^
Paul E Collins
> And then there is thhe ludo game I wrote and compiled and thought it would
> be ultra clever to save the ram like a snapshot, forgetting I was saving
> seed as well....
A related issue discussed not long ago is that, when an emulator launches a
tape file from the command line or windowing system, it is likely to load it
automatically from "time zero", so you lose your randomness.
Eq.
Paul E Collins
> however IF USR xxx = 0 THEN would probably be valid, and as long as you
> put a REM or something of no consequence after the THEN, it wouldn't
> matter.
You actually don't need anything after a THEN. It can have a zero-statement
payload.
Eq.
Paul E Collins
> Giving the USR keyword an extra twist [would have been] pointless and
> wasteful of valuable bits. They only did that with a couple of keywords.
> Like Screen$ and DATA being used for save/load as well as detecting
> characters on screen and storing data lines.
And the +3's redoubtable COPY TO SPECTRUM FORMAT.
Eq.
Geoff Wearmouth
> Any idea whether the designers of ZX BASIC deliberatly left out the
> "CALL" or "SYS" option, on the basis that it's absence could be worked
> around, or did it just never occur to them that someone would want to
> call a m/c routine withouth getting a return value? if the former, was
> "RAND USR" the officially sanctioned work around? or did it just
> evolve as a common practice (maybe from an early magazine listing?)
Sinclair BASIC was based on the 1978 ANSI Minimal standard and back
then any computer manufacturer that did not make this language
available could not tender to supply US Government departments. This
standard had adopted the POKE command as well as the PEEK and USR
functions from Microsoft BASIC.
Some BASIC ROMs had functionality only available with operating system
calls (OSC) or system calls (SYS). The Sinclair ROMS were never
designed in this way and any assembly programs were to be written by
the user.
CALL was never a part of the BASIC standard but belonged to FORTH. Two
of the programmers who designed Sinclair BASIC brought out the Jupiter
Ace in 1983.
They stuck rigidly to published standards including writing a book
embracing seven different FORTH standards.
The example in the BASIC manual used PRINT USR (n) but RANDOMIZE USR
(n) had a certain mystery and used less space. My published programs
always assigned the result to a variable.
The designers of Sinclair BASIC were always constrained by the limits
of a 40 key keyboard where every command and function must be
displayed. In fact, USR is probably the first example of an
"overloaded function" in that it behaves differently when supplied
with a (non standard) string command.
Digital Prawn
space is at a premium and the number of characters in the listing has
to be minimised at all costs, it is not unusual to find the result of
the USR being modified by an exponatiation operator and the result of
'1' being used for a useful purpose.
To cite two examples from one-liner games that were released last
year:-.
BORDER USR 7766^0
LET m(INT (RND*5)*2+1430)=USR 7766^0
Both examples effectively execute a "RANDOMIZE" via the ROM routine at
7766 without actually using the RANDOMIZE keyword, the first one also
sets the BORDER to blue at the same time.
Second one also handily does a RANDOMIZE whilst also providing a value
'1' in an expression where a '1' just happens to be needed.
Of course, code would never normally be written like this, but in "one-
liners" it is very useful to use USR to perform an action (e.g.
RANDOMIZE or the screen scroll routine) and use the (modified) result
at the same time - to keep the number of characters in the code to a
minimum.
Sometimes the result is nullified by multiplting by zero, when used in
a PRINT AT e.g.
PRINT AT 0*USR 3582+8,x;"v";
which scrolls the screen, then prints a character at the required
position.
Again, the only point of doing things this unusual way being to reduce
the overall number of characters in the entire one-liner listing.
Matthew Westcott
>> Was also the same for IF USR, with return value evaluated as true or
>> false or not ?
>
> I'm not sure... I think there has to be an "=" because there's no boolean type
> in Sinclair BASIC
Nope... Sinclair BASIC uses 0 to mean false, and 1 (or any non-zero
number) to mean true. "=" and friends are just operators that return
numbers, so you can do stuff like
IF 42 THEN PRINT "yes"
PRINT 5=6
PRINT 99 AND 1=1
Chupo
<d...@m0ng.com> says...
> I'm not sure... I think there has to be an "=" because there's no boolean type
> in Sinclair BASIC, however IF USR xxx = 0 THEN would probably be valid, and as
> long as you put a REM or something of no consequence after the THEN, it
> wouldn't matter.
>
There's no need for '=',
10 IF USR (xxxxx) THEN
would be enough to run a m/c.
--
Chupo
J D
"Jules" <jules.rich...@remove.this.gmail.com> wrote in message
news:pan.2008.12.20....@remove.this.gmail.com...
R:02 Beer Not Found., OK:01
Calum
> On the Speccy, usr("a") gives the address where UDG A is stored.
>
> Actually, that's a side question - why?
I always assumed it was simply because "usr" was a pretty reasonable
shorthand for "USeR defined graphic", so they just decided to overload it.
Lister
Arse, Tape Loading Error
J F
Arse, Tap Pouring Error surely?
Lister
Don't call me Shireley!
Jules
>>> BEEP 0, USR n
>>
>> My brain just read that as "BEER 0" :(
>
> R:02 Beer Not Found., OK:01
Gah, how is that in any way 'OK'? Where do I file a bug report?
Sam Gillett
"Lister" <fa...@SPAMclara.net> wrote ...
Hi Shirley!! ;-)
--
Best regards,
Sam Gillett
Change is inevitable,
except from vending machines!
Sam Gillett
"Jules" <jules.rich...@remove.this.gmail.com> wrote ...
At your local pub. You can file a report and correct the error at the same
time! ;-)