[REQ:ASM] Assembling and running

[jman]

Hello,

there's a couple of things I don't quite understand about assembling and running Amiga executables.

1) Everytime I run the attached src code (notice: contains DevPac macro) I experience a different speed of the scroll on the emulated 1200 I'm using: first run looks balanced, second run slow, third run very slow, then incredibly fast, ... and so on in a (apparently) random fashion.
Is this because I'm running inside a debugger (additional overhead of DevPac)?

2) This small piece of code does not run outside DevPac on the emulated A1200. On an emulated A500 it only runs once or twice in a row. Why this?
Am I leaving leftovers behind when I exit the application?

Can anyone point my nose into the right direction? I'd like consistent performances from something I'm assembling.

Thanks!

[StingRay]

Originally Posted by jman

1) Everytime I run the attached src code (notice: contains DevPac macro) I experience a different speed of the scroll on the emulated 1200 I'm using: first run looks balanced, second run slow, third run very slow, then incredibly fast, ... and so on in a (apparently) random fashion.
Is this because I'm running inside a debugger (additional overhead of DevPac)?

There are several problems, you don't disable the system so the OS is fully intact when your code runs and thus it'll slow it down. Also, your routine to wait for the vertical blank will cause problems since most probably your code doesn't need more than 1 rasterline so your routine to check for the vertical blank won't do what you expect. To fix that, you should wait for the desired rasterline first and in a second loop check if the rasterbeam is still in the same raster line and if so, wait until the raster line changed.

Code could look like this:

.loop
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #303<<8,d0 ; line to wait for
bne.b .loop

.loop2
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #303<<8,d0 ; line to wait for
beq.b .loop2

Originally Posted by jman

2) This small piece of code does not run outside DevPac on the emulated A1200. On an emulated A500 it only runs once or twice in a row. Why this?
Am I leaving leftovers behind when I exit the application?

That's most probably because you don't have a proper system kill/restore code which is never a good idea if you want to bang the hardware. What exactly happens?

[jman]

Hello Stingray, glad you show up so quickly ;-)

Originally Posted by StingRay

you don't disable the system so the OS is fully intact when your code runs and thus it'll slow it down.
Also, your routine to wait for the vertical blank will cause problems since most probably your code doesn't need more than 1 rasterline so your routine to check for the vertical blank won't do what you expect.

I've enabled back the _LVODisable. I also have commented out my check on VHPOSR before performing the paint routine, replacing with your first check on VPOSR, the general behaviour seems to have improved.

However I didn't include the second check (i.e. is the rasterbeam still in the correct line?) because I don't have clear how this is working, yet. What I knew is that in order to sync the application speed with every Amiga hardware I had to wait for the beam to start painting a new screen (thus check VHPOSR line position). Now, I don't want to make wrong guesses before having checked the ROM Kernal Manual for further details.

Originally Posted by StingRay

That's most probably because you don't have a proper system kill/restore code which is never a good idea if you want to bang the hardware. What exactly happens?

On the A500 I briefly see the screen flickering and then I'm back to Workbench while on the A1200 the application is running (the OS disabling works until I trigger the exit event) but my copperlist is not applied.
I've added a movem of all data and address registers right after the init label and another one before exiting, to no avail.
On a second thought that may be not what you meant, I'll check some examples around...

Thanks for now.

[jman]

Originally Posted by StingRay

That's most probably because you don't have a proper system kill/restore code which is never a good idea if you want to bang the hardware. What exactly happens?

Ok, I think I've finally understood why this small piece of code do not run on my virtual Amigas:

1) did not run on WinUAE/68000/OCS: most likely the issue was solved replacing the Wait routine (see my previous post) as per your suggestion.

2) did not run on the WinUAE/68020/ECS/RTG: the issue is caused by the RTG setting turned on. Running on a plain OCS/ECS Amiga works fine.
I should read some fine material concerning the RTG mode and why this is happening. If only Toni would step by this thread ... ;-)

On the other hand, I still didn't manage to understand the reason why you suggested a double VPOSR check for the vertical blank; I've looked up on EAB, you suggested that check many times.
I'll try to elaborate on that:

cmpi.b        #$ff,vhposr(a5)    ; old Wait

Possibly the error lies in that I'm checking the lower byte of that register (turns out to be the horizontal position?).

move.l       vposr(a5),d0    ; new Wait
and.l        #$1ff00,d0
cmp.l        #303<<8,d0

This code checks (if I'm not mistaken) bit 15, vertical position of the beam.

If you could spare 1 minute for an explaination to this thick mind, I'd be grateful (yes I did check the copper reference, yes I did check these links).

Thank you again for your patience.

attached proof source and binary.

[Jherek Carnelia]

jman, here is an explanation of the wait loop I wrote out for myself the other day. Hopefully it will explain what's going on for you...

[jman]

Originally Posted by Jherek Carnelia

jman, here is an explanation of the wait loop I wrote out for myself the other day. Hopefully it will explain what's going on for you...

This document is well above what I could have expected. It is detailed and very clear. Thank you so much for sharing this with me.
It is clear, unfortunately, that ASM tutorials sometimes are suboptimal when it comes to learning...

[Lonewolf10]

Originally Posted by jman

It is clear, unfortunately, that ASM tutorials sometimes are suboptimal when it comes to learning...

It's probably good to learn from multiple sources and listen (read) very carefully to what people like Leffmann, StingRay and others say in these threads.


Regards,
Lonewolf10

[StingRay]

Originally Posted by jman

2) did not run on the WinUAE/68020/ECS/RTG: the issue is caused by the RTG setting turned on. Running on a plain OCS/ECS Amiga works fine.
I should read some fine material concerning the RTG mode and why this is happening.

This is still related to the fact that you don't use a proper system kill/restore code. To make your code run from non-native screen modes, you need to reset the view properly (LoadView/WaitTOF). Check my attached mini-startup code which does all that for you.

Originally Posted by jman

On the other hand, I still didn't manage to understand the reason why you suggested a double VPOSR check for the vertical blank;

Reason is simple, if your routine is so fast that it will need less than 1 raster line, the raster beam is still in the same line when it reaches the "wait for line xxx" code and thus it won't wait (try to figure out what happens!), thus the 2nd wait which will fix that problem.

[jman]

Originally Posted by Lonewolf10

It's probably good to learn from multiple sources and listen (read) very carefully to what people like Leffmann, StingRay and others say in these threads.

I agree. Allow me to say that much documentation I find around is written by "oldskoolers" explaining things in a it_works_like_this fashion, orally passing on this crippled knowledge. But this is offtopic, so I'll cut it short, but you know what I'm talking about.

Thanks again to Stingray et al. for your contributions. I will carefully check the documentation and samples provided. mucho obligado.

[jman]

Originally Posted by StingRay

This is still related to the fact that you don't use a proper system kill/restore code. To make your code run from non-native screen modes, you need to reset the view properly (LoadView/WaitTOF). Check my attached mini-startup code which does all that for you.

Hello Stingray,

just a quick follow-up.
I spend some time studying the startup code you provided, otherwise it was useless to me.

Well, now that small piece of code is always working: inside DevPac, outside DevPac and on different emulated Amigas. It also shows exactly the same speed on different hardware (attached proof in case other newbies may find it useful).

Now, as a side thought, I noticed that I'm just the latest of a long list of people you and others have being answering over and over again to the same questions. Wouldn't be more useful to add all these suggestions to a wiki?

Thank you