Talk:Phackv1.5

From ST2205u wiki

Jump to: navigation, search

I like the 'own OS' idea, and would love to help, however my assembler is fairly rusty. If it could be implemented in C (and we chose a particular compiler) then I can see myself contributing something. I'm not sure if it's feasible to write code in C for this device. Also, I suppose there is a high chance of bricking devices while writing it, meaning not just a shit load of work, but potentially expensive :). --Bifferos 17:27, 25 January 2008 (CET)

  • Not if we retain a way to get into the normal OS. We could, for example, patch the reset vector of the firmware to see if a certain button is pressed. If so, jump to the old firmware, if not, go to the new one. We could also implement a hardware way, which would be even more bricking-resistant. -Sprite tm

I also like the 'own OS' idea. I'm no assembler expert, but I feel like if I stare at something long enough I can generally make sense of it, and am willing to help where I'm able. Sitronix says on their website that they have some library code for the ST2205U for the USB routines and such. I actually think that if we could get those from them, the rest would fall into place fairly easily. Writing to the display is already pretty dead-simple. --Pete

The OS comments got me thinking about old 6502 computer(Apple II, KIM, OSI Superboard etc.). They didn't use OSes. They used single tasking BASIC. I think this is the way to go. People can write and customize, and different screen resolutions etc. can be accommodated, and folks won't (shouldn't) brick it. Single tasking or not, USB and a battery charging must be considered. USB will live happily hung off its own interrupts. There seem to be 4 hardware timers, so presumably the battery charger can live on one, or if it is just a display for a host computer, get it juice from USB. - Mirth

I would love to see a custom firmware for these kind of devices, because I believe they could also be good prototyping platform. Ok, well, I see this fro the perspective of an interaction designer. I would be willing to invest some time into this. --allesblinkt

Pete: Any thoughts on the compiler? cc65 is the only one I know of at the moment and that is supposedly not up to much --Bifferos 19:09, 25 January 2008 (CET)

  • The 65C02 doesn't really stem from the age where C-compilers were the thing to design against... we can always look at some C-compilers, but we probably end up coding stuff in assembly. Not that 65C02 assembly is that hard, I know almost a dozen processors which are much less intuitive :) --Sprite tm
  • I guess that all depends on how much of it one is writing. I've mucked about with very simple 6502 on my BBC micro, but it was usually inter-mixed with far more BBC basic. If the PIC, AVR and Z8 micro-controllers all have C compilers, then the ability to create C 'solutions' using a cheap photo frame is going to make a lot of people interested in the project. For just a few euros more than the cost of a micro-controller you have a micro-controller with a display *and* USB interface. There isn't too much IO, but an i2c master on two of the buttons combined with a port expander would soon sort that out. C is easy not just because you can type it in faster but because you can often lift code from other projects. Some of the routines will have to be assembler for speed, but a colleague of mine always told me to remember the first and second rules of optimisation: 1st rule: Don't optimise. 2nd rule: Don't optimise *yet*! --Bifferos 02:07, 26 January 2008 (CET)
  • I'd be willing to lend a hand. Haven't had any experience writing/porting OSes yet, but I've got a bit of embedded software development experience -- so I should be able to tackle some tasks. -- Syaik

How bout a small firmware change to the default options. Switch the USB Charging and USB Upload options on the main screen, and if within 5~10 seconds, an option is not choosen, default to usb upload mode.

It also seems relatively easy to jump to add some code to the firmware's start-up code, so that it jumps to an alternate code bank (from flash) when one of the buttons is pressed. This would save you the effort of clearing the control page to clean settings, and initializing other peripheral stuff. I do have a more-or-less complete overview of what initialization code is needed to get the tomtec to boot, and I will probably try to pull-of a 'tiny-os' type of thing. However, I think it's much more useful to have a good library with support functions than it is to write a generic OS. Especially with the amount of ram available --Jorik

  • I have to agree with this. From the usability POV the things I am most missing (apart from ebuyer compatibility) are:
    • Ability to go into 'upgrade' mode automatically (without pressing any buttons)
    • Ability to put the device into 'text' mode and overcome the 10 char limit for displayed messages: 3x5 font would be good so you can fit the maximum number of characters on the screen, or it could be made an option --Bifferos 17:11, 29 January 2008 (CET)


By lack of a better place for it, I'm posting a link here to a two-line patch for crasm that fixed the stupid CPX/CPY mix up, CrasmPatch. --Jorik

Anyone familiar enough with Mac OS X Leopard to make this work? The main problem seems to be that the device doesn't show in the /dev/ directory (I think this is due to the keychain not playing nicely as a true mass storage device). I started looking into doing the USB transfers with libusb, but quickly got in over my head. If one could simply get the device to show up as a mass storage device, compiling the source is trivial. In fact I already have it modified to build.

  • I know nothing about MacOS X, but since nobody else answered I'll bite. It's quite possible that the USB mass storage driver has either blacklisted your device or you need to explicitly add support for it, probably using the device and manufacturer ID in a config file somewhere. This is how it works under Windows. On XP if you look in c:\windows\inf\usbstor.inf you find a list of manufacturer and product IDs. This affects whether or not the usb mass storage driver will 'claim' your device. It used to be like that with Linux, but from what I pick up that changed at some point, and Linux is now more likely to go by the class code obtained from enumerating the device on the bus. libusb is probably *not* the way to go for the current phack release, because you will have to implement the mass storage protocol in your libusb code, and you have to *ensure* that mass storage does not claim your device. OTOH, future versions of hacked firmware may do away with the mass storage device altogether, in which case we could communicate with the device using smaller packet sizes. Not sure if there'd by much of a perf. improvement, but it might allow the bus to be shared with other devices more easily.
    • I looked into this further, and the device is recognized on the previous version of OS X. It looks like Leopard broke something with USB mass storage, and some google searching seems to verify this. So, if Apple will just fix this on Leopard, I should be able to make this work with very little effort, as confirmed on my older installation.
      • How about you pack it up for Tiger in the mean while?--cde 17:02, 8 February 2008 (CET)
        • Could you post a howto on compiling for osx? or built binaries? it would be appreciated

Is there any way we could get this to work under Windows? I would love to use this on my XP machine!

  • I have been looking into this. The biggest problem is finding the device name in the windows object hierarchy - nothing like as simple as Linux, however if you use the Windows DD program which can be found at http://www.chrysocome.net/dd with the --list option it will list all devices and give their block sizes. The DPF device will be one of the 512-byte block-size devices. Once you have the device in the form \\?\Device\SomeName, you can open it from your favourite language as \\.\GLOBALROOT\Device\SomeName. It would not be hard to adapt the class found in my Python script in the Phack 1.4 discussion to find this path, in fact I don't believe it's required to do page-aligned direct reads/writes from/to devices on Windows meaning that from this point on the code becomes simpler. So then the only difficulty comes from graphics library support. My solution to that is to port setpic to Python and use PIL (Python Imaging Library), but I'm not sure how popular that will be with other developers (not everyone knows/likes Python). --Bifferos 17:02, 5 February 2008 (CET)

Here is a working windows version of setpic: http://sitronix-dpf.svn.sourceforge.net/viewvc/sitronix-dpf/trunk/windows/. Runs on Linux and Windows now (Tested on Windows XP SP2). See script header for requirements. You still need to actually update the firmware on Linux though. --Bifferos 02:20, 7 February 2008 (CET)

bgrep, splice and phack are now ported to Windows (mingw), so in theory with the help of cygwin you could run the hack script. This is not well tested, since I don't have a properly supported model, however phack -m does at least work. If you want binaries, please PM me. Patch is here: http://sitronix-dpf.svn.sourceforge.net/viewvc/sitronix-dpf/trunk/windows/mingw_msys_compilation.patch?revision=16&view=markup --Bifferos 02:19, 10 February 2008 (CET)

  • This has been folded into Subversion --Bifferos 12:22, 3 March 2008 (CET)

Hi, Bifferos here. I've bricked my ebuyer photo frame and now got hold of a completely different one (http://linux-adm5120.sourceforge.net/lpc2103/). I'm therefore finding I have less interest in the 8-bit devices. With the recent creation of a Google code project by Jorik it might be worth considering where we want to store the various fixes that already went into Phack. I'd hate there to be a stale sourceforge project confusing people. What I would like to know, is if we should delete the sourceforge project, perhaps move the code to the google site, or if we want to leave things as they are and simply find a new maintainer for the sourceforge project. So please voice your opinions either way. thanks.
What about the yahoo group ?--cde

i have made a c# project for hacked devices. if anyone interested, contact me.

Retrieved from "http://picframe.spritesserver.nl/wiki/index.php/Talk:Phackv1.5"
Personal tools