Kontynuuję swoją zabawę z antycznym procesorem.
Wytrawiłem i złożyłem płytkę zawierającą CPU, pamięci i parę innych
układów. W dekoderze adresów i układzie przełączania banków pracują
układy z serii HCT i LS. Szyna adresowa jest podłączona bezpośrednio do
pamięci i wejść dekodera - bufory (74HCT245) dałem dopiero przed
złączem, do którego w przyszłości zamierzam podłączyć inne moduły.
Płytka jest jednostronna, więc sporo sygnałów musiałem puścić mostkami,
gdzieniegdzie masa i zasilanie zostały puszczone w ten sam sposób.

Wszystkie połączenia sprawdziłem wiele razy. Wygląda jednak na to, że
urządzenie nie działa prawidłowo. To znaczy działa wybitnie niestabilnie.

Odpaliłem prosty program migający dwiema diodami podłączonymi do
74LS373. Działał on jako tako w momencie, gdy program był prostą pętlą,
niekorzystającą z żadnych wywołań funkcji (taka zmiana skutkowała
zupełnie chaotycznym zachowaniem LED-ów). Jedyne co zaobserwowałem, to
zauważalne zwalnianie tempa migani po położeniu palca na jednym z
układów 74HCT00 (układ generujący sygnały WR i RD + jedna bramka w roli
inwertera wykorzystywanego w dekoderze adresów).

Wylutowałem ten układ i zastąpiłem go gniazdkiem. Próbowałem podmienić
go na inne egzemplarze. Na wersji LS i zwykłym UCY7400 w ogóle nie
działa (diody nie migają).

Dziwne jest jednak to, że po włożeniu w podstawkę 74HCT00 układ nie
zaczął się zachowywać tak, jak na początku. Diody co prawda migają, ale
dużo wolniej i nieregularnie, nieraz "przeskakując" swoją kolejkę.

Sytuacja znacznie poprawia się po dotknięciu masy palcem albo
podłączeniu oscyloskopu do masy.

Ktoś orientuje się co może odpowiadać za takie zachowanie? Jak to
zdebugować?

Próbowałem już poprawić "podejrzane" mostki masy, zastępując je
izolowanymi przewodami, podłączonymi bliżej gniazdka zasilana.

Może mieć znaczenie fakt, że pole masy tworzy "pierścień na obrzeżu płytki?

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5b6c2338$0$679$6...@n...neostrada.
pl...

Ech, przypomniales mi dawne czasy.
Plytka nie dziala, a na oscyloskopie wszytko w porzadku.
Z oscyloskopem dziala, a bez oscyloskopu nie dziala.
Doszedlem do tego, ze wystarczylo podlaczyc mase od oscyloskopu i
dziala :-)

Zeby bylo smieszniej - to byl interfejs magnetofonu do Atari, ktory
jak wiadomo 6502 mial :-)


>Wytrawiłem i złożyłem płytkę zawierającą CPU, pamięci i parę innych
>układów. W dekoderze adresów i układzie przełączania banków pracują
>układy z serii HCT i LS. Szyna adresowa jest podłączona bezpośrednio
>do
>pamięci i wejść dekodera - bufory (74HCT245) dałem dopiero przed
>złączem, do którego w przyszłości zamierzam podłączyć inne moduły.

Tak w ogolnosci - o ile dobrze pamietam, to 6502 byl elektrycznie
"slaby" i obciazanie wieloma ukladami LS nie jest wskazane.

>Płytka jest jednostronna, więc sporo sygnałów musiałem puścić
>mostkami,
>gdzieniegdzie masa i zasilanie zostały puszczone w ten sam sposób.

Tez sie moze mscic.
Kondensatorowo nie zalowales przy tym ?

>Odpaliłem prosty program migający dwiema diodami podłączonymi do
>74LS373. Działał on jako tako w momencie, gdy program był prostą
>pętlą,
>niekorzystającą z żadnych wywołań funkcji (taka zmiana skutkowała
>zupełnie chaotycznym zachowaniem LED-ów).

Sugeruje problemy z RAM. Adres powrotu na stosie jest w RAM.

