What have you in mind to do with OCM ?

Page 5/19
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By Grauw

Ascended (10072)

Grauw's picture

06-12-2006, 16:30

I posted about it on my blog:

http://www.grauw.nl/blog/entry/385

If you want, you can ask me questions there :).

~Grauw

By Prodatron

Paragon (1797)

Prodatron's picture

06-12-2006, 18:39

I would use it as the base of a kickass SymbOS "workstation". With it's powerful 10 MHz mode (and it's in-code, but commented-out support for 20 MHz), MSX2 video and music chip support and more, the OCM is the most powerful 8-bit computer ever built and in combination with SymbOS could easily provide a low-cost/high-performance computer system for the third world. At the various least, I suspect that it will replace the CPC-TREX as the leading-edge platform for SymbOS development.

The TurboR already replaced the CPC-TREX as the most powerful SymbOS platform Wink
What I would like to know is, if in the 10MHz/20MHz modes the speed of the VDP is also been increased?? Question
Very interesting, as only in this case the OCM would be faster than the TurboR.

By Alex

Master (205)

Alex's picture

06-12-2006, 22:27


The TurboR already replaced the CPC-TREX as the most powerful SymbOS platform Wink
What I would like to know is, if in the 10MHz/20MHz modes the speed of the VDP is also been increased?? Question
Very interesting, as only in this case the OCM would be faster than the TurboR.

In 10MHz Z80 mode, the VDP command speed is the same as in the Z80 3.57 MHz mode. The VDP command speed is independent from the Z80 speed.

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.

In an earlier version of the VHDL code, the VDP command engine was between 3 and 8 times as fast, depending on the command and the screen mode. However, this speed has been reduced for compatibility and stability reasons.

By dvik

Prophet (2200)

dvik's picture

06-12-2006, 23:59

However, the VDP command speed is currently approximately twice as fast in the OCM as in a real MSX.

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). To make sw that works well on older MSXes, it sounds like the OCM is as bad or even worse than PC emus.

And I'm sure there will be compability issues with existing MSX sw as well because of this (although most sw doesn't rely too much on the command engine timing).

By cax

Prophet (3736)

cax's picture

07-12-2006, 09:49

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 !

By dvik

Prophet (2200)

dvik's picture

07-12-2006, 18:54

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.

By Prodatron

Paragon (1797)

Prodatron's picture

08-12-2006, 07:33

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.

By Alex

Master (205)

Alex's picture

08-12-2006, 22:15


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

By dvik

Prophet (2200)

dvik's picture

08-12-2006, 22:48

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.

By Alex

Master (205)

Alex's picture

09-12-2006, 00:40

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.

Page 5/19
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10