Karoshi MSX Community

Bueno ... como ya hay gente que me lo esta pidiendo y veo que ya existe revuelo al respecto ... he creado un documento y he subido un par de recursos para que la gente pueda montar su primera ROM de 32Kb usando C con SDCC.
La idea es que este primer documento que podéis encontrar aquí:

http://www.nerlaska.com/msx/Como_crear_ROMS_de_32Kb_con_SDCC.pdf

Sirva como plataforma de arranque en el desarrollo C para todos aquellos que quieran. Por supuesto, como primer documento y estar escrito a eso de las 3:00 AM de hoy .. seguro que igua tiene algún bug o algo mal .. bueno .. la idea es seguir agregando y modificando temas, etc.

Dejar claro que SDCC tiene un fantastico compilador + linker Z80 assembler que funciona a las mil maravillas y que resulta interesante a la hora de poder compartir código entre programadores C y ASM.

Después de todo esto, mi idea es directamente crear un documento de como poder hacer MEGAROMS Konami SCC 8Kb o cualquer otro tipo de MEGAROM usando SDCC y una herramienta de la casa. SDCC sólo trabaja con 64Kb.
He pensado que preferíria invertir mi tiempo de desarrollo en cosas como el NLKTracker que haciendo el MSXScript, pienso que si ya hay un compilador en la calle que funciona bastante bien y a la gente le gusta el primero contacto con SDCC .. es más fácil que explique como funcionan mis Tools de crear MegaROMS que tener que montar un compilador, linker, etc. Luego siempre podemos compartir código C+ASM y que cada uno lo use como le de la real gana.

Espero que todo esto nos sirva y que empecemos a crear una división C dentro del desarrollo MSX. Merece la pena!
Yo espero dejar un sistema MSXSDK listo para descargar, una vez finalice mis tareas pendientes con la MSXDev. Es importante, a mi forma de entender, que a partir de ese momento intentemos crear una plataforma sólida de desarrollo. Intentado unificar código y dejándolo a la disposición de todo el mundo.
Bueno, ya hablaremos de todo esto cuando lo suba.

También podéis bajaros el ejemplo del PDF, junto con los EXE y la rom_header.bin .. todo junto en un paquetito.

http://www.nerlaska.com/msx/prueba.rar

Nada, nada, que ya no hay excusas para no programar en C ;)
Bueno, a mi me falta un pequeño detallito para que mi convencimiento sea absoluto: jugar al Monster Hunter!! ;)

Gran iniciativa, nerlaska!. Luego lo leo todo con más detenimiento!  ;)

Y en cuanto al Monster Hunter, pues la verdad es que mola mucho, pero lo pusiste tan cojonudo/konami-like/se os caerán los huevillos al suelo, que lo vi un tanto brusco en los movimientos del personaje, y la pantalla de luchas un pelín "vacía" y algún detalle más (eso te pasa por haberlo vendido tantoooooo  ;) )... pero bueno, que el juego, la verdad (y lo digo como lo siento), tiene BUENÍSIMA PINTA. Además, en estos juegos no es la velocidad al pixel lo que cuenta, sino la historia, la ambientación (gfx y música, que por cierto, era muy guapa), etc... Ansío poderle echar mano y viciarme, eso sí, despues de la dev...

Así que, y tras verlo en la RU, puedo decir que es uno de mis más esperados del MSXdev'06. ;) Además es impresionante, como primer juego... buen trabajo, nerlaska!  :D

Lo dicho, en un rato me leo tu documento con más tranquilidad :). Muchas gracias por compartir tu sapiencia por aquí!... por cierto, podríamos montar una especie de "biblioteca" con este tipo de documentos, que os parece?...

Gracias Jon .. bueno .. tampoco habia alardeado de grandes efectos y cosas así .. simplemente de la dificultad técnica que tiene haber montado un juego como este. También tengo que decirte que se han tenido que quitar cosas por el tema de la memoria .. pero .. en fin .. se ha hecho lo que se ha podido :) y aunque no lo creas .. hay un curro de morirse detrás.

