Meatloaf. Stacja dysków w chmurze

Na horyzoncie pojawia się nowy świetny projekt stworzenia urządzenia podłączającego nasze C64 do chmury.

Artykuł napisał i wątek na forum założył nasz kolega z forum Qus. Wielkie dzięki za tak rozbudowany tekst. Zdjęcia pochodzą z tego wątku na forum oraz ze strony autora projektu na Githubiie

Stacje dysków Commodore to chyba sztandarowy przykład na to, kiedy genialny pomysł zderza się z brutalną rzeczywistością korporacyjnego myślenia i zostaje pogrzebany (choć wciąż lekko dychający) pod kupą niedorzecznego szmelcu.

No bo pomyślcie tylko – inne stacje z tamtej epoki były po prostu posłusznymi urządzeniami, którym współczesne komputery mówiły coś w rodzaju: „proszę ustawić głowicę na ścieżce X, sektorze Y i rozpocząć przesyłanie zawartości tegoż sektora”. Nic w tym złego, poza tym oczywiście, że całą logikę obsługi filesystemu zawartego na nośniku trzeba było zaszyć w ROM-ie lub systemie operacyjnym komputera, a to znaczyło mniej dostępnej dla użytkownika pamięci w czasach, gdy procesory potrafiły adresować ledwie 64 kilobajty.

Co zrobić? Cóż najoczywistszym, choć nienajtańszym dla użytkownika rozwiązaniem, było przeniesienie systemu operacyjnego stacji dysków do samej stacji. Ale prawdziwą iskierką geniuszu, wspomnianą na początku, było stworzenie, dziś byśmy powiedzieli, ekosystemu peryferów opartych na szynie i protokole IEC. Po jednym, standardowym kablu można było spiąć ze sobą kilka urządzeń na raz i to urządzeń tak różnych, jak stacja dysków, plotter, czy drukarka! Kto da głowę za to, że to nie IEC zinspirował kogoś do „wymyślenia” USB? Wystarczy zdać sobie sprawę, że protokół IEC implementował de facto architekrurę klient-serwer (sto lat przed tym, jak zaczęła być modna), więc w wypadku Commodore 64 wczytywanie danych z dyskietki było po prostu zapytaniem klienta (komputer) do serwera (urządzenie IEC) w stylu: „hej, urządzenie, prześlij mi strumień pliku ‚gyruss'”, a jakiś tam, kompletnie nieokreślony serwer, po drugiej stronie kabla, albo ten plik znajdywał i przesyłał (sam martwiąc się o to, czy nośnik ma 35 czy 666 ścieżek), albo za pomocą specjalnej abstrakcji protokołu IEC, nazywanej „kanałem”, sygnalizował szczegółowy błąd w formie tekstu. Jeżeli więc masz stację dysków opartą o protokół IEC, to nic absolutnie nie stoi na przeszkodzie, abyś w BASICu V2 poprosił o załadowanie takiej niedorzecznej nazwy:

LOAD"HTTP://GORACEWAREZY.C64/NEWEST/GTA3SA.D64/START",8

Po naciśnięciu RETURN, twój Commodore 64, klient protokołu IEC, wyśle do serwera IEC numer 8 prośbę o powyższy plik, a serwer, w tym wypadku stacja, odpowie po prostu: że plik o takiej nazwie na pewno nie istnieje na dyskietce. I tyle. Ale co jakby taki plik istniał? Nie mówię, że na dyskietce, ale pod wskazanym adresem http? Odpowiedź jest prosta – moglibyśmy wtedy wysłać, bajt po bajcie, poprzez protokół IEC, zawartość tego pliku prosto do C64, który o Internecie nie ma zielonego pojęcia! I to właśnie robi Meatloaf!

