forum speccy.pl
ZX Spectrum => HARDWARE => Wątek zaczęty przez: coberr w 2016.09.29, 20:10:03
-
Postanowiłem założyć tego typu temat - ponieważ zawsze zastanawiało mnie - co własciwie sama ULA może Zrobić z całym systemem i jak może wpłynąć na zachowanie się samego procesora oraz wykonanie programu.
Czy specyficzne Własciwosci ULI zostaly gdzies zebrane i dokładnie opisane?
(chodzi mi głownie o możliwosci pod kątem kruczków wykorzystywanych np. w niektorych demach, grach itp)
WIem , ze Sama ula moze wpłynać na procesor - np. Wstrzymać zegar itp... Jednak jakoś nigdy tego nie analizowałem :)
Czy moglibyscie sie wypowiedziec na ten temat? ( wiem, ze wazne są rózne zależnosci czasowe i w efekcie odpowieź samego układu - może warto zebrac tutaj to wszystko?)
-
Chyba najwięcej informacji na ten temat znajdziesz na WOS-ie:
http://www.worldofspectrum.org/faq/reference/48kreference.htm
-
Całą "ULĘ" rozgryzł Chris Smith, i tak powstał SLAM, czyli zamiennik ULA. Poniżej jego książka, można kupić równiez na ebay itd
https://www.amazon.co.uk/ZX-Spectrum-Ula-Microcomputer-Computer/dp/0956507107 (https://www.amazon.co.uk/ZX-Spectrum-Ula-Microcomputer-Computer/dp/0956507107)
-
o książce wiem ale chciałem poznać wasze opinie :)
Tak sobie ostatnio zastanawiałem się - czy nie stworzyć małej hybrydy - czyli spectrum (funkcjonalny odpowiednik) oraz COBRY.
WIem, ze niektóre dema i programy wykorzystują specyficzne własciwości ULI tylko nie wiem - jakie . Może Wy podpowiecie :)
-
Wstrzymywanie procesora zachodzi wtedy, kiedy ULA i procesor chcą mieć dostęp do tego samego obszaru pamięci.
To raczej w niczym nie pomaga, wręcz utrudnia robienie efektów i nadążanie za rastrem.
Pozbawiona 'contention memory' jest rodzina klonów bazująca na Pentagonie. To co można dzięki temu zrobić pokazują ostatnie dema, w których można 'usunąć ramkę' i robić efekty na pełnym ekranie, do tego w pełni sterowalny multicolor (kolory 8x1 jak w Timexie) i itp
-
Wstrzymywanie procesora zachodzi wtedy, kiedy ULA i procesor chcą mieć dostęp do tego samego obszaru pamięci.
Nie tylko wtedy. Również w sytuacji używania parzystych adresów I/O.
-
Nie tylko wtedy. Również w sytuacji używania parzystych adresów I/O.
o tym nawet nie wiedziałem :)
to dotyczy całego zakresu - 0..255 (czy nawet 65535)?
-
Tak, w oryginalnym Spectrum - wszystkich parzystych, od 0 do 65534.
ULA dekoduje jedynie niski stan A0, ignorując pozostałe linie adresowe.
Dlatego, by uniknąć kolizji, wszelkie interfejsy - a także dodatkowe rejestry w modelach 128K - używają adresów nieparzystych.
EDIT: to, co skreśliłem, jeszcze weryfikuję. Zdaje się, że chodzi tylko o parzyste adresy dla A15=0 i A14=1, czyli "odpowiednik" pamięci ekranu, ale w przestrzeni I/O. Tak na logikę ma to większy sens.
-
Czyli wstrzymywanie zdarza się również przy czytaniu z taśmy.
-
Przede wszystkim przy obsłudze taśmy, bo port 254 jest "pełnoprawnym" portem ULA.
Tak przynajmniej wynika z dokumentacji na WoS.
EDIT: I tu się całkowicie myliłem, skutki pobieżnego czytania :)
-
Czyli wstrzymywanie zdarza się również przy czytaniu z taśmy.
I myślę, że jest to całkowicie nieodczuwalne, bo co znaczy nawet 1 mikrosekunda dla sygnału, który operuje szerokościami rzędu kilkuset mikrosekund? różnica poniżej promila raczej nie spowoduje błędu wczytywania.
Bardziej mnie zastanawia, jak to się dzieje, że BEEP nie charczy. Bo AY popędzony z CLK charczy niemiłosiernie.
EDIT: No dobra, przeczytałem jeszcze raz i uważniej:
1. If the port address being accessed has its low bit reset, the ULA is required to supply the result, which leads to a delay if it is currently busy handling the screen.
2. The address of the port being accessed is placed on the data bus. If this is in the range 0x4000 to 0x7fff, the ULA treats this as an attempted access to contended memory and therefore introduces a delay. If the port being accessed is between 0xc000 and 0xffff, this effect does not apply, even on a 128K machine if a contended memory bank is paged into the range 0xc000 to 0xffff.
OK, czyli procedury obsługi taśmy są bezpieczne, o ile tylko w rejestrze B jest zero.
-
Jak SAVE nie charczy to i BEEP nie. Sygnał SAVE to przecież też audio.
Może po wstrzymaniu port pozostaje zamrożony w poprzednim stanie?
W takim razie impuls trochę się tylko wydłuży. Bardziej będzie fałszował niż charczał.
-
Jak już sprostowałem poniżej - contended I/O to parzyste adresy w przestrzeni contended RAM, czyli #4000-#7FFF. SAVE i BEEP są więc bezpieczne
, jeśli w rejestrze B jest np. zero.
EDIT: Sprawdziłem w "The Complete...", zarówno BEEP, jak i SAVE używają rozkazu OUT (#FE), A, a nie OUT (C), A. Zatem adres I/O mieści się w "bezpiecznej" strefie.
-
Jednak nie:
1. If the port address being accessed has its low bit reset, the ULA is required to supply the result, which leads to a delay if it is currently busy handling the screen.
-
Jak SAVE nie charczy to i BEEP nie. Sygnał SAVE to przecież też audio.
Oczywista oczywistość. Zastanawiałem się nad charczeniem BEEP versus charczeniem AY.
Bo AY nie fałszuje, tylko charczy - wiem, bo zbudowałem mój pierwszy AY z dzielnikiem CLK :)
-
Jednak nie:
1. If the port address being accessed has its low bit reset, the ULA is required to supply the result, which leads to a delay if it is currently busy handling the screen.
Też tak na początku zrozumiałem.
Ale pomiędzy twierdzeniami 1. i 2. zachodzi relacja "AND" ;)
Chyba, że "delay" z punktu 2. jest dodatkowy, po "delay" z punktu 1.
-
Obawiam się że w ostatnim zdaniu masz rację.
Może AY charczy, bo musi obsłużyć kilka kanałów?
-
AY charczy, bo z częstotliwością pseudolosową ma blokowany zegar, który napędza syntezator przebiegów (w 3 kanałach, ale nie ma to znaczenia, bo są obsługiwane równolegle) i "czysty" dźwięk jest modulowany (jednopołówkowo, dyskretnie, FM) "bzyczeniem" pochodzącym z wszystkich dostępów do pamięci "obrazu" (konkretnie - contended RAM) uskutecznianych przez procesor, co w przypadku np. BASIC-a oznacza składową 50 Hz (aktualizacja zmiennej FRAMES) plus wszystko, co jest na ekranie wyświetlane... To taki odpowiednik śnieżenia z oryginalnym chipem HAL (bez unrainera).
Jakbyś miał 50 okresów na sekundę, to też byś charczał - parafrazując stary kawał ;)
-
Śnieżenie to kolejny błąd ULA.
Nie jest specjalnie przydatny, został użyty w jednej grze (Vectron).
Po załadowaniu do rejestru I wartości z zakresu 64 - 127, ULA wyświetla zamiast danych z kolejnego adresu - dane z adresu gdzie młodszy bajt jest zastąpiony przez R (rejestr odświeżania). Powoduje to efekt śnieżycy w okolicy wyświetlonych na ekranie treści. Na pustym ekranie nie widać nic.
Dzieje się tak bo ULA "zapomina" wstrzymać procesor, a ten chce odświeżać pamięć.
W emulatorze ZX Spin można włączyć ten efekt.
-
Hmm, Chris Smith opisuje to zjawisko trochę inaczej, choć podstawowe fakty się zgadzają.
http://www.zxdesign.info/dynamicRam.shtml
-
Może da się wykorzystać ten niezamierzony błąd w opracowaniu "efektu deszczu" o jakim to Tygrys zapoczątkował jeden z wątków na forum :)
-
Zasugerowałem to już jakiś czas temu, ale byłby to efekt deszczu padającego poziomo ;)
A poza tym chyba wystarczy włączyć IM2 z wektorem ustawionym na pamięć contended (#4000-#7FFF).
-
Może da się wykorzystać ten niezamierzony błąd w opracowaniu "efektu deszczu" o jakim to Tygrys zapoczątkował jeden z wątków na forum :)
Da się. Ostatnie miejsce gwarantowane :P
-
Oj tam, zawsze możne postawić monitor bokiem :)
-
A poza tym chyba wystarczy włączyć IM2 z wektorem ustawionym na pamięć contended (#4000-#7FFF).
O ile pamiętam to nawet nie trzeba włączać IM2. Wystarczy załadować do I wartość między #40 a $7F. I jest wystawiane na szynę adresową podczas refresha pamięci razem z R, które jest cyklicznie inkrementowane. I to właśnie wystawienie przez procesor pary IR na szynę adresową powoduje, że ULA dziczeje ;)
-
O ile pamiętam to nawet nie trzeba włączać IM2. Wystarczy załadować do I wartość między #40 a $7F.
To właśnie napisałem
Po załadowaniu do rejestru I wartości z zakresu 64 - 127, ULA wyświetla ...
Okazuje się, że nie jestem wiarygodny >:(
Ewentualnie piszę nieprzejrzyście...
-
Okazuje się, że nie jestem wiarygodny >:(
Ewentualnie piszę nieprzejrzyście...
Opcja nr 2!
Albo nr 3 - ja piszę nieprzejrzyście ;)
-
Ewentualnie piszę nieprzejrzyście...
Nie. Po prostu po raz kolejny okazuje się, że nie powinienem się publicznie odzywać w poniedziałki przed przynajmniej drugą kawą ;)
-
I to jest chyba jedyny sprzetowy efekt specjalny na ZX. Inne mozna uzyskac tylko przez drobne zwarcie :D
-
Jest jeszcze jeden niezamierzony efekt związany z ULA - floating bus.
Odczyt z nieistniejącego portu (np. 255) daje czasem bajt z ekranu, gdy zbiegnie się w czasie z odczytem pamięci ekranu przez ULA. Można wykorzystać do synchronizacji: przy sprytnej konstrukcji ekranu, można sprawdzić którą część ekranu właśnie "rysuje" ULA, albo co najmniej wykryć dojście do konkretnego punktu.
Efekt użyty m.in w Arkanoid i Cobra, nie występuje na Timexach, więc programy używające go nie będą poprawnie działać na nich.
Szczegóły wraz z programem testowym http://ramsoft.bbk.org.omegahg.com/floatingbus.html#FLOATINGBUS (http://ramsoft.bbk.org.omegahg.com/floatingbus.html#FLOATINGBUS).