atarionline.pl Sztuczki w Action! - 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:
       
      CommentAuthorCosi
    • CommentTime4 Jul 2009
     
    Jak powszechnie wiadomo, książka "Języki programowania Atari..." jest tak pełna błędów, że początkujący powinni trzymać się od niej z daleka. Znalazłem tam pewną ciekawostkę, a mianowicie taką konstrukcję:
    while lim==-1>0 do ... od

    To jest taka sztuczka z języków C-podobnych, polegająca na tym, że fragment "lim==-1>0" najpierw zmniejsza wartość zmiennej lim, a później sprawdza, czy jest większa od zera. W C wygląda to tak:
    while(--lim>0) { ... }

    Dzięki temu można uniknąć konstrukcji
    lim==-1
    while lim>0 do
    ...
    lim==-1
    od


    Oczy mi się zaświeciły. "Niezły ten Action!", pomyślałem. Ale coś mnie tknęło, sprawdziłem. No i oczywiście bzdura, nie da się zastosować takiego rozwiązania w Action!
    Pomyślałem, że dałoby się to obejść, gdyby była funkcja, która jednocześnie zmniejsza wartość zmiennej i zwraca wynik. To nie jest takie proste, bo Action! nie udostępnia referencji - jeżeli przekazuję do funkcji/procedury zmienną, to funkcja operuje na WARTOŚCI zmiennej, a nie na samej zmiennej.
    Rozwiązaniem są wskaźniki. Jeżeli wskaźnik jest przypisany do zmiennej, to możemy grzebać bezpośrednio w miejscu, gdzie jest umieszczona w pamięci. Wyszło mi coś takiego:
    card func dec(card pointer x)
    x^==-1
    return (x^)

    proc glowna_procedura()
    card i
    card pointer j
    j=@i
    i=11 ;wartosc poczatkowa
    while dec(j)>0 do ;tu nasza petla
    printce(i)
    od
    return

    Nieszczególnie to wygląda... Może ktoś ma pomysł, jak obejść konieczność tworzenia dodatkowego wskaźnika? W Pascalu była konstrukcja ^zmienna, która odpowiadała wskaźnikowi, może w Action! też jest coś takiego?

    Przy okazji zauważyłem coś, co (chyba) jest pomijane w różnych podręcznikach do Action! Jeżeli w powyższym przykładzie damy:
    proc glowna_procedura()
    card i=[11] ;wartosc poczatkowa
    card pointer j
    j=@i
    while dec(j)>0 do ;tu nasza petla
    printce(i)
    od
    return

    i wywołamy program po raz drugi, to uzyskamy ciekawy efekt. Wygląda na to, że deklaracja "typ zmienna=[wartość]" przypisuje zmiennej wartość podczas KOMPILACJI, a później w pamięci pozostaje ostatnia wprowadzona zmiana. Dobrze o tym wiedzieć, pisząc programy :)
    • 2:
       
      CommentAuthorKaz
    • CommentTime5 Jul 2009
     
    Sadzac po rozmowach z TDC, ktory jest chyba ostatnim zywym milosnikiem "Action!" ;), to kompilator ma sporo bledow. A ze sa slabo udokumentowane to stawia to pod znakiem zapytania przewage "A!" nad "Turbo Basiciem XL", ktorego bledy sa opisane i znane :).
    • 3:
       
      CommentAuthorCosi
    • CommentTime5 Jul 2009
     
    Nie ma strachu, błędy można wyłapać i unieszkodliwić :D
    • 4:
       
      CommentAuthormiker
    • CommentTime5 Jul 2009
     
    No, wyłapanie ich by się przydąło. TDC ma jeszcze parę niedokończonych projektów, które zapewne i z tego powodu na razie cierpią.
    • 5: CommentAuthortebe
    • CommentTime5 Jul 2009 zmieniony
     
    nie wiem jakie są możliwości TDC, może mógłby się pokusić o cross kompilator !Action, np. w zespole z Cosi

    !Action ze względu na swoją szybkość i możliwości, bez ograniczeń wynikających z bufora edytora jak i innych błędów mógłby być potężnym narzędziem dla użytkowników unikających assemblera, chcących jednak coś napisać

    taki !Action wygrałby z CC65 ze względu na mniejsze zużycie pamięci i większą szybkość działania

    pewnie niewiele pomoże disasemblacja carta !Action, kiedyś to zrobiłem, w sumie nie wszystkie rozkazy rozłożyłem na części pierwsze bo jest tam sporo drobnych tablic opisujących każdy taki rozkaz, nie doszłem też do tego jak działa tam ta kompilacja

    p.s.
    aktualnie Gury zaczął kilka lat temu Effectus-a ->link<-
    • 6:
       
      CommentAuthorCosi
    • CommentTime6 Jul 2009 zmieniony
     
    Ja jestem za. W sumie wystarczyłyby drobne poprawki w Effectusie. Najpierw tylko wypadałoby zobaczyć, czy Action! się przyjmie "w środowisku".

    PS. Jak tak patrzę, to Effectus ma jeszcze więcej błędów. I bardziej denerwujących ;P
    • 7:
       
      CommentAuthorKaz
    • CommentTime6 Jul 2009
     
    Z Gurym mam bardzo dobry kontakt, wiec jesli trzeba to mozemy zawiazac jakas "grupe poprawiaczy" Effectusa ;).
    • 8:
       
      CommentAuthorCosi
    • CommentTime6 Jul 2009
     
    Tylko - jak już tebe zauważył - w grupie musi się znaleźć ktoś, kto zna Action! jak własną kieszeń, np. Tdc.
    • 9:
       
      CommentAuthorKaz
    • CommentTime6 Jul 2009
     
    TDC ma jeszcze kilka rzeczy do napisania w Action, wiec pewnie sie chetnie bedzie pisal na testowanie takiego wygodnego narzedzia... dwie pieczenie na jednym ogniu :)
    • 10:
       
      CommentAuthortdc
    • CommentTime7 Jul 2009 zmieniony
     
    Odnośnie wskaźnika, to najprostszym oraz najszybszym rozwiązaniem jest zmienna globalna;)

    Co do inicjowania zmiennej to nie miałem zwykle takich problemów bo zwykle program uruchamiałem raz ;) Natomiast ważne jest też jakiego Action! używasz, bo jeśli tego emulatorowego to jest to straszny grzyb (a nie Grzybek :D :D

    Inna kwestia, że typowe dla języków takich jak C czy Action jest to że wiele rzeczy trzeba samu pilnować (np. zerowanie tablic, zmiennych itp.).


    tebe: ja mógłbym się pokusić, ale czasu nie ma. Na razie staram się poooowooolutku pokończyć moje stare programy. Potem pomyślimy.

    > !Action ze względu na swoją szybkość i możliwości, bez ograniczeń wynikających z bufora edytora jak i innych błędów mógłby być potężnym narzędziem dla użytkowników unikających assemblera

    Pomysł zacny, choć bufor edytora nie jest aż tak straszny;) w końcu nie trzeba mieć w tym języku źródła cały czas w pamięci.

    > pewnie niewiele pomoże disasemblacja carta !Action, kiedyś to zrobiłem

    Ja tego nie robiłem, a jak oceniasz ten kod ? Faktycznie wart swojej renomy ;):) ja niektóre procedury biblioteczne oceniam że są baaardzo powolne, ale może ten kod jednak nie jest taki zły ?

    > Tylko - jak już tebe zauważył - w grupie musi się znaleźć ktoś, kto zna Action! jak własną kieszeń, np. Tdc.

    Ja jestem gotów do współpracy choć Action! wcale nie znam jak własną kieszeń. Znam głównie to co jest przydatne do pisania gier czy efektów graficznych, reszty nie znam lub nie pamiętam. Teraz uczyłem zaawanoswanego programistę gier na pecetach programowania w Action! (ciekawostka swoją drogą :) i na wiele jego pytań nie potrafiłem odpowiedzieć (odsyłałem go do manuala;)

    Kaz: TDC ma jeszcze kilka rzeczy do napisania w Action

    Tak masz rację, baardzo przydało by mi się jakieś dodatkowe środowisko, w którym mógłbym sprawdzić, czy to co się dzieje to błąd Action! czy nie...
    • 11:
       
      CommentAuthorCosi
    • CommentTime7 Jul 2009
     

    Tdc:

    Odnośnie wskaźnika, to najprostszym oraz najszybszym rozwiązaniem jest zmienna globalna;)

    Taak, wiem, ale od lat uczę się tzw. "dobrych praktyk programistycznych" i wolę namotać niż zrobić coś takiego ;)
    Co do inicjowania zmiennej to nie miałem zwykle takich problemów bo zwykle program uruchamiałem raz ;) Natomiast ważne jest też jakiego Action! używasz, bo jeśli tego emulatorowego to jest to straszny grzyb (a nie Grzybek :D :D

    Emulatorowego, wersja 2.0. Jak znajdę na Allegro karta w dwucyfrowej cenie, to na pewno kupię :)
    ja mógłbym się pokusić, ale czasu nie ma. Na razie staram się poooowooolutku pokończyć moje stare programy. Potem pomyślimy.
    ...
    Tak masz rację, baardzo przydało by mi się jakieś dodatkowe środowisko, w którym mógłbym sprawdzić, czy to co się dzieje to błąd Action! czy nie...

    Jak już znajdziesz chwilkę czasu, to ja z przyjemnością zasilę Twoją ekipę Poprawiaczy Effectusa :)
    • 12:
       
      CommentAuthortdc
    • CommentTime9 Jul 2009 zmieniony
     
    <flame>
    Tego typu poprawność polityczna została wymyślona przez lamerów. Przykładowo jakiś profesor stwierdził, że od dziś programujemy tak a to co było wcześniej jest bee. Dlatego przy nudnych programach, jak zestawienia ekonomiczne, statystyki itp. niech sobie programiści trzymają się choćby 2500 reguł i zasad „dobrego programowania” ;) Natomiast w grach i demach jest to zupełnie inna bajka.
    </flame>

    A bardziej poważnie to ów profesor zgubił kontekst.

    1. Action! jest językiem strukturalnym, którego nierozerwalnym elementem są zmienne globalne i w mojej ocenie używanie ich nie ma w sobie nic złego. Dlatego w innych podejściach do programowania i nowszych językach można się trzymać podobnych założeń, ale we wszystkich językach nie ma to sensu. Inna sprawa, że są problemy nierozwiązywalne bez zmiennych globalnych w np. czysto obiektowym projektowaniu. Sam widziałem jak puryści nie mogą tego przeboleć, że do kodu dodają jedną zmienną globalną :D :D

    2. Język Action! jest jednym z najwydajniejszych kompilatorów świata i powstał do programowania multimediów w szczególności do programowania gier (lub dem). Nakładanie na niego założeń jakiegoś profesora nie ma sensu, bo on myślał o ideach, a w inżynierii gier nie ma na to miejsca. Inna sprawa, że używanie zmiennych globalnych ma też poważne zalety (odsyłam do literatury np. Andre LaMothe)

    3. Programowanie małego Atari może być dziś traktowane jako programowanie systemów wbudowanych (ma te same założenia, cele, metody i ograniczenia), a tu również trzymamy się innych zasad programowania.


    Abstrahując od tego, które reguły są lepsiejsze, to w programowaniu multimediów czasu rzeczywistego (np. gier), skupiamy się na innych rzeczach (o których najczęściej profesorowie uniwersytetów nie mają bladego pojęcia :-> Czego przykładem niech będzie jedyna w PL katedra multimediów posiadająca kierunek programowania gier komputerowych. Dzięki temu, że tymi zagadnieniami zajmują się młodzi ludzie kierunek ten ma poziom światowy, natomiast gdyby było na odwrót to byłoby fatalnie... pewnie kończyłoby się na wykładzie z teorii gier i badań operacyjnych.


    Co się zaś tyczy paradoksu gdy lamer uczy programować programistę demek, to odsyłam do fajnego scrollera w demku Joyride, gdzie jeden z autorów opowiada, jak w jakiejś „wspaniałej” szkole uczyli go programować ;):)


    > Emulatorowego, wersja 2.0.

    No to być może to wiele tłumaczy, ale nie wiem czym się te wersje różnią. Dopiero staram się to wybadać, ale romów potrzebuję ;)
    A carta też chętnie kupię;)

    > Jak już znajdziesz chwilkę czasu, to ja z przyjemnością zasilę Twoją ekipę Poprawiaczy Effectusa :)

    Eeee tam moją ekipę, ale ja jestem do dyspozycji oraz czekam na inne chętne osoby.
    • 13:
       
      CommentAuthorimmolator
    • CommentTime9 Jul 2009
     
    <cite>
    3. Programowanie małego Atari może być dziś traktowane jako programowanie systemów wbudowanych (ma te same założenia, cele, metody i ograniczenia) (...)
    </cite>

    Ciekawa uwaga! Zabawę z Atari można będzie wrzucić do CV.
    • 14:
       
      CommentAuthorCosi
    • CommentTime9 Jul 2009
     
    Tdc: Wcale się nie pogniewałem, a nawet zgadzam się z Tobą :) Czasem zdarza mi się napisać coś w Perlu, a to jest język, który lubi nieeleganckie rozwiązania. Zawsze wyśmiewałem "programusiów", którzy uważali, że wszystko trzeba robić obiektowo i bezkrytycznie kopiowali rozwiązania, które im wpojono na studiach.
    Ale skoro piszę kod, który nie służy niczemu oprócz pokazania, to lubię, żeby był "ładny" i uniwersalny. Rozwiązanie, które przedstawiłem, zadziała zawsze, do którego programu byś go nie wkleił. A operowanie na zmiennych globalnych wymusza niestety jednakowe nazewnictwo zmiennych w każdym programie, w którym użyjesz tego kodu (albo ręcznego poprawiania kodu, co jest niewskazane).

    immolator: Kiedyś, kiedy jeszcze pracowałem w firmie, którą pochłonął Onet, na spotkaniu z tymże Onetem krótko o sobie opowiadaliśmy ("Jestem Józef, jestem alkoholikiem" ;-)). Jak powiedziałem, że hobbystycznie programuję Atari, to zamiast śmiechu usłyszałem pełen szacunku pomruk. Rispekt po prostu :)
    • 15:
       
      CommentAuthorKaz
    • CommentTime16 Jul 2009
     
    Projekt Effectus, jak napisal Gury, jest kontynuowany:

    ->link<-
  1.  
    Czy mozna jakos zaprogramowac karta dla atari zawartoscia ROM Action! Oryginaly sa juz raczej nieosiagalne...
  2.  
    Aaa efectus to chyba bedzie to czego szukalem (probowalem pisac pod emulatorem, ale roznice w klawiaturze PC i Atari byly zbyt duze...
    • 18:
       
      CommentAuthorKaz
    • CommentTime7 Aug 2009
     
    Gdybys znalazl jakies bledy albo mial pomysly co dalej to polecam kontakt z Gurym. To sympatyczny czlowiek, a na pewno sprawi mu radosc, ze ludzie korzystaja z jego programu i zalezy im na rozwoju.
    • 19: CommentAuthorw1k
    • CommentTime18 Sep 2009 zmieniony
     
    what is wrong here?
    PROC LINKA(BYTE X0,Y0,X1,Y1)
    PLOT(X0,Y0)
    DRAWTO(X1,Y1)
    RETURN
    MODULE;***
    BYTE I
    PROC DEMO()
    FOR i=0 to 79
    DO
    LINKA(0,0,159,I)
    OD
    RETURN
    MODULE;***
    BYTE KLAVESA
    PROC HLPROGRAM()
    GRAPHICS(7)
    COLOR=1
    DEMO()
    PRINTE("STLAC")
    KLAVESA=GETD(7)
    RETURN


    a use effectus, when i compile, effectus says:
    mwa w_param3 X1
    test.asm (21) ERROR: Undeclared label W_PARAM3 (BANK=0)
    mwa w_param4 Y1
    test.asm (22) ERROR: Undeclared label W_PARAM4 (BANK=0)
    mwa #159 w_param3
    test.asm (34) ERROR: Undeclared label W_PARAM3 (BANK=0)
    mwa I w_param4
    test.asm (35) ERROR: Undeclared label W_PARAM4 (BANK=0)
    MVA W_PARAM3 LINKA.X1
    test.asm (36) ERROR: Undeclared label W_PARAM3 (BANK=0)
    MVA W_PARAM4 LINKA.Y1
    test.asm (36) ERROR: Undeclared label W_PARAM4 (BANK=0)
    • 20: CommentAuthorGury
    • CommentTime19 Sep 2009
     
    Hi w1k,

    I checked the code you provided and there actually is the problem with handling variables in runtime.asm library file. I will go around the problem with new solution, which will be introduced in next version of Effectus. Currently, the only way to run your program is by making little modification in test.asm and compiling it with MADS.

    Find this excerpt in the output asm code:

    device #0

    .var I .byte
    .var KLAVESA .byte

    add this line:

    .var w_param3, w_param4 .word

    and compile resulting asm code with MADS. Of course, I will fix the problem in next version of Effectus.
    • 21: CommentAuthorw1k
    • CommentTime19 Sep 2009
     
    Gury, thank you, it's now good
    • 22: CommentAuthorw1k
    • CommentTime19 Sep 2009
     
    ok, i have one question .. is working FOR X=X TO X STEP command?
    and.. original action! for the atari support sin,cos? because a try today write one example from book, but not working (cos)
    • 23: CommentAuthorw1k
    • CommentTime19 Sep 2009
     
    effectus is slowest then original action! why?
    • 24: CommentAuthorGury
    • CommentTime20 Sep 2009
     
    Unfortunatelly STEP directive of FOR command is not yet implemented. I don't know if sin and cos functions are supported by Action! in base library of commands, but maybe they are in Action! Toolkit library. These and similar functions will be supported by Effectus, but probably in the form of custom functions coded by Effectus itself.

    It could be that Effectus is slower than original Action! in some ways, because it is not optimized yet. All the libraries consist of procedures and functions coded in MADS assembler language and they can be modified. Currently Effectus support only basic implementation of graphics commands, which are based on OS ROM commands. Of course everything can be optimized with custom code with caution. The number and order of the command parameters must not be changed for Effectus to work properly.

    There will be changes in the future. It all depends on my spare time and your support how Effectus will develop.

    Thank you for testing it, because it is easier for me to track down the missing features to be implemented.
    • 25:
       
      CommentAuthorCosi
    • CommentTime20 Sep 2009
     
    Gury, do you need some help with Effectus?
    • 26: CommentAuthorGury
    • CommentTime20 Sep 2009
     
    Hello Cosi, that's great idea. Thanks, I would appreciate any help with testing and coding. I will share source code for Effectus, but I have to polish the code first :)

    Let's say I will first make some more version amendments before doing so. What everybody already can do is help with testing like the w1k and some others are doing to track down all the problems, which are not few of course. Secondly, the code of runtime.asm, graphics.asm, etc. can be altered and improved. If anybody finds any improvements or bugs, just report to me. First task... Please check, if XIO function is written properly. Another improvement could be made in graphics.asm library for faster Plot function, for example.

    Greetz, we will talk again,
    Gury
    • 27: CommentAuthorw1k
    • CommentTime21 Sep 2009
     
    i want help to improve effectus, but i'm only begginer :/
    • 28: CommentAuthorGury
    • CommentTime21 Sep 2009
     
    Hey, that's ok. Any help is appreciated. What you are doing now is more than enough. We have to test Action! examples and watch the behaviour of the same program written in Effectus. Don't be surprised if strange results emerge, because the project is still in alpha phase. But this way we can better and faster handle new things to be implemented in next version.

    So, when you manage to get some time for testing, take an example, like the one in previous example, and see, if it compiles ok. Post it here or elsewhere. I opened a forum some time ago for posting any thoughts about the project, it can be found here: ->link<-
    • 29:
       
      CommentAuthorCosi
    • CommentTime21 Sep 2009
     
    Ok, first things first: windows version of Effectus doesn't recognize LF (\n or 0x0a) as line terminator. Sure, I understand that that's how the windows standard looks like, but the compiler doesn't even write a single warning! The compilation runs further until MADS reports error and stops. No explanation and the .asm code is almost empty. No way to get the reason. I spent much time trying to solve the problem, until I found out that it's all about the CR/LF.

    As of coding, I know Pascal a bit (well, I used to program in Delphi years ago), so maybe I could help with high-level procedures such as code parsing etc.
    • 30: CommentAuthorGury
    • CommentTime21 Sep 2009
     
    I will take a look at this thingy about the CR/LF. I also noticed some problems in Linux version, where some program examples just don't compile. It would really be better if source code is published as soon as possible, so such and other problems would be found faster.

    Great, such help would be more than welcome. Pascal makes good readable code, which is manageable also in bigger projects. But when code will be released, everybody is free to make another version in other languages. It's all about parsing the Action! code and use of MADS cross-assembler.
    • 31:
       
      CommentAuthorCosi
    • CommentTime21 Sep 2009
     
    I'll test the Linux version as only I have some free time.

    Other languages? How about writing an Action! parser in Python? :) It would be multi-platform and ready to embed in dozens of applications (desktop programs as well as on-line apps). Just wondering... ;)
    • 32: CommentAuthorGury
    • CommentTime21 Sep 2009
     
    No problem, you are free to do any version you like. We can consider parallel developments, why not. Whatever similar projects show up, I will stay with the one I am developing now. But the exchange of knowledge (algorithms, procedure implementations, etc.) will be easier to grasp, because more people would be involved. But as I mentioned, I will stick with Free Pascal, because it's powerful and portable to many platforms and architectures. Of course, Python, C# (Mono, Visual Studio), GNU C, etc. are all good alternatives.
    • 33:
       
      CommentAuthorCosi
    • CommentTime21 Sep 2009
     

    Gury:

    I will stick with Free Pascal, because it's powerful and portable to many platforms and architectures.

    You're right. It would be better to focus on one project instead of "parallel processing" ;-)
    Ok then, could you make a "to-do" list of programming problems? I'll try to help if I'm able to.
    • 34: CommentAuthorw1k
    • CommentTime21 Sep 2009 zmieniony
     
    i try this example

    PROC picture()
    CARD time
    INT x,y,r,i
    INT xp,yp
    Ingon()
    Poke(19,0) Poke(20,0)
    Graphics(24)
    Setcolor(2,0,0)
    Color=1
    Plot(10,85)
    FOR r=-85 to 0 step 4 do
    for i=0 to 360 step 10 do
    xp=10000/(r-65)
    yp=10000/(r+96)
    x=160+Sin(i-r)/xp
    y=96+Sin(i*2+r)/yp
    If x>=0 AND x<=319 and y>=0 AND y<=191 then DrawTo(x,y)
    FI
    OD
    OD
    time=peek(19)*256+peek(20)
    Graphics(0)
    PrintF("/E/ETest Time: /B tacts/E",time)
    RETURN


    but:
    An unhandled exception occured at $00417F82:
    EConverterError : "0 step 4 do" is an ivalind integer
    • 35:
       
      CommentAuthorKaz
    • CommentTime21 Sep 2009
     
    w1k - please use [ code ] and [ /code ] markers, it will make example easier to read. I put them to your comment, choose "zmien" (means Edit) and note how it works.
    • 36:
       
      CommentAuthorCosi
    • CommentTime21 Sep 2009
     

    w1k:

    An unhandled exception occured at $00417F82:
    EConverterError : "0 step 4 do" is an ivalind integer

    Maybe it's because STEP is not supported yet :)
    • 37:
       
      CommentAuthorCosi
    • CommentTime22 Sep 2009 zmieniony
     
    FOR loops don't work well in Linux version (only one iteration executes).
    Besides, some keywords are case sensitive - and, again, the compiler doesn't mention where the problem is. It just writes:
    .var i .
    test1.asm (8) ERROR: Bad parameter type .


    Aha, one tiny "bug" more: sometimes compiler messages are formatted in a weird way - as if there were invalid line terminators (no carriage return). It's not a big problem, however.
    • 38: CommentAuthorGury
    • CommentTime22 Sep 2009
     
    Yeah, Linux version behaves very strange, it will be looked later. First I will check case sensitiveness of Action! keywords, STEP directive, condition operators and some other things. I will also begin with preparing more readable source code for probable release.
    • 39: CommentAuthorGury
    • CommentTime27 Sep 2009
     
    Hello, you can download new version of Effectus for both Linux and Windows platform.

    What's new? ->link<-

    - STEP directive for FOR command added

    - Added support for IF and WHILE conditional expressions with OR and AND logical operators (Currently one of them can be repeated several times in one statement)

    - Eliminated limit of supporting only 255 procedures, functions and DEFINE statements

    - Fixed problem with using of three or more parameters in PROC and FUNC commands. This issue is resolved with placing new public variables in common.asm library and not relying on runtime.asm variables anymore

    - Other minor stuff...

    Remember: Effectus is still of limited usage, for example supporting only one command on the line, etc. ...
    • 40:
       
      CommentAuthorCosi
    • CommentTime27 Sep 2009
     
    FOR loops still don't work ;)
    One more minor bug: in common.asm there's an absolute path to equates.asm (should be 'lib/equates.asm').
    • 41: CommentAuthorGury
    • CommentTime27 Sep 2009
     
    Ow, you're right. I unwishingly prepared new version in the project directory. As you have maybe figured out already, just overwrite the path for equates.asm to the directory where you installed the program + \lib. Can you please describe how did you use the FOR statement? I will surely have to fix the problem with statements and commands on the same line, because also FOR i=1 to 10 DO does not work yet. What to say, I am lame ;)
    • 42: CommentAuthorGury
    • CommentTime28 Sep 2009
     
    Hi Cosi, can you tell me which keywords did you find case sensitive, so I can track down the problem faster. And was the FOR problem in Linux version? I am in the middle of radical changes of the code, so any new hints would be appreciated. Before moving to multiline command parser I will release source code, for which some additional work has to be done.

    Hey w1k, the PROC LINKA example you posted now works ok.
    • 43: CommentAuthorw1k
    • CommentTime28 Sep 2009 zmieniony
     
    gury, i dont know :(

    mva b_param1 X0
    test.asm (14) ERROR: Undeclared label B_PARAM1 (BANK=0)
    mva b_param2 Y0
    test.asm (15) ERROR: Undeclared label B_PARAM2 (BANK=0)
    mva b_param3 X1
    test.asm (16) ERROR: Undeclared label B_PARAM3 (BANK=0)
    mva b_param4 Y1
    test.asm (17) ERROR: Undeclared label B_PARAM4 (BANK=0)
    mva #0 b_param1
    test.asm (27) ERROR: Undeclared label B_PARAM1 (BANK=0)
    mva #0 b_param2
    test.asm (28) ERROR: Undeclared label B_PARAM2 (BANK=0)
    mva #159 b_param3
    test.asm (29) ERROR: Undeclared label B_PARAM3 (BANK=0)
    mva I b_param4
    test.asm (30) ERROR: Undeclared label B_PARAM4 (BANK=0)
    MVA B_PARAM1 LINKA.X0
    test.asm (31) ERROR: Undeclared label B_PARAM1 (BANK=0)
    MVA B_PARAM2 LINKA.Y0
    test.asm (31) ERROR: Undeclared label B_PARAM2 (BANK=0)
    MVA B_PARAM3 LINKA.X1
    test.asm (31) ERROR: Undeclared label B_PARAM3 (BANK=0)
    MVA B_PARAM4 LINKA.Y1
    test.asm (31) ERROR: Undeclared label B_PARAM4 (BANK=0)
    mwa Store1 KLAVESA
    test.asm (47) ERROR: Undeclared label STORE1 (BANK=0)
    • 44:
       
      CommentAuthorCosi
    • CommentTime28 Sep 2009
     

    Gury:

    just overwrite the path for equates.asm to the directory where you installed the program + \lib

    You don't need to put the whole absolute path into common.asm. 'lib/equates.asm' is enough :)

    About the case-sensitivity... I tested the following code:
    proc start()
    byte i
    for i = 1 to 10
    do
    printbe(i)
    od
    return

    and found out, that:
    * BYTE is case-sensitive; when written in lower case, there's variable type missing in asm code
    * FOR is also case-sensitive; and THIS IS THE REASON of the problem I mentioned above. When you write it in lower case, no iteration executes

    All these problems appear in Linux version. I didn't test the Windows version yet.
    • 45: CommentAuthorGury
    • CommentTime28 Sep 2009
     
    Ok, thanks. I checked this and similar problems with case-sensitiveness appear also in Windows version. Comments are another issue which will have to be looked at more detailed. Some commands with comments at the end just don't compile correctly.

    Hej w1k, I checked your graphics masterpiece and it works ok. Please check, which version do you use.

    Great, I have new official beta testers: Cosi and w1k :)
    • 46:
       
      CommentAuthorCosi
    • CommentTime28 Sep 2009
     
    /me is proud to be a beta tester :D
    Maybe some day a developer too... ;)
    • 47: CommentAuthorw1k
    • CommentTime28 Sep 2009
     
    gury, i use version 0.0.11
    MAD-ASSEMBLER 1.9.0
    • 48: CommentAuthorGury
    • CommentTime6 Oct 2009
     
    Hello,

    The program is now open source. You can do with it whatever you want. Just please don't use the name Effectus for your own project if you decide to modify the code.

    Cosi: FOR case-sensitiveness should work ok now.
    w1k: your graphics example is now part of example section page.

    ->link<-
    • 49: CommentAuthorw1k
    • CommentTime6 Oct 2009 zmieniony
     
    new version 0.0.12 :) i go testing

    i have question:
    i want create eurocalc (input slovak SKK and got EURO)

    input EURO: 40
    slovak: 1250,04

    40*30.1260

    how i can make the code? :(

    BYTE ARRAY euro(13)
    PROC Main()

    n1=30.1260
    n2=euro*n1

    Put(125)

    Setcolor(2,3,2)

    PrintE("*** EUROKALKULACKA ***")
    PrintE("Z Basicu previedol W1K, 09.2009")
    PrintE("Slovak Eurocalculator - From Basic to Action - W1K, 09.2009")
    PutE()
    PrintE("Zadaj sumu v eurach")

    InputS(euro)
    Print(n2)

    RETURN
    • 50: CommentAuthorw1k
    • CommentTime6 Oct 2009 zmieniony
     
    BYTE ARRAY euro(10),suma(10)
    PROC Main()

    n1=30.1260
    euro=suma*n1

    Put(125)

    Setcolor(2,3,2)

    PrintE("*** SLOVAK EUROCALCULATOR 0.2 ***")
    PutE()
    PrintE("Enter the amount in EURO")

    InputS(euro)
    Print(suma)

    RETURN


    aahh, i'm lame stupid man :( wrrr