03 April 2011, 13:35 | #1 |
Registered User
Join Date: Nov 2010
Location: .
Posts: 376
|
[REQ:ASM] Assembling and running
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! |
03 April 2011, 13:56 | #2 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
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 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? |
|
04 April 2011, 10:02 | #3 | ||
Registered User
Join Date: Nov 2010
Location: .
Posts: 376
|
Hello Stingray, glad you show up so quickly ;-)
Quote:
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. Quote:
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. Last edited by jman; 05 April 2011 at 07:50. |
||
10 April 2011, 18:19 | #4 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 376
|
Quote:
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: Code:
cmpi.b #$ff,vhposr(a5) ; old Wait Code:
move.l vposr(a5),d0 ; new Wait and.l #$1ff00,d0 cmp.l #303<<8,d0 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. Last edited by jman; 10 April 2011 at 21:26. Reason: Back to back posts merged. Use the edit function. Yes, I'm an idiot I didn't see the 'manage attachments' button :-) |
|
10 April 2011, 19:29 | #5 |
Dazed and Confused
Join Date: Dec 2001
Location: portsmouth/uk
Posts: 242
|
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...
Last edited by Jherek Carnelia; 16 April 2011 at 20:44. |
11 April 2011, 17:24 | #6 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 376
|
Quote:
It is clear, unfortunately, that ASM tutorials sometimes are suboptimal when it comes to learning... |
|
11 April 2011, 20:30 | #7 | |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
Quote:
Regards, Lonewolf10 |
|
11 April 2011, 20:35 | #8 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
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. |
|
11 April 2011, 22:35 | #9 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 376
|
Quote:
Thanks again to Stingray et al. for your contributions. I will carefully check the documentation and samples provided. mucho obligado. |
|
07 May 2011, 18:39 | #10 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 376
|
Quote:
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 |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[REQ:ASM] Reading a keystroke | jman | Coders. Tutorials | 34 | 17 August 2023 12:36 |
Suggestion for ASM Usage running example | TheDarkCoder | Coders. Asm / Hardware | 10 | 15 January 2012 21:57 |
[REQ:ASM] Sprite collisions basics | jman | Coders. Tutorials | 5 | 03 September 2011 00:07 |
REQ:ASM getting elapsed time on A1200 | jman | Coders. Tutorials | 18 | 11 January 2011 22:24 |
REQ:ASM How to use buffers | jman | Coders. Tutorials | 7 | 01 December 2010 01:41 |
|
|