I want to learn MSX-C, where do I start? | MSX Resource Center (Page 5/12)

Prophet (2927)

21-08-2015, 17:50

How about this compatible way of adding asm:

char codearr[] = { 0xCD, 0x0, 0x0, 0xC9 };

Write a C app for the PC to turn sjasm output to this format

The deal is that someone in the forum can tell you in 5 minutes the hand full of instructions how to do something,
but has not the slightest ides of your Cs inline asm parameter passing whatever.

I hope the compilers got STDCALL. That put the bytes on the stack and not registers.
Now how to make the function declaration

if the function is int add(int a, int b);
(STDCALL int*)add(int a,int b);
add = (void*)codearr[0];

I'm not sure the example works, maybe needs some fix.

Once one got that one running,
one again got a "do all on all compilers" thing.

Par anonymous

incognito ergo sum (116)

21-08-2015, 18:23

hit9918 wrote:

so the first thing an MSX C should have is to make the z80 available:

void di();
void ei();
void halt();

Well, I disagree that these are the first things MSX-C should handle, but it does support di() and ei(). These are part of the MSX-C Library package. halt() is trivial to implement.

hit9918 wrote:

void out(char port, char n);
char in(char port);

These come with the standard MSX-C library: inp() and outp().

hit9918 wrote:

void* otir(char port, unsigned char count, void *p); /*returnvalue must be the slided pointer*/
void* otir29(char port, unsigned char count, void *p); /*for MSX1 VDP , 29 cycles*/
void* inir(char port, unsigned char count, void *p);
void* inir29(char port, unsigned char count, void *p);

MSX-C does better than this. The MSX-C Library package comes with lots of graphics-related functions: ginit(), interlace(), setrd(), invdp(), outvdp(), vpeek(), vpoke(), filvrm(), ldirmv(), ldirvm(), wrtvdp(), rdvdp(), rdvsts(), color(), iniplt(), rstplt(), getplt(), setplt(), pset(), line(), boxline(), boxfill(), circle(), paint(), point(), inispr(), calpat(), calatr(), sprite(), colspr(), putspr(), cpyv2v(), cpyv2m(), cpym2v(), totext(), grpprt(), knjprt(), glocate(), setpg(), vramsize().

I'm not going to write a description of all of these in this post. The names will give you a clue of what they do. You'll recognize some VDP hardware commands in there.

hit9918 wrote:

when JaviLM has sprites based on vpoke(), when you got an out() then in 5 minutes you can get his vpoke. 
"his" vpoke:
the exact function signature of vpoke() is not so clear, 
e.g. how to handle the 128k vram vpoke on a 16bit 64k C.
things get easy when it is based on a compatible out().

Sorry, I can understand what you mean. I don't mean any offense, but are you using an online translator? Your English is very difficult to understand.

Par anonymous

incognito ergo sum (116)

21-08-2015, 18:25

hit9918 wrote:

I hope the compilers got STDCALL. That put the bytes on the stack and not registers.
Now how to make the function declaration

if the function is int add(int a, int b);
(STDCALL int*)add(int a,int b);
add = (void*)codearr[0];

I'm not sure the example works, maybe needs some fix.

Once one got that one running,
one again got a "do all on all compilers" thing.

Sorry, I don't understand what you mean.

Par tvalenca

Paladin (747)

21-08-2015, 20:54

JaviLM wrote:

hit9918 wrote:

void* otir(char port, unsigned char count, void *p); /*returnvalue must be the slided pointer*/
void* otir29(char port, unsigned char count, void *p); /*for MSX1 VDP , 29 cycles*/
void* inir(char port, unsigned char count, void *p);
void* inir29(char port, unsigned char count, void *p);

MSX-C does better than this. The MSX-C Library package comes with lots of graphics-related functions: ginit(), interlace(), setrd(), invdp(), outvdp(), vpeek(), vpoke(), filvrm(), ldirmv(), ldirvm(), wrtvdp(), rdvdp(), rdvsts(), color(), iniplt(), rstplt(), getplt(), setplt(), pset(), line(), boxline(), boxfill(), circle(), paint(), point(), inispr(), calpat(), calatr(), sprite(), colspr(), putspr(), cpyv2v(), cpyv2m(), cpym2v(), totext(), grpprt(), knjprt(), glocate(), setpg(), vramsize().

