Hi Eric, you are right, SDCC is a powerful cross compiler, however it has a serious problem: its lack of libraries. I decided to use MSX-C basically because it has the best set of libraries, the official ASCII MSX-C libs for handle basically all aspects of MSX. There is a way to get a "more or less" confortable MSX dev environment using MSX-C: OpenMSX + folder as disk.
1.- Follow steps of http://www.lavandeira.net/relearning-msx/ to setup your environment.
2.- Using OpenMSX, use feature "folder as disk". In that folder you edit your sources using a modern editor like Notepad++.
3.- Compile it using OpenMSX throtle function (F9) to speed up compilation.
It's not perfect since PC compilation with SDCC will be faster, but you have a lot of libraries available. I hope that in a near future SDCC will have as many libraries as MSX-C :(
This ^^
I used a folder that I shared from a mounted image file so I could realtime test on a real MSX using the Nowind after compilation.
I suggest @ericb59 give a try to MSX-C since you have graphic libraries instead of creating your own. Let us know if you have any question using these libs
the point is that you can make your own gfx commands in C. without needing asm.
and a lot folks know help about how to code the VDP.
It seems that the lack of gfx routines is a big showstopper.
on msx to interact with video is a matter of three simple routines, that one can easily make in c or in-line assembly.
1) write a vdp register
2) set vram ptr for read or write
3) write or read from data port
With those in place you can manage the entire gfx.
Lines are done by vdp itself, memory copy the same and some operations that move data between vdp / cpu are also easy to implement. From a graphic point of view there is a missing routine. the ellipse/circle one... but the breseham algo is easy to implement in 'c' and a good exercise to begin to work with sdcc...
so do not having a gfx graphic library is not itself a big problem.
AT LEAST, as hit9918 mentioned, one can do all in 'c'. SDCC has sfx port extensions that are translated in machine code in a reasonable efficient way....
Retrodeluxe engine routines contained on vdp.c file are not correctly implemented:
vdp_poke contains an add a,#0x40. better should be "or a, #0x40". Plus on the end there is a double ei instruction that is not needed.
vdp_poke_di contains an add a,#0x40. better should be or 0x40.
vdp_peek should NOT contain an add a, #0x40 instruction instead something like and a, 0x3f to ensure a read access.
Retrodeluxe engine routines contained on vdp.c file are not correctly implemented:
vdp_poke contains an add a,#0x40. better should be "or a, #0x40". Plus on the end there is a double ei instruction that is not needed.
vdp_poke_di contains an add a,#0x40. better should be or 0x40.
vdp_peek should NOT contain an add a, #0x40 instruction instead something like and a, 0x3f to ensure a read access.
This engine, based on sdcc by what I see, therefore follows the same guidelines as msx-c? Or point more to a more advanced c?
Retrodeluxe engine routines contained on vdp.c file are not correctly implemented:
vdp_poke contains an add a,#0x40. better should be "or a, #0x40". Plus on the end there is a double ei instruction that is not needed.
vdp_poke_di contains an add a,#0x40. better should be or 0x40.
vdp_peek should NOT contain an add a, #0x40 instruction instead something like and a, 0x3f to ensure a read access.
This engine, based on sdcc by what I see, therefore follows the same guidelines as msx-c? Or point more to a more advanced c?
It is not a question of more advanced 'c' rather than the proper way to interact with hw.
SDCC is a ansi 'c' implementation.
msx-c not
