PC Engine core

[daverhodus]

What does the "ROM Data Swap" option mean?

Devil's Crush now has flickering lines just under the scoreboard.

Have you noticed the Devil's Crush intro looking weird? Like the sprites are messed up.

[dshadoff]

What does the "ROM Data Swap" option mean?

The TurboGrafx-16 was a virtually identical machine to the PC-Engine, with a few minor differences. One was (seemingly) a protection measure where the data bus on the cartridge port had a reversed bit order from the Japanese version. So, if you ripped a US game, the bits are backward and it won't play on the PC-Engine, and vice-versa.

Since the PC Engine was the original version as well as the more popular version with more (and mostly better) games for it, the bulk of the rips are in PC Engine bit sequence. Most emulator players have long since bit-reversed their American rips for convenience, so that they are conistent with the PC Engine bit order, and don't need a special load option every time they are played. However, it may be possible that some people keep their American games in their original (reversed) bit order, so this option will reverse them in this case.

Devil's Crush now has flickering lines just under the scoreboard.

Have you noticed the Devil's Crush intro looking weird? Like the sprites are messed up.

I'm not clear exactly on what you are referring to here, but as I mentioned previously in the thread, the timing is pretty strict on many games, and the core is currently allowing writes into VRAM without slowing them down as real hardware would - this seems to cause some issues especially at the top and bottom of screen. I plan to work on correcting this timing as my next update, and hopefully many of the remaining issues will be corrected as a result.

[theimporter]

with the last release some old bug are back, like :
mising sprites in modou king granzort , drop off , rastan 2 and puzzle boy
(sorgelic o greyrogue fix this in the pass , they work in version 20200212)
dead moon, download and jj & jeff have flicker in the presentation
final lap twin has problen in the last line in boot players and some time garbage in screen
jackie chan has flicker in the last line in the playable area

most of this bug are coment and fixed in pages 4, 5 o 6 of this threat.

thanks for the work in this core

Soukoban World is also missing sprites.

[dshadoff]

I’ll look at that as soon as I can. That’s a game where it should be easy to see.

[catenaccio]

Street Fighter II also has some flickering, anyone noticed this?

[dshadoff]

There are still quite a few imperfections around video timing; specifically, BXR/BYR latching is currently done at the correct moment, but some games manage to change VRAM and/or register values a few cycles earlier.

This appears to be primarily because the CPU is not delayed sufficiently when accessing VRAM - this aspect of the core runs much faster than Mednafen (which is faster than the real machine).

This results in some flickering, especially at the top/bottom of the screen, and occasionally left/right edges. These are known issues right now.

There is no such thing (right now) as a correctly-functioning video processor emulation for this machine (although some emulators appear better than this FPGA implementation). I will be taking measurements and making corrections as time permits, with the goal of being as accurate as possible. I am also working with Furrtek on a decapped Hu6270 chip with the same goal.

Please be patient.

[BigMac740p]

I am also working with Furrtek on a decapped Hu6270 chip with the same goal..

Great news!

[ElDoctor]

I am also working with Furrtek on a decapped Hu6270 chip with the same goal..

Great news!

The core is actually more than playable; and with some patience and the great work from the devs, great things are coming.
Thanks to all involved.

[dshadoff]

I'm now back from vacation and ready for more MiSTer action (but also need to go back to work).

I have submitted a pull request implementing the "no bootrom -> make menu appear" functionality requested in issue #60.

I also bought an additional PC Engine in Japan so I can open it up and get test measurements, though I may need to buy a better logic analyzer than I currently own.

srg320, I saw the new documentation folder with the PNG's of logic traces - this looks very helpful !
Do you have some information about the test code (and/or machine state) as these were taken ?

There are definitely circumstances where the 6270 puts the 6280 into a wait state (especially the TIA -> VRAM and TAI <- VRAM), and I believe that the official documentation doesn't describe these adequately (see here:https://www.dropbox.com/s/1bmftyh8wbruu ... S.ZIP?dl=1, in the Hu6270 Notes file, especially the MWR register, R09).

I am planning to test when wait states appear on the real machine, since there are more on the real machine than Mednafen or MiSTer.

[srg320]

srg320, I saw the new documentation folder with the PNG's of logic traces - this looks very helpful !
Do you have some information about the test code (and/or machine state) as these were taken ?

I use the DE-10 Nano+signaltap as a logic analyzer, this makes it possible to use additional logic, such as H_CNT/V_CNT in my logs. I used Screen Dimension Test and CPU Test to capture logs so far.

I found that during hblank, if there are no sprites on the line for fetching, CPU slots appear at some intervals (I don’t know which ones yet).

About wait states when accessing VDC. It looks like the first 6280 cycle pauses CPU core and checks the RDY signal. If RDY is active, the next cycle is working, otherwise the CPU core remains in a pause until RDY is activated.

[Alkadian]

Hi chaps,

New user here. I am super enjoying the MISTer FPGA project!

My apologies as I appreciate my question has been already raised in the past but I couldn't find an actual solution. I can't get my favourite game, Blazing Lazers, to work. Just a black screen.

Any advice will be very much appreciated.

Cheers

[Sorgelig]

I can't get my favourite game, Blazing Lazers, to work. Just a black screen.

Broken or incompatible ROM.
It works fine for me.

[BigMac740p]

Hi chaps,

New user here. I am super enjoying the MISTer FPGA project!

My apologies as I appreciate my question has been already raised in the past but I couldn't find an actual solution. I can't get my favourite game, Blazing Lazers, to work. Just a black screen.

Any advice will be very much appreciated.

Cheers

It's also my fav shooters all platform included. It's working fine for me, maybe a rom issues here.

[dshadoff]

Also, try with "ROM Data Swap" setting set to yes. That is an American game, and depending on your rip, may still be in the American bit sequence (reversed from Japanese). 99% of the images are already reversed, but there is a chance that this version is still in the original bit sequence.

[Alkadian]

@Sorgelig, @BigMac740p and @dshadoff

Many thanks for your kind feedback and advice. I will try tonight and report back here.

A huge thanks for now!

Cheers

[Alkadian]

Also, try with "ROM Data Swap" setting set to yes. That is an American game, and depending on your rip, may still be in the American bit sequence (reversed from Japanese). 99% of the images are already reversed, but there is a chance that this version is still in the original bit sequence.

Hi dshadoff,

That worked like a charm!!! Many thanks. I am a happy boy now! Back to play till death

Cheers

[Televicious]

Getting an out of range message on my dell 1908fp when i load the 2-20 version of the core. tried all sorts of configs. The 2-12 version works fine however.

[dshadoff]

Getting an out of range message on my dell 1908fp when i load the 2-20 version of the core. tried all sorts of configs. The 2-12 version works fine however.

Is that a type of monitor ?
Does it indicate what type of range is being violated ?
Do you have more information on what you were trying to do at the time (i.e. at menu ? not at menu, but game not yet selected ? if playing a game, which one ?) ? Resolution mode is important information.

A lot of code changed in that release, but it was mostly just interrupt timing (i.e. what pixel to display, rather than the structure of the display). The only thing I see about the structure of the display is the removal of one excess clock per scanline (commit e2d8703).

[dshadoff]

From my experience with 240p test suite releases for multiple systems on a CRT, different resolutions from a system should not necessarily be expected to display squares and circles of the same proportion, even on a CRT with properly calibrated alignment for a 4:3 ratio.

The circles in the Linearity test are supposed to be perfect circles no matter which console or resolution you use. Otherwise the 240p test suite needs to be adjusted.

In this case the circles from the linearity test were copied from the Genesis version but the PC Engine and Genesis in 320 mode output 455 and 427.5 pixels per line respectively so the PC Engine needs different circles.

I don't have time to be more detailed, but:
320 wide: big circle is roughly 9" wide
256 wide: big circle is about 8.25"

If you need more information, I can get it to you in a couple of weeks when I return.

Did you use the test version of the 240p test suite? It seems you have measured the 320x240 vs 256x224 linearity test. Those are the default ones that show up. You need to go in to options and set Vertical resolution to 224 so you'll get 320x224 and 256x224 resolutions.

We can wait a few weeks if nobody else checks it in the meantime.

OK, I'm back and I've run the test - but as I mentioned previously, it's a small monitor so accuracy is perhaps questionable, and it's not easy to take measurements on a curved surface where the phosphors are about 1/4" under the surface that you are measuring... but here is what I found:

320x224 mode: width = 8-1/4" to 8-3/8", height = 8-1/4" (estimated, as bottom edge was below visible area on the screen).
256x224 mode: width = 8-1/4", height = 8-1/4" (estimated, as bottom edge was below visible area on the screen).

The 320 mode seemed *slightly* wider; perhaps a pixel or so. Not sure if this affects your goal.

[paulbnl]

Thanks! So these results are from the linearity-PCE.rar test version?

[dshadoff]

They are from the "240pSuite_lin.pce" image; it was not in a RAR file.

This version was the download from the shmups forum post that you had linked to at that time:
https://shmups.system11.org/viewtopic.p ... 9#p1396029

Is there a more recent version which needs to be tested ?

[paulbnl]

Oh right yeah that's correct. The rar file contains the raw images. 240pSuite_lin.pce is the latest test version.

Thanks, that confirms the changes are correct. The 320 and 256 circle width being the same is the expected result.

[dshadoff]

About wait states when accessing VDC. It looks like the first 6280 cycle pauses CPU core and checks the RDY signal. If RDY is active, the next cycle is working, otherwise the CPU core remains in a pause until RDY is activated.

Yes, RDY is the mechanism which the 6270 uses to inject the wait states to the CPU ("enable" in cpu65xx.vhd). This enable is checked often in the CPU code, so that the CPU will (and should) stall if this line is asserted (I didn't verify whether it is checked in every place it should, but for now I trust that it does).

VRDY is similar, but is used for a single-cycle injection for accesses to addresses $000x (except when done directly by ST0/ST1/ST2).

One edge case scenario for VRDY wait states is for read/modify/write commands such as "TSB $0003" which should have a 1-cycle penalty for both the read phase and the write phase. While I believe that the current implementation should handle this properly, I would like to verify that it does.

I'm not yet clear on how VRDY self-clears after one cycle, as the conditions which define VRDY are based on processor state... and processor state is not supposed to change while "enable" is set (and it is set when VRDY is set). This gives me some concern about whether the existing code handles multi-cycle wait states, as these also happen with RDY.

[srg320]

One edge case scenario for VRDY wait states is for read/modify/write commands such as "TSB $0003" which should have a 1-cycle penalty for both the read phase and the write phase. While I believe that the current implementation should handle this properly, I would like to verify that it does.

For "TSB $0003" everything is predictable:

TSB $0000.png

But another thing is interesting. After reading/writing to VWR/VRR real VRAM access occurs on the third CPU slot after access to the register. During hblank, if sprites are disabled, VRAM access is possible on every second VDC cycle, i.e. on the sixth VDC cycle after reading/writing to VWR/VRR. Also, during hblank there is no VRAM access for several consecutive VDC cycles, neither the CPU slots nor the SP0-SP3 slots. The number of these cycles is equal to VDC dots % 8, i.e. 5 cycles for 5MHz mode, 7 cycles for 7MHz mode and 2 cycles for 10MHz mode. It is important for correct work of X-Cycle Tests in CPU Timing Test. After implementing these features in my CPU/VDC this test passes successfully.

20200321_175110-CPU_Test_10.png

[dshadoff]

After implementing these features in my CPU/VDC this test passes successfully.

Wow, that's great news, issue a pull request !
I'll bet that solves a lot of outstanding issues.

Actually, I just got a Saleae 16 Pro logic analyzer and spare PC Engine to run some tests for comparison between the core and real hardware. I'm still working on setting it up though.

I'll be trying to write some test cases this weekend.