PC Engine core

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

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

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

Re: PC Engine core

Post by Sorgelig »

dshadoff wrote: I've already committed a fix for the wait state for ST0/1/2 in my fork ( http://www.github.com/dshadoff/TurboGrafx16_MiSTer ), although I don't know if that actually corrects any game-related issues.
Thanks for fix! i've added it too.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

So, now only 3-cycle "stairs" remains from obvious.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Yes, that’s CSL (CPU speed set low), which appears to be partially implemented.

I have a couple of other items higher-priority to fix before I get to that:
-Widen area available to display on scanline (already checked in; you may have already grabbed it)
-some junk pixels showing on some static title screens at startup (seems like uninitialized SATB)
-vertical line on CPUtest screen is about 24 pixels too far right (VSYNC-CPU synchronization off by a few dozen cycles)
-final pixel on scanline does not show when in 10MHz dotclock mode
Then I’ll finish up CSL (because I don’t think it actually is used in a place where games can see an impact)

Fixing issues is easier than writing new functionality for now.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

dshadoff wrote:-Widen area available to display on scanline (already checked in; you may have already grabbed it)
yes, i've saw but i don't understand what's that for.
I didn't work on PCE quite some time so a little off the topic now.
If i remember right, core already displays the whole line excluding the possible border, so there won't be an empty space on HDMI.
dshadoff wrote:-vertical line on CPUtest screen is about 24 pixels too far right (VSYNC-CPU synchronization off by a few dozen cycles)
This is a bit tricky. I don't remember games right now, but there was several games where i checked the CPU interrupt - otherwise some games are really broken.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Sorgelig wrote:
dshadoff wrote:-Widen area available to display on scanline (already checked in; you may have already grabbed it)
yes, i've saw but i don't understand what's that for.
I didn't work on PCE quite some time so a little off the topic now.
If i remember right, core already displays the whole line excluding the possible border, so there won't be an empty space on HDMI.
The 6270 and 6260 are capable of doing things beyond what the technical documents stated as 'normal' (and 'beyond normal' was often used in games).

For example, while 5MHz mode is *usually* set for 256 pixels (VREGs HDS = $02, HDW=$1F), these values are also exceeded sometimes. HDW is horizontal display width : ($1F+1)*8 = 256 pixels. Chris Covell's "Screen Dimension Test" (on this page https://www.chrismcovell.com/creations.html) allows you to manipulate these values to view the results; on a real system, it can still display as far as a value of $23 (provided that HDS, used for centering, is adjusted downward). While the 6270 can have virtually any values, the 6260 implements the hard limits (which is also how it is implemented in MiSTer), but the real hard limits are looser than what had been in the code.

If you look at the CPU Timing Test program, he has placed some squares at the left and right edges, which can be used as a reference (since he uses a 'beyond normal' setting). Mednafen also doesn't implement the full scanline, but it does implement 'beyond normal' to some degree.
Sorgelig wrote:
dshadoff wrote:-vertical line on CPUtest screen is about 24 pixels too far right (VSYNC-CPU synchronization off by a few dozen cycles)
This is a bit tricky. I don't remember games right now, but there was several games where i checked the CPU interrupt - otherwise some games are really broken.
I'll keep this in mind. Mednafen also has a similar position of that vertical line and has good compatibility, so it's not top priority and would need testing in any case.

By the way, thanks for pushing the framework updates (November commit); I was wondering what to do about the timing warnings coming from Quartus.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

Don't forget that real games is what core for. What can be done in test to push the HW beyond limits has low priority, especially if it will negatively affect the games. Video will reserve additional space on screen which won't be used in games - not a good idea. Some games may display garbage or broken graphics on edges which is normally beyond visible area on real HW with CRT.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

dshadoff wrote:I'll keep this in mind. Mednafen also has a similar position of that vertical line and has good compatibility, so it's not top priority and would need testing in any case.
may be it's related to this issue: https://github.com/MiSTer-devel/TurboGr ... /issues/47
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

