Quote:

dvik, December 11 2006, 18:59: Quote: Not nescessary plain logical, but useful, at least. Yes, you've got it: You can e.g. design a processor for a special purpose with only the insturction set needed for that special task, leaving space for further extensions Youre on really thin ice Tanni. It is very easy that you loose the MSX soul in the OCM if you start tweaking and improving the core characteristics of the MSX, such as the V99x8 or z80 instruction set.

Dvik, read again what you've quoted from my text. I wrote about a special purpose processor with special instruction set for a special purpose. This was intented for implementing additional functionality, not for replacing the Z80, of course. The OCM is a system on a chip, the MSX system, consisting of the Z80 processor and the special purpose processors VDP, PPI, and PSG. So, if there are USB ports on the OCM, and I we don't want to extend e.g. the PPI (this means the VHDL code of the PPI), we need to add some VHDL code to access these ports. But that isn't enough: We also need to implement the USB protocoll, which might be too performance consuming to the Z80.

To add e.g. a special purpose processor for USB management, we would like to restrict the affect on the system necessary to the smallest amount, using techniques already used in the MSX standard. Such a special purpose processor also hides implementation details and allows improvement without affecting the software support needed. We only have to define a new device, saying that from now on some already reserved port adresses are for USB device access and add some new BIOS calls dedicated to USB support. Thats the way MSX can be extended in a totally standard manner.

Quote:

I promise you that only a handful of people will be interested in developing, testing and playing with cool FPGA features (I am actually one of those that is interested so I'm not opposed to the idea). Problem is that noone in the MSX community will be intereseted in a pseudoMSX3 based on some sceners wet dreams. So that said, I can think of many cool improvments. Here are some, many more to follow: * Wider address bus (e.g. 20 bit) with extended registers, e.g. xhl * multiple plane support in the VDP, so you can do semi transparent overlays * Memory mapped VRAM * An extra accumulator register in the Z80 * div instructions * floating point unit * overclock the VDP command engine (like current OCM) All these suggestions are 100% backwards compatible with the TR, so all (99%) of existing MSX games can be played

Maybe only a few people will be interested in development. As I understood what Kay Nishi said, we are invited to develop on the OCM by our own. He wants to promote developing on OCM done by the users. There must be dicussions on what kind of development will be appropriate for future MSX versions, of course.

The ''cool improvementns'' you mention also change dramatically the core characteristics of non tR MSX, as these are extensions to the Instruction Set Architecture (ISA) of the Z80 and the special purpose processors building up the MSX system.

TR is only one way for extending the MSX standard, others also will be possible, so the MSX standard could spread out like the twigs of a tree. The core would be MSX1, MSX2, MSX2+ respectively. Why shouldn't these different twigs have its own kind of MSX ''soul''?

Quote:

Tanni, indeed, with structure I mean 'coordinated development'. The scene IS small, there should not be various groups developing the same updates. And I also agree with Wolf as well: the war will not be based on the quality of ones code, but more on 'what makes an MSX'. And again, I see NO structure in all this. WE SHOULD ACT NOW

If there are only few developers, at least now and in the near future, some kind of structure (organisation?) will not be necessary. It sounds good but leads to administrative overhead. Kay Nishi intented to raise interest for developing on the OCM and for hardware design on FPGA in general, so we should start as we did in the early 80th with software development. We should differentiate between professional development for updating the OCM and hobbyist development for learning hardware design as intented by Kay Nishi. Sooner or later, the latter may also lead to professional updates to the OCM. With the PC goes on in becoming faster and more complex, it'll be a gap between some small and low power applications and PCs. Development based on MSX or other retro systems may fill in the gap. Compare it with the upcoming of the gameboy.

The quality of the code also depends on the synthesis tool used and the amount of ''effort'' it made. What makes an MSX is quite clear as far as the classical MSX is concerned. What should be a future MSX based on the OCM could have been discussed in deep in the last few years. There were such discussions, yes, but they didn't lead to a reasonable result, as far as I see. That's maybe why we still think of ONE standard (actually, there are four, at least), defending the ''soul'' of MSX, longing for the old days of early computing and gaming etc. Doing so is ok, but should not lead to be not interested in new developments or new opportunities as FPGA or VHDL. The ''soul'' of MSX is what we put there by our own. With the OCM we have the chance to do so more than ever.

Is there a reason things should stay backwards compatible? MSX has always been forwards compatible! Somehow people seem to be hesitating to work with different configurations. What about two configs:

[MSX1 MSX2 MSX2+ tR <additions>] (these additions include G9k, Moonsound, USB etc. etc.)

and

[MSX3 ? ? ? ?] (the most ideal MSX designed today, no gates wasted on chip artifacts etc.)

Best of both worlds I'd say, the first config allows you to play any of the games 'n demos we already have. The second config is simply the nextgen MSX, that doesn't have to be compatible with the first config. The issue ofcourse is how to design this new MSX3 in line with the MSX philosophy. But then again, I already posted the question 'what defines MSX', and that's still a bit unclear.

MSX1 more or less is like a spectrum, Z80, TMS etc. not entirely, but comparible.
What made MSX2? The V9938 I'd say, and that makes it hard to compare with other systems. The rest? Comparible with other systems.
What made the MSX2+? The V9958, which is more like a photochip than a gamechip (apart from the scroll registers). And most MSX2+'s had the MSX-Music built-in, for the rest, nothing notable.
What made the tR? All the MSX2+ things + the R800 + the PCM, the rest -afaik- was already available as option for 2 and 2+ (MIDI, RAM, DOS2)

So, the way I see it: only the videochips made MSX, perhaps a bit o' sound, since other vintage computers had 3-chn chips (SID, PSG), or 4-chn PCM (Amiga). Tho, a PC with a Soundblaster would be comparible with an MSX and MSX-Audio again. (and perhaps MSX-Music, but I don't know whether Soundblasters had more than only a sine for their waveforms)

