Actually I don't expect I'd develop much MSX1/2/+/tR stuff on the OCM. I'll prolly carry it around to fairs/meetings to fiddle around a bit with MBWave orso, as it's so small. But I think I'll prefer to make real dedicated OCM software on it, with an MSX background that is. So it won' be far off, but even if I use a modification that allows more than 8 (or 16, G9k) sprites on a row, then it already doesn't work on whatever MSX. It's so easy to modify it a slight bit and make it completely uncompatible. To think that the OCM will stay like a conventional MSX is a bit naive I think. If the machine is to stay as an MSX2 then why do we bother ordering one? We already have an MSX2 or better.

Try to think about stability / compatibility. Focus on the following case:

I code an MSX game.

I test it in different configurations and different generations: MSX, MSX2, MSX2+, Turbo-R, 50 Hz/ 60 Hz, Z80, R800, 16 KB RAM - 4096 KB RAM, MSXDOS, MSXDOS2, disk, CF, IDE, with/without SCC, with/without internal/external FM, etc. It is a real PITA, but after that, I have a reasonable certainty about its compatibility in ALL MSXs.

Now try to focus on the change that implies the upcoming OCM. I have to test my program in the OCM... But using which VHDL revision? Only the "official" one? Or all the *fixed* versions done by hobbists and users? Shall I include other featured VHDL cores / extensions? As you can see, testing and debugging becomes hellish with this mutating pseudo-MSX. Imagine that I used a *feature* of the original MSX, such as the 5th sprite rule. This pure MSX program will not work in a *fixed* OCM with no 5th sprite rule.

As you can see, the main problem is that standard becomes less clear: you can upload whatever into the frankenOCM. But there is no way to verify that the result is an MSX. Or, at least, a reliable MSX.

The do-it-yourself VHDL way does smash the idea of a software compatibility standard, the only reason behind the MSX standard as we know it.

@pitpan: I don't think you need to test your games on the OCM. If the OCM or a certain VHDL revision doesn't run your game its because the OCM is not compatible. Its the same thing as if your game don't run in an emulator.
There is also a problem with forward compability. Say you do a game and verify it runs well on all MSX-A approved VHDL revisions, its no guarantee it will run in future revisions. This is however not so unique, and has been an issue with all MSX generations.

As MSX1 developer, I cannot assume that my games will not work on higher generation machines, because I know that nowadays most users have at least an MSX2 (only). Of course that one MSX1 device as the cassette is not available for Turbo-R computers, but the program at least should run properly on such machines.

The same goes for the OCM. Or shall we include a Non-OCM-compatible ban and/or a nice list of VHDL core releases and known compatibility issues?

"This game works on any MSX computer except the OCM VHDL core releases 1, 1.01, 1.02, 1.10, 2.01 and 3.xx."

Senseless.

We are retro guys. Asume it. Let's be obsolete forever. The OCM is new obsolete hardware. I prefer the vintage obsolete hardware. If my MSX is obsolete it is because it is now 20+ years old. If the OCM is obsolete today, it is because it has a poor design and very low specs.

It is not as powerful as a real Turbo-R is, and the Turbo-R was produced 16 years ago. What about the technology gap? It clearly does not follow Moore's law

Moreover, it fails on different MSX concepts:

(1) Machines with Software eXchangeability (MSX in one of its accepted meanings)

> Even software interchange between OCMs is not granted due to the VHDL mutability!

(2) Target on home computing

> Who would use it as a home computer?

(3) Good value for money - low specs at low price

> Using CPU speed, if the OCM can run at 10 MHz, its price is more or less 24 € / MHz. Asuming this as a fair speed / price ratio, try to determine the price of a low end PC running at 3 GHz -> 3,000 MHz x 24 € = 72,000 €. Not a bad price, uh?

Anyway, I must admit that it is cool gadget, but not a useful one. At least, neither for MSX gamers nor for MSX developers. Just for nostalgics? For avid MSX collectors? For MSX freaks and geeks? For ultimate Metal Gear fans that want to run their $300 Solid Snake rarity?