Si que lo creo, nerlaska, si que lo creo! ;), anduve dando vueltas yo también al diseño de un RPG y flipé del curro que hay. Lo dicho, no quisiera que te tomaras mi comentario como algo negativo, en serio... tengo la ostia de ganas de poderlo jugar entero!. De nuevo, y por si no lo hubiera dejado bien claro: buen trabajo, nerlaska! (y colaboradores, claro)  :god:

Gracias por preparar el tutorial, Nerlaska. Lo cierto es que parece más fácil de lo que me se me había antojado al principio. De todos modos, lo suyo sería coger el código fuente del SDCC y meter las modificaciones "en caliente" para que genere ya ROMs y no haya que hacer más pasos intermedios. No creo que sea especialmente difícil.

De momento me quedo con mi asMSX, pero creo que el C sí es una muy buena alternativa para gente que no tenga tiempo/ganas de meterse en ensamblador y quiera hacer algo con una ejecución mucho más rápida que en BASIC. Un camino más siempre es bienvenido.

Por lo demás, insisto:

.bios
.page 2
.rom
.start INIT

INIT:
...

Y ya tienes una ROM directamente  :D

(Sorry friends but I have to write in English)

Hi friends, my name is Andrea, from Italy. Some time
ago I sent a small game (I.N.E.R.T.I.A.) to the
MSXDEV'06 contest. Well, the game was developed
in C using SDCC, with a procedure similar to the one
proposed by Nerlaska, if time and chance will permit
I would write some similar PDF reporting my experience,
in that case I'll drop a message to MSXDEV team too.

My best regards,

Andrea

That would be great, Andrea. We look forward to hear from you!

Welldone nerlaska!
but you should document also how you deal with magarom and ROM mappers ;)
I'd like to do a similar guide for Hitech C v7.8 (when I'll have the time).

BTW
What about a small article about the compiling efficiency of the C cross compilers for z80?

I am very curious about a comparison of the ASM code generated by SDCC and Hitech C.
Do you have same small segment of code you find interesting for comparing the compiler results?
If you post it on the forum, I could try to compile it with Hitech C and post its asm,
you could do the same with SDCC and we can try to comment the two compilers.

I think SDCC is improving fast, while Hitech, even if is a commercial product, has stopped the
development of its C compiler in 2001 (v7.80  has been released in September 2001).

I think it's worth a comparison, even only to know for which kind of algorithms one is more
suitable of the other

Anyone out there is willing to prepare a C compilers benchmark? I'd be interesting to compile different source codes and compare the results using different C compilers. Check code efficiency in terms of size and speed would be great to decide which C compiler is more suitable for MSX game development.

Esto..... podrias volver a subirlo porfavor.
A ver si le pego un ojo.

Bueno como he dicho por otro hilo, este tutorial hace tiempo que lo leí y me pareció interesante. Me gustaria que hicieras algun manualillo algo mas extenso mas que nada porque tengo agunas dudas de como hacer programas ROM en C. Te las pongo aquí por si te animas a hacerlo y de paso me ayudas a resolverlas:

duda numero uno: ¿ como metes los datos que son fijos ?, no sé si me explico, por ejemplo como metes los datos de un juego nuevo de caracteres por ejemplo. Me refiero más que nada a si lo haces en forma de archivo y por supuesto a como haces referencia a ellos. Espero que la duda no te parezca un poco chorra, pero en ensamblador o basic es muy facil o bien lo haces con db  (con su correspondiente etiqueta para hacer referencia a ellos cuando haga falta) o con data.

duda numero dos: No tengo muy claro como pasar datos a las funciones que usan "assembler inline". ¿ Como pasas los datos, por referencia, por valor? ¿en donde se almacenan ?

duda numero tres: ¿ como se hace un megarom en C?  ;D

En fin podría seguir, pero esto creo que es bastante ilustrativo de mis dudas.

