CAS Interface Studio 3.3
First I would like to thank Riccardo Alessi from Duolabs for his help. Without all the information that he supplied, this page wouldn't be half as interesting to read :)
This page is divided into 4 sections:
1. brief introduction to UCAS CAM programming
2. (re)programming the Xilinx
3. (re)programming the Matrix CAM Flash
4. (re)programming the Magic CAM Flash
Brief introduction to UCAS programming:
Allthough this programming procedure generally raises most questions, it is certainly not a difficult procedure. In fact it is very easy, once you understand a bit of the way these Sidsa based CAMs work. That is why I will start with some theoretical background information here before I continue with explaining the actual programming procedure.
The Magic Module and the Matrix CAM are basically identical. The layout of the PCB is the same for both these CAM's. In fact, all Sidsa/UCAS CAM's use this same construction.
Just to make the theory a bit visible, here is a large view of the most important components that make a Sidsa CAM to what it is.
If you hover over the components on the PCB, the names will be shown.
Clicking the component will then take you to the manufacturers website.
As said, these are the important components. You could call these the building blocks of a Sidsa CAM. However, as far as this tutorial is concearned there are 2 chips that stand out in importance as they are the ones that can be programmed:
- the Xilinx (the CPLD)
- the Flash memory
The other components in these CAMs can not be programmed by the Cas Interface 2.
Now because these two components are so important to the CAS Interface 2 programming, they should be identifiable by the software. So when you connect the CAS Interface 2 and the CAM, the software will first identify the CPLD and the Flash and present the result in a message window when done.
As you can see in the screenshot below, the CAM that I used here, contains:
- a Xilinx XC9536XL CPLD Version 4 chip
- a ST M29W160DB Flash memory chip
The Xilinx:
The Xilinx is a CPLD (Complex Programmable Logic Device), a kind of programmable array.
It seems that not all Sidsa based CAMs do perform any checksum control, so that is why you can leave the Xilinx as it is, even when converting your CAM into another type of CAM. Only reprogram the Xilinx if the CAM doesn't work after the conversion.
There are 2 different categories of Xilinx files available:
1. the Xilinx for the Magic Module (3 different file configurations are known)
2. the Xilinx for the Matrix CAM (only 1 file configuration is known)
The Xilinx files have an extension .cas or .jed (abbreviation for jedec).
The Flash:
This is the real important bit. The Flash makes the CAM to what it really is. Regardless of the type of Xilinx file you have in the CPLD, the CAM will behave like a Matrix Reloaded if there is a MR file programmed in the Flash. And if you have programmed a Magic CAM file (a Pentacrypt f.i.) into the Flash, the CAM will behave like a true Magic CAM, regardless of the CPLD content.
The Flash memory files have an extension .bin.
You should be aware that not all Flash memory chips come from the same manufacturer. What's more, not all Flash memory chips are supported by the CAS Interface. For more information on supported types, you can visit the Duolabs support forum.
The Flash memory is divided into 2 layers. The first layer contains the loader software (the boot loader), the second layer contains the actual EMU software. You should be aware that the boot loader performs 2 tasks in the CAM:
1. it ensures that the CAM is recognized and the EMU software is started correctly
2. it takes care of the correct updating of the EMU software
Structure of the Flash in a Matrix Reloaded CAM:
The boot loader in a Matrix CAM doesn't have any special name and it generally isn't programmed seperately either (like in a Magic CAM). The most obvious difference between a Matrix CAM loader and a Magic CAM loader is that the Matrix CAM doesn't use any encryption, so the loader doesn't have to decrypt anything.
As explained above, the second layer (software layer) of the Flash contains the EMU software.
You will find 3 different files on the web, that are meant for programming a Matrix Reloaded CAM:
1. the .upd files, when using a UCAS Programmer + UCAS uploading software
2. the .hex files, when using Fun Cards
3. the .bin files, when using a Cas Interface 2
Structure of the Flash in a Magic CAM:
The first layer in the Magic CAM is the boot layer. The software that goes into this layer is the boot loader software. It is used to identify the CAM at startup, it has to decrypt the special Magic CAM encryption and it ensures correct updating of new EMU software in the CAM. It is usually referred to as Dream Load.
The second layer contains the actual software like Pentacrypt, Tetracrypt etc. These softwares are also referred to as EMU-software or emulator software.
Magic CAMs are typically sold in the so-called virgin state. That means that no EMU-software is loaded on the CAM yet. This state is also referred to as Dream Load State. So before you can start using the Magic CAM, you will need to put some software on it.
Now you might wonder why the manufacturer does program a Loader in the Flash but no other software. Well the answer to that is simple. Selling the CAM pre-programmed with any EMU-software would make it illegal in most countries. So they just sell it without any software, which makes it legal. That explains for the absence of EMU-software.
As far as the presence of the Loader software is concearned, that has a simple technical background. The Loader software (Dream Load) is specific to each individual Flash type. So if you have a ST manufactured Flash, you need a Dream Load file that is specifically made for the ST Flash. And if you have a Toshiba Flash, you need a Toshiba Dream Load file.
In the pre-CAM programmer era, you never had to worry about having the correct Dream Load file, because the programming equipment that was available (MM programmer, funcard) would allways start programming at the proper memory address (hex 10000). They simply could not overwrite the present boot loader. But now, since the introduction of programmers like the CAS Interface, you DO have to think about getting the proper Dream Load file for your CAM/Flash.
You will find many different CAM files on the web and they can be distinguished by the file extension: 1. the .mbf files. These files should be used when programming with the MM programmer.
2. the .bin files. These files should be used when programming with speciale CAM programmers like the CAS Interface.
This last category (the .bin files) are also referred to as dump files. And you will find 2 different kinds of dump files: those with Dreamload in it, and those without Dreamload in it. And this is very important, because the presence or absence of the Dream Load in the file determines how you shoul proceed when programming your CAM:
- if the Dream Load is allready contained in the file, start programming from address 0 (hex)
- if the Dream Load is not present in the file, start programming from address 10000 (hex)
If you are unsure whether your file contains the Dream Load or not, or if the Dream Load that it contains, is valid for your Flash type, you can check that in 2 ways:
1. use a special hex editor and have a look at hex address 5000. If the file allready contains the boot loader, then you will see the Dream Multimedia copyright notice starting at that address. If the boot loader is not contained in the file, there is no copyright notice on that address.
2. use the special program MMDLC (Magic Module Dream Load Configurator) which you can download from the download archive. It will show you if the boot loader is contained in the file and for which Flash it is suited. You can even edit that.
The programming order/priority:
I have read many different opinions on what the correct programming order is, first the Xilinx and then the Flash, or just the other way around.
Well, I can be short about this. It doesn't matter at all which one you program first.
Because the Xilinx and the Flash are two individual components which can both be addressed directly, they can each be programmed individually. Programming the Xilinx, does not influence the Flash content and vice versa.
OK, so much for theory about UCAS CAMs.
Let's go on with programming.