Last updated - September 6, 2002

Programming for the REX - Add-ins and Desktop Programs

Dynamic Link Libraries! The REX 6000 Technical Environment
REX Firmware on a DS2
(Putting the REX firmware on a DS2!!)
REX Serial Communication  

STOP!! Before you read on, you should know that there is a REX Developers Mailing List with over 100 members (as of August, 2001). After you review the information below, you should subscribe to the REX Developers Mailing List if you are interested in collaborating with other REX developers on add-ins, REX programs for the desktop, or web sync capabilities. After you have read the information below, see our Internet Resources page for info on subscribing to the mailing list.

(Thanks very much to Daniel for his generous help in updating and organizing this content!!)

Xircom has not (and will not) release a REX 6000 SDK! <back to top>

An SDK is a Software Development Kit. Programmers use an SDK to write programs for a device or software platform. Then a compiler is required to convert the programs into code that the REX can understand. Typically, when companies release a device that has this type of capability (as the Palm also does) they release an SDK soon after so that crafty programmers can create and give away or sell Add-in programs for the users of the device. That makes the device more fun/usable, and helps to make it more popular with users - good for everyone.

On August 21, 2001, Intel announced that it is discontinuing the REX. No official REX SDK will be released.

REX Owners Fill the SDK Void! <back to top>

In the absence of an SDK from Xircom, creative REX owners have developed several ways to creat add-ins for the REX.

Here is a summary of REX add-in development options, current as of August, 2001. Click the links in the paragraphs below to find links and more information on each of these options:

  1. The original DS2 SDK: This is free and uses the $200US IAR Compiler. Di has bought the compiler and set up a telnet and ftp server so others can also use the compiler (the compiler is copy protected, so you cannot simply use it on your own computer). Di has set up the server for testing purposes mainly.

  2. The rexdk. The rexdk is a modified version of the z88dk. Support for the REX was developed by Dominic, Damjan and Daniel. The rexdk is a package of the z88dk with all the REX additions and modifications. This is the most robust and effective SDK for REX add-in development at this time. There are DS2 and REX emulators as well! All of the functions documented in the DSSDK doc are implemented now and the compiler should be quite stable. (9/3/01)

  3. Programming in Z80 assembler: This is the lowest level of programming and the most difficult. Chris (Adder) and Amiram (Solirex) used that option for their addins. If you have to ask more about this you probably don't have the background and knowledge to do it!

  4. The Small C SDK: This is not as powerful or efficient as rexdk. For now not the best option to pursue. Myles' site has other info that is quite useful - his site is worth a visit whether or not you use the Small C SDK.

  5. The RxSDK Package: (Based on the SDCC - Small Device C-Compiler). This was adopted for the rex by Marc Nijweide. Marc has modified this to support the REX, packaged it up again, and set up a webpage for it. Originally the compiler was in a kind of beta stage with some drawbacks, and probably wasn't the best choice for serious development. Marc has released a couple of significant updates (info below), so check it out.

  6. The REX 6000 C Software Development Kit: Mike has released a REX SDK that is largely "home grown," including the compiler (a lot of work!). Of the existing SDKs it appears closest to the RxSDK above in terms of strong functionality and good code generation. No support for floating point funtions at this time.

Click on the links in the development options above (or scroll down on this page) for more details and links to their download sites.

The Original DS2 SDK on Di's Technical REX site <back to top>

Di has made a public server available for testing compiling REX add-ins!

If you are pursuing REX 6000 Add-in development, you should absolutely look at his site and maybe send him an email or two.

"A lot of things are going around! Wow! I bought IAR compiler and set up a public server for testing it. Now everybody can try DS2 SDK, compile code, use emulator. Look at www.dimitriy.com , then follow the links to 'Rex,' and then 'SDK setup.' Best Regards, Di"

Di's very interesting REX 6000 Technical site is also the place to go for general technical info about the REX. Di's site has detailed pictures of the REX internals, w/chip names, etc., that an anonymous donor provided. Look under "Hardware" and then "Picture Gallery - Inside REX 6000" and "REX 6000 Chip Markers" on Di's site.

Other cool stuff on Di's site include pictures and details on the differences between the DS2 and the REX 6000, and other cool stuff like below:

"All: I found one very nice utility that opens a way to create PC programs talking to Rex (database, add-in, web, ...).

From SciFiGuy: "Di: That command line utility is really great news! Maybe this is a doorway to implementing web sync capability, so we don't have to rely on rex.net. I'd really like to have a utility that reads in a list of URLs from a file, and transfers text from those pages into the REX. It would lack formatting, but would be a great way to grab some web zine articles for reading later."

The rexdk (based on the z88dk) (From Dominic, Damjan, and Daniel) <back to top>

The rexdk is probably the best development platform for REX add-in developers at this time. Daniel has been the driving force behind it for a great portion of the functionality it provides. Daniel completed a "final" release on 9/3/01. He said:

"All of the functions documented in the DSSDK doc are implemented now and the compiler should be quite stable. I've invested a lot of time in this "project", but I suppose we have a rather useable SDK now. I'm still working on the emulator but my current problem is that I would need a binary image of the 2nd chip memory. If anybody could help me with that a "true" rex emulator with a working database wouldn't be far away..."

