I have been spending some time on reverse engineering the Nintendo CIC ROMs. The CIC is the “lockout” chip in NES/SNES/N64 cartridges, used to get an iron grip on the market prevent people from copying games. It was manufactured by Sharp and is likely one of their old “one-chip microcomputers”, used in calculators and TV remotes and the like. I couldn’t find a document describing the instruction set it uses (or its architecture!), so I made it all up (combining information from lots of sources: old datasheets, old patents, and the low-res die photographs).

The N64 chips are different, and I haven’t seen a ROM dump of those yet, so all of the following is NES/SNES only.

There is one chip inside the console, and one in every cartridge; the code inside the chip decides what to do based on a pin strap (the console one will be the “lock”, and the cartridge one will be the “key”). The two chips run off the same clock, and they run the same code, so they run in lockstep (sometimes they execute different codepaths, but the code is careful to take the same number of cycles on both paths in these cases). The chips communicate over two wires, one from key to lock, one from lock to key. Both chips calculate what bits they will send, and what the other guy should send; if what they receive is not the same as what they should have received, they panic, and the lock chip resets the console.

Here is the pinout of the CIC:

+------------------+
DATA_OUT <-- | 1 P0.0 +5V 16 |
DATA_IN --> | 2 P0.1 15 | ?
SEED --> | 3 P0.2 14 | ?
LOCK/-KEY --> | 4 P0.3 13 | ?
| 5 Xout P1.3 12 | <-- RESET_SPEED_B
| 6 Xin P1.2 11 | <-- RESET_SPEED_A
| 7 RESET P1.1 10 | --> SLAVE_CIC_RESET
| 8 GND P1.0 9 | --> -HOST_RESET
+------------------+The LOCK/-KEY pin is the strap pin I talked about above. The SEED pin has a capacitor connected to it; the discharge time of that is supposedly somewhat random, the lock chip times it and uses that as a random generator, to decide which of 16 possible streams to generate. It tells the key chip which one it chose.

The lock chip can reset the key chip (pin 10 on the lock is wired to pin 7 on the key), and it can reset the console. The RESET_SPEED pins are used on the 3195 to decide at what speed to “blink” the reset line (it’s connected to a LED as well): about 0.4s, 0.6s, 0.8s, 1.0s each of on/off.

There are dumps of the ROMs here, here, and here. All credits for doing these go to neviksti; thanks!

All the bits in those dumps are inverted (0 vs. 1); if you want to play along with the disassembler I’ll give a link to in a second, you’ll need to fix that; also, that third ROM is 768 bytes, which I don’t handle in my little conversion script, so you’ll need to remove the extra columns (they are empty anyway). Or enhance the script if you want to.

Okay then, here is that disassembler. Usage should be self-explanatory.

This ancient CPU looks mighty strange to modern eyes. Let me try to explain the architecture:

First, it is a 4-bit CPU. Yessir. It has an accumulator register, A, and a secondary register, X, both 4 bits. All RAM accesses are done via a single pointer register B, which is 6 bits; the CIC chip only has 32 nybbles of RAM though. There is also a carry flag, C.

Then, there is the process counter, PC. It is 10 bits, but there are only 512 bytes of ROM (except on the 3195, it has 768). The ROM is divided into banks of 128 bytes. When the CPU increments PC, it never touches the bank number.

Well, “increments”. To save chip area, they didn’t use a binary counter, but a polynomial counter; “incrementing” works by shifting the PC by one bit to the right, and setting the the top bit to 1 if and only if the bottom two bits were the same.

There are no conditional branch instructions; instead, various instructions can skip the next instruction if some condition is true (the instruction still takes time, it just doesn’t do anything). Oh, all instructions take one cycle; except for the two byte instructions, which take two cycles.

Finally, there is a four entry stack for the PC; it’s not in RAM, it is separate.

Now the instruction set:

"skip" means "do not execute next instruction"
"M" means "the RAM nybble addressed by B"
"BL" means "the low four bits of B"
"BM" means "the high two bits of B"
"PN" means "I/O port number BL"
"x.y" means "bit y of x"

