I think that improving compatibility of OCM with old MSXes is also what we as a community can do for our pleasure. IMHO emu authors can be the best contributors.

From one side, we had a hope that we will get a 100%-compatible OCM out of the box, "just because it's a hardware solution".
From the other point of view, OCM is just a standalone emulator that also needs to be improved just as it's software "brothers in arms", and IMHO, it should be an interesting and challenging task !

I think most people have been prepared for minor compability issues and that is expected. Over all it it sounds like the quality is good. I took a quick look at the vhdl code and it looks suprisingly good. Very well structured and easy to read. So it shouldn't be too hard to dig in to the code and make improvments and/or enhancements.

Quote:

However, the VDP command speed is currently approximately twice as fast in the OCM as in a real MSX. So it is still a nice improvement for SymbOS.

Thanx for the info, Alex. It will be also interesting to see games like KpiBall on it, which use the VDP commands a lot.

Quote:

I don't want to sound critical, but why doesn't the speed match the old MSX2. If the timing is off by this much, the OCM will be quite useless for MSX development (unless the developed SW is targeted towards OCM only).

There are two reasons that the OCM is faster that the real VDP

1) The OCM simply needs less clock-cycli per iteration of a command. Apparently the finite state machine of the real MSX needs more steps. It is possible to determine the number of steps in the finite state machine of the real MSX approximately but not exactly. E.g. when only the x-coordinate needs to be increased, less steps will be required then when the x-coordinate must be reset and the y-coordinate needs to be increased. But this subtle difference is difficult to measure and hence difficult to re-implement in hardware .

2) The OCM has much higher memory bandwith available then the real MSX. In the real MSX, the command engine must regularly wait for the line-rendering and the sprite-prefetching. That is why , on the real VDP, commands are faster when sprites are off or when the screen is off. However, on the OCM, the command engine does not have to wait. Which makes the execution speed independent of sprite on/off and screen on/off. Again, it is very difficult to determine how much the command engine must wait in the real MSX. Does the command engine get intermediate memory-access-slots during the line rendering or not? I have not yet found the answer to this question.


This problem can be resolved in two manners

A) In the same manner as the software emulators (like openMSX) do it: make a table with the (average) time per command per screen on/off, sprite on/off combinations. Then make an extra step in the finite state machine to wait the correct number of clock cycli per command iteration.
Disadvantage is that this will cost much extra logical elements (chip space)

B) Do more accurate measurements on the real VDP to find the answer to question 2 (when must the real VDP command engine wait for the memory access) and then implement this same behaviour in the OCM VDP. This will cost less extra logical elements and in the end is more accurate as it will be closer to the real hardware implementation.

I'm planning to go for solution B. However, I have not yet found the time to do this. However, once I have found the time, I will implement it like that and I will add a new register to the VDP so that the developer can choose between accurate timing and fast commands. The default after a reset will be accurate timing. But by setting some bit in the register to 1, the fast command will be enabled.

I Hope this clarifies.

Kind regards,
Alex

