Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorbartgo
   • CommentTime22 Apr 2023 01:28

    
   Jak wiecie, bawię się VolksForthem ale czytam też o innych implementacjach i trochę eksperymentuję.
   
   Zajrzałem do plików ATR z grami Pana R. Pantoły. Jak ktoś już chyba kiedyś wspomniał, siedzą w tych grach ciągi znaków "fig-Forth 1.1" wskazując na APX Forth'a (Extended Fig-Forth'a?), chyba najbardziej popularnego (występującego w kilku wersjach) i bardzo dobrze udokumentowanego chociaż szeroko krytykowanego.
   
   Uwaga na marginesie, bardzo często ten Fig-Forth jest rozpowszechniany w uszkodzonym pliku ATR. Przy listowaniu ekranów przy pomocy np. 20 60 INDEX można zobaczyć powtórzone nawiasy kończące komentarz i inne babole (pewno wynikające z błędów na dyskietce). Skutek jest taki, że nie wgramy zepsutych ekranów poleceniem LOAD. Gdzieś w necie jest artykuł kogoś kto to naprawił (na podstawie dokumentacji) - poprawiony obraz też istnieje. Ponieważ jednak obcowanie ludzi z Forth (jak mi się wydaje) zazwyczaj kończy się na tworzeniu słów od razu kompilowanych do słownika a praca z ekranami to dalszy etap, błąd nie przeszkadza na początkowym etapie zapoznawania się całością i dopiero później blokuje nieświadomego amatora.
   
   Jak rozumiem, Gra-Forth wspomniany w czołówce jednej z gier RP to oryginalnie ten sam siermiężny Fig-Forth, rozbudowany przez samego Autora do frameworka do tworzenia gier (artykuły w TA i wywiady sugerują gigantyczne modyfikacje, co nie jest przesadzone widząc co język ma w standardzie).
   
   Kompilacja, o której wspominiał Autor w wywiadach, nie jest kompilacją do pliku wykonywalnego w kodzie maszynowym ale według mnie głównie wygenerowaniem ze źródeł (oryginalnie przechowywanych na "ekranach" Forth w postaci ATASCII) słownika / słowników i ustawieniem słowa uruchamiającego program jako domyślnego przy uruchamianiu środowiska. Plus co najmniej jednego dodatkowego genialnego zabezpieczenia które praktycznie nie jest do obejścia dla amatora chcącego bezczelnie się gapić w komercyjny kod.
   
   Nie zrobimy tego tutaj (wolałbym z Autorem napić sie herbaty niż rozmawiać w sądzie) bo nie umiemy... coś jednak pokażę, a wszystko w celach naukowo-archiwalnych, mam nadzieję że Autor mi wybaczy. Nie usprawiedliwia mnie fakt, że jechałem w latach 90-tych z warszawskiego Ursynowa do L. K. Avalon (a może to była redakcja Tajemnic Atari?) na Pradze żeby kupić AD. 2044 na kasecie, może okolicznością łagodzącą będzie pęd do wiedzy.
   
   Jak to opisał Cas, sprawa automatycznego uruchamiania wybranego słowa jest prosta:
   
   ->link<-
   
   Za słowem ABORT jest umieszczony jakiś rodzaj skoku do słowa wywoływanego jako pierwsze i można je podmienić.
   
   ```
   ' MYPROGRAM CFA ' ABORT 4 + !
   
   ```
   
   Robi właśnie to, szuka adresu odpalenia kodu naszej aplikacji i wbija go w miejscu gdzie oryginalnie zgłasza się prompt. I cyk, boot dyskietki odpala słowo które leci dalej z koksem. Nikt nawet nie musi wiedzieć że pod spodem jest faktyczny Forth, gotowy do pracy, co da się udowodnić.
   
   Na dyskietkach z grami RP nie ma źródeł ale są słowniki - a tam słowa, gotowe do wykonania. Które można, przy pomocy normalnie używanych słów Forth-a o znanej definicji, zdekompilować do w miarę czytelnego (choć pozbawionego wcięć i komentarzy) kodu - co najlepsze, do kodu Forth ale nie maszynowego! Proszę się jednak nie ekscytować tak do końca...
   
   Autor bardzo sprytnie zadbał o zamazanie nazw słów (własnych oraz domyślnego słownika), pozostawiając tylko adresy, którymi słowa się ze sobą spinają.
   
   Eksperyment. Moje narzędzia - emulator Atari800, edytor Memo Pad.exe (wyświetla ATASCII), HxD Portable (edycja pliku binarnego).
   
   Porównanie okolic słowa ABORT pokazuje dwie rzeczy:
   1) nazwy słów są zamazane zerem, pozostaje tylko ostatnia litera w inwersie oraz reszta słowa (adres skoku albo magia w asemblerze)
   2) kawałek za słowem ABORT faktycznie jest kilka bajtów różniących się między oryginalnym Forth a grą
   
   Kilka prób podmiany adresu i działa, z dyskietki AD 2044 zgłasza się czarny ekran a po resecie znajomy prompt Forth'a. Ale nie działa praktycznie żadne słowo Forth - bo nie mają one już nazw. Porównując charakterystyczne fragmenty kodu, przywracam nazwę VLIST i udowadniam że są tu słowa Autora, co prawda z zamazanymi nazwami ale przywracając JAKIEŚ nazwy w edytorze binarnym można je uruchamiać. COŚ będą robić...
   
   Nie da się niestety łatwo uruchomić ze słownika samej gry, pewno trzeba by rozpoznać słowa inicjujące zmienne i tryb graficzny. Słowa najświeższe są związane z zapisywaniem gry na dysku i obfuskacją.
   
   Pewno możnaby pracowicie odtworzyć wszystkie słowa podstawowego Forth (porównując bajty z plikem APX) i potem budować w górę słowa. Kilkadziesiąt godzin a efekt słaby (następne kilkadziesiąt godzin do zrozumienia co autor miał na myśli... zakładając, że znamy asembler i architekturę).
   
   Koniec.

   • ff-delta.JPG
     
     
     
     
