Chameleon

Description

The Chameleon Arduino-compatible FPGA shield board is intended to operate as a customizable peripheral of an Arduino UNO. User programmable level shifters buffer 12 UNO signals. On board SPI Flash and FRAM, and parallel 128kB SRAM allow the board to be used for any number of projects. As provided in the initial announcement/release, the Chameleon integrates the microprogrammed M65C02 soft-core processor with two buffered UARTs, a buffered SPI master interface controller, an interrupt controller, and an MMU. A follow-on release will add an external memory interface to support the 128kB SRAM (on the back), and incorporate an SSP-compatible slave interface as found on NXP LPC21xx AMR7TDI microcomputers.

The M65C02 microprogrammed soft-core processor uses 2 block RAMs for microprogram storage. One block RAM is set aside to support an on-chip 2kB Boot ROM. The remaining block RAMs are allocated as a 16kB, an 8kB block, and a spare 2kB block RAM.

Details

The Chameleon Arduino-compatible shield board was designed to support two general application areas: (1) soft-core processors, and (2) intelligent serial communications interface. The board was constructed to be compatible with the form-factor of the Arduino UNO. A similar design uses a form-factor suitable for use in a Pac-Tec DIN-rail enclosure. The Arduino UNO form-factor is small and popular with students and hobbyists. Although, the Arduino UNO form-factor may not be ideal for industrial applications, its small size makes it rugged enough for many industrial applications.

The small form-factor also presents a challenge. The greatest challenge in implementing the Chameleon for its intended applications was to keep the on-board features to those that would provide the greatest utility if the board was used in a standalone manner in addition to being used as an Arduino shield. In addition, although surface mount technology (SMT) would be required to implement the Chameleon, every effort was made to use SMT parts that a hobbyist could install by hand and a soldering iron. (The Chameleon board pictured was assembled by hand and a soldering iron.)

Thus, the VQ100 package was selected for the FPGA because it is the smallest QFP package from Xilinx which supports multiple FPGAs: the Spartan 3A XC3S50A-4VQG100I and XC3S200A-4VQG100I FPGAs. Interestingly, the board area used by the VQ100 package is also the same as the board area of the FG256 (BGA) package. All members of the Spartan 3A family are packaged in the FG256 or FT256 package. The BGA package will be used in more advanced versions of the Chameleon.

However, for this project cost and ease of assembly were the driving factors. Thus, only the XC3S50A and the XC3S200A in the VQ100 package were considered. Either FPGA may be used on the Chameleon. For an effective soft-core processor platform, the XC3S200A FPGA is a much better choice than the XC3S50A. The soft-core processor that I've already developed and proven on a similar FPGA development board, the M65C02, will fit in the XC3S50A FPGA. However, the complete 65C02-compatible core will utilize more than 50% of the logic and 2/3 of the block RAMs available in that FPGA. Thus, there would be few resources left in that FPGA to include on-chip RAM or peripherals such as UARTs, SPI masters, timers, etc. If the XC3S200A FPGA is used, then the M65C02 core can be incorporated along with two buffered UARTs (with 16 byte Rx/Tx FIFOs) and a buffered SPI master (also with 16 byte Tx/Rx FIFOs). This configuration of soft-core processor and peripheral uses only 50% of the XC3S200A FPGA, which leaves plenty of logic resources available for any additional peripherals or increased FIFO depths.

Beyond the FPGA, a commonly required interface for industrial or hobby projects is a simple RS-232 or RS-485 serial port. For this reason, the off-board I/O capabilities of the Chameleon are focused on serial communications. Supporting both RS-232 and/or RS-485 is a definite plus. It is not generally necessary to support software configuration of the interface's signalling protocol: separate RS-232 and RS-485 transceivers are sufficient. Multi-protocol chips such as those available from Sipex are not necessary, and a simple cable to select the appropriate channel is a much lower cost alternative. It is for this reason that 4-wire full-duplex RS-232 (TxD, nRTS, RxD, and nCTS) and a 2-wire half-duplex RS-485 are supported on the same connector.

