I want to learn MSX-C, where do I start?

Page 6/12
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

By hit9918

Prophet (2904)

hit9918's picture

23-08-2015, 01:05

look at this, say I got a

struct sprite { char Y; char X; char P; char C } spr;

this is the BASIC way

putsprite(i, spr.X , spr.Y, spr.C, spr.P);

and this is the C way

otir(VDPport, 4, spr);

Instead all the Y X P C getting shoveled forth and back on the parameter passing stack,
the z80 otir instuction copies these 4 bytes directly from RAM to the VDP port.
and it goes without vram address setup because it goes in a loop for sprites.

"why reinvent the wheel",
without having a library with putsprite, it was magicaly created out of nothing with otir() Smile

By AxelStone

Prophet (3020)

AxelStone's picture

23-08-2015, 11:44

@hit9918 I think that you are not understanding the philosophy behind the use of a compiled language. Libraries is one of its best feature against not structured languages as Basic or even ASM. They have 2 big advantages:

  1. Designed once, used by everyone. They are suppossed to be well tested libraries, so you are using a good solution for your needs.
  2. Code readable. Since everyone uses the same functions, is really easy to read examples since it uses everyone codes in a similar way.

The idea of "make for yourself" is applicable to ASM, but in structured languages as C the idea is the opposite: never reinvent the wheel unless absolutely necessary. Wink

By DarkSchneider

Paladin (941)

DarkSchneider's picture

23-08-2015, 12:56

@hit9918 that so direct access to hardware should be avoided in MSX when possible, its open architecture design is more oriented to use its API included in the BIOS, instead the Z80 and ports so directly.

Better than otir(), you could use i.e. a fixed-size zone in RAM equal to the SAT (Sprite Attr Table), and then use LDIRVM (BIOS function) to copy it to VRAM all-at-once. Working on RAM is much faster for CPU than writing small amounts of data to VRAM many times, and then write to VRAM all at once. I have tested LDIRVM and is pretty fast. Doing this also avoid undesirable effects for has no time between updating sprites and the VDP interruption. Do the LDIRVM at interruption so all sprites are updated at time.

MSX-C Library has a msx_bios() that I am sure is for using the MSX-BIOS functions in global beyond the translated ones in the library itself.

By hit9918

Prophet (2904)

hit9918's picture

23-08-2015, 20:13

Quote:

@hit9918 that so direct access to hardware should be avoided in MSX when possible, its open architecture design is more oriented to use its API included in the BIOS, instead the Z80 and ports so directly.

Quote:

@hit9918 I think that you are not understanding the philosophy behind the use of a compiled language.

Dear AxelStone and Darkschneider, very good, I too speak more freely Smile
All the concerns you bring up, they are not true.

"structured", the otir() was using a struct, the putsprite() did not, an irony.
"open architecture", the otir() to the VDP port of peek(6) is standard,
and if it werent, then the MSX would have NO GAMES.
I did not suggest to OUT to the floppy controller, but with the VDP it goes fast and elegant.

The question is whether we are actualy having a technical argument.
Are there more urgent showstoppers that prevent making a game or kill motivation?

By hit9918

Prophet (2904)

hit9918's picture

23-08-2015, 20:53

Quote:

Better than otir(), you could use i.e. a fixed-size zone in RAM equal to the SAT (Sprite Attr Table), and then use LDIRVM (BIOS function) to copy it to VRAM all-at-once. Working on RAM is much faster for CPU than writing small amounts of data to VRAM many times, and then write to VRAM all at once

Let me mention that you did throw away putsprite(), the thing I am always talking about Wink
Who actualy has which position, confusion Smile

The otir() requires that you get the VDP port from the bios variable. Then it is the same compatibility as LDIRVM.

The MSX C code of LDIRVM that was posted, it has exactly the 29 cycles loop as the otir29() I posted, that is the slower loop for MSX1.
But the MSX2 can go in 18 cycles with otir().

By hit9918

Prophet (2904)

hit9918's picture

23-08-2015, 21:01

p.s.
otir() vs ldirvm() is rather details, while ldirvm() versus putsprite() is a paradigm shift.
There is something that does not look like a BASIC function,
and once one has understood that, things get not complicated but MORE EASY. Empowerment, elegance.
That is what I am trying to hint about.

By AxelStone

Prophet (3020)

AxelStone's picture

23-08-2015, 21:40

@hit9918 Well you can develop in the way you feel more confortable, there is no doubt about this. I simply suggest that if you are going to use MSX-C the idea is to use the provided libraries instead of making news. You talk about kill motivation, but I think that all of these libraries allows you to focus in game development itself instead of making libs for everything by yourself.

You allready have functions to copy ram<->vram, putsprites, handle memory, initgraphics...Thats good, you can focus on game logical instead in thecnical issues. I'm not going to discuss if putsprite could be made in less cycles, I'll simply use it Wink

Obviously if there is a growing comunity around MSX-C, it'll be very possible that to people make revised versions of existing libraries in order to improve them, or even add not existing libs as moonsound support.

By ARTRAG

Enlighted (6515)

ARTRAG's picture

23-08-2015, 23:25

The main reason to use msx-C instead of hitech-c or sdcc is its library
It could even very interesting to find a way to reuse such libs in other compilers

By AxelStone

Prophet (3020)

AxelStone's picture

23-08-2015, 23:39

ARTRAG wrote:

The main reason to use msx-C instead of hitech-c or sdcc is its library
It could even very interesting to find a way to reuse such libs in other compilers

I think it's a definitive advantage, MSX-C library is very impressive, it's implemented basically all needed functions. As you say, it should be great to get all these libs compiled for other enviroments as sdcc or hitech-c. By the moment, we can use them in MSX-C Wink

By anonymous

incognito ergo sum (116)

anonymous's picture

24-08-2015, 01:35

hit9918 wrote:

I just read somewhere that "Old-style function declarations should be converted to prototype form".
Was the function prototype syntax the same in the old style?

void wrtvdp(char port, char n);

Does that work on cp/m compilers?

There are plenty of CP/M compilers, and some of them use different versions of the C language, some of them don't completely implement it, etc. You'll have to be more especific. The fact of running on CP/M, MSX-DOS or other operating system doesn't relate to what level of C the compiler supports.

The line above won't work on MSX-C V1.0 (CP/M), MSX-C V1.1 (MSX-DOS) nor MSX-C V1.2 (MSX-DOS2). It will work on HITECH-C and others.

Page 6/12
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11