• MiniITX Form Factor (17x17 cm)
  • CPU SoC AMCC 440ep (533 or 667 Mhz)
    • Integrated DDR 266 memory controller
    • Integrated PCI controller
    • Integrated Flash memory devices controller
    • Integrated USB 1.1 Host and 2.0 Device controller
    • 2 integrated Ethernet 10/100 ports
    • Up to 4 serial ports
    • 2 I2C interfaces
    • SPI interfaces
    • 64 pin for I/O General Purpose
  • DDR DIMM 100 slot, max 512 MB
  • USB 2.0 OHCI/EHCI NXP PCI controller
  • Audio Cirrus Logic CS4281 and Realtek ALC655 Codec
  • Silicon Image 4 Serial ATA ports
  • ATI RADEON Mobility M9 with 64mb RAM graphic chip
  • Pericom 8150B PCI Bridge
  • FPGA Lattice XP with 80 pin I/O expansion connector
  • PCI Slot - 32 bits, 33 Mhz
  • mini PCI Slot - 32 bits, 33 Mhz (optional)
  • RTC with backup battery
  • UBoot 1.3.1d
Power consumption:

from 10.2 Watt (no external peripherials attached, Fedora8 graphic login screen displayed, 667 Mhz model) to 25 Watt when playing Quake (full use of the 3D gfx chip)


Availability: Sam440ep is available only under bulk orders, minimum quantity 30 boards.

For information please write to:


Please visit the official ACube Systems website to download latest firmware, drivers and software updates here

 Sam440ep Revision C



From where the name "Sam" comes ?
It comes from a pun, around the 440ep reference board name, which is Yosemite. There is a cartoon character called Yosemite Sam, then the name Sam was choosen.

Is the Sam440ep board based on the Yosemite reference board?
Not at all, the Sam440ep was designed from the ground up.
All the board functional blocks are different from the reference board: the DDR block on the Sam440ep supports up to 1 GB of DDR, divided into 512 MB soldered on board and 512 on an externel slot, the soldered onboard memory chips are 8 bits data wide, while on the Yosemite they are 16 bits wide, the power supply block is different, the reference board works with a single +5V supply while the Sam440ep use an ATX connector, the power switch on/off funtion is done with a PIC controller (totally absent on the Yosemite), the DC-DC converts are different, the peripherials on the EBC local bus are different, the ethernet phys are different, there are no PCI devices on the reference board, while there are 4 PCI devices on the Sam440ep, and a secondary PCI bus, which is totally absent on the reference board. There isn't any sound codec on the Yosemite board and even the serial port is different from the reference board, where there are 2 4-wires ports while on the Sam440ep there is a single 8-wires port.
On the Sam440ep there is a LatticeXP FPGA, with a 80 pin expansion connector, totally absent on the Yosemite board.
The Sam440ep PCB is 10 layers, while the Yosemite PCB is 6 layers.
Basically the Sam440ep and the Yosemite board are two totally diffent boards, both based on the 440ep SoC.

How to obtain the maximum performance from my Sam440ep-flex ?
Keep your firmware updated, the latest version for your board may be found HERE
Under AmigaOS4 always keep your system updated.
Use the following utility to tweeck some 440ep settings: Sam440ep_setup
If need even more power, try overclocking the board with: HyperClock

I'm an AmigaOS4 developer, how to obtain the best performance?
When possible use DMA accelerated functions to transfer data from RAM to video RAM, or from RAM to RAM.
Starting from rtg.library V41.4347 WritePixelArray and ReadPixelArrays (and other functions) are DMA accelerated if the pixel format is >= 15 bits. Where possible, anyway avoid using ReadPixelArray since reading from video RAM is always very slow, regardless if the video card is on the PCI or PCI Express bus. It's best to keep a copy of video data in main RAM and read from there instead.
If Write/ReadPixelArray aren't suitable for your application, you may try with CopyMem and CopyMemQuick with exec.library V53.29 and newer. In this case the data to be transfered must meet some requirements: the block must have size >= 64 KB, even, and aligned to 4 bytes, the source must be in main RAM, and the source and destination regions must not overlap. The performance is obtained if both source and destination were allocated with the MEMF_HWALIGNED flag.

Due the time required to setup the DMA controller, the minimal optimal block size may be bigger than 64 KB to obtain a trasfer rate higher than using the sole CPU.
To be taken in consideration that the DMA channel may be busy from a previous DMA operation too.
Since rtg.library and exec.library use two different DMA channels, it may be possible to interleave DMA transfers with rtg.library and exec.library to obtain the maximum bandwidth possible on the 440ep. Another alternative is to start a DMA transfer and then a CPU transfer if the two data blocks aren't correlated.

An important aspect to keep in consideration when optimizing applications for the 4x0 platform is to keep the data aligned to their natural size, otherwise the 4x0 will generate an exception for each data not aligned, slowing down execution. This is usually done via GCC specific options, for example -mstrict-align.

 Copyright © 2006-2012 ACube Systems Srl P.I. 03367150244