Płytka z MOS6502 niestabilna do czasu dotknięci

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?

Reply to
Atlantis
Loading thread data ...

Użytkownik "Atlantis" napisał w wiadomości grup dyskusyjnych:5b6c2338$0$679$ snipped-for-privacy@news.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 :-)

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

Tez sie moze mscic. Kondensatorowo nie zalowales przy tym ?

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

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 pierwszej kolejnosci - przejdz na nizsza czestotliwosc. Moze problemy ustapia.

To tez niekoniecznie pomoze.

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

J.

Reply to
J.F.

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.

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

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.

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.

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

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...

Reply to
Atlantis

  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:

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

Reply to
Sebastian Biały

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.

Reply to
Atlantis

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.

Reply to
Atlantis

Co to jest zmienna funkcja?

Stawiam na niezainicjowana zmienną w ram.

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ć.

Reply to
Sebastian Biały

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ę.

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.

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.

Reply to
Atlantis

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?

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

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.

Reply to
Sebastian Biały

Jesli to problem z hardware warto zerknąc tutaj:

formatting link
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.

Reply to
Sebastian Biały

Pętla opóźniająca była osobnym podprogramem, który był wywoływany po każdym zmianie stanu diody. Wewnątrz tego podprogramu znajdowały się właściwie tylko dwie pętle, jedna zagnieżdżona w drugiej. Pierwsza operowała na rejestrze X, druga na Y. Każdy z nich był inicjowany wartością 0xFF i po każdym przejściu zmniejszany o jeden.

To była moja pierwsza myśl. Na oscyloskopie wszystko wygląda ok. To znaczy sygnał zegarowy bezpośrednio na wyjściu generatora SG51P jest minimalnie "postrzępiony" na górze, jednak po przejściu przez dzienlnik na 74HCT74 robi się z tego całkiem ładny sygnał, niemalże kwadrat z lekko zaokrąglonymi krawędziami.

Przy większych projektach używam cc65, ale tutaj posłużyłem się prostym webowym narzędziem asm80.com.

Pierwszy program - ten, z któ©ym były problemy:

CTRL EQU $0BC00

.ORG $0C000 CLD LDX #$FF TXS

LOOP: LDA #$04 STA CTRL

JSR DELAY

LDA #$80 STA CTRL

JSR DELAY

JMP LOOP

DELAY: LDX $FF DELAY_LOOP1: LDY $FF DELAY_LOOP2: NOP DEY BNE DELAY_LOOP2 DEX BNE DELAY_LOOP1 RTS

.ORG $FFFE DW $0C000

Drugi program - ten, który teraz zdaje się działać prawidłowo:

TRL EQU $0BC00

.ORG $C000 INIT: LDX #$FF TXS LDA #$80 STA CTRL LDA #$01 STA DIODE LDA #$FF STA TIMER LDA #$FF STA TIMER+1 LOOP: JSR HANDLE_TIMER JMP LOOP

HANDLE_TIMER: DEC TIMER BNE HT_RET LDA #$FF STA TIMER DEC TIMER+1 BNE HT_RET LDA #$FF STA TIMER+1 ; tutaj wykonujemy nasz kod LDA DIODE BEQ SET_DIODE LDA #$04 STA CTRL LDA #$00 STA DIODE JMP HT_RET SET_DIODE: LDA #$80 STA CTRL LDA #$01 STA DIODE HT_RET: RTS

IRQ: RTI

NMI: RTI

.ORG $0200 TIMER: DS 2 DIODE: DS 1

.ORG $FFFA DW NMI DW INIT DW IRQ

Reply to
Atlantis

I jeszcze jedno, czy hipotetycznie powodem (lub jednym z powodów) takiej niestabilności może być fakt zasilania tego z 5V stabilizowanego zasilacza impulsowego?

Reply to
Atlantis

Jak chiński to może. Dodaj solidny elektrolit, najlepiej mały i duzy na zasilaniu.

Reply to
Sebastian Biały