Meatloaf, uniwersalne multiurządzenie IEC, powstało jako hobbistyczny projekt Jaime’go „Idolpx”, działając w oparciu o taniutką płytkę ESP8266 (w niedługiej przyszłości, z uwagi na przybieranie projektu na wadze, będzie to ESP32), miał być w założeniu sieciową stacją dysków dla Commodore 64, udostępniającą stronę WWW do konfiguracji i serwer WebDAV, do wrzucania nowych plików, bez konieczności żonglowania kartą SD. Czyli był de facto pomysłowym rozwinięciem najgenialniejszego peryferium wszechczasów do C64 – stacji SD2IEC. Do tego, na tej samej płytce, mamy „standardowy” modem Wi-Fi, dostępny i znany z kilku innych, istniejących już projektów. Widać jak na dłoni, że kiedy Jaime się rozpędzi, trudno go powstrzymać, musi dorzucać ficzery. A ja spiknąłem się z Jaime’m w chwili, kiedy głowił się, jak poszerzyć swój kod o możliwość ładowania plików bezpośrednio z serwerów sieciowych. I tak właśnie dotarliśmy do stanu dzisiejszego, kiedy to Meatloaf umożliwia:

  • skonfigurowanie go jako urządzenia IEC o numerze od 4 do 30 (lub wszyskich ich na raz!), każde może wskazywać na inną ścieżkę abstrakcyjnego filesystemu, o którym za chwilę
  • podłączenie go jako zwykłego modemu Wi-Fi do portu równoległego
  • zarządzanie zawartością wbudowanej pamięci flash (lub karty SD w wypadku ESP32) przez WebDAV.

Główna różnica pomiędzy SD2IEC a Meatloafem jest taka, że ten pierwszy widzi tylko zawartość karty SD, a Meatloaf… całego Internetu! Tak więc, jeżeli skonfigurujecie sobie go jako urządzenie 9 i wydacie polecenie:

LOAD"HTTP://GORACEWAREZY.C64/NEWEST/GTA3SA.D64/START",9

To jeżeli tylko taki plik istnieje pod wskazanym adresem, Meatloaf po protokole IEC dokona jego stramingu prosto do Twojego C64! (nie martw się – jeżeli jesteś jedną z tych osób, która uznaje, że prawidłowe wczytanie pliku zachodzi tylko z prawdziwej stacji dysków, lub w najgorszym wypadku, wiernocykowego emulatora 1541, to także nie ma problemu. Możesz po prostu plik o takiej ścieżce na urządzeniu 9 przekopiować na 8 i wczytując go stamtąd, cieszyć się dyskretnym urokiem najwolniejszej stacji dysków w historii ludzkości, dodajmy, że Jaime planuje implementację pełnej emulacji, od czego, jako osoba poczytalna, stanowczo go odwodzę).

Zaraz zapewne znajdzie się jakiś figlarz i spróbuje wczytać, o taki plik:

HTTP://GORACEWAREZY.C64/MEAGARCHIVES/19 ... .D64/START

gdzie „1984_1998_20GB_EVERYTHINGEVERCREATED.ZIP” jest dwudziestogigabajtowym plikiem ZIP. Czy to sprawi, że Meatloaf zadymi, albo przynajmniej poczciwy C64 napisze nam „?OUT OF MEMORY ERROR” lub „?LOAD ERROR”? Otóż… nie. Do Waszego Commodore 64 zostaną wysłane bajty pliku „START” z obrazu dyskietki „WASTELAND_A.D64” znajdującej się w folderze „GAMES_AZ/W”, który jest zapisany wewnątrz zipa „1984_1998_20GB_EVERYTHINGEVERCREATED.ZIP” leżącego sobie na serwerze „GORACEWAREZY.C64″. Dla Meatloafa zarówno obraz dyskietki jak i np. archiwum ZIP są tylko nazwami folderów, których zawartośc da się wylistować (także z poziomu C64 poprzez LOAD”$”) i ewentualnie wejść głębiej, aby dokopać się do potrzebnego pliku. I proszę też nie myśleć, że ten 20GB zip zostanie gdzieś pobrany i rozpakowany. Nie ma takiej możliwośći! ESP8266 nie stoi z pamięcią jakoś szczególnie lepiej niż C64! 

