From: Andrew Jamieson <ajamiesn_at_mira.net>
Date: Mon, 10 Dec 2001 08:47:43 +1100

>[I]
>Good :)

Thanks!

>What tool do you use to make this schematic ?

Protel 98

>[I]
> Both /CS1 and /CS3 (as stated in your shematic and datasheet) :).

Ah, but in this context, CS1 & CS3 are actually used as DRAM refresh strobes (which is fairly transparent to the code, once enabled in the registers, AFAIK), not chip selects; hence my terminology.

>[I]
>Just a precision : /CS0 cannot be used if SH1 has a internal ROM, because it could need to >access to external ROM for the firmware : if ARCHOS encrypt their software ARCHOS.MOD, >why wouldn't they scramble their firmware in a external ROM ?

You'd be amazed at how different ppl percieve security. Most engineers like to think of their devices as a black box - once the code is in, it's safe. I would be suprised to see that they have scrambled (let's not dignifiy what they do to the mod file with the term encryption) the code in the internal flash.

>If so, it means that program in A-MASKED ROM needs to access to external ROM to >unscramble firmware in DRAM, so it is impossible to switch on the fly in fact. In other hand, >SH1 may directly boot with a unscrambled firmware in the external ROM too. The best way to >know is probably to check mode setting pins MD0-MD2 if SH1 boots with internal ROM.

The main question that we need answered to get anywhere is this: What does the mod file do? How is it used to patch the code? The FLASH requires a 12V signal to write, so given the IC's on the PCB, it looks unlikely that this can be reprogrammed in the field (this would also explain why the unit always boots with the original mod version first). So, the mod must be stored in the DRAM - does this mean that all the code is copied to the DRAM at boot, and then the mod is overlaid to patch required bits? This would reduce the size of the DRAM buffer for music data by 2 MBits (giving a buffer of 14 MBits). This could be easily tested by checking to the CS line to the FLASH - if it is only active at boot, then the contents are being moved somewhere.

Also, we need to know if the SH-1 is infact ROM'd or not. As Paul stated, this could be tested by measuring the mode select pins - which I will do. I will go out on a limb and speculate here - I think there is internal ROM, and that it contains at least the I2C code that transforms some of the port B pins into an I2C bus. This would make the most sense to me.

>[I]
>Could you confirm that LCD uses a 8-bit bus ? it would be nice if true :).

If you look at TJ's picture Top2 (in the Yahoo photos section), you can see the pads used to interface to the LCD - there are only 21, which makes it way too small to directly drive the glass (so therefore there _must_ be a Chip On Glass controller), it is also a bit too small to use a 16 bit interface (in fact I do not know of an LCD controller that does use a 16 bit interface ... ), and a too big to use a 4 bit interface. Also, if you look at pins 8-15 (counting up), you can see eight lines all entering the pad layout from the same direction. This screams data bus to me.
Received on 2001-12-09