dsyleixa123
Posts: 1117
Joined: Mon Jun 11, 2018 11:22 am

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 2:45 pm

@jahboater: sorry, I don't see your point:

for the program user interface, e.g., when drawing a Lottery Sequence or starting a money transfer by a RN, the user has to manually init this task anyway e.g., by pressing a key or button to start
- so why not take this user keypress Unix time for seeding or ask for a 2nd keypress to confirm and then take the intermediate time (microseconds) for seeding a PRNG? Or both?

User avatar
jahboater
Posts: 6499
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 3:59 pm

dsyleixa123 wrote:
Tue Oct 06, 2020 2:45 pm
- so why not take this user keypress Unix time for seeding or ask for a 2nd keypress to confirm and then take the intermediate time (microseconds) for seeding a PRNG? Or both?
Of course you can do that, its a free world!
I suggest using clock_gettime() to get a nano-second resolution time.

I was just saying that keypress timings and all sorts of other things go into the Linux entropy pool anyway.
In effect, its all been done for you!

Simply reading /dev/urandom will get you a real "random" number which is better than a clock time.
And that's trivially easy, see code in an earlier post in this thread.

If you want to use the clock time, here is some code to scramble it a little:

Code: Select all

  struct timespec now;
  clock_gettime( CLOCK_REALTIME, &now );
  return ((uint64_t)now.tv_nsec << 34) | (uint64_t)now.tv_sec;
You can see its put the rapidly changing nano-second field at the most significant end.
It returns an unsigned 64-bit random-looking number.

For interest, the clock code would normally look like this:

Code: Select all

  struct timespec now;
  clock_gettime( CLOCK_REALTIME, &now );
  return (uint64_t)now.tv_sec * UINT64_C(1000000000) + (uint64_t)now.tv_nsec;
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 4:20 pm

jahboater wrote:
Tue Oct 06, 2020 3:59 pm
dsyleixa123 wrote:
Tue Oct 06, 2020 2:45 pm
- so why not take this user keypress Unix time for seeding or ask for a 2nd keypress to confirm and then take the intermediate time (microseconds) for seeding a PRNG? Or both?
Of course you can do that, its a free world! I suggest clock_gettime() to get a nano-second resolution time.

I was just saying that keypress timings and all sorts of other things go into the Linux entropy pool anyway.
In effect, its all been done for you!

Simply reading /dev/urandom will get you a real "random" number which is better than a clock time.
And that's trivially easy, see code in an earlier post in this thread.

If you want to use the clock time, here is some code to scramble it a little:

Code: Select all

  struct timespec now;
  clock_gettime( CLOCK_REALTIME, &now );
  return ((uint64_t)now.tv_nsec << 34) | (uint64_t)now.tv_sec;
You can see its put the nano-second field at the most significant end.
It returns an unsigned 64-bit random looking number.
Clock time like that is of no use for many applications. A single sample does not have enough entropy and can be brute forced in seconds to determine the seed. This was the exact problem with early implementations of SSL in many web browsers. It's not even good enough to begin a game of NetHack.

https://nethackwiki.com/wiki/Random_number_generator

For the random stuff in which you want a non-repeatable sequence of numbers that appear random /dev/urandom has my recommendation. I think the hardware built into the Pi that generates random numbers should feed into that entropy pool. If by kernel 5.x it doesn't, that's an indication in my opinion that even without any psychokinesis influence there's something wrong with it.

It should be noted, almost opposite of cryptography, there is another weird world of repeatable science in which fully deterministic sequences of numbers with suitable statistical properties are used to analyse confidence and other things in various estimators and algorithms. This has led to a whole bunch of scientists intentionally packaging up out-of-date software into containers so it can be run again later for exact verification of previous results. In this case a good pseudorandom number generator means it has the behaviour needed to sample the required probability spaces but need not be cryptographically secure.
Last edited by ejolson on Tue Oct 06, 2020 4:36 pm, edited 2 times in total.

User avatar
jahboater
Posts: 6499
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 4:33 pm

ejolson wrote:
Tue Oct 06, 2020 4:20 pm
Clock time like that is of no use for many applications. A single sample does not have enough entropy and can be brute forced in seconds to determine the seed. This was the exact problem with early implementations of SSL in many web browsers. It's not even good enough to begin a game of NetHack.
I know!! It has zero entropy I think. That's why I was suggesting /dev/urandom.
But if you look at my post, I did say "random-looking" number.
In fact the output from the scrambled clock looks like this when converted to a float between 0.0 and 1.0:

