Devpac bug...?

[pmc]

Watcha people

I've just finished working on a demo routine recently. While I was working on it I noticed some strange behaviour while assembling it in Devpac.

Basically the top portion of my screen is a five bitplane display then, at a certain line, I swap all the registers round with the copper list so that the rest of the screen is two bitplanes.

I have lots of data for various things in the code and I noticed at one point that after adding some data, the logo being shown in the 5 bitplane portion of the screen was corrupted. I took the data I added out again - the corruption went away. I moved where this data was added in the source to below the logo data and the corruption moved into the two bitplaned portion of the screen.

I checked all the usual stuff like everything being word aligned and made sure I was definitely setting everything correctly with the copper list and all looked OK.

Anyway to temporarily get round the problem I just added a "buffer" section of blank data that cleared the corruption when assembling and running the source from within Devpac.

However, if I then assembled this source (with "buffer") as a file and ran it outside Devpac - there was the corruption. So, I removed the "buffer", re-assembled as a file and ran outside Devpac - the corruption was gone.

It seems to be that with the "buffer" there's no corruption when run from within Devpac and without the "buffer" there's no corruption when run outside Devpac.

Apologies for this rambling explanantion but my question is - has anyone else ever seen Devpac or any other assembler kind of doing weird stuff with data in memory like this?

Or, more likely () is it me and not Devpac that's screwing something up...?

[musashi5150]

Devpac does have it's own quirks sometimes. I haven't seen anything like you describe but when doing a WHDLoad patch if I assemble with Devpac it will crash. If I assemble the same code with AsmOne it works perfectly. It could be that one of the optimisation options is doing something odd perhaps?

Maybe you could try and assemble with AsmOne and see what happens?

[pmc]

Watcha mate

Hmmm - OK, so it might genuinely be a bug or some other kind of weirdness then...

I'll take your advice and try assembling with something else and see what happens.

[StingRay]

Hmm, might be you trash memory somewhere? Also, did you try to assemble with optimisations turned off? Does it still happen then?

Edit: easy check: Assemble with Asm1 and check what happens.
Edit2: should read Musashi's post before ;P

[Leffmann]

Do you calculate the bitplane pointers somehow, or just mark with labels and refer to them by their absolute addresses? If bitplanes start looking weird as soon as you move them a bit then it sounds like you're not setting the right address.

In any case I'd turn optimizations off. They're less useful and with asm I guess it's better if you see exactly what's going on.

[Galahad/FLT]

Make sure you're not using Master Devpac, thats a hacked version and its totally unreliable.

[Asman]

First at all you should read all posts before + I think that good idea is restart and try to assemble source on plain machine.

[pmc]

@ Sting - tried turning off optimisations - that makes no difference. Next thing on my list to do is assemble in AsmOne and see how that goes.

@ leffman - for the bitplane pointers, I just lea xxx(pc) them and then push the high / low addresses into the right places in the copper list. Normally I'd agree - if I move the display data and things go weird I'm just setting the wrong addresses but get this:

As part of my routine I use the blitter to clear both bitplanes of the two bitplane display every frame - even though I do that the corruption still shows! I can even still see the things I should see on the screen all drawn OK just with the corruption kind of "superimposed" over the top. First I thought I might just still be displaying an errant 3rd, 4th or 5th bitplane but I've checked and double checked and I'm definitely turning those bitplanes off.

Now, correct me if I'm wrong but that *really is* weird!

@ Galahad - I tried assembling with two different versions of Devpac, one I've had since I bought it and the other an updated version I downloaded from the EAB FTP server. They both exhibit the same behaviour. Out of interest, and sorry if this is an obvious question but it might help me avoid future grief - how would I know I'm using Master Devpac? - does it identify itself in some way?

[Leffmann]

The corruption has to be bitplanes or sprites. Paste the copper list and any code that initializes display related registers!

[StingRay]

Wrong BPLCON0 settings maybe?

[pmc]

@ leffman - now you're asking me to post my top secret code!