2. • 2: CommentAuthorbartgo
   • CommentTime22 Apr 2023 01:29

    
   Efekt wykonania VLIST:

   • vlist.png
     
     
     
     
3. • 3:
      
     CommentAuthorKaz
   • CommentTime30 Apr 2023 00:28

    

   bartgo:

   chyba najbardziej popularnego (występującego w kilku wersjach) i bardzo dobrze udokumentowanego chociaż szeroko krytykowanego.

   
   
   Krytykowany za powolność, ale za to jest ustandaryzowany i działa na wielu platformach.
   
   

   bartgo:

   Jak rozumiem, Gra-Forth wspomniany w czołówce jednej z gier RP to oryginalnie ten sam siermiężny Fig-Forth, rozbudowany przez samego Autora do frameworka do tworzenia gier (artykuły w TA i wywiady sugerują gigantyczne modyfikacje, co nie jest przesadzone widząc co język ma w standardzie).

   
   
   W anglojęzycznych źródłach znalazłem informacje o Game-Forth, więc sądząc po nazwie można podejrzewać, że na tej wersji bazował pan Roland. Zapewne modyfikował sobie tę ukierunkowaną na tworzenie gier implementację.
   
   

   bartgo:

   jechałem w latach 90-tych z warszawskiego Ursynowa do L. K. Avalon (a może to była redakcja Tajemnic Atari?) na Pradze żeby kupić AD. 2044 na kasecie, może okolicznością łagodzącą będzie pęd do wiedzy.

   
   
   Siedziba L.K.Avalon i redakcja TA znajdowała się w Rzeszowie, w jednym budynku (choć na różnych piętrach), więc to mógł być co najwyżej oddział. A nie pomyliłeś z Mirage, który też dystrybuował programy L.K.Avalon?
   
   

   bartgo:

   Autor bardzo sprytnie zadbał o zamazanie nazw słów (...)

   
   
   Bartku, świetne śledztwo, gratuluję dociekliwości!
4. • 4: CommentAuthorDope
   • CommentTime12 May 2023 09:31

    
   Na Pragę to mogłeś jeździć na Generała Abrahama 4, do Studio Komputerowego "AS" (późniejszego Mirage). Ale to tak trochę na wyrost, bo na Ursynowie AD 2044 można było kupić i w Batmarze na Szolc-Rogozińskiego i na Koncertowej. :) To były chyba jedyne sklepy z oryginałami w okolicy w tamtych czasach, ale asortyment miały dobry i właściciele sprowadzali to czego akurat nie było a klient chciał.
5. • 5: CommentAuthorbartgo
   • CommentTime12 May 2023 17:49

    
   Ah, a więc był to As lub Mirage, na pewno było to na Abrahama. Pamięć płata figle, nie pamiętam żadnego innego miejsca kupna oryginalnych polskich kaset (miałem/mam około 10). Na Koncertowej albo raczej na Stokłosach było "studio", stamtąd kojarzę tylko "piraty".
   
   Fig-Forth był faktycznie jakimś standardem i do tego public domain (!). Próbuję przenieść do niego swoją niby-grę z VolksForth i pomimo wielkiego "czaru" całego środowiska (niektóre ekrany kodu są po prostu piękne w swojej prostocie) ograniczenia widoczne są już na samym początku takiego zadania. Biblioteki słów są niezłe (odpowiedniki grafiki i dźwięku z Basic, przykłady) więc odpada pisanie primitive'ów i ich testy, co robiłem w Volks. Ale tu, pisanie kodu to bardziej "malowanie" go i rozplanowywanie po ekranach, uczucia mam mieszane. W Volks, źródła wyglądają dość współcześnie, w Fig ograniczenia ekranów wymuszają skrócone nazwy zmiennych i straszne ograniczenia w wykorzystaniu wcięć w kodzie, żeby wykorzystać miejsce na dysku (nie ma łamania linii, wcześnie skończona linijka jest wypełniona do końca spacjami). Wydaje się, że nie sposób zrobić większej aplikacji bez znajomości asemblera oraz wywalenia części domyślnych modułów, w tym edytora. I to chyba robiły firmy wypuszczające klony środowiska, np. ValForth posiada edytor wykorzystujący już edytor ekranowy Atari, pewno da się go sportować. Na YT jest też częściowo napisany ulepszony edytor ekranowy, inny widziałem gdzieś w skanie gazetki. Taką drogą szedł też chyba P. Roland , od początku budując lepszy edytor i inne narzędzia (patrz: TA). Też modyfikuję dyskietkę Fig-a, efekty i porównanie obydwu programów opiszę w późniejszym terminie...
6. • 6:
      
     CommentAuthorKaz
   • CommentTime14 May 2023 10:50

    

   bartgo:

   Ale tu, pisanie kodu to bardziej "malowanie" go i rozplanowywanie po ekranach, uczucia mam mieszane. W Volks, źródła wyglądają dość współcześnie,

   
   
   Zdaje się, że taka była pierwotna idea Fortha, to było inne podejście do programowania i rozwijana w kolejnych implementacjach Fig-Forha (którego na Atari już nie implementowano). Volks to już inne czasy, współczeność, i zabrzmiało w tym co piszesz, jak efekt dopasowania reguł Fortha do bardziej współczesnego sposobu programowania.
7. • 7: CommentAuthornewton
   • CommentTime16 Oct 2026 21:09

    
   Jakiś czas temu utworzyłem repozytorium ze źródłami gier i programów LK Avalon, bazując na archiwalnych .atr-ach z sources.pigwa.net:
   
   ->link<-
   
   Inspirując się tym wątkiem na forum, a także kursem Forth z Tajemnic Atari, postanowiłem wydać trochę tokenów na dekompilację AD2044, Klątwy i Władców Ciemności z powrotem do źródeł w Fig-Forth. Gry dostępne są teraz w repozytorium powyżej.
   
   Moim celem było, aby źródła i inne zasoby (takie jak np. mapy) były jak najłatwiej dostępne z poziomu githuba i współczesnego komputera. Dlatego źródła są w ASCII, grafiki w formacie .png, a wszystkie inne zasoby (jak np. układ poziomów czy hitmapy mówiące gdzie trzeba kliknąć) w formacie tekstowym. Wszystkie te zasoby Python przetwarza na formaty atarowskie i wrzuca na obraz dyskietki. Źródła Fortha kompilowane są przez Fig-Forth, uruchomiony na małej "wirtualce" opartej o bibliotekę py65.devices.mpu6502, stąd też kompilacja nieco trwa.
8. • 8:
      
     CommentAuthorKaz
   • CommentTime16 Oct 2026 22:52

    
   Tak, bardzo dobra i pożyteczna robota. Dzięki.