Quote:

Well, we do accept it from many other products. Firefox comes with security flaws that need to be upgraded, operating systems having bugs that you get automated updates for, etc etc. what is the difference with an OCM that you get upgrades for? only difference is that MSXA / Bazix do not claim the OCM's default config is flawless... now we start going upset they are honest?

Well, I'm a Firefox user. And I know it may have bugs. But I don't complain. I believe that, if you got something for free, you should be grateful. In Firefox's case, I'm fully satisfied with it, I never found a bug in it, so to me, it is perfect. And the updates are also free. The same applies to both OpenMSX and BlueMSX. They are so good that I wouldn't bother paying for them if they were sold. Too bad I'm not a C++ coder, otherwise I would for sure help any of these projects to get better and better.

OCM is not free. One has to pay for it in order to have it. If I buy a new TV from Sony, and it is not working perfectly, I'll demand it to be fixed or I'll require to receive my money back. Why it has to be different with OCM? They are doing it for the money, and there's nothing wrong with making money with OCM. I work at a university for the money too. If I don't give my boss my best work, he will fire me. Why can't I expect OCM to be a good product in exchange for my money? Should I just be grateful to MSXA for making it, regardless of its capacity to run my old msx software or not?

Quote:

in the end i guess it is all just reflecting the resistance against progression. like it was said before, some people like that they are important in the MSX community. in the MSX community you can gain fame by making a simple tile game, by making an expansion card that runs on 3.5 mhz, etc. So if it looks like the whole stable old MSX thing is going to be shaken up a lil and new things will come it means directly that some people could loose status. all of a sudden you need to know VHDL, all of a sudden the hardware expansions might not work anymore, or they might become programmable extensions even (yikes), and the worst of all: someone (MSXA + Nishi) showed they still have the power over MSX that some people thought they had. isn't that a cold shower situation?

Well, I can't speak for other people, but that's not what I want. If you see previous posts from me about OCM, one of my requests was that OCM bring at least some features that my old msxes don't have, for instance, at least a 25 mhz z80, or a new screen mode with multicolor sprites (1 color a pixel would be nice). I would be happy with OCM even if it couldn't run all my MSX1/MSX2 software. I don't need a 1 ghz 32 bits z80 or a gforce video card in OCM. I already have a PC for that. But to me at least, a 3.5 mhz z80 is not enough anymore. Softwares like SymbOS would be a lot greater than they already are if Prodatron had an OCM with features like the one I described above. This is exactly why OCM does not appeal to me: All it does is emulate an old MSX2 and it does not do well. From that point of view, my old MSX2+ is more advanced than it. And before anyone say: "Get the VHDL and do whatever you want", remember that not everybody in this comunity want to modify the VHDL code, there are those who just want to play with OCM, and not fixing/improving it. I understand OCM is really cool to those VHDL coders out there (and I even showed the MRC webpage with the news about it to the university where I work. I said to my boss that OCM would be great as a kit to our students in the hardware classes in computer science), it is just not great for those (like me) who don't find building hardware using VHDL a cool thing. Sorry.

Quote:

Quote: It is amazing people can be negative about the device itself, indeed. It is very retro, it has strong connections with MSX. You wonder what's the problem here?! Quite sad to see these negative feelings all come down to controversy, envy and doubt..... There simply isn't another reason to dislike the thing. I think most negative reactions is not about the device itself. If the OCM becomes 100% compatible with MSX2 (or other) I don't think anyone would be negative. Apart from a nice form factor, the OCM has several nice features that improves MSXing, but from a developers point of view it simply isn't accurate enough atm. I really hope this will change and I'm sure many people will help with that effort.

Exactly. If you read my previous post (the one that generated this comment) I clearly stated my preference for the beautiful design of OCM. And I welcome the flexibility of its FPGA approach. I just don't agree with a incomplete msx2 product and a policy that says that it's up to the customer to make the OCM bug free or enhanced with new features. Simple as that.

