Myślałem, że na tym forum są poważni ludzie, ale jak widże taki stan nikomu oprócz mnie nie przeszkadza, nie moja sprawa. No cóż, przyszedłem na to forum jedynie w sprawie porady, której zresztą nie otrzymałem, dyskusja też się rozwinęła w dziwnym kierunku, widać nie moje klimaty tu panuja.

PS. Mała podpowiedź - skoro sam serwer wyświetla komunikat, że strona została wygenerowana w tyle i tyle sekund, to nie maszyna, na której stoi serwer www ma problem z wyjściem z uśpienia, ale raczej baza danyc,h którą ten serwer odpytuje ma problemy ze zwracaniem wyniku na czas  i tu szukałbym problemu.

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.

Tego sie właśnie już domyśliłem. Jednak opisy pojawiające sie w sieci są sprzeczne

wg: http://krzysiobal.com/arts/atari65xe/info.htm
(musiałem skopiowac tą stronę na swoj serwer bo oryginalna jak na złość dziś przestała działać)
"wnętrze Freddie'ego to czysty synchroniczny układ, w którym nie ma celowego opóźniania (poprzez zestaw bramek) sygnałów RAS i CAS"

Z kolei: http://krzysiobal.com/arts/atari65xe/freddiei.gif
wyraźnie pokazuje, że na drodze sygnału /RAS  jest zestaw opóźniający.

Ponieważ opóźnień w CPLD nie da się wygenerować, jedynym sposobem jest zliczanie zboczy wejściowego zegara 14.1875MHz,  a cały "cykl" rozpoczyna sie od opadającego zbocza phi2 (bo rosnące jest zbyt pochylone).

Niestety nigdzie dokłądnie nie znalazłem jak te przebiegi maja wyglądać. Jest co prawda ich zrzut w nocie katalogowej freddiego, ale jest on dla mnie niezbyt zrozumiały:

No i odtworzyłem schemat freddyego w wersji na scalakach 74xx: