MSXgl works fine on Linux now, at least.
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.
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.
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.
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.
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*
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.
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.
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.
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?