Oh my god, this makes me IMMENSELY happy. I wasn't even aware of this project (Merlin 32)! Cross-assembling 65816 on present-day systems is painful (matter of opinion, and I don't want to get off-topic, but I really dislike several aspects of ca65 while appreciate others, and WLADX's documentation is bizarre (I've complained on nesdev about this before) and old bugs in it always tainted my opinion), so to see a present-day build of something I'm familiar with from days of old is delightful. Thank you!
With Windows moving into 64-bit, and refusing to support 16-bit operation there, the utility of 16-bit applications has dropped a lot. I keep a 32-bit VM (hypervisor) available for use when I want to fire up 16-bit command line program execution. But it is a pain, regardless.
I was working at Intel (which at the time owned half of Phoenix -- the BIOS folks) when they were assembling the teams to produce 64-bit BIOS support. And I stood there arguing with the managers during a very large meeting when they were moving towards a decision to boot either 64, or 32, but not to support both 64 and 32 bit modes within the BIOS, let alone 16. In fact, the 32-bit team (who held a higher "status") just wanted to isolate their work from anything that the newbie 64-bit team did, forcing the 64-bit team's future to exist in isolation.
To me, the sad thing was that the newer 64-bit cores would support 16-bit, 32-bit, and 64-bit code execution, simultaneously, without any trouble at all. The hardware design is very, very flexible and quite good. (I was working on chipset design and testing there.) But the software folks were making a veritable mess of things by decisions they were taking.
I'm guessing that Microsoft had to pick up the pieces they were dealt and decided that they weren't going to single-handedly "fix" things, anymore. Just live with it. Which means the rest of us are living with it.
I did try and make solid arguments that day there. I was the ONLY one to push hard, though. And I was brushed off, in the end.
I'll be sure to check out ASMPATCH as well. Historically I've just split games up into separate PRG banks/sections and disassembled them, then analysed and hand-edited the disassembly to resemble something more manageable, tie it all together using the equivalent of PUT in Merlin syntax (for others: .incsrc, .include, etc.) or binary includes for the rest. What you've written there would make my life a *lot* easier on romhacking projects.
I expect there is a learning curve to it. I just hacked out stuff for my son, giving him what he said he wanted. Then, when he wanted more, I added that as well. Of course, I was using my own approach to designing the solutions.
I also added something he wanted, too. I wrote a bit of a disassembler for it, that works from the command line. My son would "know" a memory address in the ROM for a subroutine that was being called and he wanted a way to just say "disassemble the subroutine which starts here in the ROM." And he wanted me to "auto-figure out" where the subroutine ended, too. (Darn him.) So I wrote code to do a reasonable approximation of that. It helps him make quick work of re-writing subroutines, because he can get the assembly code source auto-generated for him, use CMD/DOS to output that into a file, use an editor on it and change the code to his liking afterwards. Saves typing time. Then he can re-assign the new subroutine to an open block of memory and patch the calls to repoint there, often leaving a small hole for other code. That hole can be added to the list of holes in my ROM description, which can then later be used for relocation of other, smaller bits, if desired.
It's actually got quite sophisticated. But I may yet spend more time on it to add more features. If you know of anything you'd like changed, or added, or would otherwise make it easier and handier, let me know.
Topic: Where did you learn assembly from? (Read 12969 times)