[CA80] [Z80-MBC2] Oprogramowanie (ROM - Monitor).
: czwartek 13 lut 2020, 18:33
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ę.
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.
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.
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.
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ę.
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.
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.
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.