new PNG to ILBM converter for Amiga, MorphOS, Linux, FreeBSD, Haiku and Solaris

[Don_Adan]

Originally Posted by TCH

You mean this instruction itself is illegal? Why?

I dont know. This is info from my assembler book, and if I remember right I never find similar instruction in resourced code.
Anyway You can try to assemble this instruction in Vasm or Phxass, or other assembler, and check result.

[modrobert]

Originally Posted by TCH

- http://oscomp.hu/depot/png2ilbm_1.1....miga-68020.lha
- http://oscomp.hu/depot/png2ilbm_1.1....8020+68881.lha

Could someone test it on a real hardware too, that it is giving GURU $80000004 there too?

Those two GURU with $80000004 for me on the A1200 (see signature for details).

What version of SAS/C are you using?

You can find SAS/C 6.58 plus Y2K patch here.

[TCH]

Originally Posted by Don_Adan

I dont know. This is info from my assembler book, and if I remember right I never find similar instruction in resourced code.
Anyway You can try to assemble this instruction in Vasm or Phxass, or other assembler, and check result.

You're right. I tried it here. Result was

Error on line 4: Incorrect first operand addressing mode, received "(An)+", expected "(An)/Ea/<LABEL>"

So, that concludes it: without that 'fprintf()' SAS/C generates an illegal instruction there. Strange though: according to the opcode table, it should be fine.

Originally Posted by modrobert

Those two GURU with $80000004 for me on the A1200 (see signature for details).

Thanks. Thought so, that it should not make any difference.

Originally Posted by modrobert

What version of SAS/C are you using?

You can find SAS/C 6.58 plus Y2K patch here.

Same. It can be downloaded from here too:
http://oscomp.hu/?details/SAS%2FC_6.58_Amiga_840
http://oscomp.hu/?details/SAS%2FC_6....atch_Amiga_841

[Don_Adan]

Seems to be compilator bug. Some compilators creates f.e.
move.b Dx,Ax
code, which is illegal too. Even if in theory it can works as extb.l command.

[TCH]

Well, thanks for the info. At least we know now why it caused $80000004. So, just like in the story of E-Penguin: the 'fprintf' stays, "do not remove"...

[modrobert]

8.System:Temp/png_test> timeit png2ilbm test.png test_fpu.iff -bp=4 -w=300 -h=200

Decoding test.png...
Rendering...
Rescaling...
Quantizing...
Saving test_fpu.iff...

Elapsed: 4m 44.25s

8.System:Temp/png_test> timeit png2ilbm_nofpu test.png test_nofpu.iff -bp=4 -w=300 -h=200

Decoding test.png...
Rendering...
Rescaling...
Quantizing...
Saving test_nofpu.iff...
 
Elapsed: 12m 45.97s

Pretty big difference between png2ilbm v1.1.4 68020+FPU version compared to 68020, roughly three (~2.80) times faster with FPU.

[TCH]

Not surprising at all, considering how much floating point-based calculations it uses. That's why i provided the FPU-supporting binary.