Placing two DB-9 connectors on the small Arduino UNO form-factor for these two serial ports is not possible. Therefore, these the Chameleon's two RS-232/RS-485 serial ports are implemented using two 2x5 box headers. These box headers allow the use of low cost 10-pin ribbon cable to make the interface cables. A 10-pin insulation displacement (IDC) plug connector and a 9-pin IDC DB9-F connector can be crimped onto a low-cost 10-pin ribbon cable. The resulting cable provides a low cost serial port connection. In addition,...

Components

1 × SSQ-106-04-G-S Connectors and Accessories / Board-to-Board and Card Edge Connectors

1 × SSQ-110-04-G-S Connectors and Accessories / Board-to-Board and Card Edge Connectors

2 × SSQ-108-04-G-S Connectors and Accessories / Board-to-Board and Card Edge Connectors

12 × C0603C103K4RACTU Capacitor, Ceramic, 0.01uF, 16V, 10%, X7R, 0603

20 × C0603C104K3RACTU Capacitor, Ceramic, 0.1uF, 25V, 10%, X7R, 0603

Project Logs

Collapse

fig-FORTH 1.0
Michael A. Morris • 12/17/2014 at 12:57 • 0 comments
fig-FORTH 1.0 now running on the Chameleon. The source for this interpreter was provided by user enso of 6502.org.
All that is required to get fig-FORTH 1.0 to run is to edit the configuration data at the beginning. In particular, only two variables need to be modified to adapt fig-FORTH to a target such as the Chameleon: ORIG and MEM. The remainder of the variables that define the fig-FORTH environment are offsets from ORIG and MEM, or have default settings compatible with most 6502/65C02 implementations.
In addition to modifying ORIG and MEM, it is necessary to provide three serial I/O routines for use by fig-FORTH: cin (getch), cout (putch), and crout (putcrlf). fig-FORTH assumes that 7-bit ASCII is the terminal default. Since fig-FORTH sets the msb of the last character in a FORTH word's name field, I modified the fig-FORTH routine that uses cout to mask off the msb of the output character. This allows the use of the VLIST word to see the dictionary without extended ASCII characters at the end of every name.
The following is a small capture of a fig-FORTH 1.0 session on the Chameleon:
```
0020 - 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
>0400G

 PC=3A1D  A=2A  X=B4  Y=FF  S=FF  P=73 (NVRBDIZC)=01110011

>D000G

fig-FORTH 1.0a
 OK
 OK
: star 42 emit ; OK
: stars 0 do star loop ; OK
: margin cr 30 spaces ; OK
: blip margin star ; OK
: bar margin 5 stars ; OK
: f bar blip bar blip blip cr ; OK
f
                              *****
                              *
                              *****
                              *
                              *
OK
```
First, Klaus Dormann's 6502 functional test program is run, i.e. >400G. It completes successfully, and then fig-FORTH is booted, i.e. >D000G. After a couple of simple null line entries, a simple FORTH program (from Leo Brodie's "Starting FORTH") is entered and executed.
With fig-FORTH in place and working, it can be further modified in two ways for the Chameleon: (1) disk support using the serial Flash can be added, and (2) the primitives can be improved using 65C02 instructions and M65C02A FORTH instructions. The first task will be to incorporate support for the fig-FORTH file system. The second task will be to incorporate the 5 planned FORTH-specific instructions into the M65C02A and update the fig-FORTH core to use those instructions.
M65C02A Instruction Set Enhancements
Michael A. Morris • 08/16/2014 at 16:04 • 0 comments

