ray

excellent stuff man!

thanks very much for releasing it!

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

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' ?

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

Hi Ray,

 

probably you missed my announcement about my libraries and the way I develop for the Jaguar. This resembles to what you suggest here.

I use a cross gcc (old version 3.3.6) to compile 68k code and I interface this with assembly code that I assemble with MadMAC

Then I link all together with ALN

 

Please check this:

http://removers.free.fr/spip/article.php?id_article=92 (in French)

and the tools/libs/sources there:

http://removers.free.fr/softs/download.php

 

Cheers

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

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

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

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

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

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

hi,

great work man!

thanks for your effort.

regards

if you plan one, I want to participate !

me too of course

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

hiya,

I cannot give any things about that, because i use my Falcon for Jag coding and i have too much problem with C

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

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

Last time i tested dosbox was when it came up howto use wdb & an alpine dev env under xp... but then dosbox didnt have PPport support.....? so it was pritty pointless to use it for alpine dev. ..

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

hi there symmetry,

DosBox? ....ahhmm... unless they did some quantum leap coding to get it out of the nonworking beta stage I would sugest WMWare instead... (viritual pc perhapps) .....

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

anyhow I hope you use the latest environment, if not you can get it here:

yes, i do.

thanks for your hints though.

regards,

ray

[*]Most of us just came back from the Atari Connexion 2006, so we're still a bit tired

ok i will be patient. btw. i've seen some pictures, also of the CF presentation, a shame i couldn't have been there.

[*]AFAIK, the majority of coders here only use pure ASM, so they probably won't be able to help either (don't ask GT Turbo what he thinks of C, for example )

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

BTW, I saw your group's demo (the one with the sung lyrics) at the AC ; I was really amazed, it's truly an art piece

thanks, i'm glad you liked beams.

regards,

ray

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

[/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?

The DSP of the Jag is especially (by good fortune) designed to uncompress jpeg format which uses a cosinus transform. This job fits to The MMULT instruction. I don't know the wavelet reconstructing algorithm (not enough time to read the source code)

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.

By the way, great job Ray !

hehe, thanks.

regards,

ray

arf, damn typos: like the in in the jaggy = like the one of the jaggy

Second thing : if I understood correctly, ray's algorithm is optimized for minimum size and execution on the 68000 (no multiplications, that kind of things). What I'm thinking is : is it a good idea on the Jaguar, since we have a DSP which can do such operations ? By sheer coincidence, I've found documentation about JPEG and its derivatives two days ago, and I thought about adapting it (one day ) to display video with the JagCF board. In a nutshell, I'm wondering whether it would be more interesting to use those methods since the constraints are different from the ST's ones (of course, I'm acknowledging ray's effort).

 

What do you think of that ? (especially ray).

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