(August 20, 2002)

"Hi all,

The new rexdk release is available along with a new website and a new domain name (although the old ones should work too). For further information see the readme file.

http://www.rexdk.tk"

"I've updated the rexdk with the latest additions...developers of 'big' addins (using libraries) should rebuild their projects with this release. The point is that old addins using libraries can't find libraries in the new firmware-holes like opened up by CalcBGon etc. So, for example, currently it isn't possible to load the MiniData libraries into the CalcBGon firmware-holes. In fact it is possible, but the main addin wouldn't find them, so pretty useless."

(Feb 24, 2002)

The library-signature is now inserted at the beginning of the bin-file. It is possible to test and debug library addins in the emulator. For details see the readme file. As usual everything is handled in the make file. Just one click to compile the library and one for the client..."

Updates to floating point and farcall function (1/28/02)

"Dominic has done some impressive work on the floating point part. Nearly all floating point functions are now separated in the genmath lib. So only the functions which are really needed are linked in. Also the compiler floating point part should work now (with some small inaccuarcies). So no need to specify -doublestr.

I've rewritten the whole farcall logic, which is now nearly totally transparent to the developer. There is no need to pass parameters with Write/ReadPar, you can pass them like to normal functions. I've written a small c program which adds a 3-letter signature to an addin, which can then be used to dynamically "link" to it. Use the FindLibrary function to search for the lib page from another addin. To call functions in the library addin you just need to define the correct function definitions. I've included two projects to explain this. If you need to return doubles use farcalld, otherwise simply farcall (see the samples). To build a library addin use the makelib batch file."

Updates and library function added (1/15/02):

"Hi all,

I've released a new version of rexdk. Graham Cobb has found a bug in the strcmp function, which is now corrected. The DsTrace function is now also available in the rexdk. For details see the readme file. The only difference is that the string must end with a \r instead of \n.

Also Waleed Hasan's library functions are implemented now. I've added 2 more pairs of read/write par functions, so you can pass a total of 4 parameters to a 'far' function. To pass other parameters than 16bit values, just pass the address of global variables. If they aren't 'overwritten' in the 'far' addin it should be possible to retrieve them from there.

So writing a library addin is simple now. One solution to the page-finding problem would be to 'force' the user to load the lib-addin in a given adder slot. Another solution would be to write a memo with the page number for every lib-addin. That's the way I've done it in Asteroids. Or we use a separate database."

You can also get the DSSDK emulator at Daniel's site, which Daniel has recently upgraded to include the REX firmware! Here's more information on the upgraded emulator.

Daniel even has REX 6000 memo database table descriptions!

(Note: The rexdk was developed from the original z88dk created for programming for machines based on the Z80 processor. The z88dk originally wasn't developed for the rex. It was developed (by Dominic Morris, Stefano Bodrato and Damjan Marion) for other machines which all have the same processor (z80), like the rex. The z88dk is not designed for use on a windows machine. Information on the original z88dk can be found at http://z88dk.sourceforge.net.)

Having problems running the emulators on Daniel's site on a laptop? Go here and get the emulatorL.zip file. Thanks to Peter Kong.

If you're going to use the rexdk, also see the note about Shai's development tools below in the Cool Developer Tools section:

"Hi all! Here is an info for developers. Shai´s Borland Development Tools also work for Turbo C++ 1.0. You can get Turbo C++ 1.0 as a free download from Borland at http://community.borland.com/museum (after a free registraton). Now you have nearly all the benefits from the former Turbo C. A source editor, compiling your files with one keystroke and best of all (thanks to Shai), the editor automaticaly jumps into compilation error locations by clicking on the apropriate error message."

The Small C REX SDK <back to top>

There is a downloadable REX SDK available on Myles' web site. Myles' site contains information and files for developing applications for the Zircom Rex 6000. He provides a full set of files needed to compile from C source code into a rex addin. Even if you are not going to rely on his SDK, Myles' site is a "must see" REX developer site for it's wide range of REX programming information.

The RxSDK <back to top>

Based on the SDCC (means Small Device C Compiler) is an ANSI-C Compiler which also supports the z80, but the z80 part isn't finished yet. Marc has modified this to support the rex, packaged it up again, and set up a webpage for it. Note that this SDK is at an earlier stage in development than the rexdk. Definitely worth looking at, but needs some additional development. Marc is working on additional documentation for his SDK as well. Mark's SDK package includes:

Updated on 1/06/02:

"Happy new-year everyone. Seems like I'm the first one to post this year (wonder if the list is still working)...

I've placed the latest version of the SDCC compiler package on my website --- please have a try ---.

Please note that I haven't had time to test the database functions and I'm not sure everything is there.

I've also updated the documentation and uploaded everything I had. Be aware that some of it is unverified (RxDb... functions), some of it is plainly wrong (e.g. RxDisplayTab) ... and some links are missing (e.g., RxDbBeginTransaction). But in return you'll get a preview of the images you get when using the RxDisplayComponent function (http://www.xs4all.nl/~nijweide/rex/RX_ID_COMPONENT.html) and a lot of other extra's.

BTW, currently I'm working on the farcall/library mechanism, but I've run into a little problem: the global variables of the library addin. Does anyone have some ideas about the best way to keep them seperated from the 'main' addin and other library addins? Is there a map of the RAM, which areas are free to use, which aren't?"

Updated on 9/27/01:

"I've updated the RxSDK package on my website and also uploaded some new documentation. SDCC is reasonably stable, at least all bugs I've encountered are gone. Usually the SDCC developer guys are very quick in solving them (think in terms of hours here). SDCC also includes support for long integers now. Still no float though and I don't think there will be.

There is now a little addin included that is able to communicate over the serial port and that is able to send any page that can also be seen with the memview addin. There is a host program (RxSerial) included. Be aware though that this is alpha code and may contain a number of bugs. The next extension I have on my mind is to add support to write addins to the Flash memory using this addin... but I think I'll first have a look at SDCC to see if it can be easily modified to create larger then 8k addins (I'm running into that limit much to often)."

The REX 6000 Optimizing C Software Development Kit: <back to top>

"There is a new REX SDK available to create addin programs. The SDK contains the following programs: ANSI C compiler, Z80 assembler, Object Linker, Icon Creation Utility, Rex to Emulator Utility. The C compiler generates native Z80 code which results in faster execution time. Try out the prime example program (it takes about 31 seconds). Please give this a try. I look forward to hearing any comments, bugs or requests." (From Mike)

Global Optimiztion added. (10/28/01)

"I have just released an updated version of my REX SDK. The major new feature in this release is global optimization. With global optimization there can be the opportunity to significantly improve the execution time of an application. For certain applications that can be critcal.

Here are some benchmark results:

Benchmark OptRDK -O OptRDK RexDK
prime 17.0 30.3 45.7
queens 17.3 22.3 38.0?

New features in this release:

Btw, multi-diminsonal arrays supported as always ;-) Feedback is welcome."

