Sygnał 14,1875 MHz z oscylatora (lub generatora) kwarcowego wchodzi na pin 2 układu FREDDIE, z pinu 1 wychodzi ten sam, tylko zanegowany przebieg (na potrzeby wariantu z oscylatorem), ponadto z pinu 37 wychodzi przebieg OSC o częstotliwości podzielonej przez 4 (3,55 MHz) - w XL to jest bazowy zegar. Tylko te dwa zegary wychodzą z FREDDIEgo. Na pin 5 FREDDIEgo wchodzi sygnał PHI2 (1,77 MHz), który jest generowany w SALLY z sygnału PHI0, który z kolei powstaje w ANTICu z FPHI0 podzielonego przez 2. Ten z kolei powstaje w GTIA z sygnału OSC z FREDDIEgo.

Z tego co mi wiadomo FREDDIE nie potrzebuje "dla siebie" ani 14,1875 MHz ani 3,55 MHz, potrzebny mu jest jedynie PHI2 (1,77 MHz) z SALLY.

Jesteś pewien tego sprzężenia z PHI2 w generowaniu OSC? Bez OSC nie ma PHI2. OSC jest bazowym zegarem systemu, nie widzę powodu, aby miał być od czegokolwiek zależny. On jest w fazie z zegarem 14M (który nie jest nigdzie wykorzystywany i w XL go w ogóle nie było).

FREDDIE zapewne jest w pełni synchroniczny, ale w XL sygnały RAS i CAS szły przez linię opóźniającą, więc tak też się da odtworzyć tę funkcjonalność FREDDIEgo.

Ale PHI2 powstaje z OSC i zależności fazowe między OSC i PHI2 wynikają z tego co się dzieje poza FREDDIEm. Rozumiem, że chodzi tu o okład opóźniający dla CAS, ale zależność fazowa między OSC i PHI2 jest stała, choćby "nie wiem co"... ale możliwe że czegoś nie rozumiem.

To ja zadam pytanie pomocnicze - jak uzyskać sygnał zgodny w fazie z PHI2, ale bez zakłóceń i z gwarantowanym wypełnieniem 50/50, a przy okazji podzielić sygnał kwarcu przez cztery?

Moja wina, wyraziłem się nieprezycyjnie. Jak uzyskać sygnał o częstotliwości i fazie zgodnej z PHI2?

No, ludzie. Czyta, a nie rozumie. Oryginalny sygnał, dostępny w układzie FREDDIE nie ma wypełnienia 50/50 i jest mocno zakłócony. Głownie z powodu bardzo długiego czasu narastania u źródła, czyli na wyjściu CPU. A przecież wyraźnie i wprost napisałem, co chcę uzyskać.

Ja rozumiem co piszesz, ale Ty nie rozumiesz, że nie możesz w ten sposób generować OSC. Jeśli koniecznie chcesz generować "swój" PHI2 to możesz robić jak jest na schemacie, ale OSC musi być generowany w osobnym liczniku, bezpośrednio z CLK i powiązania z PHI2.

Kwestionowanie wszystkiego jest zasadne. To, że coś "jakoś" działa, nie znaczy, że jest prawidłowo zaprojektowane. Oczywiście, że Twój układ działa, ale pomyśl - PHI2 jest "na sztywno" opóźniony względem OSC o ok 40 ns, a układ sprzężenia próbuje dosynchronizować OSC do PHI. Jak OSC "zwalnia" to w kolejnym cyklu "zwalnia" i PHI2. W rezultacie sprzężenie nieustannie próbuje opóźnić OSC, by PHI2 go "dogonił", ale każde spowolnienie OSC, spowalnia również PHI2. W rezultacie PHI2 nigdy nie "dogoni" OSC, a pętla sprzężenia będzie ustawicznie próbowała opóźniać OSC. Układ będzie niestabilny, a sprzężenie nigdy się nie "zepnie". Układ działać będzie, ale OSC będzie miał jitter na poziomie 20-30 ns, co przeniesie się na wszystkie zegary w systemie. Negatywne efekty zapewne zostaną stłumione przez wolne układy 74LS, ale to nie znaczy, że tak jest dobrze. Skutkiem ubocznym będzie też nierówne wypełnienie tak generowanego OSC.

Matko. Czytam z zainteresowaniem, bo zastanawiałem się jak sobie poprawić PHI2 na złączu carta, bo tak na oko oscyloskopu to on jest w fazie nijakiej z wypełnieniem dziwacznym. Kiedyś PLLem poprawiłem fazę (na minus) CLK dla HDMI (pixelclock74MHz) lecącego drutem przez slipringa. PLLka robi to w trybie basic przy minimalnej wiedzy operatora.

