GEB 2200 hardware

The 2200 is a completely new architecture compared to the 1200. We replaced the Motorola 68K CPU used in the 1200 with the Cirrus Logic 7312 (which is an ARM Ltd, RISC processor).
This means that the 2200 can render, and process about 60 times faster than the 1200. It may not be immediately obvious, since the 1200 was pretty good at this, but if you were to hold them side by side, you would notice the difference in drawing pages as you flip them fast.

The battery change on the 2200 was made for costs. A battery in a case and the associated connectors and mechanical parts (battery door, etc) are a significant cost. The goal is to produce a product that competes with the 1200, but can be sold for a lot less. Very few people were buying new batteries, so the decision was made that people would prefer to pay less than to have the removeable battery.

REB1200 Hardware

Motorola MCF5102 ColdFire CPU
8MB memory, Mitsubishi M2V64S40DTP
2MB video memory, ICSI IS41LV16100S-50T
4MB flash memory, Toshiba TC58FVB160FT
MC68L711 - masked 6811 - an I/O controller
Epson display controller chip SED1356F0A
AMI chip is the address decoder


Front	Back

from: http://krausyaoj.tripod.com/reb1200.htm

Info on a utility to copy the contents of the REB1200's memory to a PC
How to reset aa REB1200 to factory default: Refurbish

Motorola MCF5102 ColdFire CPU

(*The end-of-life for this product family is complete. Motorola has made arrangements with Rochester Electronics to help manage any excess inventory for the End of Life process. All remaining devices have been transferred to Rochester Electronics. Contact Rochester Electronics at: (978)462-9332, or on line at http://www.RocElec.com .)

The first ColdFire Family member to be announced was the MCF5102. As the first chip in the family, it has been designed to be both ColdFire ISA compatible and 68EC040 compatible. These extensions to the ColdFire instruction set allow Motorola customers to use the MCF5102 as a bridge to future ColdFire processors for applications requiring the advantages of a variable-length RISC architecture.

MCF5102__ARCHIVED Features

Static ColdFire® Core
Supports M68000 Instruction Set
27 MIPS @ 25 MHz
Multiplexed Address/Data Bus
2 KByte Instruction Cache
1 KByte Data Cache
Bus Snooping
3.3V Operation
5V TTL Compatible I/O
Available in 16, 20, 25, and 33 MHz
Power Dissipation (Typical) 640 mW

ColdFire Programmer's Manual [3.6MB]

The BDM stuff on the Coldfire for the REB1200 isn't really useful for much besides verifying the chip at manufacturing time. Unlike the JTAG ports on many newer CPU's (like the ARM series), the JTAG stuff on the Coldfire (especially the one in the 1200) is nearly useless.

Trust me, it was frustrating when I was first bringing up the OS on the 1200 and had to rely on an external Logic Analyzer and a fairly expensive "clip" just to see the code flow.

It's best to think of the Coldfire in the 1200 as a 68040, that's really the way it works for almost all purposes (code wise). The bus is multiplexed, so that's like a Coldfire, but that's about the extent of it.

The 6811 is a secondary controller (we sometimes called it the IO processor). It is, as you guessed, just a masked 6811. It has a little bit of microcode for doing battery management and IO processing. It handles almost all the IO pins for stuff like serial output, switching
on and off the ethernet chip, battery charging, startup and reset, button interrupts and almost anything related to IO. It remains on even when the device is powered off because it constantly updates the battery status.

The display isn't memory mapped, it uses an Epson controller chip to draw to the device. The Epson chip has it's own memory and accesses are always through the Epson controller. There is a way to access it in a pseudo memory mapped mode, but I honestly forget how. Figure out the info on the Epson chip and it will probably make more sense.

I think the AMI chip is the address decoder and also might contain the modem and serial UART stuff. I think it's primarily responsible for demux-ing the address/data bus and doing the memory mapped IO. But I also think it contains the serial UART for the modem. I think we baked in an "off the shelf" UART for the serial stuff, but I can't remember if that included the modem or not.

RAM starts at 0xF0000000 (I think, we moved the memory around through the different products and I'm not 100% sure). Ethernet is probably at 0xE0000000 (I remember there being something about using the "E" to mean ethernet) display is either at 0xC0000000 or 0xD0000000 (which isn't the memory for the display, but the registers for the Epson controller).
There's also some flash ROM in there and the interface to the 6811. Can't remember specifics and probably shouldn't refer to notes (I'm in enough trouble for this message).

If you have a firmware image (which SOMEONE out there does), you can probably pretty easily map the memory out. Keep in mind the firmware lives in the flash ROM and executes there, but the stack will always be set into the RAM.

Also remember that the firmware image that the device downloads over the network is NOT a complete image. So unless you actually pull chips from the board, you'll be missing some small percentage of the firmware code. That probably doesn't matter for most uses (i.e. you could quite easily get a non-Gemstar OS running without using that code), but it
does mean that if you have a snapshot of what the bookstore sends to upgrade a unit, then it won't accurately describe the memory map of the devices.

Other tidbits that are useful to know...

The Coldfire does not have an MMU (it uses an ACU instead), so it's not possible to run Linux without doing some significant work. You would have to port the non-MMU version of embedded Linux to run on it (and it doesn't currently support this chipset).

