atarionline.pl Action! (+ benchmarks comparision) - Forum Atarum

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

    • :
    • :

    Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

      • 1: CommentAuthorbasakatu
      • CommentTime1 Mar 2019 23:03 zmieniony
       
      Dzień dobry,

      Po kolejnych kilku latach przerwy znów nostalgicznie wróciłem do swojego pierwszego komputera w wersji emulatorowej na Raspberry PI i Windozie, bo prawdziwego sprzętu już dawno niestety nie mam. Po kilku miło «przegranych» wieczorach stwierdziłem, że wrócę też do programowania, napisałem pierwszą po latach grę w BASIC-u i przy drugiej próbie stwierdziłem, że wymiękam z numerowaniem linii i pora spróbować czegoś nowego. Na assemblera jestem za cienki, więc mój wybór padł na Action!

      No i tak... ściągnąłem sobie obraz cartridge i to działa, nawet pierwsze jakieś programy napisałem i działają, ale mam taki problem. Umiem zapisać listing programu przez <ctr><shift>W, ale w ogóle nie potrafię go potem wczytać w edytorze. Wygląda na to, że skrót klawiszowy <ctr><shift>R mi nie działa, ale nie działa ani w Atari800Win ani w Altirra, co już wydaje się dziwne. Czy ma ktoś jakieś pomysły dlaczego?

      Z góry dziękuje za rady
      • 2:
         
        CommentAuthorKrótki
      • CommentTime3 Mar 2019 03:03 zmieniony
       
      Przychodzą mi do głowy 3 możliwości:
      1. Z emulatorem wszystko w porządku, tylko używany przez Ciebie obraz ROM Action! jest uszkodzony. Żeby to sprawdzić, wpisz w BASIC-u poniższy program:

      10 ? PEEK(764):GOTO 10
      RUN

      Naciśnięcie Control+Shift+R powinno spowodować wypisywanie się liczby 232. Jeśli liczba jest inna, to znaczy że to nie wina Action!, ale faktycznie emulator nie rejestruje naciśnięcia tej kombinacji.

      2. Masz w Windowsie jakiś program, który zarezerwował dla siebie tę kombinację klawiszy. Tu przykładowa lista programów. Radeon ReLive wydaje się być najbardziej prawdopodobnym winowajcą.

      3. Masz dziadowską klawiaturę, która nie rozpoznaje kombinacji Ctrl+Shift+R. Spróbuj inną klawiaturę, albo uruchom w Windows program "Klawiatura ekranowa" i "wyklikaj" w nim tę kombinację klawiszy - jeśli zadziała, to znaczy że problem jest po stronie fizycznej klawiatury.
      • 3: CommentAuthorbasakatu
      • CommentTime3 Mar 2019 19:03
       
      Piękne dzięki,

      Poskutkowało - wina leżała po stronie programu do zrzutów ekranowych, który przejął skrót Control+Shift+R.
      • 4:
         
        CommentAuthortdc
      • CommentTime5 Mar 2019 15:03 zmieniony
       

      basakatu:

      napisałem pierwszą po latach grę w BASIC-u

      A możesz nam ją tutaj pokazać? Choćby filmik z uruchomienia?

      ...o ile to nie tajemnica ;) Bo jeśli chcesz poczekać z zaprezentowaniem tej gry to oczywiście zaczekamy ;)

      basakatu:

      wymiękam z numerowaniem linii i pora spróbować czegoś nowego. Na assemblera jestem za cienki, więc mój wybór padł na Action!

      W Action! jest taka miła funkcjonalność, której nie ma w BASICach*, że istnieje możliwość "usuwania" "zbędnego" kodu poprzez przeniesienie go do innego pliku, a następnie dodanie go na etapie kompilacji (polecenie include nazwa pliku.act). To w przypadku gdyby Twój program stał się na tyle duży, że również zacząłby sprawiać problemy w odnajdywaniu odpowiednich miejsc w kodzie (co prawda numerów linii nie ma, ale za duży program może nie być wygodny w edycji).



      * chodzi o małe Atari, bo na ST w GFA jest fajna funkcja chowania procedur za pomocą klawisza Help (jeśli dobrze pamiętam klawisz).
      • 5: CommentAuthorzbyti
      • CommentTime16 Feb 2020 18:02
       
      Artykuły na AOL które mają w tytule Action ->link<-
      • 6: CommentAuthorzbyti
      • CommentTime16 Feb 2020 22:02 zmieniony
       
      Pobawię się dzień lub dwa w Action!

      Spróbuję wykonać trochę kodu jaki zrobiłem w Mad Pascalu i porównać czasy.

      Ogólnie to wymóg nieużywania procedur bibliotecznych by w ogóle runtime to chwytał to już nie na dzisiejsze czasy...

      Wygląda, że dziś na A8 to albo Mad Pascal albo MADS - przynajmniej z mojej perspektywy.
      • 7: CommentAuthorzbyti
      • CommentTime16 Feb 2020 23:02 zmieniony
       
      Coś musiałem pokręcić bo po paromiesięcznej przerwie od Mad Pascala okazuje się, że prawie wszystko zapomniałem.

      Mad Pascalowcy poprawcie mój kod :]

      Na ten moment słynny test by Yosh ->link<- wygląda u mnie tak jak na obrazkach.

      Action!
      BYTE RT = 20

      PROC MAIN()
      CARD A

      RT=0
      A=0
      WHILE RT<100
      DO
      A=A+1
      OD
      PRINTF("%U%E",A)
      RETURN

      Mad Pascal
      program YoshBench;

      uses crt, sysutils;

      var i: word = 0;
      var rt1: PByte;
      var rt2: ^byte;

      begin
      poke(20, 0);
      while GetTickCount <= 100 do Inc(i);
      WriteLn('GetTickCount: ', i);

      i := 0;

      poke(20, 0);
      while peek(20) <= 100 do Inc(i);
      WriteLn('Peek: ', i);

      i := 0;

      rt1 := pointer(20);
      rt1[0] := 0;
      while rt1[0] <= 100 do Inc(i);
      WriteLn('Pointer 1: ', i);

      i := 0;

      rt2 := pointer(20);
      rt2[0] := 0;
      while rt2[0] <= 100 do Inc(i);
      WriteLn('Pointer 2: ', i);

      ReadKey;
      end.

      Nie pokuszę się o komentarza bo do tego potrzeba kogoś bardziej oblatanego.
      • 8: CommentAuthortebe
      • CommentTime17 Feb 2020 08:02 zmieniony
       
      brakuje PAUSE przed każdym testem, licznik RTCLOCK jest ciągle zwiększany przez OS co ramkę, powinno się go zerować na początku tejże ramki inaczej dostajesz falstarty

      w ACTION! też to powinno być na początku programu

      program YoshBench;

      uses crt, sysutils;

      var i: word = 0;
      var rt1: PByte;
      var rt2: ^byte;

      begin
      pause;
      poke(20, 0);
      while GetTickCount <= 100 do Inc(i);
      WriteLn('GetTickCount: ', i);

      i := 0;
      pause;
      poke(20, 0);
      while peek(20) <= 100 do Inc(i);
      WriteLn('Peek: ', i);

      i := 0;
      pause;
      rt1 := pointer(20);
      rt1[0] := 0;
      while rt1[0] <= 100 do Inc(i);
      WriteLn('Pointer 1: ', i);

      i := 0;
      pause;
      rt2 := pointer(20);
      rt2[0] := 0;
      while rt2[0] <= 100 do Inc(i);
      WriteLn('Pointer 2: ', i);

      ReadKey;
      end.


      p.s
      PByte = ^byte, test rt2 jest nadmiarowy, to kopia rt1

      licznik I typu WORD jest za mały, użyj CARDINAL, dla obecnego testu ten licznik się przekręca
      • 9: CommentAuthorzbyti
      • CommentTime17 Feb 2020 10:02 zmieniony
       
      @tebe racja GetTickCount operuje na CARDINAL, jakoś zrozumiałem, że CARD w Action jest dwubajtowy i word starczy ;) Taki ze mnie mózg :D

      No to ten sam kod z poprawką:

      var i: cardinal = 0;

      Jeden przebieg bez pause drugi już z pause.

      Dzięki @tebe, teraz widać, ze Mad Pascal to demon szybkości! :]

      ----------------------------------

      EDIT:

      Jakby kogoś dziwił pierwszy wynik na ekranie testu to:
      function GetTickCount: cardinal;

      GetTickCount zwraca 24-bitowy licznik czasu (PEEK(RTCLOK+2) + PEEK(RTCLOK+1)*256 + PEEK(RTCLOK)*65536). Jest to przydatne do pomiaru czasu.
      • 10: CommentAuthorzbyti
      • CommentTime17 Feb 2020 10:02 zmieniony
       
      PEEK które spowalnia Action! prawie o połowe w Mad Pascalu jest najszybszą opcją :D

      @tebe skoro według Twojej dokumentacji:

      WORD	0 .. 65535	2

      to dlaczego w tym teście licznik dla pointera się przekręcał? Jeszcze mieści się w zakresie, nie?

      Znów wróciłem na moment do word by pokazać o ile różni się między sobą wynik cardinaln vs word vs zakres.

      to nie powinno być: 65535 + 4213? To jest sporo różne od 64099.
      • 11: CommentAuthortebe
      • CommentTime17 Feb 2020 11:02
       
      zwiększanie CARDINAL trwa dłużej od zwiększania WORD

      najlepiej "obciąż" pętlę testową dodatkowymi obliczeniami, np. zwiększaj dwie zmienne typu WORD albo więcej
      • 12: CommentAuthorzbyti
      • CommentTime17 Feb 2020 11:02 zmieniony
       
      @tebe a no tak: głupie pytanie prosta odpowiedź :D Ale przynajmniej widać o ile kosztowniejsza jest praca na cardinal ;)

      Ja odwykłem od zastanawiania się czy dany typ danych jest szybszy czy nie... Prawie od zawsze dobierałem je pod względem zasobności pamięci, tak że teraz w ogóle mi to do głowy nie przyszło.

      Postaram się pomyśleć zanim coś napiszę następnym razem ;)

      Może coś wrzucę jeszcze w pętle faktycznie by nie przekręcało word.
      • 13: CommentAuthorzbyti
      • CommentTime17 Feb 2020 11:02 zmieniony
       
      Action!
      BYTE RT = 20

      PROC MAIN()
      CARD A, B, C

      A=0
      B=0
      C=0

      RT=0
      WHILE RT<100
      DO
      B=B+1
      C=B
      C=C+1
      B=C
      A=A+1
      OD
      PRINTF("%U%E",A)
      RETURN

      Mad Pascal
      program YoshBenchPlus;

      uses crt;

      var i: word = 0;
      var a: word = 0;
      var b: word = 0;

      begin
      pause;
      poke(20, 0);

      while peek(20) <= 100 do begin
      Inc(a);
      b := a;
      Inc(b);
      a := b;
      Inc(i);
      end;

      WriteLn('Peek: ', i);
      ReadKey;
      end.
      • 14: CommentAuthorantrykot
      • CommentTime17 Feb 2020 11:02 zmieniony
       
      A skąd wiesz czy w Action! licznik ci się nie pzekręca?

      No i jeszcze zanim wyciągniesz wniosek że peek jest najszybsze, to wypadało by sprawdzić ten sam spoób dostępu do zegara co w Action!
      • 15: CommentAuthorzbyti
      • CommentTime17 Feb 2020 11:02 zmieniony
       

      antrykot:

      A skąd wiesz czy w Action! licznik ci się nie pzekręca?

      Bo to pisał Yosh ;P a on wie co robi :D

      antrykot:

      No i jeszcze zanim wyciągniesz wniosek że peek jest najszybsze, to wypadało by sprawdzić ten sam spoób dostępu do zegara co w Action!

      A podpowiesz jak?
      • 16: CommentAuthorantrykot
      • CommentTime17 Feb 2020 12:02
       
      absolute
      • 17: CommentAuthorzbyti
      • CommentTime17 Feb 2020 12:02 zmieniony
       
      Identyko :] Widać kompilator zna takie sztuczki ;)

      program YoshBenchPlus;

      uses crt;

      var i: word = 0;
      var a: word = 0;
      var b: word = 0;
      var rt: byte absolute $14;

      begin
      pause;
      poke(20, 0);

      while rt <= 100 do begin
      Inc(a);
      b := a;
      Inc(b);
      a := b;
      Inc(i);
      end;

      WriteLn('absolute: ', i);
      ReadKey;
      end.
      • 18: CommentAuthorzbyti
      • CommentTime17 Feb 2020 13:02 zmieniony
       
      Jeszcze jedno przekłamanie w teście, tym razem na korzyść MP:

      while rt <= 100 do begin

      zaraz to poprawię i podam wyniki Action! i Mad Pascala dla testu Yosh i SIEVE.
      • 19: CommentAuthorzbyti
      • CommentTime17 Feb 2020 13:02 zmieniony
       
      Oficjalne wyniki ;)

      Mad Pascal YoshPlus: 35572 iterations in 100 ticks
      Mad Pascal (optimized) Sieve: 1899 in 66 ticks [variables on ZEROPAGE, $DEFINE FAST]
      Mad Pascal (standard) Sieve: 1899 in ~74 ticks

      Action! YoshPlus: 33239 iterations in 100 ticks
      Action! Sieve: 1899 in 101 ticks

      Podsumowując. Przy wygodzie środowiska i licznych bibliotekach Mad Pascala i niewygodzie pisania standalone w Action! trzeba jasno powiedzieć, że szybkość też nie jest argumentem przemawiającym za używaniem Action! w dzisiejszych czasach.

      To ja podziękuję i wracam do nauki Mad Pascala :]
      • 20: CommentAuthorilmenit
      • CommentTime17 Feb 2020 14:02
       
      Albo... CC65 (60 ticks), jak składnia C bliższa niż Pascala ;)
    1.  
      a jak długości kodu wynikowego?
      • 22: CommentAuthorzbyti
      • CommentTime17 Feb 2020 15:02 zmieniony
       
      Mistrz Yoda mówi:

      tdc 2009-02-24 02:27:09:

      (...) bo wykazałoby się że np. w którymś języku program jest krótszy o np. 10 znaków, ale co z tego ? (...) Co nam da 10 znaków skoro program działa o niebo szybciej ?

      ->link<-

      Co prawda pytasz o wynikowy ale... Sprawdź sam :] Ja tego nie zrobiłem a teraz nie chce mi się już do tego wracać bo...



      Action! musiał być świetny w latch '80-tych. Ale na dziś (jak jest MP i CC65) to już szkoda się pochylać.

      Fortha jeszcze mam ochotę przetestować w podobnym teście ale to jak mnie natchnie.
    2.  
      Na prostym programie rysującym 256 kratek kolorów na ekranie jest różnica kilkuset bajtów pomiędzy CC/65 (2 729 bajtów) a Action! (2 174 bajtów) a różnica prędkości rzędu 0.2 sekundy, MP nie używałem.

      Action! był z języków kompilowanych najszybszy w latach 80tych i może jeszcze 90tych, prędkościowo i efektywnościowo do większych projektów niż parę efektów wygrają rzeczy rozwijane współcześnie czyli CC/65 i Mad Pascal.

      Gdyby Action! miał wbudowany inline asm... to byłoby super.

      Nie mam teraz czasu, żeby instalować i kompilować w MP, dla Twojego testu przyjmijmy, że to nieistotne.
      • 24: CommentAuthortebe
      • CommentTime17 Feb 2020 16:02 zmieniony
       
      ROMSUM z Millforka (sumuje bajty pamięci $E000...)

      mpas 102 ticks (bez licznika na stronie zerowej)
      mpas 98 ticks (licznik I na stronie zerowej)
      cc65 110 ticks (z optymalizacją)
      • 25: CommentAuthortebe
      • CommentTime17 Feb 2020 17:02 zmieniony
       
      rekurencja, tutaj MP jest 100% wolniejszy przez swoje alokowanie i zwalnianie pamięci

      mpas 1621 ticks
      cc65 831 ticks (optymalizowany)
      • 26: CommentAuthorzbyti
      • CommentTime17 Feb 2020 17:02 zmieniony
       
      @tebe dzięki za dodatkowe testy.

      @tooloudtoowide jest jeszcze taki minus, że by uruchamiać program w Action! bez carta to musisz dorzucić runtime, który jak wyczytałem tutaj jest strasznie skawalony i praktycznie pisanie z użyciem procedur bibliotecznych (pomijając ich szybkość) jest niewskazane (niemożliwe?).

      MP nie cierpi na takie bolączki, o CC65 nic nie wiem po za tym, że jego rozwój ponoć mocno zwolnił.
      • 27: CommentAuthorzbyti
      • CommentTime17 Feb 2020 19:02 zmieniony
       
      No to na potwierdzenie słów @tooloudtoowide, że Action był swego czasu bezkonkurencyjny zamieszczam Bench by Yosh dla CLSN Pascal na 130XE.

      EDIT: w nazwach plików błędnie wpisałem CLSC, ale co tam ;)
      • 28: CommentAuthorilmenit
      • CommentTime17 Feb 2020 20:02 zmieniony
       
      @tebe - kod C w Twoim załączniku jest jakoś strasznie przekombinowany! Mam wrażenie, że autor pisał te kody tak, aby w jego kompilatorze działały szybko ;)
      Moja znacznie uproszczona wersja - 83 ticks
      unsigned int sum(void) {
      register unsigned int s;
      register const unsigned char* p;
      s = 0;
      for (p = rom; p != 0; ++p)
      {
      s += *p;
      };
      return s;
      }

      @zbyti - od kiedy CC65 jest na githubie i ma więcej niż jednego autora, wręcz przeciwnie, rozwój znacznie przyspieszył.
      • 29: CommentAuthorzbyti
      • CommentTime17 Feb 2020 20:02
       
      @ilmenit a to przepraszam :]
      • 30: CommentAuthortebe
      • CommentTime17 Feb 2020 22:02
       
      przykład został wzięty z Millforka
    3.  
      @zbyti mam oryginalny kart, ale zrobienie dobrego konfigu pod emulator i nowe/poprawione biblioteki Runtime to też nie jest problem. Są jeszcze dwa pomocne programy do robienia listy procek z biblio i potem do zrobienia dedykowanej okrojonej biblioteki do kompilowanego programu.

      Nie wyobrażam sobie robienia programu czy gry na defaultowej bibliotece Action! ale - prawda jest taka, że chyba nikt tak nie robił - zwykle koderzy piszą swoje rzeczy podmieniając rzeczy z systemowej. W C podmieniają fragmenty kodu na asm, żeby przyśpieszyć, albo wymusić pewne rozwiązania pomijając już kompilator.

      W sumie trzeba by Kuby Husaka spytać jak robił - ale z tego co widziałem jakieś źródła to ludzie piszą sami od nowa procki. Gdyby był ten inline asm w Action! to była by prawdziwa petarda, bo kod generowany przez sam Action! jest mały.
      • 32: CommentAuthorzbyti
      • CommentTime17 Feb 2020 22:02 zmieniony
       

      tooloudtoowide:

      nowe/poprawione biblioteki Runtime

      Możesz wskazać? Bo przeczytałem prawie wszystko na forum i nie natknąłem się na wzmiankę o takiej, która by nie stwarzała porblemu.

      Ja używałem wersji carta: Action! v3.7P (2015-06-08)(OSS)(US)[f Peter Dell].car ale o robienie xex się nie pokusiłem.
    4.  
      ->link<-

      pomiń oryginalny Runtime, ja używam Runtime Jeff'a Reistera, ale generalnie okrajam z wszystkiego i staram się pisać swoje własne procki.

      plus odnalazłem poniższe dwa programy - na razie tylko testowałem czy działają, nie zrobiłem jeszcze tak dużego programu, żeby to zastosować plus bardziej skłaniam się ku napisaniu procek samemu.

      RTSCAN.COM - run against your source file to produce a listing
      showing which RUNTIME.ACT routines are actually required
      by your program. Allows you to trim out unneeded
      routines to save symbol table space, etc.
      RTWRITE.COM - If you send the output from RTSCAN.COM to a disk file, you can then run RTWRITE on that file -- it in turn
      outputs the trimmed down version of RUNTIME.ACT for you.
    5.  
      jeżeli chodzi o wersję karta, to zrzuciłem sobie swój programem Kuby, ale jest to generalnie taka sama wersja jak jest podpięta pod wiki. Xexy mi się robią.

      Jak znajdę więcej czasu do dopiszę więcej tutaj:
      ->link<-

      bo parę rzeczy mi się już urodziło od tego czasu, tylko prawda jest taka, że do SpeccyParty jestem wyjęty czasowo na grubsze grzebanie w Action!.
      • 35: CommentAuthorzbyti
      • CommentTime17 Feb 2020 22:02
       
      @tooloudtoowide thx, sprawdzę :]
      • 36:
         
        CommentAuthorjhusak
      • CommentTime17 Feb 2020 23:02 zmieniony
       
      A po co programiście procedury SO? Są dobre, bo uniwersalne, ale gry nie są uniwersalne; Ja osobiście starałem się tak, żeby w ogóle nie było jsr do biblioteki. Czyli np. żadnych mnożeń! Ale to łatwo obejść taką biblioteką, co podmienia procedurę generującą wywołanie procki z runtime na prockę z jakiegoś includa :)
      Gdzieś to jest, trzeba poszukać.

      A taki open czy close toż to przysłowiowych paręnaście bajtów. A te printASDFSDFASGSD - kto tego używa. Albo inputFASDFQERQ.

      Action jest fajny, bo wiadomo, co zrobi. Albo łatwo się tego dowiedzieć i już wiedzieć.

      A największa bolączka - 256 bajtów(!) na tablicę symboli - jest rozwiązana.
      • 37: CommentAuthorzbyti
      • CommentTime18 Feb 2020 00:02 zmieniony
       
      @jhusak gdybyś był tak wylewny jak lakoniczny to nie zabrałbyś swojej wiedzy do grobu ;)

      @tooloudtoowide poczytałem Twoją stronkę o Action (pobieżnie). Jest SUPER! :] Poważnie wydałeś 200$ na carta?

      Zobaczyłem też jak sobie organizujesz emulator etc. ale nie zauważyłem, byś stosował prostą sztuczkę z H6 i includowaniem by sobie edytować źródła poza emulatorem i wygodnie kompilować. @jhusak to nawet jakąś wersję turbo zrobił by kompilować za pomocą emulatora :]
      • 38: CommentAuthorzbyti
      • CommentTime18 Feb 2020 00:02 zmieniony
       
      No to jeszcze YoshPlus skompilowany Effectusem. W wyniku mamy minimalnie więcej iteracji.

      Action!:  33239
      Effectus: 33944
    6.  
      nie zdążyłem napisać, bo film oglądałem - "używam Runtime Jeff'a Reistera" mam na myśli, że jak kompiluję czyjeś źródła to odpalam na tym zamiast systemowej, trzymam na H: po prostu i swoje procki i tą runtime w wersji Jeffa na wszelki wypadek. Używam MacOS i emulatora jaki jest - działa mi tak jak ustawiłem więc - chyba jest dobrze. H: jest u mnie handlerem dysku twardego czyli katalogu na moim dysku. Na czym polega sztuczka z H6? Mam włączony patcher do H: i P: - tego drugiego używam też do zrzucania poprawianych rzeczy z emulatora/Action! do edytora tekstowego na Macu.

      Zbyti, ale gdzie ja napisałem, że dałem 200USD za Action!? :) "Ten kart po prawej stronie bardzo mnie kusił, ale skutecznie zmroziła mnie cena, która łącznie z przesyłką wynosiła prawie 200 USD." To jakaś forumowa zabawa w dopowiadanie treści? :D

      Karta kupiłem za ok. 100 USD (+- 4USD - musiałbym sprawdzić w zakupionych rzeczach na Ebayu). Połowa z tego to cło/przesyłka, ale jakoś to specjalnie nie bolało, zbieram generalnie karty do A8 więc to jeszcze jeden kart do kolekcji.

      Myślę są przynajmniej dwa etapy z Action! :

      Pierwszy sam przechodziłem dwukrotnie - tzn. pierwszy raz w latach 80tych jak wgrałem Action! z multikarta (miałem też tam TurboBASIC XL) i próbowałem coś wpisywać i kompilować - g... z tego wyszło, bo nie przeskoczyłem tematu 1/ braku stacji (a turbo do magnetofonu działało mi z karta, więc jak włożyłem multikarta na starcie, to nie miałem turbo) i niewygody użytkowania magnetofonu do tego 2/ braku sensownej literatury, wobec powyższego utkwiłem na TurboBASICu. Na start chce się wgrać jakieś programy, skompilować, zobaczyć, że działają, a potem rozkminiać kod. Przynajmniej ja tam mam. Jak się nie kompiluje i nie działa to kiszka, nie ma co analizować (bo powinno przecież działać).

      Drugi etap jest taki, że człowiek chce coś swojego zrobić i w C i w Action! jest podobny motyw - procki pisze się samemu, albo trzeba potem zgadywać dlaczego coś nie działa. Problem w tym, że do napisania efektywnej procki (szybkiej i kompilującej się w krótki kod) nie ucieknie się chyba od asm, to jeszcze przede mną na poważnie, ale rozmkminiam krok po kroku.

      W sumie - pod pisanie gry w Action! co potrzebujemy:
      obsługę binarek - jeżeli coś doczytujemy.
      kopiowanie/przesuwanie obszarów pamięci.
      zapis/odczyt pamięci
      logika / pętle (czyli coś co nie wymaga runtime)

      Przy dobrym przemyśleniu można uciekać z CARD na BYTE. Ostatnio patrzyłem w jakiejś grze - nabijam punkty, a one lecą... w setkach. No to dwa zera z prawej do pominięcia a reszta może lecieć... z jednobajtowego zapisu. Mi np. do tego co teraz robię pasuje tryb gfx narrow, bo mieszczę się w 256px, co przy konwersji <>ZXa robi mi 99% roboty, plus zapis danych w takich porcjach jest wygodniejszy dla mnie.

      Z powyższej listy - procka do DLI, procki graficzne plot/draw, zamiast print zapis do pamięci z konwersją z/do atascii, oprogramowanie spritów, prosta procka do odczytu rejestrów klawiatury, joysticka, procki do obsługi dźwięku. Tekst? Tekst to bajty.

      Jak tak policzyć to 95% runtime jest nam niepotrzebne, a potrzebujemy czegoś "pod nas". Jest naprawdę sporo źródeł do Action! Na ten moment nie miałem 99% problemów o jakich czytam. To co zrobię pod emu tak samo działa mi (edytowanie/kompilowanie/zapis skompilowanego na dysk) i na realnym kompie.

      Jeżeli tylko uda mi się napisać lepszą prockę kopiowania obszarów pamięci (czyli podobnie szybką jak w CC/65) to będę mega zadowolony. Cała reszta z tego co wymieniłem - do ogarnięcia. Byle człowiek miał na to energię i czas.
      • 40: CommentAuthorzbyti
      • CommentTime18 Feb 2020 01:02
       

      tooloudtoowide:

      Ten kart po prawej stronie bardzo mnie kusił, ale skutecznie zmroziła mnie cena, która łącznie z przesyłką wynosiła prawie 200 USD. Czy może on zawierać jakąś nowszą, nie znaną nam dotychczas wersję? Jest na to bardzo mała szansa, ale być może takie marzenie jest potrzebne – ja wybrałem 200 USD w portfelu (a raczej na karcie kredytowej).

      Mój błąd, przelatując wzrokiem, wybrałem zrozumiałem jak wyjąłem (np. wybrać ryby z sieci) a nie, że postanowiłeś takiej kasy nie wydawać :D

      Teraz jak czytam drugi raz to już to rozumiem prawidłowo. Istnienie homonimów czasem płata figle ;)
      • 41:
         
        CommentAuthorjhusak
      • CommentTime18 Feb 2020 12:02 zmieniony
       
      Dlatego trzeba pisać krótko. Każda dłuższa wypowiedź jest przelatywana. Najważniejsze na początku akapitu, a potem to cokolwiek może być, i tak większość nie przeczyta/nie zapamięta. Książek tu nie piszemy... A może jednak... niektórzy...

      Co to ja napisałem w poprzednim akapicie?

      A rzeczywiście, do Speedmazy, a może wcześniej, stwierdzając, że nie ma sensu robić tego w edytorze Action, użyłem mechanizmu "nagraj" w atari800.
      Wówczas "make" powodowało odpalenie na dosłownie 0.3 sek emulatora w trybie turbo z kartridżem action wpiętym, kompilację z H:, zapis exe do H: i wyjście. Myk i jest.

      @zbyti, ostatnio nic nie piszę, bo Ty piszesz dokładnie to, co miałem napisać. Albo nawet to, czego nie miałem.
      • 42:
         
        CommentAuthorjhusak
      • CommentTime18 Feb 2020 13:02
       

      tooloudtoowide:

      Jeżeli tylko uda mi się napisać lepszą prockę kopiowania obszarów pamięci (czyli podobnie szybką jak w CC/65) to będę mega zadowolony.

      A nie można użyć tej samej?

      Z drugiej strony nigdy nie potrzebowałem jakiegoś tam wielkiego kopiowania pamięci. Ot tam kafelek przekopiować.

      Może przemyśl projekt, aby potrzebował mniej kopiowania?
      • 43: CommentAuthorzbyti
      • CommentTime18 Feb 2020 13:02 zmieniony
       
      @jhusak czasem ciężko się powstrzymać od napisania tego czego Ty nie miałeś napisać bo wciąż to są błyskotliwe myśli, jak to zwykle u Ciebie, więc szkoda się nie podzielić :]

      Obiecuję jednak uszanować Twoje prawo do prywatności i pisać tylko to co byś sam napisał :D
      • 44: CommentAuthorzbyti
      • CommentTime18 Feb 2020 15:02 zmieniony
       
      To jeszcze przypomną z innego wątku (powieloną informację łatwiej znaleźć) pomysł na setup:

      greblus:

      I jeszcze taka opcja (pomysł Kuby Husaka z opcją -turbo w atari800):

      Trzeba "nagrać" otwieranie pliku źródłowego, kompilację, zapis do pliku na urządzeniu H: (katalog z PC widziany przez atari800 jako dysk H:):

      atari800 -cart Action\!.rom -cart-type 15 -record tmp

      a potem to odtworzyć w trybie turbo:

      atari800 -cart Action\!.rom -cart-type 15 -playback tmp -turbo

      Trzeba tylko sprytnie obsłużyć zmiany końców linii i nazwy pliku ze skryptu na PC i można używać karta Action! w emulatorze z mega prędkością kompilacji (-turbo). Trochę szalone, ale używałem tego kilka lat temu z dobrym skutkiem ;).

      Yosh:

      Końców linii nie trzeba obsługiwać - robi to urządzenie H.

      Najłatwiejsza konfiguracja to emulator z urządzeniem H.

      W głównym edytorze wystarczy mieć kod postaci:

      INCLUDE "H6:MAIN.ACT"

      H6 to takie H1, tylko że z tłumaczonymi końcami linii. Teraz wychodzisz do monitora i w nim "C" wciskasz aby kompilować i "R" by uruchomić, cały kod piszesz sobie dowolnym zewnętrznym edytorze (końce linii unixowe).
    7.  
      ...teoretycznie to właściwy/najważniejszy komunikat powinien być na końcu, bo ludzie nie zapamiętują początku i środka :)

      A tak na serio...

      @Kuba - generalnie masz rację - do małych kafelków nie potrzeba więcej niż wydala Action! sam z siebie, walczę z wydajnością 1/3 ekranu w hiresie, co prawda narrow, ale 64 linie po 32 bajty to już taki duży kafelek - jeżeli uda mi się to przepisać 2x szybciej to będę 2x bardziej szczęśliwy. Robię równolegle projekt w C (bo potrzebuję to zrobić też na Apple II i ZX Spectrum), w sumie Atari mogę też zrobić w C, nawet mniej roboty by było, ale to takie coś z kupki wstydu z przeszłości - chciałem coś zrobić w Action! więc spróbuję zrobić.

      Wrócę do tematu od połowy kwietnia, bo teraz szyję demo na ZX81 na kompoty, a czasu małooo, straciłem prawie 2 tygodnie przez chorowanie :(

      @Zbyti, tą metodę z otwarzaniem w trybie turbo kompulacji i zapisu znam - zrobiłem sobie coś podobnego w postaci skryptu pod MacOS.
      • 46: CommentAuthorzbyti
      • CommentTime18 Feb 2020 18:02 zmieniony
       
      No to kolejny benchmark polegający na rysowaniu szachownicy w trybie 8.

      Zrobiłem port mojego kodu z MP do Action! i mamy takie oto wyniki:

      Mad Pascal GR8 Board: 7
      Action! GR8 Board: 8

      Poniżej kod, starałem się by był możliwie podobny w czytaniu.

      Jeżeli ktoś ma pomysł jak przyspieszyć MP lub Action! to chętnie słucham.

      Mad Pascal
      program chessboard;
      uses crt, graph;

      var stop : byte;
      rtClock : byte absolute 20;
      col1 : byte absolute 709;
      col2 : byte absolute 710;
      colB : byte absolute 712;
      bmpAdr : word absolute 88;

      procedure drawBoard;
      var i1b, i2b, i3b, x, color, modLine : byte;
      p : PByte;
      begin
      p := pointer(bmpAdr);
      modLine := 0;
      for i3b := 1 to 8 do begin
      for i2b := 1 to 24 do begin
      x := 0;
      for i1b := 1 to 8 do begin
      color := 0;
      if (i1b and %1 <> modLine) then color := $ff;
      if (color <> 0) then begin
      p[x] := color;
      p[x + 1] := color;
      p[x + 2] := color;
      end;
      Inc(x, 3);
      end;
      Inc(p, 40);
      end;
      if (i3b and %1 = 0) then modLine := 0
      else modLine := 1;
      end;
      end;

      begin
      InitGraph(8 + 16);
      col1 := 1;
      col2 := 11;
      colB := 12;

      rtClock := 0;
      drawBoard;
      stop := rtClock;
      ReadKey;

      InitGraph(0);
      writeln('Drawing time: ', stop);
      ReadKey;
      end.

      Action!
      BYTE ch=764     ; ESC = 28

      BYTE RTCLOCK=20 ; sys timer
      CARD SAVMSC=88 ; screen addr

      BYTE col1=709
      BYTE col2=710
      BYTE colB=712

      BYTE stop

      PROC drawBoard()
      BYTE i1b, i2b, i3b, x, color, modLine
      BYTE ARRAY SCREEN

      SCREEN=SAVMSC
      modLine=0

      FOR i3b=1 TO 8
      DO
      FOR i2b=1 TO 24
      DO
      x=0
      FOR i1b=1 TO 8
      DO
      color=0
      IF (i1b & 1) <> modLine THEN color=255 FI
      IF color <> 0 THEN
      SCREEN(x)=color
      SCREEN(x+1)=color
      SCREEN(x+2)=color
      FI
      x==+3
      OD
      SCREEN==+40
      OD
      IF (i3b & 1) = 0 THEN modLine=0
      ELSE modLine=1 FI
      OD
      RETURN

      PROC main()
      GRAPHICS(8+16)
      col1=1
      col2=11
      colB=12

      RTCLOCK=0
      drawBoard()
      stop=RTCLOCK
      WHILE ch<>28 DO OD

      ch=0
      GRAPHICS(0)
      PRINTF("%E %U ticks",stop)
      WHILE ch<>28 DO OD
      RETURN
      • 47: CommentAuthorzbyti
      • CommentTime18 Feb 2020 19:02
       
      Czy jakiś magik mógłby to (board) trzepnąć w czystym ASM i dać nam porównanie jaki jest narzut tych kompilatorów?
      • 48: CommentAuthorilmenit
      • CommentTime18 Feb 2020 21:02
       
      Narzut kompilatorów bardzo zależy od konkretnego kodu, algorytmu, użycia zmiennych a nawet kolejności operacji i jest w okolicach 0%-50%. Jest np. SIEVE napisany w ASM w przykładach MADSa.
      ASM umożliwa znacznie lepsze dostosowanie kodu do możliwości procesora (np. adresowanie po stronach pamięci) i dla time-critical rzeczy jak obsługa przerwań lub stawianie pikseli polecałbym wyspecjalizowane procedury. Zerknij na kody Pac-Mad - chociaż główny kod jest pisany w Pascalu, są też wstawki w ASM. W ten sposób zaoszczędzasz swój czas a jednocześnie masz oczekiwaną szybkość.
      • 49: CommentAuthorzbyti
      • CommentTime18 Feb 2020 22:02 zmieniony
       
      @ilmenit dzięki za podpowiedzi i rady, tak zrobię, "przeczytam" Pac-Mad :]

      W tej chwili chcę jeszcze machnąć coś dla porównania w FORTH, aktualnie czytam arty Rolanda Pantoły.
      • 50: CommentAuthortebe
      • CommentTime18 Feb 2020 22:02 zmieniony
       
      p[x]:= color; inc(x);
      p[x]:= color; inc(x);
      p[x]:= color; inc(x);


      powinno być szybciej