Code: Select all

0.0737289787207253
0.00378891461831399
0.448940103960455
0.896968210202873
0.398696670395554
0.848524098371387
0.358677524228812
0.805784700525225
0.321451439609051
0.771272276615024
0.294456229632021
0.74986402326566
0.241346389142097
0.674466783267678
0.0941610001896031
0.614771301944972
0.0960218599934585
0.572861017746151
As I said, random looking!
(and you cannot say what the next number in the sequence will be).
Last edited by jahboater on Tue Oct 06, 2020 4:49 pm, edited 2 times in total.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

dsyleixa123
Posts: 1117
Joined: Mon Jun 11, 2018 11:22 am

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 4:37 pm

??
I didn't suggest to use the raw time for PRNGs, I suggested to seed the Xoroshiro1024++ by retrieved time stamps

But for psycho experiments, I agree with Heater, that then only TRNGs will make sense though.

User avatar
jahboater
Posts: 6499
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 4:46 pm

dsyleixa123 wrote:
Tue Oct 06, 2020 4:37 pm
I didn't suggest to use the raw time for PRNGs, I suggested to seed the Xoroshiro1024++ by retrieved time stamps
Yes I saw that, and its fine of course.
I was just trying to suggest that seeding from an entropy source might be theoretically better (and simpler).
Intel CPU's provide the RDSEED instruction specially for seeding PRNG's for a reason.
On Linux you can use /dev/urandom where you may fill the entire state array with random numbers in one go.
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

dsyleixa123
Posts: 1117
Joined: Mon Jun 11, 2018 11:22 am

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 5:56 pm

sorry, I don't get it...
what would anyone help to recalculate the seeds of a PRNG? Finally all he will know is what was used in the past but he still cannot make predictions about what will be...?

Imagine a lottery machine which produced the winner series
1 7 8 41 43 49
by using Xoroshiro1024++
perhaps one figured out that the seed was
84672548
05624316
49383524
85746353
...
15846342
(actually the seed was taken from the actual user keypress delay, fed into a Mersenne Twister, then taken 16 Mersenne rands and then feeding them to the Xoroshiro1024++ in reverse series).

even if the hacker could reverse-engineer the code and detect the Xoroshiro1024++ and the Mersenne Twister coding and the revere series feed (no idea how he could achieve that, though) -
how would he know, which the next user reaction delay would be?
So how could he predict the next lottery numbers coming?
So how could he hack the lottery by his knowledge?

Same about cryptography...
:?

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 6:05 pm

dsyleixa123 wrote:
Tue Oct 06, 2020 5:56 pm
sorry, I don't get it...
what would anyone help to recalculate the seeds of a PRNG? Finally all he will know is what was used in the past but he still cannot make predictions about what will be...?

Imagine a lottery machine which produced the winner series
1 7 8 41 43 49
by using Xoroshiro1024++
perhaps one figured out that the seed was
84672548
05624316
49383524
85746353
...
15846342
(actually the seed was taken from the actual user keypress delay, fed into a Mersenne Twister, then taken 16 Mersenne rands and then feeding them to the Xoroshiro1024++ in reverse series).

even if the hacker could reverse-engineer the code and detect the Xoroshiro1024++ and the Mersenne Twister coding and the revere series feed (no idea how he could achieve that, though) -
how would he know, which the next user reaction delay would be?
So how could he predict the next lottery numbers coming?
So how could he hack the lottery by his knowledge?

Same about cryptography...
:?
If you are using Xoroshiro1024++ by reseeding and warming it up between each random number, this would work, but is an expensive way to whiten a physical random number source. Did you read the link about recovering the state of the random number generator used in NetHack by observing the outcomes?

dsyleixa123
Posts: 1117
Joined: Mon Jun 11, 2018 11:22 am

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 6:06 pm

tbh, I didn't: my English is too poor and there are too many characters ;)

User avatar
jahboater
Posts: 6499
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Random Number Generator Using Build In Hardware

Tue Oct 06, 2020 6:31 pm

