absolutely. Thats what's makes discussions interesting.

dvik, I think we can not get MORE on topic. To summarize my thread contributions and answer the topics title question: yes, it is an MSX. Why? Because MSX Association says so. Do we want to use this MSX? For me, the answer to this question is: no, not in its current form. It's inferior to my turboR. And it also lacks essential MSX2 specifications. With VHDL updates which are not authorised by MSX Association, the device loses its specific identity and you can't qualify the device as an MSX anymore. In short, the device is an MSX as long as MSX Association says it is. And they can change this MSX-specification with VHDL-updates. Smart move.

So, MSXA is the authority here. And the scene has no authority (be it a creative one instead of an official authority) ?

Actually I think any person or organisation can demand authority (the concept of mutiny ). Not that I'm such a pirate orso, but authority has to be earnt.

Actually, Tok, do you think the Moonsound and G9k are genuine 'MSX' things? If yes: do you see Sunrise as an authority? And what about Dumas?

Actually, I think we can ditch this issue by addressing another question:

Would you accept developers releasing products including their own VHDL, and restoring the old state upon quit?

If yes: then the above discussion about 'scene vs MSXA' is zippo.

They are MSX add-ons. With an MSX machine as basis. Authorised MSX machine.

I'm going to release Playstation4 next week. Awesome.

Quote:

yes, it is an MSX. Why? Because MSX Association says so.

This is indeed imo the only valid reason to call the OCM a real MSX. But it doesn't mean it is a real MSX as in not emulated. Its real in the sense its officially approved but I strongly believe that how approved it is, its still a hardware emulation of a real MSX. I think this is really part of why this discussion can live. Its all about the definition of 'real MSX' vs 'emulated'.

I think there is nothing that says the OCM can't be a real MSX which is emulated in VHDL.

Quote:

Actually, I think we can ditch this issue by addressing another question: Would you accept developers releasing products including their own VHDL, and restoring the old state upon quit? If yes: then the above discussion about 'scene vs MSXA' is zippo.

yes

Quote:

Quote: yes, it is an MSX. Why? Because MSX Association says so. This is indeed imo the only valid reason to call the OCM a real MSX. But it still doesn't mean it is a real MSX as in not emulated. Its real in the sense its officially approved but I strongly think that how approved it is, its still a hardware emulation of a real MSX. I think this is really part of why this discussion can live. Its all about the definition of 'real MSX'. I suppose there is nothing that says the OCM can be a real MSX which is emulated in VHDL.

Indeed the only valid reason. And I don't care about that parallel, non os-based, 1chip circuited or emulated-blablabla.... It's not relevant. Question is: do we want to use this device which is being labelled 'MSX' by the authority.

I mistyped the last statement in my last post so I repost it here for clearification:

There is nothing that says the OCM can't be a real MSX which is emulated in VHDL.

I.e. the OCM can be both real and emulated at the same time.

dvik: I agree completely.

Quote:

Question is: do we want to use this device which is being labelled 'MSX' by the authority.

This is indeed a very interesting question. I posted a new topic with this (or a very similar) question here

What if I replace the MSX VHDL-code with ZX-81 code and draw a Spectrum logo on the OCM? Is it still an MSX?

One question, single question ...

OCM "emulates" *real* VDP9938 timings? And Z80?

Example:

If in MSX1 you send data to VDP without waits, VDP crash...

outi
outi

in NO VBL time, crash

If in MSX2 you send data to VDP without waits ... VDP crash

out(98h),a
out(98h),a

in NO VBL time ... crash ...

TurboR machine make waits automatic for compatibility in R800... well...

But I'm a coder. If I want that my programs run fine in ALL MSX family, if is MSX1 programs, I use correct waits ... If is MSX2 I use correct waits ... and the programs are really 100% compatible with all MSX.

If I send data to OPLL, I do waits if use R800 ...

Is this necessary in MSX Emulators (openmsx, BlueMSX) ? NO. Is this necessary in OCM? I guess ... no. And this is BIG problem.

Problem for new coders with only OCM machines, or emulators.

Please ... see DEV programs ... Some programs crash in REAL MSX1. Whats the problem? Use emulators.

And this is bad new for MSX users.

From the topic of the thread ... is OCM real or emulate MSX.

Well... is a MSX, ok. But is this new MSX is the new platform for the new users, MSX can have problems with new soft. And I want PLAY and USE new utils or new games in my "old" MSXs ... and in my new OCM.

The discussion is stupid. I suppose that this discussion is the same discussion when new Turbo R machine, appears in the market ... 15 years back ... Is Turbo R a new MSX ?

If you want use OCM, use OCM. If you want use old MSX machine, use old MSX machine. But, please ... make your programs 100% compatible.

Quote:

What if I replace the MSX VHDL-code with ZX-81 code and draw a Spectrum logo on the OCM? Is it still an MSX?

If MSX Association authorizes your ZX-81 code and your beautifully drawn Spectrum logo and labels that as an MSX: yes, it is an MSX. Point proven. Thank you, tfh.

Quote:

Quote: What if I replace the MSX VHDL-code with ZX-81 code and draw a Spectrum logo on the OCM? Is it still an MSX? If MSX Association authorizes your ZX-81 code and your beautifully drawn Spectrum logo and labels that as an MSX: yes, it is an MSX. Point proven. Thank you, tfh.

MSX-A must of course call your device an MSX, but if they do it sure is an MSX (still emulated though )