A co wychodzi na outpucie F1 i F2? Nie obciążyles przypadkiem za bardzo jednego z nich? F2 nie może popychac więcej jak 2 bramek TTL jak pamiętam.

Nie widze jakiś dramatów. Wyłącz jeszcze przerwania SEI.

Oczywiście po adresem $0100 masz ram na stos :) ? I stronę zerową ?

Reply to
Sebastian Biały

Moze

Ale nie tak, ze raz po wlaczeniu petla dziala dobrze, a innym razem nie.

... hm, a eproma zakleiles ? Moze to oswietlenie mu przeszkadzalo i sie zmienialo ?

J.

Reply to
J.F.

Z tego co pamiętam, sygnały w porządku. F1 jest w ogóle nieużywany w moim projekcie. F2 w chwili obecnej jest podłączony do wejścia jednej z bramek 74HCT00, będącej elementem układu generującego sygnały RD i WR. F2 jest też wyprowadzony na złącze - zgodnie z założeniami ma taktować generator baudrate'u dla UART-a.

A właśnie... Możliwe, żeby winę za takie zachowanie ponosił brak tej instrukcji, jak również brak wektorów wskazujących na (chociażby puste) podprogramy obsługujące przerwanie? Coś w momencie podłączenia zasilania powodowałoby odczytanie fałszywej informacji o przerwaniu i namieszanie w programie?

Tak. RAM zaczyna się od 0x0000.

Reply to
Atlantis

Był 1000uF low-ESR. Podczas eksperymentów wstawiłem mniejszy, 220uF. Opisany problem występował w obydwu przypadkach.

A co do samego CPU - parę tygodni temu przetestowałem go na prowizorycznej konstrukcji złożonej na płytce uniwersalnej, z dużą ilością kynaru. Wtedy był w stanie odpalić Enhanced BASIC-a i działał normalnie. Problemem była jednak wrażliwość tej prowizorki na wstrząsy (Zimny lut ukryty pod grubą warstwą kynaru? Uszkodzone gniazdko?) więc przeniosłem projekt na normalne PCB, a właściwie zestaw kilka modułów.

Na razie mam tylko moduł z CPU, pamięciami i podstawową logiką, więc BASIC-a jeszcze nie odpalę. Mogłem jedynie użyć LED-ów do debugowania.

Reply to
Atlantis

A co z liniami IRQ/ i NMI/ ? O ile pamietam to na stale do + dolaczone i nieaktywne.

Na pewno bezpieczniej bedzie ustawic w obsludze przerwania chocby samo RETI.

Bo teraz, jesli przerwanie sie zglosi, lub odczytasz rozkaz FF z pamieci, to program idzie w maliny i robi nie wiadomo co i jak dlugo ...

J.

Reply to
J.F.

Swoją drogą, nie chcę zaczynać nowego wątku, więc napiszę tutaj. Chciałbym upewnić się co do jednej rzeczy - jak wygląda kwestia kompatybilności CMOS-owych wersji 6502 np taki (R65C02P4) z układami różnych rodzin logicznych? Zachowują one wsteczną kompatybilność z układami TTL? Stosując je mogę stosować takie rodziny jak 74LS czy

74HCT, czy jednak powinienem użyć układów z serii 74HC albo 40xx?
Reply to
Atlantis

Hmm... Już chyba widzę w czym rzecz. Problem dotyczył poniższej pętli opóźniającej:

DELAY: LDX $FF DELAY_LOOP1: LDY $FF DELAY_LOOP2: NOP DEY BNE DELAY_LOOP2 DEX BNE DELAY_LOOP1 RTS

Na pierwszy rzut oka wszystko w porządku, a jednak popełniłem szkolny błąd. W pierwszych dwóch instrukcjach zabrakło znaku "#'. Z tego powodu argumentem instrukcji LDX i LDY nie była wartość 0xFF, ale wartość odczytywana spod adresu 0x00FF.

Reply to
Atlantis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.