For my line drawing program, I would like to generate some random coordinates but I am not sure on how to make a RNG. I read online that the function for a LCG is defined as
Xn+1 = ( A*Xn + C) mod M
Where
M > 0
A>0 and A<M
C>=0 and C<M
Seed>=0 and Seed<M
What I am not sure about is what the A and C should be. I tried to understand the math gobbledygook but really don't have the time nor the inclination to do a deep dive into random number theory. Is there a simpler way or maybe someone could maybe explain it to me in a better fashion?
I am working in 320 x 200 mode so my random coordinates need to be in that range.
Tim
I came across a Linear Feedback Shift Register RNG and it seemed simple enough to implement and seems to work ok. However, when I pass the values to my PlotLine function, it only draws a single random pixel. I ran it through a debugger and it seems to pass the values to PlotLine correctly. If I pass the values generated by my RNG as a constant to PlotLine, it draws the line fine so I am unsure why it is not working properly. I have attached my source code and program if someone wants to take a look at it to see if they spot what is happening.
RNG Code
RNDNumber proc modulus:word
mov ah, 0
int 1ah
; LFSR routine
; ------------
; 1. Seed value
; 2. XOR bits 0 and 1 of the Seed
; 3. Shift seed right by 1
; 4. Add result 2. to most significant bit after shifting seed
; 5. Divide by modulus
; 6. Move remainder in AX as return value
mov ax, dx ; save dx
mov cx, dx ; create a copy of dx
and cx, 1 ; clear bits except bit 0
and dx, 2 ; clear bits except bit 1
shr dx, 1 ; shift dx right by 1 to XOR bits in cx and dx
xor cx, dx ; XOR bits
shl cx, 15 ; set most significant bit
shr ax, 1 ; shift ax right by 1
xor ax, cx ; XOR to set most significant bit
div modulus
mov ax, dx
ret
RNDNumber endp
Well, since the RNG code looks OK (and even if it doesn't work it shouldn't matter, as it's just returning a value in AX anyhow), the problem must be in how you're passing this value to your line-drawing routine. You say it works if you pass a constant value: are you sure you're passing x- and y-coordinates correctly?
How often do you call the generator? INT 1A returns the low tick count in DX, but the tick count is only updated 18.2 times per second. If you are too quick, you will get the same value in DX since the timer wasn't triggered.
Simplest RNG used in infinished Perkin noise
https://masm32.com/board/index.php?topic=7324.0
Fast low quality RNG
Quote from: NoCforMe on June 04, 2024, 02:29:07 PMWell, since the RNG code looks OK (and even if it doesn't work it shouldn't matter, as it's just returning a value in AX anyhow), the problem must be in how you're passing this value to your line-drawing routine. You say it works if you pass a constant value: are you sure you're passing x- and y-coordinates correctly?
In debug, it is storing the lx1, ly1, lx2, ly2 in memory after RNDNumber returns and then when I call PlotLine, it shows these values being pushed on the stack before call.
Quote from: sinsi on June 04, 2024, 03:20:12 PMHow often do you call the generator? INT 1A returns the low tick count in DX, but the tick count is only updated 18.2 times per second. If you are too quick, you will get the same value in DX since the timer wasn't triggered.
This is the code
invoke RNDNumber, 320
mov lx1, ax
invoke RNDNumber, 320
mov lx2, ax
invoke RNDNumber, 200
mov ly1, ax
invoke RNDNumber, 200
mov ly2, ax
Quote from: daydreamer on June 04, 2024, 03:24:45 PMSimplest RNG used in infinished Perkin noise
https://masm32.com/board/index.php?topic=7324.0
Fast low quality RNG
Thanks I will check it out. This LFSR supposedly has a long period before it repeats. The only problem is maybe getting a zero output. I don't think it will be zero at any point but I will have to write a new program to test for randomness.
Tim
AX is the wrong value to use from INT 1A, you should be using DX
INT 1Ah, 00h (0) Read System-Timer Time Counter all
Reports the current time of day, and whether 24 hours has passed since
1) the last power-on, 2) the last system reset, or 3) the last system-
timer time read or set.
On entry: AH 00h
Returns: CX High-order part of clock count
DX Low-order part of clock count
AL 0 if 24 hours has not passed; else 1
As you can see, AX is probably always going to be 0 (assuming the BIOS doesn't change AH).
Quote from: sinsi on June 04, 2024, 10:42:56 PMAX is the wrong value to use from INT 1A, you should be using DX
INT 1Ah, 00h (0) Read System-Timer Time Counter all
Reports the current time of day, and whether 24 hours has passed since
1) the last power-on, 2) the last system reset, or 3) the last system-
timer time read or set.
On entry: AH 00h
Returns: CX High-order part of clock count
DX Low-order part of clock count
AL 0 if 24 hours has not passed; else 1
As you can see, AX is probably always going to be 0 (assuming the BIOS doesn't change AH).
I use dx but I put a copy of dx in ax to save original value of dx. Or am mixing up what you said?
Tim
Quote from: tda0626 on June 04, 2024, 11:53:26 PMI use dx but I put a copy of dx in ax to save original value of dx. Or am mixing up what you said?
My mistake, sorry.
Quote4. Add result 2. to most significant bit after shifting seed
That's a bit ambiguous, shifting seed how many times? In which direction? I don't see an Add anywhere either.
You might want to zero DX before dividing as well.
Quote from: sinsi on June 05, 2024, 12:26:21 AMQuote from: tda0626 on June 04, 2024, 11:53:26 PMI use dx but I put a copy of dx in ax to save original value of dx. Or am mixing up what you said?
My mistake, sorry.
Quote4. Add result 2. to most significant bit after shifting seed
That's a bit ambiguous, shifting seed how many times? In which direction? I don't see an Add anywhere either.
You might want to zero DX before dividing as well.
No worries, sir.
I hastily wrote the explanation. You are right though it doesn't explain it concretely. It should probably say
Shift seed right by 1 then take result from step 2 and put the bit to the new shifted value's most significant bit.
Thanks for tip. Will zero out dx before div operation.
Tim
Quote from: tda0626 on June 05, 2024, 12:57:36 AMShift seed right by 1 then take result from step 2 and put the bit to the new shifted value's most significant bit.
In that case you want
or ax,cx, not
xor.
Quote from: sinsi on June 05, 2024, 01:09:18 AMQuote from: tda0626 on June 05, 2024, 12:57:36 AMShift seed right by 1 then take result from step 2 and put the bit to the new shifted value's most significant bit.
In that case you want or ax,cx, not xor.
Oops!
For seed,dosbox supports rdtsc,clock cycles in edx:eax
Check out hutch random pad,64 bit
Inspired me to make two different 128 bit prng
But must have test tool for all prng coders is John walkers ENT program
It analysis entropy = quality of your prng output
Well how unique random number sequence is
Quote from: daydreamer on June 05, 2024, 05:13:40 AMFor seed,dosbox supports rdtsc,clock cycles in edx:eax
Um, <cough> <cough> 16-bit programming???
Hi,
Quote from: NoCforMe on June 05, 2024, 06:20:02 AMQuote from: daydreamer on June 05, 2024, 05:13:40 AMFor seed,dosbox supports rdtsc,clock cycles in edx:eax
Um, <cough> <cough> 16-bit programming???
32-bit code works perfectly well in real mode. Not
sure about specific instructions though. But the general
purpose 32-bit registers can be useful with the normal
math and logical instructions. And it can be fun to muck
about with them to see if you can write useful code. The
32-bit addressing is normally limited to a 64k range, but
can also be used.
Cheers,
Steve N.
I guess I was thinking of the die-hard DOS programmer pecking away on their still-running PC or XT, green-screen monitor and everything.
It's perfectly valid to use a 32-bit register to access memory in real mode, you just have to be careful that the high 16-bits are zero,
e.g. MOV ECX,[EAX+EDX*4+1000h] is OK (assuming the address computes to <64K).
Like Steve said, instead of mucking around with DX:AX for 32-bit numbers we can use one 32-bit register or (gasp) 64-bit maths with EDX:EAX :cool:
The assembler has to support 32-bit instructions, too.
This has me perplexed. Wrote a little program to output some random numbers but it is doing some weird stuff right after my
div dx instruction. It starts randomly executing code right after the instruction, see pictures below. The unassembled code segment shows my
add dx, 30 but never executes it. I have attached my source to this post too. What in the world is happening?
(https://i.postimg.cc/Lggpr8RQ/Capture.jpg) (https://postimg.cc/Lggpr8RQ)
(https://i.postimg.cc/gxHnMNgX/Capture2.jpg) (https://postimg.cc/gxHnMNgX)
You are trying to divide DX:AX by DX, in this case 000a0012h / 000ah, which overflows.
Use a register other than DX.
Wait a second:
I understand the overflow problem.
But isn't it perfectly valid to divide by DX, provided it doesn't result in an overflow?
In other words, the problem isn't dividing by DX, it's the values being divided, right?
Scratch that. (E)DX is the last register you'd want to use as a divisor. Because it holds the high word/dword of the dividend.
You're right. Don't use it!
Does the same thing when I change it to CX. I was under the assumption that it would return AX=0 if the number was less than 10 and put the remainder in DX. Guess not.
Did you remember to set DX to zero? Remember, DIV does DX:AX / {dividend}.
Quote from: NoCforMe on June 05, 2024, 09:46:44 AMDid you remember to set DX to zero? Remember, DIV does DX:AX / {dividend}.
LOL these little mistakes drive you crazy but I am learning from them. You are right. I XOR DX, DX and it works somewhat but doesn't print out the right characters. Prints out a triangle and some other garbage. The correct values are written to the memory location though when I dump the memory. DOS function AH=9 21h just doesn't print the right stuff.
numstring DB 0,0,32,'$'
mov ah, 9
mov dx, offset numstring
int 21h
... and of course with INT 21/AH=9 you need to remember to terminate the string with a "$".
(What a weird terminator; how'd they come up with that? What if you want to print a dollar sign in the string?)
I am on a roll tonight with blunders :biggrin: . I was adding 30 decimal to make it an ASCII number instead of 30h, which was the reason for the weird characters. Now just need figure out why my loop exit check isn't working.
Easy way to remember the binary--> ASCII numeric conversion thing:
MOV AL, number
ADD AL, '0'
No need to remember any hexadecimal #s.
Quote from: tda0626 on June 05, 2024, 10:22:39 AMNow just need figure out why my loop exit check isn't working.
You start with CX=1000 and increment it after each loop, did you mean to decrement it?
I'm not sure if the sign flag is the one you should be testing, maybe the carry or zero flag?
Yep I saw that earlier and fixed it. Got it to work finally but the period is only 15 before it starts repeating again so it does not work. Guess I need to maybe do another method or read up more on LFSR.
About your loops:
You might want to use the LOOP instruction.
When you know exactly how many iterations you want, it makes things much easier.
You set (E)CX to the loop count.
At the bottom of the loop you code the LOOP instruction with the jump target of the loop.
LOOP automagically decrements (E)CX, compares it to zero, jumps to the loop target if not.
Saves you a little bit of bookkeeping.
MOV CX, loopCount
lp: ; do stuff
; do more stuff
LOOP lp
Only "gotcha" is that it's only good for short distance loops (max. 127 bytes of code).
There are even 2 more flavors of this instruction, LOOPE/Z and LOOPNE/Z that will loop while equal (zero flag set) or not equal, from an operation that sets that flag before the LOOP instruction.
The 8086/8088 was an awesome little machine.
Quote from: NoCforMe on June 05, 2024, 11:38:36 AMYou might want to use the LOOP instruction.
...You set (E)CX to the loop count.
Only "gotcha" is that it's only good for short distance loops (max. 127 bytes of code).
And you cannot use CX within the loop (without some form of preserving it of course)... :smiley:
Right, good point.
A lot of times I use LOOP even in Win32 programming where various functions trash ECX.
Really easy fix for that, and something I do a lot:
MOV ECX, loopCount
lptop: PUSH ECX
INVOKE <some Win32 function that trashes ECX>
INVOKE <yet another Win32 function)
. . . .
POP ECX
LOOP lptop
That was from experience, btw. Not recently though, was years ago.
You mean you screwed up and changed CX inside a loop?
Tsk, tsk.
Quote from: NoCforMe on June 05, 2024, 12:51:41 PMYou mean you screwed up and changed CX inside a loop?
No it was ecx + was my first time using loop instruction.
Quote from: FORTRANS on June 05, 2024, 08:02:57 AM32-bit code works perfectly well in real mode. Not
sure about specific instructions though. But the general
purpose 32-bit registers can be useful with the normal
math and logical instructions. And it can be fun to muck
about with them to see if you can write useful code. The
32-bit addressing is normally limited to a 64k range, but
can also be used.
Besides 32 bit dos extender,there is a load instruction to load both 64k part and segment reg from 1 meg adress
You could use some of upper 16 bit half too eax, bitshift and Mov ds,ax
I found it convenient that 320 evenly divided by 16 when changing segment reg to "scroll" vertical
Old optimisation tutorials on bigger registers when copy /fill memory = faster work also in dosbox, try rep Movsd and rep stosd instead of Movsd and stosb
Quote from: NoCforMe on June 05, 2024, 11:38:36 AMAbout your loops:
You might want to use the LOOP instruction.
When you know exactly how many iterations you want, it makes things much easier.
You set (E)CX to the loop count.
At the bottom of the loop you code the LOOP instruction with the jump target of the loop.
LOOP automagically decrements (E)CX, compares it to zero, jumps to the loop target if not.
Saves you a little bit of bookkeeping.
MOV CX, loopCount
lp: ; do stuff
; do more stuff
LOOP lp
Only "gotcha" is that it's only good for short distance loops (max. 127 bytes of code).
There are even 2 more flavors of this instruction, LOOPE/Z and LOOPNE/Z that will loop while equal (zero flag set) or not equal, from an operation that sets that flag before the LOOP instruction.
The 8086/8088 was an awesome little machine.
Thanks. I will see about using that in my code going on. How can you tell if you are over the 127 byte limit?
I reprogrammed my RNG and got it to work. I used a XORShift LFSR using the triplet 7,9,8. It was the only triplet I could find that was for 16 bits. Most of the documentation on the subject was directed towards 32 and 64 bit triplets. Supposedly, this triplet combination has a period of 65,535. I ran it through some randomness tests and it seems to work pretty good from what I can tell. Did a random line test by drawing 500 lines and I can't see any patterns emerging, see picture below. I don't know, what do you guys think? Check out the code below...
(https://i.postimg.cc/JHkP9Xqn/Capture.jpg) (https://postimg.cc/JHkP9Xqn)
.data
mainseed DW 0
rand DW 0
.code
RNDNumber proc modulus:word, seed:word
mov ax, seed ; seed = seed XOR ( seed << 7 )
shl ax, 7
xor ax, seed
mov seed, ax
mov ax, seed ; seed = seed XOR ( seed >> 9 )
shr ax, 9
xor ax, seed
mov seed, ax
mov ax, seed ; mainseed = seed XOR ( seed << 8 )
shl ax, 8
xor ax, seed
mov mainseed, ax ; use mainseed to seed the next call to RNDNumber
xor dx, dx
div modulus
mov rand, dx ; Store remainder
ret
RNDNumber endp
Quote from: tda0626 on June 06, 2024, 08:25:05 AMHow can you tell if you are over the 127 byte limit?
The assembler will let you know:
QuoteJump destination too far by XX bytes
Easy fix, though: instead of
MOV CX, loop count
lptop: . . . .
. . . .
LOOP lptop
do this:
MOV CX, loop count
lptop: . . . .
. . . .
DEC CX
JNZ lptop
which will work for longer distances.
Thanks!