|  Post Your Message | |
| |
| | Previous Messages | Posted By
Ati
on 2011-03-02
14:45:37
|  Re: Random for Real
I made anno a random generator in Minesweeper. I used a TED timer too.
|
|
Posted By
NinjaDRM
on 2011-03-01
05:14:56
| Re: Random for Real
http://xkcd.com/221/ 
SID's white noise is also "only" a LFSR, so not a big loss when it is not available. For "demo-randomness", I usually do a variation of a 8-bit PRNG as described on codebase64 and write it to a table.
|
|
Posted By
TLC
on 2011-02-28
16:16:12
| Re: Random for Real
He must be talking about the "timer stop condition fadeout" effect... at least that's what comes to mind.
Explaining that needs the knowledge of two basic things: 1.) how some of the internal flip-flops of the TED are implemented, and 2.) the way the TED timers are intended to work.
1.) -- some internal bits of the TED are implemented similar-ish to dynamic ram cells (ie. they need to be accessed from time to time in order to keep their state). The best known example is the internal state flip-flop of the TED sound generator (ie. the flip-flop toggled by the counter of the sound generator). Normally, this flip-flop is toggled at least once in 1024*4 single clock cycles. The special sound freq value of $03fe locks up the toggling logic, leaving the flip-flop without access for arbitrary time. Now, the flip-flop will "fadeout" in some 10 or 100msec, ultimately ending up in "1" state. It's possible to write a testprogram which reproduces the effect. Also, sampling the sound output while the fadeout happens will reveal some noise which very noticeably resembles the video timing's frequency components -- which is due to the fact that somewhere _inbetween_ the two stable states, the flip-flop floats, and its state will be interpreted as 0 or 1, depending on the interference received from the neighbouring circuits ie. the other subparts of the TED silicon die.
2.) TED timers can be programmed like this: write timer LO, then timer stops; then write timer HI, timer starts.
The trick here is similar to the previous one -- the flip-flop which inhibits the countdown of the TED timers is "dynamic". Ie. if you write timer LO and just shut up, then the timer will wait for a while -- and after some time, it'll start counting down eventually. This "some time" is highly non-predictable -- you can't really predict "when" the inhibiting flip-flop fades out, since it's an analog measure, depending on chip, voltage, temperature (...although it will likely kick in at around some typical position of the screen first, due to the fact that this moment will be "modulated" by the noise emitted by the TED circuits, similarly to the sound experiment).
I did experiment with this sometime a year and a half ago (if memory serves well). Polling the timer AFAIR didn't work, but setting an interrupt on the timer, and measuring the time spent until the IRQ hit using another timer just did.
|
|
Posted By
IstvanV
on 2011-02-28
09:01:11
| Re: Random for Real
Another version of the above routine, with a 23-bit LFSR. The quality is improved, although still not quite perfect. However, it is slower (40 cycles without the JSR and RTS, but maybe it can be optimized).
. 2100 A5 D1 LDA $D1
. 2102 AA TAX
. 2103 4A LSR
. 2104 A5 D0 LDA $D0
. 2106 4D 02 FF EOR $FF02
. 2109 85 D1 STA $D1
. 210B 6A ROR
. 210C 85 D0 STA $D0
. 210E 8A TXA
. 210F 0A ASL
. 2110 A5 D2 LDA $D2
. 2112 2A ROL
. 2113 86 D2 STX $D2
. 2115 45 D0 EOR $D0
. 2117 85 D0 STA $D0
. 2119 60 RTS
|
|
Posted By
SVS
on 2011-02-28
09:00:28
 | Re: Random for Real
