Patrice Mandin

Merci à tous.

(désolé, j'ai pas trouvé d'autre gâteau Resident Evil)

Pas grave, c'est l'intention qui compte. Merci.

N'anniv GT

That's why loading some prog on my falcon took so much time ... Very Interesting !

 

And since TOS 3 (TT, which is the first to have FastRam), there is the FastLoad bit in the GEMDOS program header, which tells the TOS to not zero the BSS section, and leads to fast load times. When you have a 14MB (or more with FastRam) Falcon, program start up time is a bit long without this bit set.

 

Merci à tous.

I did find this link cross compiler gcc 4.x for atari st ?

 

Is this something usefull aswell ?

This is a cross-compiler to build Atari ST programs from a different machine (windows, mac or linux based). The difference with sebrmv' one is only the target system (simple m68k-coff output to be put in jaguar for seb, and .prg/.tos m68k program for Atari ST in vincent's case or on my site). And you can build gcc to build for different targets.

sdl port

With Seb/Rmv gcc m68k for Jag, a m68k version could be done for Jag as a start. Then the video and audio parts could be rewritten in GPU/DSP risc asm for better usage of TOM & JERRY. Definitely would be a huge helper to get some software on Jaguar, if properly done.

quake engine

This one is very heavy on processing power and RAM usage, maybe having a look at the Nintendo DS port will give you some directions about what to do or not. But definitely, it requires a FPU, so maybe the JagCF DSP could help, but not on a standard Jaguar.

mesa / opengl

Same category as quake from my point of view. Would be better to get a lightweight OpenGL library like TinyGL.

gameboy emu

This one could be done on the Jag, even standard.

pmdoom/hexen all look very cool

Doom already exists for Jag, so Heretic and Hexen could be also. But I know they both requires a bit more memory than Doom.

 

What is really needed on Jag is proper development tools and docs. madmac/aln and other old tools are not easy to run on recent platforms.

If I'm right, madmac is the gpu assembler, and aln is the atari linker, so what would be needed:

- gpu/dsp assembly language support in gas (GNU assembler) to replace madmac

- gpu/dsp object file support in ld (GNU linker) to replace aln

 

The problem is that I don't know if ld could link objects of different cpu together (like a m68k object file with a gpu object file). Also to be more complete, we would have to define a target for gnu binutils for jaguar gpu stuff (gpu-atari-jaguar or something like that). Seb already used m68k-aout (generic) for its gcc kit.

 

Also, a bigger long term goal would be compilation of C code into gpu/dsp assembly. With the jagcf dsp coming soon, the ability to directly compile C code would come handy.

 

How many times did I use 'would' ?

I just had a quick look at your library documentation. It could be possible to use it as a SDL backend for Jaguar, if we

add some missing stuff required (maybe some libc functions for example, or specific video or audio related tasks).

 

Even if the first versions would be for m68k and debugging, audio and video drivers for SDL could use GPU and DSP for fast work.

 

Disclaimer: it does not mean I will work on it now , just wanted to say that SDL for Jaguar is doable.