News: 11 March 2016 - Forum Rules

Author Topic: New Assembly Coding Support Page and An Offer to Help Program Tools  (Read 7873 times)

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
I'm currently adding additional features to an existing (Merlin32) 65c816 assembler/linker tool and also writing a program that accepts the binary output of that tool and uses the results to directly patch an SNES ROM. The idea here was to create a "one step" toolset to allow an assembler programmer to go directly from editing some code into a new or modified ROM to test out, using a single command at the CMD prompt in Windows. All that works now and, if interested, you can visit my web page on the topic at: One Step Patching of SNES ROMs Directly from SNES Assembly Code and Data Tables.

However, I'm now investigating the idea of further modifications to the Merlin32 assembler/linker tool. Instead of directly patching an SNES ROM, it might be better that the tool emit something in the format of IPS, BPS (byuu), UPS, PPF and/or DPS or some other existing patch format. I had written my own patch program because I wanted to directly accept the binary output files from Merlin32 (which are completely unformatted and where one such file is created for each and every distinct "segment" of patch code/data) and patch an SNES ROM directly from them without any additional steps involved. For simplicity and expediency, this meant bypassing the creation of specialized formats like IPS or BPS because I frankly didn't need them to do the work. It was, earlier, easier to just use the binary data directly. I'd like suggestions about what patching formats to support, because I'm frankly very ignorant about what people like to use. I would gather from the pages I've already read here that IPS is widely used. (Which I will definitely support.) But I'd like ideas about other patching formats to help me assess which other formats to support, as well. (I'm considering doing more with the Merlin32 source code. It has all of the information required to generate patch files in IPS format (or others) without needing my specialized patch program. So long as the assembler coder knows where things are at and has properly written their source code, it can directly emit IPS format files. So I'm thinking about making that adaptation now.)