ejolson wrote:
Tue Oct 06, 2020 6:05 pm
If you are using Xoroshiro1024++ by reseeding and warming it up between each random number, this would work, but is an expensive way to whiten a physical random number source.
Yes.
If its a decent physical random number source, it should already be conditioned, whitened, and god knows what else!
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Wed Oct 07, 2020 4:48 am

ejolson wrote:
Mon Oct 05, 2020 11:08 pm
Back on the subject of random numbers, I'm having quite a time trying to construct a 32-bit unsigned multiply function using only 16-bit 2's compliment signed integers. While the only available arithmetic operations are addition, subtraction, multiply, divide and modulus, the main difficulty so far has been a corrupt SSD caused by what appear to be memory errors on the x86 PC that serves for my desktop. Who would have known those matched DIMMs would also function as a built-in hardware random number generator when paired in dual channel mode. It appears the random numbers do not arise from a quantum source, otherwise, I might have been able to fix the fault using a simple Jedi mind trick. If only the Pi 4B supported Zoom.
I now have a pseudorandom number generator for the SuperPET written in Waterloo Pascal which faithfully reproduces the exact same sequences as the 7th edition of historic PDP-11 Unix. All testing was done using a Pi 4B with the Versatile Commodore Emulator (VICE) and the History Simulator (SIMH).

The code running on the PDP-11 was

Code: Select all

#include <stdio.h>
main(){
    srand(3141);
    printf("%u\n",rand());
    printf("%u\n",rand());
    printf("%u\n",rand());
    printf("%u\n",rand());
    printf("%u\n",rand());
    return 0;
}
and produced the output

Code: Select all

$ cc -o r7rand r7rand.c
$ ./r7rand
1568
26860
11712
19482
8069
while the code on the SuperPET was

Code: Select all

program main(output);

type int5=array [0..4] of integer;
var r7a,r7c,r7x:int5;

procedure r7init;
begin
    r7a[0]:=109; r7a[1]:=28; r7a[2]:=25; r7a[3]:=14; r7a[4]:=4;
    r7c[0]:=57; r7c[1]:=96; r7c[2]:=0; r7c[3]:=0; r7c[4]:=0;
    r7x[0]:=1; r7x[1]:=0; r7x[2]:=0; r7x[3]:=0; r7x[4]:=0;
end;

procedure r7mul(var r:int5;a,b:int5);
var i,j,c,p:integer;
begin
    c:=0;
    for i:=0 to 4 do begin
        r[i]:=c; c:=0;
        for j:=0 to i do begin
            p:=r[i]+a[i-j]*b[j];
            r[i]:=p mod 128;
            c:=c+(p div 128)
        end
    end;
    r[4]:=r[4] mod 16
end;

procedure r7add(var r:int5;a,b:int5);
var i,c,p:integer;
begin
    c:=0;
    for i:=0 to 4 do begin
        p:=a[i]+b[i]+c;
        r[i]:=p mod 128;
        c:=p div 128
    end
end;

procedure r7seed(x:integer);
begin
    if(x>=0) then begin
        r7x[0]:=x mod 128;
        x:=x div 128;
        r7x[1]:=x mod 128;
        x:=x div 128;
        r7x[2]:=x mod 4;
        r7x[3]:=0; r7x[4]:=0
    end else begin
        x:=x+16384+16384;
        r7x[0]:=x mod 128;
        x:=x div 128;
        r7x[1]:=x mod 128;
        x:=(x div 128)+2;
        r7x[2]:=x mod 4;
        r7x[3]:=0; r7x[4]:=0
    end
end;

function r7rand:integer;
begin
    r7mul(r7x,r7x,r7a);
    r7add(r7x,r7x,r7c);
    r7rand:=(r7x[2] div 4)+r7x[3]*32+(r7x[4] mod 8)*4096
end;

begin
    r7init;
    r7seed(3141);
    writeln(r7rand);
    writeln(r7rand);
    writeln(r7rand);
    writeln(r7rand);
    writeln(r7rand);
end.
and produced the output

Image

Woohoo! That's the exact same sequence, no psychokinetics needed!

Irritatingly, the random numbers took about one second each to generate. Still, reproducing the same sequence is an important step in making a version of Hunt the Wumpus with correct game dynamics for the SuperPET on Fido's birthday. Moreover, both emulators are using the built in hardware (namely the ALU) of the Raspberry Pi to generate random numbers.

If anyone sees a way to improve the speed of this pseudorandom number generator while staying within the constraints of using only the five arithmetic operators addition, subtraction, multiplication, division and modulus acting on 16-bit two's complement arithmetic, that would be very much appreciated.
Last edited by ejolson on Wed Oct 07, 2020 6:41 pm, edited 1 time in total.

Heater
Posts: 17116
Joined: Tue Jul 17, 2012 3:02 pm

Re: Random Number Generator Using Build In Hardware

Wed Oct 07, 2020 5:18 pm

ejolson wrote:
Wed Oct 07, 2020 4:48 am
I now have a pseudorandom number generator for the SuperPET written in Waterloo Pascal which faithfully reproduces the exact same sequences as the 7th edition of historic PDP-11 Unix.

Woohoo! That's the exact same sequence, no psychokinetics needed!
Man that is spooky. Random numbers from the dead.
Memory in C++ is a leaky abstraction .

dsyleixa123
Posts: 1117
Joined: Mon Jun 11, 2018 11:22 am

Re: Random Number Generator Using Build In Hardware

Wed Oct 07, 2020 5:27 pm

maths are not supposed to change even when resurrected from graves ;)

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Thu Oct 08, 2020 2:32 am

Heater wrote:
Wed Oct 07, 2020 5:18 pm
ejolson wrote:
Wed Oct 07, 2020 4:48 am
I now have a pseudorandom number generator for the SuperPET written in Waterloo Pascal which faithfully reproduces the exact same sequences as the 7th edition of historic PDP-11 Unix.

Woohoo! That's the exact same sequence, no psychokinetics needed!
Man that is spooky. Random numbers from the dead.
I now have a random graph generator written in Pascal which creates the exact same mazes as the 7th edition of Unix, though I think Ken's C code actually predates the 6th edition. As the construction of random graphs is somewhat tangential to random number generators in general, I'll continue the discussion of creating a birthday present for the SuperPET in a separate thread.

I'd agree it's a bit spooky. It's almost as if the original creator of Hunt the Wumpus has come back to life after having been cryogenically frozen.

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Thu Oct 08, 2020 8:56 pm

ejolson wrote:
Wed Oct 07, 2020 4:48 am
If anyone sees a way to improve the speed of this pseudorandom number generator while staying within the constraints of using only the five arithmetic operators addition, subtraction, multiplication, division and modulus acting on 16-bit two's complement arithmetic, that would be very much appreciated.
Seeing that you're using pascal integers (int16_t) to emulate unsigned 7 bit values in all the r7xxx functions and given that you are targetting an 8 bit architecture, wouldn't using uint8_t be faster?

As in:

Code: Select all

type int5=array [0..4] of BYTE;
Not faster, but shorter:

Code: Select all

procedure r7seed(x:integer);
begin
    if(x<0) then
        x:=x+16384+16384;
    r7x[0]:=x mod 128;
    x:=x div 128;
    r7x[1]:=x mod 128;
    x:=x div 128;
    r7x[2]:=x mod 4;
    r7x[3]:=0;
    r7x[4]:=0
end;

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Thu Oct 08, 2020 9:20 pm

lurk101 wrote:
Thu Oct 08, 2020 8:56 pm
ejolson wrote:
Wed Oct 07, 2020 4:48 am
If anyone sees a way to improve the speed of this pseudorandom number generator while staying within the constraints of using only the five arithmetic operators addition, subtraction, multiplication, division and modulus acting on 16-bit two's complement arithmetic, that would be very much appreciated.
Seeing that you're using pascal integers (int16_t) to emulate unsigned 7 bit values in all the r7xxx functions and given that you are targetting an 8 bit architecture, wouldn't using uint8_t be faster?

As in:

Code: Select all

type int5=array [0..4] of BYTE;
I think you are right. The constraint I've been working with is for the code to run under Waterloo microPascal

https://archive.org/details/Super_PET_W ... icroPascal

for the SuperPET; however, I think it may be possible to create a 6809 assembler routine using bit shifts and the Russian peasant algorithm callable from Pascal. I don't exactly know how to do this.