Some additional Q&A on the new SDK from the developer's mailing list:

"-Where is the compiler coming from? Or is it your own compiler??

The compiler was created by myself.

-What source code did you use for the library? Is it based on the rexdk library?

The library source code was also written for this compiler. For the SYS*** calls I did look at what the RexDK to see exactly what function was being preformed so I could do the same.

-Why didn't you include the source code?

I guess I didn't know if there was a want/need for the source code. I have no problem distributing some of the library code but at this time I have no plans to distributing the source code for the compiler. Let me know have more questions or need more info.

- Does it support floating point functions?

At this point the compiler does not support floating point for the REX. It will parse any floating point constructs but when it comes time to generate code it is missing support. Supporting floating point is on my list of things to support (but not on the top ;-("

Dynamic Link Libraries!

Recently (Jan 15, 2002) there has been a lot of work going on to implement libraries and enable linking to them dynamically from add-ins. Libraries are sets of code stored on the REX that other add-ins can use. Libraries allow common functions to be stored once on the REX and used by any add-in, allowing for more custom functions and features in the add-in itself! Waleed, Marc, Daniel, Dom, Graham and others have been instrumental in forging ahead in this move to a more sophisticated and powerful REX development environment. From Chris on Graham's work:

"I finally got a chance to browse Graham's very professional contributions, and all I can say is WOW!!! ... He has done an excellent job of creating what we have needed for a long time - a well written & documented Rex-6000 shared library package."

The developers are working on ways of storing these libraries in "holes" in the REX firmware, so they can have access to them on the REX without using up any of the 24 add-in slots provided by adder.

Initial release:

Dynamic Linking package. (From Graham)

"I have just released a "dynamic linking" package. See http://www.cobb.uk.net/Rex/Dynlink/ for details. This is a package which provides an easy method for an addin to call routines in another addin. This simplifies splitting code across multiple addins or creating a shareable library of utility functions.

There is more overhead than in the "jump table" approach recently proposed by Marc Nijweide and it might be worth trying to combine some of these ideas. In the meantime, I welcome comments or suggestions on the dynlink package. Also, if you use it or find it useful please let me know."

Graham's work includes the following libraries recently released:

"REGISTRY is a library of routines to store data similarly to the MS Windows registry. This is designed to avoid having to clutter the user's memos with INI files. This is version 0.2 which seems to work but there are some important things that still need doing:

1) a REGEDIT-style program to export and import registry values (e.g. so that users can import a memo with initial values and then delete the memo);
2) create a shareable library version of it so that you don't need to link all the registry code into your addin.

GRCLIB is a library of "useful" routines, which I use in most of my software. This is version 1.0 and comes in staticly linked and dynamicly linked versions."

Updated May 23, 2002

"I have rebuilt my libraries and tools with the latest RexDk, incorporating the new FindLib. This means they should work properly if loaded into the new holes made available by Chris's Bgone utilities (although I have only tested them using Adder slots).

The versions are:

As always, you can find them from my Rex page:

http://www.cobb.uk.net/Rex/index.html

Updated May 23, 2002

Chris noticed and pointed out a dependency in two of Graham's libraries. Graham has some updates to deal with the issue:

"Chris's comments pointed out an unintentional dependency between Registry and GRClib. Although some people may be using both, I hadn't intended that you had to have GRCLIB loaded in order to use Registry. MemoIO also has the same problem.

So, I have released updated versions of all three libraries: GRClib - V1.3, Registry - V0.5, MemoIO - V0.3. I have also updated the documentation pages to try explain the dependencies more carefully.

