Karoshi MSX Community

Buenas,

Pues estoy tonteando con el SDCC (compilador de C/Z80 para PC) y a la hora de pulir una librería para desarrollo sobre MSX que me estoy montando, me surge una duda...

¿Que comandos, instrucciones o funcionalidad en general debería poseer una librería a la hora de dar soporte a desarrolladores de juegos (principalmente)?. Para muchas cosas estoy tomando como modelo GFXlib, que viene a ser igual; pero para Hitech-C, que es nativo de MSX. Mi intención es soportar, sobre todo, gráficos (MSX1 y MSX2), sonido (PSG) y características específicas de los MSX.

Por supuesto todo ello en C, que aunque es la alternativa más próxima a CM, ya sabemos que no es comparable. Valga como ejemplo las rutinas 3D de GFXlib, que aunque están majas su uso no es viable ya que son muuuuy lentas. :(

A ver que se os ocurre...

Werks, yo de "C" ni flowers... Robsy, tu sabes más de esto así que te dejo la guitarra, si es que andas por ahí!!!

"Le llaman el desaparecidooooo!". Rooobys, ¿no te habrán secuestrado los de Aiky, no?  2gf:)

No, si ya no es tanto de C, si no de desarrollar juegos en general. ¿Que comandos son los que estaría bien integrar en un lenguaje de alto nivel?. Por poner un ejemplo, siempre me han parecido imprescindibles los LDIRVM y LDIRMV, no se como el BASIC de los MSX1 no incorpora algo parecido, transferir datos a la VRAM a base de VPOKEs es una pasada; por eso ya tengo implementados los comandos "vram2ram" y "ram2vram" que hacen exactamente eso...

Se me ocurre, ahora mismo:

- Accesos a VRAM y a RAM
- Accesos a los puertos de joystick
- Accesos a PSG
- Macros: (tipo PUT SPRITE, o PLAY)
- Macros para trabajar con cadenas: (MID$, STRING$, LEFT$, RIGHT$, LEN, SPC...)
- Comprobaciones/Cambios de slots

No se, esto se me ha ocurrido ahora mismo... alguien?  ;)

Pues vaya! He oído críticas poco constructivas respecto al SDCC, pero lo cierto es que no lo tengo muy claro: no he practicado nada. Al parecer no optimiza demasiado - genera código compatible con 8080, con lo cual no saca partido de las instrucciones propias del Z80 -. Y el HItech C es el que es.

Creo que el C de ASCII funciona bastante bien. De hecho, el R-TYPE está hecho con él y no funciona nada mal. Respecto a la idea de una librería, suena muy bien. De hecho, está el frontend que se hizo para el SDCC específico para MSX y parece funcionar bien.

De nuevo, me quedo con el GCC para PC. Maravilla de cosa!

Tanto el SDCC como el z88dk están totalmente desasistidos, cada uno a su manera; pero por lo menos el SDCC y gracias a las contribuciones de Avelino Herrera y Boukichi es medianamente usable para el MSX. No conozco el grado de optimización, seguro que uno nativo de MSX aprovecha mejor los recursos; sin embargo el código generado (lo puedes ver en formato .asm) si que parece soportar 100% el Z80. Tiene además detalles curiosos como el de un "peephole optimizer" especifíco para cada procesador de manera que al listado de ensamblador se le pueden aplicar automáticamente reglas de optimizado. He conseguido la tabla de reglas para el Amstrad, totalmente compatible con el MSX (comparten Z80) :).
Además mi objetivo es que el 90% del código sea ensamblador, de manera que cuando el compilador interpreta una de estas funciones se limita a inyectar (al 99%) mi código.
De momento y por las pruebas que hecho con las librerías que ya tengo, parece funcionar bastante bien :). El único problema serio hasta ahora ha sido solucionar el tema de la memoria dinámica (malloc y demás), para Z80 lo que había era una CHAPUZA.
Bueno, espero que me deis ideas al respecto...

i'm curious for C code, snippets step-by-step tutorial for newbies, etc....

public stuff url for download? where? :-)