This log describes the additions to the 65C02 instruction set added by the M65C02A core. As indicated in the previous project log, Checkout, the M65C02A core is a significant enhancement to the microarchitecture of the M65C02 core. The changes in the core were primarily focused on two objectives: (1) reducing the size of the core, and (2) improving the speed of the core. The M65C02A core meets both of these objectives.
The reduction in the size of the M65C02A core makes the core smaller than some cores which only support the base 6502 instruction set. That is, the resource requirements (LUTs/Slices/FFs) of the M65C02A (481/358/125) core are less than those of cores such as M65C02 (755/464/225), verilog-6502 (510/337/195), and ag_6502 (978/512/93). Note that each core must be evaluated separately in any particular application. When a core is synthesized in isolation, simplistic resource comparisons will not provide an accurate view of a core's resource requirements in a specific application. In other words, many internal and external factors can affect the final resource utilization values reported for any particular core. Thus, when considering the M65C02A/M65C02 cores, their use of 2 BRAMs to hold their microprograms must be seriously considered; BRAMs are a very limited resource in most FPGAs.
The M65C02A address generator has been significantly enhanced, and several recent additions to the data path logic, allow the M65C02A to support several addressing modes found only in the 16-bit enhanced version of the WDC 65C02, the W65C816 microprocessor. Specifically, the M65C02A supports the two stack relative addressing modes of the '816: sp,S and (sp,S),Y. The M65C02A core, therefore, currently supports the 8-bit mode versions of the ORA/AND/EOR/ADC/LDA/STA/CMP/SBC sp,S instructions and the ORA/AND/EOR/ADC/LDA/STA/CMP/SBC (sp,S),Y instructions.
In addition, the M65C02A supports the three '816 instructions which push 16-bit addresses/constants onto the processor stack: (1) PEA abs, (2) PEI zp, and PER rel16. In actual practice, the operand of the '816 PEA instruction is a 16-bit immediate value. That is, a 16-bit constant is pushed onto the processor stack, and a standard assembler will accept either a 16-bit absolute address or a 16-bit immediate value. The PEI instruction pushes the 16-bit value stored in locations {zp+1, zp}, which like the PEA instruction operand, may be considered to be an address or a constant. The PER instruction pushes the absolute address of the sum of the rel16 parameter and the program counter (PC) value of the next instruction. In the '816, the PER instruction is used to support position independent, PC-relative subroutines and data. With the PER instruction, the '816 uses the instruction sequence of a PER rel16 instruction followed by an BRA rel16 instruction to implement a position independent branch to subroutine (BSR).
The M65C02A implements these three '816-specific instructions, but renames them to PHW #imm16, PHW zp, and PHR rel16, respectively. This is done in order to better convey the actual implementation of the instructions, and to allow the incorporation of an additional M65C02A-only instruction: PHW abs. This new M65C02A-only instruction behaves like the PHW zp (PEI zp) instruction except that it uses the absolute addressing mode rather than the zero page direct addressing mode. To complement these 16-bit push operations, the 16-bit M65C02A-only pull instructions PLW zp and PLW abs are included in the instruction set. These instructions pull a 16-bit value from the processor stack and store it in location specified by the addressing mode.
The M65C02A also implements the '816 BRA rel16 instruction to support PC-relative, position independent software/firmware. In addition, the M65C02A-only BSR rel16 instruction provides the capability to access PC-relative subroutines directly instead of having to use the PER rel16; BRA rel16 instruction sequence. The M65C02A core also provides the means to use...
Read more »
Check out
Michael A. Morris • 04/19/2014 at 20:28 • 0 comments

