Mercury ME-DPF24MG

From ST2205u wiki


A device very similar to the Technaxx Magno, found at a Zellers store in Toronto for $15. A (nearly dead) product link can be found here. It is a 2.4" screen and appears to be a 240x320 display like the Magno. The plastics also seem to be identical, but the firmware appears to be different in some ways.

Mine came with a driver CD, which they apparently forgot to burn (It shows as a blank CD-R!), so I can't do anything involving looking at how it worked in Windows.

UPDATE: I managed to track down the software for my frame through a support page I found via google.


Overall:         Not yet working, mostly blocked on investigating the LCD at this point
Firmware Dumped: DONE
Spec file:       DONE (untested, but every address in newhack.txt was found)
LCD controller:  is unknown, and being looked into (doesn't look like either existing supported LCD)
Hack built:       not yet...
Firmware Written: not yet...


  • The board is marked: ZXDP-JINQIAO v1.0 2007-11-8 on the same side as the LCD, which appears to be glued to the top part of the PCB.
  • The LCD is marked: HC240-04A (can't find any marking indicating manufacturer, or see the LCD controller).
  • On the bottom side, there is the "blob" under which the st2205 lives
  • Also on the bottom side, is a flash chip marked: EON EN29LV320AB-70TCP
  • The rest appears to be mostly passive SMDs

The story so far

  • Using the patches/processes described on the Technaxx Magno page, I've managed to dump the firmware, and see "phack -m" work.
  • I've started to cobble together the spec/profile for the device. Most of the specs match the Technaxx Magno line for line.
    • The only real possible difference, is I found I could put EMPTY_AT at $3258, I'm also seeing it empty all the way to 7FD8, suggesting from the free space comment in that spec, that there's nearly 3K more headroom, and this may be a markedly different firmware.
  • Looking into the display controller... this might be the main difference as compared to the Technaxx Magno. This disassembly doesn't match EITHER of the suggestions in the newhack.txt file regarding setting CTRTYPE. While it's writing similarly to the PCF8833 in that it is loading things alternately into $8000 and $C000, it is never using $2A or $2B.
  • I've done a fair bit of work at annotating routines from seg0, tracing the path from the reset vector, trying to understand what's going on. This went well to a point, but I've not had time to track down or get answers on the trickier bits.

Where things are stuck...

  • in looking at the firmware, things are looking... odd
    • There are jumps into the system memory area and what's there is a mystery, common addresses seen:
      • $0108 - yes, i would assume this means jumping into a stack for reasons i may rather not know
      • $0580 - this one's fun, it appears to be DMAed from somewhere, then jumped to, after manually pushing what looks to be the return address would the jmp have been a jsr to the stack... (don't yet know where this is DMAed *from*)
      • $0820 - rather common
      • various points from $780 through $080C
  • due to above point, it's stalled the analysis of the disassembly, resulting in every tangible location being an unknown.
    • I see what looks to be communication with external hardware, but it's not obvious what
  • all of this is to support the main unknowns warranting all the above analysis:
    • what LCD is in use, and where are some of the LCD routines?
  • another point frustrating analysis is, i'm not clear on how/when the 16k segments are swapped out. (i assume it's via one of the bios or system area jumps, as I assume changing the program bank while running it is a bad thing. ;)

Logs and such

dmesg output

[477938.347030] usb 6-1: new full speed USB device using uhci_hcd and address 7
[477938.512216] usb 6-1: New USB device found, idVendor=1403, idProduct=0001
[477938.512223] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[477938.512228] usb 6-1: Product: Flash Disk      
[477938.512232] usb 6-1: Manufacturer: USB     
[477938.518206] scsi17 : usb-storage 6-1:1.0
[477939.522341] scsi 17:0:0:0: Direct-Access     SITRONIX MULTIMEDIA       0.09 PQ: 0 ANSI: 0 CCS
[477939.522958] sd 17:0:0:0: Attached scsi generic sg4 type 0
[477939.531878] sd 17:0:0:0: [sdd] 4096 512-byte logical blocks: (2.09 MB/2.00 MiB)
[477939.534321] sd 17:0:0:0: [sdd] Write Protect is off
[477939.534327] sd 17:0:0:0: [sdd] Mode Sense: 0b 00 00 08
[477939.534332] sd 17:0:0:0: [sdd] Assuming drive cache: write through
[477939.547300] sd 17:0:0:0: [sdd] Assuming drive cache: write through
[477939.547308]  sdd: unknown partition table
[477939.575316] sd 17:0:0:0: [sdd] Assuming drive cache: write through
[477939.575322] sd 17:0:0:0: [sdd] Attached SCSI removable disk

USB Tracing

I have taken a USBIO debug trace from the Windows software running in VMWare, deleting what I already had on it, and loading a whole new set of pictures. I'm hoping it helps me figure out what makes it's "write" operation tick, as I don't want to brick the frame without checking. This frame has several differences from the 128x128 frames, so I suspect the usual process might need some adjusting...

Visualizing the trace can be done via VMWare's tool, which seems to work up to a point, has a nice timeline but is like using wireshark without the deep inspection views when looking at the data. It was their guide used to configure VMWare for creating the dump.

I had an odd experience when doing this trace, in that the device seemed at first to want to come up in the VM as something other than the "SITRONIX MULTIMEDIA" label. Windows showed something like "A_Y Flash Disk" or the like. And once i traced it took me 2-3 tries to get it to connect as "SITRONIX". This is the first 2-3 minutes of my trace, and it might be interesting to know HOW that happened?

Then it loads a (large) number of images off the frame, a gap of idle, and writing a bunch of pictures back to the frame (67, the most the software allowed)

External Links