Here's the routines that intialise the bitplane and sprite pointers:

 
.set_logo_bpls: lea pc_extend(pc),a0
 movea.l a0,a1
 adda.l #logo-pc_extend,a0
 move.l a0,d0
 movea.l a1,a2
 adda.l #lg_pl1_l-pc_extend,a2
 movea.l a1,a3
 adda.l #lg_pl1_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 swap d0
 add.w #logo_bplsz,d0
 movea.l a1,a2
 adda.l #lg_pl2_l-pc_extend,a2
 movea.l a1,a3
 adda.l #lg_pl2_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 swap d0
 add.w #logo_bplsz,d0
 movea.l a1,a2
 adda.l #lg_pl3_l-pc_extend,a2
 movea.l a1,a3
 adda.l #lg_pl3_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 swap d0
 add.w #logo_bplsz,d0
 movea.l a1,a2
 adda.l #lg_pl4_l-pc_extend,a2
 movea.l a1,a3
 adda.l #lg_pl4_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 swap d0
 add.w #logo_bplsz,d0
 movea.l a1,a2
 adda.l #lg_pl5_l-pc_extend,a2
 movea.l a1,a3
 adda.l #lg_pl5_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 rts
 
.set_bitplanes: lea pc_extend(pc),a1
 movea.l a1,a0
 adda.l #screen-pc_extend,a0
 move.l a0,d0
 movea.l a1,a2
 adda.l #plane1_l-pc_extend,a2
 movea.l a1,a3
 adda.l #plane1_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 swap d0
 add.w #screen_bplsz,d0
 movea.l a1,a2
 adda.l #plane2_l-pc_extend,a2
 movea.l a1,a3
 adda.l #plane2_h-pc_extend,a3
 move.w d0,(a2)
 swap d0
 move.w d0,(a3)
 rts
 
.set_sprites: lea pc_extend(pc),a0
 movea.l a0,a1
 movea.l a0,a2
 adda.l #spr5_ptl-pc_extend,a1
 adda.l #spr5_pth-pc_extend,a2
 adda.l #spr5_star-pc_extend,a0
 move.l a0,d0
 move.w d0,(a1)
 swap d0
 move.w d0,(a2)
 lea pc_extend(pc),a0
 movea.l a0,a1
 movea.l a0,a2
 adda.l #spr6_ptl-pc_extend,a1
 adda.l #spr6_pth-pc_extend,a2
 adda.l #spr6_star-pc_extend,a0
 move.l a0,d0
 move.w d0,(a1)
 swap d0
 move.w d0,(a2)
 rts

and here's the copper list:

my_cop_list: dc.w bplcon0,%0101000000000000
 dc.w bplcon1,$0000,bplcon2,$0000
 dc.w diwstrt,$2c81,diwstop,$2cc1
 dc.w ddfstrt,$0038,ddfstop,$00d0
 dc.w bpl1mod,$0000,bpl2mod,$0000
 dc.w bpl1pth
lg_pl1_h: dc.w 0
 dc.w bpl1ptl
lg_pl1_l: dc.w 0
 dc.w bpl2pth
lg_pl2_h: dc.w 0
 dc.w bpl2ptl
lg_pl2_l: dc.w 0
 dc.w bpl3pth
lg_pl3_h: dc.w 0
 dc.w bpl3ptl
lg_pl3_l: dc.w 0
 dc.w bpl4pth
lg_pl4_h: dc.w 0
 dc.w bpl4ptl
lg_pl4_l: dc.w 0
 dc.w bpl5pth
lg_pl5_h: dc.w 0
 dc.w bpl5ptl
lg_pl5_l: dc.w 0
 dc.w bpl6pth,$0000,bpl6ptl,$0000
 dc.w spr0pth,$0000,spr0ptl,$0000
 dc.w spr1pth,$0000,spr1ptl,$0000
 dc.w spr2pth,$0000,spr2ptl,$0000
 dc.w spr3pth,$0000,spr3ptl,$0000
 dc.w spr4pth,$0000,spr4ptl,$0000
 dc.w spr5pth
spr5_pth: dc.w 0
 dc.w spr5ptl
spr5_ptl: dc.w 0
 dc.w spr6pth
spr6_pth: dc.w $0
 dc.w spr6ptl