Thanks Alex. I like your solution though (both the current and proposed). There is also nothing that say's the OCM *must* have the same timing as a real MSX2. For most users it doesn't matter (unless of course if there are games that don't run properly). Even the panaosinic MSX2+/TR machine breaks compability with older MSXes when it comes to VDP timing, mainly because of memory or databus access. The difference is not as big as current OCM but still...
The big need for accurate timing is for people that want to use the OCM as an MSX2 development tool. This is where the big difference in VDP timing will be problematic. So for me it would be very nice with more accurate timing but as I said, its really not a requirement. The OCM can and perhaps should be treated as a different machine since it never will be 100% MSX2 compatible.

Quote:

The OCM can and perhaps should be treated as a different machine since it never will be 100% MSX2 compatible.

At this moment, the objective of the people involved in the OCM is still to further improve the MSX2 compatibility (amongst others the VDP command speed).

However, on the longer term, I see the OCM involve into a kind of MSX turbo R+

The + is intentional. There are several improvements that can be made so that the OCM will eventually be significantly faster then the MSX turbo R (both CPU and VDP). My personal hope is that, once this state has been achieved, people will start to make OCM specific software (demo's, game's, utilities, etc.).

I also hope that, now that the OCM has hit the street, more people will join the project and that many new ideas for (realistic) improvements and enhancements will be suggested and implemented.

One other enhancement that I would like to have is internet support. For example with the assistance of an USB-Ethernet or an USB-WLAN adapter. That would be really cool. In this area, I also see a role for SymbOS. For example with a TCP/IP stack in the SymbOS kernel and then a web-browser application running in the graphical shell.

I actually think a lot of people don't like that idea of really new MSX systems. I do tho. A lot of people who strongly disagree with the OCM do it because they compare the price of this OCM with the price of any ordinary MSX2 (with some extra extentions) on Ebay, or perhaps they compare it with their current MSX, which might be just a very enhanced set. Naturally the reprogrammability of the machine was communicated often enough.
So, it might be that a number of people are left behind once the OCM really changes drastically. In a way you'll get discussions about "this is no MSX anymore" etc.

GEM runs on MSX2 and above, but is alsooptimized for MSX turboR. GEM emulates the classic Gameboy with remarkable accuracy and speed. Will it do also with the speed of the onechip msx? also in color gameboy...?

I'm very worried the MSX evolution will be some kind of Wild West....There is a STRONG NEED for development structure. I haven't read that much about this important part of the future. We need MSX Software Team (MST) MKII

Ehmmm ... Latok, you are no more part of the MRC team ????

Correct For some time already, actually. I was very inactive for the last year or so. And I believe that the MRC team does not benefit from inactive members. That's why I felt it was time for me to take this step back.

Back to the subject, I feel MSX evolution NEEDS to be structured. I understood Bazix wants to release 'official updates' but which updates are official?

Custom OCM code could be supplied with some demo or game, and then restored upon quit. Or: before some demo/game starts the current config is stored to some file, so in case of a sudden reset one can always manually restore the original state. But it's exactly this kinda customness that might scare off some people.

A dedicated MST could be an option, but *only* if this team knows what it's doing and not trying to artificially keep things low-profile or too hardwired. It's not a bad idea to look and think outside the box.

Personally, I like computers such as classical 80s homecomputers and modern game consoles and handhelds because they have fixed hardware. I don't fancy the PC-dogma: 'Oh, it doesn't work smoothly? Just plug in some more memory or insert a faster GFX card....' That's the reason -in my view- why pc's don't have personality (computers with personality...Laaatok, shuuuut up ^_^). Thus I really hope the MSX scene will seriously start building an MSX3 standard, instead of customly adjusting the MSX hardware in benefit of a specific game of demo or utility. That won't lead to anything structural. And that will certainly spark fire to the view that the OCM actually is NOT an MSX.

Question is: "what" is an MSX, seen from today's perspective?

CPU:

I think, the CPU itself didn't define most of the MSX that much.

Sound:

The MSX has always had a lot of sound extensions, while other systems stayed with their standard chip. Therefor, chiptunes aren't realy common on MSX, and PSG music (in Konami style so to say, not the PT3 style) isn't made that much. What was *the* soundchip on MSX apart from the PSG? I'd say the FM-Pac. Question is, should we stick to the FM-Pac? Can't we expand its possibilities, for we'd loose MSX'ness?

Video:

Is it the slow-as-sh*t V9938? If so, are the MSX gfx slow by definition then? If so, is a fast video solution not in the spirit of MSX perhaps?

You also have to see all these things from the perspective of the 80's. Things made back then weren't made for specific goals probably, but just to fit a certain amount of features for a certain price per chip. I don't believe Yamaha could have predicted a demo like Unknown Reality..

Tell me Latok: what do you think of the G9k? Is it MSX'ness? If yes, what more functionality could we agree on to still be MSX'ness?
What do you think of the Moonsound? Is it MSX'ness? If yes, what more functionality could we afgree on to still be MSX'ness?

What do you think of the speed of a tR, let alone a tR running at 40Mhz (some ppl replaced their crystal)? Is it still an MSX? If yes, what would be the maximum speed that could fit the idea of an MSX?

My point is: if a new standard is vast enough, ppl don't need to insert their own VHDL. The problem is: how sure can one be that one universal MSX3 design matches everyone's wishes?