forum speccy.pl
ZX Spectrum => HARDWARE => NAPRAWY => Wątek zaczęty przez: coberr w 2021.04.12, 22:28:34
-
Mam pytanie do specjalistów:
Czy może ktos ma w swoich notatkach lub ma możliwość podpięcia na szybko oscyloskopu dwukanałowego i sprawdzenia zależności czasowych pomiedzy sygnałami w podanej kolejności?
chodzi o dokładne opóźnienia w ns na górnym pakiecie pamięci DRAM.
MREQ\ (Z80) (n19) => RAS 4532 (n.4)
RAS =>MUX (n.1. 74157)
MUX => CAS 4532 (n15)
-
Dokładny czasów nie mam, ale możesz policzyć wg uproszczonej zależności:
/MREQ low -> /RAS low -> linia opróżniająca 1 -> S (MUX) -> linia opóźniająca 2 -> /CAS low
Zresztą tak wygląda sterowanie górnym RAM w każdym Speccy 48K. W wykresy czasowe są pokazane w instrukcji serwisowej.
-
Dziękuję Klaud ale to juz generalnie widzialem w serwisowce spectrum :)
no nic będe musiał podlączyć oscyloskopa i pomierzyć.
-
A to musi być akurat 48K?
Mam pod ręką tylko TC2048 i +3. Wiadomo, inna ULA, więc trochę inne sterowanie pamięciami, pytanie, czy chodzi o dane, które dana pamięć "łyknie" bez problemu, czy też jakieś case study modelu 48K.
-
Już sobie poradzilem :)
Musialem rozbebeszyć spectruma jakiegoś. i pomierzyć.
instrukcję serwisową ryłem - czasow tam nie widziałem - nie wiem może gdzieś coś przeoczylem. A potrzebowalem ich jedynie do porównania - bo akurat walcze z nieszczesną COBRĄ (oryginal) a jest tak wredna małpa - ze takiej jeszcze nie miałem do uruchomienia...
normalnie uwzięła sie menda na mnie :) (swoją mam trochę rozbebeszoną i narazie nie chce mnie sie jej składac) Wszystkkie sygnały na pamieciach ok / pamieci sprawdzone/ przeróbka sprawdzona - dekodowanie adresów wydaje sie byc O.k - a ram ma problem.
No nic - zostawiam dla " potomnych " moze sie przyda komuś przy jakichś wrednych przypadkach.
Na poniższych zrzutach kilka oscylogramów z ZX spectrum 48/+:
1. Zółty - MREQ\ (19 Z80)
2. turkusowy - RAS (4 4532)
3. purpurowy - MUX (1 74157)
4. Niebieski - CAS (15 4532)
Program prosty:
10 PRINT PEEK 40000
20 GOTO 10
(normalnie wyczyn programistyczny :D)
orientacyjne opóznienia:
MREQ-RAS=18..20ns
RAS-MUX = 20ns
MUX-CAS = 98-100ns
(śmietnikiem na masie sie nie przejmować - nie podłączyłem reszty mas od sond:D)
-
A jesteś pewien, że nie masz szybszych pamięci niż założył sobie konstruktor? W Speccy typowym objawem po naprawie górnego RAM układami o czasie dostępu 100ns zamiast fabrycznych 150ns, jest niestabilna praca tej pamięci. Pomaga skrócenie stałej czasowej drugiej linii opóźniającej (wymiana C64 ze 180pF na 100pF).
Swoją drogą Twoje pomiary potwierdzają to co sobie rano policzyłem ze stałych czasowych linii opóźniających.
-
Cieżko powiedzieć - akurat mam problem z cobrą - a tu chcialem tylko porownać spectrum - jak to tam wygląda...
Cały czas mi tu coś nie pasuje - muszę jeszcze zasiąśc raz do cobry i pomierzyć.
Z apmieciami teoretycznie wszystko było ok. zarowno mój komplet jak i komplet klienta przechodził testy bez problemu. są to pamieci o czasach dostępu rzędu 120-150ns.
co ciekawe - czasem z jakichś przyczyn równiez i na tej cobrze test przypadkiem odbyl sie prawidłowo - zatem po prostu utknąłem z jakąś dosłownie pierdołą.
-
A jak masz zorganizowane odświeżanie DRAM?
Pamiętaj, że pamięci 64-kbit są w wersji z odświeżaniem 7- i 8-bitowym, a Z80 odświeża tylko 7-bitowo.
-
pod tym wzgledem jest w porządku pamietam o tym.
Pamieci to MN4164P-12A lub M5K4164 NP (lub ANP)
Oba typy posiadaja 7 bitowe odswieżanie.
A dzieja sie tu rozne cuda...
Co zrobie jeden krok do przodu- to za chwile dwa do tyłu :)
Ta wredna cobra sie na mnie uwzięła po prostu...
teraz mam taką sytuacje - ze co jakis czas program idzie w pole
(procesor zachowuje sie jak by odebrał z pamięci jakiś przypadkowy rozkaz HALT- a nigdzie w kodzie go nie umiesciłem) linia HALT=L - reszta teoretycznie normalnie
-
Miałem kiedyś podobne problemy, na płycie były wcześniej przez kogoś wymieniane TTL'e 74LS157,LS32 i LS00 w okolicy pamięci na jakieś inne od przypadkowych producentów.
Po wymianie tych TTL'i na nowe od Texas Instruments problem zniknął - dziwne ale pomogło. ;)
Stare układy były oczywiście sprawne, tylko w Speccy'm nie chciały działać do końca poprawnie.
-
W ZX Spectrum krytyczną są multipleksery typu 74LS157, które nie mogą być od Nationala. Zresztą jest o tym notka w instrukcji serwisowej. W ich przypadku podejrzane są czasy propagacji dla obciążenia ich wyjść dużo większym ponad testowe 15pF (8 kości pamięci, każda po 5 pF na wejście adresowe + jakieś pojemności pasożytnicze na PCB). Było o tym tu: https://www.speccy.pl/forum/index.php?topic=3451.msg52044#msg52044
-
Ten problem też juz brałem pod uwagę.
Oryginalnie w tej cobrze siedziały 2 x74LS157N (signetics)
wymieniłem je juz wczesniej na :SN74LS157N (TEXAS INSTRUMENTS)
ALe zrobie jeszcze próbe z poczciwymi 74157PC i może jak znajde przypadkiem - UCY74157.
-
A Z80, ULA i ROM był też już podmieniany ?
Procesor w technologii CMOS czy NMOS, z tymi pierwszymi bywają czasem przygody.
Na zasilaniu nic nie "szmaci" ?
-
ups, wysłałem ten post 2 razy ;)
Proszę skasować jeśli można.
-
A Z80, ULA i ROM był też już podmieniany ?
Procesor w technologii CMOS czy NMOS, z tymi pierwszymi bywają czasem przygody.
Na zasilaniu nic nie "szmaci" ?
Damik spokojnie - bez nerw :) ja naprawiam i w zasadzie uruchamiam usuwając stado błedów rownież montażowych mikrokomputer COBRA1 ale trafil sie tak wredny egzemplarz, że nie wyrabiam :) Tytuł wątku nawiazuje tylko do ZX spectrum - z racji tego ze chcialem porównać sobie przebiegi na pamięciach DRAM - w spectrumie i cobrze :) ze sppectruem przy takim problemie pewnie szybciej bym sobie poradzil :) (mniej scalaków do ogarniecia)
co do cobry - no chyba mnie szlag jasny trafi... multipleksery... przynajmniej na to wychodzi Ani jedne ani drugie nie moga tam pracowac. (te co opisywałem powyżej).
Zrobiłem teraz test na M74LS157P (TOSHIBA?) i program od razu przeszedl poprawnie...
CO prawda mam jeszcze maly problem z wykonaniem programu -= z czasem gdzies idzie w las
ale do wykluczenia i sprawdzenia mam "pewnośc" zasilania. Dodatkowo zrobie jeszcze testy z układami 74157 PC (TUNGSRAM?) - literką "T" - na mojej cobrze KYNAROWEJ łazily bez problemu. W zyciu nie myslałem ze fizycznie sprawne układy taki problem sprawią mi tutaj :)
)chociaż brałem taki przypadek pod uwagę - wymieniając wczesniej te nieszczesne multipleksery - jak widac na takie które też nie poszły...)
W zasadzie Tydzien pracy w plecy... Gdybym mial jakis serwis to juz bym zdechł z głodu dawno :)
-
Domyśliłem się potem że nie chodzi o Speccy, nawet to poprawiłem kasując wyraz ULA jednak tablet mi zaczął głupieć i wysłałem jeden post dwa razy, w końcu nie wiedzieć dlaczego mój post źle się zmodyfikował :D
Co prawda Cobre znam dość słabo ale to w miarę prosta konstrukcja, trochę już walczyłem z systemami opartymi na Z80 i problemy bywają podobne.
Ostatnio trochę krwi mi upuscilo uruchamianie klona Meritum3, ale w końcu się udało 8)
-
wszytko jest proste do momentu gdy nie zabierzesz sie za dany układ :)
A zwłaszcza jesli nie masz sytuacji - gdzie po każdym wlucie nowego sprawnego ukladu - dzieja sie nowe cyrki :)
update:
No i udalo się znaleźć i wylutować dwa sprawne UCY74157.
COś mnie sie zdaje że udało sie rozwiązać problem całkowicie (mam nadzieje ze nie wyjdą jeszcze cyrki z płytką). Dodatkowo na wszelki wypadek wymienilem wszystkie bufory adresowe na UCY7408 oraz układ UCY 7474 (wcześniej: UCA6474) - rowniez będący częsci a układu generującego sygnal MUX.
NA 74157PC było już prawie dobrze (to samo M74LS157) ale czasem wywalało błąd pamięci.
A tutaj - wymiana na stare poczciwe UCY jakby przyniosla zdecydowaną poprawę i program przechodzi pełny test pamięci 48KB...
Jeszcze potestuje - zobacze...
Na koniec moze machnę oscyloskopem zrzut - z relacji sygnalow MREQ=>RAS=>MUX=>CAS
póoki co jest wporządku i cprogram łazi w płetli bez wykrzaczania się oraz "iścia" w pole :D
-
A że tak zapytam, jakiego typu masz bufor 74x04, który robi za linię opóźniającą /MREQ -> /MUX w Cobrze?
-
A ja zapytam, choć pewnie odpowiedź nie jest łatwa do ustalenia - czy wpływ użytych MUX-ów na funkcjonowanie DRAM wiąże się z cyklem dostępu, czy odświeżania?
Na zdrowy rozum - dostęp jest bardziej złożony niż refresh, więc większa szansa, że tu się coś krzaczy.
Z obserwacji - zawartość DRAM się chyba jednak krzaczy, czyli jakby refresh.
A że tak zapytam, jakiego typu masz bufor
Na szczęście w męskim gronie takie pytanie można zadać bez konsekwencji fochowo-przemocowych ;)
-
@KLAUD - a że tak odpowiem pokrótce w całości:
MREQ\ (19 Z80) => inwerter UCY7404 - otrzymujemy MREQ. (wykrzystany dalej do wytworzenia MEMR\ i MEMW\ - standard)
MREQ (7404) => kolejny inwerter UCY7404 - otrzymujemy sygnał RAS\ to już daje jakieś 20ns opóźnienia w stos. do MREQ\.
Sygnał MUX jest juz w troche bardziej finezyjny sposób uzyskiwany:
Dwa sygnały sa bramkowane (MREQ oraz rfsh\). w MOMENCIE GDY MAMY dostęp do pamieci (ale nie cykl odświezania) - na wejsciu D/CLK przerzutnika pojawia sie stan wysoki i w tym momencie jest po juz przepisywany na wyjscie wraz z KOLEJNYM narastajacym zboczem sygnału zegarowego 6,5MHz (podane na wejscia CLK obu przerzutników na schemacie)
W efekcie na wyjsciu mamy przerzut ze stanu niskiego do wysokiego po jakichs 100ns.
Cały "cykiel" kończy się w momencie przejscia sygnału MREQ (nie mylić z MREQ\) do stanu niskiego (MREQ\=H) LUB RFSH\ do stanu niskiego (potrzebne tylko linie A0-A6) zatem układ generuje MUX tylko w trybie DOstępu do pamieci ( ale już nie odświeżania)
Dalej mamy sygnal CAS - ktory obecnie (pakiet4164) uzyskiwany jest z układu UCY7410. (kolejne 20ns opoznienia w stos do MUX).
Jest to przerobka w stos . do oryginalnego układu COBRY - opisana w AV.
Pierwsza bramka - wejscia:
MREQ ,A14,A15 =>wyjście (nazwałem roboczo Q3[było to wyście Q3 wczesniejszego, usuniętego dekodera 74S405] ) - dekodowany ostatni segment 16KB ( stan L) w przestrzeni pamieci (EPROM/układ wizji) lub pierwsze trzy segmenty pamieci (48KB DRAM) stan H.
Druga bramka:
Q3 , MREQ , MUX po linii opozniającej RC 330R/100pF => wyjscie - sygnał CAS dla 4164.
@trojacek
Odpowiedz rzeczywiscie nie jest prosta ale ja napisze tak - jeszcze nie mierzylem oscyloskopem dokładnie przebiegów PO ZASTOSOWANIU układów UCY74157.
W sensie mierzyłem i teoretycznie- jak w przyp. reszty układów nie było sie do czego przyczepić. JEdnak jesli MUXY przeczywiscie nie wyrabiaja z pojemnosciowym obciażeniem na iniach A0-A7 pamięci - to problem moze być w obu cyklach - zarówno odswieżania jak i dostepu - zwłaszcza odczytu - w ostatniej fazie po ustaleniu sygnalu CAS\
PRzy wczesniejszych MUXach - program potrafil iśc w "pole" - a jest tak napisany - ze NIE KORZYSTA z pamieci - a jedynie z wen. rejestrow procesora - jedynie testujac pamięc.
Podejrzewam jakiesbledne przypadkowe odczyty z bufora linii danych pamieci...
jeszcze zastanawiałem się nad pamiecią testową AT28C16 ale ona ma wystarczająco długi czas dostepu - 150ns.
W kazdym razie obecnie po wymianie MUXÓw na uklady 74157 - wszelkie błedy ustapiły...
program wykonuje sie perfekcyjnie - żadnych skoków pod adres startu lub zaieszania się- czy tez przechodzenia do stanu HALT procesora....
JUz drugi dzien jest o.k.
Okazuje się, że w Cobrze zastosowanie multiplekserów UCY74157 jest po prostu krytyczne.
na koniec planuję troche pomierzyć oscyloskopem opóźnienia na różnych multiplekserach - moze sie uda wrzucić jakies wyniki tutaj
-
jeszcze się tak zastanawiam- bo nie probowałem na serii HCT.ALE generalnie skoro wersja TTL (LS) ma generalnie slabiutka wydajnośc w stanie wysokim i w sumie nie ma sie co dziwic ze ma problem przy przeladowaniu własnych oraz ośmiu pamięci + montażowych pojemnosci PCB - to czy np nie byłoby rozwiązaniem zapodanie jakiejś drabinki rezystorowej na wyjsciach MUXów - podpietej pod VCC? Musialbym ten patent przetestowac - np. 8x330-470R.I wtedy zastosować te niesforne upierdliwce co wczesniej :).