Pues puedes hacer lo mismo en C, meter los datos fijos mediante "peazo" includes. Para ello hace falta un programa que genere una salida en el formato de array de C a partir de los binarios en cuestión.


En el SDCC los parámetros de la función se pasan mediante la pila, el código de la función los puede recoger a partir del 4º byte. Estos parámetros aparecen ocupando 1 byte o 2 bytes cada uno de ellos (no se si soporta tipos más grandes; pero tampoco voy a usarlos  :P)


¿Con mucha paciencia?  ;D

Bueno, tal y como dice JL .. pues si .. puedes meter los datos en un include en algo estilo:

unsigned char SPRITES_PERSONAJE[512] = { 50, 30, 10, 30, 50, ... }

Pero cuidado!! porque si lo metes así .. resulta que lo estás metiendo como RAM, o sea . .te creará el buffer en RAM además de tener los datos en ROM.
Si sólo quieres tenerlo en ROM lo unico que tienes que hacer es meter esto:

const unsigned char SPRITES_PERSONAJE[512] = { 50, 30, 10, 30, 50, ... }

Pero bueno .. ya te imaginas que pasará en cuanto empieces a meter muchos arrays de estos, verdad? :-)

Sobre lo de pasar los datos a funciones ASSEMBLER INLINE pues . .puedes hacerlo usando el estandard SDCC o sea por pila. O bien si queires puedes hacerlo por registro, pero para eso la llamada también tendrás que hacerla ASSEMBLER INLINE. La forma del SDCC está bastante bien y es muy cómoda.
Si tu has usado algo como:

void MiFuncion (char a, int b)
{
  _asm
     ld a, 4(ix)
     ld l, 5(ix)
     ld h,6(ix)
  _endasm;
}

El SDCC ya te ha preparado las cosas como toca, o sea, que tienes el registro IX listo para leer los argumentos. A partir del 4(ix) los tienes todos.
Si quieres devolver algún valor, usa el registro HL, L si es de 8 bits y HL si es de 16 bits. El SDCC ya supone esto, por ejemplo:

char MiFuncion (char a, int b)
{
  _asm
     ld a, 4(ix)
     ld l, 5(ix)
     ld h,6(ix)
  _endasm;
}

Si llamas a MiFuncion devolverá la parte baja del valor que hayas pasado como b.

Sobre lo de los MEGAROM, jejejee .. ese es mi pequeño secreto y mi gran currada por cierto :)
Para hacer esto tienes que tener la mente despejada y tener muy claras muchas cosas antes .. pero te adelanto de que va esto..

Tienes que saber separar código de datos dentro del ROM. Yo uso 32Kb para código y el resto para datos.
Eso como lo pongo? .. bueno .. pues obviamente despues de compilarlo todo. Incluyo con una herramienta toda la parte de código y de datos.
Generando el ROM de 128, 256 o 512.
Claro .. asi dicho suena fácil .. luego esta el tener código como datos y poder ejecutarlo :)
Al igual que todo el tejemaneje de mover datos de MEGAROM a la zona visible sin tocar tu código genérico ni tu RAM. Para eso has de organizar bién tu código y tener claras las limitaciones. Pero creo que antes .. deberias tener claro como hacer ROMS de 32Kb.

Zenquius a ambos,

lo de almacenar datos, totalmente aclarado (simplemente pensaba que generabas los datos con algun otro programa y luego lo incluias en forma de archivo, no sé porque tenia esa idea).

lo de pasar valores (la devolucion de valores lo tengo claro) tambien lo tengo claro, y si no me equivoco se podria hacer, tambien, simplemente con la instruccion pop extrayendo datos.

Y lo del megarom, era una broma, solo quiero probar con el C a ver que tal. ;D

Insisto, te podrías animar a hacer algun manual algo mas extenso ;D

