Is ALN actually required?

[cdoty]

Having recently used NeoDev GCC (http://www.neobitz.com/Pages/DevTools/DevLibrary.aspx) to do some Neo Geo and Genesis development, I got to wondering if the same thing could be used for Jaguar development.

 

Does ALN do anything special, besides GPU and debug symbols? And it appears that the GPU stuff isn't really needed (The MOU example doesn't use it).

 

It's fairly easy to modify the linker script and startup code to work with the Jaguar, and objcopy could easily convert the cof file to binary format.

 

I intend to look into this more this evening, but wanted to know if there's something I'm not thinking of or don't know about.

[Starcat]

Hi!

Having recently used NeoDev GCC (http://www.neobitz.com/Pages/DevTools/DevLibrary.aspx) to do some Neo Geo and Genesis development, I got to wondering if the same thing could be used for Jaguar development.

 

Does ALN do anything special, besides GPU and debug symbols? And it appears that the GPU stuff isn't really needed (The MOU example doesn't use it).

 

It's fairly easy to modify the linker script and startup code to work with the Jaguar, and objcopy could easily convert the cof file to binary format.  

 

I intend to look into this more this evening, but wanted to know if there's something I'm not thinking of or don't know about.

 

I am a bit confused by your post. ALN is the linker, not the assembler.

MadMac (mac.exe) is the assembler.

Personally I never looked into Neo Geo or Genesis coding, and I also didn't use C for Jag programming yet, so I can not tell for sure if you could use the same tools.

 

Basically however you should be able to use whatever tools for Jaguar programming that create binary 68000 code. At least if you do not want to use GPU/DSP assembler.

You are right that Jaguar programs can be written using only the 68000.

For displying graphics you also need to use the Object Processor, but you can create the object processor lists with the 68k as well, although this is quite slow for long lists.

 

Anyway, it's great to see that you are interested in Jag coding.

I think you will enjoy Jag coding if you did genesis and neo geo stuff before.

 

Regards, Lars.

[cdoty]

GCC includes a C compiler, assembler, and linker.

 

The linker is involved in producing the debug symbols, and would(might?) determine where the GPU code would reside in the binary.

 

The assembler doesn't really matter as long as it can produce object files understood by the linker, it's the linker that's critical in producing a correct binary.

[cdoty]

I got ALN running under DosBox last night, so that will help me in determining if NeoDev GCC will work.

 

In the DosBox config file, I had core set to dynamic and it was producing a page fault. Changing it to full fixed the problem. It does crash once in a while, but works other than that. I think dynamic is the default setting for DosBox.

[justclaws]

Hello,

 

I got ALN running under DosBox last night, so that will help me in determining if NeoDev GCC will work.  

In the DosBox config file, I had core set to dynamic and it was producing a page fault. Changing it to full fixed the problem. It does crash once in a while, but works other than that. I think dynamic is the default setting for DosBox.

That's good. Does MadMac run as well ok with DosBox?

 

Regarding your earlier question, indeed neither MadMac nor ALN are

needed for Jaguar development. The early homebrew (Underground)

demos like JagTris, the BJL bundled code, JagMania, and many others

from the JagServer (pre BJL) era were written initially using Atari ST

systems, running Hisoft Devpac, a classic 68000 assembler. It was

only much later that the Atari MadMac/ALN tools became available.

 

The guys who created the UGD-Dox also created Jaguar assemblers

and disassemblers, as did Bastian42 for the Jag. They did not expect

to have Atari licenced tools available, for homebrew development...

these tools are still around, if you are happy using an ST or emulator,

and some of them are available for the PC/DOS environment as well.

 

Cheers,

JustClaws.

[cdoty]

Yep, the mac assembler runs fine also. I don't think any of the parallel tools will work any better, but there seems to already be a workaround to that.

 

I took the recently posted GCC jaguar based environment, and replaced the make with the DJGPP make and added CWSDPMI. It all works fine. I can build the examples in SOURCE and WORKSHOP.

[cdoty]

DosBos seems a bit cumbersome though...

 

NeoDev will work just fine.

 

Here's a link to the TestRGB sample converted to compile with NeoDev:

http://www.emuvibes.com/JaguarGCC.zip

 

This uses Visual Studio 6 (or at least nmake).

If using NMAKE, add 'C:NeoDevBIN' to the path.

If using Visual Studio, you need to add the bin path to the Directories under Executable files

 

Tools->Options...

Show Directores For:

Executable Files

Add 'c:NeoDevbin' to the end of the list.

 

The make files all assume C:NeoDev as being the directory where the NeoDev system is installed.

 

NeoDev can be downloaded from:

http://www.neobitz.com/Pages/DevTools/DevLibrary.aspx

 

Another thing that should be done is to drop the JaguarBJL.x into

'C:NeoDevm68km68k-elflibldscripts' and change the location in the FrogDebug.mak (and FrogRelease.mak).

 

The output is BIN (not JAG), and needs to be converted to JAG with a line under '$(BIN) --gap-fill=$(PADBYTE) --pad-to=$(ROMSIZE) -R .data -O binary $(BUILD)$(Name).obj $(Name).bin' in the .mak files.

 

There is no difference between the two .mak files, except for where the object files are stored. This was done to support the default Visual Studio project. This could be used to build different version of the program (CD, BJL, cart...)

 

The only conversion I've had to do were:

1) Change comments from ';' to '*'.

2) Move all comments at the end of the line to the start of the previous line.

3) Change '$" to 0x.

4) Change % instructions to 0x instructions.

5) Change 'equ' or '.equ' to '='

6) Remove '.phrase' and '.dphrase'

7) Remove the license_logo macro, and convert the logo to an obj file using bin2elf (see the enclosed 'gfx.bat' file).

Remove GPU related code, and access the OLP pointer directly.

9) Lines like move.l #(BRANCHOBJ|O_BRLT),d1 were easiest to convert to:

move.l #BRANCHOBJ,d1

or.l #O_BRLT,d1

10) Values such as:

ori.l #(BMP_PHRASES<<18)|(BMP_PHRASES<<28),d1

has to be converted to:

BMP_ORPHRASES = (BMP_PHRASES << 18) | (BMP_PHRASES << 28)

ori.l #BMP_ORPHRASES,d1

11) '::' had to be changed to ':' and add a .globl statement. For example:

_start::

becomes:

.globl _start

_start:

12) Remove '.68000' and '.long'. Their not needed once the GPU stuff is removed.

[cdoty]

Here's how I've allocated memory:

 

0x00004000-0x0017FFFF is program memory

0x00180000-0x0019DFFF is data memory (is this too small?)

0x0019E000-0x001FFFFF is reserved for the stack.

 

Is there any problems with this allocation?

[cdoty]

It will not build unless you create a Debug (or Release) directory under the Jaguar directory.

[cdoty]

I've posted my version of the NeoDev emvironment, which includes prebuilt libraries, Jaguar, Neo Geo and, Genesis linking scripts and extra stuff removed.

 

http://www.emuvibes.com/NeoDev.zip

 

The example needs to be modified to use 'C:NeoDevm68klibJaguarBJL.x' instead of 'C:NeoDevm68km68k-elfJaguarBJL.x'. I Have a new .mak file which will attach a correct JAG header to the front of a generated BJL file.

 

I've also created a version that will create a cartridge (and apply the universal header), if anyone is interested. The result will run under MESS.

This also involves a new .mak file.