Sidebar
This is an old revision of the document!
Table of Contents
Firmware
Name of the file with firmware
The Unicard firmware is distributed in files “unicard.app”. If there is additional text after “unicard”, it marks the type of computer the firmware is intended for. Currently (as of sd_800_v5_fw023_man211_2021-05-23.zip), Unicard firmware is available for 4 types of SHARP computers:
| Computer type | Firmware Name |
|---|---|
| MZ700 EU (07/2018) | unicard700_eu.zip |
| MZ700 JP (07/2018) | unicard700_jp.zip |
| MZ800 v0.23 (05/2021) | unicard800.zip |
| MZ1500 v0.23 (05/2021) | unicard1500.zip |
When updating firmware it is necessary to work with extracted files unicard*.app.
Firmware Update
The firmware update is done by the Unicard without the need for a JTAG programmer. All you need is a SHARP computer with a Unicard and a prepared SD card. If the Unicard firmware has different parameters than the new firmware on the SD card, the bootloader will update the firmware automatically after turning on the computer.
Preparing the SD card
- format the SD card to file system FAT32
- choose correct firmware based on the computer type (unicard700_EU.app, unicard700_JP.app, unicard800.app, unicard1500.app)
- copy firmware to SD card's root
- rename firmware to unicard.app
Update
Insert the SD card into the SHARP computer and turn it on. If everything is OK, you will see information about the update's progress on the monitor. After it is finished, a standard booting of the computer will occur. File unicard.app can be left in the SD card's root. If the bootloader finds a match between the current firmware and the firmware on the SD card, it will not update.
Limitations of firmware update
There are two limitations for firmware update:
- the checksum of the firmware must match
- the parameters of the new firmware must be different from the parameters of the current Unicard's firmware
If needed, it is no problem to update an older version of the firmware over the newer one.
The structure of the firmware files
Every file containig Unicard firmware is composed of a header of 512byte and its own coded firmware.
Description of the header's structure
| Offset | Meaning | Contents | Length |
|---|---|---|---|
| 0 byte | identification signature | UNICARD_ | 8 byte |
| 9 byte | version | n | 1 byte |
| 10 byte | separator of version and subversion | . | 1 byte |
| 11 byte | subversion | nn | 2 byte |
| 13 byte | file size including header (unsigned long) | nn nn nn nn | 4 byte |
| 17 byte | checksum of the firmware file (unsigned long) | nn nn nn nn | 4 byte |
| 21 byte | CR LF | 0D0A | 2 byte |
| 23 byte | identification of computer MZ_ID - currently:
| MZ_ID | depends on the length of MZ_ID |
| 23 byte + length of MZ_ID | CR LF | 0D0A | 2 byte |
| 23 byte + length of MZ_ID + 2 byte | unused | free | what is left to 512 byte |
The reader may send a suggestion on using the free bytes in the firmware header. Current idea from Bohouš - which modification, who translated it; what did they have for lunch and what the weather was like, as well as a forecast for the following week. I suggested an ode to Bohouš, leaving some space for a few praising rhymes for Mikeš and Martin 
.
Firmware structure description
From the 513. byte (0x0200H), there is the Unicard firmware code itself. This code is encrypted, the firmware therefore cannot be dirrecty reviewed. As mentioned in the header's description, the file contains a checksum, which prevents any possibility of a damaged firmware being used to update. When updating, the check sum is compared and if it does not match with the checksum mentioned in the header, the update will not happen.
