nfg.forums

Is the sample code from any of the many how-to-program-the-X68000 books actually available for download anywhere?

The only thing that I've found so far is the ASM skeleton on the FTP server here.

Did the full source to any of the games ever get leaked/released?

Being able to see working examples would make it a lot easier to understand all the stuff in the Inside X68000 book.

Have any of the other programming books been scanned?

Not a lot of people interested in programming, then. 

 Hi Elmer !

Here you go.

Shooting Passion source code
http://nfggames.com/forum2/index.php?topic=5541.msg38069#msg38069

Keep the scene alive !
Eidis

Quote from: elmer on March 01, 2016, 02:11:50 AM
Not a lot of people interested in programming, then. 

I am. I'll get into it eventually. Just swamped with uni/work stuff right now.

The main reason i've stayed out of x68k dev is the scarcity of english documentation.

That programming for a, by any standard, obscure Japanese PC platform is super niche should not come as a surprise to anyone.

I am interested as well of course, but only in C, not assembly. Plus I prefer figuring things out on my own rather than try to decipher someone else's complex code. Not that I imagine there being much C source code available out there to sift through.

It is a sgame that master Lydux no longer graces us with his arcane knowledge in these here parts. He knows more about X68000 programming than just about anyone in the English speaking world.

I busted out my toolchain today. Lets see if I do anything with it.

I guess while I'm at it, here's some fixed up copies of DOSCALL.MAC and IOCSCALL.MAC to use with your assembler code. You can use these with the .include directive and then make calls:

.global main

.text

.include "../includes/doscall.mac"

main:

| Your code start here.

pea hello_string
DOS _PRINT
addq.l #4, %sp

clr.l %d0 | return value
rts

.data

hello_string:
.string "Hello world !\r\n"


DOSCALL.MAC
IOCSCALL.MAC

You can refer to the docs here for details how each function works.

Here's what the X68000 compiler binary formats look like. Objects, libraries, executables, etc. Only xfiles are supported in the lydux toolchain. Anyone got experience with BFD? It'd be nice to have LK object and library support.

HLK - kaiseki.txt - LK Object Formats

Thanks for the links. Any examples are good to see.

Quote from: neko68k on March 05, 2016, 08:39:36 AM
Here's what the X68000 compiler binary formats look like. Objects, libraries, executables, etc. Only xfiles are supported in the lydux toolchain. Anyone got experience with BFD? It'd be nice to have LK object and library support.

I know that the ".x" files are the executable files on the platform.

What are the "LK object and library support" formats used for? Are they the object and library formats for the Hudson C compiler?

Yeah, thats what they are. Sample code? No. However there is tons of source available for X68000 programs though its almost entirely written in asm.

[edit]
I feel I should also mention that basically none of the assembly that's available will work in the lydux toolchain. You have to use HAS060 and HLK. None of the objects that HAS060 or the original XC and GCC 1.x/2.x toolchains will link with the lydux toolchain, hence the need for HLK and my interest in adding support for the old school objects.

HAS060
HLK

There's definitely a question of "how should I develop?" going through my mind.

All the "old" development was obviously done on the X68000 itself with tools like HAS060, XC, GCC 1.x/2.x.

"Modern" development for "embedded" platforms (and the X68000 would count as one of those) is often done with cross-assemblers and cross-compilers, and that's the style of development that lydux was going for.

Attempting to get the "modern" cross-development GCC toolchain to read all of the old object formats is way-beyond my interest level.

But I would certainly like to have a little easier time when it comes to using old source code examples, particularly in assembly.

As such, changing the GCC/binutils "defaults" so that the gnu assembler is a little more programmer-friendly is definitely something that appeals to me.

In particular, getting rid of the damnable "%" in front of the register names in GAS is on my list-of-things-to-do.

It already accepts Motorola-syntax for the addressing modes, so that's not a problem.

Using "vasm" for assembly-language development is another possibility that I should look into.

Quote from: neko68k on March 06, 2016, 09:18:06 AM
I feel I should also mention that basically none of the assembly that's available will work in the lydux toolchain. You have to use HAS060 and HLK. None of the objects that HAS060 or the original XC and GCC 1.x/2.x toolchains will link with the lydux toolchain, hence the need for HLK and my interest in adding support for the old school objects.

Another alternative would be to add X68000 executable support to vbcc/vasm/vlink (http://sun.hasenbraten.de/vbcc/).

I just had to fix an uninitialized-variable bug in lydux's binutils patch, and so spent some time looking at the details of the ".x" format.

It's very-much-like the old Atari TOS executable format, and there's already support for that format in vbcc/vasm/vlink to provide a template.

The other advantage is that vasm seems like a decent assembler, and that it might no be too hard to compile vbcc/vasm/vlink to actually run on Human68K as well as target it.

Just a thought.

Quote from: elmer on March 08, 2016, 09:02:03 AMI just had to fix an uninitialized-variable bug in lydux's binutils patch, and so spent some time looking at the details of the ".x" format.

Do you remember what the bug was? I recently built the toolchain and I'd like to fix it. Clang's -Wconditional-uninitialized didn't find anything in xfile.c, and my host OS (AArch64 macOS) doesn't support MemorySanitizer.