Basically, if you link with the sharable library versions of Registry (registry-so) or MemoIO (memoio-so), you need to include GRClib in your link command to provide a couple of small routines used by the stubs which call the shareable libraries. I recommend that you use -lgrclib unless you already have a dependency on the GRCLIB shareable library for other routines, in which case you will be using -lgrclib-so already.

Here is the list of dependencies between library addins:

GRCLIB1: no dependencies

REGISTRY: no dependencies

REGISTRY2 (only required for import/export routines): depends on
REGISTRY, MEMOIO-READ and MEMOIO-WRITE (for export only)

MEMOIO-READ: no dependencies

MEMOIO-WRITE (only required for Memo write access): depends on MEMOIO-READ

The net result is that if you use Registry or MemoIO but do not use GRClib you no longer need the GRCLIB library addin loaded.

As always, the updated libraries are available at:

http://www.cobb.uk.net/Rex

and all comments are welcome."

Updated May 22, 2002

"I have released new versions of my Registry (V0.4), GRClib (V1.2) and MemoIO (V0.2) libraries. You can download them from:

http://www.cobb.uk.net/Rex/

These new versions do not contain any feature changes (or any major bug fixes) but they work with the "new" (actually, not so new any more) Rexdk library mechanism. This means that I have retired Dynlink as it is not needed any more and it also means that the libraries and the client code have all got smaller.

I have also fixed findlib so that it finds libraries loaded into Adder. The fixed findlib.asm is ... available as:

http://www.cobb.uk.net/Rex/findlib.asm

In order to use this, do the following steps:

1) Put the new findlib.asm in your rexdk\libsrc\rex\farcall directory (replacing the one already there)
2) cd to the rexdk\libsrc directory
3) execute: ..\bin\z80asm -l -v -d -ns -nm -Mo -DFORrex -xrex_clib.lib @rex6000.lst
4) copy rex_clib.lib ..\lib\clibs

(Steps 3 and 4 can be replaced by executing the REXmake.bat file if you have installed the Rexdk in C:\REXDK)

As always, please let me know of any bugs, fixes or enhancements to these libraries, or just if you find them useful!

By the way, I plan to implement full binary mode support (memo_read and memo_write) and buffered I/O support (so memo_getc and memo_putc are rather more efficient) in MemoIO soon. If these would be useful to you, let me know as it may encourage me to add them sooner."

Udpated Jan 30, 2002 - Graham releases one new and two updated programming libraries.

"I have just released new versions of my libraries plus a new one.

Dynlink V0.3. This adds a new FarCall mechanism, not using the mechanism provided in the Rexdk. This allows for variable length argument lists and for returning short or long values, eliminating "helper routines". It is also re-entrant, allowing one library to call another. Note: I am not claiming this is better than the new mechanism in the latest Rexdk -- I haven't had a chance to look at that yet. Hopefully I can throw away my own mechanism.

As always:

This code was written for my own use but it is released under the GPL and others are welcome to use it or the ideas contained in it. I am always interested to hear of anyone using the code or finding (or fixing) bugs or just comments!

More information is on http://www.cobb.uk.net/Rex"

Must Have Developer Documentation and Information <back to top>

Myles Rexextras web site has created a wealth of information and documentation critical to anyone planning on developing for the REX. He has compiled the following information:

Do NOT miss Myles' site if you are interested in developing for the REX.

Di's Technical REX site for contains extensive background on the REX hardware, DS2 to REX comparisons (with screen shots), REX hardware diagrams, communication protocol notes, tools and utilities, and other cool stuff. Take a look!

Breakthrough in understanding REX file system! (From Chris)

One of the issues holding back some development work on the REX was a clear understanding of how the REX database utilizes the flash memory in the REX. Well, Chris (yup - Mr. Adder himself) went fishing, and has found the key information:

"I'm happy to announce, I just got a response from tech support at Fujitsu, and there IS a document on the Sophisticated Flash File System (SoFFS) in the public domain:

http://www.fujitsumicro.com/pdf/understd17n.pdf

It includes a summary of the API of the SoFFS, and details on how SoFFS uses flash memory. At first, I didn't recognize much of anything in this document, until, DUH!, I realized that the signature we see on each 64KB sector in flash memory ("CISF9 FTL100" ) is precisely the Erase Unit Header (EUH) prefix - see page 7.

Take a look - I believe we'll find this document explains everything we wanted to know about how the Rex database utilizes the flash memory. For one thing, I'm looking into how to set the Block Allocation Maps (BAM) of a number of sectors, so we can reserve a variable amount of flash memory - as Marc suggested, say 1MB or so - for addins!"

This flash memory "Rosetta Stone" will provide our developers with important information in their quest to continue to enhance the usability and fun that the REX provides. Great sleuthing, Chris!

If you are looking for Firmware information, see below in the Firmware section. In particular, Peter's "Green Guy's Guide to the REX 6000" is a very useful site!

Documenation on the REX sound hardware.