Using the "large model" in hitech C (the cross compiler, not the CPM version) you can generate up to 1Mbyte rom both for code and data.
The compiler manages the jumps among banks and the linker finds the optimal memory arrangement for code and data.
Naturally there are some limitation, as the memory management is suited for z180 not for MSX mappers.
You have are:
1) the memory layout has a common area 0, a banked area (one large bank!), a common area 1 (usually including RAM)
2) the user has to provide the code for bank switching
3) the compiler can mange only one large bank, so,e.g., you need to swap 3 pages at time as they were a single page
4) data and function must share the same bank, if you want to use the same C code of different banks, the code has to be in common area
All those limitations apply in C. Naturally, in asm, you get full access to the banks and you can address the segments allocated to the data using the pseudo-operator "seg(_nameofthe var)".
This allows you to leave the linker to manage the memory layout in rom even if programming in ASM.

La verdad es que si alguna vez tuviera que hacer un Megarom posiblemente me decantaria por el ensamblador, creo que sería más sencillo.

De todas formas yo por el momento ->I'm satisfied to programming ROM of less of 32k  ;D

Programar MEGAROMS en C .. es un pasote :) que quieres que te diga .. la verdad es que al SDCC le hago hacer volteretas .. eso y las herramientas que he tenido que confeccionarme me han permitido hacer cosas como el Monster Hunter .. pero es lo que te digo, es preferible primero dominar SDCC hasta las 32kb luego seguro que vas a querer probar con 48 y luego con 128, etc. El adjuntar datos en ROM no es problema, los clavas en el archivo ROM en su sitio, los tienes localizados y punto, el asunto está cuando además metes código y entonces tienes que dar soporte MultiBanco, crearte un linker y cosas de esas.

Your links are dead!
Where are the files?
 ???

What files do you want?
I don't know that you are refering.

I mean
http://www.nerlaska.com/msx/prueba.rar
and the tutorial

Hi again friends, as I said some time ago I wrote a short
report on how I built my ROM with SDCC. It's available on
my website: http://andrear.altervista.org under MSX Software
menu.

I also decided to make my game source code available, for people
to experiment and play a bit with the compiler; link to source code
is cited inside the tutorial.

Beware that:

1) I only built a simple 16KB ROM, and just documented steps
to build I.N.E.R.T.I.A.

2) I wrote the guidelines "a posteriori", so I could have
forgotten something ( :-[ my excuses in advance, any feedback
will be welcome)

I hope to be of any help or interest for someone. Sincerely,

Andrea

Thanks Andrea, it will be for sure! :)

THANK YOU VERY MUCH  andrear1979  !!!!!

Thanks. It is fantastic.

A ver si cunde el ejemplo por aquí.

Eso eso! que se liberen los fuentes de varios programitas estaria muy bien :)

Pero para que queréis los fuentes por ahí? :) jejeje
La potencia sin control no sirve de nada :)

Por si algún comentario va dirigido a mi persona :) (me siento aludido)
Como ya lo he hecho con otros usuarios, si alguién tiene alguna duda con algo, que me pregunte por email.
Pero tengo que decir que hay información de sobra por INET para poder montar TODO para MSX.
Hasta un driver MSXAudio/MSXMusic en C .. y mira que de eso hay poca información, pero la hay.

Animo a esos que se animan por usar SDCC .. ya os digo que habéis acertado!

jejeje, cada uno es libre de hacer con los codigos lo que quiera  :) pero un poco de ayuda nunca viene mal  ;D

y es normal que te sientas aludido, eres de los pocos que hacen cosas con SDCC :)

por cierto, haces un muy buen trabajo con el SDCC :) felicidades por tus creaciones.

Por favor, alguien me podría pasar por privado la herramienta "split", me he descargado los archivos de Adrea1979, pero no soy capaz de bajarme esta utilidad. Gracias al que me pueda ayudar.

Por cierto, Nerlaska, los archivos ASM que genera SDCC solo son compilables por el propio SDCC ?. Este archivo me ha fascinado, muy util para el que quiera aprender ensamblador :).

