Karoshi MSX Community

Despues de la fantastica adquisición LPE-MMC de Padial, estoy intentando hacerme con un leguanje C para MSX, con el que poder "pegosear" en momentos de ocio.

Actualmente tengo dos, el BDS-C y el ASCII MSX-C.

1/ Respecto al primero. Que se puede encontrar aquí:

http://www.bdsoft.com/resources/bdsc.html

Me funciona "casi" perfectamente. Todo va bien salvo cuando intento acceder a la Bios a traves de sus propias funciones, o cuando intento llamar a pequeñas rutinas en ensamblador.

2/ Visto el tiempo que llevo fracasando con el BDS-C, he decidido por fin hacerme con el ASCII MSX-C, que se puede encontrar en este otro sitio

http://msx.retro8bits.com/msxsw.html

Sin embargo, despues de tener todo preparado (incluido el ensamblador MASM), no consigo que el "generador de código", archivo "cg.com", haga su trabajo. Siempre me lanza el mensaje de error "ilegal .tco file at 0:1".

3/ Por lo que como no soy capaz de conseguir que la cosa funcione como quiero me gustaría saber si me podeis echar una mano con la siguiente información:

3.1 / Primero me gustaría saber si el siguiente programa es válido para llamar a una rutina en ensamblador y que ésta funcione. Me refiero evidentemente, ya que el código se compila bien, a algún detalle que se me pueda estar pasando en la llamada al código objeto, o al propio código objeto en sí.



3.2/ Y segunda petición de ayuda. ¿Alguien sabe dónde encontrar la documentación de ASCII MSX-C?.

A lo más que llego es a averiguar que un tal, FREDDY VULTO, tenía una página con esta documentación, sin embargo no soy capaz de encontrarla.

Lo correcto sería poner char cls[5], no? .. asi reservas 5 bytes.. si pones sólo un puntero .. no estas reservando espacio como para luego escribir en RAM ... de hecho siendo MSXDOS igual esto te da algún problema no? porque el MSXDOS tendrá que ubicar tu código en RAM según el tamaño de tu COM y si no declaras esos 5 bytes? No se muy bien como trabaja el BDS-C ni el ASCI MSX-C .. lo cierto es que me he volcado más al SDCC pero es para PC como ya sabes.

La idea del puntero es simplemente por comodidad. Así me ahorro tener que ir contando cuantos bytes tienen las funciones en C.M. Aunque reservando cinco valores para el vector cls  tampoco funciona ¿?. Además cuando asigno valores a la tabla, ya se están reservando en memoria.

El BDS-C, supongo que es similar al SDCC en cuanto colocación de variables y demás. Todas las variables se colocan justo a continuación del código, a no ser que le indiques al compilador lo contrario, y con la reserva de espacio RAM que quieras.

No sé si habrá alguien con experiencia en este C. Yo desde luego estoy un poco perdido. En principio el BDS-C fue creado para CP/M, y no se si esa puede alguna razón para que no funcione a la perfección con el MSX-DOS 2.2. El compilador genera código perfectamente, salvo cuando intentas usar funciones que acceden a la Bios, a las funciones del Dos o llamadas a C.M. Y este es el punto que más me preocupa, puesto que sin poder acceder a rutinas en C.M. solo podré usar el C para tratar cadenas y poco más.

Y respecto al ASCII MSX-C me conformaría con saber dónde conseguir documentación.

Por cierto Job's ... y estas seguro de que te entra en el main y todo eso, no?
Y de que la gestión de los parámetros de entrada se gestiona bien desde el compilador y lo de arrancar en la 0x100 .. no se .. yo pregunto .. imagino que lo estarás teniendo en cuenta.

Los argumentos de main() son obligatorios para que el BDS-C lo compile. Respecto a la dirección de inicio del MSX-DOS, supongo que lo ensambla bien, ya que si quitas las funciones init() y call() te lo compila, ejecuta y además te devuelve el control al DOS perfectamente.

He probado, creo, todas las opciones que se me han ocurrido. Desde alojar el código C.M. con la funcion poke(), haciendo la tabla cls[] como local dentro de main, y asignandole valores en ella, hasta probar con las diferentes opciones del compilador, como por ejemplo la opcion "-m" para indicar la dirección de inicio, o "-e" para alojar datos. Entre otras cosas. No podría decirte todo lo que he probado, porque no lo recuerdo. Pero llevo desde enero con él liado, y no hay forma.