>Jedyne co zaobserwowałem, to
>zauważalne zwalnianie tempa migani po położeniu palca na jednym z
>układów 74HCT00 (układ generujący sygnały WR i RD + jedna bramka w
>roli
>inwertera wykorzystywanego w dekoderze adresów).

Na HCT uwazaj - one maja obnizone progi napiec na wejsciu, dostosowane
to standardu wyjsc TTL.
Z 6502 tez powinny dzialac, ale jesli on jakis przeciazony i w
standardzie sie nie miesci ...

>Ktoś orientuje się co może odpowiadać za takie zachowanie? Jak to
>zdebugować?

W pierwszej kolejnosci - przejdz na nizsza czestotliwosc.
Moze problemy ustapia.

>Próbowałem już poprawić "podejrzane" mostki masy, zastępując je
>izolowanymi przewodami, podłączonymi bliżej gniazdka zasilana.

To tez niekoniecznie pomoze.

>Może mieć znaczenie fakt, że pole masy tworzy "pierścień na obrzeżu
>płytki?

Raczej nie.
Ja bym raczej dodal troche polaczen, zeby ta masa byla "kratką".
Ale czy to pomoze ... nie obiecuje.

J.

do góry

On 09.08.2018 14:06, J.F. wrote:

> Tak w ogolnosci - o ile dobrze pamietam, to 6502 byl elektrycznie
> "slaby" i obciazanie wieloma ukladami LS nie jest wskazane.

Z tego co czytałem, to słabe były linie adresowe. Do linii danych można
było już podpiąć więcej układów. Nie wiem jak z liniami sterującymi i
zegarowymi, nie sądzę jednak, żeby jeden układ LS miał im zaszkodzić...
Co do samych linii adresowych, to u mnie co prawda fufory znajdują się
dopiero przed gniazdem, jednak nie powinno mieć to większego znaczenia.
Te lnie są obciążone tylko RAM-em 6502, EPROMem 27128 oraz paroma
układami HCT.


> Tez sie moze mscic.
> Kondensatorowo nie zalowales przy tym ?

Hmm... Co masz na myśli? ;)


> Sugeruje problemy z RAM. Adres powrotu na stosie jest w RAM.

Stawiam jednak na to, że jest to efektem tej samej niestabilności. Ten
sam kod i te same układy RAM-u działały wcześniej na płytce
prototypowej. Nie pomaga także zamiana RAM-ów miejscami (drugi
praktycznie nie jest w tej chwili używany).
Zwyczajnie prosty kod niekorzystający z odwołań do funkcji zdaje się
lepiej reagować na przejawy opisywanego problemu.

Poza tym niestabilna praca jest widoczna nawet po wyjęciu RAM-u,
oczywiście gdy wgrany jest program nieodwołujący się nie stosu.


> Na HCT uwazaj - one maja obnizone progi napiec na wejsciu, dostosowane
> to standardu wyjsc TTL.
> Z 6502 tez powinny dzialac, ale jesli on jakis przeciazony i w
> standardzie sie nie miesci ...

W moim przypadku mowa o oryginalnym MOS6502, a nie nowocześniejszym,
CMOS-owym 65X02. On chyba miał wyjścia właśnie w standardzie TTL?
Dlatego właśnie zastosowałem HCT, a nie np. HC.


> W pierwszej kolejnosci - przejdz na nizsza czestotliwosc.
> Moze problemy ustapia.

Też próbowałem. Przy 1MHz układ ciągle jest niestabilny.



>> Może mieć znaczenie fakt, że pole masy tworzy "pierścień na obrzeżu
>> płytki?
>
> Raczej nie.
> Ja bym raczej dodal troche polaczen, zeby ta masa byla "kratką".
> Ale czy to pomoze ... nie obiecuje.

Przeciąłem dremelem pole masy przy obrzeżu płytki z jednej strony, tak
więc teraz nie stanowi zamkniętego pierścienia. Nie pomogło.

