VASM / VLink Help

[guddler]

Any chance of some help with this please? To say that documentation on vlink is sparse is putting it somewhat mildly!

I've got two source files: asteroids.s and game.s

Between them I have four sections each defined with the .section assembler directive:

'CODE'

'VDATA'

'CRT0'

'SYS_VECTOR'

What I want to achieve is to have 'SYS_VECTOR' fixed at 0x7FFC since it is the jump vector table so HAS to be there or nothing will work. I would like 'CRT0' to take up the space immediately before that so all of my implemented BIOS functions (if you will) are at the top of ROM space, VDATA can be wherever, it doesn't matter, but let's say 0x7F00 and 'CODE' wants to be at 0x7800 because I only want to have to burn one ROM for now (the full code space is 0x6800-0x7FFF).

For now, let's forget about wanting CRT0 to be below SYS_VECTOR dynamically and just hard code addresses, so:

CODE = 0x7800

VDATA = 0x7A00

CRT0 = 0x7F00

SYS_VECTOR = 0x7FFC

My assembler commands are:

vasm6502_std -Fvobj $SRC/crt0_asteroids.s -o $OBJ/crt0.o

vasm6502_std -Fvobj $SRC/game.s -o $OBJ/game.o

My link command is:

vlink -o035143-02.j2 -brawbin1 -Tlinker.txt $OBJ/crt0.o $OBJ/game.o

My 'linker.txt' is pure guesswork and contains:

SECTIONS

{

. = 0x7800;

CODE : { *(CODE) }

CRT0 : { *(CRT0) }

VDATA : { *(VDATA) }

. = 0x7ffc

SYS_VECTOR : { *(SYS_VECTOR) }

}