Otra forma de crear funciones en C.M., es crear directamente una libreria con el AsMSX, por ejemplo. En el USER'S GUIDE del BDS-C, explica paso a paso como hacer librerias para el compilador. Sin embargo tengo algunas lagunas en lo que se refiere al tratamiento de la pila y el paso de argumentos.

Además, parece lógico que la función CLS, tal y como la he definido en el código fuente, debería funcionar. Por lo menos borrar la pantalla, que es lo que se pretende. Sin embargo, según como, a veces parece que se salta la función call() y pasa directamente al printf(), imprimiendo el mensaje, pero sin devolver el control al DOS. Muy raro.

En definitiva, despues de tanto tiempo probando, tengo cierto interés en probar el compilador de ASCII, a ver si este da mejor resultado.

Veo algunos problemas en el código que paso a comentarte:



Como ya te ha dicho Nerlaska, *debes* reservar tantos bytes como sea necesario para albergar tu función. Por supuesto, puedes optar por no hacerlo; pero según organice los datos el BDS, tu código será machacado o no.


Si pones "*cls" no vas a llamar al código contenido en cls, sino a la dirección contenida en cls, es decir $CDAF. Quita el * y estaría correcto. Por lo demás no conozco la sintaxis del BDS y del call.

Lo normal en estos casos es implementar una función estandar de C con código ensamblador inline, ¿no es posible con el BDS?.

Por último, lo habitual de estos compiladores es trabajar desde MSX-DOS; así que la BIOS no está disponible. Para llamar a funciones de la misma tienes que emplear inter-slot calls, el método lo tienes explicado aquí (http://map.tni.nl/sources/callbios.php). Una vez más, no estoy seguro de como trabaja el BDS; pero si se ejecuta desde MSX-DOS ya sabes a que atenerte :)

Mi recomendación es que te pongas con el SDCC o con el Z88DK, te resultará más fácil y encontrarás más ayuda. Si de todas formas estás convencido de que quieres usar alguno de estos otros compiladores, yo te puedo pasar todo lo que tengo, en su día acumulé mucha información ;)

Acabo de probar tu sugerencia, y ciertamente con "cls[5]" y cambiando "*cls" en la llamada call por "cls". Devuelve el control al DOS sin problemas. Posiblemente me haya puesto obtuso, con cls[] y *cls, que era la idea original de ahí el comentario del código, en vez de "cls" que apunta a la tabla.


Cierto. Me remito al comentario de arriba.


Hasta ahí llega mi ignorancia sobre el MSX-DOS. Gracias por el comentario, esta tarde intentaré dedicarle algo más de tiempo a los links.


No. Solo tiene algunas funciones que llaman a rutinas de la bios o del dos, tipo bios() o bdos(). Y salvo error u omisión no soy capaz de hacerlas funcionar.


La idea no es usar un C poderoso como el SDCC o el Z88DK, sino disfrutar con el MSX real, haciendo pequeñas cosillas. Además tampoco creo que pudiera sacarle el máximo partido a estos compiladores puesto que no soy un experto en C.

Respecto a la información, mi correo esta abierto a todo el mundo. Y por supuesto si desearia recibirla, me cuesta mucho encontrar información relativa a ambos compiladores. Respecto al BDS-C solo cuento con la que el autor del compilador tiene colgada en su web.

Y creo que por mi parte nada más. Probaré esta tarde las llamadas a la BIOS. Ya contaré los resultados.

Bueno, como prometí, comento que los resultados han sido positivos. Efectivamente como ha comentado JL, el problema era simplemente el modo de llamar a las rutinas de la BIOS.

El nuevo código es el siguiente

El código objeto ha sido obtenido mediante el siguiente código fuente para AsMSX y la herramienta BinDB.

Bueno, pues gracias por las aclaraciones. Si hago algo útil en C prometo hacerlo saber.

Prueba el hitech-c. Desde mi punto de vista es el mejor compilador nativo que hay (hay versiones cruzadas que son mas avanzadas). Puedes encontrar la version de CPM en la web de hitech, y habia por ahi un par de parches y librerias para msx (incluso un make que en su dia yo use para cierto proyecto).