(sorry all people i'm not writing here in castellano, my fluency is worse than from Columbus (that one from 15th century) (he wroten castellano mistakes only a portuguese would write, like 'depiende') - and if i try to write in castellano here, surelly you all will make fun of me! ;-)  )

Do not worry about English as far as you can understand Spanish - fluent communication is the key, language does not matter.

About SDCC frontend, you can download it from here (http://msx.gabiot.com/index_es.html#sdccmsxdos)

¡Mil ánimos con eso, José Luis! No tengo ni papa de C, pero ya me gustaría hacer algo parecido en pascal. Lo malo es que los ficheros me parece que los genera para MSX-DOS solo, lo cual me tira para atrás. Pero a ver si algún día la cosa cambia...  :-[

Bueno, de momento los mejores resultados son generando COMs, con la ventaja de que tienes casi 55Kb a tu disposición en fila india. El backend para hacer ROM de Boukichi me lo tengo que mirar todavía ya que el concepto me resulta todavía un poco "alienígena".
Para proyectos grandes siempre puedes hacer un megarom; pero bueno, no hace falta estar constreñido por ese esquema. La comodidad del C es muy grande y te planteas ya cosas como usar alegremente un disquete como soporte (aventuras gráficas con una tocho-imagen por pantalla, multifases con niveles curradisimos, editores de niveles incluidos, etc). Con las ROMs se sabe que tambien se puede llegar a usar la disquetera; pero está todavía por homologar el método.  :P

Pues yo me he puesto con el SDCC y voy a ver .. me parece ok.
Lo que no tengo ni una libreria de gráficos ni de sonido ni de nada.
A ver que consigo. :-)

Lo que si necesito es saber (al menos) como crear un ROM usando el SDCC. ¿Alguién puede ayudarme?

Pero es que todo eso tambien se puede hacer en ASM, que no todo el ASM es ROM! :)

Ya me imagino.
Al igual que me se que no solo de C vive el hombre .. y en el MSX muchas cosas va a tocar hacerlas en ASM.
De todos modos .. el BIn que consigo tras compilar y linkar con el SDCC no es un ROM.
Imagino que hay que añadir alguna marca o algo .. he estado viendo algo sobre una cabecera de 16 bytes .. voy bien?
Supongo que si el ROM es de 16 Kbytes .. la direccion para CODIGO sera &h0000 y la cabecera ira en &h4000
Por más que busco cosas de C y programacion de ROM por Google y Foros ... veo que todavia hay mucha incertidumbre.
Además .. y a apenas encuentro informacion sobre el ASCII MSX-C y tampoco sobre un trabajo al respecto de un tal Bokouchi.

¡Hombre!, ¡un aficionado al C!, ¡ya era hora!  :D
Poner en marcha el SDCC ya es de por si un poco pedestre, montar una ROM aún lo es más. El señor Boukichi es un poco difícil de rastrear (por no decir imposible :P) y lamentablemente necesitarás su módulo de cabecera para crear ROMs. Así que te lo incluyo al final... :)
Yo de momento y para simplificar un poco la creación de las librerías me estaba limitando únicamente al modelo COM y tenía intenciones (de momento) de soportar los modos gráficos 2 y 8. Si estás interesado en echarme una manita con las librerías te lo agradecería infinito ;)

Pues por mi perfecto.
De C y C++ no tengo problemas .. sin embargo de programar a bajo nivel para MSX .. pues .. hombre .. he montado algun que otro emulador y tambien un interprete MSXBASIC .. vamos .. que al menos se por donde van los tiros.
Ya he conseguido hacer funcionar el SDCC y perfecto .. la verdad es que se comporta bien y tiene muchas opciones para optimizar codigo.
Lo que si es un poco complicado es lo de montar la ROM. Al menos he conseguido que el BLUEMSX se pete al cargarla :-) ya es algo.

typedef unsigned int u_int;

sfr at 0x98 vdp98;
sfr at 0x99 vdp99;

void set_mode(u_int mode)
{
   mode; //for avoid warning
_asm
   push bc
   push ix
   ld c, 6(ix)
   ld b, 7(ix)
   push bc
   pop ix
   call 5
   pop ix
   pop bc
_endasm;
}

void main (void)
{
   set_mode (2);
   while (1)
   {
   }
}

esta pinta tiene el programa C con el que he empezado a trabajar .. con el siguiente bat .. monto la ROM ...

sdcc -mz80 --code-loc 0x8010 --data-loc 0xC000 --no-std-crt0 prueba.c
hex2bin -e rom prueba.ihx
copy /b rom_header.bin + /b prueba.rom /b tmp.rom
fillfile tmp.rom final.rom 16368

