Yes -- this arrangement automatically gives you a PHI2 clock with 8 phases 45 degrees apart. Probably no point in using a PLL to generate other phases.

Here's the schematic of the FPGA: download/file.php?id=430 Most of the pins on the left side of the symbol go to the 6502, and 16 pin GPIO, and most of the pins on the right go to SRAM, plus some for SPI, UART and a LED. And you'll need a few more address lines for the bigger SRAM. However, I connected all CPU pins, and that's probably not really necessary.


If 12 bit VGA is enough, it should be possible to use the v1 design with a few modifications.

I think most keyboards support PS/2 over the USB cable, so my vote would be for a USB socket, and start with PS/2 protocol, but keep the option open to support USB devices.

How about audio out ?

I don't have any string feelings about keyboard support, and USB is certainly going to be more common and potentially more useful. If for nothing else than charging my phone...

Regarding audio -- there are many approaches possible here. If processing power were not a factor, I'd probably want a 44.1 kHz stereo audio codec. But if the sound will be generated by the 65C02 or 65C816 directly, it makes sense to scale this down a bit. As I recall, machines from circa 1990 often had an 8 kHz mono 8-bit codec chip, which is probably within the realm of possibilities for a fast 65C02 or 65C816 to work with. I guess it also depends for what purpose you have in mind to put this machine. I prefer an audio codec for general purpose use. But if you have in mind specific applications (like gaming), then other choices may make more sense. Perhaps a third choice would be to provide some kind of audio accelerator which would, for example, allow the 65C02 to pre-generate various sounds, store them in memory somewhere, and then tell the FPGA to play the sequences at specific times of its choosing. That would offload the processing from the CPU but allow high quality sound to be generated if desired (at the cost of some memory).

Thanks for the schematic -- I will spend some time with it a bit later today and probably come back with questions...

I was thinking about a simple I2S chip, like the PCM1744: http://www.ti.com/lit/ds/symlink/pcm1744.pdf It only requires 4 wires to the FPGA, and produces CD quality stereo out. How you would use it in the system is up to you. Possible options include playing samples from RAM/SD card, or use the FPGA to implement a retro sound chip that can be controlled by the 65C02.

I like this solution for audio output. What about audio input? I think that would be a nice option to include as well. An 8-bit 8+ kHz ADC would be adequate, and they come in SPI flavors as well (e.g. Microchip MCP3202-CI/SN).

How about PCM1808 or the AK5358, which are specifically made as audio input ADCs (stereo, 24 bit, up to 96 ksps). But it would depend on the I/O availability.

I was also thinking about using SDRAM instead of SRAM. Instead of 1MB of SRAM, you can get 32MB of SDRAM, using fewer I/O pins, and less money. And as long as you stay in the same page, a random read only takes 3 cycles @ 133MHz, which is still fast enough to support an 8 MHz CPU without wait states. Since you need to offer a windowed view of the RAM anyway, the window could be aligned with the SDRAM page, so you could do random access anywhere in that window. When moving the window, the SDRAM interface would have enough time to activate the new page. Everything outside the SDRAM window, such as executable code, zeropage, stack, and working memory would be mapped to FPGA internal RAM.

Sure, that works too. I was thinking of a DC-coupled DAQ-style input which could be used for audio or other purposes as opposed to a dedicated audio unit, but without a specific application in mind, I could go either way.


What sort of clocking arrangement were you thinking of? We'll need to keep the following in mind:

• VGA clock wants to be 25.175 MHz. VGA memory access can't be delayed, but a FIFO can be used if necessary.
• Would like to run the 65C02/65C816 as fast as possible -- e.g. as close to the limit of 8 MHz as possible.
• SDRAM limit is ~133 MHz.

A system clock frequency of 125.875 MHz would allow you to keep everything in the same clock domain: VGA would be /5, PHI2 would be /16, and the SDRAM can run at the system clock frequency. Otherwise the additional synchronization between clock domains could introduce excessive latency into the system, even though it may allow slightly higher clocking rates.

This doesn't factor in the audio codecs at all either, though since they are low speed devices synchronization won't be an issue if they need their own clock domain.