See the Sound page on the Ozdev.com site for information on the REX sound hardware (and it's limitations!). For more on the Ozdev site and the similarities between the Sharp Wizard Z80 and the REX, see this section below.

Cool Developer Utilities <back to top>

BMP2REX

"I made a small tool for the REX users/developpers called BMP2REX.

The main purpose of this tool was first for me to generate REX bitmaps/icons that can be inserted directly into a XML page (to be Synch after with).

There's a "readme.txt" for more info in the attached zip file. BMP2REX uses "convbmp.exe" and "MMencode.exe" provided in the zip too. I don't plan to maintain it (so far). If it's found usefull and/or needs to be improved I can provide the source code (in Visual C++)."

MemView add-in - REX memory viewer by the author of the RxSDK. (From Marc)

Marc's add-in is notable in that he has "found" the second 2 MB chip in the REX, that had previously avoided detection by available REX hardware sniffers:

"MemView allows you to view _all_ memory in the rex, including the additional ROM's and RAM's. The addin uses the bank registers (HI and LO) to map the memory to A000. The first 256 pages (0000-00FF) map to the first 2 Mb. The second 2Mb is located at 0600-06FF. There is some ROM/RAM at 0200 and 0A00 and the 32k RAM is at 1000-1003. The data at 0200 can only be read when there are batteries in the Rex and appears to contain the modem ID of the Rex. It also appears to be part ROM and part RAM... I suspect this is one of the reasons why you can't sync the rex without batteries."

"Marc, Hey, alright! You found the second 2MB flash memory! And sure enough, it looks just like the second half of the first 2MB memory, with the database header "CISF9,FTL100" on every 64KB sector. So, if I understand this correctly, the Rex actually has close to 3MB available in its database??? (less 128KB at pages 0080-008f)." (Chris H.)

RexDump - Hex-dump Memory Viewer for the REX Firmware! (From Chris H.) <back to top>

". . . a Rex memory viewer, hex-dump style, called "Rex Dump". It will dump the contents of the Rex firmware to a "memo" database file, which you can then upload to a PC via Rex Tools, and run your disassembler of choice. . . .

It's very primitive, only supports scrolling up and down, always starts at location 0000, and only views the first 64K of Rex memory. Just thought I'd share it with the Rex community, as a baby step towards greater things. The "back" key jumps (forward!) by 1000h, so you can get where you want to go quickly.

I wrote this app in Z-80 assembly language, using what I've gleaned by disassembling some of the existing Rex add-ins. Not the easiest way to program (I do C/C++ for a living), but not that hard either."

"Also, some highlights in the existing Rex 6K firmware (1.1.2.7 in mine): - the 8 RST vectors at 0000, 0008, etc. - REX s/n at 1EF0 (in mine) - strings around 1BB8, 4660, 48A0, and 6250-6C40 - the RST 10 jump vectors at 4F00."

Shai's Borland Development Tools

Shai has created some Borland development tools and a bitmap converter!

"I have added some REX developer tools to my site for those who are interested. During coding for REX I have developped some tools to help with the programing. I wish to share them with others, I hope it might help. Compiling under BorlandC 3.1 IDE environment."

Shai also has a bitmap conversion program!

"Converting Bitmaps. The convbmp utility is a small program to convert windows bitmaps into rex images. It accepts at its command line a list of files representing windows bitmaps (only 2 color B/W bitmaps will work). It then produces on the standart output a small code that repesent a REX image. This code can be redirected into a file."

Nice work Shai!

Free Turbo C++ and Shai's tools work together!. (From A_Poplawski)

"Hi all! Here is an info for developers. Shai´s Borland Development Tools also work for Turbo C++ 1.0. You can get Turbo C++ 1.0 as a free download from Borland at http://community.borland.com/museum (after a free registraton). Now you have nearly all the benefits from the former Turbo C. A source editor, compiling your files with one keystroke and best of all (thanks to Shai), the editor automaticaly jumps into compilation error locations by clicking on the apropriate error message."

Free disassembler. (From Daniel)

"While searching the internet I came across a freeware version of the famous IDA disassembler. It is actually a much more sophisticated disassembler than the dz80 is. The free version just has a dos interface but it works quite well.

http://www.simtel.net/pub/pd/29498.html."

Automatically create a memo in the emulator for add-in development . (From Daverex)

"Hi all! First of all I want to thank you all the excellent minds who have been contributing to this list and have given a huge push to REX development (libraries, enhaced compilers, farcalls, sample code, etc). I can't do other thing but sit and watch in amazement !!

While these geniuses work in how to use easily the database within the emulator, I want to contribute with a very little thing useful for beginers: An addin that writes a memo . Run it in the emulator previous to your addin (this one will find a memo ready to use in the emulator!!).

In addition I've created a simple VB program that will read any text file of your PC and will generate the C code for the above dummy addin. I have used it to develop my SunMoon addin and now I want to share it with all of you....

You can find them at this page:

http://www.geocities.com/davrex6000/Develop/Develop.html

I hope you find this useful !"

REX Tools for Linux! Yes - you heard that right!! (From Majek)

"First alpha version of RexTools for Linux is out! Now there are three programs:

  1. rexdate - get/set date
  2. rexdefrag - defragmenting rex
  3. rexdbdump - dumping database from rex with format compatible with RexToolsBeta

It don't work on 50% computers which i tested on, and there is why this is alpha, not beta release."

Great work from Majek. Posting this info on this page in case there are any Linux developers wondering what's going on with Linux and the REX! Contact Majeck for more information.

Linux development rolls on. Really! (From Tim)

"I am trying to arrange a development environment under Linux. Thought a native X-Window emulator, like PalmOS Emulator, would come out quite handy, have hacked a very preliminary GTK+ prototype of it. Just loads firmware and runs it, doing very basic memory banks switching, no input/output supported yet.

"Here's a screenshot of Rex emulator running on a Linux box. Still a LOT to be done, but at least it boots and even manages to draw the startup screen."

Linux-compatible REX development tools. (From Simon)

"If someone is interested, I've updated the conv2rex utility and added a new "viewrex" util on my homepage, see:

http://www.student.lu.se/~etn97ksi/sim_home/rex.html

Both programs are released under the GPL.

I've fixed some bugs in conv2rex, cleaned up the source and added some features. conv2rex can now convert images with arbitrary color-depth to REX bitmaps in source form (for use in C-programs), binary form and also icons for use in .res-files.

Viewrex displays REX images on a host computer from files (the image must be in binary format).

Both programs are written in C using libSDL, so I *hope* they should be portable to Windows and other platforms. I'm using getopt(), and I'm not sure if that's available in windows. If anyone would like to contribute windows executable(s), I'd be glad to place them on the homepage."

REX Serial Communication <back to top>

7/15/01: Developer news -REX serial communication success! (From Gerd)

"It looks like I can claim to be the first to have serial connection to the Rex 6000 in the normal mode ;-) The Xbasic code can be found on my web page xtide.ldeo.columbia.edu/~krahmann/rex/rex.html.

I was rather lucky in the end. I was perfectly reproducing the serial port log from the rextools but did not get an answer. When I by chance sent the DS... sequence a second time I got an answer. As odd as it sounds I always have to send them twice ! I have tried only the initialization and the version commands but I have no doubt the others will work too.

Update: " it's working with single write statement now. The write buffer wasn't flushed. I will update the code on the page tomorrow."

Next question, what kind of program do we want? I could write a standalone in xbasic which would output everything into plain readable files. I think I would not be up to write synchronizing software.

And unfortunately my Xbasic code depends on windows dll's. Thus it won't run under other operating systems (e.g. linux).

Anyway, I hope that somebody joins me now ;-)"