So, if the real difference between MSX and non-MSX are the videochips (38 and 58) used, then it means the rest could easily be souped-up already, nothing uniquely MSX to loose here. What's left is that videochip which mainly caused quite some pain due its slowness.

2ct.

note: I'm not entirely sure whether I mixed up backwards and forwards compatibility here Ohwell, you get the point: MSX1 software runs on MSX2, but not the other way around..

Quote:

And again, I see NO structure in all this. WE SHOULD ACT NOW

We should not ''act'' that fast, we still have time until that kind of decisions should be made, if at all. Time will show!

Quote:

Ps: One note about dynamic configuration (I have seen some ideas around dynamic configuration in several messages): It is possible to load a new configuration into the configuration device contained in the OCM. However, the FPGA only reads the configuration device on power-up. Not on a software reset, not on a hardware reset. Only on power-up. So if a game needs special hardware support in the FPGA then the user must first load the hardware configuration into the configuration device. Then power-off and power-on the OCM and only after that, he can load the game. Obviously, this new hardware configuration should still support loading another configuration (like the original one) from the SD-Card.

So it is not runtime reconfigurable? What does it mean that ''Obviously, this new hardware configuration should still support loading another configuration (like the original one) from the SD-Card.'' Does it mean that the original configuration can only reconfigurated at power up, but the newly loaded hardware configuration still supports loading another configuration at any time?

just chiming in from a user perspective, not a developer, so shoot me if I'm talking nonsense.

