6502.org

Update

A minor update to the hardware and 6502 program loader is available at http://apple2.x10.mx/CHOCHI/#Bitstreams

Upon power-up, the loader now flashes the LED while waiting for a 6502 binary. This provides a positive indication that the FPGA has configured successfully, the 6502 core is operational and running loader code.

A small change to the hardware has been implemented: the LED is no longer toggled by any access to $C000. Data is required to be written to $C000; the low bit will set or reset the LED. Previously, there was no way to deterministically set or reset the LED.

Please update your board when you get a chance.

Only two connections are necessary to get started:
- Regulated 3.3V to the 2-pin connector; one of the pins is marked 3.3V (lower pin)
- Serial connection: two pins are marked RX and TX. RX goes to USB-serial board's TX, and TX to RX (usually). You should also connect the ground. Depending on your USB-serial board, the ground may be in different places. I connect the top pin to ground (solder a little wire to the ground of the power connector) and use a 3-pin cable right to the board. This depends on the pinout, which is why I left the top and bottom pins unwired in the original boards (marked DILDAR50-X1). Newer boards marked CHOCHI have the top pin connected to ground.

A 6-pin JTAG connector is also available for reconfiguring the FPGA or the platform flash using Impact and a Xilinx USB cable. The bottom pin of the connector is 2.5V (red wire on my cable, but check!).

Bringing up the board

Make sure your serial port works by starting your terminal. Set it to 115200 baud, 2 stop bits, no parity, no handshaking. Short USB-serial board's RX and TX pins. Now type something; your terminal should echo your characters.

Connect CHOCHI and power-up. Boards with new firmware will start flashing the LED. The terminal should print '6502' and wait for the binary file. I then use my terminal's (gtkterm) 'send binary file' feature to upload a file. The file should be prefixed by the location (16 bits) and size (16 bits). Immediately after the upload, the new program is executed.

If you see garbage on the screen, chances are your USB-serial board's ground is not connected to CHOCHI's ground or your terminal is misconfigured. Sometimes, a faulty power connection will reset the board, messing things up. Update your firmware (see previous message); having a flashing LED will give you some degree of confidence.

I am away from my office for a few days. When I get back I will post a FIG-FORTH binary.

As a USB connector can act as a 5v supply, how easy would it be to use one for a 3v3 board like this? How easy (or difficult) would it be to do that conversion on-board?
Just wondering, not demanding!
Cheers
Ed

I've received my board and I have everything I need to get started. Can't wait, but I have to wait.. very busy right now. Thanks to enso for posting the 'get started' procedure!

-Tor

This board has evolved from DILDAR, which was conceived as an embedded board, not a standalone system. The next revision of the board will have a 3.3V regulator as well. I had to sacrifice the left mounting hole to fit it, but it's worth it (and the board is small and light enough that one hole should suffice). I'll see if I can fit a mini-usb connector (for power only) it does make life easier to have a solid power connection.

I've agonized over putting a USB interface on-board. USB is such a disaster though, I totally hate the idea. Having an external USB-serial interface that you can buy for a few dollars still seems the best solution.

Please feel free to post or PM me with questions.

I'm using http://www.ftdichip.com/Documents/DataS ... T230X.pdf‎ this chip for my USB serial converter. The QFN package is only 4x4 mm big, and doesn't require a crystal.

My idea for the sandbox rev2 board was to mount a USB connector on the board, and feed the D+/D- into the FPGA using two 33 Ohm resistors, and implement a USB controller in the FPGA. But your FPGA is probably too small for that.

Edit: what's so bad about USB ?

It is my opinion that only a fool would replace a hardwired serial port with a protocol that requires extensive initialization, handshaking and discovery. The point of the serial port is that it's there and usually just works. For a USB connection to work, you need to do quite a bit of work in hardware (bit transformations), and a lot of software upfront. So if you are not sure your CPU works and want to transmit some data, you can't count on the USB port at all.

Implementing a USB port then pretty much requires a USB chip, raising the cost. These seem to be cheaper now, but until recently it was cheaper to just put a PIC with USB onboard. Then you have a whole other processor to deal with.

And then there is the host software on Linux, Windows or whatever. I am always fighting to keep the USB serial port from being re-assigned to another location where my terminal does not see it. And for years there were bugs with USB, incompatibilities with virtual machines, etc. My printers work sometimes, and USB drives slow down for no reason at all.

