Last updated - October 4, 2001

Speculation on the REX 6000 technical architecture

Thanks to Amiram for this very interesting commentary. He believes the genesis of many issues with the REX 6000 is rooted in its technical architecture.

"Let me speculate a little about the technical aspects behind the R6K.

Xircom does not reveal much about the architecture of this product, and what it does sometimes seems confusing (see the memory size issue – 1MB or 2MB <currently confirmed via testing to be 2MB>). So everything I say is based on circumstantial evidence. Please correct me when I'm wrong.

Let's assume that we are a Citizen designer looking at the R5K and trying to architect the next generation. Here we go:

DECISIONS, DECISIONS

We start with our most important decision: we MUST stick to the PCMCIA form factor. This is the single property that can make anyone buy a Rex in the first place, and there is no way we will change it.

Now let's see what will attract those users who did not buy our current model, or what will make existing users upgrade and throw some more money at us.

The main improvement should probably be a touch screen, preferably with higher resolution. We should also put in some more memory (an important selling point but also a technical necessity, as we'll see in a moment). Other things, such as upgradeable OS, are welcomed too. And of course we should have some new software features. Web content will sell well, won't it?

TOUCH MY BATTERIES, BABY

Let's start by putting in a touch screen. But a touch screen is thicker than the one we have now, while we cannot make the card itself any thicker – we are bound by the PCMCIA 5mm standard. And since the card format dictates that the batteries go under the touch screen, we CANNOT fit our current batteries (CR2025) anymore. And perhaps the extra memory also needs some more room. Problem.

Luckily enough, there is the CR2016. It is 1.6mm rather than 2.5mm thick. Just what we need. Great.

Or maybe not so great. The CR2016 is less than half the capacity of the CR2025 (typically 80mAh rather than 170). And we also have more memory, which can take more power. And a touch screen, which can also take more power. But we still want to keep our 6-month battery life. Tough.

FLASH ME, BABY

Now let's see where we can conserve some power. Ah, the memory. Who says we need to use SRAM as in our current model? We can use Flash ROM instead. Flash ROM is good. Flash ROM does not need any power to keep its data when it is not being accessed. It is also more dense and less expensive than SRAM. The ideal solution.

Well, not really. While Flash ROM lets us use smaller batteries (at least theoretically) and pack more data, it is not really suited for a PDA. Flash is designed for intensive-read seldom-write situations. As such, it has some serious drawbacks for us.

For one thing, Flash ROM can be read but CANNOT BE WRITTEN as standard memory. We can turn its bits from 1 to 0, but there's no easy way to turn them back to 1. To do this, we need to do an "erase". And on a conventional Flash chip, we cannot do an erase on individual bits. We must erase either the whole chip, or, in more advanced chips, complete sectors (which are typically between 64 bytes and 64KB each). Having "erase" electronics for individual bits is very expensive and very large.

And then there's the matter of timing. Flash ROM reads very fast, but writes very slowly (perhaps 200 times slower) and erases even slower.

And then there's also the matter of power. Flash ROM needs more power to write or erase than to read. This is more power PER TIME UNIT, and MUCH more power if you multiply it by the considerably longer time it takes to write or erase.

It all adds up to the idea that Flash ROM is suitable for other things such as our desktop PC's BIOS, our Cell phone, our digital camera or our MP3 player, but not really for our dynamic, program-intensive, low-powered PDA.

But then we don't have any other alternative. We REALLY cannot use SRAM. We are stuck with Flash ROM and have to make the best out of it.

THE GARBAGE MAN

Of course, we cannot use Flash ROM alone. We must have some RAM for our stack variables and temporary data. But the size of this RAM is very small. Actually, we only have room and power for 32KB. We cannot use it to save data – it is only for temporary use.

Whenever we want to save some data, ANY data, beyond its temporary state, we must save it to the Flash. And if we need to modify this data, we must write it to a NEW location in the Flash each time. As we said above, more memory is not just a marketing issue – it becomes a true necessity.

But eventually we will run out of new memory locations, and we will have to have some sort of garbage collection – erase the Flash (totally or some sectors) and rewrite it with only the current data.

We can do some limited garbage collection within the card, but it doesn't make sense to do it regularly. We don't have enough RAM for this and we don't have enough power for this.

So the best place to get into the erase-write garbabe collection endeavor is while we are connected to the PC. When we are, we have the full power of the PC in our hand. We can read the card memory (in a crude or more intelligent manner) to the PC, do whatever it takes to update it, and then erase our Flash and write the relevant data back. If we design our electric interface correctly, we can perhaps even obtain some power from the PC so that the erase and the write will not drain our own batteries so quickly.

Quote from the R6K FAQ page:

'Since the REX 6000 was designed for frequent synchronization with a PC, for optimal performance and maximum data capacity we recommend that you enter the data into the PC rather than directly into the REX.'

THE VIRTUAL WORLD

Our processor (Z80) is basically an 8-data-bit 16-address-bit processor. This means that it can directly access 64KB of memory. We use an enhanced version that has a Memory Management Unit (MMU). This unit allows us to access more memory (perhaps up to 2MB or 4MB), 64KB at a time, by providing "virtual memory" – the division of actual memory locations (either RAM or Flash ROM) into blocks and the dynamic mapping of these blocks into our virtual 64KB "address space". We will probably map part (half?) of this address space to our small RAM, and the rest to certain blocks of our Flash. Not very simple, not very efficient, but at least it works.

LIKE A MODEM

So it seems that we solved most of our problems (or at least we think we did). We can have a touch screen. We can use smaller batteries. We can have Flash memory that will save us some power and space. We can have a small amount of RAM to work with. We can access the full Flash memory, chunks at a time. And we can straighten things up every time we are connected to the PC.

One thing remains, and that is how we connect to the PC. As long as we use our own cradle, the PC sees us as a serial/USB device and we can do whatever we want. But if we connect directly to the PCMCIA socket, we must adhere to the PCMCIA standards. Our current SRAM-based model (the R5K) can appear to the PCMCIA subsystem as a memory card with 512KB capacity. But our new Flash-based card cannot, since it must not be treated as standard memory – it cannot be rewritten and its write is much slower than its reads. No problem: the PCMCIA standard lets us specify the card as a modem. Let's use this specification, and then we can send and receive data from the card as we wish. Sure, it's slower than memory, but once again we don't have much choice.

THOSE INTELLIGENT PROGRAMMERS

Don't be mistaken. We are hardware people. We are designing touch screens and batteries and memory. We don't do software. While we are working here, we know that those intelligent programmers in their intelligent offices do whatever they're supposed to do to intelligently program our machine. We are sure that they have very profound software development tradition and will come up with very profound software. This is outside our scope, really.

AND THE WINNER IS...

• Inputting any meaningful amount of text directly into the Rex makes it very slow (because we have to write to the Flash).
• Inputting any meaningful amount of text directly into the Rex makes its memory fill up very quickly (either because we fill up our very small RAM or because we have to use new Flash locations every time).
• Adding text to the beginning of an existing note is very slow (because we have to rewrite the whole note into a new location in the Flash).
• Synchronizing is very slow (because we have to read, erase and write large amounts of data).
• Battery tends to drain very quickly (because users tend to use the Rex more intensively than we, its inventors, thought).
• Scrolling to the next day is very slow (Ok, this one I can't figure out).

And all of this has nothing whatsoever to do with bad recurring events, missing company names, deletion of Senior/Junior contacts and that sort of stuff – this is purely due to bad programming culture, and could happen even with the best hardware architecture.

Can all of this be fixed? – The software part can. I am really curious to see what they can do with the hardware part."