Gracias por la información. Aunque en la página oficial, no hay forma de descargarse el compilador para CP/M. Buscare a ver si estuviera colgado por algún otro sitio.

Respecto al BDS-C, va bastante bien, ayer mismo estuve haciendo algunas pruebas con ficheros(acceso a binarios y modo texto) y perfecto. La única pega que le veo, es que no tiene una triste libreria para dibujar un punto en pantalla. Por eso, la idea que me parece más asequible para mí, es crear un arhivo .h, con definiciones de tablas con el código objeto, de funciones tipo imprimir un sprite, borrar pantalla, hacer un locate, etc. y llamarlas con las funciones "call" o "calla".

http://pag-per.servicam.com/migl/amstradpcw/c_compilers.html
http://msxbanzai.tni.nl/dev/software.html


Y creo que Nestor en su dia hizo algo para hitech C, aunque en su pagina ahora no esta (lo buscare en mi disco duro)

Gracias de nuevo.

Ignorante de mi cuando pensaba que solo existía el BDS-C para MSX.

He probado el Hitech-C en el MSX, con el MSX-DOS 2.2, pero me sale directamente el mensaje de "Incompatible disk" cuando intento compilar algún archivo (con fuente basada en el estandar ANSI)...

... creo que necesitaría un manual para poder usarlo.

Por fin encontré el manual. Escondido tras un archivo "z80doc.exe". Tendré que dedicarle algo de tiempo. Aunque por ahora, no encuentro en él el error que me sale de "incompatible disk". Supongo que para eso servirán los parches que andan por ahí.

Si sigues teniendo problemas dimelo y te envio directamente la version que tengo yo en el disco duro del msx.

Y genera código chulo el Hitech este?

La version nativa no va mucho mas alla de lo normal en MSX (uso exclusivo de pila y esas cosas). Las ultimas versiones cruzdas si permitian el paso de parametros por registro y cosas de ese tipo (el codigo generado por estas versiones es muy, muy bueno), el problema es encontrarlo, porque las versiones cruzadas son de pago (yo tenia por ahi una version antigua para ms-dos pero que para el caso es casi lo mismo que la version de MSX en lo que al codigo se refiere), excepto  una demo que hay en la pagina pero que no se a que te limita

Bueno, se me olvidaba que por ahi hay un script para ejecutar la version nativa en linux (usando un emulador de CPM): http://msx.retro8bits.com/msxsw.html

y Nestor en su dia hizo unas librerias especificas de MSX (que no se por que no estan en su pagina :~), pero que seguramente tendre en mi disco duro.  El hitech C fue bastante popular entre los usuarios de MSX hace algunos años, especialmente cuando Adriano escribio Uzix usandolo.




Roberto.

Pues la verdad es que no consiguo hacerlo andar. El compilador se ejecuta y envia sus mensajes pero no carga los archivos fuente que están en la SD (FAT16)(tampoco he sido capaz de echar a andar el MSX-C). Y me gustaría probarlo, sobre todo por la libreria que hizo Konamiman para el MSX. Más que nada por saber si puedo ahorrarme el trabajo de tener que crear funciones en arrays para el BDS. Si quieres enviarmelo te estaría agradecido.

Por supuesto tambien agradezco información. Aunque sea mediante links a webs.

Ahi tienes la version que probe yo en su dia, bueno yo me las baje de funet, que para el caso es lo mismo (que mandartelo directamente es mas dificil porque no se tu email).

http://www.msxarchive.nl/pub/msx/programming/c/


Y sobre las librerias de Nestor las he encontrado y son para acceder directamente a las funciones del DOS desde los programas C, si las quieres dime a donde te las puedo enviar.

Me he vuelto a bajar de nuevo el compilador. De momento solo le he echado un vistazo por encima, y sin duda es más completo que el BDS-C.

Ya contaré mis expereciencias con él.

En cuanto a las librerías, realmente lo que me interesa es poder utilizar alguna función gráfica desde el C. Por lo que el Hitech-C tampoco me soluciona, de momento, el problema.

Respecto a mi e-mail lo puedes encontrar en mi perfil del foro. Pero no te preocupes, puesto que de momento probaré con el que me he bajado, si me falla, ya lo diré por aqui.

