trying to display an AGA image...

[jotd]

I've converted a PNG image to raw data + copperlist and it doesn't work as well as it should

the image is shifted

EDIT: thanks to Stingray, found out that one bitplane was missing. One error less.



what I want to achieve



the start of the pic is shifted (modulo issue?).

this is exe + source code: ecs_aga_pic_test.zip

There's an ECS (EHB) test that works perfect. The AGA test does not. That's my first AGA attempt so of course I screwed something up

For the ones who are curious:

I've got the supercars2 source code and got it running with a rebuild using OCS assets and files ripped off the original disks. I'd like to use DOS assets to pimp up the game to an AGA version: title screen, comm screens and more (colored enemy cars would be cool and/or more colors in backgrounds for instance). What's also planned: adding more tracks.

[mcgeezer]

Originally Posted by jotd

I've converted a PNG image to raw data + copperlist and it doesn't work as well as it should


- the image is shifted
- the colors are almost okay but not quite right


Attachment 71918

what I want to achieve

Attachment 71919

the start of the pic is shifted (modulo issue?). Plus the colors are perfect by moments, but completely off in some places

this is exe + source code: Attachment 71920

There's an ECS (EHB) test that works perfect. The AGA test does not. That's my first AGA attempt so of course I screwed something up

For the ones who are curious:

I've got the supercars2 source code and got it running with a rebuild using OCS assets and files ripped off the original disks. I'd like to use DOS assets to pimp up the game to an AGA version: title screen, comm screens and more (colored enemy cars would be cool and/or more colors in backgrounds for instance). What's also planned: adding more tracks.

What is you fetch mode and did you align your bitplanes accordingly?

[jotd]

fmode is at 0. Setting 3 results in trashed display.But I'd like to be able to set FMODE to the fastest.

[StingRay]

First observation: 40*240*8 = 76800. Your picture has a size of 67204 bytes (40*240*7 + 4 bytes (padding?)) so there's one bitplane missing!

[jotd]

correct! thanks a lot. The colors are now perfect. But the pic is still shifted. Check my edit.

[StingRay]

I have loaded your raw picture into a converter and it appears your source image is already shifted. How did you convert the image?

[a/b]

Several things:
- Stringray beat me to it, raw image size doesn't match bitplane size times depth, it's too short
- fetch mode is not set in the source, but you later mentioned you use 0. OK, 0 works but if you want to use 3 you have to set modulos to -8 (they are 0 now) and align the image address to a quadword (8 bytes), it's aligned to a longword at the moment.
- image is not shifted for me (it looks fine other than the missing data), maybe it's something inherited from your workbench screen (one of $dffxxx registers) because you are setting up your copper in a quick&dirty way without LoadView(NULL) etc.

[jotd]

great!

        move.w #$FFF8,bpl1mod(a5)                ; modulo de tous les plans = 40
        move.w #$FFF8,bpl2mod(a5)
        move.w  #3,fmode(a5)

and it also works. But the shift is stil there... It's not there with the ECS pic...

I have used LoadView(NULL) with same result. Edited first post with proper data (8 bitplanes)

[a/b]

I've loaded the AGA picture into piccon as 320x240x256col, and the green/red jacket guy is the last person on the right side, there is no red/blue shirt girl next to him, she is the first person on the left side of the image.
It looks like the actual data you load from disk is shifted, nothing wrong with code/copperlist.

edit:
Looking at your python script bitplanelib.py, the problem is that you have also included picture dimensions (4 bytes) at the start of AGA picture. That's causing the shift by 32 pixels.

[StingRay]

As I have already said, the source data is shifted! Either your conversion process is wrong or something else caused the shift but it's not related to the code. And adjusting the modulo for FMODE > 0 is ugly, better adapt your DDFSTOP settings.

[ross]

What I would do:

- realign the image:

    cnop    0,8
image_data:
	dcb.b	36,0
    incbin	"title256.raw"

- skip the first line now invalid:

        move.l #image_data+40,d1

- better setup the fetches and modulo:

        move.w #$00b0,ddfstop(a5)
...
        move.w #$0,bpl1mod(a5)                ; modulo de tous les plans = 40
        move.w #$0,bpl2mod(a5)

- adjust the view:

        move.w #$20C1,diwstop(a5)             ; la fenêtre écran

Try it

ah!, and also remove this damn:

        clr.w copjmp1(a5)

[StingRay]

I'd rather fix the conversion instead of dealing with an incorrectly converted image, but to each his own I guess.

[ross]

Originally Posted by StingRay

I'd rather fix the conversion instead of dealing with an incorrectly converted image, but to each his own I guess.

Absolutely right
Was just to use the available data (and can be useful for understanding alignments on AGA.. maybe.. )

[jotd]

spot on! yeah my bitplanelib (that I had developped to hack AAOW to english) has a default option to include dimensions. I overlooked it! stupid

and the display stop worked perfect. Perfect pic now!

thanks all

[a/b]

Hmm, now that's interesting. I haven't done any AGA coding, other than messing around with my old sources, in the last ~20 years and even back then it was pretty much setup a fmode 3 screen for c2p and call it a day. And pretty much any doc, aga coding guide, you name it back then said for fmode 1 or 2 you have to 32-bit align and subtract 4 from modulos, and for fmode 3 use 64-bit align and subtract 8 bytes. Which honestly didn't feel entirely intuitive to me but whatever, it worked. And that's how I always remembered it in some remote corner of my brain.
Now, if you think about it, this is not just a matter of ugliness... Does it actually mean overfetching and then correcting it via modulos? Because that's how it looks like compared to the suggested alternative.

[jotd]

ECS mode is well documented, AGA was less documented because Commodore didn't want people to bang the metal directly... All AGA docs come from reverse engineering by hobbyists.

Personally I'm lost at DIWSTRT/STOP datafetch stuff.

[ross]

Originally Posted by a/b

Now, if you think about it, this is not just a matter of ugliness... Does it actually mean overfetching and then correcting it via modulos? Because that's how it looks like compared to the suggested alternative.

This.

A good way to slow down your AGA setup..

[StingRay]

Originally Posted by a/b

Does it actually mean overfetching and then correcting it via modulos?

Yes. That's what I meant with the modulo correction being ugly.

[DanScott]

Originally Posted by jotd

All AGA docs come from reverse engineering by hobbyists.

Apart from the ones floating around in 1993 that came from Commodore

[kamelito]

Originally Posted by jotd

ECS mode is well documented, AGA was less documented because Commodore didn't want people to bang the metal directly... All AGA docs come from reverse engineering by hobbyists.

Personally I'm lost at DIWSTRT/STOP datafetch stuff.

Except the official AGA doc.