MiSTer FPGA Multi Console

[dshadoff]

(BUMP)

For any MiSTer FPGA owners out there, I was wondering how the PC Engine core is looking today ? Is CD support in a released version ?
I know that a lot of progress has been made on various other systems and arcade boards recently.

[ccovell]

The PCE core hasn't changed much in a long while.  However, SRG320 (the MegaCD MiSTer guy?) appears to be looking at the PCE core, so maybe he'll put some magic fairy dust on it soon, ultimately even a CD feature.  Rumours are mentioned here: www.youtube.com/watch?v=5mMHLxHv0oc

[dshadoff]

...But how good is the PCE core as it stands ? Is it 100% compatible/accurate ?

[ccovell]

For most games, it's pretty good. The VDC emulation is definitely not 100% accurate, but this is mostly seen in raster errors in my demos. 512-pixel mode has the rightmost column of pixels cut off. CPU runs either too fast or too slow, take your pick. As seen in this test: www.chrismcovell.com/CPUTest/index.html

[dshadoff]

So now I have a MiSTer, and ran Chris' CPU tests and can talk about my findings here.

First, while it is *not* cycle-accurate, everybody who is running it seems to be happy with it (currently limited to HuCards).

And then there is a point about memory: there are multiple possible memory spots, and MiSTer will use the best ones that it can.

1) There is some memory internal to the FPGA itself (several different terms exist for this, and one of them is 'BRAM' - please don't mix it up with "backup RAM").  This is basically high-speed static RAM which exists in very small amounts, and is precious (but available for use).  From appearances (I haven't yet verified in the FPGA code), it seems that PC Engine RAM is mapped to this.  When Chris' CPU tests are run, it seems to run pretty well when "run from RAM".

2) There is DDR3 SDRAM on the DE10-nano FPGA board itself.  Although it's high-speed, DDR3 is know as being high-latency; even though this latency shouldn't scare a PC Engine programmer, the real issue is that this memory is also used for various other duties, so there are wait states imposed by the bus arbitration on access to it.  I am told that it is in use for video scalers, the on-board ARM processor used for linux, and possibly other uses.  Knowing this, I am surprised that it runs as well as it does when running programs from DDR3, which is still better than the state of emulation from 15 years ago.

3) There is a SDRAM add-on board which is required by most cores; this is the recommended usage of the PC Engine core, and it performs as well from here as it does from "RAM".


Test feedback shows that the core is quite close, but not perfect.

On the CPU side:
- CSL does not seem to slow down the CPU.  Clock division appears to be roughed-in, but not actually implemented.
- ST0/ST1/ST2, which are 4-cycle instructions, seem to be taking 5 cycles.  This is probably a relatively easy fix, and the original author's information base may have been incomplete on this instruction.
- TDD appears to take 1 cycle longer than its block-transfer peers.  It's not clear why, based on my first look at the code.  This is probably a true bug to be found within the code (because it seems to be an obscure one).

On the video side:
- It appeared as though there was something funny with the length of time each test runs (should be exactly 1 scalene); I've received feedback through the forum that the video generation configuration was set slightly too long, which was done in order to deal with the different possible dot-clock frequencies via the MiSTer video scaler.  I am also told that this limitation no longer exists, so this should be easy to fix.
- Some of the transfer-from-VRAM instructions happen too fast; this may take some investigation to fix
- The top edge of the screen is missing several scanlines on HDMI, and the right edge is missing pixels in certain situations (but not all).  These seem to be edge-cases which need tuning, and possible initialization parameters for the VDC registers.


All in all, it seems pretty good, but could certainly be improved.  This will probably be necessary in order to prevent large numbers of CDROM-title error reports.