19-Apr-14
The Chameleon was initially released after the M65C02 project was ported to the board. Simulation of the modified RTL files had not been performed at that time, but a custom FPGA build that toggled all of the output lines was running. The output signals were toggling as expected.
Since that time, took the M16C5x project, a PIC16C5x-compatible SoC implementation previously released, and ported it to the Chameleon. This process simply entailed removing the Xilinx clock generator and connecting the internal processor clock net to the external 48 MHz oscillator on the Chameleon board. Also attached the external 29.4912 MHz oscillator as the M16C5x UART clock.
With these changes, and the UCF updated to match the pinout of the Chameleon board, the M16C5x SoC project was used to successfully transfer an ASCII file to the Chameleon using a baud rate of 921.6 kbps. (The Quad USB-Serial adapter from Keyspan only supports operation to that speed on a Xindows XP laptop. The UARTs are capable of being operated (in the RS-485 mode) at rates in excess of 3 Mbps with a 48 MHz UART clock.)
In moving the Chameleon to an Arduino MEGA2560 compatible prototyping card, found an error in the symbol for the Arduino UNO power connector. Updated the schematic and PCB, and posted new PDFs of these files in the project's github repository. Took the opportunity to change the part numbers given for the Arduino stacking connectors. The previously specified stacking connectors resulted in physical interference between the top of the UNO's USB Type B connector and the through hole pins of the serial port's connector. The new stacking connectors specify a connector pin length that should eliminate this interference. (Using a paper business card as an insulating separator is also an option.) Finally, also determined that the part number of the SRAM specified in the BOM was incorrect. The part previously specified is a +5V-only SRAM, and the Chameleon needs +3.3V devices for it serial and parallel memories. The schematics and BOM were updated with the part number of a +3.3V SRAM, and an alternate part number was also added.
20-Apr-14
Converted the M16C5x test program, M16C5x_Tst4.asm, to C using the CCS tool suite. The result is that the C code only requires an additional 10 program memory words, and one of those words is added by CCS to handle reset vectors at the top end or at address 0x000, and the other, SLEEP, is added at the end of each user's program. The additional 8 words are a result of using a temporary register to perform the arithmetic needed to isolate upper or lower case ASCII from the data stream. The four comparisons load a temporary register and use that register to perform the subtraction. This approach results in 8 more operations in the C version of the test program. Otherwise, the C version is almost a one-to-one map to the assembler version of the test program.
Updated the github repository with the new files. Being able to use CCS C to support the high speed SPI master and UARTs of the Chameleon's M16C5x soft-core should prove beneficial. Can now see a reason to add support for interrupts and additional stack space to the P16C5x soft-core processor used in the M16C5x SoC project.
25-Apr-14
Changed the test program to support both SSP UARTs previously incorporated into the FPGA project. Found a minor bug in the reset logic of the SSP Slave module which prevented the first bit from the SPI Master from being captured. This prevented the address of the second UART's registers from being used during that transfer cycle. Fixed the issue and updated the github repository with the modified SSPx_Slv module. The fix allows the simultaneous processing of both UARTs at 921.6 kbaud.
Next will be the check out of the external SPI Serial Flash and Serial MRAM/FRAM devices. The FPGA boots from the SPI Serial Flash, so it's not in question whether the interface works or not. Instead, it's a matter of determining if the SPI Master (SPIxIF) module is properly...
Read more »

View all 3 project logs

Discussions

Bill Rowe wrote 03/13/2015 at 21:51

Is the 6502 able to drive the arduino compatible pins and SPI so it can use arduino shields? What speed is the 6502 running at?

Are you sure? yes | no

Michael A. Morris wrote 03/13/2015 at 22:51

Yes. Although you can't see the connection, the Chameleon board pictured above is mounted on an Arduino Mega board.

I have two versions of my 6502/65C02 core: M65C02 and M65C02A. The M65C02 core is essentially completed and there's a link to its GitHUB repository above. I purposely made the M65C02 core operate with a 4 clock cycle microcycle in order to create a 6502-compatible two-phase bus cycle. It operates (in the -4 Spartan 3A FPGA of the Chameleon board) at a maximum rate of 58.9824 MHz, or at an effective memory cycle rate of 14.7456 MHz. The M65C02A core, on the other hand, is a single cycle core (including BCD ADC/SBC operations which are two cycle ops in a standard 65C02). I also wanted to implement the external two phase 6502 interface with this core. Therefore, I use both edges of the system clock. The version of this core which you can find on GitHUB will place and route at 30+ MHz making it faster than the M65C02 core on the same FPGA. The M65C02A has some micro-architectural improvements that provide the means by which I am expanding the instruction set to support 16-bit arithmetic operations, a Forth VM, expanded addressing modes, etc.