No ale tutaj jakaś masakra jest, przecież te zegary latają po wszystkich układach i każdy coś w nich grzebie. To jak na końcu cart ma się dobrze wystawić na magistrali i dla CPU i ANITCa i GTIA to bez szans jest gmeranie przy tym. To cud, że to w ogóle działa :/

Skoro nie da się inaczej, wyłuszczę ideę. Ze względu na opóźnienia na drodze OSC --> GTIA --> ANTIC --> CPU --> PHI2, sygnał PHI2 jest w praktyce skorelowany z opadającym zboczem OSC. Można więc, dla analizy, zastąpić to prostym dzielnikiem przez 2 zmieniającym stan na opadającym zboczu OSC. Licznik synchroniczny ze schematu także generuje sygnał o częstotliwości OSC/2, którego stan zmienia się równocześnie z opadającym zboczem OSC. Ponieważ jednak nie znamy stanu początkowego dzielnika znajdującego się w ANTIC, mamy dwie możliwości - albo sygnał z wyjścia Q2 licznika synchronicznego ma fazę zgodną z PHI2, albo ma fazę przeciwną. Jeśli ma fazę zgodną, wówczas nie potrzebujemy w ogóle nic robić. Jeśli ma fazę przeciwną, musimy w jednym, jedynym cyklu zmienić stan licznika w taki sposób, żeby fazy Q2 i PHI2 się ze sobą zgodziły. A jak już się zgodziły, to idziemy sobie spokojnie na piwo, bo więcej nic nie potrzebujmy robić. Na obrazkach są przebiegi z symulacji - pierwszy z fazą zgodną, a drugi z przeciwną.

Poniżej mój opis:

Freddie - jak DOKŁADNIE działa:

Składa się z trzech komponentów:

I) negator CLK_IN - CLK_OUT, używany do wprowadzenia kwarcu 14.XXX MHZ w drgania.
Nie wiem, czy ma jakieś specjalne właściwości, do podobnych zastosowań służy np. układ
74HCU04 (U-Unbuffered), który jest zalecany, zamiast zwykłęgo 74HC04

II) generator OSC generator: zmienia stan co każde 4 narastające zbocze na CLK_IN. NIE wpływają na niego żadne inne sygnały jak RST czy PHI2.

