Objaw ten jest bardzo charakterystyczny dla silnie zanieczyszczonej klawiatury. Klawisze są montowane w plastikowych prowadnicach, które w miarę upływu czasu wycierają się na skutek tarcia powstającego przy wciskaniu klawisza. Wskutek tego tworzy się drobniuteńki pytek opadający na zestyki znajdujące się dokładnie pod spodem. Pył izoluje zestyk co następnie objawia się właśnie w opisany przez Pana sposób. Radziłbym zatem oczyścić dokładnie klawiaturę.
W literaturze fachowej poświęconej Commodore ciągle wspomina się o niekorzystnym porcie SZEREGOWYM przedstawiając jako wzór doskonałości port RÓWNOLEGŁY. Czy mógłbym prosić o wyjaśnienie o co tu właściwie chodzi?
Chodzi tu o sposób transmisji danych do/z urządzeń peryferyjnych. Transmisja SZEREGOWA polega na zamianie pojedynczego bajtu na 8 bitów i wysyłaniu ich kolejno w danej jednostce czasu np. do drukarki. Transmisja RÓWNOLEGŁA natomiast pozwala na jednoczesne wysłanie 8 bitów w tej samej jednostce czasu co znacznie zwiększa prędkość transmisji.
Oba rozwiązania mają swoje wady i zalety. Wadą transmisji szeregowej jest jej powolność, zaletą natomiast stosunkowo niewielka ilość linii potrzebnych do tego celu; transmisja równoległa jest szybsza lecz wymaga stosowania znacznie większej ilości linii transmisyjnych.
„Mam program GEOS V1.3 i związane z nim dwa problemy. Po pierwsze stacja strasznie rzęzi podczas wczytywania systemu, po drugie nie mogę za pomocą modułu FINAŁ III wykonać kopii ekranu na drukarce (...)“
W pierwszym wypadku dysponuje Pan zapewne dyskietką piracką lub jedną z wcześniejszych wersji przekazanych przez firmę BERKELEY SOFTWORKS do dystrybucji; oryginalna wersja GEOS V1.3 (oznaczona w dystrybucji jako V1 3B i mająca indentyfikator LJ) wczytuje się prawie bezszelestnie W drugim wypadku podejrzewam, że następuje kolizja pomiędzy FINAŁ III i samym systemem GEOS — zarówno FINAL CARTRIDGE jak i GEOS korzystają z przerwań NMI i stąd cały problem.
Od niedawna zajmuję się programowaniem w języku maszynowym C-128. Ostatnio w mapie pamięci napotkałem określenie KERNAL JUMP TABLE (tabela skoków KERNAL-u). Do czego służy ta tabela i jak można ją wykorzystać?
Systemy operacyjne C-128 i C-64 zawierają szereg standardowych procedur, przeznaczonych m.in. do wykorzystania przez programujących w języku wewnętrznym. Jednakże ze względu na odmienne założenia projektowe dla obu tych komputerów dana procedura może być dostępna w C-64 od adresu dajmy na to E000 a w C-128 od adresu E8CA. Gdyby teraz uruchomił Pan program napisany dla C-64 na C-128 to prawdopodobnie zablokowałby się on. Ponieważ zestaw rozkazów mikroprocesora w obu komputerach jest identyczny projektanci wpadli na pomysł aby w określony i STAŁY we wszystkich komputerach obszar pamięci ROM wpisać adresy poszczególnych procedur standardowych (CLALL, RAMTAS, CHROUT itp.). Jeżeli teraz w programie układanym dla C-64 zamiast fizycznego adresu dajmy na to procedury CHROUT wpisze Pan adres $FFD2 będący jednym z adresów tabeli skoków KERNAL, to może Pan dany program wykorzystać i na C-64 i na C-128. Po wykonaniu skoku do komórki $FFD2 procesor znajdzie tam rozkaz JMP i aktualny adres procedury CHROUT zależny od typu komputera. Dzięki temu, jeśli korzysta Pan wyłącznie z procedur standardowych systemu operacyjnego (bez odwołań do BASIC ROM) Pana program będzie działał na wszystkich komputerach Commodore C-64, C-128 czy C-16. Szerzej omówimy tabelę skoków w cyklu poświęconym programowaniu w języku maszynowym.
Klaudiusz Dybowski