I think the improvements need to be concentrated around cycle accuracy. CPU cycle accuracy should be easier as it's more documented and easier to fix. More work will need for VDC's cycle accuracy as it originally written without keeping cycle accuracy in mind. Also, cycle accurate VDC may loose ability of 64 sprites per line.
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

Sorgelig wrote:Don't forget that real games is what core for. What can be done in test to push the HW beyond limits has low priority, especially if it will negatively affect the games. Video will reserve additional space on screen which won't be used in games - not a good idea. Some games may display garbage or broken graphics on edges which is normally beyond visible area on real HW with CRT.
The core should do exactly the same as real hardware and it already includes the border in the output.

The option "Vertical blank" should be renamed to "Overscan" and we can make it hide the left and right edges as well as top and bottom. Then there is a choice to show everything or hide the overscan like a CRT.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Sorgelig wrote:Don't forget that real games is what core for. What can be done in test to push the HW beyond limits has low priority, especially if it will negatively affect the games. Video will reserve additional space on screen which won't be used in games - not a good idea. Some games may display garbage or broken graphics on edges which is normally beyond visible area on real HW with CRT.
I'm sorry, I'm not clear on what you are saying - are you saying that you are not interested in accepting this correction, even with clear examples ? I know that there are games in the library which deliberately use large values such as these; Mednafen also made their display line much wider than default because of this. However, I can't say whether such examples exist in the HuCard library - the CDROM library pushed the hardware much more.

A second note: video register HDS is used to move the left edge of displayable area, in order to adjust horizontal position, but it appears that MiSTer does its own centering based primarily on HDW versus display aperture. This means that any video 'garbage' on the left edge of the screen will be visible on MiSTer always, while right-edge will not be displayed when HDS/HDW values are as described.

Sorgelig wrote:
dshadoff wrote:I'll keep this in mind. Mednafen also has a similar position of that vertical line and has good compatibility, so it's not top priority and would need testing in any case.
may be it's related to this issue: https://github.com/MiSTer-devel/TurboGr ... /issues/47
Yes, that looks like a test case for this item. I will take a look.

Sorgelig wrote:I think the improvements need to be concentrated around cycle accuracy. CPU cycle accuracy should be easier as it's more documented and easier to fix. More work will need for VDC's cycle accuracy as it originally written without keeping cycle accuracy in mind. Also, cycle accurate VDC may loose ability of 64 sprites per line.
I am always keeping in mind that the original hardware is the model which we should be following. If a correct implementation breaks 64-sprite compatibility, I'm sure there will be another way to 'hack' that back into the core. MiSTer is capable of much more than the original hardware (such as dual-ported RAM), so there will always be leeway to do such things.

I am looking forward to @Furrtek's further exposition of the de-capped 6270/6260/6280 chips (in roughly that sequence) to verify original implementations.
paulbnl wrote:The core should do exactly the same as real hardware and it already includes the border in the output.

The option "Vertical blank" should be renamed to "Overscan" and we can make it hide the left and right edges as well as top and bottom. Then there is a choice to show everything or hide the overscan like a CRT.
I agree with this general sentiment.
However, I can genuinely say that on the various CRTs which I have used over the years, about 80-90% of the additional HDW would be visible on-screen without adjustment, so I don't think it is realistic to refer to the entire change as 'overscan'. The cutoff may be best implemented as an adjustable value.


In other news, the 'junk' sprites on an uninitialized background no longer show on the updated core on the example ROMs I had previously seen it with - this doesn't mean the issue is fixed - just that the memory map has shifted, so this junk may now appear on other games (or may not). I'll keep you posted.

In any case, I won't send a pull request until I have a couple more fixes in.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