Jak to możliwe? Odpowiedź jest prosta – Meatloaf działa tylko i wyłącznie na strumieniach. Potrafi otworzyć sobie strumień pliku znajdującego się w zipie, albo pliku wewnątrz obrazu D64, a źródłem każdego z tych plików może być strumień, którego źródłem może być kolejny strumień, a tamtego z kolei inny strumień… itd. Mając taką matrioszkę strumieni, wystarczy przepchnąć do C64 najzewnętrzniejszy z nich, opakowując go w inny strumień, który implementuje zawiłości protokołu IEC i gotowe! 

To oczywiście z kolei znaczy, że jakkolwiek nie uzyskamy nic ciekawego robiąc LOAD”HTTP://GORACEWAREZY.C64/$”, ponieważ sam HTTP nie wspiera listingu plików, tak już wydanie komendy: LOAD”HTTP://GORACEWAREZY.C64/MOJEWAREZY.ZIP/$” zadziała tak, jak się spodziewamy!

Jest jeszcze jedna ciekawa rzecz, którą możemy zrobić ze strumieniami, a mianowicie – konwertować je w locie. Jeżeli za pomocą wedge JiffyDOSu spróbujesz zrzucić na ekran zawartośc takiego pliku:

@T:HTTP://HELP.WEBSITEOS.COM/WEBSITEOS/EXA ... L_PAGE.HTM

to zauważysz, że na ekranie pojawi się zawartość html z właściwymi wielkościami liter, a może nawet parę znaków unicode prawidłowo skonwertowało się do PETSCII? Ta konwersja działa w obie strony, tak więc jeżeli spróbujesz zapiszać plik tekstowy z C64 na Meatloafie w filesystemie innym niż obraz dyskietki, to spora część znaków PETSCII zostanie przekonwertowana do UTF8 i jako taka zapisana w miejscu docelowym!

Jeżeli doczytaliście do tego miejsca, to może pojawiło się Wam w głowie pytanie: skoro Meatloaf potrafi czytać strumienie z byle czego, to czy potrafiłby otworzyć taki strumień na przykład z… websocketu? Bardzo dobre pytanie i odpowiedź na nie brzmi: oczywiście, że tak. Protokół IEC wspiera nazwane strumienie (doprawdy, Commodore zatrudniał ludzi, którzy pomyśleli o wszystkim!), więc jeżeli chciałbyś napisać w BASICu V2, dajmy na to, grę w okręty dla dwóch osób, to po prostu otwórz sobie kanał:

10 OPEN 1,9,1,"WS://NAZWASERWERA.PL/JAKISCOKSET"
20 PRINT#1,"A3"
30 INPUT#1, TR$
40 IF TR$ = "TY ..... !!!" THEN itd.

Czy coś w ten deseń. Jak na dłoni widać, że Meatloaf może nie tylko z łatwością zastąpić zarówno modem jak i stos TCP/IP, ale robi to także w sposób niebywale elegancki, poprzez czyste strumienie, dokładnie tak jak obmyślili twórcy Kernala Commodore!

Ale rozpisałem się, a Meatloaf ma przed sobą jeszcze długą drogę. Wciąż brak na przykłąd większości komend CBM-DOS, nie wspominając o CMD-DOS i naturalnie – najważniejszych – rozszerzeń standardu SD2IEC. Ale kiedy to już będzie gotowe, to kto wie, co jeszcze Jaime wymyśli? Może małą ikonkę „send to Meatloaf” na Twoim telefonie?

qus

Linki

Kanał YT autora: https://www.youtube.com/user/idolpx

Strona projektu: https://meatloaf.cc

Wątek na forum: https://www.c64scene.pl/viewtopic.php?f=2&t=3422

Github: https://github.com/idolpx/meatloaf



Kategorie:Artykuły, hardware

Tagi: , , , , ,

2 replies

  1. Świetne! Czy w +4 też będzie to działać?

    Polubienie

  2. Już doczytałem i wiem, że będzie. Przepraszam za głupie pytanie.

    Polubienie