I am considering building a small FPGA-based board for playing with 16-bit CPUs. I have a number of XC3S700AN chips and will cannibalize the 6502Playground breakout patterns. In addition, I have a bunch of 256KW CY7C1352B sync pipelined memories (100MHz) that are 18 bits wide that I am itching to use.

Does anyone here have any experience with CY7C1352B chips? I was hoping they would work just like the internal BRAMs, but it appears that there is an extra cycle required (unless it's operating in burst mode). That limits FMAX to 50MHz I suppose, which is somewhat disappointing but better than what I am getting now with 10ns SRAMS on CHOCHI boards.

Learning from experience, I am planning to add a USB connector for power, JTAG, a serial port, and lots of IO pins...

My wishlist (depending on area and cost constraints):
-SD card (possibly mini)
-VGA output - with at least 2 bits per color, 5 if possible - if I can find cheap resistor networks
-Keyboard/mouse connectors
It might make sense to put the above on an expansion card.

Any thoughts/suggestions?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Sounds cool! 16-bit 6502 type is the way to go IMO. Even 32-bit when we get there...
I too am using a similar synchronous memory in the new v1.0i. Thinking that an external synchronous RAM would act like the BRAM in FPGA's. Alas, they do not. But they have advantages for ease of Verilog coding...

The IC I currently use has a pin that controls the mode to be flow through or pipelined. I already have experience with the flow through mode. Keep in mind this IC is a NoBL device (No Bus Latency) but the thing is it takes 2 cycles for a complete Read or Write transaction in flow through mode. Pipelined mode takes 4 cycles, but the access time is almost cut in half...

These are just my observations, I have no advice yet.

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

I've always thought 16 bits is enough for just about everything. Thoughtful use of fixed point math makes it possible to represent many things in 16 bits. 18 bits is even better!

8 is not really enough, unfortunately. It is surprisingly complicated to do even simple things, like moving a block of memory or just loading an arbitrary amount of bytes into RAM.

32 is probably too much, but these days no one except me cares.

So I am looking forward to doing some 16 bit work.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

If your memory already supports it, 18 bits sounds a lot cooler to me, for the retro-factor.

It also adds that "little extra" ability that makes it unique and catchy. I wish that the micro-processors of the 70s and 80s had been 9/18 bit.

Octal notation might even make a comeback, if it catches on!

Mike

You should use them in burst mode, of course

How about adding a cute little FT230x in QFN16 package, like I have on my USB-Serial converter? Takes very little room, and would give you instant USB access as well.

A trick I did with my sandbox board is to use the FPGA pins in 3-state mode, so you can create more levels. A cheap way is to just put 1 resistor on each output pin, and experiment with different levels. Keep in mind that for something like retro 8 bit games, it's more important to have different colors, than an exact even spread.

Arlet, could you explain the tri-state trick? I am not following.

If I add the UBS-serial chip, I will definitely have to add a power switch or some provision to cleanly break the power flow to the system while leaving the USB chip powered. Pulling the USB cable out to power down the system would make the PC reconnect it as a different device if the terminal is open, making life very difficult.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

On Linux ? I never have that problem with USB terminals. The terminal program needs to quit whenever the USB device is gone (it gets a read error on the file descriptor), and then the USB device will be removed as well. Next time, it should get the same number. I do this all the time, and never had a problem. Maybe the terminal program is bad ?

With the tri-state trick, I had 3 FPGA output pins, each connected to a resistor. The other sides of the resistors were connected together, and attached to the VGA input (composite TV in my case). Now, each FPGA can be written with "1" to make a high level, or "0" to make a low level, but you can also write "Z" to make an intermediate level. In theory that gives you 3*3*3 combinations. What I did is write a little program on my PC to print out all the combinations, and the resulting voltage, for 3 resistor values, and then played with some standard E12 series to get a reasonable spread. Sort them in increasing order, and then put a small lookup table in the FPGA to convert brightness to output values.

It's not a problem really, just a pain in the butt. If your board is powered by USB but doesn't have a power switch, you need to
-Quit the terminal (or it will wind up holding up the device and USB will create a new one)
-Unplug/replug USB cable
-Start a new terminal
At which point my terminal loses the directory information for sending raw files and I need to do lots of clicking to get the state back.

I think I'll add a 3-pin header with Ground, VUSB and VIN. A jumper will normally connect VUSB and VIN, but allow one to connect to an external power source if needed, or add a normally-closed button to allow power interruption to reboot the FPGA.

I like the tri-state trick. With 2 pins per color you can do even better and encode it into 3 bits.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

It's becoming more real - I just received the 18-bit SRAMS!

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut