[MSX-C] Q&A official thread

Really a good work!!. Finally it seems that the function to use were callxx, allways at address 0x0005 (BDOS) as I can see, and the operation is contained in C register. It was not trivial to discover it, thanks for the source code

Correct. Which function you use depends on the parameters that you need to pass to the function you're calling:

When calling MSX-DOS(2) functions that require no arguments, or that take arguments only in DE and/or HL:

bdos(function[, de, hl]): Use when the MSX-DOS(2) call returns an 8-bit value in A (or when it doesn't return a value at all)
bdosh(function[, de, hl]): Use when the MSX-DOS(2) call returns a 16-bit value in HL

bdos()/bdosh() can be called with one, two, or three arguments: bdos(function), bdos(function, de), bdos(function, de, hl).

When calling routines at arbitrary addresses that take arguments in A, HL, BC, DE:

calla(address, a, hl, bc, de): Use when the routine at address returns an 8-bit value in A.
call(address, a, hl, bc, de): Use when the routine at address returns a 16-bit value in HL.

In this case all the arguments are required, so if the routine you're calling doesn't use any of them, just pass a dummy value.

When calling routines at arbitrary addresses that take arguments in any register:

Create a struct of type XREG, fill the values of the registers there, and call callxx() with the address of the routine and the address of the XREG struct:

callxx(function, pointer to XREG struct)

Also, if you want to be really fancy:

Calling assembler routines INLINE from MSX-C:

If you understand how MSX-C passes parameters to assembler routines (see this article), then you can just put all the parameters inline in your C program:

(*(VOID (*)())(0x0005))((TINY)0, 'x', (TINY)0x02);

The code above means call the function located at address 0005h, that returns a VOID, with parameters 0, 'x' and 002h. 0 is passed in register A (this is a dummy argument), 'x' is passed in register E, and 02h (_CONOUT) is passed in register C. This is the same as doing bdos(_CONOUT, (unsigned)'x').

I still can't see in what cases this last format will be useful, but maybe at some point it will be useful to put it in a macro or something.

In a VSYNCed game, you’ll need to anyway, because you can not exceed the 16.7 ms budget per frame (at 60 fps). The game engine must run synchronously to the VDP, so it must wait. If your game engine does not reliably stay under the budget, even if you would be able to snoop off some left-over time from the last frame, it would be difficult to guarantee a smooth scroll and gameplay.

Of course there are scenarios where one would want to independently process (part of) the game logic asynchronously on a separate thread, e.g. in the case of a chess game or perhaps even an RTS or something, where processing a full step of the game state may take much more than 16.7 ms… In such a case you could run the visual part of the engine synced off the interrupt and use the remaining time in the main loop outside the interrupt to run the game logic. However this introduces a lot of complexity to the architecture, visuals and logic need to be strictly separated and the logic state must allow multithreaded access (very difficult topic), etc.

As this does not apply to a typical game, a fully synchronous engine is preferable, to keep the game engine design simple.

I think @JaviLM means more an "elegant" solution rather than sync or performance issues. This is, CPU doing NOPs rather than read-RAM and the interrupt doing the work.

The solution could be a simple HALT. In ASM are 3 instructions, a simple function without parameters:

EI
HALT
RET

EI to be sure the HALT is working.

Then, to use it in that way:

loop {
jiffies = 0;
... // game logic
halt(); // optional, see below
while(jiffies < FRAMERATE) {
   halt(); }
... // fast drawing instructions, like switch page, copy SAT to VRAM, etc.
}

Set FRAMERATE to 1, 2, etc. for sync the game to 60, 30, 20 fps...
The "optional" halt() is because we have 2 cases:
- If set, we always have a synchronized drawing, but at cost of possible performance loss.
- If missing, we draw the next frame "as is" (probably incomplete) if we exceed the desired FRAMERATE in the game logic. See that in this case we do not run halt() because we don't enter inside the while(), and execute the drawing instructions at that point, not coinciding with the interrupt exactly.

I disagree. Yes, working with JIFFY is fine in most cases, but there are cases when you want to use HALTs. As you said, line interrupts is one of these cases.

Anything that works in overscan mode will depend on a couple of line interrupts, so these programs will need a nice HALT loop. As an example, this is the main loop of the scroll routine I wrote (yes, it runs in overscan), and it uses only line interrupts to control precisely when things happen:

; *************************
; ** PROGRAM STARTS HERE **
; *************************

start:		di
		ld	(oldstack),sp

		call	graphic3
		call	freezesys

		call	init

		; color ,,0
		xor	a
		ld	(vdpregs0+7),a
		vdp	7

		; clear pending interrupts
		rdvdp	1

		ei

loop:		halt
		jr	loop

So, while checking JIFFY will be fine in most cases, I can't agree with you regarding staying away from halts. ;-)