Na dobrą sprawę mógłbym spróbować zrobić to w formie płytki dwustronnej,
z większym polem masy od góry. Wątpię jednak, żeby dało mi się zgrać
warstwy przy tak dużej płytce, a zamówienie tego w fabryce to jednak za
duży koszt jak na amatorski projekt. W dodatku bez gwarancji, że problem
nie ujawni się też na fabrycznym PCB. ;)

No cóż... Muszę szukać dalej...

do góry

On 8/9/2018 1:19 PM, Atlantis wrote:
> Sytuacja znacznie poprawia się po dotknięciu masy palcem albo
> podłączeniu oscyloskopu do masy.

1. Jedna z lini input procesora/pamięci badź czegokolwiek wisi sobie w
powietrzu.

2. Zabrakło kondensatorów na zasilaniu, dolutuj na pająka w poprzek
scalaków.

Zainteresuj się tym:

https://pl.aliexpress.com/wholesale?catId=0&initiati
ve_id=SB_20180809051854&SearchText=logic+probe+ttl

Cudo to nie jest ale potrafi wykryć niepodpięte wejścia i ogólnie się
przydaje w takich sytuacjach.

do góry

On 09.08.2018 15:20, Sebastian Biały wrote:

> 1. Jedna z lini input procesora/pamięci badź czegokolwiek wisi sobie w
> powietrzu.

Wielkie dzięki. Dosłowne strzał w dziesiątkę. Problem tkwił w projekcie,
podczas gdy ja szukałem czegoś związanego z prowadzeniem masy albo
zasilania.
Jak się okazuje błąd pojawił się jeszcze na etapie rysowania schematu w
Eagle - dwa sygnały stykały się ze sobą, ale nie zostały połączone -
właśnie przy tym nieszczęsnym 7400.

do góry

Hmm... Mam jeszcze jedną "zagadkę" związaną z tym układem.
Poprawiłem zauważone błędy, poprzednio opisany problem zniknął.
Zauważyłem jednak pewną inną "anomalię". Mianowicie w pamięci EPROM był
wgrany prosty program do migania LED-ami. z dwiema zagnieżdżonymi
pętlami opóźniającymi zmniejszającymi wartość rejestru. Program działał
prawidłowo, ale zauważyłem jedną dziwną rzecz.
Raz na jakiś czas (mniej więcej jedno na dziesięć podpięć zasilania)
diody migały szybciej, niż powinny. Czasem była to normalna szybkość x2,
czasem x4, czasem więcej. Zresetowanie mikroprocesora NIE przywracało
normalnego tempa.

Moje pierwsze podejrzenie dotyczyło generatora, jednak test z
oscyloskopem wykazał, że podczas wystąpienia anomalii przebieg taktujący
wygląda zupełnie normalnie.

Teraz zmieniłem wsad - zamiast pętli opóźniającej mam zmienną funkcję
pełniącą funkcję timera. Od chwili wykasowania i ponownego
zaprogramowania pamięci problem nie wystąpił.

Co mogło być przyczyną takiego dziwnego zachowania? Czy uszkodzenie
zawartości pamięci przez promienie słoneczne jest prawdopodobnym
wyjaśnieniem? Przez weekend płytka stała na stole, tuż przy oknie.

do góry

On 8/12/2018 8:12 PM, Atlantis wrote:
> Teraz zmieniłem wsad - zamiast pętli opóźniającej mam zmienną funkcję
> pełniącą funkcję timera.

Co to jest zmienna funkcja?

Stawiam na niezainicjowana zmienną w ram.

> Co mogło być przyczyną takiego dziwnego zachowania? Czy uszkodzenie
> zawartości pamięci przez promienie słoneczne jest prawdopodobnym
> wyjaśnieniem?

Kasowalem kiedyś epromy słońcem, ale trwało to kilka dni i zazwyczaj
kończyło sie w 50%. Niektórych w ogóle nie dało się skasować.

do góry

On 12.08.2018 20:47, Sebastian Biały wrote:

> Co to jest zmienna funkcja?

Tak to jest, jak się edytuje wiadomość i potem tego nie czyta. ;)
Chodziło mi o zmienną pełniącą funkcję timera. Czyli mam w pamięci
zmienną szesnastobitową, która jest zmniejszana i jeśli dojdzie do zera,
wykonuje się kod zapalający lub gaszący diodę.


