Quote:

Speed....MSX lacks speed... I think a new msx board with an eZ80 @50Mhz and a faster vdp would increase the software development. Okay...and some more colors, VGA-output for connetion with my TFT-monitor For € 200,- or less I would buy a new MSX if it's powerfull enough. How are you guys feeling about this..

I'd almost say: buy a PC (or PDA if you want to have a portable MSX) ;-)

Quote:

I'd almost say: buy a PC (or PDA if you want to have a portable MSX) ;-)

So...you want to stay in the past forever?

You don't want a new more powerfull MSX?

The ONLY way to keep the msx-system alive is to evolve the system.

With software but also with hardware.

A PC or PDA is not the same as a new backwards compatible MSX board with more or beter features.

Quote:

About a psg tracker: someone ought to make a moonblaster/mbwave/mbfm player that plays directly to the psg.. in that case it's up to the composer to use 3 square waves as reference sound. Making such a player is less work than a whole new tracker ^^;

But honestly I'd also love to use arpeggios, not to mention the noise-channel. Brilliant things can be done with the PSG, there are just so few programs that actually tap into this potential.
And if a new PSG tracker is to be useful, it should at least still run on a humble MSX1. Especially with all these new MSX1 projects it'd be nice to have some descent BGM for them.

Which reminds me, whatever happened to that new PSG tracker that was announced to be in development a while ago?

Was there a new PSG Tracker? I only know the existing PSG Tracker by Flying Bytes. Indeed, also for MSX1.

eZ80 sucks, we need a faster R800 chip.

Quote:

Was there a new PSG Tracker? I only know the existing PSG Tracker by Flying Bytes. Indeed, also for MSX1.

Well, the MNBIOs kernel got a tracker and a AY38910 driver inside, so "it is arm" and usefull by default. I full-test one time on 1998....

also I are anxious of finish the funcking routines than are stopping me the develop.

about "C" on mnbios, i read about a good C compiler than use the Z80 registers as part the input frame work, if that is true, so is very easy to program under C on mnbios, but what happen when a assembler routine called return several values in several register? how it work? i only remember a C= rutina()..... (my C programming is very newbie).

anybody can get any function from the mnbios manual than got several inputs and outputs and write here an example of how call in C to that routine?.... maybe starting from that i able to insert C lines on the programmer manual as examples.

why eZ80 sucks guyver?

coz it's not R800 compatible

Quote:

coz it's not R800 compatible

But I think that an eZ80 @ 50Mhz is faster then a r800 @ 7-10 Mhz, or not?

Are there any faster R800s available?

R800 @ 50 or 100Mhz should be suffient for running my crappy basic programs smoothly

A decent BASIC compiler would make your crappy BASIC programs run smoothly on a 3.58MHz Z80 too

KUN BASIC
actually, it would be nice if someone hacked it and made it possible to save the compiled forms of the BASIC programs (if it's possible at all...)

and compared to Z80, BASIC programs are flying on R800.

Quote:

A decent BASIC compiler would make your crappy BASIC programs run smoothly on a 3.58MHz Z80 too

You guys/girls don't know how crappy my basic programs are...hehehe...

But serious, if it was possible to implement a faster CPU and VDP wouldn't that create whole new possibilities?

What CPUs and VDPs are avialable and best suitable?
CPU:

Z80 @ 20 Mhz
R800@ 7 Mhz
Z180@ 33 Mhz
eZ80@ 50 Mhz
Some FPGA CPU?

VDP:
v9958 with Advram
v9990
FPGA VDP?

Are there any other options?

Advram is overrated. An OTIR is just as fast as an LDIR, so the only overhead there currently is when accessing the VRAM is setting the start address. For block moves (the big time consumers), that hardly matters. Only limitation is that you don't have random access, but then again, there's always HMMC as an alternative.

Usually when programming for MSX, you want to let the VDP do the big work with its commands, and let the CPU do other stuff like enemy calculation or whatever in the meantime. Only occasionally issue an interrupt to set a split, or set some registers/sprites... Well, ok, and when programming in screen 4 or so change some VRAM region for great effects.

And v9958 can do amazing stuff already by itself. I have not seen it used to its full potential yet (imagine what one could do with screen 10 + scroll registers + splits...), and certainly not commonly (because M-Kid came to mind ). Aside from scrolling and high-colour screen modes, it can also do stuff like use vdp commands in screen modes 0-4... When put to good use (it's a bit weird), can be very powerful.

And if you want real power, it's best achieved by more than just overclocking. Sure, the v9990's faster command execution is great, but its real merits are the pattern modes, planes, great sprites, command interrupt, overscan modes, built-in horizonal splits, etc.


~Grauw

I still beleive direct Vram access would be nice. I mean it's true that there isn't much difference between otir or ldir but if you need to make lotsa random access (read and write) at different point of the vram (say to do stuffs like bump mapping), the MSX way is a real pain in the ass. Here we have to prepare ALL the page in ram first and then only transfer it whereas on a stupid and basic machine like a Spectrum you don't need to do that last part. But of course this is not something u need everyday...

BTW, what's that thing about VDP commands in screen 0-4 ? Sounds like something I could use :-)