donde rom_header.bin es un archivo binario de 16 bytes con la cabecera de la ROM ...

0x41 0x42 0x10 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

y el exe fillfile me lo he montado yo para rellenar con 0x00 y completar al tamaño especificado (16Kb) un archivo.

Asi tengo un fina.rom de 16kb tope guay .. que no funciona!! :D o esa impresion me da.

HELP!!!!!

Me acabo de dar cuenta de que .. si la direccion de comienzo es la 0x8010 .. pues que .. igual no pilla el main .. sino el set_mode ese chungo...
mmm ... a que va a ser eso ..
de hecho .. he dejado solo el main con el bucle infinito y .. woala .. ahora el BlueMSX se me queda colgado claro esta al inicio...
IRE BIEN?

De C no tengo ni idea, pero recuerda que, para probar un .ROM, debes poner al final un bucle, porque si no, te empezará a hacer cosas raras o resetearse, etc... no es como un .BIN que abres desde BASIC, hace lo que tiene que hacer y despues te vuelve a devolver al BASIC.

Asín que no te olvides de un:

loop:
   jp loop

O lo equivalente ;)

Si si .. esto lo tengo claro .. es lo primero que tenia hecho.
Creo que ya tengo un ROM en toda regla .. voy a ver si consigo inicializar a Screen 2

Bua!! esto es la pasada :-)
Ya esta todo claro :) .. al menos usando los comandos de la BIOS esto esta chupao
Además .. hacer lo de las ROM al final ha resultado fácil.

Siiii!!! ya puedo montar mi primera ROM .. Dios que ilu!!!

¡Fenómeno!. Yo por si las moscas te he enviado el kit de Boukichi que a buen seguro te facilitará un poco la creación de la ROM...

Buenas

Habeis mirao aqui?
Hay unas librerias graficas MSX para C, no se q tal ira, yo de C nada... :)

http://msx.jannone.org/

Y digo yo, que si al final tienes que colocar codigo en ensamblador, porque no programar directacmente en CM. ¿?

Yo desde luego sigo el consejo que me dio Darth_Fistro hace unos meses, "que teniendo un par de rutinas en ensamblador ya se pueden ir haciendo bastantes cosas", y la verdad que en el fondo no es tan dificil programar en el ensamblador.

Claro que si lo tuyo es el C...  :D

Porque el ensamblador es especialmente útil en rutinas en las que tienes que obtener la máxima velocidad o no te queda más remedio debido, por ejemplo, a que hay que acceder a funciones de la BIOS.
El resto del programa, el esqueleto y partes en las que la velocidad no sea necesaria es muuuuucho más rápido diseñarlo con C. Una tontería del tipo intro de presentación y pantalla inicial en código máquina te puede llevar un par de días; en C, posiblemente en un par de horas ya la tengas (sobre todo si compilas sobre un PC) ;D
Sin olvidar que la base de aficionados al MSX con conocimientos de C (normalmente por razones de trabajo :P) es más grande que la de programadores en ensamblador.
.
.
Me empieza a dar la impresión de estar evangelizando... ::)

Bueno si es por cuestion de comodidad de no tener que aprender algo nuevo, estoy de acuerdo contigo.  ;D

Bueno la verdad  es que cada uno que programe en el lenguaje que quiera. :D

Sin embargo, pienso que para crear una rom de 16K por ejemplo, se puede aprovechar mejor el espacio programando directamente en ensamblaoor que colocando un codigo compilado, no creo que el C genere una rutina de impresion(p.e) mas corta que la que se pueda crear directamente en CM, eso sin contar con lo que el C abusa de la pila cada vez que hace una llamada a una funcion.

Claro que es verdad que yo no soy informatico ni programador experimentado. ;)

