What kind of coding tools do you require? (Development Foros MSX)MSX Resource Center MSXdev 2008 - MSX1 development bonanza!           
                       
English Nederlands Español Português Russian                  
 Noticias
   Página principal
  Almacén de noticias
  Temas de noticias

 Recursos
   Foros MSX
  Artículos
  Analisis
  Informe de ferias/RUs
  Álbum de fotos
  Ferias y encuentros
  Encuestas
  Enlaces
  Buscar

 Software
   Descargas
  Tienda Online

 MRC
   Quiénes somos
  Únete a nuestro equipo
  Donar
  Políticas
  Contacta con nosotros
  Enlázanos
  Estadísticas

 Buscar
 
  

  

 Login
 

Login

Contraseña




¿Aún no tienes una cuenta? ¡Conviértete en miembro del MSX Resource Center! ¡Únete a nosotros!.


 Estadísticas
 

Hay 119 invitados y 4 miembros en línea

Eres un usuario anónimo.
 

Foros MSX


Foros MSX

Development - What kind of coding tools do you require?

Ir a la página ( Página anterior 1 | 2 | 3 | 4 Siguiente página )
Autor

What kind of coding tools do you require?

pitpan
msx master
Mensajes: 1368
Publicado: Diciembre 19 2006, 20:48   
Mmm. This topis is about what coding tools you requiere, not about what coding tools you are currently using.

I'd say that I'd like to have WAV support in BlueMSX. For me, a good emulator is the BEST coding tool. openMSX does support WAV and it works pretty well, I should say, but the debugger is not as handy as BlueMSX's one is.

About coding tools, I'd like to have a central repository of assembler routines and/or snippets for different tasks. Something more dynamic than MAP, perhaps a Wiki.
manuel
online
msx guru
Mensajes: 3381
Publicado: Diciembre 19 2006, 22:14   
pitpan, did you try the GUI debugger for openMSX, which is still unreleased, but already usable?
shaiwa
msx addict
Mensajes: 287
Publicado: Diciembre 19 2006, 22:25   
For now i'll like TniAsm but i wish it has a nice GUI (for win32) and a build-in hex editor.
What would be really nice is a very good C editor/compiler for win32 for cross-development that can compile fast code for our beloved MSX machine.

manuel
online
msx guru
Mensajes: 3381
Publicado: Diciembre 19 2006, 22:37   
@shaiwa:

Do you realize that an assembler doesn't need a GUI? It should just assemble. You do need a good editor and you also seem to need a good hex editor. I think you can find plenty of free programs to fulfill your needs with that.

Also, for C there are loads of good editors. A compiler is the interesting part, which was discussed before.
msd
online
msx professional
Mensajes: 608
Publicado: Diciembre 19 2006, 23:00   
UltraEdit is very nice editor, contains all you need. You can even use regualor expresions so it can list labels for you. Too bad it's not free
shaiwa
msx addict
Mensajes: 287
Publicado: Diciembre 19 2006, 23:42   
@manual:
I know that, just want to get rid of the dos box also i've got lots of hex editor to chose from.
The problem is that there are no all-in-one proggies out there... hey we're talking windows here
About the compiler i agree, but if may wish i wish it all

@msd:
There are risky site's out there but if you want it for free ......... astalavista baby
(be sure quad check and double check you're system afterwards )

Alcoholics_Anonymous
msx friend
Mensajes: 10
Publicado: Diciembre 20 2006, 08:37   
Quote:

A very good optimizing C compiler targeted for MSX would be nice. I'm not sure about z88dk, but it looks like it's a candidate. Optimizing is a key thing. Oh, and it should be free software, of course
(We did some C development for MSX and testing it right away with an emulator is rather comfy!)



None of the C compilers can generate "good" z80 code, as in code that would look anything like what would be written by hand by a competent z80 assembler programmer. When going after execution speed (eg in the main loop of a game), the quality of libraries is most important -- they should be written in assembler and they should be "close to the surface" so that C is really only used to provide the glue for executing sequences of hand-assembled functions. At other times, when the execution time doesn't matter, everything can be in C and it doesn't really matter what the quality of C-generated code is (they're all similar, with some generating better code in certain circumstances and others in other circumstances), except perhaps compactness should be emphasized.

One thing that would be very popular is a global z80 code optimizer that could take as input assembler files and spit out something optimized; this would be able to go a lot further than any kind of optimizer built into the C compilers as they are constrained by the kind of code their code generators can emit. This would be quite a difficult project though.

[D-Tail]

msx guru
Mensajes: 2994
Publicado: Diciembre 20 2006, 09:42   
Besides that, the code optimizer can't just mock around code; it has to respect ordering in terms of disabling/enabling interrupts and pushing/popping registers. Although in general I think many optimisations are doable, such as replacing "ld a,0" with "xor a". However, the latter changes flags. So euh... it's quite difficult I guess
manuel
online
msx guru
Mensajes: 3381
Publicado: Diciembre 20 2006, 10:35   
shaiwa: you don't want all in one, you want perfect stand alone programs that can be glued together easily to create a perfect workflow

I think MSXPad or Chaos Assembler did something like this. Use very good commandline tools and glue them together. THe user won't notice it.
madcrow
msx lover
Mensajes: 68
Publicado: Diciembre 20 2006, 15:29   
I'm currently quite happy with MSXpad, but I'm stuck with text until I can find a good guide/tutorial to the libraries included with it.

High-level stuff for SymbOS would be great as well.
wolf_
online

msx legend
Mensajes: 4663
Publicado: Diciembre 20 2006, 16:13   
Quote:

such as replacing "ld a,0" with "xor a". However, the latter changes flags. So euh... it's quite difficult I guess



I'd say that's not something to automate. A coder still must do *something*..

What might be more fun is to incorporate the things that are common in C64 demo's: draw images without any loops, just directly put the whole image-creation code (for each pixel!) in RAM and perform it.

Something like: (exqueeze me my lack of asm-skills )

LD A,15
LD (0000),A
LD A,15
LD (0001),A
LD A,12
LD (0002),A
LD A,3
LD (0003),A
LD A,3
LD (0004),A

etc.

Now, this may look like a silly way to fill a piece o' RAM (and I'm not sure this actually works, since our VRAM is not shared), but this is how those C64 geeks do their stuff! (Of couse, this code is then generated) They argue that this is faster than nesting one such an instruction into a loop and add code into the loop to change the write address.. at the cost of RAM.

So, I don't exactly know how, but perhaps these kinda odd tricks could be automated!
[D-Tail]

msx guru
Mensajes: 2994
Publicado: Diciembre 20 2006, 16:26   
Disadvantage to this approach is that you'd need more memory for your code. But it may be handy sometimes, too
AuroraMSX

msx master
Mensajes: 1231
Publicado: Diciembre 20 2006, 18:07   
Quote:

UltraEdit is very nice editor, contains all you need. You can even use regualor expresions so it can list labels for you. Too bad it's not free

Then have a look at Crimson editor - almost the same feature set as UE but free!
[D-Tail]

msx guru
Mensajes: 2994
Publicado: Diciembre 20 2006, 22:34   
NotePad++ does the trick too
manuel
online
msx guru
Mensajes: 3381
Publicado: Diciembre 20 2006, 22:58   
gvim rules
 
Ir a la página ( Página anterior 1 | 2 | 3 | 4 Siguiente página )
 







(c) 1994 - 2008 Fundación MSX Resource Center. MSX es una marca registrada de MSX Licensing Corporation