Copper Bars

[pmc]

Fixed it.

@ StingRay - you were right (no surprise!) that the problem came from the blitter clear routine. I did what you did and made a cpu loop to do the clearing and all the bars worked OK. However, the blitter clear routine code was OK too - to make it work with the blitter clear, all I had to do was do another bsr to the wait_blit routine after writing blitsize.

So:

 
 lea bars+6(pc),a0
 move.w #%0000000100000000,bltcon0(a6)
 move.w #%0000000000000000,bltcon1(a6)
 move.l a0,bltdpth(a6)
 move.w #6,bltdmod(a6)
 bsr.s .wait_blit
 move.w #lines<<6+1,bltsize(a6)

became:

 
 lea bars+6(pc),a0
 move.w #%0000000100000000,bltcon0(a6)
 move.w #%0000000000000000,bltcon1(a6)
 move.l a0,bltdpth(a6)
 move.w #6,bltdmod(a6)
 bsr.s .wait_blit
 move.w #lines<<6+1,bltsize(a6)
 bsr.s .wait_blit

and then everything worked OK. My guess would be that perhaps the blitter was still clearing the colours from the copper list while the processor was busy writing colours into the copper list and that waiting for the blitter to finish with the bsr wait_blit stops the two processes overlapping.

Edit: a fixed blitter clear version of the copperwave code is attached to my earlier post in case anyone wants it.

[Vortex]

Unfortunately, doesn't seem to work on my A500.
Assembled it using ASMOne V1.20.
Had to make the following changes before it completely assembled:

- remove Devpac assembler option opt o+
- Change move.l cop_int_address(pc),cop_int_vect.w to move.l cop_int_address(pc),cop_int_vect (ditch the .w) (twice in the code)
- Change bsr.s get_val to bsr.s .get_val

All I get it a big black nudda...

I have a feeling this has to do with data not being in chipmem (spent last night figuring out why I didn't get a picture on screen... Allocating chip mem and copying bitmap data fixed the problem).
Then again I could be totally wrong...

Have to get back to work now (ahem), but if time permits I'll try to copy the data to chip and see if that works...

Lars

Edit: Did add that second BSR.s .wait_blit, made no difference

[StingRay]

Originally Posted by Vortex

- Change move.l cop_int_address(pc),cop_int_vect.w to move.l cop_int_address(pc),cop_int_vect (ditch the .w) (twice in the code)

I changed
move.l cop_int_address(pc),cop_int_vect.w
to
move.l cop_int_address(pc),(cop_int_vect).w

which works fine in ASM-One.

I have a feeling this has to do with data not being in chipmem

That's not the problem, the data is in chipmem ("section copperwave,code_c")

[pmc]

@ Vortex - thanks for trying to run it

Like StingRay says, the code is already being forced into chipram by the section code_c directive. Again, like StingRay says, I think the other stuff you had problems with when assembling under AsmOne are to do with assembler syntax differences from Devpac.

The problems you're getting running on an A500 setup are probably to do with my bad startup code and not doing things in a very system friendly way. Try running it under a UAE emulated A500+ or sit tight and if I get the time over the next few days I'll try to make a version that does the startup stuff in the right way that'll hopefully work for you.

Edit: Did add that second BSR.s .wait_blit, made no difference

That only fixes the disappearing blue bar problem - but of course you'll need to be seeing bars at all to see that!

[Vortex]

@Stingray. Right, totally missed that section code_c bit, and wouldn't have known it's for 'forcing' stuff into chip mem to begin with... Thanks!

What would be the preferred way of doing things? Using section code_c or allocating memory using AllocMem and copy data? Or really doesn't matter?

@pmc. Don't have WIN UAE (don't even have a windows machine... ), so I'll just sit tight for now... .

[pmc]

@ Vortex. No windows machine, no emulators and doing all your coding on the real thing? That, my friend, is truly keeping it retro.

[Leffmann]

Originally Posted by Vortex

What would be the preferred way of doing things? Using section code_c or allocating memory using AllocMem and copy data? Or really doesn't matter?

It does matter because the AmigaOS can do all the work for you if you use the section statement. Otherwise you have to allocate, copy, deallocate, maintain pointer to memory and all references to therein yourself, and you also end up with a higher memory usage.

[StingRay]

I don't see how you end up with higher memory usage if you use AllocMem() instead of using BSS/DATA sections. Anyway, using sections is usually easier but if you want to have relocatable code using AllocMem is much easier. IMHO it doesn't really matter though. Both is fine.

[Leffmann]

In this case and in the case of any data section you would, because you would allocate more memory to hold an additional copy of data that is already in memory.

[StingRay]

In case of data that has to be copied from fast to chip that's of course true. I was more or less thinking of just allocating memory for buffers (as you would do with a BSS section) which is why I wondered.

[Vortex]

Yes, I can see that. Let's say you have some code (1K) and an image (10K) in a single executable file. Load the file, which will ''eat' 11K of mem. The executable will then allocate 10K of chip mem, 'eating' another 10K for a total of 21K.

Using section code_c the whole file is always loaded into chip mem, so no need to copy any data, saving you 10K in the example above.

I assume you can 'force' parts of of your code and data into chip or fast?
If this is true, how does the OS know where to load the different parts? Is this done with these file hunks I've read about, or am I just making wild guesses here and should I shut up and get back to messing with copper bars...

[StingRay]

Originally Posted by Vortex

I assume you can 'force' parts of of your code and data into chip or fast?

Yes you can, that's what the "SECTION xx,CODE/BSS/DATA(_c)" statements are for. If you add "_C" this part of your program is loaded to chipram, otherwise it's loaded into any available memory (fast ram has higher prio than chip thus if there's free fast ram AmigaDOS will load it into free fast). If you definitely want to have your code/data in fast mem you can add _F.

Originally Posted by Vortex

If this is true, how does the OS know where to load the different parts? Is this done with these file hunks I've read about

Yes, there are different types of hunks (bit 30=1 -> load to chipram) so AmigaDOS "knows" what to do. You don't really have to care about this though.

[Vortex]

Gentlemen, thanks for all the info! Really appreciate it.
So far rediscovering the Amiga has been great fun.

[pmc]

@ Vortex - Attached for you is an A500 friendly version of my copperwave routine.

Using StingRay's mini startup code as a guide I've redone my own startup routine into what I hope is a bit closer to the way it should be done.

When I tested the new routine on an emulated A500 it worked fine - instead of a blank screen like I was getting before, I saw the bars waving away like they should.

Let me know if it works on the real thing and I hope you like it.

[Vortex]

Hi pmc, it works like a charm!
Thanks for the fix. Looking forward to your next piece.
Already working on mine..

Cheers,

Lars

[pmc]

No worries man, glad it's working for you.

Hopefully now that my startup is a bit better you shouldn't get anymore blank screens when I post more routines.

Already working on mine..

Nice one.

[StingRay]

Originally Posted by pmc

Hopefully now that my startup is a bit better you shouldn't get anymore blank screens when I post more routines.

One thing now that you have updated your startup code ;D You shouldn't bang the interrupt vectors directly as that won't work on any machine that has relocated VBR (e.g. all of mine ;D). Get the VBR (check my startup) and use that address to set your interrupts.

[pmc]

Thanks for letting me know StingRay.

To be honest, I noticed that you were doing some trickery there with the VBR in your startup code but I didn't really understand what the VBR was / is and what your code was doing so I stayed on the cautious side and didn't replicate that across.

I don't really like putting things in my own code unless I understand what they're doing in case I do something later that might conflict and end up with no clue why my code isn't working!

Edit: Sorry to be a pain but one other quick thing - I noticed in your and other peoples startup code that you move #%01111111111111111 (#$7fff) to dmacon to shut off dma before you turn it back on again later. Whenever I move that value to dmacon in any of my startups things don't work properly. I always end up having to move #%0000010111111111 instead to turn off dma and get things working. Is it just that my (emulated) Amiga doesn't like me...?

[Leffmann]

It's because you don't set bit 9 afterwards, the DMA master enable. The description in the hardware manual is a bit ambiguous and most people interpret it as a convenient bit that turns on all DMA at once, but the actual purpose is to permit all DMA.

[pmc]

Ah, OK. I'd read the HRM in the way you'd described too - I thought that bit 9 was just an all on / all off option. Now you've explained it that makes more sense. Thanks Leffman.