Un Saludo, y gracias.

Pero el HiTech no permite assembler inline?

HiTech have full asm support

You can both use this

#asm
code here in asm
#endasm

or this

asm("ld a,(_myvar)");
asm("xor a");
asm("ld (_myvar),a");

Si que permite, de eso estoy seguro (solo tienes que mirar el fuente del Uzix). Por cierto NErlaska que le eche un vistazo a la version 7.5 que es cruzada y genera muy buen codigo, tengo el manual de la 7.8 y la 7.5 crackeada (PIRATAAAAAAAAA), asi que si  lo quieres

Recuerdo que en su dia Airam hizo unas librerias para el HiTech, aunque creo que las hizo para el GFX9000, no estoy demasiado seguro. Sobre librerias graficas aqui tienes una que he encontrado:

http://msx.jannone.org/


Ahi por ahi otra de un japo, que si quieres, pues tu mismo ...

Hombre .. yo es que ya tengo un capazo de cosas para SDCC ... y me da un poco de perrera cambiar de compilador pero cierto es que poder programar C directamente en MSX tiene su cosita.
Pero bueno .. si fueras tan amable de pasarme lo que tengas de HITech para MSX y para PC .. pues le echo un ojo que igual hago una conversión del código SDCC y lo porto también para HiTech.
Que me da que el HiTech generará mejor código que el SDCC seguro.

Para la version de MSX en uno de los mensajes anteriores puse el link.




El codigo generado por el sdcc no es demasiado bueno que se diga. Yo he trasteado con el interior del SDCC e incluso he hecho alguna tentativa de generador de codigo propio, y te puedo decir que el generador de codigo de z80 esta a medio hacer. El codigo para el envio de parametros por registro esta escrito a medias (por lo que lo tiene desactivado), yo he pillado un par de errores en el peephole y varias cosillas asi. El codigo del z88dk es bastante mejor, pero no permite el paso de parametros por registro y casi todas las funciones basicas las hace mediante llamadas a funcion (ya les vale), con lo que se pierde un monton de tiempo en llamadas inutiles.

Y ya que estamos...¿alguien sabría aventurar cual es el compilador que genera código más optimizado en cuanto a tamaño?, la velocidad o elegancia del código de momento no me preocupa demasiado...
El SDCC genera mucho código en mi opinión y de los otros no se lo suficiente como para poder comparar.

I use HITech cross compiler v7.80p2 (the shareware demo is complete of sources and support files. It lasts 30 days, but setting back the date....)

The reasons are that it passes parameters using registers, it can manage MSX memory mappers by itself, splitting code and data among the pages
and has a good manual documenting its features.

I think that the code is good, but a general comparison is hard.
If you post there a C segment
I can compile it and give you back the ASM it produces




 

I've just downloaded the demo from HiTech site :)

Right now I'm generating about 35Kb of code and adding the GFX+mapper code, it would become a nigthmare. I'll give a look and if porting is easy I'll try to compile the code with HTC.

About all that features, specially the MSX memory mapper support, are really ready out of the box or you need to adapt them more or less to be workable?. That splitting feature could be killing for me...

Por cierto, para los que se lo quieran descargar, hay que rellenar unos pocos datos; pero está disponible aquí:

