[CA80] [Z80-MBC2] Oprogramowanie (ROM - Monitor).

[Zegar]

Dobry wieczór!
Przyzwyczailiśmy się, że wszelkie oprogramowanie pobieramy z sieci i instalujemy tam gdzie trzeba bez wychodzenia z domu. Jednak nie zawsze tak było, a w niektórych przypadkach nadal potrzeba więcej zachodu. Załóżmy że kolega @Phill2k dokończył projekt płytki CA80. https://microgeek.eu/viewtopic.php?f=82&t=2227&p=13643#p13643 Z niecierpliwością na to czekaliśmy, zgromadziliśmy wszystkie elementy i wreszcie możemy wszystko zmontować. Kiedy późnym wieczorem w sobotę kończymy pracę i chcemy włączyć zasilanie, okazuje się, że zapomnieliśmy o czymś bardzo ważnym! Nie mamy monitora w EPROMIE!!! Ale od czego jest internet? Pobieramy z jakiegoś źródła plik *.bin ... i nie mamy jak wcisnąć go do kości. O tej porze nie chcemy nikogo niepokoić, a z wrażenia nie chce nam się spać, więc nie czekamy do rana tylko budujemy programator.

EEPROM jest łatwiejszy do zaprogramowania (prawie jak RAM), ale nie mamy żadnego urządzenia z podstawką, do której pasowałby nasz KM28C64. Pamięci mają bardzo zbliżony układ pinów, więc możemy spróbować w MBC2 (mamy go również od w/w kolegi). Niestety podstawka RAMu jest większa i kilka sygnałów się nie zgadza.

Po krótkiej analizie robimy przejściówkę.

Schemat_przejsciowki.png

Pierwsze_proby.jpg

Przerabiamy kod rozruchowy dla Atmegi, kopiujemy do niego zawartość pliku *.bin (oczywiście najpierw przetwarzamy na postać 0xXX np. programem HxD - również znalezionym w sieci).

Włączamy maszynę i programujemy... Nie wiemy jak szybkie są funkcje zmuszające Z80 do pracy, więc wybieramy metodę "single byte write". Po ok. minucie mamy gotową kość!

Oczywiście to historyjka, wymyślona dla uzasadnienia mojej nikomu niepotrzebnej pracy. W rzeczywistości mam działający CA80, więc zaprogramowanie EEPROMU to żaden problem, ale chciałem czegoś się nauczyć i zrobiłem sobie "pod górkę". Włożyłem kość do CA i porównałem zawartość z moim monitorem. Niestety nie wszystkie bajty się udały. Robiłem różne modyfikacje zarówno sprzętowe jak i programowe. Dopiero po dwóch dniach orki (od rana do nocy) udało się. Wszystkie bajty na swoim miejscu. I to nie przypadek. Powtórzyłem na drugim egzemplarzu i również sukces.

Pierwsza_wersja_przejsciowki.jpg

Ale dlaczego się nie cieszę? Niestety CA nie chce wystartować na tych pamięciach... Dlaczego? W czasie kolejnych prób nauczyłem się kolejnych bajtów prawie na pamięć: 3E, 90, D3, F3... Liczby jak liczby. Jednak coś tu nie gra. Wszyscy pasjonaci MIK-ów na pewno pamiętają zasady dobrego programowania. Jedna z nich mówi, że dobrze napisany program zaczyna się od ustawienia stosu. Dlaczego? Ponieważ stos jest potrzebny, żeby program mógł wrócić z podprogramu. Nie wywołujemy na razie żadnego więc to nie ma znaczenia... Czy aby na pewno? Tę elementarną zasadę złamał nasz guru i największy autorytet - Pan Gardynik. Nikt nie jest doskonały...