I'm not going to write a description of all of these in this post. The names will give you a clue of what they do. You'll recognize some VDP hardware commands in there.

Do any of these use BIOS CALLs or translates directly to its ASM correlations? Do VDP functions read from 0x0006 and 0x0007 the VDP ports or you have to code it anywhere in your source code?

Par hit9918

Prophet (2927)

22-08-2015, 01:40

ok I made an SDCC ROM for starters.
It shows what I meant.
The entire show is based on only a hand full of trivial functions a la di() out().
You can see how the blit() function in the end does otir() to the command engine.
When you want a putspr() like MSX C library, take its function signature and then write it.
If you ask in the forum, many have an idea how to make it.
It works without having a beginners book for MSX C.
About the actual C itself, there is a lot content.

https://sites.google.com/site/tueftlerlabs/home/downloads/de...

Par anonymous

incognito ergo sum (116)

22-08-2015, 04:32

tvalenca wrote:

Do any of these use BIOS CALLs or translates directly to its ASM correlations? Do VDP functions read from 0x0006 and 0x0007 the VDP ports or you have to code it anywhere in your source code?

You can look at the MSX-C Library source code yourself. All of these functions are implemented in assembly language. A couple of actual examples from GLIB.MAC:

ginit() - This should answer your question about the library reading from 0006h and 0007h:

EXPTBL  equ 0FCC1h
;
GINIT@::
    ld  hl,6
    ld  a,(EXPTBL)
    call    000Ch
    ei          ;*** make sure interrupts are enabled
    ld  (VDPIO@),a
    ret

    dseg
VDPIO@::    defb    98h ; This initial value is for ill-behaviored
                ; programs
    cseg

interlace():

WRTVDP  equ 0047h
RG9SAV  equ 0FFE8h
;
INTERLACE@::
    rrca                ; make IL, EO
    jr  nc,intlac_1
    or  10b
intlac_1:
    and 11b
    add a,a
    add a,a
    ld  b,a
    ld  a,(RG9SAV)
    and 11110011b
    or  b
    ld  b,a
    ld  c,9
    ld  ix,WRTVDP
    jp  _CALBIO##

ldirmv():

;   LDIRMV  moves block from VRAM to memory.
;
    extrn   SETRD@
;
LDIRMV@::
    push    bc      ; save length
    ex  de,hl       ; HL = pointer to source
    call    SETRD@
    ex  de,hl       ; HL = pointer to destination
    pop de      ; DE = length
                ; C  = VDPIO@
    ld  b,e     ; set lower byte of length
    ld  a,d     ; set higher byte of length
    inc e       ; is lower byte of length 0?
    dec e
    jr  z,ldirmv_1  ; yes
    inc a
ldirmv_1:
    ini         ; INIR cannot be used (VDP may fail)
    jp  nz,ldirmv_1
    dec a
    jp  nz,ldirmv_1
    ret

Looks pretty well done to me.

Par hit9918

Prophet (2927)

22-08-2015, 05:03

"STDCALL", I wanted to put code into arrays to get an inline asm that works on every compiler.
Then the compiler needs a mode where it puts function parameters not in registers but on the stack.
It should only do it with functions where one declares it with a keyword like STDCALL.

Strictly speaking one would have to use the old function declaration to run on all compilers,
now I tried it on SDCC and

app.c:16: error 7: Old style C declaration. IGNORED 'otir64'

sigh.

Par hit9918

Prophet (2927)

22-08-2015, 05:12

about ldirvm(), when one got otir() then one got the same,
except that it works on all devices and not only on the VDP.
and for little chunks it is better that it doesnt dictate a vram address setup every time.

Par hit9918

Prophet (2927)

22-08-2015, 05:23

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?

Par DarkSchneider

Paladin (981)

22-08-2015, 11:56

If you plan to develop for MSX (and using its VDP commands is indicative) use MSX-C + Library using its syntax and it's done. Why reinventing the wheel?. If not you are going to spend more time with "how to do/solve" than coding usefully the application itself.

If you want a cross-development (multi-platform purposes), then I understand your worries.

Anyway, I think 8-bit (old machines) codes are not so vast to worry about rewrite from the original to other platforms.