[MSX-C] Q&A official thread

Page 60/68
53 | 54 | 55 | 56 | 57 | 58 | 59 | | 61 | 62 | 63 | 64 | 65

By Manuel

Ascended (19466)

Manuel's picture

15-01-2023, 13:11

MSXgl works fine on Linux now, at least.

By Grauw

Ascended (10768)

Grauw's picture

15-01-2023, 14:21

rolandve wrote:

Ascii C shouldn't be used for graphics. See code below and comment out the line where it says so. Then see the difference. Tested on openmsx 17, 18 and a NMS 8255.

I don’t know what the problem is exactly, but from the code I assume it is performance? In that case:

* Reading from file byte by byte is going to be slow. It’s much faster to read blocks into a larger buffer and then work on that.

* Similarly outputting byte by byte to the VRAM is going to be slow as well. It’s much faster to output bytes from a buffer in one go using ldirvm (I believe that exists in MSX-C?).

* Modulo is a very slow operation on Z80, as are multiplications and divisions. If the factor is a power of two you can use && (factor - 1) to the same effect, however if it’s modulo 3 you can’t do that.

* However, if you want to output every 3rd byte in a loop like this, rather than taking the modulo, you can increase a counter for every byte read, and if the counter is 3, output the byte and reset the counter to 0. This way it’s done with only simple integer operations instead of a costly modulo.

By rolandve

Champion (358)

rolandve's picture

15-01-2023, 19:31

It's not about performance.
The last code I posted, when compiled will give the screen 8 image 3 times in a row, but very small, unless you remove the line above. Then you will only get it 1 time like expected.A modulo operation should not have this strange result on a write operation to vram.

By rolandve

Champion (358)

rolandve's picture

15-01-2023, 20:17

Manuel wrote:

MSXgl works fine on Linux now, at least.

It's a library on SDCC 4.2. A few observations: dynamic memory allocation that I really need is not implemented in SDCC. They manage 1Kb of space for malloc() and that's it. Please rebuild the compiler module if you need more, but: I wouldn't need dynamic memory allocation if I knew how much I would need, that depends on the user. SDCC is a pig. My ascii sc8 viewer is 3 Kb, on SDCC, it's almost 10 Kb. A bug in fusion? void *MMalloc(unsigned integer). If it returns a pointer, it's not void, because void means: ignore, no value. Both Fusion and MSXgl inherit the limitations of the compiler they are building on.

By aoineko

Paladin (1002)

aoineko's picture

15-01-2023, 21:27

MSXgl use a custom library wrote from scratch for MSX (not the SDCC lib). SDCC is only used as a C compiler and linker. Since SDCC 4.1.12 and the new calling convention, I think the compiler generate quite good and optimized code (even it still room for improvements).
If MSX-C fulfill your needs, go for it.

By PingPong

Enlighted (4137)

PingPong's picture

15-01-2023, 21:49

rolandve wrote:

void *MMalloc(unsigned integer). If it returns a pointer, it's not void, because void means: ignore, no value.

you need to learn C. void *MMalloc means THAT IT WILL RETURN A POINTER. A pointer to data whose size is 'unknown', but actually a pointer like a char* o int*

By rolandve

Champion (358)

rolandve's picture

16-01-2023, 09:40

PingPong wrote:
rolandve wrote:

void *MMalloc(unsigned integer). If it returns a pointer, it's not void, because void means: ignore, no value.

you need to learn C. void *MMalloc means THAT IT WILL RETURN A POINTER. A pointer to data whose size is 'unknown', but actually a pointer like a char* o int*

Interesting: every result on the internet about void functions says "void return types do not return a value when the function is executed." But then, the ANSI standard allows void * to function as a catch all for generic pointers. So its a pointer to something, type unknown, size unknown. Educational.

By rolandve

Champion (358)

rolandve's picture

16-01-2023, 09:44

aoineko wrote:

MSXgl use a custom library wrote from scratch for MSX (not the SDCC lib). SDCC is only used as a C compiler and linker. Since SDCC 4.1.12 and the new calling convention, I think the compiler generate quite good and optimized code (even it still room for improvements).
If MSX-C fulfill your needs, go for it.

Looks good! I also like the build strategy. Specify what you want like rom, .com file etc.

By pizzapower

Master (165)

pizzapower's picture

16-01-2023, 13:33

rolandve wrote:

Interesting: every result on the internet about void functions says "void return types do not return a value when the function is executed." But then, the ANSI standard allows void * to function as a catch all for generic pointers. So its a pointer to something, type unknown, size unknown. Educational.

Don't overlook the *, which is part of the type declaration. void return type is completely different from void* return type. All C language standards from K&R to C11 use the same syntax for the generic pointer type.

By rolandve

Champion (358)

rolandve's picture

18-01-2023, 20:41

I ironed out the bug in my image resize program. I couldn't let it go and I also couldn't believe the compiler was that bad. So I found the bug. Now a "simple" question, as I am trying to learn how to talk to the VDP. Ascii C has the rdvdp and wrvdp functions. Looking at konamiman's documentation I find descriptions of write what, to which register. Based on these manuals I run in to some strange errors:

/* this gives a black screen & hangs the machine */
/* assumption: konamiman's blocks in the bits mean: leave the value of other bits as is. */
 wrtvdp((TINY)0,(rdvdp((TINY)0) ^ 14)); /* bits 1,2,3 set to 1 */
 wrtvdp((TINY)1,(rdvdp((TINY)1) && 231)); /*bits 3 and 4 set to 0 */

/* this doesn't work either */
VOID setscr8()
{
    direct to VDP
    di();
    outp(0x99,(TINY)14); /* screen 8 Graphic 7 */
    outp(0x99,(TINY)128); /* 14 to register 0, bit 7 == 1 */
    outp(0x99,(TINY)0);
    outp(0x99,(TINY)129); /* 0 to register 1, bit 7 == 1 */
    ei();

  /* screen is green */

/* this code loads a screen 12 YJK file but its also green */
    screen((TINY)8);
    outp(0x99,(TINY)8);
    outp(0x99,(TINY)128+25); /* screen 12 image loads but its all green*/

}

Anyone have a snippet where the system goes to screen 12 and back without letting everything turn green?

Page 60/68
53 | 54 | 55 | 56 | 57 | 58 | 59 | | 61 | 62 | 63 | 64 | 65