Y una ultima cosa, no sé si sera bien aceptada, pero en otros foros, más concretamente en uno dedicado al FREEBASIC, he visto que la gente hace comparativas entre diversos lenguajes como por ejemplo el C++ y FreeBASIC, para ver cual es mas eficiente y más rapido, etc. Se podría hacer algo parecido aqui entre el "ensamblador" y el "c", haciendo alguna rutinilla, no necesariamente complicada, que programada en ambos lenguajes nos sirva para comprobar las diferencias de velocidad y tamaño (por ejemplo) entre los dos lenguajes. No se trataría de demostrar que el ensamblador es mejor y mas rapido, sino de comprobar la diferencia entre ambos. Creo que esta comparativa serviria para elegir un lenguaje u otro para hacer segun que cosas.

Ea, pos lo dicho a ver si algun alma caritativa me puede pasar el "split".

UnxUtils (http://www.pcwelt.de/downloads/tools_utilities/desktop-tools/102440/index.html)


El problema del ensamblador del SDCC es que es un poco especial y no sigue demasiado al estandar clásico del TASM. La verdad, para meter ensamblador en C, evidentemente es lo que hay que usar; pero como sustituto de un ensamblador auténtico, ni de coña ;)

Respecto a los benchmarks, ahora mismo tienes en el MRC un intento de encontrar el compilador de C más efectivo. A ver si consiguen algo y pueden llegar a alguna conclusión útil.

Gracias, por la descarga.

En relacion a la comparacion, solo me referia a algo sencillo en el que se compare pues elementos tipicos del C, como por ejemplo los bucles, las condiciones, etc, para ver si se pierde mucha velocidad, o si ocupa mucho más tamaño, etc, no me referia a algo serio, simplemente algo para matar la curiosidad. Claro que tendría que hacerlo quien domine los lenguajes. Pero bueno, solo era una idea, yo este año quiero probar con el C a ver que tal va la cosa, Nerlaska me tiene medio convencido.

Well, even if the code tested has been manipulated by me in order to link the Hitech libraries, It seems
that SDCC is faster than Hitech C v7.8 that, in turn is faster that Hitech CPM
If we stay to Microtech tests (but I want to verify) Ascii C 1.2 is even faster than SDCC

Moreover I need to test IAR and WinIde also, to see how they behave

Job's .. ni lo dudes .. usa SDCC .. te lo digo yo . .que el año pasado me pegue con 5 compiladores diferentes!!! porque estaba igual que tú .. o sea .. que leches uso? ahora ya conoces a alguien que te asegura es la mejor opcion .. yo en mi dia .. no tuve a esa persona aunque Avelino Herrera formo parte de la inspiracion :)
El SDCC es fácil de usar y funciona perfectamente con Windows y otros sistemas operativos.
El Assembler del SDCC es una maravilla y se integra divinamente en el código.
El SDCC te deja hacer mil y una martingalas para compilar
Además de que te permite generar información muy interesante para poder hacer cositas (como los MegaRoms)
Montar una ROM de 48Kb con el SDCC esta chupao!
Montar un MEGAROM con el SDCC esta chupao! siempre y cuando no uses código fuera de las primeras 32Kb
  Nota: Si alguien tiene curiosidad. El Monster Hunter si usa código fuera de los 32Kb primeros.

Que más quieres que te diga, tirate ciegamente al SDCC!!! vas a ganar y mucho en tus desarrollos MSX. Y si necesitas ayuda de algún tipo, enviame un email. Ya te lo dije!!

  Mis excusas Jos'b for not including a valid "split" link, I'm gonna
add the suggested link to the tutorial. Some (maybe obvious,
maybe wrong: I don't pretend to be a C guru) personal opinions
about SDCC:

1) negative: as this is a general 8bit C compiler, you have to
add MSX-specific code by yourself. Very limiting if you would
(for example) build a standard COM file using MSX-DOS.

