Jump to content
Jagware

SebRmv

Level1
  • Content count

    1,553
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by SebRmv

  1. Jaguar Image Converter

    Hello, I am proud to announce that I have finally managed to compile a version of my Jaguar Image Converter for Windows XP and Linux which does not require additionnal packages or softwares to be installed You can find the binaries there: http://removers.atari.org/softs/download.php Enjoy ! Seb PS: for other binary release, please contact me... PPS: under windows, you do not need to install cygwin, you just need to have the file cygwin1.dll which is included in the package I have made
  2. RLN

    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
  3. RMAC

    I think it makes sense to create also this topic
  4. RMAC

    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 ) For instance, the source code of atomic (which is available on my website) cannot be assembled with RMAC.
  5. 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
  6. RLN

    An alpha version is available here for Windows users. Your feedback is welcome
  7. RLN

    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)
  8. RLN

    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
  9. What kind of bugs? I must have been lucky, but I haven't had any problems with Atari's ALN and MAC. I am not surprised that Mac/Aln are broken. But as you, I must have been lucky because I can't remember having a serious problem with Atari tools.
  10. 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...)
  11. Ok thanks! What are the (known) differences between these tools and madmac/aln ?
  12. I can't remember where to find MadMac and ALN source code? Do anyone know that?
  13. Jaguar Image Converter

    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.
  14. Jaguar Image Converter

    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.
  15. Jaguar Image Converter

    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...
  16. SCPCD-day

    Happy birthday to both of you!
  17. Gt Is The Man Of The Day

    Happy birthday my friend!
  18. Another.....

    Thank you !
  19. You can get the vbcc ready for linux from http://www.hillsoftware.com/files/atari/jaguar/ Download the file jaguardevlnx.tar.gz The vbcc was located under the path jaguar//jaguar/bin Best regards Michael Thanks! I will give it a try.
  20. 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!
  21. 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?
  22. 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.
  23. 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?
  24. 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
  25. Impulse

    This looks really great!
×