Retro Teachie, I think I can't. When I click on compile button in chaos assembler it automatically generate the bin file. I looked for a way to change file type, but I haven't found it
Name of destination file can be set as describe in the manual page 26~27.
https://ja.scribd.com/document/352013986/Chaos-Assembler-Man...
I know, but you can only choose .bin or .dat file extension. So I simply asked (I think it's a clear question) if a rom file is a bin file with simply changed extension (with the right header of course). Is it so difficult to have a clear answer about a clear question? yes or no. So I can decide to change assembler, choosing one that compile --> .rom file or continuing use chaos assembler and simply rename the bin file obtained as a rom file (I know about different header, I know I misunderstood before and wrote $AB instead of "AB")
As long as Chaos Assembler spits out a file with the .BIN extension but internally it only has the usual ROM headers and is sized exactly to 16kB, you're good to go. I think a bit of the confusion comes from the fact that both ROM and BIN refer to binary files. And what really matters is what's inside.
Binary files intended for direct loading from BASIC have usually the BIN file extension and those 7 header bytes. Everything that follows will be loaded from the memory position specified on the second and third bytes of the header, as described here.
ROM files originally used by emulators (and nowadays quite commonly by various MSX loaders) are a different beast. They are supposed to be a 1:1 direct copy of binary data, so to work on MSX they are subject to a few MSX-related rules, as previously described py @tvalenca. For example, a 16kB cartridge, to work on MSX, must have a 16 byte header. This header isn't "loaded" by the MSX; instead, every byte is directly mapped to the Z80 address space. When you turn of the MSX, the slot search routine uses this header to identify the type of cartridge and to start the program inside it, if necessary. So if you dump this memory region you'll see the header itself.
Conversely, if you want to make a cartridge-based program, you must add this header at the beginning of the program. Even if you never burn this binary data to a real ROM cartridge, you'll need the data to inform your preferred ROM loader program. An interesting side effect is that it's really simple to convert a 16kB ROM file into an equivalent BIN file: you just prepend the relevant BIN header.
Ok, thx. This is what I wanted to know
Throw away chaos assembler... I will use Glass from now on. I couldn't create a proper rom file cause ds directive wasn't in CA (but when I wrote code and compiled seemed to works, in the list file either). Then I tried with fill directive. Same result and fill caused asm file to be empty too! Now I realize that CA is pretty bugged (also it does strange things with explorer.exe, sometimes with its close and resize buttons and/or not properly showing modified files). So... Glass is the assembler I will use from now (finally I've created a working rom file but obviously bug filled I'll fix it ASAP). Now I'll can include bin files and throw away all those db rows created by copy _and_paste from a hex editor)
Good news! I like Glass, I find it easy to use and it has a lot of useful features.
I liked CA 'cause it has inbuild editor and easy compiling by just one click. But it is really too buggy... So from now on... New assembler, new life
I also use Glass. For me, the big pluses of Glass are:
1) The developer (@grauw) is in these forums, so, he's super easy to reach!
2) It's cross platform and works from the command line, so, I can add it to my automated build scripts
I have even used it for one non-MSX project (for Amstrad CPC), and it worked perfectly there too!
Yep, and Grauw is a great coder and great helper too ok, next post will be my scrolling routine in a ROM file. I have to fix a lot of bugs so I have to read my code again and again until I discover where I exactly made those mistakes