What about the REX 6000 Serial Protocol? (From Peter)

"From observations using a serial tap and examining Rex.dll in the Windows\System, a complete set of available commands were compiled. Directly testing these commands and using information obtained from syncronization using both Intellisync and Rextools, some of the details of the protocols and parameter values were obtained and are presented in this document."

If you are interested in more of this (and I know a lot of you are!) look here. Thanks, Peter!

Communication type libraries for the REX 6K. (From Kevin.)

"These are the communication type libraries (as published on a W2K machine) for the REX 6K. They are text files that describe how to communicate communicate (through COM) with the REX. These are published interfaces inside of windows. Also, you might want to glance at all the references to DS2 in the comments, an interesting read. I think they would be helpful to anyone trying to create third party sync software.

Here are the libraries for now. We'll try to get them located on Di's technical REX page soon.

"There is a direct way to import type libraries. This allows for code completion and better compiler error generation.

  1. In Delphi: Menu -> Project -> Import Type Library
  2. In VB: Menu -> Project -> References

I'm sure VC++ is similar... I'd be willing to bet there is a one to one translation between these calls and Di's CMDTool."

Serial traffic sequence for REX firmware update. (From Peter.)

"This is the serial traffic sequence when you put REX.BIN in the RexTools directory and select "Firmware Update" in RexTools. This uploads the contents of REX.BIN to the Rex. The sequence below describes what happens. Knowing this one could add this feature to any utility destined to replace or enhance Xircom's RexTools.

Synopsis of recorded serial session with RexTool's "Firmware Update"

Legend:
> = to Rex, < = from Rex, \r = CR(0x0D), \n = LF(0x0A), \nmo(numeric) = nmo (decimal)
the quotes delimit traffic content.

Recording begins after RexTools initial scan,
and just before selecting "Firmware Update" in RexTools menu.

To Serial Message comment
-----------------------------------------
> "DSBS0000EC\n" start session command
< "OK9A\n" acknowlege
> "DSSG31\n" defrag command
< "OK9A\n" acknowlege
> "DSBE1E\n end session command
< "OK9A\n" acknowlege

> "DSBS0000EC\n" start sesion command
< "OK9A\n" acknowlege

> "DSUF32\n" update firmware command
< "OK9A\n" acknowlege

> "\002"
< "REX6000 Boot loader "
< "Ver1.1(@(#)bboot.c"
< " 1.2)\r\n"
< "Block size=8kbytes\r\n"
< "ENTRY=$2000\r\n\006"

> 1st 8k block sent in as a pair of 4k packet
< "?ABS_ENTRY_M\r\n\006"

> after each susequent 8k blocks in two 4k packet:
< "/006"
..........
..........
..........

last block is a 4k packet followed by 1859 bytes
PC does not wait for response, but clears DTR and closes commport

However Rex sends back:
< "Detect S9\r\n"
< "Completed.\r\n"

End of serial recording.

Note: See the Linux section on our Operating System Compatibility page for available Linux software and information on communication tools for Linux!

