może kiedyś AI będzie umiało modyfikować istniejące gry :-)

- napisz czwartą część gry Spy vs Spy w kosmosie używając silnik gry SpyvsSpy 2

@xxl pamiętam, że zajmowałeś się sporo portowaniem i budowałeś narzędzia pozwalające ten proces automatyzować.
Polecam zerknąć na "examples" w tym repo Ilmenita, jaką analizę wsteczną pliku xex potrafi zrobić AI.

Powiedziałbym że to na razie pieśń przyszłości, ale może okazać się że smaku nie do końca był wariatem :P

A mówiąc poważnie: LLMy działają na kontekstach. Kontekst to n tokenów. Obecnie, najpopularniejsze podejście to że token to jedno niewielkie słowo albo 'sylaba' (kilka znaków, ale niekoniecznie sylaba w rozumieniu gramatyki). Na ten moment w tym kontekście musiałbyś zawrzeć w tym kontekście opisy obu architektur (źródłowej i docelowej) i opis zadania do wykonania, a potem w tym kontekście musi się zmieścić wynik pracy LLMa. Obecnie, płatne usługi dają konteksty rzędu 1M tokenów (a zapotrzebowanie na pamięć liczymy w terabajtach). Wydaje mi się że to trochę za mało.

W locie to jeszcze dalsza pieśń przyszłości, na oryginalny sprzęcie to zapomnij.

(jeszcze tylko dopiszę, że zwiększanie kontekstu powoduje wykładniczy wzrost zapotrzebowania na pamięć)

niesamowite :)

na SV bedzie nowa kategoria ;)

a moze nakarmic AI muzyka Roba Hubbarda i niech napisze cos nowego :-) to by bylo cos :D

xxl -  mojej ocenie to jest całkowicie do zrobienia, tyle, że aby wygenerować muzykę na Pokeya albo SIDa trzeba by pewnie wytrenować model specjalnie do tego, a to by kosztowało. Inaczej dostaniesz tylko coś "w stylu" chiptune, albo "a la" Atari.

Analogiczny problem mam zresztą z generacją grafiki pixelartowej na popularnych modelach. Każ mu zrobić grafikę pixelart w rodzielczości 16x16 w 4 kolorach. Dostaniesz pixelart, ale na pewno nie w takiej rozdziałce i w większej liczbie kolorów.

A może ktoś już zrobił odpowiednie modele do grafiki i muzyki retro? Nie sprawdzałem od wiosny, wiele mogło się zmienić ;)

chyba pod VBXE, Shanti77 przerobił w ten sposób Commando z C64

Dla najnowszych modeli źródła już nie są konieczne. Analizują binarkę w kilka minut. Zerknij: https://www.atari.org.pl/forum/viewtopi ... 78#p326978

To zrobił GPT-6 Astra w przeglądarce, w trybie Work, nawet bez Codexa, bez żadnych skilli. Sam sobie zbudował środowisko ściągając asembler, emulator i sam testował to co robił.

Akurat Alien 3 z C64 wymagałoby chyba sporo pracy (i to pewnie w dużej części ludzkiej) nad grafiką, bo widzę tam sporo kolorów.
Ostatnio powstaje mnóstwo portów na różne platformy, produkowanych przez AI prawie maszynowo. Działają i to poprawnie, dają radość tym, którzy się bawią w to portowanie, ale często jest tam też sporo błędów i niedociągnięć, bo poprawienie ich wymaga już 5x więcej pracy, a często też sporo wiedzy.

Ja się nie podejmę, mam z AI inne wyzwania na tapecie, równie ambitne (w tym jeden port).
Co z tego, że zrobiłbym Ci na jutro działającą wersję Alien 3, skoro wyglądałaby jak gówno, przy wersji z C64? To bez sensu, bo słaby port tylko szkodzi Atari.

Okazało się, że jestem gapa i nie zauważyłe, że Dely wrzucił źródła :)

Właśnie mnie często interesuje odwrotna strona - jak coś jest zrobione. Niby czytałem ziny, artykuły ze strony MadTeamu, czasem kogoś zapytam, a i tak dalej czuje się gupi :)

Wrzuciłem XEXa od Delyego w Sonnet 5 effort medium na darmowym limicie.
Analiza trwała 2 dni, bo co limity  wypalały się ekspresowo. Z Astrą czy Fable pewnie byłoby 5 minut jaku Nostyego :)

Kilka wniosków - pewnie Ameryki nie odkryłem:
* Sonnet 5 lubi zgadywać, jeżeli coś "wydaje mu się" prawdopodobne. Ale jeżeli go pocisnąć i dopytywać o szczegóły - przeanalizuje dany aspekt i przyzna się do błędu :D
EDYCJA: sam Sonnet mi dobrze podpowiedział. dawać w prompcie "zweryfikuj każdą interpretację przeciw WSZYSTKIM wcześniej ustalonym faktom, zanim ją zapiszesz" i nie miałbym tego problemu :)
* przy złożonych zadaniach, np. odzyskiwanie źródła trzeba najpierw poprosić o plan pracy,
* trzeba nakazać mu zapisywać postępy w realizacji planu. Gdy darmowe wiadomości się kończyły, czekałem 5h by potem napisać krótkie "Kontynuuj gdzie przerwałeś".

