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 coded and integrated to support the external SPI devices while also accessing the internal UARTs.

25-Jul-14

Completed the verification of the M65C02A core. Using Klaus Dormann's 6502_Functional_Test program, the last few bugs were tracked down and eliminated from the new M65C02A soft-core. The M65C02A core is an improved version of the M65C02 microarchitecture. The microprogram is expanded from 64 to 72 bits. Several control fields which were previously implemented in an encoded manner have been replaced by unencoded fields. These changes allow a reduction in the number of levels in the control logic, which results in increased speed. The increased speed provides single cycle operation.

Thus, the 4 cycle memory interface of the M65C02 core has been replaced by a single cycle interface. The result is a 65C02-compatible core which easily operates at 30 MHz in the -4 speed grade Spartan 3A FPGA of the Chameleon board. (Speeds exceeding 40 MHz have been reported by the Xilinx tools when the M65C02A core is re-targeted to a -3 Spartan 6 XC6SLX9 FPGA.)

In the XC3S200A-4VQG100I versions of the M65C02/M16C5x Development Board or the Chameleon Board, the M65C02A core is currently implemented using the internal Block RAMs. There is a total of 28kB of available program/data memory for the core. The remaining 4kB of BRAM is used to implement the microprogram.

The M65C02A microarchitecture supports the implementation of more complex microroutines. The fixed microprogram ROM can now be controlled directly by the microprogram in the variable microprogram ROM. This is expected to allow the M65C02A to support virtual machines such as a FORTH VM by implementing some FORTH primitives in the microprogram. As it sits currently, the M65C02A microarchitecture supports the incorporation of stack relative instructions as found on the W65C816 microprocessor.