Firmware Information <back to top>

After you review this section, don't forget the information below on putting the REX firmware on a DS2!

Firmware information (and questions!) (Chris H.)

"I have analyzed the Rex.bin file, here are some preliminary findings:

Rex.bin is composed of 4 different types of packets, with header strings S0, S1, S2, and S9. All of the code in the "normally resident" portion of Rex memory (as viewed with my RexDump utility) is loaded from the S1 packets. The S2 packets constitute apparently 15 blocks of 64k firmware, labelled 00-0f (there is no 06). I have located some of the areas of code I am interested in modifying, but still have one open issue: the packets use an 8 bit checksum (or CRC), but I feel stupid because I have not yet been able to decode it. It doesn't appear to be a simple XOR checksum. Any hackers out there can break this simple (appearing) code?! Here's a small sample packet: Sample packet: 53 31 06 50 00 C3 03 50 [93] where: "S" "1" msglen addr data... checksum"

This morning I regenerated the sixteen 64K byte "pages" (for lack of a better term) of firmware contained in Rex.bin, posted at:

http://www.io.com/~harris8/rbinaries.zip

Each file is 64K bytes, named r00.bin, r01.bin, ... r0f.bin (except no r06.bin). I named the 16-bit address (S1 records) "page" = r0000.bin, which is the page I've been calling the "resident" page, as it is visible while running RexDump. Each file is padded with 00's, ready to run through your favorite disassembler.

Let me know if you find any discrepancies between the regenerated code and Rex.bin Have fun!"

Tons of information on the REX firmware.

Peter's "Green Guy" REX site (that's the Green Guy, above!) contains excellent information on the REX firmware and REX serial communication. Peter's information includes:

From Peter on his firmware information/downloads:

"Discovered a minor mistake in my previous output of memory written by REX.BIN due to signed/unsigned errors in my code. So I've put 3 files on my website. Two are zipped versions of the 1MB memory image. One is prefilled with zeroes and the other is prefilled with 0xFF's (erased flash is usually all filled with 0xFF's). Both are then written to with REX.BIN. The comparison of the two, results in a mapping of areas of memory not written by REX.BIN and therefore probably unused. It also results in a much smaller file that list addresses of unused vs used memory. This could be useful to people trying to dissemble code. Unwritten areas that are referred to by a disassembly could mean that one is erroneously decoding a data area as a program area.

Also, I did screw up on using 0x0F and meant 0xFF. Unfortunately, I'm used to bytes values as two hexadecimal characters like or 0xff, but one compiler I use in the past would not accept 0xff style as valid hex, but would insist on requiring "0x0" so that 0xff had to be 0x0ff. Once in while the two opposing trends clash, an unfinished 0x0ff written 0x0f is correct from both perspectives, but is an incorrect value. Peter"

A Motorola S-Record connection! (More from Peter)

(Peter) "It appears to be a bastardized Motorola S-Record. It follows the format but other then the Sx line headers in Ascii, the data is in raw binary. The standard is all data is in ascii hex and each Sx line terminated with CRLF. The 8-bit checksum is the one's complement sum of the bytes after the Sx header up to the checksum ( = ~(unsigned sum of data) & 0x0F).

Motorola S-Records:
Info:
SO, length(byte), addr(2 bytes) = 0000, text data usually title, version etc., chksum

16-bit address:
S1, length(byte), addr(2 bytes), data (length-3 bytes), chksum (byte)
S9, length(byte) = 3, starting execution address in 2 bytes, chksum (byte)

24-bit address:
S2, length(byte), addr(3 bytes), data (length-4 bytes), chksum (byte)
S8, length(byte) = 4, starting execution address in 3 bytes, chksum (byte)

32-bit address:
S3, length(byte), addr(4 bytes), data (length-5 bytes), chksum (byte)
S7, length(byte) = 5, starting execution address in 4 bytes, chksum (byte)

Count of total records of type S1,S2,S3 already sent
S5, length(byte) = 3 , count (2 bytes)"

S-Record verified. (From Peter.)

"Cranked some code and verified that the rex.bin is definitely a modified Motorola S-Record. I had my program examine it for valid S-code and checksum and listed each block of records written to an address. It tends to write 128 bytes (16 at a time) to each block upwards from a base address and then drops 128 bytes from the last base address to write another 128. At other times it writes scattered bytes in other locations. First entry is the length of the file minus the four bytes used for the length. The second entry is for an S0 record with its text content. I only generated entries for S0,S1,S2,S3. The only S-code I didn't bother with is the S9 at the very end." Peter's result file can be found here.

Important Sharp Wizard "family" resemblence (from Benjamin)

The Sharp Wizard Z80 and REX may share the same (or similar) processor! Recently (11/1/01) Benjamin from the Sharp Developer group contacted REX developers about sharing information. The Sharp Developer group (OZDEV) has already done work similar to that of our REX development community. Sharing information should help both groups!

"Hi,

Firstly, thanks for providing resources on the rex. All too often it seems that manufacturers are incapable of providing useful development support.

I'm part of a group (ozdev, www.ozdev.com ) that has, to some extent, reverse-engineered the hardware and software of the current line of Sharp Wizard organisers (oz730,750,770). For the longest time we couldn't find any clue as to the particular flavour of Z80 cpu the wizard had. Then, yesterday, I came across your site and a couple of other rex-related sites. Snap.

