Why the screen does not open?
 

I have this code:When i run it, the screen freezes/mouse freezes, but when i click, it properly exits and comes back to the shell. Why the screen does not open?

move.l #copperlist,COP1LCH(a2)

And also, as well as what Ross said, is your copper list in chipmem?

Also at start of code it should be move.l #custom, a2

Also your copper list sets bitplane 1 as $7c080 and bitplane 2 as $7dfc0, yet there is nothing in your code to suggest you are clearing or setting any data at those addresses.

Originally it was that, with the hashmark, but if i do it that way, then the executable becomes corrupted and the Amiga refuses to run it with error 121...Must be, as there is no FastRAM in the machine...but point taken, you're right, if someone runs the program with a machine with FastRAM, then the Amiga will most likely load it into the FastRAM, thanks for pointing out.If i do that, the entire machine crashes when i run the program. This way it works, just the screen does not open. The disassembly also shows correct values for

CUSTOM

.True, but this code is not needed to be system friendly; right after it finishes, a single-task game will take over.

Well, there are quite a few mistakes in fact...

move.w DMACONR(a2),d1
....
or.w #SETCLR,d1
move.w d1,DMACON(a2)

and there are system calls in between that don't preserve the value of D1

I just looked quickly, probably there is more :)

Okay, maybe, but that code is at the exit, when the program closes the graphics library. It does not explain why the screen is not opening, as d1 is not used anywhere else. But thanks for pointing out, d1 and d2 should be stored in a variable.

Edit: Aaaaand if i try to store them in a variable, then the exe is corrupted again and refuses to run with error 121. What is this?

One possibility is the DMACON value.
You set it to
But this is not correct, you need to set the DMAEN bit (bit 9) as well.
Edit: I know this sounds like an odd thing, but DMAEN does not do what you might think if you read the HRM description. The HRM description suggests it activates all the DMA channels in bits 0-8. Instead, it merely makes it so that you can enable the DMA in those bits.

jsr OldOpenLibrary(a6)
move.l d0,a3 ; graphics.library handle stored in a3.
move.l 38(a6),d2 ; Old Copper settings in d2.

38(a6) read from execbase...

Rewrite it from scratch with more attention.
In assembler you cannot afford errors of any kind ;)

But it's not working ;)

Its "working" completely by accident, not by design.

Your first line is moving the contents of $dff000 into a2, when the value $dff000 should be in a2.

If that line is incorrect, the next line is also wrong as it's not going to be pulling from the correct register.

So here is my advice.

Cut first two lines.

Where you move #$7fff,dmacon(a2), put that before your move of the copper list, dont forget # Ross told you.

The two top lines you cut from the top, put them both before the #$7fff,dmacon(a2), not forgetting the # in front of custom.

Make sure custom = $dff000
Make sure setclr= $8000

That big setup for DMA before you wait for left mouse button, trim all that out and put in the value $87d0
See how you get on

I was about to post that one..
TCH: What assembler are you using? I got used to seeing that blinking red box (GURU) quite quickly.

I completely missed that. Yeah 100%. It should either be lea CUSTOM,a2 or move.l #CUSTOM,a2.

Thanks, but nothing changed.

Also, this line:

move.w		DMACONR(a5),DMABackup

causes the program to refuse to run with error 121. Why? It does not help, if i put the value into

d1

first.Thanks. It's late. :PI did. New code snippet:Result: error 121, does not run.It's vasm.Thanks, that was it!

lea

was the correct solution, if i used the hashmark, then error 121 was all i got. Finally, a black screen. I now will test, if the bitplanes are in the right place.

Edit: If i try to save the original copper and DMA into variables instead of d1 and d2, then the program crashes...

Edit: Galahad, you were right about the

$87d0

, thanks.

The following code is the 'correct' version of what you tried to do.
I would never write it like this, too many important parts are missing

For the old farts, don't look at me badly, I just got the code and "fixed" it :p

Regardless, it is needed for it to work - I made that mistake so many times :)
If you're aiming this at a standard A500 with a 68000, your variables need to be aligned to an address which is a multiple of two. If they aren't, you can get a crash. However, I can't be certain this is the case here because you didn't show the part of the code where you declare the variables. Something worth checking for sure.

About error 121: this means your assembled program is not a proper executable. What VASM/VLINK flags are you using and what version of Kickstart/Workbench are you running your code on?

This is a good point.
vasm require

-kick1hunks

to be KS1.x compatible, probably by default it generates reloc tables for KS2.0+ only.

I edited the code to be fully pc relative, so problem solved at the root.

Thanks, it is much more clearer. (Although i canot store the DMA value in d0, i need that register, so that will be changed.) What is this

LVO

prefix?I see, thanks.You must be right, i am an idiot.

-Fhunkexe -nosym

KickStart 1.3, there is no WorkBench.Well, it only happened when i tried to access some variables, it worked without

-kick1hunks

, so roondar must be right about the alignment. If i use

-kick1hunks

, then it will not be usable under KS 2.0? (Although the targetted game itself has glitches over 1.3, so it is not recommended to run it on KS 2.0+ anyway.)

Edit: @ross: You open

graphics.library

, but do not call anything from it, you've removed the

WaitTOF

calls; if it is not needed, why open it?

Sure, you can use what is useful to you in the code.
But as I told you in a previous message, and it seems to me that you did not get the point from your reply, it is that when you call the system functions you cannot save variables into d0/d1/a0/a1 because they are scratch registers.
Unlike you, I don't have any calls in this piece of code so I took the first free register available :)

Library Vector Offsets

Absolutely use it if you want your exe to work on old KS!
KS2.0 are fully compatiple with old generated hunk.

To grab system copper list..
About WaitTOF: not the right way to use it, so useless in your case.

L.ibrary V.ector O.ffset

It is used to restore the system copperlists.

Sorry, in the meantime, i've noticed the

move.l      38(a5),$80(a2)

No-no, point taken, i will place them in variables. Aligned ones. :P

The point is only regs d0/d1/a0/a1 are scratch registers for system calls (there are very few excetions, well documented in Autodocs).
So you have plenty of registers (or stack) to save (temp)variables.