kolejne rozszerzenie pamięci
kolejne rozszerzenie pamięci
Cześć braci Komodorowska.
Postanowiłem po latach wrócić do swoich projektów, jakie kiedyś udało mi się dokonać na c64. Jeśli tylko tematy okażą się warte zachodu obiecuję przysiąść fałdów i wrócić do niektórych z nich. Mam nadzieję, że wasze słowa konstruktywnej krytyki dodadzą mi sił i wiary, że to się może jeszcze komuś przydać.
Ok, starczy tego przydługiego wstępu, zaczynamy pierwszą prezentację. Pomysł tej przystawki zrodził się jeszcze w latach dziewięćdziesiątych, działający pierwszy prototyp został ukończony około 1999 roku. po tej dacie prace nad projektem ustały. Było to rozszerzenie pamięci 512 kb w swojej konstrukcji zbliżone do rozwiązań technicznych w C&A oraz RamCart.
W moim wykonaniu wyglądało to tak:
Czas pokrył to już kurzem, ale podłączone wciąż działa. Jakiś czas temu postanowiłem odświeżyć ten projekt i wykonałem nową płytkę, którą wykonałem metodą termotransferu. 16 kostek 32kb zostało zastąpionych jedną 512 kb, dzięki temu dekoder adresowy mógł być trochę odchudzony. Sama idea pozostała bez zmian.
Na ekranie:
Ostatnie modyfikacje kodu systemowego to jak widzicie 99 rok, szmat czasu, nigdy nie byłem dobrym koderem, tym bardziej teraz po latach wygląda to dość żenująco.
Myślę, że temat można potraktować jak ciekawostkę, jeśli uważacie, że warto to udostępnię dokumentację.
Postanowiłem po latach wrócić do swoich projektów, jakie kiedyś udało mi się dokonać na c64. Jeśli tylko tematy okażą się warte zachodu obiecuję przysiąść fałdów i wrócić do niektórych z nich. Mam nadzieję, że wasze słowa konstruktywnej krytyki dodadzą mi sił i wiary, że to się może jeszcze komuś przydać.
Ok, starczy tego przydługiego wstępu, zaczynamy pierwszą prezentację. Pomysł tej przystawki zrodził się jeszcze w latach dziewięćdziesiątych, działający pierwszy prototyp został ukończony około 1999 roku. po tej dacie prace nad projektem ustały. Było to rozszerzenie pamięci 512 kb w swojej konstrukcji zbliżone do rozwiązań technicznych w C&A oraz RamCart.
W moim wykonaniu wyglądało to tak:
Czas pokrył to już kurzem, ale podłączone wciąż działa. Jakiś czas temu postanowiłem odświeżyć ten projekt i wykonałem nową płytkę, którą wykonałem metodą termotransferu. 16 kostek 32kb zostało zastąpionych jedną 512 kb, dzięki temu dekoder adresowy mógł być trochę odchudzony. Sama idea pozostała bez zmian.
Na ekranie:
Ostatnie modyfikacje kodu systemowego to jak widzicie 99 rok, szmat czasu, nigdy nie byłem dobrym koderem, tym bardziej teraz po latach wygląda to dość żenująco.
Myślę, że temat można potraktować jak ciekawostkę, jeśli uważacie, że warto to udostępnię dokumentację.
Cieszy mnie wasz odzew. Nie mam zamiaru robić z tego wielkiej tajemnicy, oczywiście wszelkie materiały udostępnię.
Po zmontowaniu drugiego prototypu okazało się, że w zasilaniu spoczynkowym kości ram wkradł się błąd, płytka została przerobiona ręcznie. Teraz poprawiłem tylko schemat, płytka nie nadaje się, bo trzeba ją bardziej przerobić. Kody źródłowe mam na dyskietce, przez weekend postaram się przegrać na pc.
Pokażę wam zdjęcia jeszcze dwóch zabawek, które przez lata udało mi się zmajstrować. Pierwszy to prosty cart na 7400 i 74174, oraz 27c256. Prosty w budowie i wykonaniu:
Lecz teraz to co lubimy najbardziej, prosty driver twardego dysku zbudowany w oparciu o port równoległy 8285 oraz dwa scalaczki 7404.
W 8255 wykorzystane są wszystkie trzy porty na transmisję danych i parametry, daje to pełne 16 bitów danych, a nie tylko 8 bitów jak przy użyciu układu CIA.
Konstrukcja to też pająk, powstawała w czasach gdzie płytki termotransferowe to było marzenie.
Z tego jestem najbardziej zadowolony. Oprogramowanie umożliwia pełną kontrolę nad twardym dyskiem. Niestety jak to w życiu bywa brak wiedzy, czasu i chęci spowodował, że temat już od dłuższego czasu przestał być przeze mnie rozwijany. Teraz postanowiłem wrócić do tych projektów i poświęcić im swój czas. Bo to ma po prostu dawać przyjemność.
Na razie dokumentacja z eagla dotycząca rozszerzenia, poprawny jest tylko schemat (chyba) płytka jest do przerobienia.
A i jeszcze jedno, nie jestem elektronikiem z wykształcenia, wybaczcie jeśli przyjęte rozwiązania techniczne będą razić.
Po zmontowaniu drugiego prototypu okazało się, że w zasilaniu spoczynkowym kości ram wkradł się błąd, płytka została przerobiona ręcznie. Teraz poprawiłem tylko schemat, płytka nie nadaje się, bo trzeba ją bardziej przerobić. Kody źródłowe mam na dyskietce, przez weekend postaram się przegrać na pc.
Pokażę wam zdjęcia jeszcze dwóch zabawek, które przez lata udało mi się zmajstrować. Pierwszy to prosty cart na 7400 i 74174, oraz 27c256. Prosty w budowie i wykonaniu:
Lecz teraz to co lubimy najbardziej, prosty driver twardego dysku zbudowany w oparciu o port równoległy 8285 oraz dwa scalaczki 7404.
W 8255 wykorzystane są wszystkie trzy porty na transmisję danych i parametry, daje to pełne 16 bitów danych, a nie tylko 8 bitów jak przy użyciu układu CIA.
Konstrukcja to też pająk, powstawała w czasach gdzie płytki termotransferowe to było marzenie.
Z tego jestem najbardziej zadowolony. Oprogramowanie umożliwia pełną kontrolę nad twardym dyskiem. Niestety jak to w życiu bywa brak wiedzy, czasu i chęci spowodował, że temat już od dłuższego czasu przestał być przeze mnie rozwijany. Teraz postanowiłem wrócić do tych projektów i poświęcić im swój czas. Bo to ma po prostu dawać przyjemność.
Na razie dokumentacja z eagla dotycząca rozszerzenia, poprawny jest tylko schemat (chyba) płytka jest do przerobienia.
A i jeszcze jedno, nie jestem elektronikiem z wykształcenia, wybaczcie jeśli przyjęte rozwiązania techniczne będą razić.
- Załączniki
-
- Exram.rar
- (114.19 KiB) Pobrany 592 razy
Termotransfer wymaga trochę precyzji i wprawy. Po kilku nieudanych próbach temat jest do ogarnięcia. W porównaniu do ręcznego malowania płytek to ogromny skok jakościowy.
Jeszcze nie udało mi się przenieść oprogramowania, jest to efekt niekompatybilności PC do którego mam podłączoną 1541 z kompami, na których jest net. Jest to kwestia dołożenia stacji dysków.
Na razie dołączę schemat i płytkę carta, dodałem do płytki reset, bo w wersji podstawowej zapomniałem o tym dodatku. Do carta jest napisane oprogramowanie pozwalające wgrać pojedyncze pliki zapisane w epromie do pamięci c64. Coś na zasadzie loadera jaki jest w Ramcarcie.
Logika układu pozwala na bezproblemową zamianę epromu 64k na 128k. Myślę, że można to dość szybko poprawić.
Sterownik twardziela jest w wersji kabelkowej, niestety nie mam tego jeszcze w wersji elektronicznej. Tu znowu potrzebny jest czas. Oprogramowanie obsługuje komunikację z twardym, niestety teraz stanąłem na implementacji systemu plików. jakby ktoś miał w tej kwestii doświadczenie chętnie wysłucham rad.
Jeszcze nie udało mi się przenieść oprogramowania, jest to efekt niekompatybilności PC do którego mam podłączoną 1541 z kompami, na których jest net. Jest to kwestia dołożenia stacji dysków.
Na razie dołączę schemat i płytkę carta, dodałem do płytki reset, bo w wersji podstawowej zapomniałem o tym dodatku. Do carta jest napisane oprogramowanie pozwalające wgrać pojedyncze pliki zapisane w epromie do pamięci c64. Coś na zasadzie loadera jaki jest w Ramcarcie.
Logika układu pozwala na bezproblemową zamianę epromu 64k na 128k. Myślę, że można to dość szybko poprawić.
Sterownik twardziela jest w wersji kabelkowej, niestety nie mam tego jeszcze w wersji elektronicznej. Tu znowu potrzebny jest czas. Oprogramowanie obsługuje komunikację z twardym, niestety teraz stanąłem na implementacji systemu plików. jakby ktoś miał w tej kwestii doświadczenie chętnie wysłucham rad.
- Załączniki
-
- cart c64.rar
- (95.54 KiB) Pobrany 554 razy
Co do implementacji FAT ja wybrałem FAT16 i LFN do napisania, dysk w 1995r miałem CHS więc takie źródła są wrzucone, obecnie działa to tylko z LBA podstawy:
1. ustalić gdzie zaczyna się partycja podstawowa, fat1 (i fat2), katalog główny, wszystkie takie mam przeliczone przy starcie do późniejszych szybkich obliczeń.
2. ustalić wielkość klastra i ustawić wielkość buforów np. ja mam bufor na dir, plik 1 i plik2, fat1.
Po takich przeliczeniach masz zabawę z:
- procedurą wyszukującą plik w katalogu, konwersja LFN w tą i z powrotem mnie zajmuje jakieś 16 lini na plik.
- procedurą open, chrin,chrout, czyli podmianką kernala,
i najłatwiejsze na początek load a potem save.
Mnie to zajęło kupę czasu a korzystają z tego może trzy osoby.
książka anatomia dysków twardych, wiki wystarczy do rozkminienia wszystkich rzeczy o dyskach i systemach plików. No a jak chcesz zobaczyć jak zaczynałem to masz tutaj http://projekt64.filety.net/index.php?d ... %20SOURCE/
Statystycznie: Fat16 zabrał mi 16K RAM i 8K ROM i jeszcze dziada nie skończyłem, został pryszcz poprawka w expdir i dorobienie od nowa load"$",10 i bug fix który już mi bokami wylewa.
1. ustalić gdzie zaczyna się partycja podstawowa, fat1 (i fat2), katalog główny, wszystkie takie mam przeliczone przy starcie do późniejszych szybkich obliczeń.
2. ustalić wielkość klastra i ustawić wielkość buforów np. ja mam bufor na dir, plik 1 i plik2, fat1.
Po takich przeliczeniach masz zabawę z:
- procedurą wyszukującą plik w katalogu, konwersja LFN w tą i z powrotem mnie zajmuje jakieś 16 lini na plik.
- procedurą open, chrin,chrout, czyli podmianką kernala,
i najłatwiejsze na początek load a potem save.
Mnie to zajęło kupę czasu a korzystają z tego może trzy osoby.
książka anatomia dysków twardych, wiki wystarczy do rozkminienia wszystkich rzeczy o dyskach i systemach plików. No a jak chcesz zobaczyć jak zaczynałem to masz tutaj http://projekt64.filety.net/index.php?d ... %20SOURCE/
Statystycznie: Fat16 zabrał mi 16K RAM i 8K ROM i jeszcze dziada nie skończyłem, został pryszcz poprawka w expdir i dorobienie od nowa load"$",10 i bug fix który już mi bokami wylewa.
Tak się zastanawiam czy implementacja FAT 16 wynika ze szczególnej prostoty tego systemu plików. Przecież istotne ograniczenia, nazwa tylko 8 znaków, 16 bitowy licznik klastrów, w zasadzie pozostaje tylko kompatybilność z IBM i łatwe przenoszenie danych.
Może warto tworzyć jakąś modyfikację z 16 znakami na nazwę plus rodzaj pliku, oraz 24 bitowy adres klastra.
Może warto tworzyć jakąś modyfikację z 16 znakami na nazwę plus rodzaj pliku, oraz 24 bitowy adres klastra.