Friday, 17 July 2020

QMTECH Wukong board support and Audio over Digital Video testing

The HDMI-compatible audio drama might finally be coming to an end.
Adam has kindly written an implementation that uses direct FPGA lines instead of the ADV7511 chip, which we have confirmed works on the QMTECH Wukong FPGA board

The Wukong board is quite amazing: It is a complete 100T based FPGA board, that you can buy for less than the price of a single 100T FPGA!  And it has a direct HDMI output interface, which is good for our debugging purposes.

This makes it a much better option than the Numato Mimas A7 board we used previously for this, as that board had only a smaller FPGA that couldn't fit the whole MEGA65 design, so I was limited to testing the HDMI video output. Being able to fit the whole MEGA65 design means that I am able to get a head-start on the changes to the VHDL that I need to make for the MEGA65 R3 PCB, that will also have such a direct HDMI interface.

The starting point was to make a target for the Wukong board in our build environment.  Making new targets really just consists of making three files:

vivado/TARGET_gen.tcl
src/vhdl/TARGET.vhdl
src/vhdl/TARGET.xdc

The first is used to generate the Vivado project files, and is rather boring, being mostly a list of files.  I even started some work on auto-generating those, but for now, it is just hand done.

The second is the top-level VHDL, where we connect all the interfaces of the MEGA65 design to the external hardware pins, and also add any optional pieces that are required, e.g., HyperRAM controllers for boards that have HyperRAM.

The third is the list of FPGA pins and their names.

That's the easy part.  After a day or so of fiddling, I had a bitstream to try.

The next fun part is that on the current revision of the Wukong board, there is no integrated JTAG-over-USB.  This is annoying, as it means that you have to connect an external JTAG programmer to the header. I used the TET0004-02 Arrow programmer that I normally use for programming the keyboard CPLD in the MEGA65, and workout the pin arrangement to connect it up.  Also, the Wukong board has no microSD slot, so I used a PMOD microSD adapter I had laying around.  Then add the USB mini port for the serial-over-USB for the MEGA65's serial monitor interface, and then a 5V power supply, and I had it all going.

That's right, including the HMDI out, we need four different connections to the board to make it work.  They could have easily done the same as the N4DDR board or the TE-0725, and allowed it to be powered over USB, and to do JTAG over USB, so that only USB and HDMI would be required. I've contacted QMTECH about this, and they gave me a nice polite response indicating that they would likely implement at least some of that on their next revision.

Anyway, here is what the spaghetti-monster cable-salad looks like with the current revision, with close-ups of the connectors that are important to get the correct pinout for:





It took a little fiddling to get the pin-out for the microSD right, but that now works nicely. We also get a good stable HDMI image.

What is currently the problem, is that I can't switch it to C64 mode, as the CPU goes off somewhere funny when tries. 

Tracing through, it goes into the DOS ROM to do the normal C65 internal drive DOS setup up.  It's interesting going through that code. It is quite inefficient in places, such as how it initialises buffer memory using tight loops, rather than using the DMAgic controller, for example. The code to extract drive error messages is also quite fascinating in just how long it takes to get such a message out.  Neither is really a problem, except when you are single stepping through the startup trying to find a problem...

Okay, after nearly giving up, I have traced out the otherside of the DOS setup, and got to $FCF5, which is the C64 ZP and low memory setup routine.  While stepping through that, I thought I would just check if the $01 CPU register was set properly to map KERNAL and BASIC.  It looks like it is, but there seems to be something funny going on: The BASIC ROM is not visible at $A000. Rather, I see a slab of $00's.  But it isn't the RAM at $A000 showing through, because if I modify the RAM, it doesn't show up in the ROM area. Nor is it from $1A000 or $3A000. I did make sure that the BASIC ROM data is loaded at $2A000.

Ah, but it could be that it thinks that there is a cartridge... That would indeed be the case, it seems. I had tied the /GAME and /EXROM lines to Z for high-impedance, but in the absence of an actual driving signal, that results in a low rather than high signal when read.  

So I made some changes to the VHDL to fix that, but in the meantime, I thought I would try to use the Hypervisor option to disable cartridges to work around it temporarily and let me get to C64 mode where I could test audio, without having to wait for the new bitstream. That was all going fine, until I started smelling magic smoke.  I still don't know that happened, but I think the JTAG programmer must have rested on something in a way that shorted it out. Anyway, as you can see, the power lead got a bit melty:

Fortunately it didn't let all of the magic smoke out. Its a bit tricky to get it to programme the FPGA now, but it still usually works.

So I was finally able to switch to C64 mode, and load a game that I know makes noise at the intro screen, and confirm that, yes, we now have audio coming out of the HDMI TV I have connected up to it:



The audio sounds nice and clean, if a little quiet.  But we can easily increase the gain in the MEGA65's audio mixer to compensate. 

It's hard to test much more on the Wukong board right now, because I don't have keyboard or joystick inputs hooked up to it. I do have a spare MEGA65 prototype keyboard here, but not a cable to hook it up. And, besides, I don't really need to for testing purposes.

What I will do, though, is make a D81 to be the default disk image, and put an auto-booting version of Commando or maybe our MOD file music player, so that its easier to test other screens.  Then its just a case of flashing the bitstream to the onboard flash memory, and we will have the board all setup for easy testing of different TVs and monitors. 

Probably using the TE0790 JTAG programmer would allow me to flash it from vivado, but after letting magic smoke out of the Arrow one, I'm not that keen on risking the TE0790, since ordering replacement parts in the middle of the Outback takes weeks.  I'll have a think about how I work around that soon.

But the main thing is that we now have an updated HDMI audio test platform, that I can use to test all the TVs around the place up here -- in particular the Sony one, as those are renowned for being picky about the audio framing.

No comments:

Post a Comment