Limitations of RND() function
Limitations of RND() function
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:
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?
Limitations of RND() function
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.
Limitations of RND() function
It does change things up a bit. There was at least one run where there were only four pixels left.
Limitations of RND() function
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.
- svenvandevelde
- Posts: 488
- Joined: Wed Dec 23, 2020 6:30 am
- Location: Belgium, Antwerpen
Limitations of RND() function
Note that the TI function on the CX16 R41 emulator returns 0?
Limitations of RND() function
Oh wow, does it??!! LOL
Huh works over here. Maybe it depends on the ... well what? The hardware the emulator runs on??
- svenvandevelde
- Posts: 488
- Joined: Wed Dec 23, 2020 6:30 am
- Location: Belgium, Antwerpen
Limitations of RND() function
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!
Limitations of RND() function
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.
- JimmyDansbo
- Posts: 476
- Joined: Sun Apr 26, 2020 8:10 pm
- Location: Denmark
- Contact:
Limitations of RND() function
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
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
- svenvandevelde
- Posts: 488
- Joined: Wed Dec 23, 2020 6:30 am
- Location: Belgium, Antwerpen
Limitations of RND() function
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.