(Which OK, is even more 'put it where you like' than what I really want, but it's a start!)

After a bit of messing about with undefined symbols everything builds with no errors. BUT my ROM file '035143-02.j2' is 0 bytes!

Any ideas please?

If I just do it all as a single file with include statements then things work but that's pain in the arse enough in itself as I then have to manually keep everything in check which I'm trying to avoid. I'm trying to make things re-usable if I can.

 

[guddler]

I have to be missing something fundamental here. Banging my head against a brick wall and I just can't get vlink to output anything. Despite no errors or warnings the output file is always 0 bytes

 

[cmonkey]

Sorry, can't help you with this one buddy as I've never used vlink

 

[pobtastic]

.CODE : { *.o(*) }

This means "put everything from .o files in the .CODE section".

Of course I'm assuming it's the same as "normal" ldscripts... https://sourceware.org/binutils/docs/ld/Scripts.html

Also... Where on earth did this sub-forum come from?! Has it always been here?!

pobtastic2015-01-02 19:50:41

 

[pobtastic]

Hmmm maybe the syntax is different then;

http://cpcsdk.googlecode.com/svn-history/r519/wiki/GenericMakefile.wiki

{{{

SECTIONS

{

.text : { *.o(*) }

}

}}}

...This means "put everything from .o files in the .text section" and is from something more specific.

 

[guddler]

I'm beginning to wonder if VLINK simply doesn't work when compiled under OS X. Though that would be kind of odd seeing as VASM is working fine.

Essentially, it doesn't matter what I put in the linker file (in terms of section names) I can't get it to output anything to the ROM. I did wonder if it had to have the standard sections (.text, .data, etc.) but even if I define .text and shove everything init, I still end up with a 0 byte file.

My latest attempt is this:

SECTIONS {

ROM3 0x7800 :

{

*(CODE)

*(VDATA)

*(CRT0)

}

ROM3 0x7ffa :

{

*(SYS_VTABLE)

}

}

Which again gives a 0 byte file and yet using the -M flag to show the mapping I can see that the linker knows all about my code and where is should be

Files:

game.o: CODE 7800(123), VDATA 7923(20) hex

crt0.o: CRT0 7943(4b), SYS_VTABLE 7ffa(6) hex

Section mapping (numbers in hex):

------------------------------

00007ffa ROM3 (size 6)

00007800 - 00007923 game.o(CODE)

00007923 - 00007943 game.o(VDATA)

00007943 - 0000798e crt0.o(CRT0)

00007ffa - 00008000 crt0.o(SYS_VTABLE)

 

[cmonkey]

Also... Where on earth did this sub-forum come from?! Has it always been here?!

This sub-forum came out of my desire to get a lot more people on this fine forum interested in creating games/demos for arcade hardware, instead of playing them!

I doubt my desire will be realised but if just one person gets bitten by the homebrew coding on arcade hardware bug then my job here is done!

 

[guddler]

Out of curiosity, if you use VASM for 68k, what do you use to link? Or do you just put everything in a single huge file?

 

[cmonkey]

I have all my source in a single file and 'incbin' all my binary data into it. I then just assemble it to a single binary, no linking required.

 

[guddler]

Goddammit, sounds like I'm over complicating things as always!!

Just can't shrug off modern OO practices even when working on old stuff

 

[cmonkey]

I never left the 80's, so I don't have that problem!

 

[RGP]

I want to solve guddler's problem as it's the right coding approach but the 80's side of my brain and C64/Amiga experience says go with cm' sway.

Someone's going to end up implementing a cruncher at some point - I want flashing bars during decrunch.

I can't offer much here just this minute but I probably would have done multiple ORG and include statements and then written a routine to split the final file into rom sized chunks

 

[guddler]

I've been sat here watching a film while at the same time tapping away on the laptop. I've literally just cracked it and got the linker to output a 2K ROM image with an address structure that will do as a starter for 10.

I'm saddened to say that to get it to output anything I had to literally use the standard section names '.text' & '.data' in my code which just really doesn't seem right as it appears to me to defeat the object of the syntax in the link file.

I'm going to play some more, I must have missed a fundamental option or concept somewhere. Probably in the assembler and the sections / labels.

 

[guddler]

OK then. For the record in case anyone else wants to do it...

You don't have to name your sections according to any standard names - I kind of thought that would be a little silly, but you do seem to need to start the section names with a . That may be in the documentation somewhere. I'll have a look when I'm a little less tired.

I would still like to auto-calculate the positioning of the 'BIOS' routines just below the jump table for for now I can live with it being hard coded. It would also be nice to be able to split it up into the ROMs as it grows automatically as well but I'll worry about that as it happens too!

So, this is the linker file that I have settled on for the moment which is working (note, rom0 & rom1 intentionally not used until everything no longer fits into rom2). Code and vector data are stored at the start of ROM, standard routines and jump table at the end. Both will grow and meet in the middle:

MEMORY

{

rom0 : org=0x6800, len=0x800

rom1 : org=0x7000, len=0x800

rom2 : org=0x7800, len=0x800

}

SECTIONS {

.code :

{

*(.code)

*(.vdata)

} > rom2

.bios 0x7f00 :

{

*(.crt0)

} > rom2

.data 0x7ffa :

{

crt0.o(.jtable)

} > rom2

}

After link, the result is as follows:

vlink -brawbin1 -Tlinker.txt intermediate/crt0.o intermediate/game.o -o 035143-02.j2 -M

Files:

crt0.o: .crt0 7f00(4b), .jtable 7ffa(6) hex

game.o: .code 7800(123), .vdata 7923(20) hex

Section mapping (numbers in hex):

------------------------------

00007800 .code (size 143)

00007800 - 00007923 game.o(.code)

00007923 - 00007943 game.o(.vdata)

------------------------------

00007f00 .bios (size 4b)

00007f00 - 00007f4b crt0.o(.crt0)

------------------------------

00007ffa .data (size 6)

00007ffa - 00008000 crt0.o(.jtable)

 

[guddler]

Arrgggghhhhh....

Bloody thing seems a bit flaky! Don't know what I've done but it's not working again

 

[cmonkey]

Seems like a lot of p*ssing around dude! Wouldn't the time be better spent actually coding rather doing all this stuff!

 

[guddler]

Yeah it would, but I'm a bit OCD on things like this. Once I've started I tend not to give up

If something should work then I'll make it.

Don't know if it's a bug or not, but it seems you need to have a '.text' section defined at the start of the code, even if the next line is some other section definition, then it all works.

I'm going up the shed to work on some PCBs today as I spent all day in front of my monitor yesterday and I've only got 2 days before I'll be back doing that for work all day every day. Tonight I'll hopefully make some proper progress!