PC Engine on v2

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • runs for me, i can load and execute .pce file, sound works, display works. F12 menu works. actual console controls (via joystick or keyboard) do not work :)

    OK that's strange - C64 joystick, PS/2 keyboard and CDTV remote all work here. The only thing I'd overlooked is that I'd forgotten that joystick port 1 interferes with keyboard scanning, and because the V2 io module merges CDTV remote buttons into the C64 keyboard matrix, that was causing some interference. See if you have more luck with this one?


    (The io module still isn't working 100% by the way - I ran the HWTest a few minutes ago (via JTAG), and neither keyboard nor joystick worked at all. I then re-ran it via JTAG half a dozen times and it was fine every time.)

  • played around some more.... both cores work in standalone mode. in cartridge mode the second one registers "enter" on the ps/2 keyboard to start a game, but then the joystick apparently is being constantly "pressed" up/right/fire (perhaps polarity of signals reversed?)


    the source is on your github, so i can stare at it a bit, i guess? :)

  • played around some more.... both cores work in standalone mode. in cartridge mode the second one registers "enter" on the ps/2 keyboard to start a game, but then the joystick apparently is being constantly "pressed" up/right/fire (perhaps polarity of signals reversed?)


    the source is on your github, so i can stare at it a bit, i guess? :)

    OK. I must confess I've only tested in Cartridge mode (on my C64C) but it works there, so it's not a simple case of polarity reversal.


    The only thing I can think of that might cause problems is the IO module being clocked at 126MHz (the HWTest runs it at 100MHz) - there's an 84MHz clock available, too, so it might be happier running on that, but the ena_1mhz signal will need to be moved to that clock, too - and its counter adjusted accordingly.


    If you want to play with it from GitHub, the Chameleon V2 target is on the "split rom" branch. Otherwise I'll take another look late tonight.

  • it'd be great if you'd have a look... i will play around with it a bit perhaps, but it'd be pure luck if i find a solution for this :)

    Sure, no problem. In the meantime I saw in another thread that you have several C64s to hand - if you get a chance, could you let me know whether the issue's the same on all of them, or if it varies at all between machines?

  • Tried with 6 different C64s... same behaviour for the first core. With the second core on two of them it looks like the joystick lines randomly change (in salamander the player moves randomly up/down, but still to the right always).

  • OK thanks for that. Are any of the 6 C64Cs or are they all breadbins?

    Here's another core, with the IO stuff migrated to the 84MHz clock - please let me know if this behaves any differently. (It won't fix things completely because there's still a small window where the joystick interferes with keyboard scanning. The symptom will be releasing the joystick causing a phantom triggering of the start button. I may end up pulling the CDTV controller module into the toplevel and not allowing it to be merged with the keyboard, in order to avoid this issue. )

  • all kinds of C64s, breadbin, c64c, pal, ntsc, MK1, MK2 etc :)


    unfortunately this core seems to behave the same (only tested on my main c64, which is a PAL C64C) :(

  • all kinds of C64s, breadbin, c64c, pal, ntsc, MK1, MK2 etc :)


    unfortunately this core seems to behave the same (only tested on my main c64, which is a PAL C64C) :(

    Sounds like quite a collection!


    Thanks for testing - I'll see if I can devise another test to narrow the problem down. (Too bad you don't have a USB-Blaster - this would be much easier to trace using SignalTap.)

  • Not really a huge collection, just 6 machines :)


    I actuall have some usb jtag thing which i used to program the cpld in the MK2 - it might work with quartus and the chameleon too - but i have never done this before, no idea how to connect it, or even how to use it with quartus :) not sure if i could be of any help there =P

  • That JTAG cable for the C64RMK2 is for Xilinx chips. We do have spare "Altera USB Blaster" cables, but to my knowledge, your unit does not have the JTAG connector installed, because it'll conflict with the RR-Net MK3.

  • Hi,


    Here's another build - this one won't fix anything, but I've added a new page to the on-screen menu - Debug - which shows in realtime the status of the docking station ports, cdtv controller, some of the keyboard matrix and the c64 joysticks.

    When you have time could you let me know whether the numbers shown here are stable or fluctuating, and whether any of them respond to the joystick, please?

  • ok,,, i see this:


    Code
    1. 3F3F3F3F
    2. 3F3F0000
    3. 00000000


    the first row is totally stable, and nothing changes when i press keys, wiggle joysticks etc

    in the second row the leftmost two 3F react to CDTV remote, this seems stable to me too

    in the second row the rightmost two 00 are mostly zero, but occasionally show different numbers (cant tell which, its too fast)

    bottom row is all 0s most of the time, with seldom glitches to other numbers (again, cant tell)


    apparently none of these react to pressing keys on the c64 or ps/2 keyboard, or the joystick


    (this is in cartridge mode)

  • the first row is totally stable, and nothing changes when i press keys, wiggle joysticks etc

    in the second row the leftmost two 3F react to CDTV remote, this seems stable to me too

    in the second row the rightmost two 00 are mostly zero, but occasionally show different numbers (cant tell which, its too fast)

    bottom row is all 0s most of the time, with seldom glitches to other numbers (again, cant tell)

    OK thanks, that proves that the problem's with the joy and key outputs of the io module, and not being masked by something else. Here's another build with the IO module running on a clock closer to 100Mhz, and which latches the transients briefly so we can get a closer look at them. (Assuming they haven't now gone away!)

  • 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 :)


    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.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.