CA80 reaktywacja. Co można zrobić ze starym ośmiobitowcem.

Dzień dobry.

Mój CA80 został reanimowany (dzięki https://www.elektroda.pl/rtvforum/topic2697585-240.html), więc najwyższy czas dać mu jakieś zajęcie. Choćby wyświetlanie czasu. W końcu zegar w domu jest potrzebny. Można na przykład sterować grzałką bojlera, żeby wykorzystać drugą taryfę i zmniejszyć rachunki za prąd. (Zapomniałem! Prąd miał zdrożeć, ale kwoty na rachunkach nie wzrosną. )
Prąd niestety nie zawsze jest w gniazdku. Mimo, że CA80 jest prawdziwym RTC, po włączeniu zasilania niestety ma nieustawioną godzinę. Bez rezerwowego zasilania ani rusz... Jest na to rada. Pierwszy pomysł, jaki mi przyszedł po uruchomieniu mojego zabytku, to wpisanie czasu z serwera NTP za pośrednictwem ESP8266. Schemat i oprogramowanie zamieściłem we wspomnianym wcześniej wątku. Wystarczy przylutować złączkę golpin do 7442. Mamy tam wszystkie sygnały sterujące (ABCD) potrzebne do zdekodowania klawisza oraz zasilanie do płytki sterującej. Trzy linie wracające z sygnałem klawiatury wpinamy bezpośrednio do ZK.

Układ już jest zmontowany i działa.



Nie wszystkim podoba się takie rozwiązanie (też nie jestem z dumny z tego powodu), jednak zabytkowi należy się więcej szacunku. Na to też jest rada. Pani Tasza (chylę czoła) w tym samym czasie co ja zajęła się podobnym tematem. Zrobiła zdalne sterowanie klawiaturą CA80 z komputera przez Arduino. Użyła enkoder 74147, żeby z powrotem uzyskać cztery linie. Polecam przeczytać http://bienata.waw.pl/ca808.php
Gdy trafiłem na jej dzieło, stwierdziłem, że może lepiej będzie zabrać zabawki i schować się do swojej norki...
Nikt nie jest doskonały, a zwłaszcza ja. Dużo myślałem, co dalej począć i stwierdziłem, że zamiast rozpaczać, można pójść za ciosem. Przecież enkoder można wstawić do mojego projektu. Wilk syty i owca cała.
Długie myślenie pomaga nie tylko przy pisaniu procedur. Można też lepiej zaprojektować urządzenie.
Po kilku próbach z enkoderem zmieniłem założenia. Po co rozbudowywać niedoskonały układ, kiedy można stworzyć go od nowa.
Okazuje się, że multiplekser lepiej spełni zadanie. Do tego na wyjściu wstawiłem inny bufor i w ten sposób udało się zablokować fizyczną klawiaturę, żeby przez nieuwagę nie zakłócić "transmisji" danych przypadkowym naciśnięciem klawisza. Do strobowania bufora wykorzystałem ósme wyjście z rejestru PCF8574. Program sterujący prawie się nie zmieni. Jeszcze nie wiem, czy lepiej będzie zmienić tablicę kodów klawiszy czy zanegować strob. W końcu 7400 ma cztery bramki. Niestety w mojej szufladzie nie znalazłem multipleksera, więc układ sprawdzę, gdy dotrze przesyłka.

W oczekiwaniu na multiplekser zrobiłem porządek w okablowaniu i przymocowałem płytki do siebie, żeby zrobić trochę miejsca na nowy układ. Przygotowałem wszystko na płytce stykowej i kiedy przesyłka dotarła, pozostało tylko włożyć 74150 w przewidziane dla niego miejsce. Po wgraniu nowej wersji programu (zmiany tylko kosmetyczne), wszystko ruszyło zgodnie z przewidywaniami. Tylko przewodów musiałem szukać w różnych zakamarkach, bo trochę ich przybyło. Stara wersja miała siedem sygnałów i zasilanie. Nowa szesnaście sygnałów i zasilanie. Dwa razy więcej przewodów połączeniowych! Do tego na ZK wyjścia z 7442 nie są umieszczone po kolei, więc bardzo trzeba uważać, żeby czegoś nie pomylić. Mimo to udało się. Klawiatura na czas "transmisji" jest zablokowana i połączenie z płytą główną jest "bezinwazyjne", jak to określiła cytowana wcześniej Pani Tasza.

Ale nie możemy jeszcze spocząć na laurach, bo wyświetlanie zegara nie jest zbyt spektakularnym osiągnięciem.
Jeżeli ktoś przyjrzał się fotografii nowego układu, na pewno zauważył płytkę z kartą microSD. To będzie kolejny krok w rozwoju mojego projektu.
Zamierzam "wstukiwać" kod, uruchamiać go i sterować pracą całego systemu za pomocą plików umieszczonych na SD.

I jeszcze poprawiony program do ESP8266. Proszę nie zapomnieć o wstawieniu swoich danych WiFi.
CA80_inter..._74150.txt Download (5.71 kB)

Przed podjęciem kolejnych kroków postanowiłem przetestować szybkość transmisji prototypu.
Napisałem program, który próbuje przesyłać dane z coraz krótszym czasem "wciśnięcia" i "puszczenia" klawisza. Za pomocą poleceń monitora CA80 wpisuje on krótki kod maszynowy, następnie wartość opóźnienia i uruchamia program w CA80. Na wyświetlaczu powinien pojawić się napis "TEST" i wartość opóźnienia szesnastkowo.
Po wielu próbach okazało się, że zarówno wciśnięcie jak puszczenie klawisza powinno trwać dłużej niż 40 ms. Ostatnia wartość, którą udało się wpisać pod adres 0xc01b wynosiła zwykle 0x28 lub 0x29 czyli 40 lub 41. Dla pewności przyjąłem 42 ms. Ta wartość nie uwzględnia czasu transmisji I2C. Gdyby użyć portu równoległego kontrolera, można by uzyskać większe prędkości. Jednak ESP nie ma aż tylu dostępnych wyjść i dlatego zastosowałem PCF8574. Można spróbować hybrydę AVR i ESP...
Niestety nie przetestowałem pierwszego prototypu, więc nie można porównać obu metod. Może jeszcze wrócę do "inwazyjnej" maszyny.
Program nie używa WiFi ani microSD, więc można zamiast ESP8266 zastosować dowolny mikrokontroler np. Arduino Nano, który też można włożyć do płytki stykowej. Wtedy wystarczy jedno napięcie zasilające 5V. Mikrokontroler podłączony jest tylko przez magistralę I2C. W trakcie prób można obserwować przebieg transmisji na ekranie komputera ( monitor portu szeregowego ).
Wiele razy usuwałem usterki spowodowane niełączeniem jakiegoś przewodu w płytce stykowej(najczęściej zielonej). Przy tej ilości przewodów łatwo o awarię.
Chyba nadszedł czas na polutowanie prototypu.

Dzisiaj nadal męczyłem pajęczynę, ale bez problemów z kablami. Zmodyfikowałem trochę program i zmierzyłem czas przesłania 256 bajtów o kolejnych wartościach 0 - 0xff. Trochę ponad minutę czyli 1kB ponad cztery minuty. Zapis 1 kB bez rekordu EOF na taśmie magnetofonowej to 2 minuty czyli "wklepywanie " jest dwa razy wolniejsze od magnetofonu. Za to nie musimy pierwszy raz wpisywać ręcznie, co na pewno zajęłoby kilkanaście minut, o ile nie pomylilibyśmy (ale trudny wyraz mi się trafł!) się w kilku miejscach. Poza tym jak wygodne jest używanie magnetofonu, pamiętają chyba tylko najstarsi górale. Sprawdziłem ręcznie przesłany blok pamięci i nie znalazłem ani jednego błędu. To znaczy, że TTL z 1976 roku nadal jest w pełni sprawny. 74150 jest najstarszym elementem mojej układanki.
Na razie nie testuję poprzedniej wersji, bo żal mi rozbierać zabawkę. Tyle się namęczyłem z kabelkami, że jeszcze kilka dni się z nimi pobawię.

Dzisiaj niedziela, więc temat mniej poważny (o ile zajmowanie się wykopaliskami można uznać za poważne w ogóle). Jestem zbieraczem wszystkiego, więc mam wiele niepotrzebnych rzeczy, ale wśród nich czasem znajduję jakąś perełkę. Jedną z nich jest kopia mojej pracy dyplomowej z technikum. Teraz uwaga!!! Podaję temat pracy: "Przeanalizować użyteczne procedury i podprogramy systemu mikroprocesorowego i wykorzystać je w przykładowych programach". Temat, jak temat... Ale jakiego systemu? No właśnie: SA-80. Pamiętałem, że uczyłem się na nim asemblera. Zaczynałem od Intela 8080, bo nie miałem innej literatury. Na początek dostałem kserokopię skryptu Politechniki Warszawskiej, jeżeli mnie pamięć nie myli, napisanego przez profesora Misiurewicza. Kiedy dostałem małą broszurkę Ziloga z listą rozkazów Z80, od razu polubiłem nowe skoki względne, a zwłaszcza DJNZ. To było coś. Do dzisiaj robię błędy polegające na mieszaniu mnemoników Intela i Z80. Do teraz nie miało to żadnego znaczenia, bo programy pisałem na kartce i kompilowałem przy pomocy ołówka i gumki, czasem zaglądając do ściągi. Jakoś wszystko działało!
SA-80 zaprojektował Pan Stanisław Gardynik. W mojej szkole były montowane i uruchamiane również przystawki do tegoż komputera. Na mnie trafił programator EPROM.
Ale dzisiaj nie o tym. Na potrzeby w/w pracy napisałem pierwszą i zarazem jedną z ostatnich grę. Jest bardzo prosta, co umożliwiało wstukanie kodu na przerwie i pogranie z kolegami. W tamtych czasach zegarek z pozytywką był urządzeniem tak cennym, że mało kto taki miał... A komputer był prawie nieosiągalnym marzeniem. Piszę o tej grze, bo jeśli ktoś zna CA80, od razu zauważy podobieństwo. Procedury mają takie same nazwy (nie wszystkie), działają niemal identycznie. Brakuje procedury PRINT i musiałem ją napisać. Jak znam życie, pewnie skądś skopiowałem
Zamieszczam skany kilku stron mojej pracy wraz z listingiem gry. Oczywiście przerobiłem ją na CA80 i wynik mojej pracy również udostępniam. Przy okazji okazało się, że w listingu jest błąd! Napisałem JR NC a powinno być JR NZ, ale kod wynikowy był właściwy! To efekt przepisywania z kartki. Życzę miłej zabawy.

Jeżeli ktoś przyjrzał się listingowi (temu archiwalnemu), to na pewno zauważył, że system miał inne adresowanie RAMu. Przewidziany był tylko 1 kB od 0x4000. Bufor wyświetlacza, zegar i inne zmienne systemu były między 0x439f a 0x43ff.
W grze jest jeszcze błąd, którego nie mogę znaleźć. Gra działa, ale wyświetla tylko cyfry parzyste z wyjątkiem pierwszej. Generator liczb pseudolosowych polega na wycięciu młodszej cyfry setnych sekundy zegara systemowego... Kiedyś działało, a na CA80 kuleje... Może ktoś to naprawi? Ta sytuacja ułatwia zdobycie dobrej oceny. W czasie egzaminu (obronie pracy) na jednym z komputerów była wpisana właśnie ta gra. Egzaminatorzy walczyli z mizernym skutkiem. Pamiętam radość, gdy któremuś udało się uzyskać trzy "na szynach". Oczywiście skala ocen z tamtych czasów.

Dobry wieczór,

Orologgio wrote:

Gra działa, ale wyświetla tylko cyfry parzyste z wyjątkiem pierwszej. Generator liczb pseudolosowych polega na wycięciu młodszej cyfry setnych sekundy zegara systemowego... Kiedyś działało, a na CA80 kuleje...

Zakładam, że problem wynika z różnicy w implementacji obsługi klawiatury starego (SA) i nowego (CA) systemu oraz wykorzystania jako random setnych części sekundy zegara. Zegar napędzany jest w przerwaniach NMI, takoż w tychże dekrementowany jest licznik LCI, który m.in. służy do odmierzania czasu w kodzie procedurki systemowej CI. Procedura CI operuje opóźnieniami będącymi wielokrotnością 2ms, a licznik LCI jest zmieniany w niemal tym samym czasie co zmienne SETSEK, SEK, MIN etc.. zegara RTC, niejako synchronicznie. Stąd jak raz "załapiemy" się (nie)parzyste setne, to dalej odpytywanie SETSEK (czy STOPER jak nazwano w kodzie gry powyżej) będzie dawało (nie)parzyste wyniki, kwestia trafu. Listing CI w załączniku.

Powyższe zjawisko pokazuje działanie programu CI_demo.asm (źródło dla SB-Assembler) uruchamianego od $c000, filmik: https://youtu.be/gydT4Oe8i5k

Gdy zamiast procedurki CO użyjemy LBYTE i pooglądamy cały akumulator to widać, że dziesiątki już nie są tak podatne, klawiaturowa CI wprowadza opóźnienia na poziomie kilkudziesięciu a nie kilkuset milisekund, to widać w drugiej części filmiku, gdzie program uruchamiany jest od $c100

I stąd naprawa, choć nieco siermiężna to skuteczna - potrzeba zmodyfikować program tak, aby do losowania brał dziesiąte a nie setne, najprościej przestawić bity pobranej z RTC wartości czterema rozkazami RRA. Zmodyfikowana gierka refleks.asm (SB-Asm) także w załączniku, film z działania: https://youtu.be/oHgR7xUxmcQ

To prawda, trudno o dobry wynik, szczególnie gdy trzeba pilnować aparatu.

Przy okazji, w archiwum ze źródłami (CA80_SRC.zip), które wrzucono na to forum jest gra Reflex II, tam generację liczb losowych zrealizowano przy pomocy rejestru R (do odświeżania pamięci dynamicznych), którym indeksowany jest obszar systemowego EPROM, z tego punktu widzenia uznawany za "losowy", może warto i w to rozwiązanie zerknąć...

ps.
treść wczorajszego e-mail podtrzymuję, a tu kończę ogólnym dobranoc.

Dobry wieczór.

Postanowiłem w święta zająć się czymś poważniejszym niż zwykle, żeby nadrobić stracony przez ostatnie lata czas. Żeby się nie nudzić, wziąłem ze sobą CA80. Owinąłem pianką i zapakowałem do pudełka...
Okazało się, że pomysł był raczej słaby. Mój pupilek wyzionął ducha. Wyświetlacz nawet nie błysnął. Po oględzinach długo nie wiedziałem, co począć. Piny VFD ukruszyły się przy otworach w płytce drukowanej. Sytuacja nie jest beznadziejna, ale nie byłem przygotowany na taki remont. Lutownicy nie wziąłem, a o odsysaczu cyny nawet nie wspomnę. Zamiast robić coś pożytecznego, myślałem o nowym wyświetlaczu. Przy okazji narysowałem pierwszy w życiu schemat bez kartki i ołówka. Nie było łatwo. Straciłem kilka godzin na to, co zwykle zajmowało mi kilka minut... I na koniec okazało się, że brakuje jakichś footprintów i płytki drukowanej nie da się zaprojektować.
Po powrocie do domu, szybko zmontowałem pajęczynę i po kilku modyfikacjach programu (odwrócenie kolejności bufora i zanegowanie danych odczytanych ze złącza wyświetlacza) udało się. Już wiem, jaki wyświetlacz zbuduję do mojej zabawki.


Poważniejsze tematy niestety muszą zaczekać.

Dobry wieczór!
Postanowiłem naprawić wyświetlacz. Wylutowałem resztki nóżek z płytki. Tylko trzy ścieżki się odkleiły, więc nie jest najgorzej. Żeby awaria się nie powtórzyła, wymyśliłem wspornik. Gdyby ktoś pomyślał wcześniej... Starą sprawdzoną metodą z resztek laminatu i paru śrubek. Dwustronna taśma klejąca trzyma, że można szaleć, ale bez przesady, bo to jednak szkło.

Miałem już gotowy układ zastępczego wyświetlacza, więc też go zmodyfikowałem. Ponieważ "red is the color that will make me blue...", zmieniłem kolor LEDów. Ale nie na blue tylko green i to w jakimś żółtawym odcieniu. Gotowce występują zwykle czerwone, więc trzeba trochę polutować. Bez lupy ani rusz...

Pajęczyna zaświeciła od razu.

Zainspirował mnie pewien Italiano. Zbudował system oparty o układy Z80 na płytkach stykowych. Sami zobaczcie: https://www.leonardomiliani.com/wp-content/uploads/2019/01/IMG_5294.jpg
Może kiedyś sterowanie wyświetlaczem przeniosę do ESP, bo biedak się nudzi. Trzeba będzie dobudować jakieś piętro do jego płytki.

Dodano po 1 [godziny] 27 [minuty]:

A teraz z innej beczki.
Dawno, dawno temu, kiedy jeszcze nie potrzebowałem lupy, dostałem zadanie polegające na zbudowaniu symulatora obiektu fizycznego, opartego na 80C517. Dwanaście wejść analogowych itd. Okazało się, że na mikrokontroler trzeba trochę zaczekać, bo w Polsce jeszcze go nie ma. Żeby nie tracić czasu ograniczyłem liczbę wejć analogowych (które były niestety najważniejsze) i wybrałem 80C535. Ale zaraz, zaraz! Jaki to ma związek z CA80?

Jak widać na ostatnim obrazku, jest związek. 8255 jest połączone z Gold Pinami w liczbie dwa razy trzynaście, czyli miała to być wersja CA51, albo CA535... Wszystko chciałem przerabiać na CA80, wiadomo: stara miłość nie rdzewieje
Pani Tasza zbudowała "ładowarkę danych do pamięci". Kiedy zobaczyłem jej konstrukcję, którą wpina w podstawkę Z80, zaraz przypomniałem sobie w/w temat. Odszukałem w kartonie ze skarbami właściwą szkatułkę i proszę zobaczyć, co w niej znalazłem!
Nie byłbym sobą, gdybym nie wykorzystał gotowca, żeby ułatwić sobie pracę. Niestety DSM51 nie przewidywał zastosowania innego mikrokontrolera. Ale nic prostszego - zbudowałem przejściówkę. Niech mi ktoś powie, jak nazywa się złącze, które pasuje do podstawki czterdziestopinowej. Przeszukałem za pomocą wujka w okularach internet i nic. Żadnej podpowiedzi. A jednak mam to! Oczywiście nie zawaham się tego użyć.

Na płytce, którą znalazłem w pudełku jest podstawka PLCC68, w której odpoczywa 80535. Teraz proszę zapiąć pasy, będzie jazda! W takiej samej obudowie był produkowany Z180. Nie dość, że znacznie szybszy od Z80, to jeszcze ma na pokładzie prawdziwe DMA! Do tego UART i liczniki (jak CTC). Poza tym może adresować do 1 MB pamięci.
Niezwłocznie poczyniłem zakupy: płytka przejściówka, żeby znowu nie drutować kynarem i procesor. Na początek wersja 6 MHz, bo peryferia w moim staruszku mogłyby nie nadążyć. Na razie czytam dokumentację i nie mogę się nadziwić, że wcześniej na to nie wpadłem.

Okazało się, że płytka z Cyfroniki poniekąd pasuje do podstawki, ale do Gold Pinów już niekoniecznie. Rozstaw otworów 3,96mm... Kto to wymyślił?!?! Znowu przerwa w pracy, bo trzeba zaczekać na złączki. Najzwyczajniej nie chce mi się lutować przewodów, a trochę ich jest...

Quote:

jak nazywa się złącze, które pasuje do podstawki czterdziestopinowej

To wtyk emulacyjny, są różne rozmiary, najłatwiejsze do zdobycia wydaja się DIP24/28/32 bo w takich obudowach występowały popularne pamięci EPROM. Zdjęcia IDC40 z sieci.

Dobry wieczór!

Z180 jeszcze czeka na swoją kolej. Na razie z braku lepszego zajęcia zająłem się konsolą CA80. Mam już rozwiązania umożliwiające symulowanie klawiatury i odczyt wyświetlacza (wszystko bezpośrednio ze złącz ZK i ZW - bez ingerencji w płytę główną), mam też dostęp do internetu, więc nic nie stoi na przeszkodzie, żeby pokusić się o połączenie z CA80 przez WiFi. Na razie klawiatura jest podłączona bezprzewodowo a wyświetlacz przez USB do monitora IDE Arduino. Napisałem procedurę zamieniającą kody siedmiosegmentowe na stringi. Słabo to wygląda, ale można się domyślić... Z klawiaturą wyszedł mały niewypał. Niestety edukację kończyłem w czasach przedinternetowych... O HTMLu owszem, słyszałem... Kilkanaście lat temu mój syn uczył się tego w gimnazjum. Nawet dał mi ściągę i link do Pajączka, ale na tym się skończyło. Przez ostatni tydzień nadrabiałem braki i po chwilowej euforii musiałem zejść na ziemię. Owszem wszystko działa, ale nie wiedziałem, że przesłanie formularza powoduje ponowne wczytanie strony.

Z wyświetlaczem jeszcze sobie nie poradziłem, więc pozostał w Arduino.
Na kłopoty z klawiaturą już znalazłem receptę. Nazywa się Ajax. Znalazłem kilka dobrze opisanych przykładów, ale nie wiem, jak przekazywać dane. Z jednym guzikiem poradziłbym sobie na zasadzie kopiuj - wklej, ale dwadzieścia klawiszy to zbyt dużo. Pozostaje czytać i próbować. Podobną bezsilność pamiętam z pierwszego podejścia do Z80. Kiedy wreszcie wpadłem na to, czego nie mogłem doczytać, zaraz chciałem napisać instrukcję dla takich nowicjuszy jak ja. Niestety kiedy się do tego zabrałem, nie pamiętałem już tego, co było tak ważne. Dzisiejsze poradniki mają tę samą wadę, bo dla autora wszystko jest oczywiste, a czytelnikowi często brakuje jakiegoś drobiazgu, który uniemożliwia zrozumienie tematu...

Szesnaście guzików, można dowolnie wiecej. Proszę usunąć rozszerzenie pliku txt aby został *.html i uruchomić w przeglądarce, szpetne to i na kolanie, ale pod FireFox i Opera działa....

Dobry wieczór!

Nareszcie miałem trochę czasu! Niestety od czasu do czasu trzeba popracować...

Dzisiaj dwie pieczenie na jednym ogniu:
- 1. dokończyłem wirtualną klawiaturę
- 2. połączyłem przejściówkę Z180.



Dwa sukcesy w jeden wieczór! No dobrze, przyznaję się, AJAX zajął mi tydzień, a Z180 jedno popołudnie. Jeszcze dwa tygodnie temu http było dla mnie chińszczyzną. Przypomniał mi się stary dowcip:

- Ile czasu potrzebujesz, żeby nauczyć się chińskiego?
- A kiedy jest egzamin?

Może nie napisałbym porządnej strony internetowej, ale egzamin pewnie bym zdał...

Teraz przede mną wiele pracy z nowym procesorem. Na razie podłączyłem go do synału zegarowego z płytki CA80, tak jak wszystkie pozostałe piny. Na szczęście od razu zadziałał. Ze szczęścia nie mogę się skupić...


W kolejnym kroku chcę wykorzystać UART, później DMA a dalej jeszcze nie wiem. Myślę, że trochę wody w Warcie upłynie, zanim będą jakieś efekty. Dziękuję za pomoc Pani Taszy. Zmotywowała mnie do pracy w chwili zwątpienia. Proszę o informacje, gdyby ktoś wykorzystał chociaż kawałek z moich wypocin. Pozdrawiam wszystkich i do zobaczenia mam nadzieję wkrótce.

Dzień dobry.

Moje prace zatrzymały się na chwilę, ponieważ próbuję opanować sytuację. "Okablowanie" nie byłoby problemem, gdybym prowadził stacjonarny tryb życia... Zabieranie zabawek w podróż wymaga trwalszych konstrukcji, czego dowodem jest awaria wyświetlacza. Pomysł użycia Z180 spowodował, że dużo czasu straciłem na poszukiwanie gotowej płytki. Projektowanie własnej przekracza moje możliwości, a życie mam tylko jedno. Niestety za Wielkim Murem niczego nie znalazłem, na rodzimym portalu też niewiele więcej. Moje doświadczenia z dużą firmą na "A" nie należą do przyjemnych, więc postanowiłem niczego tam nie kupować. Trafiłem na gotowy system, ale 499$ to zbyt dużo za coś mniejszego od CA80! Jest też RC2014. Gotowe moduły do tanich nie należą, ale można kupić puste PCB.

Najciekawszy dla mnie wydaje się: https://www.tindie.com/products/tindiescx/sc111-z180-cpu-module-kit-for-rc2014/

Do tego baza : https://www.tindie.com/products/tindiescx/sc112-modular-backplane-kit-for-rc2014/

Oczywiście kupiłem "gołe" płytki po 6$. Teraz trzeba zrobić przejściówkę do CA80 i przenośny warsztat będzie gotowy. Niestety złącze systemowe nie ma wszystkich sygnałów procesora (np. brakuje adresów A10-A15), więc wtyk emulacyjny bardzo się przyda. Z resztą Z80 i tak musiał opuścić podstawkę, w której tkwił od trzydziestu lat.
Myślałem, że wpinając się w gniazdo Z80, przejmuję kontrolę nad CA80, tak jak to zrobiłem z DSM51. Bardzo się zdziwiłem, kiedy połączyłem ostatnią "pajęczynę". Wszystko jest względne i zależy od punktu widzenia. To CA80 zawładnął nowym procesorem! I tak już zostanie.

Dobry wieczór!

Dzisiaj zmontowałem przejściówkę, którą użyję do połączenia CA80 z systemem RC2014. Przy okazji sprawdziłem działanie kilku przysłów. "Co nagle, to po diable" idealnie pasuje do sytuacji. Zbyt pochopnie zamówiłem płytki i niepotrzebnie się narobiłem.

Dopiero po zakupie pomyślałem, że można użyć np. taką:
https://www.tindie.com/products/tindiescx/sc108-z80-processor-module-kit-for-rc2014/
Wystarczy taśmę na obu końcach okuć wtykami emulacyjnymi i gotowe! "Mądry Polak po szkodzie". Co prawda nie mam drugiego wtyku, ale mogłem go kupić zamiast płytki, którą użyłem. "Nie ma tego złego, co by na dobre nie wyszło" - w czasie poszukiwań wpadłem na lutownicę USB. Jest rewelacyjna. Teraz mogę lutować nawet na ławce w parku (jeszcze nie próbowałem .

Mimo wszystko dokończyłem pracę.

"Wszystko dobre, co się dobrze kończy": pajęczyna działa. Mam nadzieję, że już niedługo zlikwiduję wszystkie zbędne kabelki i zajmę się UARTem.
Teraz czekam niecierpliwie na przesyłki. Łańcuch dostaw na jedwabnym szlaku jest nieprzewidywalny, a Królewskiej Poczty jeszcze nie testowałem. Mam nadzieję, że jest szybsza...

Dzień dobry.
Tym razem poczta była szybsza ode mnie. Tak jak w ofercie 5 dni roboczych. Zanim wróciłem do domu czekały już dwie i kilka z innych stron świata. Niestety zbyt szybko chciałem zobaczyć CA bez sterty kabli... Jak nowicjusz przylutowałem zasilanie: czerwony "+", niebieski "-" i stało się. Chciałem wykorzystać przewód USB z odzysku i okazało się, że montował go daltonista, albo złośliwiec. CA padł. Próby reanimacji (wymiana procesora, RAMu, EPROMu, 8255) nic nie dały. Na szczęście mam jeszcze rezerwy. Na pierwszy ogień poszła płytka bez CTC. Złącze systemowe jeszcze bez śladu cyny. Brakowało tylko 7442. Po zlutowaniu i połączeniu z MIK-191 z pechowca, na wyświetlaczu pokazał się znajomy komunikat. Niestety zarwanej nocy i przedpołudnia nie da się odzyskać. Uszkodzoną MIK-90 też będzie trzeba kiedyś naprawić... Sprawdziłem scalaki: EPROM przeżył, procesor i 8255 (oba NEC - tworzyły parę) niestety nie. RAMu nie mam gdzie włożyć bo nowa - stara płytka ma wlutowany, a pozostałe miejsca (U10 i U11) nie mają podstawek. Na szczęście wyświetlacz nie ucierpiał.
Niezwłocznie przystąpiłem do montażu przejściówki. Działa!!!

Jak już wcześniej pisałem, CA80 przejął kontrolę nad nowym procesorem. Proszę przyjrzeć się zdjęciom - na płytkach RC2014 nie ma żadnych elementów oprócz procesora i podstawki w którą jest wpięty wtyk emulacyjny (kondensatorów odsprzęgających nie liczę). Procesor jest taktowany zegarem z CA. To była jedyna niezbędna przeróbka płytki SC111. Z180 może sterować układami zewnętrznymi sygnałem z wyjścia PHI, na którym jest zegar o dwa razy mniejszej częstotliwości od wewnętrznego. Wystarczyło przeciąć ścieżkę i dolutować kawałek przewodu.

Pan Stephen się napracował, a barbarzyńca używa efekt jego pracy zamiast zwykłej podstawki...
Nadal nie zająłem się UARTem... Niestety muszę odpocząć.

Dobry wieczór.

Na razie studiuję dokumentację Z180, chociaż temperatura otoczenia nie sprzyja pracy. Okazuje się, że jest kilka wersji różniących się nie tylko częstotliwością taktowania. Dotychczas nie zastanawiałem się nad tym, dlaczego ktoś użył kwarc o jakiejś wartości, chociaż nieraz się dziwiłem. Np. w DSM51 zastosowano 11,0592 MHz. W RC2014 natomiast często występuje 7,3728 MHz (dla Z80) i 18,432 MHz (Z180). Dlaczego nie maksymalna częstotliwość np. procesora? (lub jej krotność jak w CA80: 8 MHz dla Z80A albo 5 MHz dla Z80). Wytłumaczenie jest bardzo proste - ułatwia uzyskanie standardowych szybkości transmisji UART bez dodatkowego źródła sygnału taktującego. UART w Z80180 (mam dwa egzemplarze: 6 i 10 MHz) działa podobnie do Z80 SIO. Można użyć zegar procesora i odpowiednio dobrać dzielniki w SIO. Niestety z 4 MHz nie można uzyskać żadnej standardowej szybkości transmisji... Pozostaje zbudować dodatkowy generator np. 7,3728 MHz.

Jest jeszcze inne wyjście. Z8S180. Na początku moich poszukiwań nie mogłem znaleźć procesorów szybszych niż 10 MHz. Dopiero niedawno zwróciłem uwagę na literę "S" zamiast zera w pełnej nazwie MPU. Właśnie ta wersja ma 20 i 33 MHz. Znalazłem też "eskę" z zegarem 10 MHz i niezwłocznie ją zamówiłem. Cena szybszych mnie powstrzymała... Co takiego ma Z8S, że wydałem kolejne 3$? Nie znam wszystkich różnic, ale jedna jest w tej chwili ważna: BRG (baud rate generator). Jest to dodatkowy szesnastobitowy rejestr, do którego wpisuje się stałą przez którą dzielony jest PHI (sygnał zegara wychodzący z procesora). Dzięki temu można z 4 MHz uzyskać 9600 bodów (z bardzo małym błędem).

Teraz czekam na przesyłki. Jeżeli najpierw dotrze kwarc - zbuduję generator, a jeśli procesor - włożę go do podstawki zamiast poprzedniego.
Programowanie UARTu czy ASCI, jak go nazywa Zilog, wydaje się znacznie mniej skomplikowane niż Z80 SIO, ponieważ mamy bezpośredni dostęp do wszystkich rejestrów I/O znajdujących się w MPU. Nie musimy wysyłać numeru rejestru, który chcemy zapisać lub odczytać.

Dobry wieczór.

Ostatnio słabo mi idzie... Ciągle zajmuję się tematami zastępczymi: naprawiam to, co chwilę wcześniej zepsułem, albo zmieniam koncepcję i czekam na nowe części. Koniec z tym! Zamiast czekać na kwarc, można go poszukać w złomie.

Zamiast budować generator (odłożyłem to na potem), można spróbować transmisji na dowolnej częstotliwości - byle nadajnik i odbiornik miał taką samą.

Drugi zestaw RC2014 już prawie gotowy. Uszkodzona płytka CA80 prawdopodobnie ruszy. Zapomniałem, że w systemie był jeszcze CTC i najpewniej (jeszcze nie sprawdziłem) on też padł. Wszystkie NMOSy nie wytrzymały odwrotnego napięcia zasilającego. Za to generator i dzielnik częstotliwości przeżyły. Przydałby się oscyloskop, ale niestety nie posiadam. Znalazłem urządzenie zastępcze za kilka dolarów. https://www.instructables.com/id/Open-Your-Eyes-Logical-Analyzer/

Działa znakomicie. Przy okazji bardzo się zdziwiłem, bo okazało się, że zastępcza płytka CA80 pracuje z CLK = 2MHz. Dlaczego? Nie pamiętam, a sam to przerabiałem. Może radzieckie KP580BB55A nie chciały współpracować? Muszę to jeszcze przywrócić do porządku. Za tydzień będą dwa systemy CA80 z procesorami Z180 i nie będzie żadnej wymówki!

Jak widać NMI jest takie samo, a CLK nie. Znalazłem kolejny temat zastępczy!

Dzień dobry.
Ilekolwiek wolnego czasu byśmy nie mieli, zawsze przydałoby się więcej... Znowu się nie wyrobiłem, choć jak zwykle zmieniłem plany. Postanowiłem wysłać cokolwiek przez port szeregowy. Dostatecznie długo się do tego przygotowywałem, więc oczekiwałem szybkiego sukcesu. Ponieważ Tniasm nie jest zbyt wygodny w użyciu, a Pani Tasza poleca Sbasm, zdecydowałem się na zmianę.
http://bienata.waw.pl/ca8011.php

Uporałem się z zawiłościami tematu (potrzebny był też Python) i zaraz wziąłem się do pracy. Dla wprawy zacząłem od definicji wewnętrznych rejestrów Z180.
Nadszedł czas na program. Napisałem coś i po kilku próbach udało mi się skompilować. Przykłady Pani Taszy bardzo się przydały. Plik CA80.inc również. Żeby coś działo się na wyświetlaczu, wstawiłem wyświetlanie adresu kolejnego bajta do wysłania (HL) i licznik wysłanych (B).
Niestety po wpisaniu kodu do CA na wyświetlaczu zatrzymał się adres drugiego znaku i FF na pozycji licznika... Zapomniałem, że rozkazy IN i OUT wystawiają szesnastobitowy adres! Nie jest to żadna nowość, Z80 zawsze tak działał, ale do tej pory mi to nie przeszkadzało. Rejestry wewnętrzne Z180 są podpięte do pełnego adresu i trzeba jakoś jego starszy bajt wyzerować... Coś mi się przewinęło przed oczami o nowych rozkazach Z180, ale nie skupiłem na tym uwagi. Znalazłem! Do adresowania rejestrów wewnętrznych stworzono nowe rozkazy. Już chciałem pisać makra, żeby jakoś wstawić je do programu, ale na szczęście się powstrzymałem. Sbasm jest wieloprocesorowym narzędziem i wystarczy jedna zmiana .cr Z80 na .cr Z180. Szybko skompilowałem, trochę wolniej wklepałem... (a miałem zrobić wpisywanie z karty SD). Coś drgnęło. Na "oscyloskopie" pojawiły się jakieś przebiegi. Nawet udało się zdekodować wysłany bajt. Bit startu, jedynka i siedem zer...


Tylko raz na jakiś czas. Co siedem sekund Tx wyrzucał jeden bajt. Akurat tyle trwała pętla wysyłająca 256 bajtów, więc pewnie pierwszy przebieg był prawidłowy, a w następnych coś było nie tak... Zmieniłem wyświetlanie rejestru B na C (mała zmiana bez użycia kompilatora) i od razu się wydało: w C zamiast "06" było "0C". Wszystkie dane leciały w kosmos, bo zachciało mi się ozdobników: LADR i LBYTE zmieniają zawartość rejestru C. Już wcześniej przeczytałem, że OTIM (odpowiednik OUTI) inkrementuje C, więc po każdym wysłaniu trzeba dekrementować, żeby adres się nie zmienił. Nad rejestrem C wisi chyba fatum. A może trzeba bardziej uważać na to, co się robi?

Dobry wieczór!

Wklepałem poprawiony program.

Zmieniłem szybkość transmisji na maksimum i call LADR zastąpiłem NOPami.

Widać, że na 2Mhz za wiele się nie da, więc wyrzuciłem wszystko od PUSH BC do POP BC (NOPy).

Na razie nie potrafię oszacować prędkości transmisji, ale i tak jest sukces.
Dobranoc! xD

Dodano po 14 [minuty]:

P.S. Rzeczywiście OTIM inkrementuje C. Po co i dlaczego? Może inaczej się nie dało zaprojektować...

Dobry wieczór!

Nadszedł czas kończenia odłożonych na później tematów. Wcześniej nie wiedziałem, jaki format będą miały dane, które prześlę do CA80 za pomocą karty SD. Asembler TniAsm, który wcześniej używałem, nie tworzył plików *.hex (albo nie umiałem tego zrobić), a plik *.bin jest trudniejszy do obróbki. Sbasm ma wszystko, czego potrzebowałem, więc nie ma już wymówki.

Napisałem uproszczony translator pliku *.hex na kody klawiszy CA80. Nie sprawdza on sumy kontrolnej, ani rekordu końcowego, ale poprawnie wyciąga z pliku adresy i wartości bajtów, które należy zapisać. Oczywiście dodaje kody niezbędnych klawiszy (zlecenie *D CA80). Zamieszczam kod programu testowego Arduino, który należy połączyć z którąś z wcześniejszych wersji CA80_internetClock (jeszcze tego nie zrobiłem) i "odkomentować" linie powiązane z tym kodem. W programie testowym brakuje deklaracji zmiennych, tablicy kodów klawiszy i niektórych funkcji.

Program wysyła przez port szeregowy najpierw zawartość pliku CA80.HEX, który należy zapisać na karcie SD. Potem otwiera plik ponownie i wysyła zmodyfikowany kod tak, jak będzie to robił poprzez złącze ZK CA80. Można porównać wynik pracy programu z zawartością pliku. Wszystko się zgadza, więc ostateczna wersja pojawi się wkrótce (mam nadzieję).

Teraz pisanie programów na CA80 będzie szybsze i w czasie "wklepywania" można będzie wypić np. herbatę.

Dobry wieczór!

Czytnik SD zrobiony. Działa znakomicie. Napisałem (okroiłem stary) nowy program do obsługi tego ustrojstwa bez ustawiania czasu i wirtualnej klawiatury. Można użyć dowolnego Arduino (czas kompilacji dla ESP jest zdecydowanie zbyt długi).

Zrobiłem też porządek: żadnych wiszących na kablach płytek! Wszystko (prawie) przykręcone i solidnie się trzyma. RC2014 nie chciał w żaden sposób zmieścić się pod CA, więc przeciąłem płytkę bazową. Na stałe w systemie potrzebne są dwa sloty: Z80 i Z180. Trzecie złącze umożliwia podłączenie płyty bazowej (całej albo pozostałości z przeciętej), co daje nowe możliwości: ułatwia diagnostykę i ewentualną rozbudowę. CA ma coraz dłuższe nogi!!

Prztestowałem Z8S180. BRG (baud rate generator) znacznie ułatwia użycie UARTów. Nie trzeba budować dodatkowego generatora, ani zmieniać CLK w CA80 (popsułoby to obsługę zegara!). Wszystkie szybkości transmisji da się uzyskać z 4 MHz. Program niewiele się zmienił, tylko kilka rozkazów w celu ustawienia parametrów transmisji. No i nareszcie mam CLK = 4 MHz! Na początku program wysyłał jeden znak i zatrzymywał się... Okazało się, że procesory różnią się między sobą. Poprzedni hulał bez końca, a nowy musi mieć CTS podpięte do masy. Skoro musiałem wyjąć płytkę, wlutowałem w nią wszystko, co może się przydać.

Przygotowałem tabelę wartości dla BRG. Przy 4 MHz musimy zaokrąglać więc będzie mały błąd (bardzo mały). Dla porównania wyliczenia dla 4.608 MHz (z noty Ziloga) są całkowite, więc idealne.
Myślałem, że szybkość transmisji wylicza się przy pomocy jakiegoś magicznego wzoru, a okazało się, że jest to bardzo proste, wręcz banalne. Jeżeli weźmiemy dwa sąsiednie bity, to mieszczą się one w jednym cyklu (na oscylogramie np. 150 Hz), podwajamy częstotliwość i mamy szybkość w bodach.

Potrafię już wysłać coś przez UART, ale na razie na tym koniec. Trzeba jeszcze jakoś to odebrać. Znowu się zatrzymałem.

Dobry wieczór!

Wczoraj jeszcze nie wiedziałem, jak przesłać dane do komputera. Nie mam żadnego programu terminala. Kiedy próbowałem znaleźć coś w sieci, nagle mnie olśniło. Przecież mam Arduino! Szybko przerobiłem przykład SoftwareSerial i napisałem coś dla CA80. Oczywiście będziemy transmitować dokładny czas.

Wszystkie zabawki działają, więc debugowanie poszło sprawnie. Wpisywanie kodu do pamięci jest tak szybkie, że i tak nie zdążę w tym czasie niczego zrobić. Na razie tylko wysyłam, bo w drugą stronę coś nie poszło po mojej myśli. A może raczej moje myśli nie poszły właściwą drogą.

Ogłaszam kolejny sukces!

Dobry wieczór!

Znalazłem powód braku komunikacji. Jak zwykle drobne niedopatrzenie. W czasie ustalania parametrów transmisji należy ustawić szósty bit (Receiver Enable) w rejestrze CNTLA0.
ld A,%01100100 ; parametry transmisji: 8 bitów danych, 1 bit stop, bez parzystości
out0 (CNTLA0),A ; b6 - Receiver Enable, b5 - Transmitter Enable
Niestety transmisja nadal kuleje... CA80 odczytuje znaki poprawnie, to znaczy reaguje tylko na 'G', 'g', 'D' i 'd', jednak monitor odbiera jakieś krzaczki. Z8S180 ma wewnętrzny bufor, więc można wysłać więcej znaków na raz. Zwykle drugi pakiet jest już prawidłowy, a trzeci zawsze. Wysyłanie większej liczby znaków nic nie daje - bufor jest za krótki. Nie zbadałem jeszcze przyczyny takiego zachowania, ale przypuszczam, że CA80 jest OK. Myślę, że SoftwareSerial nie łapie synchronizacji i pierwsze bajty odczytuje źle. Dołożyłem na początek każdej paczki kilka spacji i była poprawa. Zwiększenie szybkości transmisji na 600 bodów nic nie zmieniło.

Na dzisiaj koniec - obowiązki wzywają.

Dobranoc.

Dobry wieczór!

Dawno mnie tu nie było... W końcu są wakacje!

Niewiele zrobiłem, ale jest postęp. Tak jak podejrzewałem, SoftwareSerial nie radził sobie z synchronizacją. Ponieważ nie umiem pisać programów dla PC-ta (analfabetyzm wtórny), zastosowałem nową przejściówkę - Arduino Mega, w którym aż roi się od UART-ów. Przerobiłem program dla Arduino i od razu zadziałał. Zwiększyłem szybkość transmisji na 9600 i usunąłem "rozruchowe" spacje i nadal działa.
Następny krok to będzie prawdopodobnie transmisja danych z SD przez UART do ramu CA80. Już się nie mogę doczekać efektów.

Do zobaczenia wkrótce!

Dobry wieczór.

Znowu coś zrobiłem, ale tym razem coś pożytecznego! Ostatnio mój CA80 zaczął szwankować - co jakiś czas się zawieszał. Nie było to zbyt częste, ale należało znaleźć przyczynę. Zacząłem od EPROM-u. W końcu leżał 30 lat z niezaklejonym okienkiem. Znalazłem inny (jeszcze starszy) i po wymianie wszystko wróciło do normy, jednak monitor miał tylko 2 kilobajty...
Postanowiłem zaprogramować nowy EPROM, ale programator od lat nieużywany i nawet nie ma do czego go podłączyć. Nie chciało mi się uruchamiać drugiego CA80 (uszkodzonego przeze mnie w czasie wcześniejszych eksperymentów), więc znalazłem EEPROM. I tak musiałem włączyć lutownicę, bo potrzebne były podstawki U10 i U11. Przy okazji dolutowałem A13 do 26 nogi U11 (żeby było 16 kilobajtów). KM28C64 ma tylko 8 kB, ale 27128 - 16.
Napisałem szybko programik do kopiowania (w nocie katalogowej piszą, że można zapisywać jak zwykły RAM, tylko zapis trwa do 5 us). Wszystko się udało i CA dostał nową kość.


Radość skończyła się już po pierwszym wyłączeniu. System nijak nie chciał wstać. Wróciłem do starego EPROM-u. Okazało się, że pierwszy bajt się wyzerował...

Przeczytałem notę do końca. Trzeba jeszcze zabezpieczyć zawartość przed zapisem...
Skoro już się zabrałem do tej pracy, postanowiłem wykonać ją solidnie. Napisałem nowy program, który zapisuje bloki po 64 bajty na raz. Dopisałem procedury zabezpieczającą przed zapisem i zdejmującą to zabezpieczenie. Nie zrobiłem żadnego interfejsu użytkownika, bo dzień jest za krótki. Na początku umieściłem skoki do procedur, żeby nie szukać adresów: C000 - blokada zapisu, C003 - zdjęcie blokady, C006 kopiowanie U11 do U10.

Uzbierało się 120 bajtów. Gdyby nie czytnik SD nie zdążyłbym dzisiaj dokończyć tematu!

Zajrzałem do noty KM28C256 i wszystko wygląda tak samo. Różnice są tylko w adresach kluczy blokujących. Można użyć tych kości w CA80 jako 16 kilobajtowych, bo A14 jest na pierwszej nodze, a ta jest na stałe podpięta do +5v. Czyli wykorzystamy górną połówkę, co planuję zrobić w przyszłości, żeby wreszcie na stałe wpisać coś swojego.

Dzień dobry!
Niedawno uruchomiłem mój najstarszy egzemplarz CA80. Zrobiony z najtańszych możliwych do zdobycia w sezonie 1985/1986. Płyta główna nie ma nadruku, więc jest albo z partii próbnej albo z odpadów. Pozostałe płytki rysowałem ręcznie. Pamiętam moje zdziwienie, kiedy na wyświetlaczu zobaczyłem CA80. Spodziewałem się SA80, bo taki komputer chciałem zbudować. Znałem go ze szkoły. Mój nauczyciel też miał taki i to on pomagał mi skompletować wszystko, a potem uruchomić. Zrobił pewnie 90% a reszta to mój udział.

To co pozostało z pierwszej wersji nadaje się może do roli eksponatu w muzeum. Klawiatura to najsłabsza część. Była wielokrotnie naprawiana i wymieniana, bo w szkolnych czasach bardzo dużo przeszła. Kalkulatory nie były projektowane do tak intensywnego użytku. Nie dość, że program wpisywało się ręcznie po każdym wyłączeniu (kto wtedy miał magnetofon?), to najczęściej były to gry zręcznościowe.

Drugim słabym ogniwem jest wyświetlacz - bardzo słabo świeci, do tego jest mały.
Wyświetlacz już wymyśliłem wcześniej i na pewno go użyję, nadal pozostaje klawiatura. Nie chce mi się projektować nowej, bo zbyt wiele musiałbym się nauczyć. Kiedy idę połupać drewno do kominka (polecam jako świetne ćwiczenia ogólnorozwojowe), nie zaczynam od projektowania siekiery, bo ktoś już dawno to zrobił za mnie. Jak zwykle zacząłem od poszukiwania czegoś gotowego. Niestety większość tanich gotowców ma mało klawiszy. LED&KEY (płytka, którą użyłem jako zastępczy wyświetlacz) ma tylko osiem, chociaż TM1638 może obsługiwać matrycę 3x8. Znalazłem nawet taką wersję.

Niestety jest nie do kupienia. Wymyśliłem sposób. Można użyć dwie matryce 4x4. Kiedy je odpowiednio połączymy i użyjemy tylko po trzy kolumny, uzyskamy 3x8. Taką matrycę można podłączyć bezpośrednio do CA80. W MIK05 jest rozdział o podłączaniu niestandardowej klawiatury. Pan Gardynik zaszalał i zaprojektował klawiaturę 3x10, ale wcale nie jest tyle potrzebne. Poza tym prościej byłoby emulować mniejszą klawiaturę na przykład multiplekserem ośmiowejściowym. Życie byłoby prostsze Nadal można to zrobić. Wystarczy przypisać inne kody do klawiszy, tak by zmieściły się na matrycy 3x8. Nie polecam takiego rozwiązania, bo musielibyśmy przeprogramować EPROM z monitorem. Nasz CA80 stałby się niekompatybilny z oryginalnymi klawiaturami. W życiu niczego nie można być pewnym. Może uda się zdobyć jakiś oryginał. Może spotkamy kogoś, kto też ma CA80 i będzie potrzebował sprawnego egzemplarza, żeby coś sprawdzić...
Co w takim razie począć? Wspomniany TM1638 może rozwiązać problem. Wystarczy dolutować dwa przewody bezpośrednio do układu scalonego, bo nie są używane. Da się!

teraz szybki program na Arduino i gotowe. Niestety nadal pozostaje zaprojektowanie jakiejś płyty czołowej z opisami klawiszy, chociaż z doświadczenia wiem, że da się żyć bez tego. Przecież kiedy piszemy coś szybko, nie patrzymy na klawisze.

Połączyłem całość. Poprawiłem kod. Działa. Wyjąłem z płytki ESP z czytnikiem SD i zamiast niego wpiąłem SCL i SDA z Arduino. Niestety TM1638 nie jest I2C... ESP ma za mało pinów, żeby wszystko działało, więc chwilowo jest bezrobotny.



Przepraszam za jakość filmów... pierwszy słaby, drugi obrócony. Niestety mam słaby sygnał WiFi i nie mogę tego teraz poprawić.

Dobranoc.

Dzień dobry.

Od jakiegoś czasu myślę o obsłudze magnetofonu w CA80. Prawie pół kilobajta zapomnianego, nikomu niepotrzebnego kodu i trzy a nawet cztery polecenia systemowe do wykorzystania. Jednak szkoda trochę pracy pana Gardynika, bo włożył w to kawałek swego życia. Może warto się jeszcze raz zastanowić...?
Poczytałem, przemyślałem i podjąłem decyzję: kod pozostaje bez zmian, ale zacznie być potrzebny, wręcz niezbędny do dalszej pracy.
Co można zrobić? Najprościej będzie wyrzucić zbędny układ wzmacniacza sygnału z magnetofonu i modulator sygnału zapisu na magnetofon, czyli de facto nic, bo po prostu układy te nie były zmontowane. UCY74123 jest, bo generuje sygnał brzęczyka, więc odcinamy tylko go od PA7, które połączymy bezpośrednio z ZA4, a PC4 połączymy z ZA3. W ten sposób na złączu mamy sygnały cyfrowe, które łatwo można wykorzystać.

Jak widać na powyższym obrazku, sygnał jest niesymetryczny - zero znacznie dłuższe od jedynki (nie mówię o dwóch bitach stopu, ale o połówce normalnego bitu). Zgodnie z opisem w MIK05 jedynka tworzona jest przez czas siedemnastu z dwudziestu próbek przypadających na pół bitu. Dlatego następne zero trwa dwadzieścia trzy próbki. "Doświadczalnie stwierdzono..." często możemy przeczytać w serii MIK. Pozostałe trzy próbki są uzupełniane w czasie odczytu przez 74123, który właśnie został wyrzucony. Nie jest to żaden problem, po prostu sygnał który podamy na wejście będzie symetryczny i już. Nawet łatwiej taki wygenerować.

Wystarczy użyć cokolwiek, co ma jakiś timer generujący przerwania. Pod ręką było Arduino, więc szybki programik i już działa. Najtrudniej było z sumą kontrolną, bo CA80 wyrzucał "Err". Ale analiza sygnału od końca dała rozwiązanie. Szybciej bym je znalazł, gdybym poczytał o rozkazie CPL...

Mam już generator rekordu EOF, pozostało dopisać kilka procedur do tworzenia rekordu danych i gotowe. Program do wklepywania plików HEX już dawno napisałem. Trzeba tylko połączyć go z nowym i stworzyć jakiś system plików.
Planuję dopisać program odczytu danych z CA80, który sam określi stałą czasową dla timera. Sterowanie całym urządzeniem można zrobić za pomocą zapisu rekordu EOF. CA wysyła ten rekord, Arduino najpierw określa szybkość transmisji, potem odczytuje nazwę pliku np. "AA", a następnie odczytuje plik o wybranej nazwie z SD i wysyła go na złącze magnetofonowe. Można jeszcze utworzyć dodatkowy plik tekstowy z długością danych i adresem wejścia do programu. Wtedy moglibyśmy utworzyć rekord EOF i nie musielibyśmy tworzyć rekordów danych szesnastobajtowych, ale dłuższe (do 255 bajtów), co znacznie skróciłoby czas transmisji (każdy rekord ma 32 bajty startowe, co przy standardowej szybkości trwa ok. 2 sekundy).

Zostało jeszcze trochę do zrobienia, ale już dziś się chwalę, bo nie wiadomo kiedy dokończę całość. Ale obiecuję, że się postaram. Chyba że ktoś ma lepszy pomysł...

P.S. Dzisiaj filmów nie będzie. Przepraszam.

Dodano po 13 [minuty]:

Zapomniałem dodać program...

Nie byłbym sobą, gdybym nowej zabawki nie użył do ustawienia czasu w CA80!
Trochę mi to zajęło, ale działa.