At the moment, I've been concentrating on completing a User's Manual for the M65C02A core, so I've not worked too hard to develop an Arduino sketch that communicates with the M65C02A core in the Chameleon's FPGA.

There are two example projects for the Chameleon FPGA that provide a number of peripherals that can be used for communications with an Arduino processor card. Alternatively, the slave peripherals of the Chameleon can be re-directed from the serial I/O interfaces to the Arduino-compatible I/O pins.

My plans for the Chameleon are to use it as an intelligent communications engine for Arduino projects. I expect the interface between the Arduino and the Chameleon to use one of three interfaces: (1) UART, (2) SPI, and (3) I2C. I've not developed an I2C interface, master or slave, so I'll probably use the SPI and UART peripherals included in the M16C5x and M65C02A projects provided for the Chameleon FPGA.

For my other development board project (link provided above), I used an SSP-compatible interface, which I developed to connect an LPC2148/2138 ARM7TDMI microprocessor, as the mechanism for connection the M65C02A core to a UART module. The SSP-compatible module can be used to provide the slave interface between an Arduino processor card and the M65C02A or M16C5x cores in the Chameleon FPGA. I've also provided a parallel interface version of the UART for the Chameleon M65C02A core project. Therefore, all of the components necessary to make the Chameleon function like an Arduino master or as an intelligent Arduino slave are available.

If you have any other questions, I'll be happy to respond as time permits this weekend. Thanks for posting your question.

Are you sure? yes | no

Bill Rowe wrote 03/13/2015 at 23:02

Would it be possible to run the chameleon as a standalone 6502 computer without an arduino, and if so, could it run(say) an arduino ethernet shield?

On the speed, i understand you to say that it will run at 16+MHz vs the original's 1-2MHz. Is that correct?

I have had a lot of fun playing with an "olduino" that lets an old school 8 bit processor(RCA 1802) run modern peripherals. I am using an actual 1802 though so my speed is limited.

https://olduino.wordpress.com/about/

Are you sure? yes | no

Michael A. Morris wrote 03/14/2015 at 00:21

Tracked down your project. That's cool. I've thought about modeling the 1802 in Verilog, but I don't have any hands-on experience with it.

To answer your question, it is very much possible to do that. I just didn't have a wall supply with the proper range so I just used the Arduino Mega's USB cable for that purpose.

The memory cycle speed of the M65C02 and M65C02A cores is 16+ MHz. I use internal memory, but there is on-board SRAM to expand the memory beyond the 28 kB that's available for the program/data memory. I use two (4 kB) of the internal memories to implement the microprogram control store. At this moment I've not implemented an external memory interface to support the core. All the on-chip RAM is nice. There is an MMU module available in the project to allow the use of the additional 128 kB of SRAM external to the FPGA.

I have thought about making some more of these modules in the near future for some of my projects. If you decide that you'd like to make a soft-core of the 1802, let me know. The modules are not that expensive, but they are certainly not as cheap as an Arduino.

Are you sure? yes | no

Eric Evenchick wrote 03/30/2014 at 18:32

Nice, that soft-core seems like a great way to handle communication. Can you work with this board using the free version of Xilinx's tools?

Are you sure? yes | no

Michael A. Morris wrote 04/06/2014 at 12:56

Yes. I have some older projects that I maintain with my licensed ISE 10.1i SP3 tool set, but I restrict most of these type of projects to using FPGAs supported by the Xilinx WEBPack tool set. Similarly, although I have a licensed copy of ModelSim XE, I use ISim to build and run the test benches for these projects.

Are you sure? yes | no

Chameleon

Description

Details

Components

Project Logs

Collapse

fig-FORTH 1.0

M65C02A Instruction Set Enhancements

Check out

Discussions

Similar Projects

IO881

ECM-16/TTL homebrew computer

Suite-16

Baffa-1 Homebrew CPU Minicomputer

Chameleon

Become a Hackaday.io member

Just one more thing

Description

Details

Components

Project Logs Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse