You could use my MSXhex tool to generate the ROM file from your IHX. It is SDCC friendly and is the only (to my knowledge) that support automatic mapped-ROM segment placement using SDCC format (it support SDCC's 32 bits address with the SSAAAA format).
Thanks, will look into it. I think most of my current issues come from SDCC’s makebin
tool, which is not really supporting the MSX.
Makebin is completely broken if you want to use an offset. And this has been known for some time now. ☹ https://sourceforge.net/p/sdcc/bugs/3411/
In Fusion-C it is used the command hex2bin to pass the ihx file (obtained by sdcc) to bin.
I've used it to get a com file to be run in MSX-DOS using Fusion-C as it is explained in this article.
I know that in Fusion-C there is a makefile to get a rom file, but I've never used it. Maybe you can read it to understand how it works. There is the windows version or the Linux/Mac
Yeah, like @pizzapower said, SDCC is insufficient to produce anything working for the MSX. It's funny that it has out-of-the-box support to closed platforms such as the GameBoy and the Master System, but not for an open standard like the MSX.
Also to be honest, when I look at these other linkers and MSX pages on the subject, I'm often overwhelmed by the seemingly lack of a "standard" CRT0 for an MSX ROM. There are simply too many options and they all look like "magic opcodes" to me. That's not very helpful to someone trying to understand how things actually work. Most of the information I find on the topic is shrouded in mystery and usually leads to dead ends.
SDCC is a project created by a community of volunteer developers. If the MSX part is less developed, it may simply be because there are no MSX programmers participating in the project. We can't blame them.
Also, the MSX is much richer than a game console like the Gameboy, and therefore also much more complex. To take the example of CRT0 for a ROM, there's nothing standard except the 16-bytes header. As for the rest, it all depends on the programmer's needs, so it's only logical that they should require specific code.
If you want a minimalist CRT0 here's :
MSXROM.s .ascii "AB" .dw _main .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000
This will work for a 16 KB cartridge on page 1.
And to get back to SDCC, even if it was no out-of-the-box support for MSX, it has led to the creation of C libraries (such as MSXgl or Fusion-C), which offer quite advanced functionalities. On the latest MSXdev, there are at least 5 games made with MSXgl and at least 1 made with Fusion-C. For that alone, I think we can be grateful to the SDCC team.
Anyway, if you need help getting started with C programming with SDCC, don't hesitate to ask your concrete questions here; you'll find people to help you.
Yeah, like @pizzapower said, SDCC is insufficient to produce anything working for the MSX.
Well, my (ROM, BIN, DOS) templates are pretty "turnkey" with a bunch of configurable options.
You download the application template, compile the example applications and tools needed (Python, SDCC and Hex2Bin. The documentation explains that step-by-step) with a single and simple command line ("python Make/make.py Debug clean all" is *ALL* you need) and run it straight away in emulators or real machines.
They integrate well with MS Visual Studio, but are pretty independent of it as well, if you want to work with other IDEs, Linux or Mac.
I'm often overwhelmed by the seemingly lack of a "standard" CRT0 for an MSX ROM. There are simply too many options and they all look like "magic opcodes" to me. That's not very helpful to someone trying to understand how things actually work. Most of the information I find on the topic is shrouded in mystery and usually leads to dead ends.
I tried to make the code as understandable as possible and modular, in order for the programmer to be able to identify and turn on and off features (which you can do in self-explicable text configuration files). Version 00.06.00 which is in the oven (I'm trying my best to release it today) is even more modular.
Also, all templates come with ready-to-compile example applications in C and ASM, and you can even choose to enable certain features from the C example or from the ASM example, interchangeably.
Moreover, I always try my best to support the developer, so fell free to contact me if you have any questions about the "magical opcodes" in CRT0 or in the examples.
If you're interested, check the project at https://github.com/DamnedAngel/MSX-Templates-for-VisualStudio. If everything goes well, I will deploy a new release of the templates later today (Nov 11th).
[]s
You download the application template, compile the example applications and tools needed (Python, SDCC and Hex2Bin. The documentation explains that step-by-step) with a single and simple command line ("python Make/make.py Debug clean all" is *ALL* you need) and run it straight away in emulators or real machines.
I meant "You download the application template and tools needed (Python, SDCC and Hex2Bin. The documentation explains that step-by-step), compile the example applications with a single and simple command line ("python Make/make.py Debug clean all" is *ALL* you need) and run it straight away in emulators or real machines."