Did you want to consider making this work both with a 65C02 and a 65C816, or just stick with the 65C02? If the former then it would be worth spending some time to come up with an MMU scheme for the 65C02 that maps onto the 65C816 addressing scheme relatively cleanly. The SDRAM would need to be fast enough to do a random access for the VGA at 25.175 MHz if memory access is to be interleaved with the CPU. At first glance, I don't see any problems there, however.

Would also be nice to have some kind of off-CPU DMA engine available for moving memory around at high speeds. Nice to have for video acceleration, audio, and perhaps even moderately high-speed I/O (e.g. between a microSD card and memory directly rather than going trough the CPU).

In the end, the CPU winds up being like a traffic cop just directing traffic rather than doing any heavy lifting itself.

VGA doesn't need to be exactly 25.175 MHz, especially not with any kind of modern monitor, but video can easily run asynchronously with everything else by using a block RAM as async FIFO between the clock domains, so whatever is closest to 25.175 should work. A FIFO also takes care of variation in SDRAM timing, or additional video processing, like sprite handling. Video can then run in arbitrary bursts around the CPU access.


Or 133 MHz, and /16 for 8.3MHz PHI2. Slightly overclocked, but I don't expect problems from what I hear from others, or 128 MHz and /16 for exact 8 MHz PHI2.


Mostly 65C02, but try to keep it 65C816 compatible if possible with a minimum of compromises.


Yes, that should be possible and quite helpful.

I'm all for overclocking. Typing this from a i5-3570 running at 4.0 GHz... Need all you can get when running ISE or Quartus as I'm sure you know!


BDD has nearly convinced me that my anti-65C816 bias is unjustified. So I picked one up recently. If it doesn't cause too many issues for the design, I would love to build two boards, one with a 65C02 and the other with a 65C816.


OK, we are in violent agreement then!

On my other board I had a PLCC CPU in a socket, so you could easily change it. I was planning to do that again.

I've got SDRAM attached to FPGA and routed. The SDRAM is a MT48LC32M8, but will also fit a MT48LC64M8. It's 8 bit wide, and it has 4 banks of 8MB. The idea is that 2 banks will be available for the CPU, and 2 banks for the video generator. Random CPU accesses to the same page, in a bank not in use by the video generator should be possible without delay. Accesses that conflict with video may result in a few cycles of clock stretching. By flipping two video pages back and forth between CPU and video generator, it should be possible to avoid that.

I took some care to make the trace lengths between FPGA and SDRAM similar (within 2 mm), so as not to generate any unnecessary skew. I'm planning a 4 layer board from Eurocircuits (0.15mm trace/clearance and 0.25mm drill). With the smaller SDRAM pitch, compared to the SRAM, it would result in too much layout compromises to try this on a double sided board. Also, I'm using 0402 bypass caps.

If there's interest, I can reflow the boards, and sell them at cost. I'll also make the Eagle files available if anybody wants make modifications.

Very nice work. You work fast! Is this your V1 board with the SRAM replaced with SDRAM?


I agree with your choices. I'd probably go with a different board manufacturer like dirtypcbs.com as I have used them before, but I'm guessing you have used Eurocircuits before as well and are happy with them. Four or more layers is the only way to go on high density boards like this and winds up being a lot easier to route as well.


Let me know if you get enough interest to make this possible as I might be interested. Time allowing, I'd like to re-enter your design into Altium Designer possibly along with some small changes and then have the boards manufactured myself as well. Either way, it would be great if you are not the only one testing this new design when it is ready to go and I will join you one way or another.

I'm definitely going to reflow this for myself, so I'll order the stencil anyway. It's no problem to make a few more.

Yes I've worked with eurocircuits before for dozens of other designs and probably over 1000 boards total.

The Eagle schematic and board file are available on github. You should be able to view the files with free Eagle, but you won't be able to edit because of its two layer restriction.

https://github.com/Arlet/6502-sandbox

Some stuff is new, some is from V1, or V2. The schematic of the CPU shows which pins I intend to connect to FPGA, so you can already look at that and let me know if you disagree, or spot a mistake.