For example, I plan on porting a plain-jane copy of SMB2jDIS (Super Mario Bros Lost Levels Disassembly By Doppelganger) to CA65 instead of ASM6,
But first... I need to make a working template for a .FDS Image as a base, But it looks like a simple CFG file won't do it alone.
Would someone find a way around this?
I've seen no ca65 FDS projects but there are for asm6 here:
viewtopic.php?f=2&t=15169
Didn't I already make it clear from the beginning?
ASM6 is what I have just already known and talked about for use with FDS,
CA65 may be a good assembler to switch to when needed.
It is not very possible right now due to the specifics on how the CFG must be setup.
I tried contacting the current CA65 Github Issues page about this, It's a No Go!
What exactly makes ca65 unable to assemble an FDS project?
I generally agree with the other commenters in that GitHub issue that an assembler is not really an appropriate tool to use for generating a disk image.
Is there an existing command-line tool to generate FDS images from individual files? I think integrating that into the build process would work much better and would require much less assembler-specific configuration for projects in general.
You'd probably need a specialized linker script anyway to spit out a separate file for each overlay segment, which segments the command-line builder combines into a .fds/.qd file.
And then you'd need to distribute the builder to anyone who wants to build your project, and the method by which that is done depends on the language in which the builder is written. Do more people have, or are more people willing to install, a Python 3 interpreter or a C++ compiler?
If anyone is willing (this is not forced), try to make it with C.
thefox wrote:
A similar reference:
https://github.com/cc65/cc65/pull/259So would this tool just have to link a bunch of .bin files together and slap a header at the beginning?
Mostly?
Each file has a
bunch of attributes, though; more than just a filename and a size.
ccovell has already adapted an existing FDS lister to be able to extract the actual data blocks, but there isn't a great place to put the extra metadata for reassembly.
I took a look at an asm6 fds example, and I don't think that ca65 is really the right tool for the job.
You could use segments for the different files on the disk, but then you'd be modifying the cfg file constantly. Especially since the files don't seem to have a set size, and I don't think ld65 will take a rom segment without a size (note: don't think).
There's also using just one module for the whole project and then the cfg file is pretty simple, but then you'd need pad commands which the assembler doesn't seem to have either.
Maybe I'm not the right person to be trying this but afaik asm6 is the way to go for making fds files no matter how you intend to do it.
nicklausw wrote:
You could use segments for the different files on the disk, but then you'd be modifying the cfg file constantly. Especially since the files don't seem to have a set size, and I don't think ld65 will take a rom segment without a size (note: don't think).
If you don't specify
fill=yes in a
MEMORY area, the
size is treated as the maximum size of that memory area, not its exact size.
Quote:
you'd need pad commands which the assembler doesn't seem to have either.
ca65 has
.res, which adds a particular number of bytes rather than adding enough bytes to get to a particular address.
nicklausw wrote:
You could use segments for the different files on the disk, but then you'd be modifying the cfg file constantly. Especially since the files don't seem to have a set size, and I don't think ld65 will take a rom segment without a size (note: don't think).
The linker is allowed to define symbols about the segment size which you can use in the code (they get patched in at link time, just like all other linked symbols). See:
define = yes.
I did try to make an old fds asm6 example compatible with ca65. It's...alright, I guess.
A big problem is that the way I did things, files use a config called file.cfg and the final fds uses fds.cfg. For files, I'm just blindly assuming they'll all be size=$4000, and for the final fds I got lazy and ended up setting the size=$4000+8548. If dynamic segment sizes were a thing, my set-up would probably be alright but I can't find anything even like that.
If anyone here wants to mess with it, I'll upload.
EDIT: sorry, I didn't see tepples' post above somehow! Trying his suggestion now.
I might as well just upload my disaster here for anyone who wants to see. Running the fds gives a disk error. The code is very sloppy in that it uses previously made and bloated cfg files, gross looking code (not an insult to original creator but I haven't been going for cleanliness), and pretty sure I put ".segment "CODE"" three times in a row somewhere in there...but this is just annoying me. Maybe it'll fill in some blanks for someone else trying to do this with ca65.
Build with build.sh, windows users just rename it to build.bat and run that. Just please don't try using this as a template. You won't get very far
.
Edit, I just figured out why it doesn't work but am not at my computer...didn't pad the fds header to be 16 bytes.
Edit: this example now lives at Github. This post below will be left intact for posterity, but please find the latest version of this example here: GitHub repositoryHere's a modified version of my
simple ca65 example program to run on FDS.
Rather than trying to do everything with CA65/LD65, it uses ca65/ld65 to assemble a binary file and then creates the FDS with a python (3) script.
While you could technically just build the file in ca65/ld65, it feels a lot more sensible just to assemble the FDS with a secondary tool. I might make a third version just to demonstrate how to do it in ca65/ld65 alone though.
edit: eventually reconsidered that maybe an external python script wasn't that great either, and would recommend instead the version below that skips the license (or the ca65 only version just above it if you want to keep the license for some reason). keeping this uploaded here for posterity, though, just in case it's wanted.
Why is this hard to do in ca65? And why does it make more sense to use an additional tool for it?
To me it sounds like it would be better if the assembler could do it without outside help.
Here's the ca65/ld65 only version, demonstrating that you can in fact do it without any additional tools.
Pokun wrote:
Why is this hard to do in ca65? And why does it make more sense to use an additional tool for it?
To me it sounds like it would be better if the assembler could do it without outside help.
I don't think it's "hard", you can look at the example I am posting now to see exactly how it looks.
I just think it's easier to work with an external tool than write all the extra boilerplate in the ca65 stuff. You could make some of it cleaner with macros, but the config files have to be the way they are. Though maybe it's just me, already having python installed and ready to go, and used to just using it to write quick/simple tools whenever I need them. Admittedly it's not really a big difference either way.
I see, thanks for the example!
Using the
technique described here, I've made a third version of the example that skips the license screen.
This is convenient because it makes the startup sequence a few seconds faster, but also prevents your program from lying to the user about a license from Nintendo.
(This is built upon the second "ca65 only" example above.)
This is now maintained at GitHub:
https://github.com/bbbradsmith/NES-ca65-example/tree/fdsThe original version is still attached to this post below.
edit: examples updated to prevent accidental clearing of BIOS variables at $F9-$FF