museum-of-art-and-digital-entertainment/macross

Macross 6502, the assembler written by Lucasfilm Ltd. that was used for Habitat and SCUMM

macross's Issues

Slinky is getting wrong answers when writing the binary

If I create the hello.m test program and use the commands you state on your blog to build it, the linker fails as it attempts to jam the value $3ff8 into a single byte. On Linux, the link succeeds but the value loaded in the binary for the "text" variable is $0705 instead of $c007. Oddly enough, this only appears in the .bin file; the .sym file correctly names the intended locations.

Slinky: how does org work?

I am having problems with organizing. I think I am missing something....for I would expect the following code to produce output to be at least 0x8000 bytes in size, but it is only 23 bytes.

start 0x0000

lda 0
sta 0

org 0x8000

lda 1
sta 0

I've also tried block and align, but with similar results.

Questions about build tools

I'm decent with build infrastructure and I like to help, but I don't want to push anything that's not wanted/needed. So, without further ado:

• Does macross require GNU make (with extensions), and not some minimally POSIX-compliant make?
• Is there any interest in autotooling?
• Is anyone absolutely against autotooling?
• Is the project better served by "simple" Makefiles instead? How many?

Does not build on GCC

As noted in the release announcement, this doesn't yet build on GCC or MSVC. I've started looking into this, and the primary problem we have here is that extern functions are being declared inside the functions that use them, instead of in header files. Worse, some of them are being declared inconsistently (see, for instance, evaluateOperand, which takes two arguments when called but only one when defined.)

I'm working on cleaning this up in my fork so I can get a pull request out of it. I'm trying to make it a minimal set of changes, but even with that this will probably get us about halfway to ANSI C.

Code should be updated to ANSI C

This has several subtasks:

• Function prototypes for everything that is used in other files (GCC support required some of this but not for everything)
• Match up functions to include files as ultimately standardized
• Many functions that take format strings should really be varargs functions that forward to vprintf
• Remove calls to deprecated functions like mktmp and use the preferred functions instead
• There are some extremely dire errors involving objects being missized at link time by hundreds of bytes. We should look into that
• Ideally, in doing this we could make the code 64-bit clean. That's a task of unknown size at present and might be better tracked as a separate issue.