Limitations of RND() function

Chat about anything CX16 related that doesn't fit elsewhere
kelli217
Posts: 531
Joined: Sun Jul 05, 2020 11:27 pm

Limitations of RND() function

Post by kelli217 »


I've been messing around with the emulator a bit, playing with programs that I used to type in for fun all the time back in the day.

The first computer I ever used on a regular basis was the TRS-80 Model III down at the Radio Shack in a nearby shopping center. And it had some pseudographics commands. SET, and RESET. They're very similar to the PSET command.

The program that I am thinking about at the moment was the one for filling the screen with random pixels until the whole screen was full. It took a while, but eventually, every pixel would be filled in, and at that point I'd hit BREAK and move on to the next activity.

But while the TRS-80 BASIC would eventually fill the screen, X16 BASIC won't. Using exactly the same 128×48 grid that the old Z80 system used, trying to use the RND() function to fill the screen results in a few pixels always being left over.

I know that the available routines have a fairly short periodicity, so I tried to enhance the randomness by recursive randomizing. But still, even using RND(RND(1)*32768)*[number of pixels] for both X and Y, this is the best it will do for a 128×48 grid:

image.png.f2804e751b9e1ec0374bab1ec603a1e4.png

I ran that at top speed for an hour, and that's as far as it got. Those white pixels never get filled in. If I try to fill the entire SCREEN $80 grid of 320×240, it's much worse.

I would use RND(0) as the inner seed, but it's my understanding that it's even more repetitive, at least, going by the C64 Wiki's article on the function.

While I don't know much about the TRS-80 version of the function, and I know it's still a pseudo-random number generator, it seems to be a little better at covering a wider range of values more comprehensively.

Is this just something we're stuck with, and will just have to code our own, or is there a way to shoehorn in a better PRNG algorithm into the stock interpreter? Or is there a workaround to get better results out of the existing RND() code?

Jeff Pare
Posts: 32
Joined: Fri May 08, 2020 3:31 am

Limitations of RND() function

Post by Jeff Pare »


Waaay back when I had a Vic-20 as a kid, I learned to seed using TI, at least I think that's what I used to do. Did a bit of googling and some use the negative value as a seed: RND(-TI)

No idea if it would work on the x16 though.

 

kelli217
Posts: 531
Joined: Sun Jul 05, 2020 11:27 pm

Limitations of RND() function

Post by kelli217 »


It does change things up a bit. There was at least one run where there were only four pixels left.

rje
Posts: 1263
Joined: Mon Apr 27, 2020 10:00 pm
Location: Dallas Area

Limitations of RND() function

Post by rje »


X16 uses the Commodore RND(x) function, which uses that "x" parameter in specific unexpected ways:

https://www.c64-wiki.com/wiki/RND      <-- I use c64-wiki for all my Commodore BASIC questions!

RND(0) is never really a good idea.



RND(-TI) should be done first for a seed... but first, have the user press a key.   This effectively randomizes TI.

RND(1) is then used to fetch your random numbers.  And RND(1) or RND(17) or RND(92), and so on, all do the same thing, so RND(1).

 


Quote





  • By using RND(<positive number>) gives a different random number each time from a predetermined sequence (the sequence number is stored internally).


  • Using RND(<negative number>) jumps to a point in the sequence determined by the particular negative number used. Repeatedly calling RND with the same negative number results in the same result; typical use is to call RND(<negative number>) once and then repeatedly call RND(<positive number>).


  • With RND(0) the C64 generates the random number from the internal clock, though the possible values are limited as the digits of the clock only fall in the range 0-60, so it is not suitable for generating large ranges.




 

User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Limitations of RND() function

Post by svenvandevelde »


Note that the TI function on the CX16 R41 emulator returns 0? 

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
rje
Posts: 1263
Joined: Mon Apr 27, 2020 10:00 pm
Location: Dallas Area

Limitations of RND() function

Post by rje »


Oh wow, does it??!!   LOL

Huh works over here.  Maybe it depends on the ... well what?  The hardware the emulator runs on??

1496449776_ScreenShot2022-09-13at12_31_14AM.png.6e2556d84da26bc03113009d4b586cbd.png

 

User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Limitations of RND() function

Post by svenvandevelde »


Seeing your feedback, I immediately booted up the x16emu and the box16. And yes, they DO seem to have the TI functioning properly!

But for sure I've seen zero as a result of PRINT TI ... Not sure however what that was again, but yes, it works!

image.png.f770890b982756eb5cc884e03aa9f57a.png

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
rje
Posts: 1263
Joined: Mon Apr 27, 2020 10:00 pm
Location: Dallas Area

Limitations of RND() function

Post by rje »


I was kind of bummed when I read that TI isn't working!  I mean it's required for RND() to work.  I'm glad it works in r41 though.

 

User avatar
JimmyDansbo
Posts: 476
Joined: Sun Apr 26, 2020 8:10 pm
Location: Denmark
Contact:

Limitations of RND() function

Post by JimmyDansbo »


I thought I had seen the same issue so I fired up all releases of the emu from r31 and onwards and so far it seems that TI works in all of them, but in R39 and forwared TI$ just returns 000000

Visit my Github repo
or my personal site with CX16/C64/6502 related information.
Feel free to contact me regarding any of my projects or even about meeting up somewhere near Denmark
User avatar
svenvandevelde
Posts: 488
Joined: Wed Dec 23, 2020 6:30 am
Location: Belgium, Antwerpen

Limitations of RND() function

Post by svenvandevelde »



On 9/13/2022 at 3:30 PM, JimmyDansbo said:




I thought I had seen the same issue so I fired up all releases of the emu from r31 and onwards and so far it seems that TI works in all of them, but in R39 and forwared TI$ just returns 000000



aha! that is it yes! TI$ or TIME$ returns nothing.

KICKC home page by Jesper Gravgaard.
My KICKC alpha with Commander X16 extensions.
Post Reply