dshadoff wrote:are you saying that you are not interested in accepting this correction
i didn't say so strict. As an optional feature it should be fine.
What i want to say is this change won't fix any glitches in games. It's pure cosmetic change.
dshadoff wrote:A second note: video register HDS is used to move the left edge of displayable area, in order to adjust horizontal position, but it appears that MiSTer does its own centering based primarily on HDW versus display aperture. This means that any video 'garbage' on the left edge of the screen will be visible on MiSTer always, while right-edge will not be displayed when HDS/HDW values are as described.
it's related to resolution change in the middle of frame. Analog CRT has no pixels on surface and stretches the video regardless the pixel clock. MiSTer cannot stretch lines independently from each other. So the only compromise way for such games is to center the visible area depending on resolution. So "Order of Griffon" looks good. Otherwise the bottom panel would be squeezed to the left.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

I had been viewing the output on HDMI (which looked fine), but I'm also working with Chris Covell who is using RGB output to a 15KHz CRT monitor... the results are not the same (CRT is pushed too far left), so now I understand your hesitation.

I'll back out this change in my repository until I can get it to work well on both. I believe that it is related to the HDS value being ignored by the current code (although it is important on CRTs), and that a solution may require more work to incorporate that into the timing.


Another item we found (by oscilloscope measurement) is that the VSYNC/HSYNC period on this core is not acting exactly as expected; a normal PC Engine's VSYNC is a 3-line period with inverted HSYNC signals in the middle; however, the current MiSTer core's VSYNC period is actually only 2 lines + an extra non-inverted HSYNC. (The edge-offset of both the CPU test vertical line and issue #47 are nearly-exactly an HSYNC pulse width time). I am currently looking into this.

In an effort to track down the issue, I have found the code to be a little challenging to work with so it is taking some time to digest the inner workings. While much of the code is sort of self-documenting, there are areas which are less clear because of abbreviations in names etc...

-> If I add some comments to the code to aid in understanding, would you accept those changes into the standard codebase (providing of course, that they are accurate) ?
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

Looks like the 2-line Vsync is caused by this: https://github.com/MiSTer-devel/TurboGr ... 0.vhd#L260

VS_N goes high at line 2 so VS_N is only low at line 0 and 1. It should be

Code: Select all

if V_CNT = VS_LINES then VS_N <= '1'; end if;
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

dshadoff wrote:Another item we found (by oscilloscope measurement) is that the VSYNC/HSYNC period on this core is not acting exactly as expected; a normal PC Engine's VSYNC is a 3-line period with inverted HSYNC signals in the middle; however, the current MiSTer core's VSYNC period is actually only 2 lines + an extra non-inverted HSYNC. (The edge-offset of both the CPU test vertical line and issue #47 are nearly-exactly an HSYNC pulse width time). I am currently looking into this.
What you are talking is a serration. For modern digital TV it's not required. It's not required even for many CRTs. Serration may interfere the other parts of video, so i highly not recommend to implement it. It's not related to video shift.
Shift on VGA output is accomplished by shifting VSync/HSync. HDMI doesn't use these signals for frame composing (but they should be present for general sync).
dshadoff wrote:-> If I add some comments to the code to aid in understanding, would you accept those changes into the standard codebase (providing of course, that they are accurate) ?
You can add comments in PCE itself - that's fine (just don't write poems there, please).
Don't modify /sys files.
Peredonov
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Jan 04, 2020 8:06 pm

Re: PC Engine core

Post by Peredonov »

Lack of serration pulses can be a big problem on some CRTs, causing flagging distortion at the top of the picture.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

Peredonov wrote:Lack of serration pulses can be a big problem on some CRTs, causing flagging distortion at the top of the picture.
not a big. 99% of cores (non-MiSTer) have no serration.
Don't make an elephant from mosquito. If it's happened that you have one of those PVM/BVM not able to cope with this, then get an Extron - it will fix the problem.
Peredonov
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Jan 04, 2020 8:06 pm

Re: PC Engine core

Post by Peredonov »

Sorgelig wrote: not a big. 99% of cores (non-MiSTer) have no serration.
Don't make an elephant from mosquito. If it's happened that you have one of those PVM/BVM not able to cope with this, then get an Extron - it will fix the problem.
The overlap between MiSTer user base and video quality enthusiasts who use professional monitors is not small, and you can bet it will grow even more, so it is worth it to care about increasing compatibility with such monitors if reasonable. An Extron RGB interface can fix the problem often, though it is not always effective. Plus not everyone will own one. But it's true that lack of serration in this core may not cause problems for anyone, so this topic can be revisited if issues do appear.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

paulbnl wrote:Looks like the 2-line Vsync is caused by this: https://github.com/MiSTer-devel/TurboGr ... 0.vhd#L260

VS_N goes high at line 2 so VS_N is only low at line 0 and 1. It should be

Code: Select all

if V_CNT = VS_LINES then VS_N <= '1'; end if;
Thank you, paulbni - I think that you're correct - this comparison will cause the end of VSync one line too soon.
Sorgelig wrote:
dshadoff wrote:Another item we found (by oscilloscope measurement) is that the VSYNC/HSYNC period on this core is not acting exactly as expected; a normal PC Engine's VSYNC is a 3-line period with inverted HSYNC signals in the middle; however, the current MiSTer core's VSYNC period is actually only 2 lines + an extra non-inverted HSYNC. (The edge-offset of both the CPU test vertical line and issue #47 are nearly-exactly an HSYNC pulse width time). I am currently looking into this.
What you are talking is a serration. For modern digital TV it's not required. It's not required even for many CRTs. Serration may interfere the other parts of video, so i highly not recommend to implement it.
To be clear, this is what I am talking about:
PCE output:
Image

MiSTer output:
Image

You can see that on the PCE output (actual machine), the HSync signal is not a distinct anti-sense pulse at the start or end of the VSync - but rather is embedded into it.

On the MiSTer, the start of VSync incorporates HSync properly. However, at the end of the VSync, it appears that 2 HSyncs are asserted - one, included in the end of the VSync, and an additional one.

If this is what you are saying a serration is, I agree that it should not exist here, and I would like to eliminate it. I just can't see what is causing it yet.
Sorgelig wrote:It's not related to video shift.
Shift on VGA output is accomplished by shifting VSync/HSync. HDMI doesn't use these signals for frame composing (but they should be present for general sync).
In the case of the vertical line in the CPU test, the first color change is timed a specific number of CPU clock cycles after the VSync interrupt, and it is approximately 24 pixels further right on MiSTer as compared to real PC Engine (on both HDMI and VGA output). HSync is coincidentally about this duration.

In this case, one of two (or maybe more) things is happening - it's likely either:
1) The Vblank IRQ and VSync signal may not actually happen at the exact same moment, and may need to be separated slightly (this is the next measurement we need to take from the actual machine), or
2) The serration may be interfering with regular timing of scanline generation. By this, I don't meant that the VDC displays lines differently, but rather that the CPU gets a slightly different amount of work done.

