PC Engine core

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, Greenious, spiny, Sorgelig, Moderator Team

SuperSpongo
Atarian
Atarian
Posts: 5
Joined: Mon May 27, 2019 8:57 am

Re: PC Engine core

Postby SuperSpongo » Thu Jun 13, 2019 7:16 am

Immediately the first thing that popped into my head as well.
"Neat, MiSTer Controllers!"

seastalker
Captain Atari
Captain Atari
Posts: 308
Joined: Sun May 15, 2016 3:44 pm

Re: PC Engine core

Postby seastalker » Fri Jun 14, 2019 8:42 pm

It would be REALLY cool if they added a Supergrafx version (surprised they didn't) since the system is expensive, rare, and possibly looks the best of the retro consoles; Of course put all the SGX titles on it and then some CD-rom based games. :) I also wonder if any of the shells would fit a MiST/MiSTer?
I'm jumping topics a bit, but I'd love Analogue to do a NEC system with similar case lineup. A SGX inspired case with the pack-in title being a hypothetical newly discovered proto of the planned SGX Strider version.

Even if just playing the built in emulated games, if it gets hacked with jailbreak firmware, I'd rather play emulated games on a thing that LOOKS at least like the console I'm playing. Heck, wouldn't it be cool if the cases' Hu-Card slot was now a SD-card slot?

I am also wondering how you make a MINI PC-Engine as it is already the tiniest thing! Any smaller and it might be mistaken as a Triscuit! The Turbografix-16 mini would be a welcomed scale-doown as it would have (and should have) been 30 years ago as well. ;)

drj3rk
Atari User
Atari User
Posts: 35
Joined: Tue May 14, 2019 10:12 pm

Re: PC Engine core

Postby drj3rk » Fri Jun 14, 2019 9:02 pm

seastalker wrote:I am also wondering how you make a MINI PC-Engine as it is already the tiniest thing! Any smaller and it might be mistaken as a Triscuit!


TriscuitGrafx!

I agree, they should have done a SuperGrafx edition.

normal19
Retro freak
Retro freak
Posts: 14
Joined: Sat Jul 20, 2019 4:17 pm

Re: PC Engine core

Postby normal19 » Fri Dec 06, 2019 12:25 am

https://www.chrismcovell.com/CPUTest/

According to this the Mister core is very innacruate at every test level, should we be concerned about this?

MottZilla
Atariator
Atariator
Posts: 20
Joined: Fri Oct 04, 2019 2:27 am

Re: PC Engine core

Postby MottZilla » Fri Dec 06, 2019 1:20 am

normal19 wrote:https://www.chrismcovell.com/CPUTest/

According to this the Mister core is very innacruate at every test level, should we be concerned about this?


Hopefully the information and test ROM could be used to improve the accuracy. Ideally you'd want the MiSTer implementation to behave exactly the same as the original hardware if possible. It is interesting that running from DDR3 instead of SDRAM causes potentially serious issues.

crocky
Atari maniac
Atari maniac
Posts: 93
Joined: Fri Nov 23, 2018 2:01 pm

Re: PC Engine core

Postby crocky » Fri Dec 06, 2019 1:48 am

normal19 wrote:According to this the Mister core is very innacruate at every test level, should we be concerned about this?


Its known that the aging PC Engine core has inaccuracies. As and when any dev has time and is interested to fix this it will happen.

User avatar
bootsector
Retro freak
Retro freak
Posts: 16
Joined: Wed Aug 21, 2019 11:51 am

Re: PC Engine core

Postby bootsector » Fri Dec 06, 2019 4:54 pm

It's actually great to see the TG16/PCE MiSTer core put under tests like this! It could give us a hint that people might be truly expecting good things from it. Hope to see this already great core getting improvements soon!

seastalker
Captain Atari
Captain Atari
Posts: 308
Joined: Sun May 15, 2016 3:44 pm

Re: PC Engine core

Postby seastalker » Sun Dec 08, 2019 3:50 pm

That actually surprises me. I have a TG16, a PCE and haven't noticed any problems yet with the core. I'll have to pay more attention now. I still think the core is already EXTREMELY good.

MottZilla
Atariator
Atariator
Posts: 20
Joined: Fri Oct 04, 2019 2:27 am

Re: PC Engine core

Postby MottZilla » Sun Dec 08, 2019 9:21 pm

seastalker wrote:That actually surprises me. I have a TG16, a PCE and haven't noticed any problems yet with the core. I'll have to pay more attention now. I still think the core is already EXTREMELY good.


If you're familiar with emulator development or older emulators it's actually not that surprising that many games will not exhibit any issues despite inaccurate hardware emulation. It all just depends on how the program was designed and what it tries to do. Now demo roms and test roms are often a great way of revealing inaccuracy to the real hardware because they often do things that commercial games never did or weren't sensitive to those behaviors. But probably every system you'll have some games that are sensitive to certain edge case behaviors.

I've never worked on an emulator for PC-Engine so I don't know any specific issues that could come up due to inaccurate emulation. The NES is probably more sensitive to timing details with certain games using a lot of timed code like Battletoads for example.

The important thing is having more information about accuracy problems will eventually allow the core to be improved.

dshadoff
Atarian
Atarian
Posts: 8
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Postby dshadoff » Sun Dec 29, 2019 9:42 pm

I just received my DE10-nano board (no SDRAM yet - a few days from now...), and examined the results of this test.

The issues demonstrated could be considered "edge cases" which may not often appear in games, but could cause lockups and other issues which could otherwise be difficult to diagnose (for example, an interrupt could be missed). I also don't have a dev environment set up yet, but will also get that set up soon.

Note that the webpage (https://www.chrismcovell.com/CPUTest/) is based on the July version of the core; some improvements have already made it into the September version.

My results show (remember, these are DDR3-based for the time being, and "run from RAM (not ROM)" ):

1) The VSYNC timing appears to have been corrected, as the indent on the top line looks appropriate in the 201909 version of the core.

2) The right edge is still wrong by 2 characters.

3) Every timing test at every level shows a gentle slope leftward as the tests progress down the screen. About 1 pixel per line, which equates to about 2 cycles per test. This does not imply a problem with the opcodes involved with the test, but rather something which occurs once per test. I suspect it's the update to the 6260 palette generator, which seems too fast (~2 cycles as I mentioned). I would suggest writing a new test for this (or, given time, I will do so).

4) Opcode 'CSL' is egregiously fast. Does this even implement slow CPU-speed, I wonder ?

5) Opcodes ST0, ST1, ST2 take longer than they should. Probably 1 cycle more than they should. Not sure whether this is on the opcode side, or the write-to-VRAM side.

6) For some strange reason, TDD operations take longer than any other transfer operation. That was unexpected.

7) The vertical interface line (between opcodes) shakes a little even on normal systems, because the VRAM clock and the CPU clock don't always line up and wait states occur. In the case of MiSTer, this shakes tremendously, and by greater magnitudes toward the bottom of the screen; perhaps this is due to the fact that the DDR3 is being used by both the CPU and the video circuitry. Ideally, these memories should not be on a shared bus, so I will assume that DDR3 may never reach a level of perfection that the SDRAM should (unless the 2 DDR3 chips can be addressed separately ?)

I will test again when I get the SDRAM board working.
If somebody else is working on this, I am happy to help - otherwise I will eventually fix the above issues myself (but my schedule will not be fast).

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5594
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Postby Sorgelig » Mon Dec 30, 2019 12:41 am

PC Engine core is NOT cycle accurate. It's not developed originally as cycle accurate. After porting to MiSTer, several people improved it and made more closer to HW. Still it's far from cycle accuracy. It's just happened that most games are not bound to specific timings, so glitches are minimal through the whole game library. To make it cycle accurate the whole VDP and CPU modules must be rewritten which is very large task comparing to possible benefit.

dshadoff
Atarian
Atarian
Posts: 8
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Postby dshadoff » Mon Dec 30, 2019 1:07 am

Sorry, I didn't mean to sound like I am complaining, it's actually quite good (just not perfect).
Based on what I have seen while developing emulation and hardware devices, several of these items will cause incompatibility issues if a CDROM core is built on top of this.

I'm really just making a list of the items I found; I am looking to participate in its development once I get a dev environment set up, and will aim to correct these.

Looking more deeply at the code, CSH/CSL basically are just placeholders (needs invasive change to implement), but ST0/ST1/ST2/TDD should be possible to correct relatively quickly (although TDD appears properly-implemented at first glance...that looks interesting).

I don't think the VDP and CPU modules need to be rewritten to fix these issues (although I think I would have written them differently).

GreyRogue
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 105
Joined: Thu Mar 22, 2018 3:50 am

Re: PC Engine core

Postby GreyRogue » Mon Dec 30, 2019 3:41 am

dshadoff wrote:3) Every timing test at every level shows a gentle slope leftward as the tests progress down the screen. About 1 pixel per line, which equates to about 2 cycles per test. This does not imply a problem with the opcodes involved with the test, but rather something which occurs once per test. I suspect it's the update to the 6260 palette generator, which seems too fast (~2 cycles as I mentioned). I would suggest writing a new test for this (or, given time, I will do so).

The slope is caused by the Video Encoder using a slightly off number:
https://github.com/MiSTer-devel/TurboGr ... 60.vhd#L68
This number is a multiple of all 3 horizontal display resolution modes. The actual hardware should be 2730 https://github.com/mamedev/mame/blob/ma ... 60.cpp#L11, not 2736. If this is changed, it will need to be done in a way that doesn't break the scalar/scan doubler.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5594
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Postby Sorgelig » Mon Dec 30, 2019 7:29 am

GreyRogue wrote:The slope is caused by the Video Encoder using a slightly off number:
https://github.com/MiSTer-devel/TurboGr ... 60.vhd#L68
This number is a multiple of all 3 horizontal display resolution modes. The actual hardware should be 2730 https://github.com/mamedev/mame/blob/ma ... 60.cpp#L11, not 2736. If this is changed, it will need to be done in a way that doesn't break the scalar/scan doubler.

Long time passed since that. Requirements for scandoubler are relaxed, so probably now it can be 2730 without breaking.


Return to “MiSTer”

Who is online

Users browsing this forum: alexh, Piacenti, PsyFX and 6 guests