HI-TECH C for Z80/Z180 (http://www.htsoft.com/downloads/getfile.php?sourcepage=demos&productid=33)

Cada día que pasa me convence más programar en C y no en asm, donde el código generado no es del todo óptimo óptimo... ;D ;D ;D

Hablando ahora en serio, C puede ser una buena alternativa al asm siempre que el código generado no introduzca un montón de instrucciones espúreas... ¡a ver si alguien se curra un buen generador de código!

¡Buf!, pues no te mires lo que genera el SDCC, se desperdician ciclos y bytes como rosquillas...:-(

La clave del uso en C es la portabilidad, algo hecho en C siempre podrás plantearte el adaptarlo fácilmente a otra plataforma, algo que en código máquina es algo más complicado (que se lo digan sino a Fudeba :o).

Claro que igual se puede hacer algo en C que entre en 2Kb... ;D

Several people helped to do some C compiler comparison at MRC. IIRC both Artrag and JLTursan contributed, as well as many other MSXers.

The original threads are these:

(1) C compiler comparison (http://www.msx.org/forumtopic7077.html)

(2) C compiler comparison - part two (http://www.msx.org/forumtopic7228.html)

Anyway, I doubt that any single C compiler will give the best solution whatsoever. Accepting this fact, we should look for the best overall solution or, perhaps, the one that provides higher flexibility.

I'd like to make some tests regarding application development in C. I still think that assembler is the way for games (although that recent productions show that C is an option too), but maybe C compilers can provide an affordable development time for applications without compromissing performance. Any views regarding this?

I doesn't really contributed too much, ARTRAG was the main tester. Most of the tests were speedwise, what about I'm really interested is in size optimizations (although with a good banking framework, the size is not so important of course).

Por cierto, cuidado con el enlace que he publicado antes, te descargas el compilador; pero luego pide un código de registro...¡que no veo que te proporcionen por ningún lado! >:(. No puede ser tan complicado, me debo estar liando con algo...

Hombre .. realmente en C se puede programar y bien .. cierto es que el SDCC no genera un código demasiado compacto/óptimo .. de hecho ninguna de las dos cosas :) .. pero no es tan importante la verdad.
De hecho en un juego tienes el motor hecho en assembler inline .. el que he usado yo para los juegos que he montado tiene soporte Bitbuster, Pt3, Psg, Scc, Opll, Vdp y herramientas por doquier .. y se queda en menos de 8kb. Luego ya viene el núcleo de los juegos que eso si es C puro y duro y ahí si se notan los bytes. Pero bueno, teniendo soporte multibanco tampoco es un gran problema.
Me alegra ver que se abre un nuevo hilo sobre el C y la gente piensa en el lado oscuro!! :)

Gracias, para mi la mejor opción.


Pues de momento me voy a quedar con la sugerencia de ARTRAG. Aunque ya me he descargado los archivos para echarle un vistazo.

Por cierto he conseguido por fin compilar mis primeros programas. Básicamente fuentes que ya tenía hechas y, perfecto. Quizás salen demasiados mensajitos mientras compila para mi gusto, más que nada por que no sé de momento que quieren decir.

Por último me gustaría que me recomendaras algún buen manual/tutorial o similar. Y por supuesto reiterar mi agradecimiento por tu información, has conseguido ampliar las posibilidades de mi MSX.


Yo también. Solo falta algún concurso opensource en C.

No te has planteado hacer alguna versión del AsMSX, aunque sea reducida, para MSX. Sería una buena opción para programar en ensamblador, indistintamente desde el PC o el MSX.

No hacerme mucho caso con este comentario. Todo lo que necesito (creo) está en la guia de usuario que viene comprimida en el archivo "z80doc.exe". Aunque admito consejos y detalle/s que haya/n que tener en cuenta, a la hora de programar con este compilador.

Bueno pues continuo con mis problemas MSX y el C.

He estado ensayando con este código, con ensamblador in-line.


Y el compilador me da los siguiente errores,
1.- EOF in asm
2.- Undefined simbol: endasm

De lo que deduzco, mirando el manual, que el problema "único" es que no reconoce la etiqueta "#endasm". Puesto que ambos errores están relacionados.

He mirado el manual de arriba a abajo (por cierto hay partes del mismo que no existen), y no encuentro el por qué de esto. Tampoco veo en las opciones de compilación que haya que hacer nada especial para que el compilador reconozca las etiquetas #asm y #endasm.

Si alguien me puede ayudar y decirme dónde me estoy equivocando. Se lo vuelvo a agradecer y prometo hacer un jueguecillo en C programado directamente en el MSX.

De Hitech no tengo ni idea; pero, ¿por qué no pruebas el método alternativo que comentó ARTRAG?

También lo he probado. Y el compilador no reconoce la instrucción asm(). De hecho en el manual no he conseguido encontrarla en la referencia a todas las funciones que soporta.

Solamente hace una pequeña mención en un apartado que ni siquiera está titulado, y dice literalmente esto:


Lo cierto es que me estaba atreyendo la idea de utilizar este C. Ya que el BDS es tan elemental que no te deja ni siquiera inicializar un array al declararlo.

Así que de momento me gustaría agotar todas las vias posibles antes de desistir.

He estado probando el compilador bajo el MSX-DOS1 y compila bien. No emite ningún mensaje de error. (El resultado de ejecutar el .com es un bloqueo total, pero bueno lo importante para mí ahora son los mensajes de error).

¿ Tendrá algo que ver que lo este usando bajo MSX-DOS 2.2, FAT16 y SD en la tarjeta de de Padial ?

¿ Existe alguna alternativa que me permita usar el compilador sin renunciar a la configuración anterior ?

If anyone is interested in some ready to go examples to generate msx roms in HTC v7.8, I could try to share the code of some projects.

I did a rom of 48K using the small memory model and a megarom of 512K using the SCC Konami mapper using the large memory model.

I would attach them here, but the forum does not allow upload anymore.

If anyone needs support in developing with the HTC I think I can help a bit, my experience at your service ;)

The first thing could be put 7.8 version in a site in which download it, because version from ht web ask for a code that I don't know where can be obtained. I have 7.5 version, and I don't know the diference with 7.8 version

do not worry
v7.5 and v7.8 are almost the same
if you need my samples send me an email, you can also use the address :  ragozini at gmail you know the rest

Indeed, seems that the 7.8 version can't be unlocked >:(. From where can be downloaded the 7.5 version?

if you do not have any fear of viruses google for

"HI-TECH Z80 Compiler v7.50 Demo"

But .. HiTech 7.5 or 7.8 .. have currently support? are there bugs known?

About version 7.8, it is currently supported. If you register on the site:
http://www.htsoft.com/downloads/log_in.php?productid=33&cookie_test=1&sourcepage=demos
you can ask for a free code key for a trial of 30 days, and join to an active forum of developers
(on the same site)

The demo v7.8 is complete and fully working.
After 30 days, you can :
1) buy the product and receive an eternal key (the compiler is exactly teh same you have been using)
2) set back the date of the pc and run it without problems