spr6_ptl: dc.w $0
 dc.w spr7pth,$0000,spr7ptl,$0000
 dc.w color00,$0000,color01,$0000
 dc.w color02,$01bb,color03,$0088
 dc.w color04,$00ee,color05,$0066
 dc.w color06,$00aa,color07,$0077
 dc.w color08,$0055,color09,$0044
 dc.w color10,$0033,color11,$0166
 dc.w color12,$0000,color13,$0266
 dc.w color14,$0144,color15,$0255
 dc.w color16,$0133,color17,$0122
 dc.w color18,$0022,color19,$0033
 dc.w color20,$0022,color21,$0011
 dc.w color22,$0011,color23,$0111
 dc.w color24,$0010,color25,$0ccf
 dc.w color26,$099c,color27,$0558
 dc.w color28,$0000,color29,$0ccf
 dc.w color30,$099c,color31,$0558
 dc.w $2207,$fffe,color00,$0001
 dc.w $2a07,$fffe,color00,$0002
 dc.w $3207,$fffe,color00,$0003
 dc.w $3a07,$fffe,color00,$0004
 dc.w $4a07,$fffe,color00,$0003
 dc.w $5607,$fffe,color00,$0002
 dc.w $6207,$fffe,color00,$0001
 dc.w $6407,$fffe
 dc.w bplcon0,%0010000000000000
 dc.w diwstrt,$2c81,diwstop,$2cc1
 dc.w ddfstrt,$0038,ddfstop,$00d0
 dc.w bpl1mod,$0000,bpl2mod,$0000
 dc.w bpl1pth
plane1_h: dc.w 0
 dc.w bpl1ptl
plane1_l: dc.w 0
 dc.w bpl2pth
plane2_h: dc.w 0
 dc.w bpl2ptl
plane2_l: dc.w 0
 dc.w bpl3pth
plane3_h: dc.w 0
 dc.w bpl3ptl
plane3_l: dc.w 0
 dc.w bpl4pth,$0000,bpl4ptl,$0000
 dc.w bpl5pth,$0000,bpl5ptl,$0000
 dc.w spr5pth,$0000,spr5ptl,$0000
 dc.w spr6pth,$0000,spr6ptl,$0000
 dc.w color01,$0ddf,color02,$0888
 dc.w color03,$0ddf
 dc.w $ffdf,$fffe
 dc.w $0007,$fffe,color00,$0001
 dc.w $0807,$fffe,color00,$0002
 dc.w $1007,$fffe,color00,$0003
 dc.w $1807,$fffe,color00,$0004
 dc.w $2807,$fffe,color00,$0003
 dc.w $3407,$fffe,color00,$0002
 dc.w $3607,$fffe,intreq,$8010
 dc.w $ffff,$fffe
 dc.w $ffff,$fffe

Now go easy boys - if you spot any really obvious mistakes then don't ridicule me too badly.

[hitchhikr]

Did you try to use "add.l #logo_bplsz,d0" instead of the add.w ?

[StingRay]

What hitch said

[pmc]

@ hitch and Sting - tried it - no difference.

[pmc]

As I say - I *only* get this corruption when I assemble and run from within Devpac.

If I assemble the exact same source to a file and run outside of Devpac everything looks perfect.

Correction - if I run on a clean booted Amiga I get no corruption otherwise I do.

Perhaps it is my source that's shit! Yeah, yeah, no surprises. :-)

[hitchhikr]

Whatever or wherever it is it's probably because the executable starts at a different address depending on the environment. There's 2 possibilities
1. Something is overwriting part of the logo, check in the memory some graphics rip tool if the logo is really corrupted.
2. Somewhere there's a word range overflow (eg. address going back to $50000 from $5ffff).

[StingRay]

I'd go for 2! Add.w is definitely a bug as long as the code is supposed to be run anywhere in mem.

[pmc]

OK thanks guys - I'll amend the add.w's to add.l's.

[pmc]

@ hitchhikr & StingRay - fixed it! Thanks for your expertise guys!

There were a couple more of those errant add.w's updating pointers elsewhere in my source that have now been changed to add.l's

Now everything looks clean. \o/

Going to prove once more that:

1. I'm generally a muppet and no matter how much I think I've learned there's always more for me to learn...

2. You guys rule.

[Leffmann]

You should still use long operations on data registers for the bitplane pointers, or it will operate on 16 bits only and will eventually result in bad pointers. For data registers you can still do add.w #x, a0 because it will extend to 32 bits. And you should point unused sprites to somewhere other than address 0. I don't know if the exec uses that address after booting but I've seen it fail more than once, and I guess it's better to not set it to 0 yourself as well. Not related but I think the COLOR bit in BPLCON0 should be set as well or you won't get a proper color signal on one of the video connectors?

Any screenshots of what the corruption looks like?