Quote:

Imagine that I used a *feature* of the original MSX, such as the 5th sprite rule. This pure MSX program will not work in a *fixed* OCM with no 5th sprite rule.

using a feature like a 5th sprite rule? what are you going to do then? monitor the 5th sprite to implement some kind of hacked line interrupt? if this is what you are talking about then i can't see how this is something in the MSX standard, since the standard did not specify when the 5th sprite detection was done and when the result was placed in the register. it only states that it is done at some undefined moment in time.

so if you are talking about a hacked VHDL version that does not implement the 5th sprite, no one would blame you if the code relied on hiding sprites by putting 5 in a row and it would look odd. if the other one was the case you just did not make a "pure MSX" program.

this is what TI says about their chip, and they even do not guarentee anything on timing: www.xs4all.nl/~ronholst/map/resources/video/texasinstruments_tms9918.pdf

E.g. The Maze of Galious uses the 5th sprite rule to mask off the sprite when entering a shrine. It will break on a "fixed" machine.

I wonder if it's so bad that things aren't downward compatible...Not everyone can run turbo r games if you don't have one.
Not everyone can play msx 2 games if you don't have an msx2. PLus I guess there are more OCM's around then turbo r's.
having a gfx9000 and moonsound shows that there could be done even more with an msx then the real ones could.
Those 2 additions have been embraced with open arms.
So why not the OCM ?
I agree with latok that it's the msx-a and nishi who decide what msx is, give it corporate identity etc.
When windows releases vista, do you still run 98 or ME ?
If they decide they release a new piece of hardware, and they decide that doing it like this is efficient,
then that's the standard. Like it or not, I think they have a bit more authority then anyone else here.
If sony says the PS3 is a playstation, then it is a playstation, even if the hardware is completely different.
Is the WII not a WII because you can run non nintendo related games on it as well ?
It's nice seeing that people know better what an msx is then nishii, I guess he'll be quite surprised hearing
that the thing he relased, his new baby, is in fact not an msx.

Quote:

E.g. The Maze of Galious uses the 5th sprite rule to mask off the sprite when entering a shrine. It will break on a "fixed" machine.

wow, didn't know that. nice example!

and here i thought you couldn't use that silly 5th sprite for anything useful

@wolf_: Have you had a chance to listen to an OCM yet? I'm a bit curious how good the audio is emulated. I think the OCM has potential to sound better than an old MSX since you don't have any interference with power, floppies and other things that makes a real MSX a bit noisy. But it requires of course that the emulation itself is well done and I haven't seen any comments on it.

I heard it, over a big PA haha... there should be a youtube link roaming around here somewhere demonstrating it

dvik: nope, I would've had the opportunity at several MSXCG meetings if some Dutch reviewsite had returned the OCM the past few months..

As for emulators : they currently aren't good enough. One of the essential things missing in FM emulation are legato envelopes, which means that tones with a certain attack are, like, 'smoothed' together to sound more as one line.. bit hard to explain perhaps.. but quickly after a note with that same envelope a new attack doesn't start from volume 0 afaik but somewhere halfway. There are quite some musicdisks that go horribly wrong because of this. I don't know exact specs about this, you'll have to try to find docs about this.

Also, the only annoying thing for me is humm/buzz noise from the electrical net. As for noise: this can actually make the sound more alive. This noise, of course, is something one could control manually..

The reason why I am a bit, well I shouldn't say worried, but maybe concerned about the audio in the OCM is the fact that PC emus aren't very accurate. I would think that the OCM implementation is based on some exisiting PC emulation. But there are quite a few FM implementtaions and hopefully the OCM is one of the better.

That particular bug you're talking about doesn't sound too hard to fix but maybe there is more to it. I'll see if there is something I can do. Is there a particular OPL that has the problem or all of them?