Jump to content
Jagware

SebRmv

Level1
  • Content count

    1,553
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by SebRmv


  1. I need to fill several bug reports. I have been unable to switch from MadMac to RMAC either (and feel a bit lazy to rewrite my own macro assembler :P)

    For instance, the source code of atomic (which is available on my website) cannot be assembled with RMAC.

     

     

     


  2. Hello,

     

    I recently wanted to replace original Atari MadMac and ALN from my toolchain, because the available binaries for Linux are old executables which are more and more difficult to run on recent Linux distro.

     

    I failed to replace ALN by RLN because it lacks support for archive files (used to make library of objects).

    As I had a few days off, I decided to write my own linker using a high-level language (namely OCaml).

    I have reached a point where I have something that seems to work and thus I wanted to share this development with the community.

     

    The source code is available on my github repository. As I know that installing the ocaml toolchain on Windows can be a bit tedious, I have also made available on The Removers website a 32 bits binary for Windows (of the current version).

     

    I am happy to hear your feedback regarding this tool (especially Windows users, because I use myself Linux version).

     

    Seb


  3. Thanks Shamus. Actually, I don't really need this anymore because...

     

    As I had a few days of vacation, I made my own linker using a modern language (yes, you guessed it: OCaml !)

     

    The project is hosted on github and is GPLv3.

     

    Of course, it needs a lot of testing and all that... but I managed to link some of my programs successfully, so I guess it is a good start :)

     

    The supported modes are (for now):

    - partial linking (local and debug symbols are pruned) -> O files

    - absolute linking -> ABS files with/without header and COFF files (no debug symbol, no relocatable segment)

     

    An alpha version is available here for Windows users. Your feedback is welcome :)


  4. Thanks Shamus. Actually, I don't really need this anymore because...

     

    As I had a few days of vacation, I made my own linker using a modern language (yes, you guessed it: OCaml !)

     

    The project is hosted on github and is GPLv3.

     

    Of course, it needs a lot of testing and all that... but I managed to link some of my programs successfully, so I guess it is a good start :)

     

    The supported modes are (for now):

    - partial linking (local and debug symbols are pruned) -> O files

    - absolute linking -> ABS files with/without header and COFF files (no debug symbol, no relocatable segment)


  5. Hello,

     

    I am trying to switch from aln to rln.

    I am missing one option of aln which is the flag -y <incdir> that allows to specify include directories for object and archive files.

    Is there some equivalent flag in rln?

    If not, can you please add this option?

     

    Seb

     

    Read the sources and seen that RLNPATH environment variable can be set.

    So I wrote a small patch to add -y flag, attached to this message.

     

    Now another question: would it be difficult to add support for linking with archive files? For the moment, I get "rmvlib.a is not a supported object file" error, which is a bit annoying...

     

    0001_Patch_to_add_y_option.patch.zip


  6. Hello,

     

    I am trying to switch from aln to rln.

    I am missing one option of aln which is the flag -y <incdir> that allows to specify include directories for object and archive files.

    Is there some equivalent flag in rln?

    If not, can you please add this option?

     

    Seb


  7. What are the (known) differences between these tools and madmac/aln ?

     

    RMAC/RLN mostly work, and when they don't - Shamus fixes them. The originals (and SMAC and SLN) are really, really broken. Especially in GPU areas.

     

    Ok, so basically, is it ok to assume that RMAC/RLN are compatible with MadMac/ALN, but have fewer bugs?

    (the question is: can I switch to these tools without fearing that some of my old sources won't compile/link/work...)

     

     


  8. Thanks for the quick release, but, I tried to install ocaml on windows, it works but I can't compile camlimages :/

     

    Zerosquare > thanks but I use rgb output, not cry :)

     

    Do you use a cygwin environment?

    You need to take an old version of camlimages.

    On archlinux, I packaged this version: https://aur.archlinux.org/packages/camlimages3/

    I guess it should compile/work the same on windows/cygwin.

    I hope you manage to compile it, because I am a bit lazy to install cygwin myself.

    Please let me know. If you can't do it, I'll give it a try next tuesday at my office during the lunch break.

     


  9. Just added the --header option. The source is available on my website.

    It emits two words and a long corresponding to the height of the picture, the width of the picture, and the flags for the blitter (PITCH, DEPTH, WIDTH): this is to mimick tga2cry behaviour.

     


  10. Thanks for the suggestion. I will add the option very soon (hopefully tomorrow).

    What is the exact behaviour of tga2cry when the --header option is enabled?

     

    Once added, I plan to make a source release. Will you be able to build yourself the binary? I have not the compilation chain setup for windows...

     


  11. Hi Seb,

     

            .globl  _video_height
            .globl  _a_vdb
            .globl  _a_vde
            .globl  _video_width
            .globl  _a_hdb
            .globl  _a_hde
    
            .globl  _vblPerSec

    Sorry, I still don't get this part.

    I just said that in the original crt0.s I provide with jlibc, these variables are declared global and are visible from any other module.

    So, what is the issue with these? Is it just a matter of naming?

     

    I renamed the variables for my use. I used different names because i like the camel convention from Pascal. And i like a prefix which indicates, what part of the system belongs to this. So my names for this variables all start with Vid because they describe the video parameters. There is no need to rename your variables.

     

    You can ignore this part of my patch.

     

    Best regards

    Michael

     

    Ok, got it!


  12. Regarding the defined variables (width, height, ...), I don't really understand your point since I declared globl the following ones in crt0.s:

            .globl  _video_height
            .globl  _a_vdb
            .globl  _a_vde
            .globl  _video_width
            .globl  _a_hdb
            .globl  _a_hde
    
            .globl  _vblPerSec

     

    And these are accessible from C as any other global variables (and are used in rmvlib for instance).

     

    It is my personal name convention. So you can ignore this part of my patch.

     

    Sorry, I still don't get this part.

    I just said that in the original crt0.s I provide with jlibc, these variables are declared global and are visible from any other module.

    So, what is the issue with these? Is it just a matter of naming?

     


  13. what was wrong with crt0.s in jlibc? I don't think I understood the reason why you changed it.

     

    Your crt0.s calls _main which is main() in C. Your init function of start.c is __main() which is ___main in assembler. So the init function of the jlibc is never called automatically. Instead your startup code jumped directly to the main function of a user.

     

    I let crt0 call the init function of start.c ___main in assembler and __main() calls main(). You can instead call main() from crt0.s I don't know, what is the usual way. But usually the initialization of the c lib is done automatically from the startup code and not from the user.

     

    I made also some other modifications. The ctr0.s was derived from the startup examples from Atari. This code defines a object list with 1 bitmap an initializes the graphic system. The initialization of the graphics system set some variables e.g. screen width and screen height. I have used global variables which i can access from C (leading _) and modified the name. So i was able to initialize a object list with the same bitmap than the Atari examples from C in my main() function. Your crt0.s hides these values. This is more important for my own code. But i think, to make these variables visible to other functions is also useful for others. We can check, if the other Jaguar libraries like the raptor lib or the removers lib uses these variables.

     

    For the memory management i made also a modification. I have a variable _end which was used inside start.c for set get the address of the unused memeory ínstead of BSS_E. This is also vbcc specific.

     

    Ok, I understand. Actually, I think it is gcc vs vbcc issues.

    The code generated by gcc calls the function __main from main. So the crt0.s does not need to call it itself.

    (see http://gcc.gnu.org/onlinedocs/gccint/Initialization.html the part on __main)

     

    Maybe we can tweak something with #ifdef so that the "same" code works with gcc and vbcc.

    Is there a macro variable defined by VBCC that indicates that VBCC is the current compiler? I know for sure gcc defines _GNUC_

     

    Regarding the defined variables (width, height, ...), I don't really understand your point since I declared globl the following ones in crt0.s:

            .globl  _video_height
            .globl  _a_vdb
            .globl  _a_vde
            .globl  _video_width
            .globl  _a_hdb
            .globl  _a_hde
    
            .globl  _vblPerSec

     

    And these are accessible from C as any other global variables (and are used in rmvlib for instance).

     

    The variable BSS_E is generated by madmac and is declared global. Cannot you use it from vbcc?

     

    Seb

     

    PS: by the way, I am pretty sure that raptor does not use jlibc at all.


  14. Hi Michael,

     

    what was wrong with crt0.s in jlibc? I don't think I understood the reason why you changed it.

     

    Cheers,

     

    Seb

     

    PS: I just backported some of your patches to github repo, thanks again for your work. (https://github.com/sbriais/jlibc)

     

    Just for my information, is it the case that vbcc does not support

    - constructions like *(x++) = y and

    - variable declarations anywhere else than at the beginning of a block?

     

    PPS: where can I get vbcc?


  15. That's interesting. I'll have a look at your patches to see if some can be integrated to jlibc directly. (remove C++ comments, ...)

     

    Regarding the memcpy done by blitter by default, I don't think it is a good idea. This is funny because I had a talk with Matmook at the latest RGC and we agreed that implicit calls to blitter are never a good idea.

     

    I think it's better if the programmer has the complete control on how he manages the blitter. Imagine for example that you call a GPU rendering routine that uses the blitter, and that concurrently your m68k code calls memcpy: with your approach, this will fail.

    This scenario may happen because the C compiler may insert some calls to memcpy/memset when complex struct are copied/initialized.

     

    That is why I made the choice to have pure m68k version of memcpy/memset in jlibc.

    However, in rmvlib, I have defined two functions blitcopy/blitset that have the same API as memcpy/memset but these functions use the blitter. If the programmer wants to make fast memory transfers, then he explicitly uses the blitter (and thus he is aware that the blitter cannot be used concurrently by another "thread")

     

    Cheers

     

    Seb

×