Displaying images
 

I have been messing around with 68k assembly for a few weeks, the next step I want to make is to display an image on the screen.
I am using workbench 3.1 and I am using os includes to do everything at the moment, and am not confindent enough in my asm skills to do otherwise just yet.

Can anyone point me to any tutorials or post up some sample code that does this?

Cheers :)

Hello Tiddlypeeps :)

What does your code do so far...?

Displaying a pic is nice and easy but I'm not personally sure how to go about showing the pic in an OS friendly way - is that what you're after?

Here's an example which displays a 32 color picture. It's OS friendly, but it will pause the OS to poke the hardware directly.

Don't be alarmed by the amount of files and code, most of it is just library code for support, the actual picture showing part is in the showpic.s file.

Out of curiosity I had a look at the source and just wanted to tell you that the option -opt-allbra (or any other optimization) is useless when you specify -no-opt on the same line. The -no-opt option can be seen as a main-switch for all optimizations.

You can get more control over individual optimization options with the Devpac-compatible OPT directive.

I changed the doc to make that clearer in the next relase. ;)

Hi Frank

Glad you told me. The behavior I wanted was to optimize .s and unspecified to the shortest, while leaving .b .w .l as they are since I explicitly say what size they are. I'll look into the OPT directive.

That's not possible, as vasm makes no difference between .s and .b for branches. I would suggest to do a search-replace in your editor to replace all ".s" by "" and then assemble with default settings.

First sorry for hijack this thread ;)
I´m trying to display a pattern in a 1 bitplane screen with the following code found in Amiga Computing magazine but it results in screen garbage and not in a regular pattern as it should be.
I already tried to find the bug but with no luck.
Can someone point what´s wrong in the code that results in the garbage displayed on the screen, please?

You're specifying a 256 lines tall display window, but only have 200 lines in your screen buffer. Write $F4C1 to DIWSTOP to shorten the window to 200 lines ($2C + 200 = $F4).

Also if you're on AGA then 32 or 64 bit bitplane fetch mode might be enabled and you need to adjust DDFSTRT and DDFSTOP accordingly, or you can write 0 to FMODE $DFF1FC to set it to 16 bit fetch mode.

As Leffmann says, or you could change the line
scr dcb.b 8000,$55

to

scr dcb.b 10240,$55

and get the attached when you run it (I still got some intermittent (sprite?) garbage though).

Thanks for the help. Already understood the problem and fixed the code

Yes, he has to zero all sprite registers ($120 to $13e).
I usually start my copperlists with the following code:

And only after I fiddle with the sprites.

jman: doing this:

for each sprite will most likely work OK to stop you seeing random sprite garbage but isn't strictly correct. Those sprite registers are address pointers so you're not zero-ing them by doing that - you're pointing the sprites at address zero!

When you have sprite DMA enabled, what you should really do instead for any sprites you're not using, is set their address pointers to point at a dummy null sprite:

Since he's not using any sprites it would be enough to disable sprite DMA in this case. He should disable the system anyway as otherwise all kind of random bugs can appear since the OS is running while he's banging the hardware registers. Plus, what PMC (hi o/ :D) said regarding sprite pointer initialisation.

Didn't that cause a sprite row to be drawn over the whole screen height, when disabling DMA in a bad moment, while reading sprite data?
Then you would also have to zero the SPRxDAT registers, IIRC.

Or, you have to turn off sprite DMA during the VBLANK

See TDC's answer. :) Sprite DMA needs to be disabled in the vertical blanking period, otherwise you'll see the mentioned bug (mouse pointer from the OS is a sprite and thus can cause this "nice" bug you mentioned).

*slaps forehead*

I wasn't switching my sprites off at the right time. Had that random garbage thing coming up periodically for ages :D

Hey, thanks, I didn't really notice that until you pointed me the obvious.
And this casts a dark shadow over all I'm doing to prepare registers before triggering a copperlist.
Using DC.W to set registers is not the same as using move.w in the main code body, I suppose now. Example:

wrong: right: Am i correct? After the copperlist LABEL there should really be place only for the copper chip instructions. All the register setup should be done in the code section, correct?

Hey thanks again, It's great to be on EAB!

In a copperlist you set registers with dc.w register,value, it's the same as writing to these registers in your "normal" code.


These instructions are not the same.
dc.w bplcon1,0 is not the same as move.w $0,bplcon1.
Correct would be move.w #$0,bplcon1. :)

It's good style to do it that way but you can actually do it in whichever section of your code (that allows code) you want.

But then how is that different doing
rathen than
PMC made a clear point stating that in the first case I'm pointing the register to $0 memory location (wrong), while what I want is to zero all bits in the register (latter example). Sorry if I'm missing the obvious, I'm here to learn ;-)

I'm sorry, of course I meant to write zero (#$0) in that address, not copy a memory location, I have to amend my post.

Thanks!