2) positive: very similar to gcc, easier to learn you are already familiar
with it (gcc it's often used in academic/educational structures).

3) very positive: as it's a cross compiler, you get high compilation
speed, and can also interface easier with software you can hardly
have on MSX: syntax-coloring IDEs, complex makefiles, documentation
systems, binary manipulation programs, graphics packages... net result
is faster developing time.

Bye friends,

                                                                                 Andrea

No problems.
I think to create my own utility  :D

Vamos que no creo que sea dificil hacer una pequeña utilidad para generar cualquier tipo de archivo msx, (rom o bin), a partir del ".ihx" sin tener que usar varios programas externos :).

Para mí lo más positivo del C u otros lenguajes frente al ASM (y hablo en general) es la posibilidad de poder montar estructuras logicas (del tipo if ... then ...) de una forma muy muy sencilla y rapida.

Job's . .de Ihx a bin .. necesitas un Hex2Bin .. vamos que ya hay un programa asi para Windows Visual Studio si lo quieres y con fuentes
Y si lo quieres en EXE ya compilado y operativo .. me lo dices que te lo paso.

Y con el SDCC puedes programar ROMS, COM y lo que te de la santa gana .. de la manera más fácil del mundo .. pero claro .. ya te aviso de que has de olvidar usar los msxcrt.o y cosas que hay por ahi .. Andrear ha empezado mal sus andaduras por estas tierras del SDCC :)

Has de empezar a pelo, desde 0 .. que es muy fácil y has de tener control máximo sobre el código generado .. que quiere decir .. que no uses sus multiplicaciones ni divisiones .. usa las tuyas .. para asegurarte que todo el código generado se crea donde tu quieres. Recomendación MAXIMA!

  Hi Jos'b, SDCC comes with the "makebin" utility, that creates the binary
file from .ihx files. Would you ever create your own utility, I think it's much
simpler to alter makebin's output instead than .ihx (even for doing ROM to
BLOADABLE changes).

  I also think that MSX user Boukichi already suggested or made his own
ihx->rom filter (don't remember more details, sorry); finally, may worth to
look at http://srecord.sourceforge.net (complex but very complete package).

  Bye everyone,

Andrea

Thanks Andrea

Pues si no tienes inconveniente pásamelo por privado, voy a compararlo con las utilidades que ha indicado Andrea

A eso no sé a que te refieres. ¿ Qué no use los operadores matematicos del C ? Me gustaría que me pusieras un ejemplo.

En general, para el uso que se le va a dar, las implementaciones de estos operadores matemáticos son un poco aparatosas. Ya no es sólo que no es necesario hacer operaciones con coma fija; sino que ni siquiera necesitaremos posiblemente decimales. Si se quiere rascar al máximo posible la velocidad y el tamaño, lo mejor es implementarse rutinillas de multiplicación y división reducidas a tope. En cualquier caso eso es si no nos queda otro remedio, lo más recomendable es conseguir que todas las operaciones se hagan con potencias de 2, con eso podremos utilizar desplazamientos que es lo más rápido y compacto.

Oye gracias por la aclaración, no tenía ni idea que esas operaciones fueran tan impertinentes en el codigo final. Pero aún así, sigo sin comprenderlo muy bien, y si usamos vaolres enteros (p.e un "short int" o "char", el resultado de multiplicar un byte por otro, no deberia inflar el codigo en exceso  ???).

Mas que por inflar es porque el SDCC a menos que sea una multiplicacion VARIABLE * CONSTANTE .. lo que suele hacer es llamar a una rutina interna mul8 o mul16 que te agrega en codigo .. y tu no tienes control de donde te mete estas rutinas .. entiendes?
Por eso te lo digo .. porque si no tienes en cuenta estas cosas y luego quieres tener control 100% sobre tú código .. pues vas a tener problemas.
Pero claro ... si quieres puedes usarlas .. están bien .. lo que te aumentara un poquitin el espacio que vayas a usar. Ya te digo .. si simplemente quieres tu rutina dentro de los 32Kb .. pues no pasa nada si las usas.
Por cierto .. fíjate siempre en el archivo .MAP que te genera el SDCC es muy importante. En él, vas a ver todas las cosas que se han generado en tu código, etiquetas, variables, funciones .. TODO .. verás que direcciones se han asignado y que funciones se han agregado que tu en principio no esperabas.
Va bien para saber si todo esta correcto, el código está en su sitio y la RAM en el suyo también, etc.

Bueno, pos ya he hecho mi primero bloqueo de msx en C ;D

Tendreis noticias mias, para bien o para mal, os lo aseguro.

Ah por cierto Nerlaska, Thank you

Lo que no encuentro es alguna referencia al ensamblador del SDCC un poquitin extensa ???. Claro que a lo peor no existe.

Lo quieres usar inline o no? .. te recomiendo que lo uses inline siempre.
_asm
_endasm;

Y entre esas cosas pues... instrucciones Z80 de toda la vida. Por email te paso un PDF con los código del Z80 bien explicados y todo eso. Es de Zilog el PDF así que mejor que ellos. :)