As I see it, it's another situation where things were fine until someone decided to create a 'solution'. I wish USB would just disappear. I'd pay extra to have good old serial ports on my PC.

If you have problem in Linux to find your USB device, there are some tricks: http://gnosia.anu.edu.au/wiki/FT232R#Gi ... etter_name

For example, based on the serial number, you can rename a device to something specific like /dev/chochi, instead of /dev/ttyUSB1

I agree that implementing serial over USB introduces a lot of extra complexity, but it also enables other applications, such as sticking a memory stick, printer or webcam in the same connector. Without USB, it probably would have been a bigger mess.

I've had issues as there are layers in linux that interfere with simple renaming, and you have stick the rules in somewhere so your work is available after a reboot. If my terminal is open and I unplug and re-plug the cable, it USB-serial comes up as a different port and I haven't been able to change that lately. I have to close all software that keeps the ports open, unplug, plug back in, then it works. I've had it working better, but I think the kernel was changed and it's back to this.

Overall, USB is probably a good thing, and I've seen minimal implementations that are quite small (you don't have to fill in all the information specified for discovery, just the minimum...) For mature applications it's probably easier for grandma then setting DIP switches. Serial ports in experimental systems however would be better off the old way, the way I see it.

Anyway, we've got it, so we might as well use it when it makes sense.

EDIT: having said that, I am still annoyed that it takes quite a bit of work and a few K of code to bring up a USB connection (unless you use a FTDI chip or something like that), as opposed to a few instructions to set up a serial port. And it's still not as reliable as a serial connection - if the cable is unplugged, you have to restart the connection at both ends; with a serial port, it just works.

USB is fine for consumer items like connecting your digital camera or scanner to your PC; but I have quite a few beefs against USB.

• It's not hobbyist-friendly and workbench-hackable. Too much software overhead. To have the option of such intelligence is fine; but not to require it. This is why we made such intelligence optional on 65SIB, and made the interface usable even with dumb shift registers. You can have the whole range of intelligence levels on the bus at once.
• USB is not universal if it has a half-dozen kinds of connectors.
• USB is not really a bus, if one port normally goes to only one thing.
• Battery-powered hand-held devices are not allowed to be USB controllers.
• USB connection distance is very limited compared to RS-232.
• USB is not suitable for fast bit-twiddling. Packets go fast, but it may be over a millisecond before the next packet goes out.
• A USB-to-LPT port adapter is verrrrrrry slow, as it has to emulate the LPT port over these sparsely spaced packets.

I believe that the automotive equivalent of USB is CAN (controller area network). It has gone through several revisions through the years, just like USB, but is omni-present in modern vehicles. The software overhead is similar to USB, and can be lessened somewhat through gate-way chips, but it can be just as ornery, frustrating, and expensive to a hobbyist-type project.

Mike

Might be a great starter topic for a new thread! Xilinx products have CAN controller IPs available for free for FPGA. I for one am interested in this area, as my day to day job is in automotive and I do a great deal of diagnostics...

Regarding USB, I personally like Microchip's MCP2200 which I've used in a past project with Windows XP 32-bit and free drivers provided by Microchip. I got the Tx (from the 32-bit Intel computer) speed up to 1Mbit IIRC using a "special" terminal. I think it was called Br@y terminal.

CAN on the hardware level is fairly simple. The problem is the huge amount of protocol software built on top of that.

My CHOCHI is connected to a CP2102 serial-usb board I bought on ebay. It is wired like this: Note: the board revision marked DILDAR X1 serial connector only has the pins marked RX and TX connected. For a reliable connection, the grounds must be connected as well. For this particular serial card, the simplest way to do this is to connect the top pin of CHOCHI's serial port to the ground connector of the power supply, as shown. I soldered a wire underneath.

Later boards (marked CHOCHI) will have ground connected to the top pin on the board.

Here is a binary image of FIG-FORTH, adapted for CHOCHI: The zip file contains the source code modified for Kingswood assembler, and the loadable binary.

Load it after the terminal displays the '6502' prompt. If you look at the listing you will note the following code pre-pended: This is the general pattern for creating CHOCHI binaries. The first word is the load address and entry point; the second word is size in bytes (not counting the address/size header). In this case ENTER was the lowest address, and TOP was the highest. Since the origin was $0400, I backed up 4 bytes to account for the header.