PC Engine core

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

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

Locked
User avatar
BitsNStuff
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 122
Joined: Tue Oct 16, 2018 7:55 am
Contact:

Re: PC Engine core

Post by BitsNStuff »

Really exciting to see people working on this again after all this time, it's a wonderful little system with a great library of games.
Thanks everybody, really appreciated!!! :cheers:
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: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...
#39 is more fun :)
Last time i've tried to fix it (long time ago) i found the game uses 2 line interrupts but doesn't bother to check which line is interrupted, so it's based on some empirical coincidence which line starts to interrupt first. Actually programmer could easily avoid such problem, but seems was too lazy.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Sorgelig wrote: #39 is more fun :)
Last time i've tried to fix it (long time ago) i found the game uses 2 line interrupts but doesn't bother to check which line is interrupted, so it's based on some empirical coincidence which line starts to interrupt first. Actually programmer could easily avoid such problem, but seems was too lazy.
That one definitely relies on timing.

I see that VRAM writes are happening a little too fast on this machine (also from CPUTest); there should be additional wait states injected against CPU accesses, based on unavailability during scan. I thought I saw some code already doing this, but it may not be enough. Hint: different number of access slots available depending on dot clock.

I’ll get to that eventually, but that one might take some time since it’s quite complex. I suggest a release once the correction to the sync/rcr irq code is in, before I start on the next thing.
drj3rk
Atari freak
Atari freak
Posts: 62
Joined: Tue May 14, 2019 10:12 pm

Re: PC Engine core

Post by drj3rk »

dshadoff wrote:
Sorgelig wrote: #39 is more fun :)
Last time i've tried to fix it (long time ago) i found the game uses 2 line interrupts but doesn't bother to check which line is interrupted, so it's based on some empirical coincidence which line starts to interrupt first. Actually programmer could easily avoid such problem, but seems was too lazy.
That one definitely relies on timing.

I see that VRAM writes are happening a little too fast on this machine (also from CPUTest); there should be additional wait states injected against CPU accesses, based on unavailability during scan. I thought I saw some code already doing this, but it may not be enough. Hint: different number of access slots available depending on dot clock.

I’ll get to that eventually, but that one might take some time since it’s quite complex. I suggest a release once the correction to the sync/rcr irq code is in, before I start on the next thing.
This is my favorite core. It's quite interesting to see some of the video functions get debugged like this. Nice work!
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

I have checked in a correction to VSYNC timing and to RCR timing (separate check-ins at https://github.com/dshadoff/TurboGrafx16_MiSTer ).

Based on measurements from a real machine, VSYNC interrupt occurs at the transition from HDS to HDW on the first non-visible scanline.
Also, RCR interrupt occurs about 12-13 VDC cycles before the end of HDW, as the render engine prepares the final display pixels.

More discussion on these timings can be found here:
http://pcengine.proboards.com/thread/90 ... llTo=12272

In making these changes, several issues were fixed as previously mentioned.
However, I noticed that some other measurements are still off, and there were some new issues introduced - notably, a change in behaviour during the introduction to Bomberman '94.

In order to reduce the visual impact of these changes, I set the RCR interrupt to 11 cycles before the end of HDW, and one line early (leaving comments to go back and fix once other timings are corrected).

In order to correct other timings, it looks like the video engine will need to properly observe all of the video controller register settings, instead of calculating many of its own values as it does today (plus some other timing corrections).

For example, HDS is currently calculated by MiSTer in order to centre the image on HDMI and VGA, but on the original system it is set by games to ensure proper placement on the original screens; signal timing happens as a consequence. (if correcting this results in off-centre images on HDMI, there can always be a post-processing layer added if necessary).

Sorgelig, is this what you meant by "need a full rewrite" ? Measuring and adjusting timings like this ? Or is there another deeper infrastructure layer underneath which also needs attention ?

I don't mind doing incremental work like this; I just want to know what I'm getting myself into.
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 »

Well, more you trying to fix - more you understand the internals and probably why something made not exactly like in real HW. Some adjustments were done to compensate one problems without making new problems. So when you start to make some part exactly as in real HW you will instantly see that other parts need to be fixed. VDC needs a proper timings in all aspects: when sprites are exactly fetched, when they analysed, when they drawn on the line buffer. Same for tiles. When different registers are applied. Some games change registers like scroll X/Y at specific time keeping in mind exact timings, but in this core it gives improper effect. That's why some games have broken lines on edges of scrolling area. You can tweak some timings like interrupts for one game, but other game may become broken. Because VDC has state machines not resembling the real HW state machines. So you already see it.
This is why i've told VDC needs full rewrite. It's impossible to fix it by patch in couple lines.
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 »

Video on HDMI in MiSTer is centered only by HBlank/VBlank signals. HSync/VSync from the core doesn't affect HDMI centering.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Sorgelig wrote:Because VDC has state machines not resembling the real HW state machines. So you already see it.
This is why i've told VDC needs full rewrite. It's impossible to fix it by patch in couple lines.
I think it resembles the real HW state machine... but isn't an exact match. It was built without knowing all the proper timings, sequences and measurements. I expected this, and I agree that it would be ideal to know the original circuitry to avoid poking around in the dark like this.

I still believe that it needs "many small-to-medium changes", rather than a "complete rewrite", but you're more familiar with it than I am.

In any case, I will continue compiling these timings/sequences/measurements and try to adjust each part which needs fixing.
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

I was wondering whether those extra CLKEN at the end of the line in the VDC clock divider were necessary.

https://github.com/MiSTer-devel/TurboGr ... 0.vhd#L213
https://github.com/MiSTer-devel/TurboGr ... 0.vhd#L244

I found in the link below that those should be removed so that in 5 & 10 Mhz there is one slightly longer clock cycle. That means that currently there is one VDC cycle too many per line.
Note that in the 5.36MHz timing on the bottom, the 1st clock pulse after the /hsync is lowered (the yellow line) is extended by 1/4 cycle (== 1 clock @21.47MHz) to make the timing work.
http://pcengine.proboards.com/post/7842/thread
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

I'm still not clear on what the _FF versus _FS signals are in those two groups...

The CPUtest program has a roughly vertical line which looks nearly exactly like the one on the real machine, so I would classify this as a minor problem if it is a problem at all (although - maybe this quarter-clock already exists in the line, but in the wrong place).

The thing that's bothering me is that I'm not clear why the 10MHz dotclock mode is one pixel late (shifted right) on the screen, where the other modes are not... I would have expected all or nothing...
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

dshadoff wrote:I'm still not clear on what the _FF versus _FS signals are in those two groups...
The _FF signals are used in the core. The _FS signals are only used for the MiSTer video output and the dotclock of the _FS signals is only latched once per frame so the scaler is happy. This does mean that the video output and core video pixels are not aligned if the dotclock is changed midframe.

If you set 256 pixels at the top and 512 at the bottom with the Split-resolution demo then the 512 part is very pixelated. Maybe there should be an option to use the original dotclock so you can enable it if you only use the analog video output.
dshadoff wrote: The CPUtest program has a roughly vertical line which looks nearly exactly like the one on the real machine, so I would classify this as a minor problem if it is a problem at all (although - maybe this quarter-clock already exists in the line, but in the wrong place).
The quarter clock is caused by the 2 cycles that are left at the end of the line (2730-341*8). Currently it incorrectly generates another VDC cycle at the end of the line so there are 342 VDC cycles at 5MHz mode. Maybe this does not appear as a problem with the CPUtest but it is still wrong. Easy fix though.

I think I figured out why the 10Mhz is shifted one pixel. The rendering pipeline takes 4 master cycles to update COLNO_FF so at 10Mhz. However the first part (REN_INI) starts 1 cycle after CLK_EN goes high so it also updates COLNO_FF 1 cycle after CLK_EN with the VDC clock at 10Mhz. When the VDC clock is 5 or 7Mhz the pipeline is always finished before CLK_EN goes high.

It would be fixed if the REN_INI part starts at the same cycle as CLK_EN is high. Although it seems to me that it needs a rewrite so that the rendering part runs on the VDC clock instead of the 43Mhz master clock?
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Thanks for clarifying FF versus FS - that makes sense.

I knew something was one clock delayed; I just wasn't clear on the mechanism of the delay.
If you already know the correction for the 2 cycles at the end of the line, I'll take it and integrate it in my source base. The next thing I am working on is verifying the BYR/BXR latch is happening at the correct time, so it'll go well in testing this.

I think it would be ideal it it were rewritten as you suggest - but I don't think I'm ready to impose that level of change yet. I'm just not familiar enough with FPGAs and HDLs (yet). But I'll roll up my sleeves and make small fixes until I get the confidence to make bigger modifications. I'll get there soon...

I guess I should start reading and configuring for signal tap now.
paulbnl
Captain Atari
Captain Atari
Posts: 151
Joined: Wed Oct 24, 2018 9:43 am

Re: PC Engine core

Post by paulbnl »

dshadoff wrote: If you already know the correction for the 2 cycles at the end of the line, I'll take it and integrate it in my source base.
Just remove those two CLKEN_FF <= '1' and CLKEN_FS <= '1' lines that I linked to.
https://github.com/MiSTer-devel/TurboGr ... 0.vhd#L213
https://github.com/MiSTer-devel/TurboGr ... 0.vhd#L244
Chris23235
Captain Atari
Captain Atari
Posts: 234
Joined: Thu Aug 07, 2014 6:52 pm

Re: PC Engine core

Post by Chris23235 »

Did anybody manage to get the translated version of Out Live to work? The japanese Rom runs fine, but whenever I try the patched rom it crashes when starting a game.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Chris23235 wrote:Did anybody manage to get the translated version of Out Live to work? The japanese Rom runs fine, but whenever I try the patched rom it crashes when starting a game.
Did you try it on a real system or even an emulator ?
It's probably an incorrect patching job; on a translation patch, it would be very odd to change anything axiomatic enough to stop running on any system. My expectation is that the ROM had no header, but the patch expected a header (or vice-versa), which would cause corruption.
Chris23235
Captain Atari
Captain Atari
Posts: 234
Joined: Thu Aug 07, 2014 6:52 pm

Re: PC Engine core

Post by Chris23235 »

dshadoff wrote:
Chris23235 wrote:Did anybody manage to get the translated version of Out Live to work? The japanese Rom runs fine, but whenever I try the patched rom it crashes when starting a game.
Did you try it on a real system or even an emulator ?
It's probably an incorrect patching job; on a translation patch, it would be very odd to change anything axiomatic enough to stop running on any system. My expectation is that the ROM had no header, but the patch expected a header (or vice-versa), which would cause corruption.
First I thought so too, but to be sure, I tried it again, I used this translation patch:

https://www.romhacking.net/translations/2814/

and applied the no-intro version to the no-intro rom and it runs fine in the emulator. It is definitely an issue of the core, because I just tried the same file on the MiST core and there it works fine 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 »

Just ugly dumb patch.
Correct ROM size should be power of 2.
So after patching add padding to 512KB and it will work.
Chris23235
Captain Atari
Captain Atari
Posts: 234
Joined: Thu Aug 07, 2014 6:52 pm

Re: PC Engine core

Post by Chris23235 »

Sorgelig wrote:Just ugly dumb patch.
Correct ROM size should be power of 2.
So after patching add padding to 512KB and it will work.
Many thanks, I expanded the Rom to 512KB and this did the trick. Many thanks for the help!
Chris23235
Captain Atari
Captain Atari
Posts: 234
Joined: Thu Aug 07, 2014 6:52 pm

Re: PC Engine core

Post by Chris23235 »

The PC Engine core was updated:
TurboGrafx-16:
- Use SDRAM instead of DDR3 if present.
Just curious, are there advantages in using SDRAM over DDR3?
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

Access to DDR3 is shared with other systems, resulting in inconsistent access latencies. SDRAM is far more consistent.
Chris23235
Captain Atari
Captain Atari
Posts: 234
Joined: Thu Aug 07, 2014 6:52 pm

Re: PC Engine core

Post by Chris23235 »

I see, thanks for the info, could have thought of it myself.
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

I've just submitted a pull request with a reasonably large change to the 6270 coding.

- Fixes Air Zonk (GitHub #27), Dungeon Explorer (#31), Pac Land (#37), OutRun (#46), Power Drift (#47)
- Corrects RCR & VBLANK timing as per tests created specifically to validate

- Appears to improve (maybe even fix ?) Bomberman '94 (GitHub #29), Street Fighter II (#34)

Sadly, it makes Andre Panza worse; I think this is related to the timing of the CPU-VRAM slots which will need to be addressed separately. This will be another invasive change, which is why I'm committing this now. This was the only game I tested with negative consequence.

I have some more fixes/improvements (mostly non-video) queued up once this is accepted, and video will continue to need more investment.
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 »

Thanks for fixes!
It seems fixes many scrolling games with glitches on the top/bottom scroll lines. Side Arms was one of them - also fixed.
Kick boxing game is a small trade off. Not sure if anyone really like to play this game ;)
dshadoff
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Dec 29, 2019 9:07 pm

Re: PC Engine core

Post by dshadoff »

I'm glad we agree on this. =)
I'll get this fixed eventually though. Lots of TO-DOs...
trashuncle
Atari maniac
Atari maniac
Posts: 93
Joined: Fri Jul 05, 2019 9:34 pm

Re: PC Engine core

Post by trashuncle »

So excited for more accurate PC Engine/TG-16. Air Zonk and Outrun are some of my favorites! And I can also agree that the Andre Panza game is pretty unfun and barely playable anyway, so I don't think anyone will mind for a while ;)
Locked

Return to “MiSTer”