Port szeregowy dla CA80? To proste!

  Platforma RCbus daje nam wiele nowych możliwości. Nie musimy projektować nowych modułów sami, bo wiele osób robi to za nas. Wystarczy odszukać projekt, który spełni nasze założenia. Gotową płytkę udostępnił mi kolega @tapy.

Port szeregowy RCbus przygotowany do pracy z CA80.

Transmisja szeregowa w czasach kiedy poznawałem CA80 była zbędną ekstrawagancją. Nie było takiej potrzeby, bo nie było komputerów. Dzisiaj trudno to sobie wyobrazić, ale programy pisało się na kartce i ręcznie tworzyło kod binarny, który trzeba było wpisać za pomocą klawiatury. Każdy bajt był ważny, bo to dwa-trzy stuknięcia w klawiaturę. Poza tym mój CA80 miał 2 kilobajty RAM, więc należało się streszczać. Napiszmy zatem program zoptymalizowany pod względem rozmiaru.

Nie od razu wszystko działa poprawnie.

Na początku musimy sprawdzić adresowanie, bo CA80 używa niepełnego. Porty 0E0H (8255 użytkownika), 0F0H (systemowy) czy 0F8H (CTC) w rzeczywistości "widziane" są też pod innymi adresami. 0E0H to również 080H, 0A0H i 0C0H. Moduł USIO umożliwia wybranie 080H lub 084H, więc nie musimy niczego przerabiać - wystarczy zworkę umieścić w odpowiednim miejscu.

Druga wersja prawie gotowa.

Do pisania programu należy się przygotować. Dobrze jest zapoznać się z User Manual producenta (UM008101-0601), albo z jakimś poradnikiem. W sieci można znaleźć np. "How To Program The Z80 Serial I/O (SIO) and CTC". Jest to dosyć zaawansowany projekt jak na początek, więc znalazłem coś o wiele prostszego.

 

Deklaracje adresów rejestrów.

Autorka przedstawia trochę chaotycznie, ale bardzo przejrzyście niezbędne minimum. Metodą kopiuj-wklej zaczynamy pracę. Powstają pierwsze wersje najważniejszych procedur.

Odbiór znaku.

Wysłanie znaku.

Izabella sama na koniec zauważa, że nie trzeba za każdym razem włączać Rx i Tx, wystarczy zrobić to raz na początku, więc uwzględniłem to w SIO_INIT. Program wydaje się być krótki - po co go zmieniać? Na razie nie mamy jeszcze właściwego programu, ale jego części składowe, które trzeba ze sobą połączyć. Do tego obsługują one tylko jeden kanał.

Procedura inicjalizacji SIO wg poradnika.

Przyjrzyjmy się pierwszej procedurze. Jest w niej siedem sekwencji tych samych rozkazów LD A,nn i OUT (nn),A. Obydwa są dwubajtowe, więc razem jest 28 bajtów. To samo musimy zrobić w drugim kanale! Wysyłamy ciągle do tego samego adresu, więc można użyć rozkaz OTIR. Wystarczy utworzyć tablicę wartości wysyłanych do kolejnych rejestrów, do HL wpisać adres jej początku, do B długość tablicy a do C adres rejestru SIO Control. Jeżeli obydwa kanały ustawimy tak samo, możemy użyć tę samą tablicę.

Wersja zoptymalizowana.

Teraz jedna krótka procedura ustawia parametry obydwu kanałów. A co można zmienić w pozostałych procedurach? Możemy użyć adresowanie portów rejestrem C, żeby jednym podprogramem czytać lub pisać do wybranego kanału.

Zoptymalizowana procedura READ_CHAR.

Można wykorzystać to, że rejestr danych ma adres o dwa mniejszy od sterującego. Przy okazji flaga przeniesienia (CY) służy do rozpoznania, czy nowy znak został odczytany. Rejestr B służy do pamiętania adresu aktualnego kanału, żeby ciągle nie wpisywać nowej wartości do rejestru C. 

Wysłanie znaku z timeoutem.

Procedura wysyłania znaku jest blokująca, to znaczy czeka na gotowość SIO na przyjęcie znaku. Jest to niebezpieczne, bo w przypadku awarii generatora XCLK program się w niej zawiesi. Żeby tego uniknąć zastosujemy "timeout" w postaci pętli z rozkazem DJNZ. Tak jak w READ_CHAR flaga CY może posłużyć do sprawdzenia, czy operacja się udała (nie zrobiłem tego, ale wystarczy wstawić rozkaz CCF po DJNZ i SCF po OUT (C),A.

Pierwsza wersja programu testowego.

Teraz zajmijmy się głównym programem testującym SIO, który zainicjuje obydwa kanały, następnie wyśle komunikaty i w pętli zaczeka na przychodzące znaki, o czym poinformuje odpowiednim komunikatem w tym samym kanale. Pierwsza wersja w pętli wysyłała na przemian komunikaty w obydwu kanałach, co utrudniało znalezienie przychodzącego znaku.

Procedury wysyłające komunikaty.

Komunikaty są zapisane w postaci tablic zakończonych bajtem 0FFH, tak jak w CA80. 😊 Zamiast kodów siedmiosegmentowych mamy znaki ASCII. Brakuje jeszcze procedury przejścia do nowej linii CRLF.

Koniec komunikatu przenosi kursor na początek nowej linii.

Tutaj nie ma co optymalizować - wysyłamy tylko dwa znaki, więc nie opłaca się robić tego w inny sposób.

    

PRINT zoptymalizowany.

Komunikaty powitalne zostały przeniesione przed pętlę, bo jednorazowe ich wykonanie w zupełności wystarczy. Przy okazji zrobiłem optymalizację polegającą na zmianie kolejności procedur, co pozwoliło na zmniejszenie liczby rozkazów CALL.

Program główny.

 

Teraz program spełnia swoje zadanie i jest dosyć krótki. Procedury mogą posłużyć do napisania innych programów, na przykład do odbierania programów bezpośrednio z komputera PC, ale to może następnym razem.

Cały program jest dostępny w repozytorium.

 

Repozytorium.