I'm also interested, now that I'm considering spending more time supporting my son who is writing new SNES code and data tables, in hearing about other requests for useful hacking tools. I may be happy to help, if I can understand with clarity what is being requested. I do NOT know well the needs of people doing ROM hacking (my knowledge, experience, and worldview is much more closely aligned with those who write assembly code to create new routines, functions, data tables, or entirely new games of their own.) But I'm open to learning about what people are actually doing and what kinds of tools they wish they had. I may be able to help out. But I'd need as clear a description as possible. If there really isn't anything new needed, I'm happy to just keep enhancing assembler/linker tools to generate patch files supporting standard patch formats. But I'm opening the door to other needs, since I'm focused on supporting my son and trying to otherwise help out where I may. (I can write operating systems, assemblers, compilers, multivariate symbolic computation, editors, simulators, and pretty much anything where I understand the goals. I've 40 years' experience doing this professionally for companies such as Intel. So don't be shy about the need and instead let me decide if it is outside the scope of my offer.)

I will also go through the thread, "Hack ideas: for those without the skill but with all the ideas." But I wouldn't mind newly directed suggestions added here (unless the moderators object, of course.) It saves me time having to scan through some 140 pages of discussion!
« Last Edit: May 04, 2016, 01:30:52 pm by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

nesrocks

  • Hero Member
  • *****
  • Posts: 738
    • View Profile
    • nesrocks.com
Oh wow I am editting super pitfall (nes) right now and it would be great to have a map editor and metatile editor. I could make a mockup of what I think it should look like if you think you can help. I can give you exactly the data format and exactly what the tool has to do if you're interested on that idea. Basically it would load a rom, it would look for data on the preset addresses and it would provide a graphical interface for map editing and metatile editing based on chr data (also preset addresses). The editing itself would be a lot like hex editing, but the graphical interface is what would help imensely in the process. Then save the changes back to the rom.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Oh wow I am editting super pitfall (nes) right now and it would be great to have a map editor and metatile editor. I could make a mockup of what I think it should look like if you think you can help. I can give you exactly the data format and exactly what the tool has to do if you're interested on that idea. Basically it would load a rom, it would look for data on the preset addresses and it would provide a graphical interface for map editing and metatile editing based on chr data (also preset addresses). The editing itself would be a lot like hex editing, but the graphical interface is what would help imensely in the process. Then save the changes back to the rom.
I'm interested in any help where it isn't currently already pretty well-covered and where it seems to be of some general interest (like, two or more people?) I don't mind the idea of an NES-specific editor. And map and metatile editing doesn't scare me. It's mostly going to come down to how well I can fathom what needs to be done and whether or not I can accept the time risks in moving forward with it. I'm most familiar with PC programming today, though I know Unix/Linux pretty well (I worked on the Unix v6 kernel in 1978, for example.) So platform questions come up in my mind. I also expect to have ZERO proprietary interest in the source code and will release it fully for any use. And for Windows hosts I can write in C, C++, C#, VB.NET, and F# more easily. So there may be some preference of language to be worked out, too. It doesn't really matter to me. I'm fluent in everything from ancient COBOL, FORTRAN, ALGOL, and PL/I to more modern .NET tools like VB or C# or more functional languages like F#. It's just all slight variations of syntax to me.

Let me start with this question: Would it be best to save directly to the rom? Or would it be just as helpful, but perhaps more broadly useful, if it instead saved things in IPS or BPS format (or some other such format?) that would then be applied to the rom as a patch? Either way seems fine to me. And, as I gather things, saving directly the rom doesn't preclude using the already existing tools from creating the patch file from a pair of rom sources, either. So I suppose it doesn't really matter, either way. But is there a preference?
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

AWJ

  • Full Member
  • ***
  • Posts: 105
    • View Profile
Maybe you don't realize this because it doesn't apply to DQ3, but the most common cartridge memory mapping on the SNES (more than half of all games) is noncontiguous: the ROM is mapped across the upper halves of each 65816 bank.

008000-00FFFF: first 32KByte
018000-01FFFF: second 32KByte
028000-02FFFF: third 32KByte, etc.

In hardware terms, the connection from address bus lines to ROM address lines skips over A15. Does your linker/patcher support this?

nesrocks

  • Hero Member
  • *****
  • Posts: 738
    • View Profile
    • nesrocks.com
Great, I suppose C# would be best because I have some familiarity with that. I'll whip up an interface reference and give you the details and you see if it can be done.

Yes, saving directly to rom is preferable because there's a lot of going back and forth with testing. IPS can always be created later by comparing the changed rom to an original one.
And great about the open source! I was wishing that'd be true because I can improve on the editor later!

STARWIN

  • Sr. Member
  • ****
  • Posts: 454
    • View Profile
I recommend not spending coding time for patch format support as the wheel already exists and is simple.

elmer

  • Full Member
  • ***
  • Posts: 122
    • View Profile
Nice to see another "old-timer" having fun doing some useful stuff and stopping the brain from turning to mush!  ;)

I'm currently adding additional features to an existing (Merlin32) 65c816 assembler/linker tool and also writing a program that accepts the binary output of that tool and uses the results to directly patch an SNES ROM.

I'm curious about you decision to modify Merlin32 rather than, say, CC65/CA65.

Is there some specific thing that made you decide to choose to work on one open-source project instead of the other?

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Maybe you don't realize this because it doesn't apply to DQ3, but the most common cartridge memory mapping on the SNES (more than half of all games) is noncontiguous: the ROM is mapped across the upper halves of each 65816 bank.

008000-00FFFF: first 32KByte
018000-01FFFF: second 32KByte
028000-02FFFF: third 32KByte, etc.

