Quote:

gvim rules

Emacs!

:1,$s/emacs/vi/g

Quote:

:1,$s/emacs/vi/g

(This won't catch Emacs, only emacs... :%s/[Ee]macs/vim/g)

To be honest I never used Emacs(Esc-Meta-Alt-Control-Shift). Hm, the only Emacs cmmand I once knew was how to get out of it, but I can't even remember that atm (Alt-Q, X or sumthn?)

I just can't understand why some people drool over VI(M). The program as a whole is utter crap; even cursor movement needs loads of complex commands. For a text-mode text editor, I prefer NANO. Maybe less powerful, but understandable

well, I'm not an MSX developer perse (although I used to be a developer), but I'd be tempted to get into MSX coding if:
- a decent recent-status compliant c/c++/objC compiler/linekr environment (gccMsx! ) with full MSX layer integration (without weirdo assembly calls)
- editor like subethaedit on Mac .. with collaboration possibilities
- symbOS integrated IDE.

or:
- complete MSX basic extention to allow for real exception handling, functions and some multithread/tasking without falling back to assembler. Check e.g the IS-basic, which is much better in this respect.

Quote:

({-Tail on vi): even cursor movement needs loads of complex commands.

Complete and utter bull crap. Just use the cursor keys, page up/down etc. ...
But vi/emacs/nano bashing is a weeny bit off-topic here. Let's just

* pixeled the A-Team and the RNFF .. what have I done ^_^

Quote:

well, I'm not an MSX developer perse (although I used to be a developer), but I'd be tempted to get into MSX coding if: - a decent recent-status compliant c/c++/objC compiler/linekr environment (gccMsx! ) with full MSX layer integration (without weirdo assembly calls) - editor like subethaedit on Mac .. with collaboration possibilities - symbOS integrated IDE. or: - complete MSX basic extention to allow for real exception handling, functions and some multithread/tasking without falling back to assembler. Check e.g the IS-basic, which is much better in this respect.

Are you talking about Windows or about MSX? Problem is that YOU DON'T NEED all those things for MSX development. *ANY* tool does the trick. Only knowledge and time are requiered.

Quote:

Are you talking about Windows or about MSX? Problem is that YOU DON'T NEED all those things for MSX development. *ANY* tool does the trick. Only knowledge and time are requiered.

yeah, well, if everyone still thought like that we'd still be using punchcards for programming, because "who needs a decent development environment, I can do everything with punchcards, only knowledge and time is required".

Good point, Hydlide. I'm not against progress and I had coded my own crossassembler and PC tools for MSX development. But the problem is that MSX does not have enough memory or processing power to waste it. Therefore, direct C development with long libraries and no embedded asm, produces big an unefficient code. Maybe a better optimizer could do the trick. I don't know. But at the moment, stick to pure asm or C+asm combinations.

By the way, has anyone coded a game using MS-Cobol for MSX !?

well, the OCM gives some perspective regarding memory etc but yes, an efficient linker/optimizer would be needed. However, a cross development environment on windows (preferably mac OSX though, or multi platform a la gcc) which produces efficient Z80 MSX binaries could be nice.. with a high level language like C of course.

cobol? hmm, i still have it for MSX.. but KUMA Forth was much cooler although Forth can hardly be called a high level language compared to other langs

Quote:

By the way, has anyone coded a game using MS-Cobol for MSX !?

The right tools for the right application. COBOL is not the right tool for an MSX game, I think...

Then, let's say BrainFuck!

I've used the MS-DOS EDIT.COM for 98% of my coding for a dozen years. For assembling z80 code I'm using Pasmo but it doesn't support any unofficial z80 instructions which is somewhat annoying. The debugger that blueMSX has now is pretty good.

I'm a MS-DOS EDIT.COM addict too! I code EVERYTHING with that editor.