III) Logika generowania RAS/CAS/MUX/WR
* Ta część ukłądu jest taktowana zarówno narastającym jak i opadającym zboczem na CLK_IN (nie spotkałem sie nigdy wcześniej z czymś takim, ale sygnały RAS/CAS zmieniają się zawsze dokładnie w tym samym czasie po odpowiednim z kolei zboczu narastającym/opadajacym na CLK_IN, nie ma żadego jitteru. Gdyby wewnątz freddiego był jakiś zegar o większej częstotliwości niż CLK_IN, Freddie mogłby próbkowac CLK_IN w wykrywaniu jego zboczy, ale wtedy sygnały RAS/CAS pływałyby troszkę.

Do rzeczy:

* Zaczynamy w stanie S1
* W stanie S1: jeśli /RST='1' i podczas dwóch kolejnych zboczy CLK_IN, sygnał PHI2='1', zmiana stanu do S2
* W stanie S2: jeśli podczas dwóch kolejnych zboczy CLK_IN sygnał PHI2='0', zmiana stanu do S3
* W stanie S3:

state                S1  |  S2  |   S3                           | S1
CK_IN             _.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
                               2   4   6   8  10  12  14  16  18    
                             1   3   5   7   9  11  13  15  17 |19  
                                         |     |     |       | | |
PHI2             -----------.______________________________________
nRAS             ------------------------.___________________.-----
nCAS dla odczytu ------------------------------(_______________)---
nCAS dla zapisu  -----------------------------------(____________)- 


#nr zbocz| Co wtedy sie dzieje
CLK_IN   |
---------+---------------------------------------------------------------------------------
7        | - nRAS opada w dol
         | - RnW jest probkowany i zapamięany wewnątrz jako latch_RnW
---------+---------------------------------------------------------------------------------
8        | - wewnętrzny multiplekser przestawia się do:
         |   BA0<=A9, BA1<=A10, BA2<=A11, BA3<=A12, BA4<=A13, BA5<=A14, BA6<=A8, BA7<=A15
---------+---------------------------------------------------------------------------------
9        | - nCASINH jest próbkowany i zapamięatany wewnątrz jako latch_nCASINH
---------+---------------------------------------------------------------------------------
10   (R) | - if latch_RnW='1' and latch_nCASINH='1', wewnętrzny sygnał sig_nCAS idzie w dół
---------+---------------------------------------------------------------------------------
13   (W) | - if latch_RnW='0' and latch_nCASINH='1', wewnętrzny sygnał signal sig_nCAS idzie w dół
---------+---------------------------------------------------------------------------------
17       | - nRAS idzie w górę
---------+---------------------------------------------------------------------------------
18   (R) | - if latch_RnW='1' and latch_nCASINH='1', wewnętrzny sygnał sig_nCAS idzie w górę
         | - wewnętrzny multiplekser przestawia się do:
         |   BA0<=A0, BA1<=A1, BA2<=A2, BA3<=A3, BA4<=A4, BA5<=A5, BA6<=A6, BA7<=A7
---------+---------------------------------------------------------------------------------
19   (W) | - if latch_RnW='0' and latch_nCASINH='1', wewnętrzny sygnał sig_nCAS idzie w górę
         | - zmiana stanu do S1
---------+---------------------------------------------------------------------------------

- pin: nCAS <= sig_nCAS OR (not nEXTSEL)
- pin: WR  <= latch_RnW when nRAS = '0' or sig_nCAS = '0' else RnW;

Pierwszy problem jest taki, że nie da się w FPGA reagować zarówno na jedno jak i drugie zbocze zegarowe. No chyba, że mamy szybszy zegar i próbkujemy. Czyżby? Wczoraj wpadłem na genialny pomysł, który opisałem tu:
https://www.elektroda.pl/rtvforum/viewt … highlight=

Drugi problem jest taki, że powyższy opis w 100% zgadzałał się z krokową symulacją, jaką przeprowadziłem na żywym układzie.
Problem jest jednak taki, że sam stan S3 skłąda się z 19 zboczy, podczas gdy zegar PHI2 ma przecież okres 16 zboczy.
Gdyby więc zastosować powyzsze rozumowanie, to zanim skończy się S3, zacząłby się nowy cykl PHI2 w którym nic by się nie działo (bo nie zostałby wykryty) więc wszystkie sygnały wyjściowe byłyby generowane co dwa cykle PHI2.
Wsadzając Freddiego do Atari i patrząc na przebiegi faktycznie chyba między dwoma CASami musi być minimum jeden cykl PHI2 pusty:

No ale już sygnał RAS generowany jest co kazdy cykl:

Trochę się zastanawiałem jak tego dokonać. Zrobiłem mały eksperyment - chwilę po 7 cyklu, gdy RAS poszedłw w dół (pionowe żółte linie oznaczają proces który trwa w układzie) sprawdziłem co by sie stało, gdyby zasymulować rozpoczęcie nowego cyklu PHI2, czyli PHI2 idzie w górę na dwa cykle CKL_IN, potem w dól na dwa cykle.
Ku mojemu zdziwieniu, po 17 cyklu RAS nie poszedł w górę tylko został w stanie niskim, który trwał łącznie 20 cykli (normalnie RAS jest niski przez 10 cylki).

To dało mi do zrozumienia, że wewnątrz Freddiego działają tak naprawde dwa identyczne procesy, opisane jak wyżej, z których drugi startuje w następnym cylku PHI2 po pierwszym.
Pierwszy proces wygenerował swój RAS który trwał 10 cykli i drugi wygenerował swój ras , który tez trwł 10 cykli.
Wynikowy RAS to więc logiczny AND pierwszego i drugiego RASa.

Po zaimplementowaniu tego wszystkiego w VHDL, układ zadziałał od pierwszego razu, witając mnie radosnym niebieskim ekranem READY.
Odpalilem kilka gier i wszystkie działały bez problemu na mojej protezie Freddyego.

W opisywanej protezie moim początkowy marzeniem było zastosowanie jedynie scalaka EPM3064. Niestety ma on o jeden pin IO a mało. Postanowiłem więc początkowo zastosowac jeden bufor 74LVC245, ale poprowazenie wsystkich ścieżek na tak małej płytce wiązałoby się z koniecznośćią użycia przelotek pod scalakiem, których w domu zrobić się nie da.
Potem jednak dodalem wspomniany 74HCU04 jako bufor zegara, bo EPM nie radził sobie w roli negatora, dzięki temu EPM nie musi generować CLK_OUT i zwalania mu sie jeden pin.
Finalnie więc całe rozwiązanie będize można zmieścić w EPM3064+74HCU04.