|
|
| (3 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| Each REX ships with all the software needed for normal use of REX.
| |
|
| |
|
| Once REX is installed, and the REX system is installed, you will be able to access the REX Manager.
| |
|
| |
| REX Manager allows the user to:
| |
| * load and save binary OPTION ROM images to/from TPDD
| |
| * select an OPTION ROM for use from the list of stored images
| |
| * manage images in the directory (kill, name, copy, calculate checksum etc.)
| |
| * create and manage RAM images
| |
| * load and save binary RAM images to/from TPDD
| |
|
| |
|
| |
| REX ships with TS-DOS pre-loaded. Once REX is completely installed, the user should be able to access TS-DOS immediately.
| |
|
| |
| A collection of tested good, fully compatible ROM images is available for download from this wiki. To load these images for use into REX, you must
| |
| * download these binary files ( .BX extensions)
| |
| * place them on you favorite TPDD protocol based remote storage device (NADSBox, LaddieCon etc)
| |
| * make sure they are "visible" to TS-DOS (so they are ready to be read by REX)
| |
| * start REX Manager
| |
| * TAB to the ROM group
| |
| * place the cursor over a free slot
| |
| * press F2 to LOAD
| |
| * provide the filename for the desired ROM image as named on the TPDD device
| |
| * REX Manager will load that image into REX
| |
| * following a successful load, the user must ACTIVATE that OPTION ROM for use.
| |
|
| |
|
| |
|
| |
|
| |
|
| |
| == REX SYSTEM Images ==
| |
|
| |
| REX SYSTEM images contain the REX Manager software package, including the default directories, and are 32kbyte binary files. For M100/T102, images have filenames of REX1XX.BR, and T200 images have filenames of REX2XX.BR, where XX is the release number.
| |
|
| |
| <table border="1">
| |
| <tr><td>Status</td><td>Release</td><td>Model</td><td>Description</td><td>File</td><td>Submitter / Date</td></tr>
| |
| <tr><td>GA</td><td>4.5</td><td>M100/T102</td><td>Initial REXROM release</td><td>[[Media:REX145.BR|REX145.BR]]</td><td>[[User:Sadolph|Sadolph]] 11:56, 1 July 2009 (PDT)</td></tr>
| |
| </table>
| |
|
| |
| == REXU - REX Upgrade Utility ==
| |
|
| |
|
| |
|
| |
| <table border="1">
| |
| <tr><td>Status</td><td>Release</td><td>Model</td><td>Description</td><td>File</td><td>Submitter / Date</td></tr>
| |
| <tr><td>GA</td><td>2.0</td><td>M100/T102</td><td>REX Upgrade Tool</td><td>[[Media:REXU1.CO|REXU1.CO]]</td><td>[[User:Sadolph|Sadolph]] 11:57, 1 July 2009 (PDT)</td></tr>
| |
| </table>
| |
|
| |
|
| |
|
| |
| REXU is a utility that allows the user to upgrade the internal REX Manager software. REXU first provides a mechanism to save the entire contents of block 0 of REX to a file on TPDD. This is critical to allow a restore of your REX should there be a problem with the upgrade.
| |
|
| |
| To use REXU, a TPDD device must be attached to the laptop, and be ready to use. The TPDD device must have a copy of the upgrade file, REX###.BR.
| |
|
| |
| Follow your usual procedures to load REXU#.CO into your laptop. Make sure you clear enough upper memory to RUNM this application.
| |
|
| |
| The user is first asked if they wish to store the current SYSTEM to disk. If not, then the user is sent to the next stage in the process. If the user wishes to create a restore file, then the user must provide a 6 byte file name. When entering a file name, <ESC> key aborts the process.
| |
|
| |
| System images are 32kbyte binary files with the extension .BR. When TPDD is ready to use, hitting any key commences a transfer of the SYSTEM to a TPDD file as specified.
| |
|
| |
| The next stage is the flash upgrade process. Here the user must select what type of upgrade is desired - either a 16k upgrade, or a 32k upgrade. In the REX SYSTEM image, the software exists in the first 16k of the image file, and the directories (specific to each REX in use) is stored in the upper 16k. Typically the user will want to keep their directory, and upgrade their software only. This would be a 16k upgrade.
| |
|
| |
| Again, the typical selection is to do a 16k upgrade of the software only.
| |
|
| |
| Only in special cases will the user actually want to do a full 32k upgrade. Doing so restores the directories to their original state, erasing any record of the contents of REX.
| |
|
| |
| The user can choose to exit the application at this point by typing <Q> or <ESC>. Choosing <1> or <2> selects either 16k or 32k upgrade respectively.
| |
|
| |
| Once the size of the upgrade is chosen, the user is again prompted for a 6 byte filename. This filename should be the name of the upgrade file on the TPDD device. After entering the name, ensure the TPDD device is ready, and hit any key to proceed.
| |
|
| |
| The flash upgrade of REX commences at this point.
| |
|
| |
| Be careful to keep the laptop powered up during the flash process!
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
| REXMR.CO is a utility that allows the user to program upgraded main rom images into REX for use in "ROM Replacement" installations.
| |
|
| |
|
| |
|
| |
| == Rel. 4.5 testing: bug reports/fixes ==
| |
|
| |
|
| |
| 1) It has been pointed out that if one deletes REXMGR.BA, it can be difficult to get it back. I'm thinking of an emergency keystroke that will allow one to recover from this.
| |
|
| |
| 2) REX is limited to 12 images right now. I will have a fix ready in the next release.
| |
|
| |
|
| |
| == Rel. 4.3 Beta testing: bug reports/fixes ==
| |
|
| |
| I should not have sent out the "4.3 beta" a few weeks ago as it was too alpha.
| |
|
| |
| I found a number of bugs that were subtle and affected stability. Now that those are resolved, and the TPDD routines are robust to TPDD problems, I now have a candidate final load. All the features I have considered have been implemented.
| |
|
| |
| R4.3b supports M100/T102 only right now.
| |
|
| |
| Tested drive targets include: NADSbox, LaddieCon, TPDD-1, TPDD-2
| |
|
| |
|
| |
|
| |
| 1) fixed in 4.3 - timeout of TPDD 1/2 - after loading an image, a command response times out at the end...need to extend the timeout delay.
| |
|
| |
| == Rel. 4.2 Beta testing: bug reports/fixes ==
| |
|
| |
| 1) DONE R4.3 - found error in code - Year bug - the year data is not correctly preserved by REX when RAM images are saved and loaded. Solution - implement a mechanism that maintains the year data properly.
| |
|
| |
| 2) directory bug with entry for block 31 - it appears that the name entry for block 31 is not displayed correctly, investigation continuing.
| |
|
| |
| 3) DONE R4.3 - sound is disabled - sounds - currently REX uses audible clicks to indicate progress, which can be annoying. Solution - disable audio, replace with some other mechanism.
| |
|
| |
| 4) DONE R4.3 - directories are now sorted in descending order of date/time - directory order - current directory entries are displayed in order of block number, which is problematic since this causes reordering whenever REX garbage collection forces an image to be moved from one block to another.
| |
|
| |
| 5) DONE R4.3 - Overall stability - Identified and fixed two subtle bugs relating to interrupt handling and bank switching.
| |
|
| |
| 6) DONE R4.3 - Robustness for TPDD routines - major rewrite of the TPDD routines in 4.3.
| |
|
| |
| 7) DONE R4.3 - included choice for refresh or revert - Restore from current ram image - there is no easy way to restore from the current backup image. Solution TBD. work around is to copy the backup image to a new block, and then install that image.
| |
|
| |
| 8) DONE R4.3 - non-blank block recovery - it is possible that REX attempts to copy an image to a non blank block. This situation is indicitive of a problem with the system since this should never happen. If it does occur, the system gets in a deadlock condition. Solution - make sure REX has no bugs in this functionality first, but an option to "name" or "delete" the offending block would be a nice safety system.
| |
|
| |
| 9) DONE R4.3 - enter function displayed on line 2 - state function of <enter> for cursor item on screen somewhere - don't leave it to memory only
| |
|
| |
| 10) DONE R4.3 - <TAB> is included in top line now - indicate <tab> is used to toggle groups.
| |
|
| |
| 11) DONE R4.3 - order is now RAM ROM OS (SYS) (SYS is a superuser feature) - change group display order to avoid tabbing past OS type.
| |
|
| |
|
| |
|
| |
| == Enhancement Requests ==
| |
|
| |
| <table border="1">
| |
| <tr><td>Status</td><td>Description</td><td>Requester / Date</td></tr>
| |
| <tr><td>Unknown</td><td>Support for so called Paired Switching, where a RAM image is swapped and an OPTROM image is switched in the same step. </td><td>[[User:Sadolph|Sadolph]] 05:17, 15 August 2009 (PDT)</td></tr>
| |
| <tr><td>Unknown</td><td>Support import of file from frozen RAM image to the thawed RAM image. RAM images can be used in a way similar to subdirectories. Therefore it is useful to be able to retrieve files from frozen RAM images</td><td>[[User:Jhoger|Jhoger]] 08:16, 16 April 2009 (PDT)</td></tr>
| |
| <tr><td>Done R4.3</td><td>Suggestion: make the TAB order OptROM, RAM image, Main ROM since Main ROM switch will be significantly less used. (order is now RAM ROM OS SYS)</td><td>[[User:Jhoger|Jhoger]] 19:54, 18 April 2009 (PDT)</td></tr>
| |
| <tr><td>Done R4.3</td><td>Add a visual progress indicator for flash functions.</td><td>[[User:Sadolph|Sadolph]] 04:36, 19 April 2009 (PDT)</td></tr>
| |
| <tr><td>unknown</td><td>Support for TPDD-2, for drive 1: (0: is supported).</td><td>[[User:Sadolph|Sadolph]] 04:36, 19 April 2009 (PDT)</td></tr>
| |
| </table>
| |
|
| |
|
| |
| nb: to put a username+datestamp just type 4 tildes <nowiki>~~~~</nowiki>
| |
