Czy mozliwe jest zrobienie rozszerzenia pamieci do C-64 ale wpinane do USER_PORTU ?
Powinienem moze napisac jaka wielkosc itp. ale chodzi mi oto czy sie da czy jest sens czy trzeba sie mocno-gimnastykowac, bo jak widze wszelkie rozszerzenia sa robione na zlacze cartridgea.
Nie chodzi mi o rozszerzenie pamieci z jakims oprogramowaniem czy systemem plikow, sama pamiec. Przez userport wybieranie odczyt/zapis, strone pamieci w rozszerzeniu, offset i pobieranie/wysylanie bajtu.
Teraz pytanie ostateczne:
czy mozliwe byloby polaczenie takiego rozszerzenia z kablem bursta na userporcie. W tym rozszerzeniu moznaby trzymac obraz d64 juz przekonwertowany na GCR i szybko burstem zapisac na dyskietke.
Minimum rozszerzenia 256 KB RAM.
rozszerzenie pamieci na USER PORT
Można nie wiem czy nawet w jakimś starszym czasopiśmie nie było coś takiego opisane na 8255. Ogólnie trzeba by do tego zaprzęgnąć jakie PIO, ale obsługa i tak będzie programowa, chyba żeby zaprojektować jakie specjalne PIO na układzie CPLD z trybem (pseudo) DMA (tryb przesyłania z arbitrażem który obsługuje 6526).
Ogólnie powinno się dać, ale była by to tylko specyficzna programowo obsługiwana pamięć danych, nie dało by się zbytnio z niej wykonywać programu.
Ogólnie powinno się dać, ale była by to tylko specyficzna programowo obsługiwana pamięć danych, nie dało by się zbytnio z niej wykonywać programu.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
C&A 1/95, ale tam pamięć była podłączona do szyny adresowej i danych komcia. 8255 wykorzystany był tylko do wyborów /CS poszczególnych kości pamięci. Na User Porcie mamy trochę mało linii (1 pełny port 8-mio bitowy i kilka pojedynczych linii sterujących).
W prosty sposób się nie da, więc pewnie do tej pory nie powstało żadne rozszerzenie pamięci na User Port.
W prosty sposób się nie da, więc pewnie do tej pory nie powstało żadne rozszerzenie pamięci na User Port.
Kisiel to by zaraz wszystko w cpld robił. 
To ma sens jeśli trzeba coś bardziej rozbudowanego na maxa zminiaturyzować (tak jak w przypadku GeoActiona). Moim zdaniem fenkowi wystarczy w tym przypadku RAMdysk (z dostępem sekwencyjnym), pracujący na Userporcie, prosty i tani, metodą mojego Ucarta: czyli SRAM (praktycznie dowolny - możesz sobie i w mega tam wetknąć, jak będziesz chciał i podtrzymywać go bateryjnie - wtedy będzie RAM/ROMdysk) oraz np. dwa liczniki 4040, robiące za szynę adresową: łącznie szyna adresowa dla 2 x 4040 to 24bit (i dalej można rozbudowywać). Tylko trzy układy scalone, łącznie z pamięcią i mamy fajny RAMdysk, Przy czym nie musimy angażować do tego w CIA2 pinów odpowiedzialnych za IEC - po co robić kolizję ze stacją, czy SD2IEC. Wystarczy wykorzystać z userportu dla szyny danych 8bit (PB0-PB7 w CIA2), oraz trzy sygnały sterujące dla RAMdysku: /RD, /WR i sygnał CLOCK dla 4040 (zmiana adresu na szynie adresowej RAMdysku), a mamy do dyspozycji (poza pinami interfejsu szeregowego) w CIA2 jeszcze pięć pinów: CNT, SP, /PC, PA2, /FLAG, a więc powinno się to dać zrobić!
To ma sens jeśli trzeba coś bardziej rozbudowanego na maxa zminiaturyzować (tak jak w przypadku GeoActiona). Moim zdaniem fenkowi wystarczy w tym przypadku RAMdysk (z dostępem sekwencyjnym), pracujący na Userporcie, prosty i tani, metodą mojego Ucarta: czyli SRAM (praktycznie dowolny - możesz sobie i w mega tam wetknąć, jak będziesz chciał i podtrzymywać go bateryjnie - wtedy będzie RAM/ROMdysk) oraz np. dwa liczniki 4040, robiące za szynę adresową: łącznie szyna adresowa dla 2 x 4040 to 24bit (i dalej można rozbudowywać). Tylko trzy układy scalone, łącznie z pamięcią i mamy fajny RAMdysk, Przy czym nie musimy angażować do tego w CIA2 pinów odpowiedzialnych za IEC - po co robić kolizję ze stacją, czy SD2IEC. Wystarczy wykorzystać z userportu dla szyny danych 8bit (PB0-PB7 w CIA2), oraz trzy sygnały sterujące dla RAMdysku: /RD, /WR i sygnał CLOCK dla 4040 (zmiana adresu na szynie adresowej RAMdysku), a mamy do dyspozycji (poza pinami interfejsu szeregowego) w CIA2 jeszcze pięć pinów: CNT, SP, /PC, PA2, /FLAG, a więc powinno się to dać zrobić!C64PLC
he.. każdy lubi to co ma. Wbrew pozorom różnica miedzy zrobieniem czegoś na CPLD a na klasycznych scalakach aż tak wielka nie jest. Oczywiście miniaturyzacja jest zauważalna, po przeskoku z jednego na drugie, ale najtańsze CPLD nie mają aż tak porażających zasobów jak by się to wydawało, jedyny zysk to mniejsza i prostsza płytka drukowana.
Co do liczników do adresowania pamięci, to ja jak bym miał już się w coś takiego bawić, to wolał bym poświecić jeden kanał szeregowy i mieć rejestry przesuwne do których wpisuję adres niż "zgadywać" co mam w liczniku.
Co do liczników do adresowania pamięci, to ja jak bym miał już się w coś takiego bawić, to wolał bym poświecić jeden kanał szeregowy i mieć rejestry przesuwne do których wpisuję adres niż "zgadywać" co mam w liczniku.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
@Jacek31, chodzi o to, żeby to było jak najprostsze układowo/softowo i skuteczne. Nie twierdzę, że z rejestrami nie da się zrobić, ale rejestr wymaga do obsłużenia min. dwóch pinów: wej/wyj. Danych, oraz Clock, a nie jeden pin jak to ma miejsce w przypadku użycia liczników. Poza tym trzeba pamiętać, że będzie jeszcze prawdopodobnie potrzebny jeden wolny pin na softowy reset RAMdysku (niezależny od RESETu komcia) Moim zdaniem obsługa rejestrów przesuwnych wcale nie będzie łatwiejsza ("zgadywanie" aktualnego adresu) niż obsługa liczników, gdzie w prosty sposób można zliczać softowo i pamiętać tylko ilość impulsów podanych na wei. zegarowe liczników adresowych RAMdysku. Zresztą nawet nie o to chodzi, taki RAMdysk to raczej pamięć podręczna do przechowywania calych plików (zrzutów) i dostęp bezpośredni do określonych komórek (ze względu na prostotę rozwiązania) nie jest w takim przypadku konieczny. Po co komplikować coś co z założenia ma być proste i tanie. UCart się sprawdził praktycznie, dlatego takie rozwiązanie polecam, nie mniej nie mam monopolu na jedyne słuszne rozwiązania, więc możecie kombinować do woli. - być może dobrze przemyślany sofotowo/układowo RAMdysk z rejestrami dla szyny adresowej nie będzie gorszy!
PS Mniejsza płytka wcale nie musi oznaczać prostsza i tańsza! Popatrz na ostatnie wpisy w temacie GeoAction: "... dodali 30% za małe odległości między ścieżkami".
- być może dobrze przemyślany sofotowo/układowo RAMdysk z rejestrami dla szyny adresowej nie będzie gorszy!PS Mniejsza płytka wcale nie musi oznaczać prostsza i tańsza! Popatrz na ostatnie wpisy w temacie GeoAction: "... dodali 30% za małe odległości między ścieżkami".
C64PLC
Suchy nie wiem czy zauważyłeś ale Clock + Reset i Data + Clock to dokładnie 2 linie, czyli wychodzi na to samo, z tą różnica że w przypadku rejestru przesuwnego reset właściwie niepotrzebny, bo wpisujesz same zera i masz stan po resecie. Dodatkowo do rejestru wpisuję sobie np. $4000 i po 16 cyklach zegara adres w pamięci mam ustawiony a nie muszę zliczać 16384 cykli aby ustawić licznik adresu. Różnica raczej spora, jeżeli dostęp do pamięci nie jest liniowy.
Oczywiście ma to i swoje wady, głównie tę pod nazwą programator, szczególnie w przypadku GALi, bo te w wersji ISP są drogie i trudne do zdobycia od jakiegoś czasu.
To też jest dla mnie takie szukanie trochę problemu na siłę. Kto od razu karze stosować układ SMD, można zastosować obudowę PLCC44, tradycyjna przewlekaną podstawkę pod nią i masz standardowe rastry. Na mojej karcie Turbo do A1200 cała gumowa logika jak często to się zwie to 4 układy GAL22V10, to samo można zrobić w tym przypadku 2-3 GALe 20V8 czy 22V10(DIL28) i masz jak najbardziej standardowo wyglądające rozwiązanie z tą różnicą ze bardziej elastyczne, tak sprzętowo jak i pod katem budowy PCB.Mniejsza płytka wcale nie musi oznaczać prostsza i tańsza! Popatrz na ostatnie wpisy w temacie GeoAction: "... dodali 30% za małe odległości między ścieżkami".
Oczywiście ma to i swoje wady, głównie tę pod nazwą programator, szczególnie w przypadku GALi, bo te w wersji ISP są drogie i trudne do zdobycia od jakiegoś czasu.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
Założyłem ten wątek z tym zapytaniem bo myślałem że może taki prosty i tani ramdysk mógłby być pomocny dla osób korzystających z sd2iec, mmc2iec, ide64, ciaide do trzymania w nim obrazu .d64 lub dwóch obrazów d64 i mógłby być alternatywą dla 1541u.
Jeżeli ktoś korzysta z 1541u to mountuje sobie obraz dyskietki jako .d64 i może wcześniej wczytać np. dirmastera i edytować dysk, dokonywać operacji bezpośrednio na dyskietce.
Żeby nie było ostatnimi dniami przed założeniem wątku zaznajomiłem się trochę z softem na c64. Ja na ide 64 w sumie mam plugin do zapisu obrazów d64 z dysku na dyskietkę, jednak plugin do obejrzenia katalogu extractu pojedynczych plików napisałem sobie jakoś w 2006 roku, widzę że na sd2iec są jakieś toolsy do przeglądania ale chyba nie ma softu do odczyt/zapis obrazu .d64 na dyskietkę.
Czy taki ramdysk nie byłby sensownym rozwiązaniem do wczytania w powyższych rozszerzeń poprzez c-64 obrazu .d64 przeniesienia do ramdysku i edycji "dyskietki" potem zapisu obrazu na dyskietkę lub używane rozszerzenie ?
Jeżeli nie, to koniec tematu z mojej strony.
Kisiel: to jest za ambitne podejście, aczkolwiek gdyby coś takiego powstało to oprogramowałbym to od strony c-64, ale musiałoby to wyglądać tak że jest podpięta jakaś karta a na nią tworzę system plików "ułomny" do trzymania TYLKO obrazów .d64, po stronie c64
byłby napisany manager filesystem/pliki/uruchamianie pojedynczych plikow/zapis przez bursta obrazow d64 na dyskietke
Taki manager pewnie i tak musiałby być uruchamiany z zewnątrz, np. z ram-carta z GeoActiona, urządzenie musiałoby być powiązane w burstem po to żeby w te 10 s nagrać obraz (bez weryfikacji) .d64 na dyskietkę.
reszta:
Skoro zacząłem temat to w sumie z mojej strony tyle, ramdysk na user-porcie taki o pojemności 1MB i tak by MI się przydał
Jeżeli ktoś korzysta z 1541u to mountuje sobie obraz dyskietki jako .d64 i może wcześniej wczytać np. dirmastera i edytować dysk, dokonywać operacji bezpośrednio na dyskietce.
Żeby nie było ostatnimi dniami przed założeniem wątku zaznajomiłem się trochę z softem na c64. Ja na ide 64 w sumie mam plugin do zapisu obrazów d64 z dysku na dyskietkę, jednak plugin do obejrzenia katalogu extractu pojedynczych plików napisałem sobie jakoś w 2006 roku, widzę że na sd2iec są jakieś toolsy do przeglądania ale chyba nie ma softu do odczyt/zapis obrazu .d64 na dyskietkę.
Czy taki ramdysk nie byłby sensownym rozwiązaniem do wczytania w powyższych rozszerzeń poprzez c-64 obrazu .d64 przeniesienia do ramdysku i edycji "dyskietki" potem zapisu obrazu na dyskietkę lub używane rozszerzenie ?
Jeżeli nie, to koniec tematu z mojej strony.
Kisiel: to jest za ambitne podejście, aczkolwiek gdyby coś takiego powstało to oprogramowałbym to od strony c-64, ale musiałoby to wyglądać tak że jest podpięta jakaś karta a na nią tworzę system plików "ułomny" do trzymania TYLKO obrazów .d64, po stronie c64
byłby napisany manager filesystem/pliki/uruchamianie pojedynczych plikow/zapis przez bursta obrazow d64 na dyskietke
Taki manager pewnie i tak musiałby być uruchamiany z zewnątrz, np. z ram-carta z GeoActiona, urządzenie musiałoby być powiązane w burstem po to żeby w te 10 s nagrać obraz (bez weryfikacji) .d64 na dyskietkę.
reszta:
Skoro zacząłem temat to w sumie z mojej strony tyle, ramdysk na user-porcie taki o pojemności 1MB i tak by MI się przydał
Fenek jak pokazują konstrukcje kiśla nie ma rzeczy nie możliwych. Natomiast należy sobie zdać sprawę, ze konstrukcja prosta oparta o liczniki jak proponuje Suchy, to sprzęt z natury mułowaty i ograniczony swoją prostotą. Lepsze konstrukcje oczywiście będą droższe, ale bardziej praktyczne i elastyczne programowo. Jak widać jest to zawsze szukanie niełatwego kompromisu między ceną, budową, a możliwościami.
Ja osobiście np. bardzo chętnie bym widział czytnik kart MMC/SD wpinany do User Port, po co mam rozbierać kompa i w nim grzebać, jak bym mógł mieć urządkonko które ładnie wpinam sobie w Usera i git majonez.
Ja osobiście np. bardzo chętnie bym widział czytnik kart MMC/SD wpinany do User Port, po co mam rozbierać kompa i w nim grzebać, jak bym mógł mieć urządkonko które ładnie wpinam sobie w Usera i git majonez.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
@Fenek, wbrew pozorom sd2iec działa na obrazach d64 prawdopodobnie jak 1541u (chociaż tego drugiego nie mam) różnica polega na emulowaniu samej transmisji (jak również kernala) stacji c1541, aby zapewnić 99% kompatyblinosci.
Ale jeśli chodzi o same obrazy to dostęp nie jest do nich w żaden sposób ograniczony. Przykładowo, jak "przejdę" do jakiegoś obrazu na karcie, to komunikacja się odbywa tak samo jak dla innych stacji:
load"$",8 - wyswietli mi katolog dokladnie jak na stacji c1541, mało tego nawet po resecie c64 ta emulowana dyskietka nie znika. jak wpiszesz load "*",8 to wgra się pierwszy plik NIE na karcie, ale akurat na otwartym obrazie dysku (dokładnie tak jakby dyskietka siedziała w stacji).
Problem leży głównie w loaderach - bo one sie pakuja do ramu stacji c1541 - a sd2iec po prostu jest inny.
Nie wiem dokładnie jak, ale świetnie radzi sobie z sd2iec FINAL3 (widocznie jego turbo bazuje tylko na obsłudze z c64, a nie z urządzenia) - wgrywa pliki w turbo jak ze stacji - ACTION mu tu ustępuje, i wgrywa programy w "tradycyjnej" szybkosci transmisji.
Na razie nie zauważyłem jakiegoś całodyskowego kopiera z obrazów d64 umieszczanych na karcie SD, takiego sektor w sektror, ale to jest tylko i wyłącznie kwestia software'u - który na razie jak widać raczkuje (niestety kopier actiona wariuje, a szkoda).
Co do rozwiązań sprzętowych, tylko niech nikt nie kombinuje takiego urzadzenia które procek w c64 musiłoby skanować CYKLICZNIE stany portów, aby szła transmisja. To zaburza całkowicie używanie takiego urządzenia w trakcie czegokolwiek oprócz samej transmisji - jakieś muzyczki, albo animacji i efektach opartych na cyklowaniu koncząc.
Ale jeśli chodzi o same obrazy to dostęp nie jest do nich w żaden sposób ograniczony. Przykładowo, jak "przejdę" do jakiegoś obrazu na karcie, to komunikacja się odbywa tak samo jak dla innych stacji:
load"$",8 - wyswietli mi katolog dokladnie jak na stacji c1541, mało tego nawet po resecie c64 ta emulowana dyskietka nie znika. jak wpiszesz load "*",8 to wgra się pierwszy plik NIE na karcie, ale akurat na otwartym obrazie dysku (dokładnie tak jakby dyskietka siedziała w stacji).
Problem leży głównie w loaderach - bo one sie pakuja do ramu stacji c1541 - a sd2iec po prostu jest inny.
Nie wiem dokładnie jak, ale świetnie radzi sobie z sd2iec FINAL3 (widocznie jego turbo bazuje tylko na obsłudze z c64, a nie z urządzenia) - wgrywa pliki w turbo jak ze stacji - ACTION mu tu ustępuje, i wgrywa programy w "tradycyjnej" szybkosci transmisji.
Na razie nie zauważyłem jakiegoś całodyskowego kopiera z obrazów d64 umieszczanych na karcie SD, takiego sektor w sektror, ale to jest tylko i wyłącznie kwestia software'u - który na razie jak widać raczkuje (niestety kopier actiona wariuje, a szkoda).
Co do rozwiązań sprzętowych, tylko niech nikt nie kombinuje takiego urzadzenia które procek w c64 musiłoby skanować CYKLICZNIE stany portów, aby szła transmisja. To zaburza całkowicie używanie takiego urządzenia w trakcie czegokolwiek oprócz samej transmisji - jakieś muzyczki, albo animacji i efektach opartych na cyklowaniu koncząc.
Bo pecet to zwykły banan...
... no dawno już nie czytałem większego bzdeta!Jacek31 pisze:...Natomiast należy sobie zdać sprawę, ze konstrukcja prosta oparta o liczniki jak proponuje Suchy, to sprzęt z natury mułowaty i ograniczony swoją prostotą. ...
Na jakiej podstawie tak twierdzisz: zrobiłeś UCarta? Testowałeś go? Jacuś weź ty się w końcu za jakąś konkretną robotę i przestań tworzyć takie konstrukcje literackie, bo się ośmieszasz!@Skull, testowałeś DraCopy (nie DraBrowser nie FileBrowser, nie Fibr) ze stacją i SD2IEC. Kopier z managerem katalogów i plików dla dwóch urządzeń - w dwóch okienkach można ustawić różne numery urządzeń IEC, jest tam również opcja zaznacz wszystko (* - gwiazdka) dla kopiowwania?
DraCopy dla C64
... Kisiel pisał niedawno, że nawet na jego twardziela dobrze kopiuje.
C64PLC
testowałem, chyba już wszystkie - niestety w każdym z tych programów, to kopiowanie szfankuje, albo zamienia miejsca plików, albo wogole nie wszystkie skopiuje, i wszystkie działają przeraźliwie wolno -> wygrywa tu nadal kabel x1541...suchy pisze: @Skull, testowałeś DraCopy...
Ech, jak nie wyjdzie nic sensownego w najblizszym czasie to moze sie pokusze o napisanie czegos -> najlepiej połączyć turbo z finala 3 z jakimś loaderem (a właściwie wystarczy sama obsługa danych po serialu, nie koniecznie dwubitowa i bez zabawy w kodzie gcr) dla stacji 1541. Może guru od loaderów Wegi coś pomoże.
ps. na razie udało mi się napisać taki "mikro"substytut kernala c64 - na potrzeby loadera w swojej gierce. Działa to szybciej niż standardowe ładowanie i można to jakoś kontrolować.
ps2. a swoją drogą jestem zawiedziony procedurami transmisji zawartych w romie c64, nie dość że działają wolno, to nie można ich kontrolować tak aby działały pod własnymi aplikacjami - dłuższe wywołanie własnych przerwań i... po synchronizacji (łatwiej już się bawić z cyklowaniem w transmisji dwubitowej) .
Bo pecet to zwykły banan...
Primo.... no dawno już nie czytałem większego bzdeta! Very Happy Very Happy Very Happy Na jakiej podstawie tak twierdzisz: zrobiłeś UCarta? Testowałeś go? Jacuś weź ty się w końcu za jakąś konkretną robotę i przestań tworzyć takie konstrukcje literackie, bo się ośmieszasz!
Ja porównałem szybkość uzyskania danego adresu na liniach adresowych za pomocą zwykłego licznika i rejestru przesuwnego. Nie porównywałem żadnej konkretnej konstrukcji (choćby z tego powodu że nie mam jej schematu). Nie wiem skąd uroił ci się ten UCart o którym nawet na moment nie wspomniałem
Duo.
Chyba sam przyznasz że wystawienie dowolnego adresu na choćby 16 bitowej szynie adresowej większego niż owe 16 będzie szybsze za pomocą rejestru przesuwnego który potrzebuje na wystawienie dowolnego adresu tylko tych 16 cykli zegara, niż zliczenie go programowo za pomocą licznika.
Zresztą dobitny przykład już podałem wcześniej.
Tri.
Ty w swoim rozumowaniu uparcie zakładasz liniowy dostęp do pamięci, czyli właściwie kopiowanie jakiś tam bloków pamięci, wtedy owszem licznik będzie szybszy od rejestru przesuwnego, ale ja jak by sobie budował jakąś pamięć to też bym chciał mieć w miarę szybki dostęp do danych w trybie wybiórczym (przesyłanie danych pod różne znacząco się od siebie różniące adresy).
Reasumując atakujesz moje rozumowanie, bo się różni od twojego, a jak byś dobrze pokombinował to dojdziesz do wniosku że wystarczy połączyć rejestr przesuwny z programowanym licznikiem i masz 2 w jednym, w zależności od potrzeb mając do wyboru lepsze rozwiązanie.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
@Skull, sprawdź jeszcze raz DraCopy jak zainstalujesz EPROMka, zobaczysz różnicę! Jedynie DraCopy działa u mnie dobrze, jeśli chodzi o SD2IEC (stacji nie mam więc nie sprawdzę). Fibr jest też OK, ale dłużej od DraCopy ładuje directory (zauważysz jak będziesz miał ponad 100 podkatalogów w głównym dir. ! - ważne przy plikach M2I). Tylko DraCopy (no i Fibr) poprawnie obsługuja pliki dyskowe M2I w SD2IEC, FileBrowser, DraBrowser wymiękają. A M2I dla SD2IEC to miodzio dla pełnodyskowych programów, działających w C64 poprawnie (z dogrywaniem introsów, poziomów, zapisywaniem HI-scores itd - sprawdziłem), tak jak .D64 dla stacji. Pisałem już gdzieś, że na niemieckim forumC64, chłopaki mają programik: "M2I maker", którym przekonwertowali dla potrzeb SD2IEC większość interesujących pełnodyskowych gierek .D64 (które w tym formacie nie działały na SD2IEC chyba ze względu na orientalne fastloadery, odpalane w stacji). Tutaj jest zbiór ok. 300 gierek (klawych, sam ostatnio pogiercowałem sobie na realmaszynce w golfa (wspomnienia), RenegadeIII, TurricanaIII (którego nie znałem) a żona widząc to, znacząco stukała się w czoło ):
http://www.creepitz.de/downloads/m2i/
SD2IEC z pełnodyskowymi programami M2I + C64 z JiffyDOSem i DraCopy (wgranym do każdego istotnego katalogu - przy pojemności karty SD 2GB można sobie na to pozwolić) to sama przyjemność!
):http://www.creepitz.de/downloads/m2i/
SD2IEC z pełnodyskowymi programami M2I + C64 z JiffyDOSem i DraCopy (wgranym do każdego istotnego katalogu - przy pojemności karty SD 2GB można sobie na to pozwolić) to sama przyjemność!
Ostatnio zmieniony 08 cze 2010, 13:06 przez suchy, łącznie zmieniany 1 raz.
C64PLC