I'm using the development branch of VICE, because it emulates the CBM dual floppy drives more sensibly and because SuperPET emulation is a relatively new feature. In particular, the 6809 is not cycle accurate while the 6502 has been for a long time.

https://vice-emu.sourceforge.io/

If you have any trouble building VICE for the Pi 4B let me know and I'll post my configuration with what extra packages need to be installed.

In other news, the Pascal version of Hunt the Wumpus is passing the unit tests I already had, but playing the game in lock step with the SIMH PDP-11 version is still uncovering a few inconsistencies. So far, at least, the random number generators are staying synchronized.

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Thu Oct 08, 2020 9:50 pm

I'm not familiar with Commodore vintage and had assumed the Super Pet was a classic 6502 implementation. An AND operator could nicely replace the modulus operator, but I suspect the Waterloo compiler is smart enough to do that optimization. Even the 6502 had shift operations for multiplies and divides by powers of 2.

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Thu Oct 08, 2020 10:00 pm

ejolson wrote:
Thu Oct 08, 2020 9:20 pm
If you have any trouble building VICE for the Pi 4B let me know and I'll post my configuration with what extra packages need to be installed.
Thanks but the Pis all run headless.

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 12:14 am

lurk101 wrote:
Thu Oct 08, 2020 10:00 pm
ejolson wrote:
Thu Oct 08, 2020 9:20 pm
If you have any trouble building VICE for the Pi 4B let me know and I'll post my configuration with what extra packages need to be installed.
Thanks but the Pis all run headless.
I'm actually running VICE on a Pi that has no monitor. In my opinion, it should be possible (but isn't) to emulate a SuperPET using an xterm after loading a suitable PETSCII font. However, it seems many people are interested in playing graphical Commodore C64 games.

The way I am currently running VICE is through xorgxrdp so that I can connect to the Pi using Remote Desktop or xfreerdp from a Linux PC. One could also use RealVNC, which is a proprietary package that comes with Raspberry Pi OS.

Since the Raspberry Pi originated as a inexpensive computer for education, I think it is interesting that the SuperPET also originated to provide an inexpensive environment for students to learn programming. There are few machines that have such a history. Not only did the Waterloo language package allow people to develop software that could later run on more capable machines, but the SuperPET included a built-in capability to allow those programs to be transparently stored on a remote machine and accessed as local files if so desired.

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 1:01 am

ejolson wrote:
Fri Oct 09, 2020 12:14 am
lurk101 wrote:
Thu Oct 08, 2020 10:00 pm
ejolson wrote:
Thu Oct 08, 2020 9:20 pm
If you have any trouble building VICE for the Pi 4B let me know and I'll post my configuration with what extra packages need to be installed.
Thanks but the Pis all run headless.
I'm actually running VICE on a headless Pi as well. In my opinion, it should be possible (but isn't) to emulate a SuperPET using an xterm after loading a suitable PETSCII font. However, it seems many people are interested in graphical Commodore C64 games.

The way I am currently running VICE is through xorgxrdp so that I can connect to the Pi using Remote Desktop or xfreerdp from a Linux PC. One could also use RealVNC, which is a proprietary package that comes preinstalled with Raspberry Pi OS.

Since the Raspberry Pi originated as a inexpensive computer for education, I think it is interesting that the SuperPET also originated to provide an inexpensive environment for students to learn programming. There are few machines that have such a history. Not only did the Waterloo language package allow people to develop software that could later run on more capable machines, but the SuperPET included a built-in capability to allow those programs to be transparently stored on a remote machine and accessed as local files if so desired.
Not sure why I'd want to emulate an 8 bit micro on the Pi?

This may not be a popular opinion hereabouts but I still prefer using the Windows desktop where I can. So if I need to run a graphical Unix thing I'll just remote an X session using MobaXtrem which incorporates an well integrated X server for Windows. Pi desktop apps render just fine. Would that work for Vice?

In any case I go here for the most accurate retro emulation. Many of the classics such as Apple and Pet are included. The 6809 core if featured in the Vectrex emulator as well a some of the arcade stuff.

ejolson
Posts: 6320
Joined: Tue Mar 18, 2014 11:47 am

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 3:56 am

lurk101 wrote:
Fri Oct 09, 2020 1:01 am
ejolson wrote:
Fri Oct 09, 2020 12:14 am
lurk101 wrote:
Thu Oct 08, 2020 10:00 pm