9. • 9: CommentAuthorbartgo
   • CommentTime20 Oct 2026 11:25 zmieniony

    
   Kilka ciekawostek, które na szybko zauważyłem:
   
   - Kod ma specyficzną składnię przeznaczoną dla zbudowanego w Pythonie kompilatora ("target compiler"? "cross compiler"?), więc bez wcięć i komentarzy ciężko coś tutaj ogarnąć; nie jest jednak źle; przykładowo, "firmowa" dekompilacja (słowo DECOMP z podsłownika DEBUG) jednego ze słów fig-Fortha M* (służącego do mnożenia dwóch liczb ze znakiem):
   
   
HEX DECOMP M*
1FCE OVER
1FD0 OVER
1FD2 XOR
1FD4 >R
1FD6 ABS
1FD8 SWAP
1FDA ABS
1FDC U*
1FDE R>
1FE0 D+-
1FE2 ;S

   
   Podczas gdy w ad2044/src/10-kernel.fth (to jest odtworzona "goła" dyskietka APX Forth, bez dodatków Rolanda) mamy:
   
   
( M* | NFA 1FC7 CFA 1FCC )
( APX fig-FORTH dictionary, same NFA/CFA and link in game )
AT 1FC7
( Saved dictionary header: flags, name bytes, link )
BYTES 8200AAAF1F
DOCOL
t.OVER t.OVER t.XOR t.>R t.ABS t.SWAP t.ABS t.U* t.R> t.D+-
t.;S
AT 1FE4

   
   Widać, że słowo ląduje w tym samym miejscu w pamięci (NFA=1FC7, CFA=1FCC i po nagłówku opisanym w BYTES pierwszy skok do OVER siedzi w 1FCE, czyli w PFA słowa M*) - oraz, że składa się z tych samych "klocków" (OVER, OVER, XOR, bla bla).
   
   - część kodu maszynowego została zdekompilowana do *własnego* asemblera (zrobionego przez LLM?), przykładowo polecenie JSR w typowym asemblerze Fortha byłoby zapisane w stylu: "E465 JSR,", gdy tymczasem dekompilat wygenerował i obsługuje bardziej tradycyjnę składnię (bez RPN): "JSR.ABS E465"; oczywiście dla wynikowego kodu maszynowego to żadna różnica
   
   Z mojego punktu widzenia - ze względów historycznych - oryginalny proces z lat 90-tych oraz narzędzia są ciekawsze od budowy samej gry, ale tutaj wykonana praca jest absolutnie pożyteczna.
10. • 10:
       
      CommentAuthorKaz
    • CommentTime20 Oct 2026 12:12

     
    Czekaj, czy dobrze rozumiem, że wersja zdekompilowana przez Newtona wygląda inaczej niż rzeczywiste źródła? To w takim razie, czy da się te rzeczy połączyć? To znaczy, skoro celem projektu Newtona było:
    
    

    Newton:

    (...) celem było, aby źródła i inne zasoby (takie jak np. mapy) były jak najłatwiej dostępne z poziomu githuba i współczesnego komputera. Dlatego źródła są w ASCII, grafiki w formacie .png, a wszystkie inne zasoby (jak np. układ poziomów czy hitmapy mówiące gdzie trzeba kliknąć) w formacie tekstowym.

    
    
    to czy te materiały nie będące w języku Forth można dodać do rzeczywistych źródeł i dalej się będą kompilować? Czy te materiały wymagają specyficznej, przetworzonej formy, aby być kompilowalne?
