Assemblers You Use

[Nemesis]

Just as an aside, how extensible is Exodus at this point? I know from the MAME source that all the Konami TMNT hardware games are basically 68k/z80/ym2151+pcm and whatever bespoke custom video hardware in different configurations.

It's very extensible. The actual emulation platform is quite thin, pretty much everything comes in the form of plugins, and the plugin interfaces don't require matching STL or compiler versions, so you can compile and release plugins separately at any time to extend what's already there. The emulation cores themselves are generic and aren't hard-coded to any particular system, and systems themselves are "wired up" through XML markup, so you can literally build a new system from existing cores just by writing an XML doc, or add support for a new system by dropping in plugins for any new emulation cores that are required.

[powerofrecall]

I love it. So you're saying I could in theory code up emulation for the video + ym2151 as modules and then map the whole thing out in xml? Is there an API spec or headers available for the plugins yet?

[Nemesis]

I love it. So you're saying I could in theory code up emulation for the video + ym2151 as modules and then map the whole thing out in xml?

Yep, that's been how I've built it to work right from the start.

Is there an API spec or headers available for the plugins yet?

Not yet, I'm working frantically towards that goal. The whole project will be going open source with the next release. There were a few large architectural improvements I wanted to make to the interfaces before I made them public and then had to deal with backwards compatibility, but a big change in regards to the way debug windows and menus are defined and interact with the emulation cores has blown out massively in the amount of time it's taken. It's coming towards a close now, but it's put me quite a few months behind where I wanted to be. I've still got to write a lot of documentation too, but that's an easier task, as I can just keep on developing and improving that at any time, it doesn't have to be 100% complete from the start or bound to some kind of release schedule.

I'm still realistically a couple of months away from release, simply because I only get so much time to work on this project between work, family, and life in general.

[powerofrecall]

The work you've already done on Exodus as a one-man show is basically incredible, and I think getting that extensibility out in the open is going to blow it up in popularity. Your debugger & active disassembly IMO is basically unmatched in emulation for its capabilities. I can't wait!

[r57shell]

As for assemblers I use, maybe I'm old fashioned, but I just stick with my hacked version of asm68k (to add support for spaces in paths and longer filenames).

Is it not enough just to enclose path in quotes?
I didn't know that there are some limitations.

Also, you can use "equ" to declare in RAM scope.

[Nemesis]

As for assemblers I use, maybe I'm old fashioned, but I just stick with my hacked version of asm68k (to add support for spaces in paths and longer filenames).

Is it not enough just to enclose path in quotes?
I didn't know that there are some limitations.

That didn't work originally, no, I had to hack the binary to make it work that way. You're probably running my tweaked version. If you just run it without parameters and check the usage instructions, you'll probably see a few lines I inserted at the top there explaining the edit.

[bgvanbur]

Can someone help me with a gas assembling issue?

A simple test named a.asm

Code: Select all

Test:
	dc.l	Test

Then I run:

Code: Select all

m68k-linux-gnu-as -m 68000 --mri -o a.o a.asm
m68k-linux-gnu-ld -nostdlib -e 0 --oformat binary -o a.bin a.o

And I get the following a.bin (hexified)

Code: Select all

00000000   80 00 00 00

Why does it assume the initial address is 0x8000000 and how can I fix it? Is there a better way to run gas for sega oriented development?

[MintyTheCat]

Can someone help me with a gas assembling issue?

A simple test named a.asm

Code: Select all

Test:
	dc.l	Test

Then I run:

Code: Select all

m68k-linux-gnu-as -m 68000 --mri -o a.o a.asm
m68k-linux-gnu-ld -nostdlib -e 0 --oformat binary -o a.bin a.o

And I get the following a.bin (hexified)

Code: Select all

00000000   80 00 00 00

Why does it assume the initial address is 0x8000000 and how can I fix it? Is there a better way to run gas for sega oriented development?

