Using openMSX with GFX9000

Page 4/4
1 | 2 | 3 |

By Manuel

Ascended (16625)

Manuel's picture

27-06-2020, 20:02

You probably found a case where the emulation isn't accurate.

Please try with the latest development build.

By edoz

Prophet (2276)

edoz's picture

27-06-2020, 20:15

Just did the upgrade:

Same behavior.. probably it has something todo with timing issues.

I assume this is the last version for Windows?

By Manuel

Ascended (16625)

Manuel's picture

27-06-2020, 20:35

Looks new enough. You have to take into account that gfx9000 emulation isn't as accurate as V993x8 emulation. There is much less software for it and it's quite a complex beast.

Please add a ticket to our issue tracker if you find such differences. Preferably with a minimal test case that shows the issue and a video of real hardware running the test case.

And yes, check the V9990 manual for the required timing and implement it. I don't think openMSX implements the timing constraints.

By edoz

Prophet (2276)

edoz's picture

27-06-2020, 22:44

Okay thanks for the hint! Yes the g9k is a very complex chip Wink and a beast as well Big smile
I have huge respect for what you guys do with openMSX. All the work you put into it.. that is just amazing.

Rob and I will try to get it working on the real hardware first and then we can compare i hope.
How do you submit a ticket? Sounds very official Wink)

By ducasp

Champion (304)

ducasp's picture

28-06-2020, 02:42

edoz wrote:

Okay thanks for the hint! Yes the g9k is a very complex chip Wink and a beast as well Big smile
I have huge respect for what you guys do with openMSX. All the work you put into it.. that is just amazing.

Rob and I will try to get it working on the real hardware first and then we can compare i hope.
How do you submit a ticket? Sounds very official Wink)

https://github.com/openMSX/openMSX/issues

If you don't have a github account, I believe you need to register, but it is pretty quick ;)

By Manuel

Ascended (16625)

Manuel's picture

28-06-2020, 14:37

It may sound official or even bureaucratic, but it is very helpful to keep all information regarding a single issue together and keep overview of what is going on. So thanks in advance!

By ducasp

Champion (304)

ducasp's picture

28-06-2020, 17:27

Manuel wrote:

It may sound official or even bureaucratic, but it is very helpful to keep all information regarding a single issue together and keep overview of what is going on. So thanks in advance!

Also it is important to notice that this is a huge project with several developers working on it, so if issues aren't well organized they just get lost... Also, as the source code is freely available, anyone with good knowledge about an issue might just fork the project, do what they can, and then request the changes to be merged back... I've done it once as I had implemented an undocumented v9938/9958 feature for SM-X and OCM, just looked that it was an open issue on OpenMSX and gave my contribution to get it working there two... Also, I've been benefited a few times on my Telnet and MSX2ANSI (Derived of the great, amazing, uncanny Toby / Sonic_Aka_T job) where Piter Punk contributed as well.

I can't express how important it is to people to open issues on developer's github/gitlab when those are available, it is a powerful tool to keep track of what to do, to plan when to do (you have your issues laid out nicely, just prioritize then and organize your time), to the occasional programmer that can pick up an issue he is familiar with, to the users that can see what priority has been given to the issue and be notified when it is solved... And ultimately, for big teams, this is the only sane way to get the team energy focused. Wink

By edoz

Prophet (2276)

edoz's picture

28-06-2020, 17:53

Thank you guys for you kind help! I understand that it is good to have a list of all the bugs. It was not my intention to call it bureaucratic or what so ever .. But it felt very structured Wink And that is good.

Rob and i have a (maybe) a idea what is wrong. It seems the timing between CPU and VDP is always perfect in OpenMSX but it is not on a real machine, at least not with our SymbOS environment Big smile Hope we can report something later.

By Mumbly

Resident (63)

Mumbly's picture

28-06-2020, 18:19

Did you solved that issue ? Otherwise I can help you out if you need.
Please keep in mind that, in open msx, vram copy are not managed
the same way than in real V9990 hardware, Same for vdp interruption.
Be carefull also with the vram plan b page2, some real hardware
Are simply not showing it in pattern mode.

Regards

By Manuel

Ascended (16625)

Manuel's picture

29-06-2020, 21:59

Mumbly, can you detail which issues you are talking about? If not done yet, I'd like to document them in a GitHub issue, so it is clear and can be solved some day. (Perhaps with your help?)

Page 4/4
1 | 2 | 3 |