Jump to content
Jagware

ray

Members
  • Content count

    50
  • Joined

  • Last visited

Everything posted by ray

  1. Jaguar Gpu Debugger

    excellent stuff man! thanks very much for releasing it!
  2. Cross Gcc?

    hello guys, check this out: http://vincent.riviere.free.fr/soft/m68k-atari-mint/ marvellous work.. the guy describes how to build a Cross GCC for windows (even supporting C++ features and 68k inline assembly) which outputs TOS executeable m68k code using cygwin. as far as i'm concerned i think this might be an option for developping jaguar executeable code, too. one would need to build a standard library (and maybe a mathlib would be helpful) though and if i'm right it currently only outputs GCC like objects/old DRI formatted ones, so no BSD objects like processed by ALN - which would also prevent one from using external GPU/DSP objects build using MADMAC - but maybe swapD0's JAS could be a solution there (hey there mate) in case he'd rework his object output-format *hint* *hint* . regards, ray
  3. Virtual Jaguar Bjl Bin File Support

    that's some cool news mate. plus it actually works. can you tell me where to get the sources? i might be interested in optimizing the thing a bit (just an idea, maybe we coders here on jagware could join forces in order to do so). regarding the debugging, i got in touch with swapd0 recently, beggin' him to port JDB to windows/linux or at least to release the source and he said that it would be feasible (don't quote me on that, those aren't any official news of course) - so combined with is already working packet-loader on the jaguar side, we could finally have a working graphical debugger. kind regards, ray
  4. Cross Gcc?

    hey there patrice, first of all, you are right about the need of up-to-date assembler + linker tools. secondly, don't get me wrong, no offense taken here (especially since i plainly missed the existance of SebRmv's work on building the m68k-aout gcc + a more or less decent jaguar libc) you should maybe check the following links on swapd0's excellent 68k/gpu/dsp assembler called jas here: http://www.freewebs.com/swapd0/tools.html#Jas http://www.jagware.org/index.php?showtopic=365 http://www.atariage.com/forums/index.php?s...;p=1112868& and maybe my dropped work on atari's GASM sources here: http://www.jagware.org/index.php?showtopic=291 kind regards, ray
  5. Cross Gcc?

    okay mate this is *excellent* work . an english translation of the attached article would be highly appreciated though. maybe i will finally sit down an implement a hopefully decent math-library using DSP/GPU calculus once i got it installed properly (as i said and english translation of that article would be great). best regards, ray
  6. Cross Gcc?

    hi there seb, in fact i missed your "announcement", but this is truly cool news, i'm gonna try it out. did you happen to talk about this with with swapd0? i mean he could "easily" incorporate support for gnu like objects into JAS and we would finally have a modern SDK. regards, ray
  7. Little Announcement

    hi there people, it has been rather quiet around my jaguar related activities, i am again quite busy with my exams and jobbing, so sorry for that. first thing ahead, those are great great news about the JagCF board it looks the project is finally getting somewhere, great great work is all i can say! on the other hand i'm wondering, how's swapd0 work on the jaguar GPU/DSP/68k assembler progressing, i haven't talked to him in a while. he also mentioned he had some (vague) plans for developing a 68k C compiler suiting his assembler package, but if i got him right he said that he wanted to finish JAS completely beforehand and he had some issues with C's typecasting rules because he could not find any info on that. does anyone have some news on that? i also searched the net on building an up-to-date cross 68k gcc for a jaguar target, it should be feasible but it seems that no-one did succeed in doing so yet (a retargeted djgpp as a compiler used in Atari's SDK would be a good option as long as it would still run under windows 2000 >). just some additional thoughts: i think i'll finally take a look into my compiler building class during the next semester. they talk about a programming language description language + tools called "LiSA" (dunno if anyone has heard about it, but i'm sure it's a very generic thing) and it should be easy to build our own tools (at least an apropriate C compiler + linker to produce jaguar executable 68k code - linking in JAS objects could then hopefully be an option to use DSP/GPU modules from there). study-related i recently "rediscovered" my enthusiasm for digital signal processing and programming digital signal processors (an rather modern ADSP21065 by analog devices in my case) so i decided to come up with some tools for the Jaguar's more powerful processors, which is what my announcement is about (i'm still working on all of those things, so i hope i will be able to release them soon, but please don't expect too much since as i pointed out already i am rather busy especially at the moment): -a C math (standard math-lib like) - umm - library supporting 16:16 fixedpoint numbers and standard trigonometric/hyperbolic and transcendent operations invoking the DSP/the GPU -an <=128 point FFT (so i can directly use the chips internal ROM sine-table) for the DSP which might be an interesting thing for sound synthesis/filtering or just something to experiment a bit etc. -a fast DCT (probably <256x256 points) for the GPU just for fun as i had great results filtering images in the frequency domain using rather long impulse responses which wouldn't make it a lot (at least realtime applicable) fun when applied in the time domain the latter one is not started yet at all... i have some other ideas like an EZW like image coding sheme to overcome some of BPEGs weaknesses (8x8 DCT artefacts and such). i don't know which of those projects will ever make it to and finally see any daylight, but stay tuned and keep watching my page (http://ray.tscc.de) and feel free to maybe send in some motivation emails encouraging me to make a little comeback since i have so much love for the scene best regards, ray
  8. Gasm Sources....

    hi there, i though someone might be interested, i've found C sources to a simple GPU assembler that was supposed output object code for "oberon", the jaguar II's GPU. as it seems to be downwards-compatible with the jaggy's GPU this might be an option to make up a portable development environment (maybe along with some decent open source 68k assembler) as an alternative to madmac, which for instance doesn't run under win nt/2000/xp etc., with some slight rework. let me know what you think, please... here's the url: http://archives.atarimuseum.com/archives/f.../jag/oberon.zip -> /soft (warning: the archieve is ~18.4 Mb large) regards, ray
  9. Gasm Sources....

    ok guys, i finally decided to cancel my work on the GASM-project. i'd like to use this chance to do some advertising, though: thanks to GT i recently discovered another very promising assembler called jas which has been created by roberto nadal martinez, which is also capable of handling 68k sections, unlike GASM. maybe you've already heard of that...roberto used to compile his projects for BeOS, but due to request he now build a windows version of jas, as well. you can now get hold of it over at his site, here: http://www.freewebs.com/swapd0/tools.html -> jas (he also has some promising projects like a remote debugger for BJL and such - again, built for BeOS unfortunately). he seems to be a very friendly guy, who is open to suggestions and coorporation, at least i've had some requests in making this assembler more madmac compatible + some bug-reports and he quickly responded to my emails. atm. it has become very close to madmac's behavior except it doesn't support macros. it doesn't need any linker, either since it's able to operate like one on it's own and it's also capable of outputting diffrent formats, such as no-header, gemdos-header, an own object-file format. there are also some built-in macros to support subroutine calls in dsp/gpu programs (call/rts, fastcall/rts) and some useful extended in/decremental pseudo addressing-modes like load (rn)+,rn etc. . take a look into the readme file or drop him an email in case you have more specific questions. regards, ray
  10. Gasm Sources....

    hiya, ok, i've done some work now and here's the priliminary result. you can watch what it's up to by now and compile the stuff for your platform (provided as dev c++ project): http://ray.tscc.de/lost+found/readme.txt (it'd appreciate if you'd read that first) http://ray.tscc.de/lost+found/gasm.zip (please do not spread ) here's an expample listing as outputted by GASM from one of my little screens: http://ray.tscc.de/lost+found/gputest.lst (please do not spread, either) please let me know what you think, or if you find bugs. it also appreciate some support regarding the linker question (refer to readme.txt), a CVS should be up soon. regards, ray
  11. Jaguar Image Converter

    hi, great work man! thanks for your effort. regards
  12. A Jag Mega Demo, It's Possible ?

    me too of course
  13. Gasm Sources....

    ok mates, i've now taken a further look over the sources and with some slight rework i think this stuff could be expanded to a fully useable standalone DSP/GPU assembler. atm. it uses the C-preprocessor to resolve equates/expand macros before it sarts assembling, so it uses some rather strange pseudo-opcodes like "INT" to define a longword or "FLOAT" to define a 16:16 fixed value (?!), CODE_SEG and DATA_SEG and so on. it also does not expect immediate values to be prefixed by "#" so it's supposed to mean "shlq 1,r0" instead of "shlq #1,r0" for instance. but as i said, with some rework this stuff could be resolved. the main problem i see at the moment is that it only supports two binary output-formats (executeable & rom), so the linking stage is omitted and hence there isn't any mechanism to im-/export symbols and of course link several modules etc., which makes it rather pointless to this moment - i assume Atari designed their new GASM that way since oberon was supposed to overcome the former bug of not being able to execute code (sic) from external ram anyway. it'd appreciate support nonetheless, maybe i can make up a little CVS during the next few weeks, if anyone is interested. regards, ray
  14. Gasm Sources....

    hiya, imho C is a nice language even if many ppl won't agree with me in that point...we also have a cross-gcc to output jaguar GPU/68k object code so i'd definately recommend you to take a look at it. it's easy to learn as well imho, but that's not the point. anyway those given GASM sources are documented and written in a horrifying way in my humble opinion. nonetheless with a tiny bit of rework i managed to recompile them using the current gcc but yet without any success in executing the binary afterwards, i assume there is a problem with calling C preprocessor out of GASM so i believe i'm close to spotting it. however, this might be a decent base to develop a decent assembler like madmac on it, at least much better than from scratch. and btw. from what i can see from the instruction-definitions the Jaguar II's DSP/GPU were supposed to have some additional opcodes and support for big jumps by +/-512 words. definetely worth taking a look at i'd say, regards, ray
  15. Gcc Setup Trouble...

    hi there mates, i'm obviously having some trouble in getting gcc v2.6 (AGPU/M68K version) to run properly after all. i've modified the SPECS files and also setup the needed environment variables. gcc seems to hang into running madmac though, meaning it will produce (a rather unoptimized btw.) assembly source from the compiled c-source but then nothing happens. i'm using dosBox so this might be the problem, i'm not sure. invoking madmac manually works of course but the gcc processor seems to have trouble, here's one of my SPECS files though (i thought the first line should be -cmac -fb, but that doesn't seem to help, either ) *asm: -cgcc -fb *asm_final: *cpp: -nostdinc -Ic:/dokume~1/reimund/desktop/Atari/stuff/jaguar/include *cc1: -fno-builtin *cc1plus: *endfile: *link: *lib: %{g*:-lg} %{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p} *startfile: %{pg:gcrt0.o%s}%{!pg:%{p:mcrt0.o%s}%{!p:crt0.o%s}} *switches_need_spaces: *signed_char: %{funsigned-char:-D__CHAR_UNSIGNED__} *predefines: -DJAGUAR -Amachine(JAGUAR) -DAGPU -Acpu(AGPU) *cross_compile: 1 helpful suggestions are really welcome, regards, ray
  16. Gcc Setup Trouble...

    ah that's annoying, for a BJL setup, things work well since zerosquare has already written a windows 2000/XP compatible uploader...yo might also want to try allowio.exe providing direct LPT-acces to get your alpine tools going under windows NT/2000/XP it also works with the BJL-uploader. concerning the gcc-setup i got things running well now by just removing the -B (BINDIR) directive from the commandline ...cheers! regards, ray
  17. Gcc Setup Trouble...

    hi there symmetry, in fact DosBox works rather great, it runs madmac, aln and other legacy programs flawlessly (even quake and such), it also runs gcc (both the 68k and the gpu compiler) but halts at the point it is about to run madmac+aln for assembling and linking the produced sources, so it's just a stone's throw away from working it seems (as i mentioned, the compiler actually manages to output decent-looking madmac asm sources into the temp/source directry from the processed c-sources, but manually compiling all of these doesn't appear like a feasible solution to me). yes, i do. thanks for your hints though. regards, ray
  18. Gcc Setup Trouble...

    ok i will be patient. btw. i've seen some pictures, also of the CF presentation, a shame i couldn't have been there. yes, i used to be (and still am in some situations) a complete asm maniac, and of course i see where it makes sense to write handoptimized asm code, which is also very interesting and neccessary in many situations on the jaggy - i agree. but on the other hand i've grown a bit tired/lazy of/by coding large projects completely in 100% asm even where some quick lines of C would have made sense at some places. and hence i thought it would be nice to have a running GCC setup, that's my whole point thanks, i'm glad you liked beams. regards, ray
  19. A propos de l'uploader Bjl

    [/color]I made a modified version of the BJL uploader for Windows XP without using PortTalk, it seems to work better for Azrael than the existing one. If you're interested, you can download it here. cool stuff, thanks for your effort, it ss _very_ appreciated. it works great and i don't have to use this annoying allowio-tool anymore. but still, is there any chance to get rid of that bug which makes the jaggy hang on into the loader screen after the upload has finished?
  20. Biq, The Bpeg Alternative !

    ok, the DCT as well as the DWT (as used in BiQ) are ideally suited for implementation via MMULT and vice versa - i don't want to sound like a smartass, but it just so happens that matrix-multiply/multiply and accumulate operations are a natural thing in digital filtering and signal processing (which is a much wider range than just image encoding), so it's self-evident that DSPs (like the in in the jaggy) do have hardware-support for those - otherwise they wouldn't be called DSPs . ah and btw. azrael: the DWT is a very interesting topic to read into, and if you're already familiar with the DCT maybe you have a little advantage in understanding the filtering methods. hehe, thanks. regards, ray arf, damn typos: like the in in the jaggy = like the one of the jaggy
  21. Biq, The Bpeg Alternative !

    hi there zerosquare, using the DSP's/GPU's quick multiplication or multiply and accumulate instruction it might be feasible to improve BiQ's wavelet filters to use for instance daubechies or mexican hat wavelets instead of haar in the future which are known to produce lesser blocking artifacts. i still need to port the decoder to the GPU so we could think of that in the future but in general, BiQ is supposted to be all about small size which of course is an issue on the DSP/GPU, so i don't think the port of a simple JPEG decoder could be that. be=beat, sorry
×