Would it be worth making the Z80 driver assemble?

[Clownacy]

The AS branch has really nice Z80 support. Obviously that isn't the case with asm68k. I have an experimental branch that builds the driver using a separate assembler, compresses it, and then runs asm68k, which incbin's the compressed file like normal.

There are a few hurdles though. Firstly, finding a good assembler is a little tricky: VASM had a severe bug, last time I checked, ASMX is barebones, and AS is AS. AS is bagage I'd rather we find a proper replacement for in the future, so I don't really want to go with that, VASM flat-out doesn't work with the Z80 driver right now, and that just leaves ASMX.

ASMX ain't that great either. It's barebones, lacking in the most basic features like error messages that print variables or labels, it's buggy, and it's not even under an open-source license. The source code's a pretty easy read though, and I have taken the time to weed out the handful of bugs I've noticed in my fork.

Currently, my branch assembles bit-perfect, but there are still issues.

The Z80 driver and the ROM itself are both dependant on each other: the Z80 driver needs to know where the Sega chant is, and the 68k sound driver needs to know where the timpani pitch is.

To address this, I have a file a bit like C's .h files, which is included by both the Z80 and 68k code. This file contains hardcoded values for things like the Sega chant location, size, and where the Z80 timpani pitch is. If either assembler detects the constants don't match their generated equivalents, it flags a warning telling you what to change them to, but still assembles a ROM anyway. This is comparable to how S2's driver handles the size of the compressed driver.

But my question is, is this worth it? It technically makes using the disasm more difficult, since whenever you shuffle the ROM around, you have to update the header file. Not to mention, things like the Mega PCM installation guide obviously don't detail taking out the Z80 build system. Not that the Git disasms ever really cared about backwards-compatibility, I guess.

[FraGag]

There's also the option of using my assembler, though I wouldn't consider it "production-ready" yet (I'm not sure I like how macros work; it's mostly compatible with asm68k but that makes it not as powerful as it could be) and I haven't worked on it in a few years. reasm can assemble code for mixed architectures, and it could in theory handle compression directly.

I made a branch locally, based on master, that makes the 68k code assemble with reasm (on both Windows and Linux). I can publish it if anyone's interested.

[Clownacy]

Ah, neat, I'll give that a look when I get a chance.

[flamewing]

We could take a page from the ShiningForceCentral and do it like what they do for Shining Force II. And not just for the s1disasm, but also for s2disasm and skdisasm.

What they do is: separately assemble the sound driver and each music banks with AS. Then incbin the output and assemble the remainder with asm68k.

An advantage of this method: we could use the Saxman compressor stuffed inside s2p2bin, and the Kosinski compressor stuffed inside s3p2bin, to compress the sound driver before the incbin/binclude.

But even better: we could have the S2 songs decompressed, assemble them, Saxman-compress them, and finally add them to the appropriate sound banks.

Using the a command line switch from AS would allow creating an assembly include with shared constants, which could be used for defining music and SFX IDs to be passed along for the other steps.

[flamewing]

One issue about what I just said (and which I just realized) is bankswitching: the bank numbers are required inside the driver, and you need to know the location of the banks in ROM. I have no solution for it in the SFII-based setup I proposed.

[Awuwunya]

I am a little late to this, but using my Z80 macros for ASM68K, with some limitations (some Z80 syntax will inevitably be different to the official specifications), you are able to both build and compress Z80 drivers without a lot of overhead. In particular, I used this approach recently to compress the Z80 code for Dual PCM for AMPS. Although the setup there is messy (and using an external tool as opposed to 3 instances of ASM68K would make more sense), I think its a good proof of concept for assembling compressed Z80 drivers in ASM68K. It has the same limitation as the Sonic 2 and S&K disassemblies where you must tell the driver size beforehand, but I think its a fair compromise to make.