CommentTime10 Jul 2026 20:31 (45 minut temu) zmieniony
Wydłubałem coś całkiem fajnego, żadne rocket science ale zaczyna się przydawać więc opisuję.
Cel ćwiczenia: ==============
- usprawnienie pisania kodu w APX fig-Forth pod VS Code i innymi IDE
- wywoływanie kompilacji na emulatorze Atari
- pozbycie się nawyku duplikowania kodu, ujednolicenie bibliotek, z których korzystam i "includowanie" ich z jednego miejsca w nowo pisanym kodzie
- zabawa z bash i LLM
Problemy do rozwiązania: ========================
- wczesne Forthy na Atari (w tym mój "ulubiony" APX) nie ogarniają plików tylko "ekrany" - na dyskietce namalowane są ciągi znakowe, umownie podzielone na linijki i "strony", wciągane przez język przy pomocy własnych metod (np. polecenie LOAD, poprzedzonego numerem "ekranu"), bez użycia Atari DOS; konwersja plików z PC do "ekranów" jest możliwa ale nie do końca banalna
- musimy uruchomić Fortha z jednej dyskietki i poprosić go o kompilację źródeł z drugiej
- musimy mieć jakiś sensowny feedback z kompilacji
Podejście: ==========
0. Wszelkie zgromadzone przeze mnie znane i lubiane dodatki, biblioteki, przydasie i bajery mam na PC w katalogach kontrolowanych przez Gita, podzielone na grupy (zarządzanie słownikiem, zarządzanie zmiennymi, debugowanie itp)
1. Skrypt w bashu (preproc.sh - podziękowania dla Copilota) operuje na głównym pliku źródłowym nowo tworzonej aplikacji (nazwijmy go... "main")
2. W "main" piszę właściwą aplikację, wstawiając referencje do innych plików na zasadzie podobnej do "#include" w C lub "import" w Pythonie
3. Skrypt preproc.sh wyszukuje te pliki (też rekurencyjnie) i składa w jeden plik wyjściowy
4. Następny skrypt (txt2scr.sh) przetwarza tekstowy plik z poprzedniego kroku w ATR, rozumiany przez fig-Forth jako obraz dyskietki ze źródłami ("ekranami"); źródła są "cięte" na "ekrany" przy pomocy polecenia "-->"
5. Ostatni skrypt odpala Altirrę, przekazując jako parametry:
- pierwszy obraz dyskietki: z podstawowym Forthem, dość "gołym" ale zdolnym do kompilacji (np. ma wkompilowany asembler i może mieć opcjonalnie np. dekompilator oraz narzędzia do przeglądania i przeszukiwania "ekranów")
- drugi obraz dyskietki: zbudowany w poprzednim kroku (źródła do kompilacji)
- polecenie "DR1 1 LOAD", przechodzące na dyskietę drugą i odpalające kompilację
- końcowym poleceniem na dyskietce ze źródłami może być uruchomienie skompilowanej aplikacji lub testów jednostkowych; można też to pominąć i testować wybrane słowa w interpreterze
6. W przypadku błędów kompilacji możemy wyświetlić miejsce standardowym poleceniem WHERE
7. Pseudo-debugowanie (wyłącznie poleceń stworzonych definicją dwukropkową) możemy uzyskać wpisując w kod źródłowy polecenie || które zawiesza działanie programu i wychodzi "na chwilę" do interpretera (można sprawdzić stos, zmienne, wznowić program itp).
Sprawdzone na Windows z VS Code ale zbliżona metoda działa mi też pod Linuxem (AntiX + Geany IDE + atari800). Tam jest nawet fajny feedback z Atari800 (logowanie na PC informacji o kompilacji, wyplutej przez emulator).