The demo of v7.5 comes in various crack (not all of them fully working) and is generally
missing of the sources of the libraries (this is a problem when going to magaroms, as you need to customize
a file to allow mapper support)

I can't find the exact place where you can ask for the code key. I only have found a place where they ask for a serial number which they say there is in the cover of the product ...

try here
http://www.htsoft.com/downloads/details.php?productid=33

You can download it after registering indeed; but the problem is that the installer has some kind of protection asking for licenses and keys. I've searched the whole site looking for traces of this key (or how to get it); but without luck.

A bit rough method; but I'm afraid that we'll need to ask manually (e-mail) for an evaluation key :P. I'll try to google some more time looking for info about the 7.5 compiler (although I'm getting fond of pr0n sites...).

Actually you need to ask manually a demo key to the sellers...
At least this is what I did.
My evaluation key expired in May 2005 IIRC... never the less I continue using it :-)

I have send them a mail requesting a demo key, and they don¡t answer anythink yet ...

Register your account first, download the product,
ask for the evaluation telling that you have found the product
and you are seriously evaluating to buy it as your company
will soon start and embedded project on z80
Use a bit of creativity  ;D

I register it 6 moths ago. I will wait a week or so, and if they don't answer me then I will send other mail.

It's hard to be a hobbyist... ;D

jltursan, does your email in the profile work ?

Sure! :)

Let me know if you succeed in using the compiler
In case, I can share some sample code to do roms of any size

They have send me the evaluation code. I hope do tomorrow some simple test tomorrow.

Bueno voy a seguir un poco con mi rollo autista dentro de este hilo.

Despues de la desilusion del Hitech v3.09 para MSX (nada que ver con las modernidades que estaís comentando) y la posibilidad de incluir código in-line, he vuelto a los origenes y estoy usando de nuevo el BDS-C.

He decidido hacer una libreria orientada a funciones gráficas para este compilador. De momento ya he conseguido hacer una (totalmente a mano, byte a byte, y desde el propio BDS)  con la funcion CLS con la que he estado dando la lata este tiempo. Y funciona perfectamente.

Así que ya lo tengo todo preparado, simplemente para ir añadiendo funciones en codigo objeto. Como el trabajo es un poco pesado me he propuesto ir añadiendo funciones de vez en cuando. Y de momento solo incluiré funciones elementales para el MSX1, tales como borrar pantalla, locate, vpoke y vpeek, mover sprites y definirlos, etc. cosas elementales de este tipo.