Cóż zatem złego się dzieje? Pewności nie mam, ale poczytałem trochę i nasuwa się trop przerwań. Nie wiemy kiedy procesor dostanie pierwsze zgłoszenie NMI. Nie mam oscyloskopu ani innego sprzętu, żeby to sprawdzić, ale trop jest chyba właściwy. Po resecie procesor ma PC=0000 - to wiemy na pewno. Wskaźnik stosu podobno FFFF, jednak bardziej prawdopodobne jest 0000, ponieważ czasem udawało się uruchomić CA00 na EEPROMIE. Jednak kolejna próba już się nie udawała. Jeżeli udało się ruszyć, tylko pierwszy bajt zmieniał wartość z 3E na 00. W przypadku niepowodzenia - EEPROM mógłby być żródłem liczb pseudolosowych...

Procesor zawsze wykonuje pierwszą instrukcję i dopiero po jej zakończeniu może obsłużyć zgłoszone przerwanie - tak został zaprojektowany i dlatego pierwszą instrukcją musi (MUSI!!!) być LD SP,nn.

Ale dosyć narzekania! Gdyby Pan Stanisław nie doprowadził do U9 sygnału /WR (pin 27), problem prawdopodobnie by nie wystąpił, co nie zmienia faktu, że CA80 zanim ruszy we właściwym kierunku, trochę błądzi. Pewnie dlatego po włączeniu czasem wyświetla się "errCA80", a innym razem wyświetlacz pokazuje coś dopiero po kilku sekundach. Jakie jest wyjście z sytuacji? Można zabezpieczyć pamięć przed zapisem. Dopisałem odpowiednie funkcje, jednak nie działają... Do ich wykonania niezbędne jest przestrzeganie czasu zapisu. Musimy zmieścić się w 0.15 ms. Procedury generujące sygnał CLK używają arduinowych "digitalWrite", które przy 16 MHz trwają ponad 3 us. Nie liczyłem wszystkich, ale każdy rozkaz LD (HL),n ma 10 taktów (20 digitalWrite'ów), a to nie wszyskie rozkazy, więc prawdopodobnie za długo. Spróbuję to zmienić na bezpośredni zapis do rejestru, ale nie dzisiaj.

Efekt_koncowy.jpg

P.S. Mam nadzieję, że autor Z80-MBC2 (J4F) nie obrazi się, że sprofanowałem jego kod. W końcu rozwinięcie jego nicka to Just_for_fun, a zapewniam, że rozpracowałem jego program dla zabawy.

MBC2_CA80_MONITOR_LOADER.zip

[tasza]

Proponuje wykorzystać układy AT28C64B dokumentacja poniżej:
http://ww1.microchip.com/downloads/en/D ... oc0270.pdf
Mają programowe zabezpieczenie przez zamazaniem zawartości, właśnie na takie okazje. Upycham te kostki do wszelkich (główne starych) CA80, które uruchamiam ludziom i póki co nie było wypadku.

[Zegar]

Dobry wieczór!
Wiem, wiem... Mój CA też na takiej śmiga. Opisałem powód, który nie pozwolił mi tego zrobić. Wiem nawet jak go ominąć, ale dzisiaj już mi się nie chce. Poza tym żona mówi, że żyję w innym świecie (matrixie ), więc muszę zrobić coś normalnego, np. przynieść drewno do kominka...

P.S. Tutaj jest moja praca na CA80 o KM28C64: https://www.elektroda.pl/rtvforum/viewtopic.php?p=18097567#18097567

P.S.2 Nie doczytałem literki "B"... Akurat takich nie mam, jednak moje też mają zabezpieczenie programowe. Procedury SDP umieściłem w załączonym kodzie, jednak nie działają prawdopodobnie z powodu zbyt długiego ich wykonywania. Kod zabezpieczający i odbezpieczający musi być zapisany w trybie Page Write (czy coś w tym rodzaju - piszę z pamięci), a do tego konieczne jest spełnienie warunku t_blc<150us. Żeby się zmieścić trzeba pisać bezpośrednio do rejestrów zamiast arduinowego digitalWrite(). Chciałem wszystko zrobić na jednej maszynie, ale na razie się nie udało, co nie zmienia faktu, że sposób wykorzystania Z80 mnie zafascynował.

[Zegar]

Zmodyfikowałem niezbędne fragmenty kodu i EEPROM jest zabezpieczony przed zapisem. Pozostawiłem programowanie w trybie Single Byte Write, bo już mi się nie chciało... Mam nowy temat do przemyślenia.

Kod: Zaznacz cały

// ------------------------------------------------------------------------------

// Z80 bootstrap routines

// ------------------------------------------------------------------------------

#define CLK_HIGH    PORTD |= B10000000
#define CLK_LOW     PORTD &= B01111111
#define RAM_CE_HIGH PORTB |= B00000100
#define RAM_CE_LOW  PORTB &= B10111011

void pulseClock(byte numPulse)
// Generate <numPulse> clock pulses on the Z80 clock pin.
// The steady clock level is LOW, e.g. one clock pulse is a 0-1-0 transition
{
  byte    i;
  for (i = 0; i < numPulse; i++)
    // Generate one clock pulse
  {
    // Send one impulse (0-1-0) on the CLK output
    CLK_HIGH;         //Bylo: digitalWrite(CLK, HIGH);   
    CLK_LOW;          //      digitalWrite(CLK, LOW);
  }
}

// ------------------------------------------------------------------------------

void memoryWrite() //zapis do EEPROM
// Generate 3 clock pulses on the Z80 clock pin.
// The steady clock level is LOW, e.g. one clock pulse is a 0-1-0 transition
{ 
    // Generate 3 clock pulses and enable EEPROM to write
 
    // Send one impulse (0-1-0) on the CLK output
    pulseClock(2);
    RAM_CE_LOW;   //digitalWrite(RAM_CE2, !HIGH);        // Enable the RAM (CE2 = HIGH)
    RAM_CE_HIGH;  //digitalWrite(RAM_CE2, !LOW);        // Disable the RAM (CE2 = LOW)
    pulseClock(1);
}

// ------------------------------------------------------------------------------


MBC2_CA80_MONITOR_LOADER_SDP.zip

Programator.png

[Zegar]

Proponuje wykorzystać układy AT28C64B dokumentacja poniżej:
http://ww1.microchip.com/downloads/en/D ... oc0270.pdf
Mają programowe zabezpieczenie przez zamazaniem zawartości, właśnie na takie okazje. Upycham te kostki do wszelkich (główne starych) CA80, które uruchamiam ludziom i póki co nie było wypadku.

Trochę czasu minęło zanim sprawdziłem proponowane układy. Skończyły mi się te z literką "A", więc kupiłem z "B". Nie chciało mi się rozkręcać obudowy CA80, żeby użyć go jako programatora... Wyciągnąłem z szuflady przerobiony Z80-MBC2. Niestety programowanie udało się połowicznie. Dosłownie! Został zaprogramowany co drugi bajt. Powtórzyłem na innym egzemplarzu i niestety z takim samym skutkiem. Już chciałem sprawdzać połączenia, bo to w końcu prowizorka, ale zajrzałem do dokumentacji. Okazało się, że kluczowa jest zaznaczona przez @Taszę na żółto litera. Niestety to nie Z80, w którym "B" oznacza, że egzemplarz jest lepszy od tego z "A" (6 MHz vs 4 MHz). Tutaj litera "B" oznacza 10 ms, a "A" 5 ms. Jednak tym razem "less is more". Parametr ten to czas zapisu dotyczący zarówno zapisu blokowego jak i pojedynczych bajtów, a w moim "programatorze" użyłem właśnie tej drugiej metody. Ponieważ zapis kolejnego bajta zaczynałem przed zakończeniem poprzedniego (delay(5) //ms), był on ignorowany. Zmieniłem opóźnienie na 10 ms i po kłopocie.
Nie znalazłem innych istotnych różnic między w/w wersjami EEPROM-ów.