W załączniku odzyskane źródło i pełna analiza prawie dla zielonych.
Na następny test wrzucę mu snapshot z emulatora z efektu z jakiegoś dema.

w tym momencie wpisalem do czata zeby napisal w asemblerze dla atari 800 program do kasowania zawartosci ekranu. oto co wypul:

; ------------------------------------------------------------
; CLEAR_SCREEN
; Wypelnia standardowy ekran 40 x 24 spacjami.
; SAVMSC wskazuje poczatek bufora ekranu.
; ------------------------------------------------------------

CLEAR_SCREEN
        lda SAVMSC
        sta DST
        lda SAVMSC+1
        sta DST+1

        ldy #0
        lda #0             ; kod spacji w kodowaniu ekranu
        ldx #0

CLEAR_LOOP
        sta (DST),y
        iny
        bne CLEAR_LOOP

        inc DST+1
        inx
        cpx #4             ; 4 strony po 256 bajtow = 1024
        bne CLEAR_LOOP

        rts

------------------------------------------------------------
; ZMIENNE
; ------------------------------------------------------------

DST      .word 0

nie wiem jak udaje sie mu napisac te wszystkie cuda skoro w tak banalnych procedurach robi kardynalne bledy.

przeciez Ty nawet nie wiesz gdzie jest blad ;-)

No i potem pęla sprzężenia zwrotnego

"uruchom to w emulatorze i sprawdź czy działa"

Ładuję skill AltirraSDL, żeby uruchomić program przez AltirraBridge i zrobić zrzut ekranu.

● Skill(altirra-sdl-engineering)
Successfully loaded skill

  Ran 4 shell commands

Uruchamiam emulator headless i piszę skrypt testowy: breakpoint na $2000, boot XEX, zaśmiecenie ekranu, zrzut "przed", wznowienie, zrzut "po" i sprawdzenie pamięci obrazu.

  Read 1 file, ran 3 shell commands

● Background command "Run breakpoint-based clear-screen test for both XEX files in the emulator" failed with exit code 144

  Ran 2 shell commands

Stary proces emulatora się zawiesił; ubijam oba i startuję na czysto.

  Ran 3 shell commands

Klucz to PC wielkimi literami; breakpoint już trafił. Poprawiam skrypt i puszczam oba testy.

  Read 2 files, ran 5 shell commands

Widzę, że zrzuty "po" pokazywały loader Altirry, bo program po RTS wraca do niego i podmienia display listę. Zmienię adres powrotu na stosie na pętlę jmp *, żeby wynik został widoczny na ekranie.

  Read 2 files, ran 2 shell commands

Oba programy działają poprawnie w emulatorze AltirraSDL (headless, przez AltirraBridge). Zrzuty ekranu leżą w /tmp/ll/cls/ jako przed.png, po_cio.png i po_fast.png.

Jak testowałem. Breakpoint na $2000, boot pliku XEX, a po zatrzymaniu wypełniłem całe 960 bajtów pamięci obrazu (pod adresem z SAVMSC, czyli $BC40) znakami i inwersami, zrobiłem zrzut, potem wznowiłem program i zrzuciłem pamięć obrazu oraz ekran ponownie. Adres powrotu na stosie podmieniłem na pętlę w nieskończoność, bo inaczej po RTS loader Altirry wstawia własną display listę i zrzut "po" pokazywał ekran loadera, a nie efekt programu.

Wyniki:

┌──────────────┬────────────────────────┬──────────────────────────┬───────────────────────────────┐
│   Program    │         Przed          │            Po            │ Pamięć poniżej/powyżej ekranu │
├──────────────┼────────────────────────┼──────────────────────────┼───────────────────────────────┤
│ cls_cio.xex  │ 960 bajtów niezerowych │ 1 bajt: $80 na pozycji 2 │ nietknięta                    │
├──────────────┼────────────────────────┼──────────────────────────┼───────────────────────────────┤
│ cls_fast.xex │ 960 bajtów niezerowych │ 0 bajtów niezerowych     │ nietknięta                    │
└──────────────┴────────────────────────┴──────────────────────────┴───────────────────────────────┘

- Wersja CIO czyści ekran i zostawia kursor OS-u w wierszu 0, kolumna 2. Ten jeden bajt $80 to właśnie kursor edytora E: na lewym marginesie (LMARGN = 2). To jest poprawne i oczekiwane zachowanie polecenia CLEAR, na zrzucie widać niebieski ekran z kursorem w lewym górnym rogu.
- Wersja szybka zeruje dokładnie 960 bajtów i ani bajtu więcej. Na zrzucie jest czysty niebieski ekran bez kursora, bo ta wersja nie przechodzi przez OS.

Dwie rzeczy, na które natknąłem się po drodze w samym mostku, żebyś wiedział na przyszłość: po trafieniu breakpointu komenda FRAME blokuje się na zawsze, więc trzeba odpytywać REGS z opóźnieniem zamiast stepować klatkami, a słownik z REGS ma klucze wielkimi literami (PC, nie pc).

@mcs: ale to jest darmowy czy platny? bo czytam ze darmowa to inna wersja od platnej.

widze, ze musi sobie sam testowac bo inaczej to jak w pierwszym przykladzie uzyje nawet nieistniejacego trybu adresowania.