I used to read $FF02 $FF03 and never had a double number.
Real to obtain a doubled (or predictable) value, your routine should have a timing exactly the multiple of the tick. Anyway if you have a conditional statement this never should happen IMO.
|
|
Posted By
IstvanV
on 2011-02-28
08:28:46
| Re: Random for Real
This very simple code I have tried combines the use of a timer ($FF02) and a 15-bit LFSR:
. 2100 A5 D0 LDA $D0
. 2102 4D 02 FF EOR $FF02
. 2105 AA TAX
. 2106 0A ASL
. 2107 A5 D1 LDA $D1
. 2109 2A ROL
. 210A 86 D1 STX $D1
. 210C 45 D1 EOR $D1
. 210E 85 D0 STA $D0
. 2110 60 RTS
. 2000 78 SEI
. 2001 20 00 21 JSR $2100
. 2004 8D 19 FF STA $FF19
. 2007 4C 01 20 JMP $2001
It takes 25 cycles to execute without the JSR/RTS. The quality of the generated random numbers is probably not very good for serious uses, but this algorithm could be usable in a game or demo.
Some quick tests I have done on it: a sample of 1000000 bytes of output could not be compressed with various compressors I have tried. With a 10000000 byte sample, 7-Zip was able to reduce the size by about 1.5%. On the larger sample, 3 of the 15 "DIEHARD" randomness tests (5, 6, 7) have obviously failed, while about 2 more looked not very good; however, it is not easy to write a routine consisting of only a few 6502 instructions that passes all of these tests.
Of course, since it uses a timer, the intervals at which the code is called have an effect on the quality of the randomness: it could be worse, but also better (e.g. if not called in a simple loop, but rather more "randomly"). Replacing the EOR $FF02 with something else may also have a useful effect.
The X register can be used for 16-bit output, but it is just an EOR between the previous value and the timer, so it is not as good as calling the routine twice.
|
|
Posted By
Luca
on 2011-02-28
06:57:46
 | Re: Random for Real
On other forums, someone pointed out this (he added he heard about that from Dave Haynie):
"Commodore tried to make "more random" numbers on the 264 series of computers (C16, C116 and plus/4) by adding a funny feature to the TED chip: There's kind of an antenna around the chip die, which picks up the radio waves generated by the chip itself, and that feeds a register that can be read by the CPU. However, I'd also say that it's not truly random, because it will heavily depend on the displayed gfx and the code that's currently executed. It'll be fuzzy, but surely not random, because there are reproducable dependencies - again, not suitable as a random seed for a cryprographic algorithm."
Ok, which's the antenna register?
|
|
Posted By
Chicken
on 2009-03-16
08:10:35
 | Re: Random for Real
Luca...
Are you playing back the digis with the first timer ($ff00/1)? Then you'll probably end up with the same values over and over again because you are fetching the registers at the same position(s). Same for $ff1e (as Gaia already pointed out).
If I'm not sure the values I want are matching my expactations I usally do something like this (crude example just for illustrating what I mean):
0 GRAPHIC 1,1
1 X=PEEK(DEC("FF1E"))
2 Y=PEEK(DEC("FF1D"))
3 DRAW 1,X,Y
4 GOTO 1
You can tell, that there are the same values after a couple of loops... Try pressing some keys for a change then
|
|
|
|
Posted By
Chronos
on 2009-03-15
16:28:57
 | Re: Random for Real
my addition to the topic 
..
sta $ff3e
jsr $a725 or jsr $a70e
sta $xxxx
..
|
|
Posted By
Gaia
on 2009-03-15
08:11:42
| Re: Random for Real
Here's a good read for a start
http://random.org/
Generating pseudo random numbers that stand the statistical test of independence to a certain degree of confidentiality is not a straightforward task.
Luca: reading $FF1E for random numbers is not really ideal when you have raster IRQ's in your code.
|
|
Posted By
Luca
on 2009-03-14
22:09:13
| Re: Random for Real
Argh! It seems there's no best solution. In Mikropyros, I used:
LDA $FF00
EOR $FF1E
but, while coding a little "resultstro" for limiTED2, and using digis, I simply coded a flash border which "flashes" (luminance fadeout) at every digi slice (hence, it follows the rhythm, a classic, no?). I would have a real random selection of the flashing colour, but I obtained pseudorandom stuff only, the genre of values which doesn't change once loaded and run the program again 
|
|
Posted By
Csabo
on 2009-03-14
18:58:18
| Re: Random for Real
I have a routine in The Alchemist, but I think it must have been copied from the above or some similar source
Usually for demos pseudo-numbers are good enough. There's lots you can do! FF1D/1E are good ideas, so are the regular counters ($FF00-$FF05), or some EOR between those. If you look at Quadrillion, it reads the ROM from somewhere $8000 and up, that gives pretty much random numbers.
|
|
|
|
Posted By
Luca
on 2009-03-14
17:21:11
| Random for Real
Ooooh, damn, I'm really sick of this! 
How do you get real random values in assembly? On the c64, you can use the white noise generator...and on the Plus/4?
Post here your random values'routine, I'll add'em in a proper voice in the encyclopedia.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
