Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33

Thread: FPC4GBA vs GPC4GBA :P

  1. #11

    FPC4GBA vs GPC4GBA :P

    The magic here is the {$DEFINE FPC_SYSTEM_HAS_MOD_LONGINT}, which instructs the system unit not to include the default fpc_mod_longint. It must be defined before generic.inc gets procesed; it might help moving this define up to the top of the file.

  2. #12

    FPC4GBA vs GPC4GBA :P

    Quote Originally Posted by dmantione
    The magic here is the {$DEFINE FPC_SYSTEM_HAS_MOD_LONGINT}, which instructs the system unit not to include the default fpc_mod_longint. It must be defined before generic.inc gets procesed; it might help moving this define up to the top of the file.
    And - of course - this way it works...
    I was losing myself in tons of include :doh:

    It is impressive how quick you answer my questions... Next time I'm thinking that your reply will arrive even before my (stupid) question. :lol:
    Thanks
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

  3. #13

    FPC4GBA vs GPC4GBA :P

    Next chapter!
    Now previous code returns a black screen. The asm file looks good, because it calls fpc_mod_longint, but seems that something goes wrong in the rtl.
    Another question: I have seen that in generic functions there is fpc_mod_longint and fpc_mod_qword. The gba bios has only a function for mod... It is good/enough to replace fpc_mod_qword with same code for longint too?
    BTW, I have tryied to compile rtl for smartlinking and it works pretty fine ^_^
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

  4. #14

    FPC4GBA vs GPC4GBA :P

    Hmmm... That is bad.... :? If the screen stays black that most likely means that mod doesn't work at all.

    There are two possibilities:
    * The return value of fpc_mod_longint gets lost somehow. Perhaps we did something wrong with the "bx lr" somehow (I'm an apprentice at ARM assembler :think: )
    * fpc_mod_longint overwrites a register that it isn't allowed to overwrite causing the loops to end prematurely or something.

    We need to find out which situation is the case, otherwise ne need to have Florian a look at the assembler code, he's a bit more experienced here.

    Regarding fpc_mod_qword, no, it should calculate the modulo between 64-bit unsigned numbers compared to the modulo between 32-bit signed numbers. Code designed for one calculation does not automagically work for the other...

    What kind of exe size did you get with smartlinking?

  5. #15

    FPC4GBA vs GPC4GBA :P

    Quote Originally Posted by dmantione
    There are two possibilities:
    * The return value of fpc_mod_longint gets lost somehow. Perhaps we did something wrong with the "bx lr" somehow (I'm an apprentice at ARM assembler :think: )
    * fpc_mod_longint overwrites a register that it isn't allowed to overwrite causing the loops to end prematurely or something.
    Seems like the executable goes in a bad kind of loop, because I have noticed a loss of frame rate on the emulator (working executable runs at 100%, bad one runs at 70%).
    [quote]
    What kind of exe size did you get with smart]
    Well, about 30/35 kb instead of 160. That's fine
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

  6. #16

    FPC4GBA vs GPC4GBA :P

    Quote Originally Posted by Legolas
    Seems like the executable goes in a bad kind of loop, because I have noticed a loss of frame rate on the emulator (working executable runs at 100%, bad one runs at 70%).
    That points into the direction of the second explanations, which is a bit what I was afraid of. Assuming the GBA bios does not destroy registers other than input and output, you should check if the compiler has data stored in r1 before it calls fpc_mod_longint, since r1 is destroyed by your implementation of fpc_mod_longint.

    [quote]
    What kind of exe size did you get with smart]
    Well, about 30/35 kb instead of 160. That's fine
    Yes, but it should be possible to do better. It might be an idea to check what kind of code is called by the system.pp unit initialization and kick some cruft out. But on the other hand, it's not a big priority at the moment, fast math is much more important.

  7. #17

    FPC4GBA vs GPC4GBA :P

    Quote Originally Posted by dmantione
    Quote Originally Posted by Legolas
    Seems like the executable goes in a bad kind of loop, because I have noticed a loss of frame rate on the emulator (working executable runs at 100%, bad one runs at 70%).
    That points into the direction of the second explanations, which is a bit what I was afraid of. Assuming the GBA bios does not destroy registers other than input and output, you should check if the compiler has data stored in r1 before it calls fpc_mod_longint, since r1 is destroyed by your implementation of fpc_mod_longint.
    Urgh!!! That hurts... I have found some ASM tutorials for ARM... Maybe this is the time to start reading them

    [quote]
    What kind of exe size did you get with smart]
    Well, about 30/35 kb instead of 160. That's fine
    Yes, but it should be possible to do better. It might be an idea to check what kind of code is called by the system.pp unit initialization and kick some cruft out. But on the other hand, it's not a big priority at the moment, fast math is much more important.
    I have used linux rtl and I havent removed alot of lines, indeed.
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

  8. #18

    FPC4GBA vs GPC4GBA :P

    Quote Originally Posted by dmantione
    Assuming the GBA bios does not destroy registers other than input and output, you should check if the compiler has data stored in r1 before it calls fpc_mod_longint, since r1 is destroyed by your implementation of fpc_mod_longint.
    Uhm... well, according wiht your suggestions I have tryied to save r1 value:

    [pascal]
    mov r8, r1
    swi #0x060000
    mov r0, r1
    mov r1, r8
    [/pascal]

    I don't really know if this is a suitable way to save and restore r1 value, however it does not work at all

    Looking at this doc I have tryied to tell to fpc compiler which register is affected by fpc_mod_longint function:
    [pascal]
    function fpc_mod_longint(n,z: longint):longint; compilerproc; assembler; [public, alias: 'FPC_MOD_LONGINT'];
    asm
    swi #0x060000
    mov r0, r1
    end['r0','r1','r2','r3'];
    [/pascal]

    or even

    [pascal]
    function fpc_mod_longint(n,z: longint):longint; compilerproc; [public, alias: 'FPC_MOD_LONGINT'];
    begin
    asm
    swi #0x060000
    mov r0, r1
    end;
    end;
    [/pascal]

    ...but no way. What a headache!! :fuzzy:
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

  9. #19

    FPC4GBA vs GPC4GBA :P

    are you able to maybe push r1 on a stack?
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  10. #20

    FPC4GBA vs GPC4GBA :P

    Quote Originally Posted by JSoftware
    are you able to maybe push r1 on a stack?
    Not really. Push and pop are allowed only in thumb mode, while fpc handles only arm mode. I have tryied to translate it in a couple of store and load calls, but does not works too.
    Get your fpc4gba copy now!
    Get your fpc4nds copy now!

Page 2 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •