PC Engine on v2

Quote from Tobias

more weirdness...

first, i noticed when playing with the remote, the values in the second and third block are changing with some delay to the first block... sometimes

OK well the idea with the second and third block is that the second one will latch any recently seen zero bits, while the third block latches recently seen high bits - both are reset every second or so, on a fixed shedule for simplicity's sake, so it's normal for the delay to vary. The idea is just to make brief transients readable, since we don't have the luxury of signaltap here.

Quote

then... now that you asked for the fourth row, i noticed something else: when i run the core using chaco (power up, then use chaco to start the core slot) the third and fourth row are all zeros (and do not change ever). now, if i select the core in the chameleon menu, the third and fourth row will contain somehwhat random values (that dont change either) - but ONLY if there is a sd card inserted when the core starts. when i remove the sd card before, the values will also be all zeros.

That's *very* weird. Is there a schematic available for the V2 hardware?

OK let's go right back to basics here. Here's a build of Peter's hardware test core, which he updated recently to fix the transients I was seeing on my setup. So this is the same version of the IO module, built with the same version of Quartus as the PCEngine core. Could you just double check that this works correctly on your machine, please?

Quote from Tobias

hw test works, no glitches from C64 keyboard or joysticks

schematic is in the wiki: http://wiki.icomp.de/w/images/…ameleon_schematics_v2.pdf

Excellent, thanks. I think I might have cracked it - please test the attached when you have a moment.

(Comparing line-by-line the hwtest and PCE toplevel, I noticed that I wasn't writing default values to the clockport control lines, so a clockport device might be visible on the bus and interfere with the IO module. I think you have something attached to your clock port, and I don't - which is why the core was working for me and not for you.)

I still have to work around the interference between the C64's first joystick port and the keyboard, but that's relatively trivial.

Thanks for the debugging help - I've just released an updated version of the core which is basically as per the most recent debugging core but with a tweak to the io module to prevent the C64 joystick interfering with keyboard scanning. This should prevent spurious presses of the start button when a joystick is in port 1.

http://retroramblings.net/?page_id=969

After a long struggle figuring out an SDRAM problem and getting the internal firmware to fit in just 20k of block RAM, the enhanced PC Engine / TurboGrafx16 core is out now: http://retroramblings.net/?page_id=969

Supergrafx games are now supported.

CDROM games in bin/cue format are now supported.

The core has a 19-bit audio DAC, allowing the PC Engine audio to have 18-bits resolution and be mixed with 16-bit CDDA audio.

For those wanting to try out CDROM bin/cue support, please note that you need a SuperCD BIOS file such as (syscard3.pce) which you will load as though it were a game ROM. Then you can mount a .cue file. However, please note that only images with a single .bin file are currently supported - images split over multiple .bins or with the music in .wav/.mp3 files won't work.

Quote from Jens

I remember we've exchanged quite a few eMails where I've thrown you a number of hints on how to debug the SD-Ram issue, but I'd of course be interested in what the final solution was!

The only solution I found was not to do ACTa NOP ACTb RDa NOP WRTb.

On the newer Winbond chip the write appears to cancel the read and the data never arrives. This behaviour appears to be absolutely deterministic, and doesn't change with clock speed or phase shift. That pattern works on every other chip I've tested (including the older Winbond chip on TC64v1 - though fails with Micron's verilog simulation model), and is used in the SDRAM controllers of the upstream MiST Genesis and PCEngine cores. I suspect that this access pattern is not actually legal, and just happens to work on other chips by taking advantage of undefined behaviour.

I ended up re-writing the controller more or less from scratch - it still makes heavy use of bank interleaving, but doesn't attempt to overlap reads and writes quite so aggressively.