The SRAM is a Cypress CY7C1019DV33, 128k*8 with 10 ns access time. I'm planning to use it for both program/data space as well as video storage. I picked the 96 MHz internal clock with the intention of using the same clock to access the SRAM, giving 12 memory clock cycles for each PHI2 cycle. Out of those 12, one will be needed to service the 6502, and the other 11 can be used for video access.

In addition, I can use the block RAMs for additional storage without having to worry about SRAM access.

Here's a close up of the 50 MHz canned oscillator. It just happened to fit nicely on the 100 mil grid intended for the GPIO header, with the clock output pin matching up with a GCLK input of the FPGA. As the FPGA is configured, it writes a "0" to the GND pin, and a "1" to the VCC pin of the oscillator, so I didn't have to add any patch wires

Configuration from M25P80 SPI Flash is also working correctly, so a push on the button reconfigures the FPGA, which then resets the 6502.

You had mentioned before I think, that the SPI flash can also store user programs and data in, addition to configurating the FPGA, for available transfer into the high speed FPGA blockRAM. I use SPI flash for my project exclusively for nonvolatile storage for this purpose. Although I have not worked on the drivers yet.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yes, but the configuration from SPI flash was new for me, so I'm happy to see it actually working. Reading the user data has less chance of mess ups, because it's just a matter of setting up user I/O pins, and the rest is all "software".

In rev 2 of my board, I also have room for a micro SD card, just like on your board. If I get that working, I'll be happy to share the code.

I appreciate that, you'll probably hit that point of development much sooner than me.
And it shouldn't be too difficult to convert to 65Org16.b. I just need to watch out for shifts and the flags, as I remember converting your I2C driver written for the 6502.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Edit: changed the trace log

I still have the "NOP" test where the data bus is fixed and tied to the EA bit pattern for the NOP instruction, but I added a small trace module to single step through the code, and send the contents of the address bus to the UART as a 16 bit hex number, plus additional control lines: This is what I get:

Added a block RAM, R/W support, so I can now run 6502 code from block RAM, and let it read/write from memory. Everything looks good, so far. I won't have time tomorrow, but maybe on Thursday.

By the way, the SPI Flash configuration is based on Figure 2-12 from UG380, but I don't have the resistors to terminate the CCLK signal. It's just a straight connection (but less than 0.5 inch, so pretty short). Picture from scope shows the CCLK signal on the header pins next to the SPI flash, set to the highest speed it will go (26 MHz according to spec, but closer to 30 MHz on actual silicon). At this speed, configuration is near-instantaneous.

So, if you are thinking about doing SPI Flash configuration instead of Xilinx PROMs for any future projects, you can keep that in mind.

26MHz eh? Now that is a fast FPGA config! I believe that part is cheaper than the Xilinx FPGA PROM too.

From memory I thought my FPGA was being programmed at a 6MHz cclk. I just checked and the config clock is only running @ 2MHz. Almost a full second before I see any action. Do you have a schematic for your SPI flash setup?

EDIT: Also one more question: Are you using the WDC65C02 or your softcore 6502 using the FPGA blockRAM?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The CCLK speed is programmable. Using BitGen, you can change the CCLK speed. The initial bits of the bit stream provide information regarding the configuration options, the target FPGA of the bitstream, configuration stage in which several signals are released, etc.

The BitGen properties can be changed like the synthesizer and PAR options: right-click the Generate Programming File process. If I remember correctly, unless you set a specific speed for CCLK, it will use the default, or 1 MHz. The internal oscillator's tolerance is such that it may actually run faster than 1 MHz.

On the Spartan-3AN, the VS[2:0] pins configure the clock to the internal SPI configuration memory bonded to the FPGA.

On the Spartan 3A, the VS pins define the read command for the SPI memory. In this way, the SPI configuration option can support various SPI devices from different vendors, and various SPI read modes for those parts.

Xilinx has indicated to me that they may not continue manufacturing the Platform Flash products; they can't compete in price or density with the SPI Flash offerings from several vendors. Further, since they have added the SPI configuration mode to all of their more recent FPGA families, it appears that they may not continue supporting their proprietary configuration products. Thus, their proprietary devices, XC17xx, Platform Flash (XCFxx), etc., may soon go the same way as my favorite FPGAs: Spartan-II.

BTW: Arlet, great project. Looking forward to hearing about its progress. Will follow along here.

_________________
Michael A.

I'm attaching a pdf.

I'm using the attached WDC65C02. The FPGA only implements the memory interface and other hardware, but does not have a core running.

Okay - feature creep! An idea that's been floating around my head for a while is to make a board very similar to this but with the following changes:-

1) Provide hardware SPI support using something akin to Daryl's 65SPI chip http://sbc.rictor.org/65spi.html. Daryl's design (and I apologise for not having spoken to him about this first) uses a 44 pin FPGA and I wonder if there's space in the FPGA on this board to include the functionality?

2) Provide some 'arduino' spaced connectors. This would allow a lot of 'shields' (particularly those that at 'bit-bashed' or driven via SPI) to be hardware compatible. Okay, the analog support would be missing but... Since the Arduino boards are mainly 8-bit it's not as though it would be trying to shoehorn 16-bit support from an 8-bit micro. Sure, there are voltage levels to consider but it would allow use of boards like this https://www.olimex.com/Products/Modules/Video/MOD-VGA-32MB video card card that includes keyboard support.

Just an idea to throw in...

Simon

The SPI interface for the flash is already available on header pins, so if I add one extra select signal, it could be used for controlling external peripherals. There's no problem fitting the logic in the FPGA.

A full blown shield would involve too many I/O pins, I'm afraid. Bigger FPGAs exist, but only in BGA packages.

Edit:By the way, for the next revision I have video output planned to be integrated on the board, but with a PAL/NTSC encoder for connection to a TV set. I'm planning to do component/rgb, composite, and probably s-video. In addition, there will be a stereo audio output, dual USB, and a micro SD card slot.

If there's enough interest, I could also make a version that has VGA instead of TV.

I added the SRAM device. On the scope, it looks like it's working, but I still need to check the data in the FPGA/CPU. Right now, only the CPU has access to the SRAM, so I can set up really slow and easy access cycles, spread out over several clocks.

Completed SRAM/6502 interface, and successfully ran some simple read/write tests. I also added feature to switch UART tracing on/off. By typing 't' on the UART, single stepping is enabled, and UART shows trace log of addr/data/control buses. When you hit 'g', execution continues at full speed. SRAM interface is still really simple, without any other access than the 6502's. I'll worry about a proper memory controller/arbiter when I need it for video.

All 64KB of the memory is routed to the SRAM, except the F000-FFFF area goes to internal block RAM, with serves as a boot ROM.

Next steps: add UART interface for 6502, and run some bigger programs.