Thanks but the Pis all run headless.
I'm actually running VICE on a headless Pi as well. In my opinion, it should be possible (but isn't) to emulate a SuperPET using an xterm after loading a suitable PETSCII font. However, it seems many people are interested in graphical Commodore C64 games.

The way I am currently running VICE is through xorgxrdp so that I can connect to the Pi using Remote Desktop or xfreerdp from a Linux PC. One could also use RealVNC, which is a proprietary package that comes preinstalled with Raspberry Pi OS.

Since the Raspberry Pi originated as a inexpensive computer for education, I think it is interesting that the SuperPET also originated to provide an inexpensive environment for students to learn programming. There are few machines that have such a history. Not only did the Waterloo language package allow people to develop software that could later run on more capable machines, but the SuperPET included a built-in capability to allow those programs to be transparently stored on a remote machine and accessed as local files if so desired.
Not sure why I'd want to emulate an 8 bit micro on the Pi?

This may not be a popular opinion hereabouts but I still prefer using the Windows desktop where I can. So if I need to run a graphical Unix thing I'll just remote an X session using MobaXtrem which incorporates an well integrated X server for Windows. Pi desktop apps render just fine. Would that work for Vice?

In any case I go here for the most accurate retro emulation. Many of the classics such as Apple and Pet are included. The 6809 core if featured in the Vectrex emulator as well a some of the arcade stuff.
That's an interesting idea to use FPGA's to emulate historic hardware. It looks like the SuperPET is not among the PET variants, which is not surprising, as it had both 6502 and 6809 processors working together along with some weird bank switching to run pretty complete implementations of Pascal, Fortran, COBOL and APL among other things. I suspect it might be possible to run that Waterloo language package on simpler hardware, as it was directly derived from a previous 6809 system called the MicroWat. Though slow, I'm pretty impressed with how well Waterloo MicroPascal functions.

Apparently there's a generation of programmers who learned on these systems. I enjoyed the original PET when it first came out, but never tried the SuperPET until it was emulated on a Pi. I think the reason people emulate 8-bit microcomputers on a Pi is because it's is much cheaper than finding authentic hardware in working condition, because a Xeon workstation takes too much electricity, and in order to generate historically accurate random numbers.

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 4:42 am

ejolson wrote:
Fri Oct 09, 2020 3:56 am
Though slow, I'm pretty impressed with how well Waterloo MicroPascal functions.
Waterloo, my alma matter. :D
... and in order to generate historically accurate random numbers.
Would you have the source code for the 7th edition's historic PDP-11 Unix version of the rand function?

User avatar
jahboater
Posts: 6499
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 1:30 pm

lurk101 wrote:
Fri Oct 09, 2020 4:42 am
ejolson wrote:
Fri Oct 09, 2020 3:56 am
... and in order to generate historically accurate random numbers.
Would you have the source code for the 7th edition's historic PDP-11 Unix version of the rand function?
@ejolson posted this earlier in the thread:

Code: Select all

return(((randx = randx*1103515245 + 12345)>>16) & 077777);
It seems to rely on the overflow of signed integers which is frowned upon these days :)
Pi4 8GB and Pi4 4GB running Raspberry Pi OS 64-bit

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 1:50 pm

It occurs to me that GCC back ends have been written for 8 bit processors, AVR for example. It should be feasible for 6502 though not in time for Fido's birthday. Imagine, a standard C++ compiler for 6502! Could there be a slower way to generate random numbers?

lurk101
Posts: 355
Joined: Mon Jan 27, 2020 2:35 pm

Re: Random Number Generator Using Build In Hardware

Fri Oct 09, 2020 1:57 pm

jahboater wrote:
Fri Oct 09, 2020 1:30 pm
lurk101 wrote:
Fri Oct 09, 2020 4:42 am
ejolson wrote:
Fri Oct 09, 2020 3:56 am
... and in order to generate historically accurate random numbers.
Would you have the source code for the 7th edition's historic PDP-11 Unix version of the rand function?
@ejolson posted this earlier in the thread:

Code: Select all

return(((randx = randx*1103515245 + 12345)>>16) & 077777);
It seems to rely on the overflow of signed integers which is frowned upon these days :)
The PDP11 code, not the pascal code.

Return to “C/C++”