It's not 100% clear from the oscilloscope capture whether it may be interfering with scanline timing at the start of the frame.

(But with respect to issue #47, I'm not yet sure whether it's even related.)
Sorgelig wrote:
dshadoff wrote:-> If I add some comments to the code to aid in understanding, would you accept those changes into the standard codebase (providing of course, that they are accurate) ?
You can add comments in PCE itself - that's fine (just don't write poems there, please).
Don't modify /sys files.
Thanks.
I mostly wanted to comment the meaning of the signals/variables in the core itself (is "COL" short for "color" or "column" ; what does "X" count ; the _FF signals are actually 1-cycle delay pipelines in many cases, etc.)
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

SNAC

Post by dshadoff »

I understand that support for SNAC has been built by somebody for PC Engine, but not integrated into the standard codebase.
I was wondering how I could review the related code updates ?

My interest is not related to low-latency normal controller input; rather, I am interested in all of the non-traditional devices:
- pachinko controller
- mouse
- memory base 128
- serial communications
- etc.

Please let me know if this is something available (even if not on the standard codebase).
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

dshadoff wrote:You can see that on the PCE output (actual machine), the HSync signal is not a distinct anti-sense pulse at the start or end of the VSync - but rather is embedded into it.

On the MiSTer, the start of VSync incorporates HSync properly. However, at the end of the VSync, it appears that 2 HSyncs are asserted - one, included in the end of the VSync, and an additional one.