The rex-3/5000/6000 and the wizard 7xx appear to use the same (or a very similar) processor - a Z80 with built-in memory unit, interrupt controller, power down modes, lcd controller, real time clock, uart. The memory scheme is the same, as is the allocation of ports.

The hardware section of the ozdev site: http://www.ozdev.com/knowledge/hardware/ may be of interest (although it's mostly on-par with what you have). If there are any processor related things I might be able to help with, I'd be happy to.

I am about to contact the z88dk people to inform them of this (they recently started looking at the wizard; given that they support the rex already, the similarities might already be obvious to them- if not, it should be pointed out).

I'll also contact toshiba and try to extract a complete cpu datasheet. My experience with this kind of operation is that it's difficult, but not impossible."

More fun stuff <back to top>

A number of programmers have been playing around with the DS2 SDK and different programming tools to see if they could come up with a way to create English-language add-ins without the benefit of an actual REX 6000 SDK. (Yeah - that's life on the edge!)

Below is a link to downlaod the file (it's been zipped) dataslim.lib (dataslim.asm). This file is in assembly, and so may enable a work-around of workaround of the problems linking with dataslim.lib. The asm (assembly) file is made to be compiled with TASM.

Here is the file - enjoy, and post anything you find of interest or questions to REX Rumor Central.

And, here's a description of how to rename a Japanese add-in using a HEX editor.

Need a HEX editor? Check here. (Thanks, Bill)

Some Speculation on the REX Add-in Environment <back to top>

In addition to the information below, Amiram has provided us with some very interesting speculation on the REX 6000 Technical Architecture.

The REX 6000 can only load a maximum of 8 Addins (Extras). [NOTE: This limit has been broken by Chris' add-in "Adder" which allows loading of up to 18 add-ins. See the Add-in and Other REX Programs page for more on Adder.]. At 8KB each, that means there is about 64KB in the device available for third party applications. If the author of Tiny Draw's observations in his "readmee.txt" file that accompanies the program is also applicable to the REX 6000, then that math works out about right.

It seems a common 4KB is set aside for whichever Addin is executing at the moment.

It is interesting to note that if you are in the process of viewing info on a given contact for example, you can switch to the calendar and do a detailed lookup there, and switch back and forth between the two using the "task switcher bar" without losing the context of the screen you were using in the other application.

This all may mean that more robust applications for the REX might have to be written in separate modules, not unlike the separate Citizen programs for drawing and viewing images.

It is interesting to note that in the screen shot in the online REX 6000 User Guide that shows how to uncheck Add-ins in the Memory Settings section of the Controls application, the two visible Add-ins on the REX 6000 are shown to be 12KB and 23KB. So maybe the REX 6000 has a capacity for larger Add-ins than the DataSlim 2 does. [NOTE: The rexdk allows development of add-ins that use more than one add-in "page," which will allow development of add-ins larger than 8K.]

See below:

Additional Technical Links <back to top>

The key technical links for developers are in the page above.

In case you missed it above, make sure you visit Di's Technical REX site for extensive background on the REX hardware and other cool stuff.

Here's some other miscellaneous stuff:

And here are a couple more links, really just subordinate links to the ones above, but they do have some interesting content:

DS2 to REX user provides report on satisfaction w/the conversion. (From Chris, creator of Adder and cMemo)

Below is an interesting exchange between Chris and a DS2 user he assisted in loading the REX firmware on his DS2. Their exchange below consists of a series of questions from Chris (preceded by the ">" symbol) and his responses:

"> How's your "new" Rex working? Any surprises or problems?

Everything seems to be perfect, except the memory size. The DS2 has 1Mbyte only (I tested it by downloading known amount of web content).

> Does the converted DS2 support the Rex "web browser" feature? If you are willing to give it a try, there are a couple options - please see Rex6000.org "Web Sync" link for more info. Note: I haven't tried any of these myself, as I have no interest in loading web content on my Rex!

I tried the rex.mammy, and it seems OK. Anyway this task is mainly done by the Intellisync, isn't it?

> Also, simple question: do the white buttons along the bottom of your DS2 work properly? The only "wrong" one should be the "Books" button, which now should display the "Download web content..." screen, correct?

Not really, the converted DS2/REX has the same button positions as the REX, which is slightly different from the DS2.

> Is there any speed advantage or battery life advantage to using the DS2 as a Rex? That is, is your converted Rex/DS2 any faster or have longer battery life than a "real" Rex? Unfortunately, I know of no simple empirical tests for either. Personally, I suspect there is no significant difference. There is only so much that can be done with the "ancient" Z80 processor!

I guessed the higher speed from the shorter expected battery lifetime predicted by the japanese manual (which could mean higher clock frequency in case of the same architectures) - but it has no real significance in my case.

> Regarding "real memory size", it is now quite clear that the Rex actually has nearly 3MB available for database, and the "2 MB" displayed on the Memory function is a hard-coded approximation.

The DS2 seems to be the 1Mbyte REX version - with a hiragana/katakana/kanji character map hidden somewhere.

Thank you very much again, Chris!"

<back to top>