Check your scripts but does the ORG directive work the same in GAS as other Assemblers?

org $1000

With a tab before the Org should set you up, you can check in the output ROM. I am about to start using GAS instead of ASM68K due to the lack of flexibility in ASM68K compared to GAS.

[bgvanbur]

Using MRI style org 0

Code: Select all

a.asm: Assembler messages:
a.asm:2: Error: MRI style ORG pseudo-op not supported
m68k-linux-gnu-ld: cannot find a.o: No such file or directory

Using gas style .org 0

Code: Select all

a.asm: Assembler messages:
a.asm:2: Error: Unknown operator -- statement `.org 0' ignored
m68k-linux-gnu-ld: cannot find a.o: No such file or directory

I found that using a MRI linking script will set the origin to zero:

Code: Select all

m68k-linux-gnu-as -m68000 -M -o a.o a.asm
m68k-linux-gnu-ld -nostdlib -c a.mri --oformat binary -o a.bin a.o

Where a.mri has:

Code: Select all

BASE 0

[Mechanical Menace]

Why does it assume the initial address is 0x8000000 and how can I fix it? Is there a better way to run gas for sega oriented development?

You should really be building binutils for the m68k-elf target. (CPU family)-linux-gnu targets are expecting your binaries to be running on top of GNU/Linux, the entry point is (almost) always in the 0x80xxxxx range for those setups.

[bgvanbur]

You should really be building binutils for the m68k-elf target. (CPU family)-linux-gnu targets are expecting your binaries to be running on top of GNU/Linux, the entry point is (almost) always in the 0x80xxxxx range for those setups.

Thanks. I was trying to use prebuilt gas binaries and those were the only 68k already available in my distro's repositories. It seems it is best to build my own for z80, so I guess I should do the same for 68k too.

[Mechanical Menace]

Thanks. I was trying to use prebuilt gas binaries and those were the only 68k already available in my distro's repositories. It seems it is best to build my own for z80, so I guess I should do the same for 68k too.

Tbh I'd say that whenever you're planning on coding for "bare metal," even on the architecture of the computer you're using you should grab the latest source straight from GNU's servers and build it yourself. Even if you want to build a GCC cross compiler for each target it doesn't take long to build once you work out the right flags. I mean you may at a push want C++ as well as C support but do you really want Obj-C, Java or Fortran support?

[bgvanbur]

It wasn't bad at all to build m68k-elf and z80-unknown-coff from the binutils source. But the m68k-elf-ld still wants to place at 0x80000000 if not specified by some means.

I also contacted the vasm author and he is really nice and making a few updates to make the z80 oldstyle more compatible with other z80 assemblers (such as 0ffh support, make the colon optional for equ directives, and allow labels for RST if a org is specified so the target can be correctly converted to the immediate value, he said they should be available in tomorrow's daily snapshot).

[r57shell]

If you just run it without parameters and check the usage instructions, you'll probably see a few lines I inserted at the top there explaining the edit.

Code: Select all

SN 68k version 2.53

Copyright (c) 1988-1997 S.N. Systems Software Limited,  all rights reserved

USAGE : asm68k /options source,object,symbol,listing,temporary file
.....................

This is working:

Code: Select all

 org $0
 incbin 'qwe asd zxc'
 include 'qwe asd zxc'
 dc.l filesize('qwe asd zxc')

[MintyTheCat]

If you just run it without parameters and check the usage instructions, you'll probably see a few lines I inserted at the top there explaining the edit.

Code: Select all

SN 68k version 2.53

Copyright (c) 1988-1997 S.N. Systems Software Limited,  all rights reserved

USAGE : asm68k /options source,object,symbol,listing,temporary file
.....................

This is working:

Code: Select all

 org $0
 incbin 'qwe asd zxc'
 include 'qwe asd zxc'
 dc.l filesize('qwe asd zxc')

Yes, but that's for asm68k and he wants GAS' Org. Also, you had better tab that Org directive