In hardware terms, the connection from address bus lines to ROM address lines skips over A15. Does your linker/patcher support this?
Take a look at the web site I mentioned earlier: One Step Patching of SNES ROMs Directly from SNES Assembly Code and Data Tables. You can specify the ROM format. You can even mirror memory, as well, where the output of the assembler will be automatically patched into more than one location on the rom file format (though I've no idea why that might help anyone, it does support the concept.)



May 04, 2016, 04:01:24 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Nice to see another "old-timer" having fun doing some useful stuff and stopping the brain from turning to mush!  ;)
Thanks! I love doing this kind of stuff and would do it free for my clients, just because I love it so much. (But please don't tell them that!)

I'm curious about you decision to modify Merlin32 rather than, say, CC65/CA65.

Is there some specific thing that made you decide to choose to work on one open-source project instead of the other?
At the time, I was looking for something completely open-source, relatively uncomplicated, and where it would be "easy" to get my son using it. I also didn't expect to have to modify the assembler toolset, hoping instead that it would work for him right out of the box. And, finally, I knew up front that I'd have to write a tool to take the output and to directly apply it to ROM files for him. So the output had to be "easy" for me to handle. I did NOT want to have to deal with object file record types for my patching process. Not at first, anyway.

Keep in mind that he already had a LOT of binary bytes for the code and tables he'd spent a few months developing. I wanted to encourage him to move to symbolic assembly. So it had to work with what he ALREADY had developed. This meant perhaps dozens of tiny "patch" areas. I wanted to make it easy for him to specify the patch areas he already was using and their sizes and to let a relocating assembler accept various source files, relocate them to patch areas he directed them towards, and then to generate a collection of binary output files I could then apply as patches in an automated process.

An alternative would have been to find an assembler/linker toolset that generated an IPS patch file. Or to find one that produced a single, simplified object file format that I could then read and apply, as the final link-time output. But a lot of what I saw didn't actually get there for me.

Merlin32 solves the problem quite well, already. But I'll take a further look at CC65/CA65. He won't need C, at all. But if the assembler tool can be used as an alternative, that's fine. The patching tool I wrote can accept any number of binary files and apply them, but it does generate a Merlin32-specific linker file. It wouldn't be hard to adapt it to CC65/CA65, if those tools support linker files I need to prepare and output file formats I can consider supporting. I'll check it out.

Merlin32 did the job, was in open source, had relatively uncomplicated linker specifications, and referenced just a few documentation files. My son will NOT use the web for any web-based documentation (he's like that) so the docs must be off-line, in nature. It was, in this case. Which solved that problem, for me, too.

Unfortunately for me, Merlin32 didn't handle PC RELATIVE (BRA and the conditional branches) and PC RELATIVE LONG (BRL) across modules in the linking process. They worked fine within a single assembly. But not across, via externals, in the linking process. So I fixed that, as well, using the open source.

I'll add that I started out just writing the darned assembler from scratch, using the WDC assembly documentation as a guide. My thought there was that I'm quite familiar with writing symbolic assembler tools already and I could be absolutely certain that I would make a tool that would exactly adapt to my son's hesitance regarding using an assembler, if I wrote it myself. (After examining some of the web available assemblers, like WLA, I was pretty much certain I'd have lots of trouble getting him to use them.) I was about half done with it in three days' work, but stopped that project when I found Merlin32 while looking for assembly instruction docs. So I guess this is an admission that I didn't search well enough or long enough, as perhaps I should have.

And finally, Merlin32 was a dead-easy drop-in for the freely available Microsoft Visual Studio as a project (though I have an MSDN subscription.) I didn't have to do anything. Just dropped the source into a project and compiled. That simple. No need for Watcom, etc.



May 04, 2016, 04:16:21 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I recommend not spending coding time for patch format support as the wheel already exists and is simple.
I take your point!



May 04, 2016, 04:17:25 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Great, I suppose C# would be best because I have some familiarity with that. I'll whip up an interface reference and give you the details and you see if it can be done.
I'll be happy to look it over!

Yes, saving directly to rom is preferable because there's a lot of going back and forth with testing. IPS can always be created later by comparing the changed rom to an original one.
And great about the open source! I was wishing that'd be true because I can improve on the editor later!
Point made. I agree.
« Last Edit: May 04, 2016, 04:20:11 pm by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

Klarth

  • Sr. Member
  • ****
  • Posts: 498
    • View Profile
Keep in mind that he already had a LOT of binary bytes for the code and tables he'd spent a few months developing. I wanted to encourage him to move to symbolic assembly. So it had to work with what he ALREADY had developed. This meant perhaps dozens of tiny "patch" areas. I wanted to make it easy for him to specify the patch areas he already was using and their sizes and to let a relocating assembler accept various source files, relocate them to patch areas he directed them towards, and then to generate a collection of binary output files I could then apply as patches in an automated process.
I'm not sure exactly what your son is doing. There's a pretty strong division between fully-featured assemblers meant to create demos/games from scratch and assemblers meant to apply small code changes to games (ie. what romhackers are interested in). The most commonly used of the latter form are xkas for SNES and armips for other systems. I would much prefer making a "build script" for a game where xkas is called multiple times to insert/overwrite game code from assembler source code than applying a series of IPS/xdelta patches.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
I'm not sure exactly what your son is doing.
My son is completely replacing many different functions as well as replacing entire string tables and other data items. There are some arrays of string pointers that must sit at fixed locations (for now), but where the pointers themselves can point at entirely relocated strings. He also needs to be able to craft specific global symbols at specific addresses to annotate existing functions not being replaced, to make it easy to call them by symbol rather than by address (for future changes there.) The code and data must be able to be relocated, as desired. And this means that there may be dozens of holes he's created when replacing things, that may be used by the relocating linker to "back fill," when things can fit there. As well, of course, being able to specify other regions he finds are "unused" at the time. The size of his own contributions is moving rapidly towards the order of several thousands of bytes of code and still more of data. That's part of why I was pressuring him, for months now, to get active with an assembler instead of hand-coding everything.

There's a pretty strong division between fully-featured assemblers meant to create demos/games from scratch and assemblers meant to apply small code changes to games (ie. what romhackers are interested in). The most commonly used of the latter form are xkas for SNES and armips for other systems. I would much prefer making a "build script" for a game where xkas is called multiple times to insert/overwrite game code from assembler source code than applying a series of IPS/xdelta patches.
I'd like to see some examples, then. I don't know about xkas. But I'd be happy to learn about it. It sounds interesting.

For some reason I didn't find it when earlier searching for 65c816 assembler and linker tools. I also wanted to support his modifications of NES code, as well. So I did want an assembler that could limit itself to 6502.

Regarding IPS patch generation, I'm not currently doing that. I'm instead directly patching the ROM file format from the assembly source code information and generated, post link-time, binary segment streams.

But I'll check it out. Thanks!

As an aside, if it hasn't already been clear by this point, I DO REQUIRE that the source code be completely available and available by free license for any modifications I choose to make. Lacking that, I'm not interested.
« Last Edit: May 04, 2016, 05:03:39 pm by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

elmer

  • Full Member
  • ***
  • Posts: 122
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #10 on: May 04, 2016, 05:12:40 pm »
I'd like to see some examples, then. I don't know about xkas. But I'd be happy to learn about it. It sounds interesting.

It's just a complete reversal of what we'd normally expect from development tools.

In "development", you're usually producing "object" files and then letting the "linker" sort out where to put things ... and as the "developer", you usually don't care exactly where that is (within limits).

The "hacking" assemblers (like xkas) take the opposite approach.

You start by loading memory with an existing ROM image, and then you assemble your instructions on top of that existing image, allowing the programmer to specify exactly where in that image that the assembled instructions start.

That makes hacking/patching an existing image ... trivial.

The actual syntax for the assembly language doesn't change, nor do the pseudo-ops, just the internal details of how something like ".bank" or ".org" actually operates, and when the determination of the final address is made ... i.e. at "link" time in traditional developement, and at "assemble" time when hacking.

Since I'm currently doing a translation for the PC Engine, I use the open-source PCEAS for all the assembly-language patching that I need to do.

If I were developing something new, i.e. "homebrew", it would be with CA65/LD65, which provide a much-more-flexible environment that is tuned to "creating" rather than "hacking".

Your desire to add IPS or other "patch" support to Merlin32 basically comes from using the wrong (IMHO) tool for the job ... you'd be better off using a "hacker's" tool like xkas for modifying SNES ROMs ... AFAIK they already do what it is that you want to modify Merlin32 to do.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #11 on: May 04, 2016, 05:22:52 pm »
The actual syntax for the assembly language doesn't change, nor do the pseudo-ops, just the internal details of how something like ".bank" or ".org" actually operates, and when the determination of the final address is made ... i.e. at "link" time in traditional developement, and at "assemble" time when hacking.
For you and me, the internal syntax details aren't all that important. For my son, I needed to make the process of moving from hand-coded binary to using an assembler tool "easy." I looked at WLA, for example, and found the syntax "daunting" as far as getting my son to use it. So I looked away from that tool, for example.

It also needed to be something where he could move gradually away from Lua + hand-coding, towards a symbolic assembler. Right now, I think he will be keeping some "text to data" conversion algorithms in Lua, generating DB assembly source instead of binary, and then using the assembler to assemble the rest. But it's a "process" for him. He's not there, quite yet. It's still a mixture.

Since I'm currently doing a translation for the PC Engine, I use the open-source PCEAS for all the assembly-language patching that I need to do.
Open source is important. I like having access to the linker, as well. This allows me to enter into the process at the pre- and post- link phase and to examine the final segments being emitted.

If I were developing something new, i.e. "homebrew", it would be with CA65/LD65, which provide a much-more-flexible environment that is tuned to "creating" rather than "hacking".
I've already taken a few minutes looking it over. I still need to read more, of course. But I've started the process. At this point, it is just a little bit more complex to use out of the box than Merlin32 is (my perception, knowing him.) However, I may move him off of Merlin32 and in this direction, as my time and his willingness allow. So thanks for another good recommendation here!

Your desire to add IPS or other "patch" support to Merlin32 basically comes from using the wrong (IMHO) tool for the job ... you'd be better off using a "hacker's" tool like xkas for modifying SNES ROMs ... AFAIK they already do what it is that you want to modify Merlin32 to do.
Yes. I have gotten that point. I will NOT be adding IPS or any other format to the Merlin32 assembler/linker. I was considering it and, given the excellent thoughts and advice here, have recognized my ignorance on this topic. Thanks to you and others here! However, I will be further considering the idea of interceding at the post-link phase to do direct patching using a very generic output rom format description language as input to the toolset.


As a separate aside given your knowledge of CA65, do you feel it should be very easy to use the toolset there (assembler and linker) to transition from hand-coded binary towards assembly source code that is readily (and trivially) patched into some working ROM for direct use immediately after the multi-module assemble-link step? (I'm trying to avoid complex link-input structures that require assumed prior knowledge of C compiler object code models that are often required when using tools designed for both C and asm.)
« Last Edit: May 04, 2016, 05:33:47 pm by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

Klarth

  • Sr. Member
  • ****
  • Posts: 498
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #12 on: May 04, 2016, 05:36:22 pm »
It's impressive that he's managed to keep a project that large completely unorganized yet still functional. The rest of this response will be from the reverse engineer's perspective and the status quo.

I'd like to see some examples, then
Build system is more of an overglorified term for a batch file here. Basically you start with a clean ROM, call xkas to apply various assembler source files to the ROM, call other programs to operate on the ROM, etc and you end up with a "production" ROM in one click. An example of assembly mod using xkas is FF6 stat growth modification by Lenophis.

Quote
My son is completely replacing many different functions as well as replacing entire string tables and other data items. There are some arrays of string pointers that must sit at fixed locations (for now), but where the pointers themselves can point at entirely relocated strings.
For string tables, we use programs like Atlas, which I wrote and is open source, to reinsert text that was dumped by a hex editor or other program. Early console games do not use standard character encodings like ASCII or Unicode and typically must have character conversion tables made specifically for that game's text encoding. Programs like Atlas can repointer strings, but rely on the end user to specify where the pointers and the initial position of the string table are located at in the ROM.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #13 on: May 04, 2016, 05:44:57 pm »
It's impressive that he's managed to keep a project that large completely unorganized yet still functional. The rest of this response will be from the reverse engineer's perspective and the status quo.
Yes, I'm actually rather shocked by the scope. It was only as I began to hear more about the mistaken encodings, which as the project grew lead to ever-increasing re-work here and there, that I began to push. He is autistic and doesn't readily engage "new" things. He knew about writing in assembly, but getting him to actually get on the web (for anything) is like pulling teeth. Getting him to download something off the web is nearly impossible. He was used to Lua because it is used as a back-end in some emulators. So that's what he used, while using the emulator disassemble capability to uncover and learn about the coding going on there. (I gave him manuals on the 65c816 to read.) I let him be, things grew, and eventually stuff got drawn-out in time long enough that I got a clue about his struggles with hand-coding and some better idea of the scope he was tackling.

Build system is more of an overglorified term for a batch file here. Basically you start with a clean ROM, call xkas to apply various assembler source files to the ROM, call other programs to operate on the ROM, etc and you end up with a "production" ROM in one click. An example of assembly mod using xkas is FF6 stat growth modification by Lenophis.
I still need to find out if xkas is open source and open licensed. But I will look around sometime soon. Thanks again for the clue.

For string tables, we use programs like Atlas, which I wrote and is open source, to reinsert text that was dumped by a hex editor or other program. Early console games do not use standard character encodings like ASCII or Unicode and typically must have character conversion tables made specifically for that game's text encoding. Programs like Atlas can repointer strings, but rely on the end user to specify where the pointers and the initial position of the string table are located at in the ROM.
I know that he is using two completely different encodings for strings in the current translation patched version of Dragon Quest 3. (Because he brought it to my attention, recently.) It's worth my time to find out if your tool handles the encodings he's doing in Lua, right now. So I'll take a look. I have the PDF doc loaded up already, in fact. Again, my thanks!



May 04, 2016, 05:49:21 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Just a note: I see that "As of march 2013 I have stopped maintaining cc65." (And by implication, CA65??) Looking at the FTP, it may take me a little bit to figure out where all the source code is located (CC65, CA65, LD65, and whatever else may be required to create a full toolset from the ground up.) There is an easy one that actually includes "source" in the .bz2 download filename. But I'll need to look inside to see what it has and doesn't have.
« Last Edit: May 04, 2016, 05:53:49 pm by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

elmer

  • Full Member
  • ***
  • Posts: 122
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #14 on: May 04, 2016, 06:42:04 pm »
Just a note: I see that "As of march 2013 I have stopped maintaining cc65." (And by implication, CA65??) Looking at the FTP, it may take me a little bit to figure out where all the source code is located (CC65, CA65, LD65, and whatever else may be required to create a full toolset from the ground up.) There is an easy one that actually includes "source" in the .bz2 download filename. But I'll need to look inside to see what it has and doesn't have.

It's still under active development, with a mailing-list and everything.

Oliver Schmidt (a long time contributor) took over the project and moved it to Github (http://cc65.github.io/cc65/).

I had a "patch" merged into the mainline codebase only a few weeks ago.  ;)


I've already taken a few minutes looking it over. I still need to read more, of course. But I've started the process. At this point, it is just a little bit more complex to use out of the box than Merlin32 is (my perception, knowing him.) However, I may move him off of Merlin32 and in this direction, as my time and his willingness allow.

The LD65 linker script is definitely something that took me a few hours to figure out. It provides complete flexibility in the linking, so that it can pretty-much output nearly-anything that you want ... but that that flexibility comes with the price of having to figure out the script so that you can get your first program written.

Here's what I wrote to help some guys in another forum ...

------------------------

CC65/CA65 are working perfectly fine as a compiler/assembler.

I've built a test-rom with it to confirm that it compiles standard C code (a FAT32 library for reading the Everdrive's SD card).

It was easy to use and incredibly flexible once you've got your head around the power of its code-layout and startup options.

The point is that it's all configurable and you get to decide where the linker puts the startup-code/library-code/game-code/data.

The guy that was working on the PCE-port hasn't committed anything new in about 4 months. But that's not really a problem since he was definitely a novice on the PCE and was doing some things in a very strange (and wrong) way.

Because it's all "linked", we can just use the bits of his CC65-specific code that we like, and override anything else with new code.

Then, if you want to make a CD, you have to piece-together the .iso binary with something like 'bincat' and then modify the 2nd-sector with your particular

------------------------

Here's my batch file for compiling the test code ...

Code: [Select]
# C files.

cc65 -O -t pce hello.c
cc65 -O -t pce fatfs/ff.c
cc65 -O -t pce fatfs/diskio.c
cc65 -O -t pce fatfs/option/unicode.c

ca65 -t pce -v hello.s
ca65 -t pce -v fatfs/ff.s
ca65 -t pce -v fatfs/diskio.s
ca65 -t pce -v fatfs/option/unicode.s

# ASM files.

ca65 -t pce -v crt0.s
ca65 -t pce -v text.s
ca65 -t pce -v sd.s

# Link

ld65 -o hello.pce -m hello.map -C pce.cfg hello.o text.o sd.o fatfs/ff.o fatfs/diskio.o fatfs/option/unicode.o crt0.o pce.lib

------------------------

I decided to use the following layout for the HuCard ...

The STARTUP & library CODE go in bank $00 that lives at $E000-$FFFF.

The INIT code and the 'initialized' DATA (that get copied to RAM) goes in bank $01 that lives (temporarily) at $C000-$DFFF.

Once the HuCard starts up and my customized crt0.s runs the INIT code, and copies the 'initialized' DATA to RAM, then I map banks $02-$05 into $4000-$DFFF for my main code, and leave $C000-$DFFF for paging code/data as I need to.

Now I'm not saying that this is a particularly great way to lay out a HuCard, but I needed an uninterrupted 32KB for the FAT32 code, and the big point is that I was easily able to do that with CC65.

And here's my customized CC65 configuration file for that layout ...

Code: [Select]
SYMBOLS {
        __STACKSIZE__: type = weak, value = $0300; # 3 pages stack
}

MEMORY {
        # Preserve System Card standard ZP locations.
        ZP: start = $00, size = $ec, type = rw, define = yes;

        # reset-bank and hardware vectors
        ROM0: start = $E000, size = $1FF6, file = %O, fill = yes, define = yes;
        ROMV: start = $FFF6, size = $000A, file = %O, fill = yes;

        ROM1: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
        ROM2: start = $4000, size = $8000, file = %O, fill = yes, define = yes;
        ROM6: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
        ROM7: start = $C000, size = $2000, file = %O, fill = yes, define = yes;

        # First RAM page (also contains stack and zeropage)
        RAM: start = $2200, size = $1E00, define = yes;
}

SEGMENTS {
        STARTUP:  load = ROM0, type = ro,  define = yes;
        INIT:     load = ROM1, type = ro,  define = yes, optional = yes;
        CODE:     load = ROM0, type = ro,  define = yes;
        RODATA:   load = ROM0, type = ro,  define = yes;
        DATA:     load = ROM1, type = rw,  define = yes, run = RAM;
        SDCODE:   load = ROM2, type = ro,  define = yes;
        SDDATA:   load = ROM2, type = ro,  define = yes;
        BSS:      load = RAM,  type = bss, define = yes;
        VECTORS:  load = ROMV, type = rw,  define = yes;
        ZEROPAGE: load = ZP,   type = zp,  define = yes;
        EXTZP:    load = ZP,   type = zp,  define = yes, optional = yes;
        APPZP:    load = ZP,   type = zp,  define = yes, optional = yes;
}

FEATURES {
    CONDES: type    = constructor,
            label   = __CONSTRUCTOR_TABLE__,
            count   = __CONSTRUCTOR_COUNT__,
            segment = INIT;
    CONDES: type    = destructor,
            label   = __DESTRUCTOR_TABLE__,
            count   = __DESTRUCTOR_COUNT__,
            segment = RODATA;
    CONDES: type    = interruptor,
            label   = __INTERRUPTOR_TABLE__,
            count   = __INTERRUPTOR_COUNT__,
            segment = RODATA,
            import  = __CALLIRQ__;
}

I guess that it would help to explain a couple of things in the configuration file (it's for the "LD65" linker).

The "MEMORY" section is basically just a list of areas (and their sizes) that get written to the output file ... in this case I'm having it create an 8 bank HuCard ROM image.

The actual names of the different sections in "MEMORY" can be anything ... I'm just using the name "ROM" + bank-offset for my own convenience.

The "SEGMENTS" section defines the names of the different segments in the C and ASM code (user-defined, but with a few defaults like CODE/DATA/RODATA/RAM), and it shows where in the output file those segments should be put.

That's it ... you have total flexibility to map your code/data into the output HuCard/ISO image in any way that you like.

------------------------

As a separate aside given your knowledge of CA65, do you feel it should be very easy to use the toolset there (assembler and linker) to transition from hand-coded binary towards assembly source code that is readily (and trivially) patched into some working ROM for direct use immediately after the multi-module assemble-link step? (I'm trying to avoid complex link-input structures that require assumed prior knowledge of C compiler object code models that are often required when using tools designed for both C and asm.)

Well ... since you can split up your source files and create as many "MEMORY" and "SEGMENT" definitions as you like, then AFAIK you can make the binary output look like anything that you want.

But note ... I haven't actually tried to make it write out a file as a bunch of "header+chunk" sections, which sounds more like what you're after.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #15 on: May 04, 2016, 06:50:45 pm »
Here's what I wrote to help some guys in another forum ...

Cripes! Thanks very, very much. As you point out, LD65 might take some getting used to. But I very much appreciate the effort at discussing details here. I'll dig in and play with the tools a bit over the next few days or week. It may turn out this is a better direction for my son. I'll see.

Note: He and I are based on Windows tools and I don't/won't ask him to work with Cygwin (or me, with MingW.) It has to be source I can readily compile on Windows for use with Windows.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

elmer

  • Full Member
  • ***
  • Posts: 122
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #16 on: May 04, 2016, 07:49:54 pm »
Cripes! Thanks very, very much. As you point out, LD65 might take some getting used to.

Hahaha ... it's a bit of a nasty-shock, isn't it!  ;)

Then again, it doesn't seem much worse than the GNU LD scripts that I've been messing around with for the PC-FX.


Quote
Note: He and I are based on Windows tools and I don't/won't ask him to work with Cygwin (or me, with MingW.) It has to be source I can readily compile on Windows for use with Windows.

I don't know if you're still using the original MingW/Msys environment, but if so, I can heartily recommend moving to the newer MingW64/Msys2 project ... those guys have done a really great job (for both 32-bit and 64-bit Windows).

I compile all my stuff as pure Windows-native applications (that don't need MingW64/Msys2), and that includes building GCC cross-compilers, CC65 and my customized version of Mednafen.

<EDIT>

Here are some links for one version of the XKAS assembler ...

http://www.romhacking.net/forum/index.php/topic,19640.0.html

https://github.com/devinacker/xkas-plus
« Last Edit: May 04, 2016, 09:31:11 pm by elmer »

dougeff

  • Sr. Member
  • ****
  • Posts: 358
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #17 on: May 04, 2016, 10:32:05 pm »
Cc65 (c compiler) may not be ideal for SNES development, as it only produces 6502 specific ASM code...while compatible with 65816 processors, it doesn't compile 16-bit related things (direct page, 16-bit processing). However, the CA65 assembler can use all the 65816 ASM, and is excellent for SNES development.

BTW, if I were going to modify NES code, I would use a disassembler like Frantik's disasm6 ...
http://www.romhacking.net/forum/index.php/topic,12177
which can reassemble with asm6, but with a little effort, could also assmble with CA65. That is how I would convert binary to ASM.

Someone told me once there was an SNES disassembler out there (Github*) which can generate ASM code from an SNES ROM. I tried it once with Geiger's Snes9x disassembly tool, but it was a mess, since various 8 vs 16bit modes were wrong producing gibberish ASM.

*maybe this is it
https://github.com/pelrun/Dispel

« Last Edit: May 04, 2016, 10:59:53 pm by dougeff »
nesdoug.com -- blog/tutorial on programming for the NES

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #18 on: May 05, 2016, 12:01:01 am »
Cc65 (c compiler) may not be ideal for SNES development, as it only produces 6502 specific ASM code...while compatible with 65816 processors, it doesn't compile 16-bit related things (direct page, 16-bit processing). However, the CA65 assembler can use all the 65816 ASM, and is excellent for SNES development.
Got it! Thanks.

BTW, if I were going to modify NES code, I would use a disassembler like Frantik's disasm6 ...
http://www.romhacking.net/forum/index.php/topic,12177
which can reassemble with asm6, but with a little effort, could also assmble with CA65. That is how I would convert binary to ASM.
Now that one I'm going to examine soon. Thanks!! It has to be better than using the simulator's disassembly.

Someone told me once there was an SNES disassembler out there (Github*) which can generate ASM code from an SNES ROM. I tried it once with Geiger's Snes9x disassembly tool, but it was a mess, since various 8 vs 16bit modes were wrong producing gibberish ASM.
*maybe this is it
https://github.com/pelrun/Dispel
Thanks. I'll follow up on that. A good disassembler is quite complex. Data has to be sussed out and things cross-checked several ways to Sunday. It would be wonderful to find a truly good edition of such a thing. So I will look around at the suggestions there!

Thanks again!
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

nesrocks

  • Hero Member
  • *****
  • Posts: 738
    • View Profile
    • nesrocks.com
Re: New Assembly Coding Support Page and An Offer to Help Program Tools
« Reply #19 on: May 05, 2016, 10:41:58 am »
Hey jonk I've sent you a personal message.

It got me thinking into a new feature for fceux: it would be nice if fceux would allow to load a PPU pattern table as a "tbl" in hex viewer and view the rom contents in graphical format. I think this is up to the fceux devs though.