Si todo me sale bien, intentaré hacer otra para MSX2.

Y cuando la tenga hecha me gustaría, por supuesto, compartila con vosotros.

Que digo yo .. no te sería fácil hacer un programita que pille el código binario generado por un compilador asm y generar automáticamente los byte array del BDS-C?
Igual así irías más deprisa y podrías automatizar el proceso .. también de cara a mejorar o compartir código ASM visualmente más sencillo que un byte array.

Cuales son los problemas que has tenido exactemante?, yo en su dia lo use bastante, y quitando el problema del caracter EOF que meten algunos editores al final del fichero y que no le hacen nada de gracia al compilador, no tuve mas problemas.

Si, lo que pasa que para hacer las primeras pruebas me ha sido más rapido copiar directametne byte a byte.

De todas formas, creo que voy a montar la libreria directamente con el AsMSX, ya que es tan solo un archivo binario puro, organizado en 512 bytes de directorio de funciones, 5 bytes de intercambio informacion (linker-compiler) y el resto de funciones, que a su vez tambien estan organizadas (en fin, todo viene detalladito en su manual de usuario, por lo que es relativamente fácil).


Los problemas los comenté varios post atrás. Basicamente es la imposibilidad de poder usar las directivas #asm y #endasm, así como la funcion asm(), con el msx-dos2 ya que con el msx-dos1 va perfecto.

¿Y para eso no seria mas facil usar el propio ensablador del hitech y linkar los objetos?



Probare con las versiones que tengo y con los parches que hay, y ya te digo algo.

Pues eso, que ya lo he probado y acabo de enviartelo por correo. Ya me dices algo despues de probarlo.

Pues no me ha llegado. En mi perfil está mi correo, si no mandame un mensaje de estos privados que hay en el foro. Me gustaría seguir insistiendo con el Hitech-C.

Si me llego uno de JL (Gracias, por cierto) pero con el Hitech tengo el mismo problema, y con los demas aún no los he probado.

Por lo pronto, y para el que le interese, he cambiado de parecer. Ya no voy a crear la libreria. ¿por qué?

El uso de la librería tiene un inconveniente gordo a la hora de crear funciones eficaces. Todos los parametros de la función se pasan a través de la pila, y en función del tipo de dato que sea hay que recolocar el registro SP de tal manera que los pueda leer adecuadamente. Me refiero a tipos char(1 byte) o int(2 byte). Un rollo.

Por el contrario, la idea que expuse en mi primer post de este hilo, sigue siendo la idea que más me atrae. Porque usando las funciones call() o calla() me permite llamar directamente a rutinas en C.M. y pasar los parametros directamente a través de los registros del Z80. Por lo que la rutina toma el control directamente y sin perdidas de tiempo. El inconveniente que tiene es que hay que cargar las rutinas cada vez que se ejecuta el programa.

Las opciones que me estoy planteando son las siguientes:
- Crear un archivo binario puro con todas las rutinas en C.M., cargar dicho fichero en memoria (reservada previamente por el compilador BDS) y llamarlas mediantes las funciones call.
- O crear un archivo de cabezera .h donde incluya todas las funciones mediante arrays.

Ni que decir tiene que si consiguo hacer funcionar el Hitech crearía las funciones directamente en ASM.

Me rectifico, si me ha llegado. Lo acabo de recibir ahora mismo.

Gracias, lo probaré y a ver que tal.

Planteate esta otra:

- Escribir en un fichero una funcion del tipo:

char myfunction()
{
}


y decirle que te genere el asm con el switch -S. Asi ya tienes todo lo necesario para escribir directamente tu funcion.
Ventajas: el resto del codigo sigue siendo portable,
               No dependes de directivas tipo asm y demas.
               

Este es el metodo que yo usaba en 8086, ya que definir los segmententos y demas era un coñazo enorme, asi que le dejaba al compilador que hiciera el trabajo por mi.

Me apunto la sugerencia. De momento le estoy echando un vistazo a toda la documentación, sin duda mucho más completa de la que yo tenia (basicamente el "z80doc").