Niemal od początku serwisu Stare Programy użytkownicy tworzyli nietypowe modyfikacje systemów, będące przykładowo paczkami uaktualnień (Delta City) lub kompresujące system do niezwykle niskich rozmiarów (Windows 95 5MB project by MrMateczko). W moim przypadku za cel objąłem sobie zmniejszenie rozmiaru tak, żeby system zmieścił się na dyskietce ED (2.88MB), co jest maksymalną wielkością wspieraną przez SeaBIOS, a co za tym idzie - projekt coreboot. Celem całego projektu było otrzymanie laptopa, który bez dysku byłby wstanie uruchomić okienkowy system operacyjny bez kompromisów używalności.

Projekt zawiera podstawowe aplikacje i gry, takie jak...

  • Notatnik
  • Kalkulator
  • Write
  • Paintbrush
  • Sound Recorder
  • Calmira (zastępująca domyślny Program Manager)
  • Miny
  • SkiFree
  • Tetris
  • LifeGenesis
  • JezzBall
  • Reversi
  • W pełni funkcjonalny Visual Basic 3.0 (bo czemu nie!)

... i więcej! :3

LifeGenesis

Przygotowanie sprzętu

Cały projekt zacząłem od rozkręcenia laptopa, którym w tym przypadku był ThinkPad X200. Chip BIOSu znajduje się pod palmrestem, więc przy w pełni skręconym laptopie od flasha nieoficjalnego BIOSu dzielą nas tylko cztery śrubki. Z braku odpowiedniego klipsa do kostki ROM przylutowałem kable z drugiej strony podpięte do Raspberry Pi, które w tym przypadku służyło jako programator SPI. Używając programu flashrom nagrałem wcześniej spreparowany ROM. Po nagraniu odłączyłem programator i włączyłem komputer. Zostałem przywitany ekranem librebootowego GRUBa (bo to nagrałem jako obraz testowy), który po chwili przeszedł w ładowanie mojego systemu z dysku.

Domyślny payload libreboota na rozłożonym X200

Problemy z blobami

Coreboot w swoim założeniu używa jak największej ilości wolnego oprogramowania. Niewolne części firmware'u do kart sieciowych lub grafiki są często zastępowane wolnymi implementacjami, dzięki czemu dostajemy sprzęt, w którym praktycznie nigdzie nie ma części niewolnych. Nie inaczej jest z X200, gdzie dzięki staraniom społeczności nie są wymagane żadne elementy niewolne. Problem pojawia się, kiedy chcemy użyć starszego systemu, który nie umie poprawnie zainicjalizować danego urządzenia, przykładowo z powodu generycznych sterowników. W przypadku Windowsa 3.1 problem pojawia się przy inicjalizacji karty graficznej, gdzie libgfxinit nie potrafi uruchomić trybu graficznego. Rozwiązaniem było użycie VGA Option ROM'a wypakowanego z oryginalnego BIOSu, co było niezwykle trudne przez to, że X200 ma nietypowo ułożone elementy w ROMie. Popularne narzędzia okazały się bezradne (próbowałem UEFITool oraz bios_extract, drugiemu udało się co najwyżej wypakować bezużyteczny dla mnie w tym przypadku mikrokod). Finalnie, wypakowałem pliki .FL1 i .FL2 z ISO z uaktualnieniem i podmieniłem metodą przetestowaną z X201, opisaną jako "nowy" format zapisu ("nowy", bo w T420 czy X230 UEFITool po prostu działa, a formaty rzekomo są takie same). Wypakowany VGA ROM użyłem przy make menuconfig do stworzenia obrazu coreboota.

Testowa instalacja

Początkowo spróbowałem Windowsa zainstalowanego na pendrive, który po spreparowaniu ROMa z odpowiednim sposobem inicjalizacji VGA wstał bez żadnego problemu. Dograłem wtedy spatchowane wcześniej drivery SVGA dzięki którym system wyświetla się we "wspaniałej" rozdzielczości 1024x768 i 256 kolorach. Ponieważ karta dźwiękowa nie jest zgodna ze standardem AC'97 ani nie posiada innych driverów pod jakiekolwiek stare systemy operacyjne, dźwięk opiera się na sterowniku SPEAKER.DRV, dzięki któremu możemy usłyszeć cokolwiek, nawet jeśli w bardzo niskiej jakości. Myślałem również o dołączeniu sterowników do karty sieciowej - tutaj z pomocą przychodzi Intel, który dostarcza oficjalne wsparcie tej karty pod DOSem - ale koniec końców uznałem, że nie zmieściłbym w paczce niczego oprócz stacka TCP-IP.

Transfer danych

O ile to wydanie to zwykły obraz dyskietki, o tyle taki obraz wgrany do ROMa z corebootem przestaje być zapisywalny. Pojawia się jednocześnie problem przenoszenia plików z i do systemu, który można rozwiązać na kilka sposobów. Oczywista wydaje się mała partycja FAT na początku dysku, ale z nieznanych mi przyczyn crashuje to windowsa. Alternatywnie możemy więc użyć pendrive - jeśli będzie obecny przy bootowaniu, to zobaczymy go jako dysk C:, jeśli włożymy go po załadowaniu DOSa i załadujemy drivery (skrypt USB.BAT z R:\windows\usb), będzie widoczny jako dysk S:. Niestety, w żadnym przypadku dysk nie jest poprawnie odczytywany przez Windowsa - konieczne jest kopiowanie plików zapisanych wcześniej w ramdysku do pamięci USB bezpośrednio w DOSie.

*shrug*

Minimalizacja i kompresja

Samo zmniejszenie wielkości systemu nie było problematyczne - można użyć plików z archiwum MINI.CAB wypakowanego z płyty instalacyjnej Windowsa 95, w internecie dostępne są również poradniki jak dokonać tego z plików oryginalnego Windowsa 3.1. Sam wzorowałem się na tym poradniku z własnymi usprawnieniami.

Po wyborze software'u (który tak na prawdę trwał kilka dni, ale to szczegół) przyszedł czas na wybór pakera. Początkowo myślałem o samym zip -9, dzięki któremu pliki windowsa zmniejszają się o około 35-55%, ale ponieważ projekt rozrósł się do niespełna 7MB (!), wybrałem xz -e jako paker (-9 wymaga większej ilości pamięci, -e to opcja "extreme" która tylko dłużej wykonuje się przy pakowaniu) oraz zip -0 jako archiwizator. Dzięki temu, mogłem spakować samo xz, co zaoszczędziło mi około 150KB przy compression ratio 50%. Oprócz pakerów, potrzebowałem też gdzieś wypakować archiwa, do czego użyłem XMSDSK.EXE (jest lepsze od klasycznego RAMDRIVE.SYS, bo pozwala wybrać m.in litere dysku). Końcowo, wszystkie niepakowalne pliki zajmują około 300KB, co na obrazie dyskietki 2.88M zostawia około 2.5M na spakowany system. W tym miejscu warto wspomnieć, że wcześniej już linkowany Windows 95 5MB Project by MrMateczko używając moich metod mógłby się zmieścić w mniej niż 2MB!

Ekran początkowy, wersja bez animców

Download