The memory for the Epson controller is in a rotated mode. Since there were no options for a "portrait" mode controller (at the time), we ended up doing funky things with the controller to get the memory to map to the display (since both wanted to be in landscape mode).

The CF interface only supports IDE mode. That means any card that uses IO mode (serial cards, WiFi cards, ethernet cards, etc) will not work. The bus was overloaded and there just wasn't any way to bring those signals to the CPU.

Keep in mind I haven't worked on the 1200 since 1999, so my memory may be fuzzy (or just plain wrong) on some of this.

On Jan 3, 2004, at 12:15 PM, Richard Newman wrote:

> Jeffrey,
>
>     Thanks for the technical blurp. Since we are there....
>
>     Does anyone know the exact spot of the JTAG pins? I think they are
> the 4 bed of nails points near TP1B which is near the Motorola Coldfire pin
> 1.
>
>     Has anyone played with creating a new program, from scratch, that
> would reside in place of the reader software? Even if it does nothing useful
> but reflash the flash and display a hello world message, that's significant
> work.
>
>     Has anyone looked at doing their own program to run on the Reb1200
> device?
>
>     Has anyone mapped out the peripherals of the Reb1200 so that
> someone who does want to create a program to run on the Reb1200 has a idea of
> where the display, compact flash and CS8900 are mapped in the Coldfire's memory?
>
>     There is also a little MC68L711 on the board, is this just a masked
> 6811? Any idea what it does?
>
>     What is the AMI Device at u2, a fpga?
>
>     While I was authoring this message I received your latest message
> about downloading rom files via Reblibrarian. I never knew it was able to do
> this nor that anyone was interested in doing this. If 3.3 breaks this then
> knowing the JTAG location (Motorola really refers to their boundary
> scan and debugging interface as BDM interface) would be important to anyone
> trying to write code to run on the Reb1200.
>
> Richard N.

> Is there anyway to force load boot firmware? My GEB1150 firmware got
> scrambled and now only boots to a big plus on the screen and I have to
> push the reset to turn it off. The GEB1150 is almost the same as the
> GEB2150 or at least it is supposed to be.
>

The OS is very similar, but as far as loading the firmware, they are two completely different animals. The GEB1150 uses a boot ROM to load an encrypted file off the filesystem and puts that in memory and then executes that code. The 2150 (or 1200) simply uses flash ROM and just lets the CPU execute from that address space at boot time. It's one reason no one ever has any problems with the firmware on the 1200/2150, but you constantly see "my 1100/1150 won't boot" messages.

Unfortunately the only way to fix it is to send it to Gemstar. The boot ROM uses public key cryptography to verify the image and the loader that installs it, so there's no way (I know of) to get around that. Last I heard they were going to epoxy the boot ROM's into the
motherboard, so there's not even an option to replace them.

Would this chip be the Epson SED1356F0A? I was not able to find
documentation for this chip on Epson's site but did find
documentation for the S1D13506 which says that SED1356 is the
previous number.

http://www.erd.epson.com/vdc/html/contents/S1D13506.htm and search for S1D13506 at http://www.eea.epson.com/

Does the Epson chip display the fonts or are the fonts for serif, san-
serif, etc in the flash memory? I am specifically interested in the
font metrics as that is needed to calculate line and page breaks.

The required font metrics are all stored in the publishing tools (if the publishing tools can paginate the data, they would have to be). A person knowledgeable in the .RES folder format (such as yourself) should be able to pick apart the NFNT data type to find the individual font metrics for each font. All that remains is figuring out the NFNT
format (hint: use Google).
>
> Does the Epson chip display the fonts or are the fonts for serif, san-
> serif, etc in the flash memory? I am specifically interested in the
> font metrics as that is needed to calculate line and page breaks.
>

All the fonts (and metrics) are stored in the flash in the firmware image. The original fonts are Mac fonts and are then converted to the format we use for the rendering engine. Part of the build process creates the fonts WITH the metrics as data in the firmware. The format
is pretty much identical to the NFNT resource format on a Mac. The major difference is that there is no FOND resource to describe families, that's all done by resource ID.

The font data is ALSO in the publishing tools, as the line and page breaks are calculated by the tools when you build the books. The book doesn't have any real clue how wide lines are, it just knows where to put things and when to break lines (all set by the tools). In other
words, it might be possible to extract that info from the freely available publishing tools (rather than trying to pull it from the ROMs).

The only change to the fonts in the 5 years I worked on the product was the addition of the Euro character in the end of 2002. I think firmware earlier than 3.2 is missing the Euro character in some fonts.
If anybody out there ever wants tools for manipulating early Mac OS NFNT resources, let me know. I wrote utilities to dump the font characters to images, and then recombine those images later. For doing the Euro update, I dumped everything to images, edited them in
Photoshop and recombined them. The original fonts were created using a program called Fontastic which only ran on very early versions of the Mac OS (pre 6.0), needless to say I needed to find a better way when I did the update. From: Erik Walter < ebook@e... >

Some additional information about the REB1200 hardware. The DRAM for
the Epson controller chip is an IS41LV16100S-50T 1M X 16 3.3V

From: "Jeffrey Kraus-yao" < krausyaoj@a... >

http://web.icsi.com.tw/domino/packinfo.nsf/WebDSProcNum/(81C81230EEC6D4CE829CD80D96690494)?OpenDocument