La tienes aquí (http://sdcc.sourceforge.net/snapshots/docs/sdcc-doc-20061231-4542.zip), en el último snapshot de la documentación del SDCC. Busca dentro de la carpeta AS y encontrarás un montón de documentación.

Gracias a ambos por la información :D

pero ya los tenía ;D, el de zilog(Nerlaska) además lo tengo impreso, y el del SDCC (JLTursan) es que lo veía un poco flaco en algunas informaciones (por ejemplo en asm).

Pero bueno ya más  o menos tengo claro como tengo que introducir el codigo "inline".

Gracias de nuevo, asi da gusto programar.
 :D

Ahí va...

Mi primer programa en C para MSX ;D

No sé si liberar el codigo fuente ;D de la hazaña.

Enhorabuena! :) .. ese es el gran comienzo .. tras eso .. ya vienen los Maze Of Galious 2, Metal Gears 3 y todo eso :-)

Otra pregunta de C (Para Nerlaska y Otros que quieran ayudarme)

¿ como haces para que suene la musica en C ? ¿ tienes preparado algun player por tí o has adaptado alguno que ya existia ?

He estado probando varios programa para editar musica para el PSG, como el PSGTRAKER, y otros que hay por MRC(incluidos los que usan SCC, etc), sin embargo el que mas me convence es el Carusso de Robsy, entre otras cosas porque incluye un ejemplo de uso del fichero que genera el propio programa. Aunque no tengo muy claro si sería facil adaptarlo al C.

Me gustaría saber, tambien, si usais otros programas para musica, que no sean muy coplicados para PSG.

Pues yo me he montado un player PT3 para la musica y AFX para el audio.
Aunque ahora estoy trabajando en un formato propio con soporte PSG/SCC/MSXAudio/MSXMusic
Pero vamos, si no te quieres complicar la vida usa los players que te deja la gente por ahi, como el del Carusso que te costará poquito de convertir al ASM de SDCC.

Nerlaska, tienes pensado publicar algunas de tus librerias para SDCC? musicales o graficas, el pobrecito esta desnudo.

Pues de momento no, la verdad porque quiero cerrar un SDK completo de programación SDCC y aún necesito tiempo para cerrarlo. De todos modos, a Job's ya le he ayudado por email y siempre que el quiera estaré dispuesto a hacerlo. A él y a quien quiera, claro.

Oks, yo tambien estoy creando funciones para el juego en red que podrian añadirse, eso si no valen para ROMS tiene que ser bajo msx-dos (de momento).

Muchas gracias, ya sabes que soy un discipulo tuyo nnchks:)

Seria posible volver a colgar los archivos que hay en la primera pagina de este post?
El pdf de como hacer roms y el rar.

Muchas gracias!

Merci por el PDF!
Este fin de semana me esperan un par de NightCodingSessions  ;D
A experimentar toca!