Thanks everybody for your suggestions, I'll start with standar Ascii compiler since I've it allready instaled.
I feel a bit guilty about advertising my own stuff, but you can start with the MSX-C tutorials I've been writing:
I haven't been writing for a while, but there are 18 chapters. That will be enough to keep you busy until I continue posting new chapters (soon).
Good way to start, I'll read this chapters first, thanks ;)
Time to recover the thread :)
Good luck AxelStone.
Please keep us informed about your progress, difficulties etc...
Sure, I'm very insistent when I start with something, so once I have started you'll see me here often. About difficulties, I suggest to all basic programmers try a structured language (C/Pascal). They are not difficult to learn and provides a much more readable code. You'll be glad with the change ;) . In Javi's blog you can see difference between codes C vs Basic:
AS you can see C code is much more clear and you can add as many comments as you want.
I feel a bit guilty about advertising my own stuff, but you can start with the MSX-C tutorials I've been writing:
I haven't been writing for a while, but there are 18 chapters. That will be enough to keep you busy until I continue posting new chapters (soon).
Good tutorial. The TED editor could be added to environment. The MSX-C Library of MSX-C is a huge advantage over other C compilers, if you plan to develop software for MSX. Can other compilers use the MSX-C Library?
If you could translate those MSX-C manuals it would be great!
About C, any old C manual is valid to learn. What we need to know are the MSX-C specifics, like parameters, compilation options, etc. Because this, those MSX-C manuals translations have a great value.
The MSX-C Library of MSX-C is a huge advantage over other C compilers, if you plan to develop software for MSX. Can other compilers use the MSX-C Library?
It comes with full source code in C and assembler, so I don't see a reason why it shouldn't be usable, other than you would have to update at the very least the C part to comply with other compilers.
About C, any old C manual is valid to learn. What we need to know are the MSX-C specifics, like parameters, compilation options, etc. Because this, those MSX-C manuals translations have a great value.
The tutorials I wrote already describe the parameters and compilation options for the three commands that compose MSX-C's toolchain: parser (CF.COM), function parameter checker (FPC.COM) and code generator (CG.COM).
In MSX-C manuals are included the directives?, like the #pragma OPTIMIZE SPEED in other compilers.
Also, the memory management is not some specific on MSX?, particulary if not using MSX-DOS2. The slots, pages, 16KB blocks, memory mappers.
Found something that can help:
http://www.fvue.nl/wiki/MSX-C_manual#Tips_.26_Tricks
But yet we need more info for when using more than 64KB. Like changing the 16KB blocks to store more data in the same place. Is malloc aware of it?. Or placing some code in a specific location (for page purposes). Also, how can C call the BIOS, if TPA is using the page 0? What about interrupts if there is no BIOS enabled in page 0?
A bit confusing oO
The MSX-C Library of MSX-C is a huge advantage over other C compilers, if you plan to develop software for MSX. Can other compilers use the MSX-C Library?
It comes with full source code in C and assembler, so I don't see a reason why it shouldn't be usable, other than you would have to update at the very least the C part to comply with other compilers.
So you could compile them to use in other compilers. However I prefer to use native ASCII C as you described in your tutorial. About MSX-C manuals, is there any way to get translated versions of MSX-C manuals from ASCII? We can learn standar C with standar manuals, but not peculiaritys of MSX (memory management, specific libs, etc).
Thanks.
In MSX-C manuals are included the directives?, like the #pragma OPTIMIZE SPEED in other compilers.
Yes, the MSX-C V1.20 manual describes the compiler directives in pages 40-46:
#pragma nonrec #pragma recursive #pragma pdp11mode #pragma regalo #pragma nonregalo #pragma optimize time #pragma optimize space
Also, the memory management is not some specific on MSX?, particulary if not using MSX-DOS2. The slots, pages, 16KB blocks, memory mappers.[...] But yet we need more info for when using more than 64KB. Like changing the 16KB blocks to store more data in the same place. Is malloc aware of it?
Section 4.3.3 of the MSX-C V1.20 manual explains memory management. MSX-C V1.20's alloc() function call only handles the 64KB mapped by MSX-DOS(2) to the CPU. You can still manage all available memory using normal page switching (under MSX-DOS) or the memory segment management functions (under MSX-DOS2). You'll probably need to write some assembler code for this.
Also, how can C call the BIOS, if TPA is using the page 0?
Using the bdos(), bdosh(), bios(), call() and callxx() function calls. Described in the MSX-C V1.20 manual, pages 127-131.
What about interrupts if there is no BIOS enabled in page 0?
Interrupts work in exactly the same way as under MSX-DOS. Section 5 of the manual explains how to write C programs to run under MSX-BASIC (pages 107-115), and how to write software to run from a cartridge (pages 115-121).
So you could compile them to use in other compilers.
In theory you could. In practice it's going to be much more complex than that. I see a couple problems:
- The MSX-C Library code is written in K&R C. Most modern compilers will require a newer dialect, so the code would have to be rewritten.
- The assembler files of the library are full of hacks:
If someone is interested in porting these for use with a different compiler, then I think it would be more practical to rewrite the library while looking at the MSX-C Library code. After all, there are just three files: GLIB.MAC (38KB), MATHMAC.MAC (32KB) and MSXBIOS.MAC (15KB). These files are relatively big, but they mostly contain lots of very simple functions that shouldn't be difficult to reimplement while looking at the original.
About MSX-C manuals, is there any way to get translated versions of MSX-C manuals from ASCII?
ASCII never produced English versions of these manuals. If there was an English version then I wouldn't be writing tutorials nor translating anything. I would just tell people to go RTFM. :-)
The MSX-C compiler was actually developed by LSI Japan. MSX-C V1.00 was LSI's CP/M compiler, using the standard M80/L80 assembler and linker by Microsoft in their CP/M-80 versions. MSX-C V1.10 was customized for MSX-DOS with MSX specific of M80/L80, and MSX-C V1.20 was improved with MSX-DOS2 support and newer M80/L80 tools.
By the way, Mr. Koichiro Mori (the author of LSI-C 80 and MSX-C) passed away in January this year.
ASCII never produced English versions of these manuals. If there was an English version then I wouldn't be writing tutorials nor translating anything. I would just tell people to go RTFM. :-)
Sorry to ear that. Really good luck with the translation!!
By the way, Mr. Koichiro Mori (the author of LSI-C 80 and MSX-C) passed away in January this year.
Sorry to ear that too, R.I.P.
One thing I would like to know before eventually starting learnin MSX-C...
One of y friend is Making Colecovision Games, ans he is using SDCC.
He port two of his game on MSX (It was PANG and Bomb 'n Blast), this are 32K Rom.
I encourage him to do better versions for MSX, using more ROM space. But he was unable to handle more than 32K with SDCC. Neither, He doesn't find good way to make a Floppy version, loading graphics from a floppy.
Perhaps it 's because of his own limitation about MSX understanding, or SDCC limitation... ?
But, how is it easy (or not) making 64K ROM or MegaRom when programing with MSX-C ?
How is it easy (or not) making floppy disk games (loading files) ? with or without MSX-DOS ?
It would be great to have translated first the specific parts of the manual then. Because for C itself any other manual can be used.
You can still manage all available memory using normal page switching (under MSX-DOS) or the memory segment management functions (under MSX-DOS2). You'll probably need to write some assembler code for this.
There is a way to put some part of code, and data (variables, arrays, probably not using malloc but I don't care) in a specific address like in ASM? For using pages or mappers manually is required to select the 16KB block and not split the data nor broke the code at switch. I guess so because C can make ROM.