Wait, what, didn't I just release an entire emulator a couple of weeks ago? Where the heck did this come from? Here's something I've been quietly working on for a while now: for my honours project at university, I've developed a partial clone of asm68k (also known as S.N. 68k) which aims to function as a drop-in replacement for it. Currently it assembles the Sonic 1 Git disassembly and SuperEgg's Sonic 2 Nick Arcade prototype disassembly without any problems. Unfortunately, software which makes use of asm68k's more elaborate features (like Aurora Fields' Z80 macros, vladikcomper's debugger, and radioshadow's Dr. Robotnik Mean Bean Machine disassembly) do not currently assemble, but I do plan to eventually make this assembler support them. clownassembler! 'clownass' for short. ;) The idea behind this is to alleviate the community's dependency on a dusty old EXE that's a pain to edit and to run on other platforms (such as Linux, especially on non-x86 architectures). Now, I know, that's what switching to AS was meant to do, and that failed, causing fragmentation. So how is this assembler supposed to avoid the same fate? Simple: AS was not compatible with asm68k, meaning that code made for asm68k had to be tediously ported to AS. This was a hurdle which harmed adoption. clownassembler aims to avoid this by working with the exact same assembly code and the exact same build scripts as asm68k. Converting a disassembly to clownassembler is as simple as replacing the S.N. 68k 'asm68k.exe' file with clownassembler's. Don't believe me? Here's a video: And here's a video showing clownassembler building the asm68k version of the Sonic 1 Git disassembly on Linux with zero modifications: Being an open source project written in good old C, Flex, and Bison means that modifying this assembler should be infinitely easier than modifying the closed-source blob of x86 assembly that is asm68k or the sprawling codebase of AS. As with clownmdemu, portability is a focus of this assembler. As a showcase of this, the Windows builds on GitHub have been compiled with MSVC 12.0 (the one bundled with Visual Studio 6, from 1998). Good luck finding an operating system that this assembler can't run on! I'd talk more about my goals for this assembler, but I don't want to start making any big promises. For now, I think that it's best to just enjoy clownassembler for what it currently is: a drop-in asm68k replacement for projects that don't make use of asm68k's more exotic features. Download Windows Builds (You'll probably want 'clownassembler_asm68k.exe', as that's the one that's compatible with asm68k's interface. The other one has a custom, simpler, interface that is incompatible with it.) Source Code Development Like with clownmdemu, I've been documenting the development of clownassembler on my blog. There are currently four posts, and I'll cross-post any future ones here. 2022/02/28 2022/03/17 2022/03/22 2022/03/29
I've been looking forward to this for a long time. I would have shortened the name to "clownasm" myself ;-) I actually really want to hear about these goals; I'm assuming native Z80 assembly is among them?
Yes, the idea is to eventually be compatible with AS as well as asm68k. Before I get around to that though, I want to flesh out the asm68k support.
Very interesting. asm68k does a thing where it replaces some instructions with equivalent ones. There's one in Sonic 1 and I found a few more in Streets of Rage 2. Presumably this will always use the correct instructions for byte-perfect ROMs? Two features of AS that I always wished asm68k had are Z80 support and custom functions. In fact, I might've switched to AS if not for its lack of a filesize function. I tried it with my Sonic 1 disassembly (with Z80 macros removed), and it didn't work. Apparently there's an issue with the ptr macro:
The errors are caused by 'strcmp' and 'equs' not being supported yet. My assembler should produce the correct machine code for each instruction: that one 'exg' instruction in Sonic 1 definitely assembles correctly.
Oooh This is really great! Is there support for "debugging symbols", if not, planning for it? I've been thinking with MD Studio that bigevilcorporation has hosted on his github account. I'm rewriting it though in wpf because I feel I can do more with it (I hope). But I'd love to add this assembler to it.
It can generate .sym files if that's what you're referring to. At some point, I want to get the listing files to resemble asm68k's, which would give another way to obtain symbols, but that hasn't been done yet.
Ah, cool. I'm going to look through your code just to get an idea on how it all works. Any chance you can point me to to the .sym generation? As a side note, I looked at your emulator too. I really like how simplistic it is compared to others - so much easier to get around and see what's going on. Not that it matters, but you get my stamp of approval lol
Sure, it's in the DictionaryFilterProduceSymbolFile function of semantic.c. The filter is ran once for every symbol in the symbol table at the very end of the assembly process. The code that calls this function is responsible for creating the header of the .sym file.
Since I recently migrated away from Windows to Linux, this will be crazy helpful with working on my Sonic 1 project once the missing features get implemented! (I'm using a lot of Aurora Fields' stuff along with vladikcomper's debugger)