¡¡¡ODIO EL C!!!  >:( >:( >:( >:(

A mí, mientras me sigan pagando por programar el susodicho... ::)


Que ya sabemos que a tí lo que te pone es el Haskell. ;)

nerlaska:

Ya que estás recopilando tanta información y realizando pruebas, ¿te ves con coraje para dejar constancia de todo lo que hacer por escrito? Es decir, lo suyo sería aprovechar tus conocimientos para preparar un tutorial en el que hables de qué compiladores existen, cómo usarlos, cómo generar una ROM, etc. Sería -creo yo- un buen punto de entrada para muchos desarrolladores que ya conocen C en otros entornos, pero que se ven limitados por la lentitud del BASIC para MSX y por la complejidad de entrada del ensamblador.

¿Recoges el guante?

Pues sí. También el PERL y el ensamblador del Z80...  ;D ;D

Robsy:

Pues si .. lo tenia previsto. Me gustaría recopilar todos los conocimientos adquiridos en esta experiencia y hacer un Mega PDF en plan libro.
Porque la verdad ..hay mucho que escribir ... no sólo de cual es el compilador a elegir .. he probado varios (HiTech, AVOCET, SDCC, SoftTools y algún otro que ni me acuerdo), si no tambíén de como ayudar al compilador a generar el código más optimo, de como programar y organizar un MegaROM, de como crear audio optimo para MSX, de las herramientas de exportación y mucho mucho más .. sin duda es una verdadera pasada! programar este RPG .. me lo estoy pasando divinamente :-)

¿Y en Java se puede programar para MSX?
 :)

Pues no se .. digo yo que poder se podrá .. aunque no he visto ninguna máquina Java para MSX.

Lo que yo quiero preparar es una ROM para compilar e interpretar el lenguaje script que utilizo en mis juegos de PC .. sólo que con la librería de funciones para uso MSX (vdp, psg, scc, etc.), por supuesto.
Es un lenguaje tipo Java, tipo C y tipo C++ .. vamos .. pupurri .. pero esta bien y tira rápido .. aunque eso ya me lo dira el Z80 cuando lo pruebe.
Si lo consigo pues .. además de trabajar con un lenguaje de más alto nivel que el MSX-BASIC (en mi humilde opinión) pues se tendrán objetos, estructuras, funciones y llamadas a un API con todo lo necesario para acceso a RAM, VDP, PSG, SCC y todo el percal.

Pero .. no se cuando voy a poder!!! estoy con lo de la MSXDev .. y otras historias .. jar!

Pues sí, ahora que la velocidad tendría que ser de risa  ;D.


Lo bueno de todo esto es que cuando empieces a pillarle el gustillo a esto de optimizar el código Z80 ya no podrás parar, siempre podrás sacarle aun un poquito más de velocidad. Eso es lo bueno de desarrollar sobre estas plataformas, en cualquier equipo superior los SOs, APIs y demás zarandajas ya no te permiten controlar tan directamente el hardware.

Are there any open source C library for MSX that compiles under SDCC?
I'd be very interested in join efforts.

By the time I started working on GFX Lib, it was a general consensus that Hitech-C generated the most optimized code.. but things might have changed since then. Also I was advised to stick with calling the BIOS routines by people with more expertise than me.

--
Rafael Jannone

Nerlaska is working on a very powerful library based on SDCC and a high level scripting language over the later with integrated support for memory mapper, graphics and so. I'm sure that we could join efforts around this project in a near future. :)

Jannone .. what do you need exactly? or in what can I help you?
I like very much your MSXWeb job and i'm looking to do this things too with server-side languages, activex controls or even Flash or Shockwave.

Currently i have worked in a library for SDCC for developing my Dev game.
At the same time, i have worked in a script language called MSXScript for giving more power to MSXBASIC users. This languaje gives you the power of work with MegaROMS and use without difficult between ROM/RAM and XRAM and many other features.
Next step .. is to create MSXScript as a real compiler that generates Z80 optimized code directly with inline assembler, etc. using base tools of SDCC.

Well, I don't have a specific need... Rather, I'd like to contribute in some way with the scene.

Say, if we had a free (as in freedom) and powerful C library for MSX, that would compile with a free compiler like SDCC, we would have a lower entry-barrier for C hackers to write MSX software. There would be no need for those guys to mess around, reinventing their wheels all the time; just download it and write great software, while also learning a great deal from well-written code.

Ultimately, that's something very interesting for developers *and* users alike :)

If your library already runs on a multitude of environments, like MegaROMs and such, you obviously gave a lot of thought and work into it, much more than I could ever do for GFX lib. Who knows, maybe I could have been porting the 3D stuff as an add-on for your library. Maybe some great MSX devs could be porting their cool effects like realtime rotozooming and such...

--
Rafael Jannone