Osobom zorientowanym w temacie pytanie pewnie wyda się banalne, ale chyba prościej zapytać kogoś zorientowane w temacie, niż przekopywać się przez tony artykułów w Internecie. ;)
Chodzi mi po głowie pomysł wyciągnięcia z pudełka starego C64. W związku z brakiem stacji dysków i brakiem ochoty na zabawę z magnetofonem, szukam jakiegoś prostego, w miarę "współczesnego" rozwiązania.
Wiem, że istniały rozmaite interfejsy. Dawno temu na zlocie miłośników starych komputerów widziałem cartridge DIY, wyposażony w gniazdo EPROM, do którego ładowało się pamięć z wypalonym obrazem gry. Obecnie z tego co widzę są dostępne urządzenia wyposażone w czytniki kart SD, podłączane do złącza cartridge'a albo portu szeregowego.
Szukam właśnie czegoś w tym stylu, najlepiej gdyby spełniało następujące warunki:
1) Prostota obsługi - niech urządzenie nie wymaga wklepywania długiego programu do obsługi w BASIC-u albo ładowania go z taśmy.
2) Prostota konstrukcji - preferowane rozwiązania oparte na jednostronnej płytce drukowanej. Może być SMD, ale nie musi.
3) Dostępność części - niech urządzenie składa się z popularnych elementów, których nie trzeba będzie zamawiać na zachodzie.
4) Idealnie byłoby, gdyby konstrukcja pasowała do jakiejś standardowej obudowy ze sklepu za rogiem. ;)
Istnieje coś takiego? Chętnie dowiem się też czegoś na temat podobnych rozwiązań stosowanych w innych platformach ośmiobitowych (małe Atari, Spectrum, Amstrad CPC) - wiedza przyda się na przyszłość. ;)
Skleroza mi juz dopisuje i nie pamietam ... ale w Atari to chyba "system operacyjny" byl w stacji dyskow. A moze to wlasnie w C64 tak bylo ?
Haslo mialo oznaczac, ze to w stacji dyskow byl program zajmujacy sie nazwami plikow, przydzialem pamieci dyskowej itp. Interfejs ze stacja byl niby skomplikowany, ale tam po prostu zwykla asynchroniczna transmisja jak RS232 grala glowne skrzypce, tylko ze poziomy napiec TTL.
Atari mialo o tyle dobrze, ze sektor byl w miare standardowy - 128 bajtow FM, ale zorganizowane tak smiesznie, ze bylo 125 bajtow danych i na koncu 3 bajty nr nastepnego sektora. Dzis trzeba by chyba jakis sprytny kawalek programu, ktory by pliki z karty FAT32 udostepnial po 125 bajtow ...
Tak mi jeszcze przebija, ze na C64 byl jakis bardziej uniwersalny kontroler dyskowy, ktory pozwalal na dosc swobodny dostep do surowych danych z dysku. Przez co z jednej strony mial bardzo szerokie mozliwosci, ale z drugiej - pelna emulacja niemozliwa niestety. A moze to juz Amiga a nie C64 ?
Na spectrum zas, to o ile mnie pamiec nie myli, żadnego rozszerzenia funkcjonalnosci nie przewidywano, wiec co ambitniejsze interfejsy podstawialy po prostu caly nowy ROM. W przypadku stacji dyskow z CPM to w ogole traktowano Spectruma jako terminal ekranowy, pamiec, procesor, system operacyjny - to bylo w stacji. Sensu w tym za grosz nie bylo z powodu miernego ekranu, ale jak to byl Timex a nie ZX, to mial tryb podwojny i 64 znaki w linii ...
W C64 system był wbudowany. A pytający pyta o cartridge. Z tego co pamiętam to umożliwiały nagranie jednej czy kilku gier, które standardowo wygrywało się z magnetofonu. Dzięki temu można było błyskawicznie załadować grę do komputera. Realizacja takiego cartridge z kartą SD dawałaby możliwość załadowania na niego całej kolekcji gier. Ciekawy pomysł.
W sumie jeżeli jest port szeregowy, to nawet niczego nie trzeba lutować. Wystarczy czytać z portu i pakować w pamięć C64. Problem w tym jak takiego loadera wbić w C64 i to nie przerabiając/niszcząc tego zabytku. Wpisywanie za każdym razem z klawiatury raczej męczące jest.
Chyba idealnie byłoby gdyby zrobić hardwareowy emulator magnetofonu. Ale ten był dedykowany do C64 - jakiś opatentowany kabelek. Może gdzieś już ktoś to zrobił.
Kartridże wpinały się IMHO gdzieś pod magistralę. Kartridże bywały AFAIK made in Poland, więc odtworzenie tej technologii nie powinno być niemożliwe. Oczywiście Flash i nowoczesne IC zamiast. Ale jeżeli Polak potrafił w 198x to pewnie w 2016 też się da.
Prostszym rozwiązaniem jest emulacja C64 na czymś. PC, Rasberry, cokolwiek.
Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:57c42e04$0$654$ snipped-for-privacy@news.neostrada.pl...
Niezupełnie. Jako tako, oba komputery posiadają własny system operacyjny, ten z C64 ma nawet nazwę - Kernal (nie kernel) Natomiast, swój system posiadają też stacje dysków tych komputerów, podobnie jak Spectrumowski Timex FD3000, czy jakoś tak. Stacje więc mogą pracować niezależnie od komputera, do tego stopnia, że komputer zadaje urządzeniu jakieś zadanie, a sam robi swoje, jakby stacji nie było, sprawdza tylko, czy zadanie zostało ukończone. Umożliwia to dzięki temu, np. odtwarzanie sampli i online ich doczytywanie, normalnie, transmisja z dyskiem opiera się o przerwania i bez odpowiedniego oprogramowania tejże w tym przypadku, takie doczytywanie było by utrudnione, bądź nawet niemożliwe.
Mało kto wie, że istnieje interfejs, mający kilka wersji, umożliwiający połaczenie stacji dysków Commodore z pecetem. Najprostszy interfejs, to prosty kabelek z jednej strony zakończony wtyczką DIN-podobną, do nabycia, z drugiej wtyczką DB25 do portu drukarki LPT, bez żadnych dodatkowych elementów, należy tylko unikać (roz)łączania przy włączonych urządzeniach, dwa razy upaliłem tak port w stacji :P Ale naprawa jest banalna - wystarczy wymienić bufor portu, którym jest TTL 74LS14 (można zastosować zwykły 7414, ale może to wtedy przeciążyć magistralę) i stacja ożywa. Są programy, które transferują pliki tam i z powrotem, jednakże najwygodniejszy jest DOSowy program Star Commander, to nieco rozbudowany pod kątem tej stacji klon Volkov-a Commander-a. Przy zastosowaniu specjalnego sterownika, można to odpalić pod systemem z linii NT. Oczywiście, w drugą stronę, są programy, które udają stację dysków i Commodore tak je właśnie widzi. Przy okazji możesz mieć monitorowanie transmisji na porcie, kabel ten sam, tylko DIN wtykasz nie w stację, lecz w Komodę. Jak poszukasz, znajdziesz też program, który uruchomi tak drukarkę komodzianą, znów kabel ten sam. Testowałem to z
10-15 lat temu, nie pamiętam ile dokładnie. Na YT znajdziesz rozmaite filmy z tym, włącznie z modernizacją. Wyszła też całkowicie przebudowana płyta główna do C64, całkiem niedawwno, wyrzucono z niej tylko modulator TV, nie pamiętam, co weszło w zamian, funkcjonalnie komputer jest identyczny i odpala stare programy.Płytę zakłada się zamiast starej, wchodzi do tej samej obudowy... aha, zasilacz ma inny, to mi się przypomniało, stary nie pasuje. I chyba zabrali 9V AC, obecne w starej wersji, potrzebne OIDP chyba do czegoś związanego z drukarką.
Bardzo nieekonomicznie... Komoda 1541, sektory 256 bajtów, dwa pierwsze linkują do następnego, gdy pierwszy zerowy, to drugi podaje, ile bajtów wchodzi do pliku.
Przypuszczam, że wątpię, by tak było. wydaje mi się, że to idzie na poziomie plików, a nie struktury systemu plików. Że na karcie zapisany jest obraz dysku i wszelkie operacje opierają się o obraz dysku. Natomiast plik-za-plikiem, to tzw. plik taśmy, złożony po prostu z kolejnych plików, jeden za drugim, ja macałem tylko transfer na odcinku stacja dysków-katalog w komputerze, paczka może mieć do 500 plików i może zawierać pliki normalnie nie mieszczące się w pamięci, czy na dysku C64, np. 3-megabajtowe, wchodzą jak nóż w masło. Taka prymitywna wersja TAR-a. Normalny TAR też jest.
W najnowszym programie Star Commander, miała pojawić się możliwość obsługi obrazów bezpośrednio w formacie Group Coded Recording, w jakim tradycyjnie zapisuje stacja C64, gdzie OIDP, nie może być przerwy dłuższej, niż 4 bity zerowe, jeśli, to wtrącana jest jedynka, trochę jak w Packet-Radio. Ale na razie nie ma. Nadmienię przy okazji, że stacja 1570 (jednonapędowa jednostronna) i 1571 (jednonapędowa dwustronna) i 1572 (dwunapędowa, czytałem, ale nigdy nie widziałem), mają, dzięki rozbudowanemu kontrolerowi, możliwość pracy z kodowaniem MFM, dzięki czemu umieją, po przestawieniu w odpowiedni tryb, odczytać (zapisać też OIDP) dyskietki 360 kB formatowane i zapisane w pececie (1570 raczej nie obie strony, ale formatowano w pecetach jednostronnie też).
Użytkownik "HF5BS" napisał w wiadomości grup dyskusyjnych:nq1jtu$kfn$ snipped-for-privacy@node2.news.atman.pl... Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości
Z tym, ze ten z Atari, to nie znal sie na dyskach wcale. Mial ekran, klawiature, magnetofon chyba ... i budowe umozliwiajaca rozszerzanie systemu o inne urzadzenia.
W Atari (8-bit) raczej nie, ona prosta byla.
Akurat ekonomia podobna, jak w innych rozwiazaniach. Zawsze gdzies musisz pamietac numer nastepnego bloku, i zyskac mozesz tylko zwiekszajac dlugosc bloku (ale wtedy tracisz na koncowkach). Wada Atari byla ta liczba 125 - taka jakas nieokragla :-)
Mozliwe, ale to utrudnia wspolprace z pecetem. Trzeba pisac program obslugujacy ten wirtualny system plikow na windows/dos/linux/itp. Az by sie prosiło zrobic to inaczej, szczegolnie ze architektura od strony Atari chyba nie przeszkadza.
I to wlasnie mnie martwi - pelna emulacja dosc skomplikowana bedzie ...
Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:57c45f30$0$639$ snipped-for-privacy@news.neostrada.pl...
Ale tez różne Atarynki były, zdaje mi się, że najbardziej wymagająca była
2600, gdzie programista naprawdę musiał się postarać, by przeskoczyć ograniczenia sprzętu, nie wiem, czy nie trudniejsze, niż ZX80/81...?
(stacja dysków)
Ale za to dość szybka, ZTCP 19200 bps, bobec ok. 4k oryginalnej Commodore. Za to C64, 1541, z dopałem, uzyskiwały do ok. 0.1 Mbps, ok. 25-razy przyspieczenie do oryginału, tzw. tryb warp, realizowany programowo)
Commodore miało też, 254, dupawo się to liczyło.
To jest tak prosty system, że nawet XT powinien sobie poradzić. Na pewno dawał już radę 286, bo spinałem ze stacją, poniżej nie chce odpalać Star Commander. Więc wysiłek systemu na zrealizowanie tego wirtualnego systemu jest praktycznie żaden. Hehe... i ma (1541) jedną rzecz, którą, czytając w opisie, znalazłem dopiero w ReFS...
C64 z FATem sobie nie poradzi? Poradzi. C128 tym bardziej, bo ma ok. 60 kB na program i niezależnie, drugie 64 na zmienne. Spokojnie ci napiszę program jadący w obie strony. Tylko w odróżnieniu od dzisiejszych wielotonowych programów typu Pasjans, tu trzeba by się naprawdę postarać, programując. Ja się pewnych rzeczy nauczyłem, przez kilka lat mając VIC20 z 3.5kB pamięci. Tak sobie teraz pomarzyłem, aby pobawic się klawiaturą dynamiczną, nie wiem, czy prócz VIC20, C64, C128, inne kompy to miały, bardzo przydatna rzecz, w oparciu o to napisałem 3, albo 4-linijkowy programik, wczytujący się do pamięci z listingu tekstowego z pliku, a następnie, po pomyslnym wczytaniu, kasujący się bez śladu, by nie przeszkadzać wczytanemu programowi. To i FAT na C64 zrobię.
Znał się doskonale. Przypomne ze OS Atari był dość wybitny i bazował na wielu współczesnych mu rozwiązaniach profesjonalnych. Np. na IOCB:
formatting link
Dzis można się z tego smiac, ale przynajmniej probowano zrobić namiastkę elastycznego systemu.
Atari bez żadnych problemów obsługuje stacje dysków przez specjalny interfejs który jest dostepny w tym samym gnieździe co wkładasz magnetofon. DOS jest czytany ze stacji w momencie bootowania. Efekt jest taki że całość chodzi w sposób przezroczysty i czujesz się podobnie jak na kazdym innym systemie z tamtych lat, w szczegolności CP/M. DOSy Atari są bardzo rozbudowane i mają wiele profesjonalnych fuknkcji spotykanych wtedy we wczesnych latach PC. Niestety procesor nie ten co w ZX Spectrum więc oprogramowania z CP/M nie ma.
To czy stacja potrafi czytac jakieś niestandardowe formaty zalezy tylko od firmware stacji i we wszystkich mi znanych było ono wymienne przez DOS, przez co przyspieszano komunikację i zmieniano parametry fizyczne dyskietek jesli to było konieczne.
formatting link
Miała własny CPU.
Najpopularniejszy model:
formatting link
Ogólnie rozwiązania technicze w obu komputerach (C64/Atari) były wręcz identyczne. Atari zostało zaprojektowane wcześniej więc miało pewne ograniczenia techonologiczne w krzemie jak pixelclock, ale ogólnie to ten sam komputer z bardzo podobnym systemem operacyjnym i podobnymi rozwiązaniami sprzetowymi komunikacji ze światem. Atari ma zdecydowanie bardziej skomplikowany hardware od C64 z powodu próby wykorzystania pełnej mocy 6502. W C64 poszli na łatwiznę ale mieli ładniejsze sprites ;)
Atari zleca stacji odczyt jakiegośtam sektora i czeka aż spłyną dane. Wszystkie emulatory stacji po prostu reagują na polecenie i wysylają paczkę. Co najwyżej doskonalono techniki przesyłania bajtów przez te kilka drutów, z całkiem niezłym skutkiem.
Wlasnie o to chodzi - jesli mnie skleroza nie myli, to uzywales np OPEN#1,12,0,"D:TEST" .... i ROM w Atari nie zawieral programu do obslugi dysku.
Ale ... zawieral program, ktory przy starcie systemu sprawdzal obecnosc napedu i bootowal DOS zabootowany DOS podlaczal sie gdzies tam do "systemu z rom" w te IOCB i obslugiwal pliki na dyskach.
formatting link
Owszem, to robilo wrazenie ... jak sie o tym pierwszy raz czytalo. Bo o ile pamietam, to chcialem to kiedys wykorzystac ... i trudnosci sie pietrzyly. Do niczego sie to nie nadawalo.
No wlasnie - ten sam interfejs, ten sam port szeregowy (umiarkowanie szybki - 19200 chyba z dyskami bylo), multipleks jakis trzeba bylo kombinowac. Pewnie dalo sie dosc prosto - wsadzic malego atmelka ... ale atmelkow jeszcze nie robili. A jak mialem robic odpowiedni modul mikroprocesorowy, to mozna sie bylo zastanowic po to co Atari :-)
O, tu jest dobry opis jak dodac port szeregowy i rownolegly do "systemu"
formatting link
Commodore 128 - tam zdaje sie byl CP/M ... i dwa procesory :-)
Juz nie pamietam, ale to nie tylko kwestia firmware, ale tez hardware. W pececie wstawili intel 8272/uPD765, i obslugiwal tylko kilka formatow. Commodore (tylko C64 czy Amiga) mial jakis WD, ktory jakos bardziej elastyczny byl.
Miala, ale on nadal byl mocno ograniczony.
O wlasnie. Pamieci cale 256 bajtow (6810 i 6532). 128 potrzebne na bufor sektora. Nie wgrasz tam zadnego nowego firmware, bo po prostu nie ma gdzie. Program w ROM, chyba nawet nie ma takiej opcji, aby firmware wgrac.
To w C64 sie wgrywalo do (RAM) stacji nowy program, ktory podnosil predkosc transmisji z komputerem, bo bez niego byla zenujaco mala ;-)
Kontroler floppy tez niby WD, ale wydaje mi sie ze 2793 jakos mniej elastyczny byl.
Usiluje sobie przypomniec jak to z tym MFM bylo - po schemacie widac, ze mogl byc wybierany (pin DDEN/). Ale pamietam ze byl jakis problem ... czy nie taki, ze pecet potrafil w MFM minimum 256 bajtowy sektor obsluzyc, a 128B to tylko w trybie FM, ktory mial niedostepny ?
No nie, pewne ogolne podobienstwa byly, ale szczegoly juz sporo inne.
Czy tak bardziej skomplikowany ... oba juz wykorzystywaly specjalizowane uklady.
Chocby ten przyklad :-) C64 o ile pamietam to mialo jednak ladniejsza grafike i ladniejsza muzyke.
Masz racje, pomylilo mi sie cos. Stacja istotnie byla prosta, reszte zalatwial DOS.
Niby mozna by napisac wlasny DOS, ktory by FAT32 obsluzyl i zabootowac go do komputera :-)
formatting link
Chodzi po glowie jeszcze jeden malutki DOSik, ktory sluzyl tylko do ladowania gier. Jak to sie nazywalo ... NDOS ?
Użytkownik "HF5BS" napisał w wiadomości grup dyskusyjnych:nq1rg6$rqk$ snipped-for-privacy@node2.news.atman.pl... Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości
XT to bez problemu, ale pytanie brzmi, czy potrafisz napisac system plikow pod windows 10 :-)
Bo ze Atari sobie z karta poradzi to jedno, ale chcialoby sie jeszcze, aby pecet sobie poradzil.
Oczywiscie mozna jakos obejsc bez pisania drivera FS, ale to mniej wygodne bedzie.
Fat na C64 zrobisz, ale kilka ambitnych programow na oryginalna stacje dzialac juz nie bedzie. Co prawda - chyba nie ma potrzeby, aby dzialaly.
Atari miało specjalnmy system rozszezania IOCB w sposób automatyczny. Nigdy nie miałem żadnej "wypasionej" zabawki, ale wiele systemów turbo z okolic Blizzard (np. cartridge Phoenix autorstwa Hurk[a]) instalowało w systemie urzadzenie T: co pozwalalo wszystkim programom czytać i pisać w turbo blizzard.
T2000 było bardziej prymitywne ale też coś takiego mieli.
Czemu kombinować? Atari natywnie obsługiwało ileśtam stacji dysków podpietych jedna za drugą daisy chain.
Robili 8051. Pierwszy widziany przeze mnie emulator stacji dysków to właśnie 8051 w jakimś niemieckim czasopismie. Gdzieś tam była wzmianka o wcześniejszym na Z80.
Oba tak samo kiepskie. C128 mial konkurencję ze strony Amigi i prawde mówiąc była to dominacja a nie konkurencja.
Oczywiscieze hardware tez, ale zmiana formatu dysku ogólnie w stacjach programowalnych była praktykowana. Ja jestem magnetofonowiec. Nie byłem przy tym kiedy to robili.
Firmware miało kilkadziesiąt bajtów. Istniał specjalny rozkaz w stacji "załaduj to do ram i skocz". Bajtów nie trzeba gromadzić, można je wysyłać jak lecą w formacie raw bez dekodowania.
To samo na atari.
Niestety nie miałem przyjemności (watpliwej) programować kontroler. Jedyny kontroler w którym robilem machloje to Amigowy, ale gdzie by człek pamiętał takie detale.
Atari w bardzo skomplikowany sposób haltowało CPU poprzed dodatkowe układy co pozwalalo osiągnąc max prędkośc cpu i antica (potem wyprodukowali specjalna wersję 6502 "Sally" z tymi układami w środku). W C64 poszli na latwizne, zwolnili cpu i pozwolili mu na zatrzymywanie się z własnej woli z lini HALT (która zatrzymywała tylko w okreslonych okolicznościach). C64 był konstrukcyjnie dużo prostszy co nie znaczy ze gorszy bo "gry miał lepsze". Oba wykorzystywały własne układy ASIC, w atari było ich więcej.
SID byl uważany za układ bardzo dobry i dużo w tym racji choć nie prakuje zwolenników Pokey z jego specyficznym "czystym" dziwiękiem. Obecnie żadna róznica bo ludzie instalują SIDa w Atari i Pokey w C64. C64 miał ładniejsze spritey (hires lub lores kolor) i więcej ich co miało związek z wyższym pixelclock w VIC-II a to znowu z postępem w produkcji układow. Atari miało natomiast znacznie bardziej skomplikowany układ graficzny z prymitywnym ale zawsze "koprocesorem" który potem przerodził się w Coppera z Amigi. Tak czy inaczej oba to prawie identyczna konstrukcja hardwareowa z detalami w postaci obsługi grafiki.
Czas poszedł do przodu i z C64 zrobiło się Atari ST a z Atari XL zrobiła się Amiga :D Wszystkie 4 na moim biurku, choć ST chwilowo zniknął ale wroci :D
Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:57c4923e$0$12551$ snipped-for-privacy@news.neostrada.pl...
Ja myślę, że nie powinno być problemu, najmniejszego. Chyba, że programista zaraz otoczy się pierdylionem kompletnie niepotrzebnych bibliotek, gdzie kompilat programu
10 k=0
20 k=k+1
30 PRINT k;
40 GOTO 20 Będzie mieć pół mega z kawałkiem, bo kompilator zupełnie niepotrzebnie skompiluje np. transfer dyskowy, czy badanie zakresu wartości zmiennych... i tak się wywali, jak przekroczy zakres.
Bo ja wiem? Skoro z Komodą sobie radzi, to z Atarynką nie da rady?
Jak wspomniałem, wydaje mi się to tak proste, że pisanie osobno sterownika pod peceta, będzie zwyczajnie, nieekonomiczne. Powinno się to, uważam, dać zamknąć w samym programie. Aha... chodzi ci o coś w rodzaju TSR? Nie jest to aby przedszkole programowania? Fakt, tu sterownik, ale nie w postaci takiej, jak komp robi NTFS, czy FAT, tylko jako osobny program, który od systemu przejmuje (a nie system tym obciąży) wywołania transferu dysku i podstawia to, o co się poprosi.
Zastanawiałem się czasem, czy nie da się załatwić, że pisze się dedykowany sterownik, umieszcza w pamięci stacji, który sczytuje wartości RAW i takie je przesyła do komputera, co powinno, kosztem wydajności, umożliwić odczyt dyskietek FAT także w stacjach nie przystosowanych do tego... A komputer sobie poskłada surowe dane w jakąś całość. Zastanawiałem się też, czy da się w drugą stronę, dyskietkę C64/Atari w podobnym podejściu, czyli surowe dane, odczytać w napędzie PC. Ale ZTCW, to nie takie najprostsze, bo kompy sobie poradzą, ale napędy niekoniecznie. Mimo chyba takiego samego nawet skoku głowic. Czy ambitne zadziała... Zależy pewnie jak ambitne i co zechce pomacać.
No, chyba nie ma. Choć jak ktoś się porządnie uprze i zhakuje pewne tematy...?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.