Disassembling X68k Software and Programs

[exodusmodules]

Well, because of my impatience, instead of taking the time to learn to read Japanese, I decided to learn to program in assembly for the x68000 by reverse engineering existing programs. My main goal for a first program is either a vgm player or music tracker, because music is the reason why I'm so interested in this system.

There are a few memory maps for the x68000, and with some research and the likes, I should be able to piece together ideas of how some programs work.
Here's a good start (I haven't analyzed it yet, just disassembled with dasm68). I have no idea yet whether the disassembly is completely correct, but the one way to find out is to attempt to assemble it (I'm tempted to "accidentally" stumble on a copy of IDA Pro floating around the internet because it's a much better disassembler, and I don't have half a thousand bucks to buy it with). It's a disassembly of the note.x mml compiler.

[exodusmodules]

Double post.

So after some digging through the note.x binary, it seems that it has a 130-byte long header? Not sure but I did see what I thought was some 68000 machine code immediately starting at byte 133.

Code Select Expand

................$Header: /src/mfi/RCS/note.has,v 2.8 1995/08/23 07:07:56 DIS Exp $
EDIT: What is quite interesting is that the header contains the file location of what seems to be the assembly source that note.x was assembled from.
Above is a nice human readable header. I came to the conclusion that the header ends at byte 130 because there's a nice USD symbol before the text that says "Header blah blah blah" and another after the last piece of human readable text (at the beginning of the binary, at least) . Then there's two null bytes before the "machine code" (or at least what I think is machine code) begins.

At the end of the note.x binary, we have 990 bytes of nice (English!!!) human readable text ...which seems to be the Human68k prompt text output and some MML stuffs.

Code Select Expand

mml file converter for mxdrv2 v0.8.5 1994,95 by DIS..usage: note [switch] <mml file[.mml|.mus]>...switch ¥¥¥ -m<bufsiz>.mdx buffer size (default:64)....   -x..octave reverse....   -p..ex-pcm mode....   -r..remove file....   -i<channel>.channel mask....   -b..beep at error....   -l..output 'pcmuse.map'....   -o..old pcmuse.map|new pcmuse.map....   -c[n].compress length....   -t[name].save tone data....   -w[name].save wave data....   -z[dvqpt012].optimize command....   -v[0|1].verbose....   -e..ignore error(-t/-w/-l)... converted by note 0.8.5..mml..mus..mdx.pcmuse.map.tone.bin.wave.bin.dvqpt012.FLAT.SHARP.NORMAL.NATURAL.[  TITLE  ]: .[ PCMFILE ]: .[ T O N E ]:.[ PCM:000 ]:.         A.ch   B.ch   C.ch   D.ch   E.ch   F.ch   G.ch   H.ch...         P.ch   Q.ch   R.ch   S.ch   T.ch   U.ch   V.ch   W.ch... TOTAL:. LOOP :.==== ..channel ==========================....[31m..[m... .¨ ..........ABCDEFGHPQRSTUVW....,,.2.ª.v.d...........P.(...6.......@...:.....8...:.$.2.R...6.V.*..

If you've written any music in MML and/or used note.x on the x68000, then you should recognize some of this as MML macro related things. If you don't, then you should really read my MML documentation: http://gamesx.com/wiki/doku.php?id=x68000:mxdrv_mml_mdx_tutorial.

So the big question...what is required to get a program of our own creation, in 68k assembly, running on the x68k? An nice header? Random but necessary human readable bytes at the end?

Well, on my next venture, I'm going to try to compile some C code of my own for the x68k and then analyze the assembly generated by gcc.

Also, I'm in the process of comparing some VGM tunes I logged from XM6 Pro to some audio code from the game "Parodius Da!" to figure out exactly how data is written to the YM2151's and OKI's registers through memory. The FM memory area is from 0xe90000-0xe91FFF, and the ADPCM memory area is from 0xe92000-0xe92FFF. I'm analyzing the data written to those memory areas.

EDIT: Attached is a vgm I logged from Parodius. Knowledge and documentation of the VGM format specification is helping me a good bit.

[kamiboy]

Music hardware as always goes way above my head. But it seems we are crawling slowly closer to a music playback library that people, chiefly myself, can drop into their game projects.

[Pinwizkid]

I'd love to see a music tracker program for the X68000 capable of loading any MDX file. I can't offer any guidance on the programming side, but having used several trackers in the past I may be able to provide some graphic concepts for the GUI, perhaps in the style of MMDSP (shame that player didn't have a tracker built in!)

Best of luck on your research

[neko68k]

You have a few options for getting C built to run on an X68.

• XC: Sharps official tools. Not recommended for a lot of reasons.
• GCC 1.3: This is the recommended toolchain. It seems to be the most overall compatible and working C toolchain and has regparm support which is pretty nice.
• GCC 2.6.3: I finally got this to produce a working DooM binary but it has an unidentified problem in the raycasting part that isn't present when built with 1.3. Because of this I can't recommend you use it.
• Lydux GCC 4.6.2 cross tools: This can be a workable solution if you are only doing simple C programs or carefully writing assembly. The newlib port is very incomplete and it seems to have problems related to relocations so compiling very complex things(DooM...) isn't going to work.

There are also considerations around what assembler to use if you aren't using Lydux tools. All of the on machine tools use one version or another of Sharps AS or HAS. These assemblers are similar to GAS but they're a bit wonky in places. Output from the disassembler DIS should, but won't always, rebuild using some version of HAS. DIS doesn't seem to produce correct output all the time but there are myriad options and maybe it's workable for whatever if you poke at it hard enough. The nice thing about DIS is that it marks IOCSCALL, DOSCALL and other things in the disassembly which can make reading the output a bit easier.

There is also the debugger DB, which is a bit similer to GDB, and its upgraded "graphical" cousin SCD. They work with output from any of the toolchains as long as you've enabled debug symbol output. They're a little wobbly but they work pretty well.

All that being said; you're really going to have to learn Japanese or get really good at using OCR and Google Translate and figuring out what things mean. The tools and the best documentation are going to be difficult to use and understand if you can't manage the language somehow. Otherwise it'll be like using a hammer when you just need to walk across the street and buy a screwdriver at Home Depot

Go peep the X68000 docs at the Data Crystal wiki and get a copy of Inside X68000.

I have an HDS specifically set up for development that includes the 3 C toolchains and a heap of UNIX tools (like the DASH shell and typical UNIX things). I can probably put it somewhere if you want a copy.

I should probably properly write all this up someday. ~shrug~ If you have questions, ask. I don't promise to have an answer, but I might.