11. • 11: CommentAuthorbartgo
    • CommentTime20 Oct 2026 13:57 zmieniony

     
    (post edytowany kilka razy, chyba na razie skończyłem)
    
    Nie testowałem jeszcze kompilacji z plików Newtona, więc to co napiszę to taka... dobrze poinformowana fantazja, poparta kilkoma faktami ale i domysłami.
    
    Jak rozumiem, te "nowe" źródła to efekt dekompilacji gotowego programu (np. A.D. 2044). Gotowy produkt z lat 90-tych miał wewnętrzną strukturę "threaded code" Fortha, więc można odtworzyć jego forthową budowę. Chociaż nazwy poleceń zostały "zamazane" przez Rolanda jako część zabezpieczeń, to pozostały połączenia, po których można rozpoznać strukturę i powiązania między poleceniami (skoki). Znana jest budowa nagłówków "słów" i podstawowy słownik - więc większość informacji jest. Bez oryginalnych źródeł nie da się określić nazw poleceń, ale były często tak krótkie i enigmatyczne, że nie za wiele by to pomogło. Rozplątanie zależności i zbudowanie połączeń brzmi zupełnie wykonalnie (chociaż ekstremalnie męcząco DLA CZŁOWIEKA).
    
    Oczywiście, proces kompilacji na Atari wyglądał zupełnie inaczej, nie sposób z gotowej gry przy pomocy dekompilacji odtworzyć procesu i wszystkich narzędzi (bo nie wchodzą one do produktu). Oryginalnie, tekst i grafika były skompresowane własnymi procedurami oraz umieszczone na dysku we własnym formacie (nie plikowym). Duża część oryginalnego kodu używanego przy kompilacji musiała zająć się czytaniem "bloków" dyskowych, a nie plików, dekompresją, przenoszeniem zasobów... Ta część procesu jest jakoś, hm, wywnioskowana i zmieniona przez LLM podczas kompilacji - aby np. zasoby były brane z plików a lądowały na dysku (ATR) już jako bloki. Nieźle, a właściwie WOW.
    
    Źródła wizualnie wyglądają inaczej u Newtona, są w Forth - ale jakby w narzeczu przeznaczonym do cross-kompilacji (?), celując w konkretne miejsca w pamięci (adresy "słów" i adresy skoków).
    
    Pewno da się podmienić nazwy "słów" z "newtonowskiego" projektu na oryginalne.
    
    Postscriptum - przykład różnicy w składni zdekompilowanej vs oryginalnej:
    
AT 8031
BYTES 830000D0C77F
DOVAR
BYTES 1100010F50414C454E49453D535A4B4F445A4920

AT 804D
BYTES 830000B53180
DOCOL
t.CURRENT-ROOM t.@ t.0=_12DE t.0BRANCH CELL 001D
t.POP-VIEW t.DROP t.ACTION-ARG1@ t.ADD-CURRENT-OBJECT
t.ACTION-ARG2@ t.CURRENT-ROOM t.@ t.OPEN-ROOM-EXIT
t.USE-SCENE-RESOURCES
LIT8 0F t.SOUND-COMMAND!
t.BRANCH CELL 0007
LIT8 13 t.SOUND-COMMAND!
t.REDRAW-CURRENT-VIEW LIT16 FFE2 t.ENERGY t.+!
t.ENERGY t.@ t.1 t.< t.0BRANCH CELL 0008
t.1 t.ENERGY t.!
t.CLEAR-TEXT-AREA t.MSG-SMOKING-HARMFUL t.2+ t.SHOW-MESSAGE t.PRESERVE-MESSAGE-TEXT t.1 t.;S


--- vs ---


#ZP <=TXT PALENIE=SZKODZI"
: &15
#KOM @ 0= IF
P> DROP 1W OB!
2W #KOM @ KIE!
RZ>
% 15 SOUND
ELSE
% 19 SOUND
ENDIF
=OB -30 ENERGIA +!
ENERGIA @ 1 < IF
1 ENERGIA !
ENDIF
CE #ZP 2+ RTXT 0K! 1 ;


    
    I przykład wizualnej różnicy kodu w asemblerze (sens oczywiście ten sam):
    
    

( RUN-VBI1 | NFA 544D CFA 5457 )
( SETVBV deferred-VBI vector $540F, matching the $VBI1 )
( handler )
AT 544D
( Saved dictionary header: flags, name bytes, link )
BYTES 87000000000000B14054
CELL 5459 ( native entry point )
STX.ZP D1 ( 5459 )
LDX.# 54 ( 545B )
LDY.# 0F ( 545D )
LDA.# 07 ( 545F )
JSR.ABS E45C ( 5461 )
LDX.ZP D1 ( 5464 )
JMP.ABS 0F47 ( 5466 )
AT 5469

--- vs ---

CODE RUN-VBI1 XSAVE STX,
$VBI1 1+ LSB-MSB # LDX,
# LDY,
7 # LDA, E45C JSR,
XSAVE LDX, NEXT JMP, C;



    
    Cieszę się, że mogłem chociaż trochę zainspirować taką fajną robotę.
    
    Bardzo dobre zastosowanie dla AI/LLM.