00+N adi N "add immediate", A := A + N, skip if overflow (00 is nop)
10+N skai N "skip acc immediate", skip if A = N
20+N lbli N "load B low immediate", BL := N
30+N ldi N "load immediate", A := N

40 l "load", A := M
41 x "exchange", swap A with M
42 xi "exchange and increment", swap A with M, increment BL, skip if overflow
43 xd "exchange and decrement", swap A with M, decrement BL, skip if underflow
44 nega "negate acc", A := -A (two's complement)
46 out "output", PN := A
47 out0 "output zero", PN := 0
48 sc "set carry", C := 1
49 rc "reset carry", C := 0
4a s "store", M := A
4c rit "return", pop PC from stack
4d ritsk "return and skip", pop PC

This week should be an interesting week. The next (and hopefully final) sample cases should arrive at Michaels place. We're all excited, as they will look so much better than the already good-looking cases we already got.

In the meantime, while it has been quiet around here, a lot of other things have happened.

Preparing the Assembly


Michael has spend all his time preparing for the mass assembly.
He created a well documented assembly manual for the Pandora which contains several parallel processes that can be set up as stations. There are six sub stations and two main stations. The main stations (assembly of lid and assembly of base) require the most staff in order to crank them out faster. The sub stations require one person each (could be more if there are people) and are monotonous (ie. trim and solder speaker wires, apply copper tape, etc.). They could also be combined into more tasks and fewer stations.


Building the boards is a well understood process at this point and done very quickly. The pick and place machine can jam them out as quickly as you can keep the reels loaded. The boards are being built in batches according to how fast they can be tested. Currently that is going to stay at about 450-500 at a time. The process is to build 500, get them into testing and build the next 500 while the first ones are being tested. Once cases are available, the third parallel step will be to have a batch of 500 being assembled while a previous set is in testing and another new set is being populated.

All 4000+ antenna boards and LCD cables have been assembled and inspected. Things are progressing in the natural fashion a small run (by any big company's standards) like this should be done. When the cases show up, this parallel process will fall right into place and pump out shipments at a steady and predictable rate that has been expected from day one. We can't build and ship all 4000 in a day or even a week but it will be done as quickly as possible.

Michael himself will probably spend 12-15 hours a day on the floor helping to build building these bad boys to get them to you all as fast as humanly possible. It's going to be an exhaustive and miserable process, but that will help speed things up a bit. Yep. You read right - some of you guys will actually get a Pandora assembled by the creator himself!

Preparing the OS

The devs have continued to work on the OS. DJWillis fixed (and is fixing) quite a few bugs while also doing various tests to make it NAND-ready.
The OS itself is in a pretty good state. XFCE4 is working nicely, all those installed apps (AbiWord, Midori, ClawsMail, XChat, etc.) run flawlessly. PND Discovery and starting is also working fine. The standard stuff (closing the LID switches off the backlight, battery charging, etc.) is also included.

Here are the current issues still to fix:

* Include pmenu as second startup-option
* WiFi works, but can't be stopped once running. If we can't fix the driver in time, we'd probably put in a small tool where you can enable and disable WiFi on start.
* Bluetooth works fine but is missing a GUI.
* Some permissions need to be fixed (so a normal user can change maximum clock speed, etc.). Nothing spectacular
* Other minor stuff (keyboard mappings, etc.)
* Include scripts to enable TV Out.

So while it will surely not be perfect on first release, you can be sure playing, surfing, working, etc. works fine. It just is in need of more tweaking.

Preparing the shipping

I don't know how Craigs shop looks like at the moment, but I got over 700 empty boxes lying around, waiting to be filled with Pandoras. We're ready to ship them out as fast as possible when they come in!


So - everything is prepared from our side. And as soon as the cases are good... let the fun begin!

BouKiCHi posted a compiled version of Mplayer that does not need zImage with IPU enabled!

Quote
Note to Windowsusers: The file is compressed as. Tar.gz, you should draw a time to generate. Tar and then extract it again, only then will the executable icon Mplayer + + configuration for the dmenu .


Thanks to Ezequiel and the Dingoo Brazil team for the news.

Official Release post is here: http://www.dingoobr.com/?p=800