With the new R5 board, we spotted a problem where some cartridges aren't detected when inserted. This doesn't happen if the C64 core is launched, so we know it's not a hardware issue, but rather a VHDL issue, i.e., a bug in our FPGA "program" that is the MEGA65. So time to quickly get to the bottom of it and fix it.
One of the cartridges that used to work fine, but is no longer detected is Sam's Journey, which I have one of here. I have an R5 board here, so that's the key ingredients.
To add to the recipe, I have ordered and assembled a couple of cartridge port break-out boards that will let me probe all signals on the cartridge port much more easily than in the past. I'm hoping that with the R5's new bi-directional controllable expansion port pins, that I am just driving one of those incorrectly, and that with this break-out board, the solution of the problem will be swift and decisive. Let's see if my expectations play out in reality...
The PCBs were only US$5 from PCBway for 10 (I don't have any special deal with them, they are just who I use to build PCBs), and as I was already getting some other PCBs manufactured, didn't even cost me any extra postage, which was nice.
As you can see above, I have assembled two of them, one with a pass-through cartridge port connector to plug Sam's Journey into, and one without. The one without is in case I decide to make a special bitstream for this debugging, that would let me read all the cartridge port lines at high-speed using a 2nd MEGA65 board. I'm hopeful that I won't need that right now, though. But it might still be handy for debugging some other cartridges that we never got working with the MEGA65 core, but work with the C64 core, as we will be able to see what has gone wrong.
So let's hook it all up:
And sure enough, it doesn't detect, and my MEGA65 boots straight into MEGA65 mode BASIC.
Let's start by probing the /GAME and /EXROM lines. Well, it would help if I connected the jumpers on the cartridge port break-out board to enable them first...
Okay, with that connected, I now get a black screen. So the CBM80 signature of the cartridge must be being detected. But presumably either the IO1 or IO2 area is not working properly, causing the cartridge to fail to change ROM banks. Or at least that's my theory.
I can't see IO1 or IO2 go low when accessing $DExx or $DFxx. I've just checked on the FPGA pin assignments for those against the schematic, and they match. They do go through a level-converter buffer that has an /OE line. Is that correctly handled? That's controlled by F_CTRL_EN on FPGA pin G18. And that's a change from the R3A board, in that G18 now has a pull-up on it, which was not there on the R3A. Thus it has to be actively driven low by the FPGA.
Let's synthesise that, and see if it fixes the problem. I'm pretty hopeful that it will.
In the process, I also noticed another improvement we could make for any future R7 board: R/W line is currently not open-collector, and it would be easy to make it so.
And, with that fix, Sam's Journey starts again :)
So that probably fixes the C64 carts not being detected. This will of course also apply to the electrically identical R6 boards that are being produced by Trenz Electronic right now to clear the entire back-order queue.
In short, as hoped, by having the right tools (the cartridge port break-out boards) this was a much quicker and simpler job than it would have otherwise been.
I'll leave it there, for an uncharacteristically short blog post.
No comments:
Post a Comment