forum speccy.pl
ZX Spectrum => PROGRAMOWANIE => Wątek zaczęty przez: Abrimaal w 2013.10.22, 06:58:26
-
W jaki sposób wywołać funkcję INT (RND*n), jednobajtową. Jakiś CALL do ROMu?
Jaki prefix w asm, konkretnie w Pasmo stosuje się żeby zapisać liczby binarnie?
-
Jeżeli ta liczba jest 8bit a operacja jednorazowa to może wystarczy LD A,R.
dla liczb binarnych stosuje się znak %, np %00001111 = $0F = 15
-
Dobra generacja liczb losowych to wcale nie jest proste zagadnienie :)
Osobiście staram się trzymać od ROMu z daleka i używam jakichś swoich procedur, podobnie zresztą jak większość innych programistów.
Spróbuję dziś wieczorem coś podesłać.
-
O znalazłem, dość przydatna strona dla programisty:
http://baze.au.com/misc/z80bits.html
A tutaj funkcja losowa, można ją też samemu trochę przerobić
Rand8 ld a,Seed ; Seed is usually 0
ld b,a
add a,a
add a,a
add a,b
inc a ; another possibility is ADD A,7
ld (Rand8+1),a
ret
-
To ja tez cos dorzuce z wykopalisk :D
http://zxsnippets.wikia.com/wiki/Random_generators (http://zxsnippets.wikia.com/wiki/ZX_Spectrum_Snippets_(ZXSS)_Wiki)
Generates a psuedo random number between 00h and FFh; the random number is loaded into A. The seed for the random number is held at location RandSeed.
ld hl,(RandSeed)
ld a,r
ld d,a
ld e,(hl)
add hl,de
add a,l
xor h
ld (RandSeed),hl
A tutaj troche matematyki: http://sgate.emt.bme.hu/patai/publications/z80guide/index.html
-
A to nie jest tak, że wynik jest pseudolosowy?
W określonych okolicznościach zawsze może "losować" tą samą liczbę... Chyba coś takiego już gdzieś kiedyś przerabiałem w jakiejś grze (chyba Dallas albo SuperSpekulant). Dodaliśmy tam muzykę AY na przerwaniach i jakiś kod. Po uruchomieniu ciągle losował te same parametry, a okazało się, że winny był rejestr R, który po wykonaniu jakichś instrukcji startował z odliczaniem od nowa, a kolejne instrukcje zawsze wykonywały się tyle samo czasu, co powodowało trafienie tej samej "liczby losowej". No w przybliżeniu piszę, bo już nawet nie pamiętam dokładnie jak to było.
-
A każdy generator pseudolosowy (w sensie w którym kolejne kroki są liczone ze wzoru) będzie dawał na wyjściu zawsze taki sam ciąg, jeśli go zainicjujesz tą samą wartością (co może być wykorzystywane np. do szyfrowania)
I trzeba o tym pamiętać... i unikać :)
A jak porządnie zainicjować generator, to już zupełnie inna historia... ;)
-
Rejestru R do tej pory nie ogarniam ;) Też wiem że czasem zachowuje się losowo a czasem nie i wstawieniem jakiejś zupełnie niezwiązanej instrukcji można tę losowość popsuć.
Jakby ktoś chciał poczytać to jakieś zaawansowane generatory tworzą ludzie na WOSie:
http://www.worldofspectrum.org/forums/showthread.php?t=39632
Dla moich potrzeb jednak zawsze wystarczały prostsze rozwiązania.
-
Rejestr R to jest wyjątkowo prosta sprawa i wyjątkowo nie nadaje się do użycia jako generator pseudolosowy - jest on (a właściwie jego młodsze siedem bitów) zwiększane przy każdym pobraniu instrukcji (na początku cyklu M1 procesora) a następnie w trzecim i czwartym takcie tego cyklu jest wystawiany na młodszych ośmiu bitach szyny adresowej (na starszych ośmiu wystawiana jest zawartość rejestru I) wraz z sygnałem /RFSH. Ten mechanizm jest przeznaczony do ciągłego "omiatania" pamięci dynamicznych w celu podtrzymania ich zawartości i miał uprościć konstrukcję komputerów - w wypadku innych procesorów trzeba było zapewniać dodatkową elektronikę generującą sygnały odświeżania pamięci.
Użycie R jako generatora pseudolosowego może mieć sens tylko w wypadku jeśli liczby potrzebujemy rzadko - w wypadku częstego losowania zwłaszcza w krótkiej i stałej pętli ryzykujemy uzyskanie bardzo krótkiego i bardzo powtarzalnego ciągu danych.
-
Jasna sprawa. Chociażby tęczowe paski w czasie pilota przy ładowaniu pliku z taśmy, jak wstawimy przed OUTem LD A, R. ;)
...czasem zachowuje się losowo a czasem nie i wstawieniem jakiejś zupełnie niezwiązanej instrukcji można tę losowość popsuć.
Zachowuje się losowo, jeśli czas pomiędzy kolejnymi odczytami zmienia się.
Czyli w naszym przykładzie - w czasie ładowania danych paski nie są już "kolejne" a zupełnie zwariowane.
-
Potrzebowałbym krótki kod, nie korzystający z procedur ROM, wypełniający 4kB losową zawartością, potrzebne to do generacji szumu.
odpowiednik w Basic:
FOR i=adres TO adres+4000 : POKE i, INT (RND*256) : NEXT i
-
Chociażby
FillRandom
ld hl,START
ld bc,4096
Rand ld a,0
ld b,a
add a,a
add a,a
add a,b
inc a
ld (Rand+1),a
ld (hl),a
inc hl
dec bc
ld a,b
or c
jp nz,Rand
ret
Losowość do przetestowania, pisałem na sucho
-
Szukałem rozwiązania, które może tworzyć "wzór" do generacji szumu. Różne próby stworzenia takiego "patternu" od zera mają wadę - powtarzalność i odtwarzany szum przypomina raczej chrapanie. Jednak najlepszym generatorem jest tutaj ROM, lub dowolny długi kod.
Kilka testów różnych modyfikacji tej procedury i podobnych. Ostatni to kopia ROM.
-
Jak tu widzę głęboki porządek w niektórych tych generacjach :)
-
Mi coś świta ze studiów, że do liczenia wartości pseudolosowych stosuje się wielomiany. Na wiki znalazłem coś, co pachnie generatorem "komputerowym", w skrócie PRBS:
http://pl.wikipedia.org/wiki/PRBS
No i jeszcze dość przystępnie napisany materiał o podstawach generacji liczb pseudolosowych:
http://fatcat.ftj.agh.edu.pl/~chwiej/mn/generatory.pdf
-
Właśnie ten głęboki porządek tworzy raczej falę dźwięku o pewnej częstotliwości, jak najbardziej niepożadaną przy szumie.
Kolejne próby były właśnie z liczbami pierwszymi, na nich bazowały pętle. Może mniej widoczny był wzór na ekranie, ale to chyba iluzja wyświetlania na ekranie=256px.
-
Ale licznik pętli jest 16-bitowy? Bo 8 to stanowczo za mało.
-
Szukałem rozwiązania, które może tworzyć "wzór" do generacji szumu. Różne próby stworzenia takiego "patternu" od zera mają wadę - powtarzalność i odtwarzany szum przypomina raczej chrapanie. Jednak najlepszym generatorem jest tutaj ROM, lub dowolny długi kod.
Kilka testów różnych modyfikacji tej procedury i podobnych. Ostatni to kopia ROM.
Jeden z lepszych które znam.
Z pakietu FOX Toolkit.
Choć jak widać do szumu wciąż mu trochę brakuje :)
W załączniku kod dla SDCC.
-
W załączonych wcześniej przykładach licznik był=4096 jednak operacje typu xor c redukowały go do 256, kolejne poprawki to pętla przy osiągnieciu liczby pierwszej, też 1-bajtowej np. 199. Do gier w karty wystarczy :D
W jaki sposób skompilować tą procedurę do kodu w SDCC? Który plik to kompilator dla Z80?
... tak na marginesie, przydałoby sie poprawić nazwę tego tematu.
-
W jaki sposób skompilować tą procedurę do kodu w SDCC? Który plik to kompilator dla Z80?
BAT w załączniku.
W jaki sposób z ihx zrobić tap opisuje artykuł tutaj : http://speccy.pl/articles.php?article_id=22 (http://speccy.pl/articles.php?article_id=22)
BTW, w załączonej konfiguracji program się kompiluje pod adres $8000, ale trzeba doliczyć jeszcze 10 bajtów rozbiegówki, więc otrzymany kod należy ładować (i uruchamiać) od adresu $7ff6 (32758).
(Adresy można zmienić na inne modyfikując plik crt0.s zamieszczony w artykule linkowanym powyżej i podając nowy adres jako parametr kompilacji)
-
Ciekawi mnie, czy istnieje możliwość odczytania z AY liczb losowych, które odpowiadają za szum. Jeśli chip potrafi generować szum, to albo ma generator liczb losowych albo "pattern".
-
Nie ma możliwości odczytania z AY jego licz losowych. Jeżeli takie generuje dla szumu, to jest to wewnętrzna funkcjonalność, nie udostępniana na zewnątrz.