The '816 can now run programs!

https://youtu.be/Qlqry14JsGg

My assembler was mishandling sta (pixelAddrL),y. I was using dj-on-github's py6502 (https://github.com/dj-on-github/py6502) because it ran smoothly in the Pynq's programming environment. Fixed the problem.

Now the pixel moves across the screen, but very fast. I'm going to have to implement a timer.

I got a video transmitter working on the FPGA using the Pynq's built-in HDMI port. Got a few simple programs to run. Some of the programs have odd results.

I tried to draw a pixel moving across the screen from left to right. Here is the part of the code that draws the pixel:


ldy ballX
lda #$ff ...

Awesome! What did you do to fix it?

I changed the read/write logic so that memory transactions are launched and completed within the current cycle, instead of what I had before, where memory transactions are launched on cycle 1 and completed on cycle 2. I misunderstood the datasheet and assumed ...

Eureka!

Yes, there was tremendous confusion on my part. I currently launch memory accesses on the falling edge of PHI2, after capturing the bank address and A. The read value is presented in the next cycle while PHI2 is high.

IIUC, what's actually supposed to happen is the memory read completes in the ...

Thank you all for the advice! Why, yes, I am a bit of a novice... I knew it was good to have caps near a chip but I didn't have any on hand, and I guessed that it wasn't terribly important.

Now I have caps on my board, and the signal is much cleaner.

Unfortunately the data lines seem to be ...

390.625GHz? Er...390.625kHz. :D
Yep, that's what I meant! :oops: Sorry, it's the weekend and my brain is asleep.

I suppose I might as well show off the project. Attached is a photo. Please don't laugh.

As I've mentioned, the FPGA is able to detect the FFFC,FFFD bootup sequence and run a program ...

Here is an oscilloscope trace of the PHI2 signal going from the FPGA to the 65816. The frequency is 390625 MHz = 100MHz / 256. Voltage is 3.3V.

The rise and fall times are about 20ns, measured from 20%-80%. Some ringing is visible- could that cause issues?

Basically, I want to reduce the rise and ...

Update: with better probe calibration, I measured a 30-40ns rise and fall time on the PHI2 pin. This is still a far cry from the datasheet's figure of 5ns max.

I've made some progress. The data lines weren't reading properly because the FPGA was misconfigured. After fixing this issue, I can read actual data coming in from the 65816 to the FPGA.

Timing issues are still present. Data is arriving late to the 816. I suspect the reason is electrical/timing ...

After some experimenting, it looks like there's a problem with syncing. The data sent out to the 65816 belongs to an earlier clock cycle than the current read cycle.

It's possible my timing constraints are incorrect. Since I don't have an oscilloscope yet, I rely on the Zynq's internal logic ...

Both clocks are driven by Zynq PLL's.

I don't have access to an oscilloscope yet, but I will soon!

Thanks for the tip. I tried sending NOPs to the chip on all data reads. The chip reads incrementing addresses, as expected. Success!

So, then I tried running a simple program on the chip. The program is designed to write some values to memory and loop indefinitely. The first instruction is LDY 123 ...

Hello,

I have a project where I'm attempting to interface a Xilinx Zynq FPGA with a real WDC65C816S. Most Verilog projects discussed here implement a 65816 or 6502 core on an FPGA, but this project is different since I am using a real, physical 65816, and turning the FPGA into an external device ...