IMO, there's no real need for 100% compatibility in an "MSX3". You can always flop back to the "default" MSX2.
Id' like to see:
- real performance gain, say a relative speed of 20-30x native Z80 (66MHz sounds good)
- faster VDP (also about 20-30x current 9938/58 VDPs)
- screen modes.. here's the nice bit. For "future proofness" a resolution options of 480p (maybe 576p for PAL?) and depending on performance maybe 720p (although this may be too much?)
- 16 bit colors (ok, maybe 24 or 32, but only if it's not eating to much slot space in FPGA)
- internet capability! i want to check websites, email with my OCM (this is of course also s/w related, but the h/w should be prepared as well)
- SymbOS collaboration! make this beauty the default environment for the next MSX!

wrt performance, I'd prefer focus on raw performance than technical features like multi-planes.

anyway, from a (stupid?) user perspective

edit:
Bazix, D4E, and MSX Association should define a standard for the next MSX. It will then up to the developers to develop this. imho this would be the only real, visionary step to a new standard for MSX

Sounds quite good, Hydlide! We need fresh opinions here.

Quote:

Bazix, D4E, and MSX Association should define a standard for the next MSX. It will then up to the developers to develop this. imho this would be the only real, visionary step to a new standard for MSX

I would like the MSX users define the standard for the next MSX systems by themselves. There must be discussions on that issue, and it will take some time. We need not come up with that in a few month. It also will become ''difficult'' to define such a standard when hardware can be changed by reconfigurating the system.

It's clear that there will not be ONE standard anymore, at least not in the classical sense of the word standard. What we need is a standard to administrate standards.

The next MSX is the OCM. To my opinion, it's an intermediate product to test the capabilities of FPGAs. A future MSX3 standard should not based on the OCM. It's too restrictive. New FPGA devices will have more CLBs, will be runtime reconfigurable, even in parts. So, an MSX3 standard should also be independend form the actual FPGA platform used.

An MSX3 need not be compatible with MSX standards lower than MSX3, as long as it is possible to achieve this compatibility by demand, either envoked by the user or by an application program or game. I would like this to be called MSX1-, MSX2-, MSX2+-, MSX tR-, or OCM-coherent respectively, according to cache coherency: Coherency is consitency on demand. So, an MSX3 system is MSX1 coherent if the MSX3 can be reconfigured to behave like an MSX1 by demand. An MSX2 computer is always compatibel with an MSX1 machine, but an MSX1 coherent MSX3 computer would not be always MSX1 compatible, possibly never.

Was ZX81 compatible to the ZX80? Was ZX spectrum compatible to the ZX81, and most important, was Sinclair QL compatible to the ZX spectrum?

With FPGA, we are able to maintain compatibility without the need of being compatible all the time.

Hydlide: you are not talking nonsens at all.

- VDP+CPU speed gain should be indeed 20-30x
- Implemeting HD resolutions is a very good idea!
- SymbOS should be the standard for the next gen MSX!

But the MOST IMPORTANT part is that Bazix, D4E, and MSX Association defines (with input from the msx scene) a new MSX standard and also defines the needed development phases/steps. They should also define several teams like VDP development team, CPU development team, etc..each theam should have PM/leaddeveloper and developers. If someone want to participate he can contact then a PM.

Apart from the, say, 'game'-related things hydlide mentioned, I'd like to take these ones apart:


- internet capability! i want to check websites, email with my OCM (this is of course also s/w related, but the h/w should be prepared as well)
- SymbOS collaboration! make this beauty the default environment for the next MSX!


They're somewhat related I think, but in the first place it's about that internet point alone. It's just that I know internet from running inside a browser, and this browser has these GUI looks which SymbOS also has.

I ask myself: why browse/email the net with the OCM? I can imagine multiplayer-games over the net. But browsing/mailing? And it's not whether the OCM is capable enough (no doubt it will, esp. when taking SymbOS into account), but whether ppl really want to do their Office stuff on their OCM, rather than on their PC/Mac.

My point is mainly about whether people want to proof something "look, my MSX can browse the net" vs doing something that 'will be used'... Uhm, I mean: if a coder can choose between making a browser/emailclient, or make a game.. by all means: do the game! Rather a game to play than PC-software to pimp around.. (all imho)

3ct

Quote:

I ask myself: why browse/email the net with the OCM?

The OCM could be the brain or terminal in your home entertainment system. In both cases its nice with a TCP/IP stack and Internet so you can browse for TV programs for example. Also it is nice if you have a PC server with all your apps that can be easily ftp'd into the OCM.

could be .. but will be? How many people *will* do it like this if it would be available?

The OCM could be the core of a cheep, lightweight, mobile system with wireless internet access . . .

Like my notebook, so to say ^_^

Was your notebook that cheep?