If this is what you are saying a serration is, I agree that it should not exist here, and I would like to eliminate it. I just can't see what is causing it yet.
Ah, no. It's not a serration. It's just first HSync is glued into VSync and got lost.
Serration is the HSync with twice higher frequency embedded into VSync.

I remember sys_top has module to separate the first HSsync from VSync and make the picture the same as on your real PCE. Probably it goes only to direct video only. need to check.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: PC Engine core

Post by Sorgelig »

Oops.. i've swapped the pics :) It's happened a real PCE glues HSync instead of MiSTer.
So, you should not worry about it. MiSTer's sync is more proper then ;) Just need to add one more VSync line as for some TV's 2 lines are not enough.
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

dshadoff wrote: You can see that on the PCE output (actual machine), the HSync signal is not a distinct anti-sense pulse at the start or end of the VSync - but rather is embedded into it.

On the MiSTer, the start of VSync incorporates HSync properly. However, at the end of the VSync, it appears that 2 HSyncs are asserted - one, included in the end of the VSync, and an additional one.

If this is what you are saying a serration is, I agree that it should not exist here, and I would like to eliminate it. I just can't see what is causing it yet.
The PCE uses a simple XOR to combine HSync/Vsync which causes the falling edge of HSync to be shifted right due to it being inverted. This makes the falling edge of the first HSync inside Vsync too late and the last HSync falling edge inside Vsync to be lost.

We have added a proper Sync combiner in MiSTer Sys framework so that there are 3 proper HSync falling edges inside. Vsync. At first glance this appears as a double HSync at the end but is not.

PVMs and BVMs expect proper HSync in Vsync and will have that distortion at the top of the screen when the last HSync is missing inside Vsync.

Real NES and SNES consoles are examples that have this correct sync.

Check here for more sync information. https://www.hdretrovision.com/blog/2019 ... ling-short
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

Btw you can use the SignalTap logic analyzer in Quartus to easily look at the precise timing of the internal core signals.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

paulbnl wrote:The PCE uses a simple XOR to combine HSync/Vsync which causes the falling edge of HSync to be shifted right due to it being inverted. This makes the falling edge of the first HSync inside Vsync too late and the last HSync falling edge inside Vsync to be lost.

We have added a proper Sync combiner in MiSTer Sys framework so that there are 3 proper HSync falling edges inside. Vsync. At first glance this appears as a double HSync at the end but is not.
OK, I'm not too concerned about the internals of the signal itself; I was just searching for landmarks to compare timings against. Now that it is understood, I'll concentrate on the raising of the IRQ. I have a suspicion that both VBLANK and RCR interrupts are raised a few cycles late on this core... but I'll need to run some tests and measurements to confirm whether this is true or not.
paulbnl wrote:Btw you can use the SignalTap logic analyzer in Quartus to easily look at the precise timing of the internal core signals
I knew about SignalTap... but as you guessed, I haven't become so comfortable with the environment to try it out yet. Soon.

My goal is, of course, to be a net-positive to the project, but of course there is a learning curve so I will inevitably ask questions while I ramp up. I'll try to be as little of a burden as possible.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

OK, I'm just checking some values and timings, but I should have a fix for minor adjustment of the timing of VBLANK and RCR interrupts in the next day or two (not yet checked in locally). It's empirically working here, but I'd prefer to have confirmation from the real machine to justify the specific choice of timings.

Issues fixed by this will include at least:
#47 Power Drift
#46 Outrun
#31 Dungeon Explorer
plus the CPUtest vertical line position.

I also didn't see issues #29 or #34 when I checked, but I don't think they are related to this (probably fixed by some of the other commits).

Stay tuned...
Locked

Return to “MiSTer”