Strict Standards: Declaration of action_plugin_googleanalytics::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/ex6502/lib/plugins/googleanalytics/action.php on line 6

Strict Standards: Declaration of action_plugin_safefnrecode::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/ex6502/lib/plugins/safefnrecode/action.php on line 66

Strict Standards: Declaration of action_plugin_popularity::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /membri/ex6502/lib/plugins/popularity/action.php on line 57

Strict Standards: Declaration of Doku_Renderer_metadata::table_open() should be compatible with Doku_Renderer::table_open($maxcols = NULL, $numrows = NULL, $pos = NULL) in /membri/ex6502/inc/parser/metadata.php on line 24

Strict Standards: Declaration of Doku_Renderer_metadata::table_close() should be compatible with Doku_Renderer::table_close($pos = NULL) in /membri/ex6502/inc/parser/metadata.php on line 24
6502 EX (Extended) [applications]


In this page are describe some examples of 6502EX usage into different systems. These examples shall be considered at conceptual level, they are reported with the unique aim to inspire the user and to demonstrate the versatility of the 6502EX core.

Single Core on extended 6502 bus

The following figure represents a block diagram of a generic simple platform based on a single 6502EX core connected to memory and to peripherals by means of extended 6502 bus. Basically, the extended 6502 bus implies larger memory space addressability (up to 32bit) and larger data memory support (8bit or 32bit). The extended 6502 bus contains also additional control signals not existing in the legacy bus protocol, they are not shown in the following schemes.

In this example the code/data bus is limited to 8bit.

Fig.1: Single Core platform on extended 6502 bus

The orange bus represents the 6502EX program fetch and data access bus. Memories are connected to this bus. A DMA facilitates data moving between the SPI and the memory.

The memory sub-system is built-up around a ROM and a synchronous RAM.

The blue bus represents the 6502EX System Register bus to which the user can connect the programming registers of his peripherals without interfering with the main bus. The System Register bus becomes the configuration bus of the system. Still in this example, the System Register bus is connected to General Porpoise Register (GPIO) to be used to control the external world.

Single Core with Coprocessor on AHB bus

In this example the 6502EX is connected to a coprocessor through the System Register bus. The coprocessor in this case has local dedicated memories.

The 6502EX main bus and the System Register bus are wrapped respectively on AHB protocol and APB protocol.

The exposed AHB bus gives access to the huge number of legacy AHB peripherals available on the market.

The exposed APB bus is used as configuration bus to program AHB peripherals.

In this case the 6502EX main bus is 32bit large to speed up data access, enabling implementation of 32bit software stack for faster subroutine calls management.

Fig.2: Single Core with Coprocessor on AHB bus

Twin Core with Coprocessor on extended 6502 bus

This is an interesting example showing a system composed by two 6502EX cores and two coprocessors realizing a low cost eyes tracking system.

Fig.3: eyes tracking system

The TCB block (Twin Core Bus) gives the possibility to easily connect the two 6502EX cores to the same memories and to the same peripherals without making the design complex. In fact, TCB exploits a time-division bus sharing principle that makes practically transparent to the user the management of the two cores running in parallel. Thanks to this technique the timing of the application is always predictable for both the threads (particularly suggested for strong real time application).

The bus clock (ckb) is supplied to TCB that derives two slower clocks (divided by two), ck1 and ck2, which are supplied respectively to core1 and core2. Pay attention that ck1 and ck2 are in counter-phase. This way, each core always takes its bus slot to make code/data accesses without interfering with the other.

Fig.4: bus and cores clock phases

Thanks to this clock scheme, the two cores can access the same memory without clock penalties (wait state due to arbitration).

The Camera interface connects the camera to the system in order to transfer the frames of the scene that will be processed by the eyes tracking algorithm running into the two cores and into the two coprocessors. Finally, the USB interface transfers the processed data externally to the host system that will take the proper action (e.g. a PC that moves the cursor on the monitor when the user watches the monitor and moves the eyes).

This MIPS demanding application is enabled thanks to a dedicated coprocessor (this application uses two of them connected to two different 6502EX) called GAZE.

GAZE is a sophisticated coprocessor implementing an optimized state of the art real time eyes tracking algorithm that makes possible silicon low cost implementation without performance compromise.

Network of elementary Twin Core (node)

The following example represents an extreme use of a Twin Core module. As already seen in the previous example, a Twin Core module is a dual 6502EX core connected to a dedicated TCB module that allows a time-division bus sharing to preserve time predictability of each thread execution.

Fig.5: elementary node: dual threads processor

In the picture below a network of nine elementary nodes is connected to an external generic RISC that controls the network and collects data processed by the network.

Fig.6: network of nine nodes connected to a generic RISC

In this figure three accesses are shown:

  • the green path represents a local data access of node 5 into its local memories. Here, the two local cores access two different data into the SRAM without arbitration policies.
  • the red path represents a data read operation invoked by node 4 on node 9. The data read from the SRAM of node 9 is written into the local memory of node 4 and, after its usage, the result is stored again into its memory.
  • Finally, the orange path represents a data read from SRAM of node 1 and the storage into the main memory.

This kind of solution can be used for highly parallelizable complex algorithm requiring high computational capability (e.g. multimedia applications or images processing) at low cost and low power consumption.

Replacement of original 6502

This nice example shows how a daughter board based on a 6502EX core could replace the 6510 (basically a 6502) processor of the Commodore 64 in order to extend its computational capability.

The basic 64Kbyte memory system is extended with additional 1Mbyte of SRAM and 8Kbyte of Flash containing the boot code. An SD Card connected to the 6502EX bus provides support for ram disk.

Fig.7: Commodore 64 CPU replacement

The SPI interface connects the SD Card to transfer data in and out. In this example a low cost SPI is used for data transfer. Specific SD Card controller could be used to increase the transfer rate.

The 32bit to 8bit Adapter enables the possibility to connect the 6502EX bus (32bit) to the Commodore 8bit bus. It provides also clock synchronization between the Commodore clock system (1Mhz) and the 6502EX daughter board clock system that should have an higher clock, in the order of 100Mhz.

During the boot, the 6502EX loads and copies the Commodore Operating System into its local ram and makes it extremely faster during its execution.

Accesses to external devices like the VIC and the SID will be kept at original frequency (1Mhz).

If you are interested to know more about 6502EX availability, please send an email to 6502ex [at] gmail [dot] com . We will be pleased to answer to your enquire.

The information reported on this page is proprietary of the author of this site, all right reserved.

This page contains proprietary information that may be only used by persons in accordance to authorization under and to the extent permitted by the author of this site.

Information reported on this page is subject to change without notice according to continuous 6502EX development and improvements. All 6502EX details and 6502EX usage described in this page are given by the author in a good faith.

The author shall not be liable for any loss or damage deriving from the incorrect use of information contained in this page, or any error or omission in such information, or any incorrect use of the 6502EX.

Trademarks and pictures reported in this page are the exclusive property of their respective owners.

Extended 6502 for 8bit and 32bit Embedded Systems

applications.txt · Last modified: 2011/08/26 23:19 by sysadmin
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki