For my First ASM Prog - Page 2

Alter · 09 February 2006, 17:38

Thanx alot Ray, I will download it right away :-)

NOB · 09 February 2006, 19:07

Thanks Ray, checked it out on an original AMIGA.

thor · 20 May 2006, 22:39

Quote:

Originally Posted by Ray Norrish

I`ve uploaded the System close / restore code into the zone. This works for all processors.

Can you upload it again? I missed it. Thanks in advance

AGN · 21 May 2006, 14:42

Quote:

Originally Posted by thor

Can you upload it again? I missed it. Thanks in advance

http://www.aminet.net/search.php?query=phxass439.lha
/PhxAss/Examples/DemoSupp.asm

Very good example.

AGN · 21 May 2006, 16:05

Here is altered example to one posted by x_to.
Now it compiles fine under vasm.

Code:

;
; Copper-Demo
;

CUSTOM		=	$dff000
CIAA		=	$bfe001
COP2LC		=	$084
DMACON		=	$096
INTENA		=	$09a

	section	"code123",code

	lea	CUSTOM,a6
	move.w	#$4000,INTENA(a6)	;disable Interrupts
	move.w	#$0020,DMACON(a6)	;disable Sprites
	move.l	#copperl,COP2LC(a6)	;activate Copperlist
loop:
	btst	#6,CIAA			;loop unil mousebutton
	bne.s 	loop 			;is pressed

	move.w	#$8220,DMACON(a6)	;enable Sprites
	move.w	#$c000,INTENA(a6)	;enable Interrupts
	rts
	nop				;ignore me

	section	"data123",data,chip

copperl:
	dc.w	$008e,$3081		;DIWSTRT
	dc.w	$0090,$35c1		;DIWSTOP
	dc.w	$0104,$0064		;BPLCON2
	dc.w	$0092,$0038		;DDFSTRT
	dc.w	$0094,$00d0		;DDFSTOP
	dc.w	$0102,$0000		;BPLCON1
	dc.w	$0108,$0000		;BPL1MOD
	dc.w	$010a,$0000		;BPL2MOD
	dc.w	$0100,$1200		;BPLCON0
	dc.w	$00e0,$0005		;BPL1PTH
	dc.w	$00e2,$0000		;BPL1PTL
	dc.w	$0180,$0000		;COLOR00
	;	read this	http://eab.abime.net/showthread.php?t=21866
	; 	and have fun
	dc.w    $a051,$fff0
        dc.w    $0180,$0090
	dc.w    $a0b1,$fff0
        dc.w    $0180,$0000

	dc.w	$ffff,$fffe		;Copperlist end

jaycee · 28 September 2006, 18:10

just to jump in.. i used to HATE reading code where the author had written all the hardware addresses and bitflags by hand! There's just no need for it... it's easy to get the include files and do .include "hardware.i" at the top of your source. Especially if its example code for someone to read.

I never liked not using the relative address mode for writing to hardware regs either, especially the $DFF000 range.

jrom · 29 September 2006, 15:01

how right you are... for once i'd like to see some code that actually uses the NDK... they didn't release those for nothing!

cdoty · 06 October 2006, 17:17

Quote:

Originally Posted by polish

Is ASM really hard to learn, i was thinking of trying it myself? I mean all the offsets and stuff look hard to understand but i think ill work it out

ASM isn't hard to learn. It just requires a lot of attention to detail and getting used to doing things in small steps.

In C/C++ you can do ptr++, and it will increment depending on the size of the pointer (ie an 'long *' will increment 4 bytes on a 32 bit system). In ASM, you have to increment the pointer by the size of the data, unless you use move.l (a0)+, (a1)+

Also, I wouldn't necessary worry about learning the entire instruction set, learn the load/store (move), branching (bne, jsr, etc) and compare (cmp) instructions (inc/dec are important on other chips). Then, keep an instruction set sheet handy for the test, asl, shr, etc type instructions. After using ASM for awhile, you will get used to these instructions.

Learn to use a debugger. Running code through a debugger can teach you more than reading tutorials or instruction sets. MESS is a nice debugger, but is a pain to use with amiga executables. It's hard to find the address where the executable loaded. But, once found, it usually remains the same (assuming you're loading the executable before workbench starts or automatically on boot).

Is there an easy way to determine where an executable will load to?

jaycee · 06 October 2006, 17:34

I had 2 sheets of A4 paper with the 68000 instruction set, condition codes and such on it which I kept to hand. I think I got it from Aminet. Later on I downloaded an AmigaGuide file which had a full run-down of 68000 and some 020 instructions to refer to. I formatted and printed it out into an A4 binder file

Debuggers - can't really recommend anything here as I was used to RossiMon, and then MonAm3. Both are rather unfriendly, especially MonAm3 which is totally keyboard shortcut driven. I don't know if it's still maintained but PowerVisor looked good too.

You can't really determine where your executable will be loaded... this is entirely up to AmigaDOS' LoadSeg() function which loads your executable. You can use the SECTION directive of the assembler to guarantee your code/data/whatever will load into a particular type of ram, though.

(wow... I pulled out some memories there.. I haven't written any asm on the amiga in at least 8 years!)

23 February 2007, 19:13

Quote:

Originally Posted by jaycee

... it's easy to get the include files and do .include "hardware.i" at the top of your source. Especially if its example code for someone to read.

Any idea where to get "hardware.i" - I need it for another program. I have NDK's 1.2 and 2.1 and have Googled without joy. It will save me changing a lot of code e.g. Bltapth to bltapt etc.

Jim

BippyM · 23 February 2007, 20:46

it'll be on the ndk

Joe Maroni · 23 February 2007, 21:34

otherwise buy one of the Amiga Developer CDs...

still available at http://www.vesalia.de

25 February 2007, 20:38

Quote "I have NDK's 1.2 and 2.1.."

Sorry, of course I meant the Developer CD's (I thought you 'experts' would have known that

) which I just bought from Vesalia and 'hardware.i' is NOT on either of them. I'm not out to l33ch copyright stuff, I just want the file! Are you SURE it's on the NDK, bippym, x_to was SURE it was on the Developer CD?

Jim

StingRay · 26 February 2007, 01:10

Hey Jim, I guess you needed hardware.i for sp's c2p.

That problem should now be solved I suppose.

Check the pouet thread, I answered you there.

26 February 2007, 02:58

stingray: Yep, that's what kicked it off. I was using hardware/custom.i but was having to change all the blitter equates so rather than hard code a load of equates or build a custom include file it seemed easier to get hardware.i (and I wanted to check for any 'variations' from the standard as sometimes creep in). It's sorted now thanks to your revised source but I'm still curious about hardware.i - why is it even necessary if all the equates are in the standard hardware/custom.i etc? Is it an assembler-specific issue?

StingRay · 26 February 2007, 10:03

Well, to be honest, I never used includes when I needed to access hardware regs, for me it's just way more comfortable to write move.w #(256<<6)|20,$58(a6) if I want to start a blit f.e.

Bad style? Maybe, but I'm doing it like this since 1990/91 so it won't change anymore.

Why there is a hardware.i include now I don't know either, custom.i should have been enough I think. I don't have hardware.i so I don't know how it differs to custom.i, would be interesting to know though. The only differences I could spot so far are the Bltxpth constants which are lowercase in custom.i and don't have the h, e.g. Bltapth is called bltapt in custom.i. I guess all custom offsets start with an uppercase letter in hardware.i but I am not sure. I find it pretty stupid anyway to have 2 different include files for the same thing.

Another reason why using good old "bad" style has advantages.

26 February 2007, 15:37

Yeah, I guess, I was just looking to save some time (and perhaps trouble) in order to focus on getting a clean compile and thought there might have been some tricks and/or traps in there e.g. Devpac throws a wobbly when you try to 16-bits test an 8-bit location in the WAITBLITTER routine (btst #14, $dff002) but ASM-Pro and ASM-One don't even bat an eyelid - heh - just thought, for all that hardware.i stuff and he doesn't even use 'dmaconr' anyway

27 February 2007, 23:45

Quote:

Originally Posted by bippym

it'll be on the ndk

Erm, apparently I do have all the NDK's - I just checked my (legal version) Developer CD 2.1 and all the NDK's are there (apparently for historical purposes) BUT no "hardware.i" so I must assume this is either a version specific to a particular assembler or a home grown include file. Thanks to StingRay I'm past it but just to close off this part of the thread (BTW I ought to say sorry for hijacking it

).

28 February 2007, 11:54

Only place i got Hardware.i was from "The hardware reference manual" that i had to type out myself...

That was 10+ years ago thou so i may be wrong lol

IFW · 28 February 2007, 23:44

OS/hw header files all came from C= bundled with development software and hardware.
You could also get them from CATS.
SAS/C and Devpac are just two examples where the original package contains all the necessary header files.
These header files were also available with some book (don't remember which one, probably RKM or HRF) and were part of some PD discs too.
C= was quite happy to distribute them in any way that was possible at the time, so feel free to get them.

26 February 2007, 15:37	#37
jima Posts: n/a	Yeah, I guess, I was just looking to save some time (and perhaps trouble) in order to focus on getting a clean compile and thought there might have been some tricks and/or traps in there e.g. Devpac throws a wobbly when you try to 16-bits test an 8-bit location in the WAITBLITTER routine (btst #14, $dff002) but ASM-Pro and ASM-One don't even bat an eyelid - heh - just thought, for all that hardware.i stuff and he doesn't even use 'dmaconr' anyway Last edited by jima; 27 February 2007 at 18:25.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Rainboot 2.9 prog	Rod_cl	request.Apps	4	26 February 2019 17:02
Viewer Prog	AlfaRomeo	request.Apps	4	24 August 2008 02:38
Best prog to scan floppys?	Eny-	support.Apps	10	04 August 2004 21:42
Snoopdos prog	stainy	request.Apps	3	04 April 2004 00:09
Need prog!	Time Bandit	Retrogaming General Discussion	6	20 November 2002 22:28

09 February 2006, 17:38	#21
Alter Oldskool Join Date: Dec 2005 Location: Norway Age: 52 Posts: 28	Thanx alot Ray, I will download it right away :-)

09 February 2006, 19:07	#22
NOB Zone Friend Join Date: Aug 2005 Location: Germany Age: 52 Posts: 424	Thanks Ray, checked it out on an original AMIGA.

28 September 2006, 18:10	#26
jaycee Registered User Join Date: Sep 2006 Location: Norwich, UK Posts: 57	just to jump in.. i used to HATE reading code where the author had written all the hardware addresses and bitflags by hand! There's just no need for it... it's easy to get the include files and do .include "hardware.i" at the top of your source. Especially if its example code for someone to read. I never liked not using the relative address mode for writing to hardware regs either, especially the $DFF000 range.

29 September 2006, 15:01	#27
jrom Wannabe asm coder ;) Join Date: May 2002 Location: The Netherlands Age: 47 Posts: 459	how right you are... for once i'd like to see some code that actually uses the NDK... they didn't release those for nothing!

06 October 2006, 17:34	#29
jaycee Registered User Join Date: Sep 2006 Location: Norwich, UK Posts: 57	I had 2 sheets of A4 paper with the 68000 instruction set, condition codes and such on it which I kept to hand. I think I got it from Aminet. Later on I downloaded an AmigaGuide file which had a full run-down of 68000 and some 020 instructions to refer to. I formatted and printed it out into an A4 binder file Debuggers - can't really recommend anything here as I was used to RossiMon, and then MonAm3. Both are rather unfriendly, especially MonAm3 which is totally keyboard shortcut driven. I don't know if it's still maintained but PowerVisor looked good too. You can't really determine where your executable will be loaded... this is entirely up to AmigaDOS' LoadSeg() function which loads your executable. You can use the SECTION directive of the assembler to guarantee your code/data/whatever will load into a particular type of ram, though. (wow... I pulled out some memories there.. I haven't written any asm on the amiga in at least 8 years!)

23 February 2007, 20:46	#31
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	it'll be on the ndk

23 February 2007, 21:34	#32
Joe Maroni Moderator Join Date: Feb 2003 Location: Germany Age: 44 Posts: 1,303	otherwise buy one of the Amiga Developer CDs... still available at http://www.vesalia.de

25 February 2007, 20:38	#33
jima Posts: n/a	Quote "I have NDK's 1.2 and 2.1.." Sorry, of course I meant the Developer CD's (I thought you 'experts' would have known that ) which I just bought from Vesalia and 'hardware.i' is NOT on either of them. I'm not out to l33ch copyright stuff, I just want the file! Are you SURE it's on the NDK, bippym, x_to was SURE it was on the Developer CD? Jim

26 February 2007, 01:10	#34
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,865	Hey Jim, I guess you needed hardware.i for sp's c2p. That problem should now be solved I suppose. Check the pouet thread, I answered you there.

26 February 2007, 02:58	#35
jima Posts: n/a	stingray: Yep, that's what kicked it off. I was using hardware/custom.i but was having to change all the blitter equates so rather than hard code a load of equates or build a custom include file it seemed easier to get hardware.i (and I wanted to check for any 'variations' from the standard as sometimes creep in). It's sorted now thanks to your revised source but I'm still curious about hardware.i - why is it even necessary if all the equates are in the standard hardware/custom.i etc? Is it an assembler-specific issue?

26 February 2007, 10:03	#36
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,865	Well, to be honest, I never used includes when I needed to access hardware regs, for me it's just way more comfortable to write move.w #(256<<6)\|20,$58(a6) if I want to start a blit f.e. Bad style? Maybe, but I'm doing it like this since 1990/91 so it won't change anymore. Why there is a hardware.i include now I don't know either, custom.i should have been enough I think. I don't have hardware.i so I don't know how it differs to custom.i, would be interesting to know though. The only differences I could spot so far are the Bltxpth constants which are lowercase in custom.i and don't have the h, e.g. Bltapth is called bltapt in custom.i. I guess all custom offsets start with an uppercase letter in hardware.i but I am not sure. I find it pretty stupid anyway to have 2 different include files for the same thing. Another reason why using good old "bad" style has advantages.

28 February 2007, 11:54	#39
CoDeMaN Posts: n/a	Only place i got Hardware.i was from "The hardware reference manual" that i had to type out myself... That was 10+ years ago thou so i may be wrong lol

28 February 2007, 23:44	#40
IFW Moderator Join Date: Jan 2003 Location: ... Age: 52 Posts: 1,838	OS/hw header files all came from C= bundled with development software and hardware. You could also get them from CATS. SAS/C and Devpac are just two examples where the original package contains all the necessary header files. These header files were also available with some book (don't remember which one, probably RKM or HRF) and were part of some PD discs too. C= was quite happy to distribute them in any way that was possible at the time, so feel free to get them.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)