Absolute addressing

Old_Bob · 18 September 2018, 11:41

Hey, dudes.

I've been revisiting my Bombjack game in the last few days, after a little break, and have run in to a bit of an obstacle.

I'd like to use absolute addressing, but it's proving to be a real pain in the arse. If I try to assemble the source using Asm-Pro with an ORG directive it spits out a "relative mode error". Devpac assembles it fine, but has no option to output the binary directly. Vasm *did* correctly assemble and output some small test programs I tried using the -Fbin option but when I try to build the whole game, it churns out unusable nonsense.

Can anybody give me some pointers here?

B

Leffmann · 18 September 2018, 15:21

Are you mixing section and org statements, or use PC-relative addressing across sections? That would give you relative mode errors.

What does the nonsense code look like? If you use vasm's binary output, it may pad the space between consecutive org statements, which might look like nonsense code.

Old_Bob · 18 September 2018, 20:16

Thanks, dude.

I'm using only the ORG statement, with no code sections of any kind in the source. The binary vasm outputs looks like part of the graphics/bob data. There's no actual code as such, that makes sense at least. And, even that's incomplete as I can't see my "end of program" ASCII marker at the end of the file.

Using Devpac at least assembles correctly, so I guess I possibly could strip the extra chunk of stuff it sticks in at the start and maybe use it that way?

B

Leffmann · 18 September 2018, 23:04

Quote:

Originally Posted by Old_Bob

Using Devpac at least assembles correctly, so I guess I possibly could strip the extra chunk of stuff it sticks in at the start and maybe use it that way?

Yeah I guess, if Devpac outputs a regular AmigaDOS object file, but I don't see why vasm wouldn't work. The -Fbin switch does exactly what it's supposed to when I test on my machines. Everything comes out as a single binary blob relocated to where I org'ed it, and it does a much better job than Devpac at optimizing.

Do you have any example source file that comes out wrong?

phx · 18 September 2018, 23:45

Quote:

Originally Posted by Old_Bob

I'm using only the ORG statement, with no code sections of any kind in the source. The binary vasm outputs looks like part of the graphics/bob data.

Do you have multiple ORG directives in the source? -Fbin will sort all "ORG-sections" by their start address before emitting them.

Another option would be to use code, data, bss sections as usual and define their absolute addresses in a linker script.

hooverphonique · 19 September 2018, 09:38

Quote:

Originally Posted by Old_Bob

And, even that's incomplete as I can't see my "end of program" ASCII marker at the end of the file.

This sounds strange. Why would there be an ascii marker at the end of a binary file containing code?

meynaf · 19 September 2018, 10:39

Quote:

Originally Posted by hooverphonique

This sounds strange. Why would there be an ascii marker at the end of a binary file containing code?

Because the programmer put it there to check what the assembler produced ?

Old_Bob · 19 September 2018, 11:55

I put this in so I can keep an eye on the size of the game as it grows. There's a small routine at the start of the program that uses it to print out the address of the last byte when it runs.

Code:

				dc.b		"End of program"

end_marker			dc.b		$ff

Some more thorough examination reveals some interesting stuff...

The reason, as it turns out, that I couldn't find this marker at the end of the program. Is because it's not at the end of the program.

It's mixing up the order of things, FSR.

We can also see the first opcodes for the program code immediately following the $ff byte when it should be loaded to address $30000.

I'm wondering if it's just some simple noob option that I don't know about when building with vasm that's making this happen??

B

Old_Bob · 19 September 2018, 14:36

Got this sorted, at last.

It turns out you were all correct in that there was a stray SECTION data,DATA statement buried away in one of the includes from yonks ago.

It now works as the gods intended, in Asm-Pro, too.

I guess I've got no excuse now for not getting this damned game finished...

Thanks all, for your help.

B

hooverphonique · 20 September 2018, 10:36

Quote:

Originally Posted by meynaf

Because the programmer put it there to check what the assembler produced ?

Ahh.. I read it as something expected to be implicitly put in by the assembler

18 September 2018, 11:41	#1
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	Absolute addressing Hey, dudes. I've been revisiting my Bombjack game in the last few days, after a little break, and have run in to a bit of an obstacle. I'd like to use absolute addressing, but it's proving to be a real pain in the arse. If I try to assemble the source using Asm-Pro with an ORG directive it spits out a "relative mode error". Devpac assembles it fine, but has no option to output the binary directly. Vasm did correctly assemble and output some small test programs I tried using the -Fbin option but when I try to build the whole game, it churns out unusable nonsense. Can anybody give me some pointers here? B

19 September 2018, 11:55	#8
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	I put this in so I can keep an eye on the size of the game as it grows. There's a small routine at the start of the program that uses it to print out the address of the last byte when it runs. Code: dc.b "End of program" end_marker dc.b $ff Some more thorough examination reveals some interesting stuff... The reason, as it turns out, that I couldn't find this marker at the end of the program. Is because it's not at the end of the program. It's mixing up the order of things, FSR. We can also see the first opcodes for the program code immediately following the $ff byte when it should be loaded to address $30000. I'm wondering if it's just some simple noob option that I don't know about when building with vasm that's making this happen?? B

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
IDE68K addressing	Yulquen74	support.Hardware	3	16 May 2015 16:39
CDTV addressing questions	Yulquen74	support.Hardware	1	15 May 2015 11:43
Memory addressing	CmdrVimes	Coders. General	7	25 October 2010 22:20
Memory Addressing Architecture	Zetr0	support.Hardware	2	10 July 2007 16:55
Addressing modes	BippyM	Coders. General	17	03 February 2005 09:57

18 September 2018, 15:21	#2
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Are you mixing section and org statements, or use PC-relative addressing across sections? That would give you relative mode errors. What does the nonsense code look like? If you use vasm's binary output, it may pad the space between consecutive org statements, which might look like nonsense code.

18 September 2018, 20:16	#3
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	Thanks, dude. I'm using only the ORG statement, with no code sections of any kind in the source. The binary vasm outputs looks like part of the graphics/bob data. There's no actual code as such, that makes sense at least. And, even that's incomplete as I can't see my "end of program" ASCII marker at the end of the file. Using Devpac at least assembles correctly, so I guess I possibly could strip the extra chunk of stuff it sticks in at the start and maybe use it that way? B

19 September 2018, 14:36	#9
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	Got this sorted, at last. It turns out you were all correct in that there was a stray SECTION data,DATA statement buried away in one of the includes from yonks ago. It now works as the gods intended, in Asm-Pro, too. I guess I've got no excuse now for not getting this damned game finished... Thanks all, for your help. B

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