The WDC65C02 is, regardless of clock speed, much faster at transitioning from one phase to another. Timing has to be kept tighter as this internal speed makes it less tolerant. WDC may have not been too careful about how they internally produced the Phi2O signal making it essentially useless. Given ...

I'm not sure what you mean by technique. I am using a professionally fabricated PCB made from the KiCad designs in the Github repo, if that's what you mean.

I had already switched to using the clock signal from the PHI2 input on Pin 37, and it solved my problem. My question was just a matter of ...

Looking around the forum and reading the datasheet, I gather that using PHI2O is no longer recommended. Before looking here, I found this out the hard way when my SBC stopped working after I attached a character LCD using these instructions, http://6502.org/mini-projects/optrexlcd/lcd.htm, using ...

Hoglet, thanks for pointing me to your core. Yes, I believe it should fit. Arlet's 6502 core alone takes 40% of the slices on the XC3S50A, and my top module adds another 8% so far. I'll probably stick with the classic core for now since I cut my teeth programming the 6502 on the C64 (only last year ...

Michael, I did get it working on the target board. Thanks for your detailed explanation about the differences between simulation and actual behavior of the FPGA. I will have to read a few more times to fully digest it, but I will definitely keep in mind going forward.

The first test program I wrote ...

I got it working. The trick was I had to delay the address my output multiplexer was using by one cycle.

Edit: here is what finally worked for anyone interested: https://github.com/jblang/verilog-6502

Michael,

Thanks for the suggestions. I think I have my RAM set up the way you suggested now:


module ram(clk, addr, data_in, data_out, cs, we);

parameter ADDR_WIDTH = 11;
parameter DATA_WIDTH = 8;
parameter INIT_FILE = "";

input clk;
input [ADDR_WIDTH-1:0] addr;
input [DATA_WIDTH-1:0] data_in ...

I looked at how SpacedCowboy had implemented his ram and modified mine to match, and now my simulation looks right.

This is my corrected ram implementation: https://gist.github.com/jblang/febdcc0b6987ff5d52e60e40f35fdfc0

It's still not running right on my FPGA yet but I still need to do a bit ...

I'm also trying to get Arlet's core working and I'm having some trouble with the memory timing. I tried to synthesize it on a Spartan XC3S50A FPGA board couldn't get it to work, so I tried simulating it.

Here is my test bench: https://gist.github.com/jblang/a7fed634811a3df8587e2c1eea1a1eae
And my ...

Not sure where you got that information.

By disassembling it. The code is almost identical to Micromon, albeit with some functionality removed. The biggest difference is that MADS uses zero page for a lot of variables whereas Micromon puts them in the tape buffer. Many of the subroutines are ...

Do you have any means to access a d64 image from your commodore? Either by writing it to a real disk or something that reads SD cards like a SD2IEC or a 1541-Ultimate-III? If so, you can find the disk image for it here, and it would be a lot easier than trying to enter it: http://www.bombjack.org ...

While I had monitors on my mind, I also decided to take a look at Micromon 64, which Bill Yee converted to the C64 from the VIC-20. It was available as a type-in program in Compute's First Book of Commodore. I contacted him and asked him if he had any sources for it, and his answer was "no, because ...

Regarding the earlier discussion as to the provenance of some of the code in Supermon64, I found a Compute article with the original Supermon for PET which credits.


DISSASSEMBLER BY WOZNIAK/BAUM
SINGLE STEP BY JIM RUSSO
MOST OTHER STUFF (,HAFT) BY BILL SEILER
TIDIED & WRAPPED BY JIM BUTTERFIELD ...

The relocator doesn't just adjust the high byte of the address though, it adjusts both high and low, and for that the address needs to be contiguous. Supermon isn't necessarily loaded at the same place within the page each time. It depends what other machine code has already been loaded and lowered ...

The relocator code as it was originally written doesn't handle them. It expects the lower and upper bytes to be consecutive within the binary. If the code had something like LDA #>VECTOR .. LDY #<VECTOR, the bytes in the address would be separated from each other by the intervening opcode, and would ...