> Stawiam na niezainicjowana zmienną w ram.

Wersja ze zmienną akurat działa ok. Problemy były z prostszym wsadem,
gdzie była tylko pętla opóźniająca na rejestrach X i Y.


> Kasowalem kiedyś epromy słońcem, ale trwało to kilka dni i zazwyczaj
> kończyło sie w 50%. Niektórych w ogóle nie dało się skasować.

Chodzi mi o to, czy wystawienie EPROM-u na działanie słońca (właśnie
przez kilka dni, poprzez położenie go koło okna) może w teorii
spowodować niestabilne działania programu? A konkretnie działanie
niestabilne w ten konkretny sposób, gdy czasem po włączeniu do zasilania
program zaczyna zachowywać się dziwnie?

Bop nic innego nie przychodzi mi do głowy. Skoro generator sygnału
taktującego był ok, a program robił to co powinien (tyko czasem
szybciej) to mam wrażenie, że raz na ileś tam włączeń musiało się dziać
coś, co sprawiało, że błędnie interpretowana była wartość, którą
reinicjowany był rejestr po zakończeniu przebiegu pętli.

do góry

On 8/12/2018 9:07 PM, Atlantis wrote:
>> Stawiam na niezainicjowana zmienną w ram.
> Wersja ze zmienną akurat działa ok. Problemy były z prostszym wsadem,
> gdzie była tylko pętla opóźniająca na rejestrach X i Y.

Która była ładowana z czego?

Ponadto jednak w tego typu projekcie wykluczyłbym najpierw hardware.
6502 można solidnie przetaktować przez zniekształcony sygnał zegarowy,
wtedy częśc funkcjonalności nie działa a takim małym programie czasem
nie widać że np. się sam resetuje. Jak wygląda generator zegara?

> Chodzi mi o to, czy wystawienie EPROM-u na działanie słońca (właśnie
> przez kilka dni, poprzez położenie go koło okna) może w teorii
> spowodować niestabilne działania programu? A konkretnie działanie
> niestabilne w ten konkretny sposób, gdy czasem po włączeniu do zasilania
> program zaczyna zachowywać się dziwnie?

Wątpliwe. Nie dość że za krotko to jeszcze epromy nie mają w zwyczaju
wracać jak już się ustawia na 1.

> Bop nic innego nie przychodzi mi do głowy. Skoro generator sygnału
> taktującego był ok, a program robił to co powinien (tyko czasem
> szybciej) to mam wrażenie, że raz na ileś tam włączeń musiało się dziać
> coś, co sprawiało, że błędnie interpretowana była wartość, którą
> reinicjowany był rejestr po zakończeniu przebiegu pętli.

Niezainicjowania zmienna/rejestr, błąd w sofcie. Mozliwe, choć watpliwe
że wina asemblera/kompilatora. Czego używasz?

Pokaż źródła jednego i drugiego. Jeszcze coś pamiętam z asm 6502.

do góry

On 8/12/2018 9:07 PM, Atlantis wrote:
> Bop nic innego nie przychodzi mi do głowy.

Jesli to problem z hardware warto zerknąc tutaj:

https://github.com/Klaus2m5/6502_65C02_functional_te
sts

Mała uwaga: miałem w ręku uszkodzony 6510 bodaj, wydłubany z C64 na
którym Kernal nie wstawał tylko sobie wisiał, ale kolory na ekranie są
poprawne czyli część kodu wykonał. Okazało się przy zabawie że coś było
w środku popsute co powodowało że jedna z instrukcji, jakiś prostych jak
TAX czy podobna powodowała halt procesora. Zdiagnozował to kolega, wiele
więcej nie wiem, ale lata potem doczytalem że ludzie bawiący się naprawą
retro czasami trafiają na egzemplarze które "prawie działają". Hipoteza
jest taka że maskrom w cpu do zarządzania bebechami czasem gubi bit ze
starości, naprężeń, chemitrails czy innych neutrin.

do góry