Rockbox Development > New Ports

The Zune -- has the day finally arrived?

<< < (2/3) > >>

gigawatts:
The "sample" application that comes with the ZDK is coded to use the ZuneHD's tegra graphics chip, which the 1st and 2nd generation zunes lack.

I too would love to see a bootloader and rockbox ported to the Zune.  I have a Zune 80, and would be very happy if it were able to play more file formats (.flac, .ogg, etc).

How feasible is such a bootloader?

saratoga:

--- Quote from: gigawatts on April 21, 2010, 04:53:04 PM ---How feasible is such a bootloader?

--- End quote ---

I'm sure when someone figures that out they'll find time to post it here.

M_Koga:
Looks like the breadcrumb trail is starting to fall into line...

http://zunedevwiki.org/wiki/documentation/apis/start

http://zunedevwiki.org/wiki/documentation/apis/zdkcontent/start

If I was a bit younger, and a bit healthier, I'd be having visions of writing a Zune shell dancing in my head.

From what I can see on those pages, once those "crumbs" are fleshed out a bit, I'd think it ought to be possible to write wrapper code for the stuff necessary to access files on the Zune WITHOUT using zune.exe on the PC.

While "true" USB access may not be do-able at this point, I'd consider an application that served as a shell, exposing enough of the file system (to enable copying and deleting) to be a MAJOR victory, and something that would make the Zune VERY appealing to a lot of people who would otherwise never consider it (like me, for example, having bought into it before I realized exactly how solidly walled-in it was).

Once that happens, I think it may create enough of a critical mass of deeply clued (and younger, healthier, energetic) developers who will be able to make the NEXT leap -- getting Rockbox onto this sucker.

At that point, the Zune will be one formidable mofo.

(I still can't wrap my mind around the groupthink in Redmond that so intensely dedicates itself to doing all that it can to ensure that a very nice piece of hardware is virtually non-marketable, due to it being crippled by insane nannyware.)

saratoga:

--- Quote from: M_Koga on April 26, 2010, 01:23:53 PM ---Looks like the breadcrumb trail is starting to fall into line...

http://zunedevwiki.org/wiki/documentation/apis/start

http://zunedevwiki.org/wiki/documentation/apis/zdkcontent/start

If I was a bit younger, and a bit healthier, I'd be having visions of writing a Zune shell dancing in my head.

From what I can see on those pages, once those "crumbs" are fleshed out a bit, I'd think it ought to be possible to write wrapper code for the stuff necessary to access files on the Zune WITHOUT using zune.exe on the PC.

While "true" USB access may not be do-able at this point, I'd consider an application that served as a shell, exposing enough of the file system (to enable copying and deleting) to be a MAJOR victory, and something that would make the Zune VERY appealing to a lot of people who would otherwise never consider it (like me, for example, having bought into it before I realized exactly how solidly walled-in it was).


--- End quote ---

Keep in mind, we do replacement firmware, not application development (at least not yet), so things like APIs for the Zune firmware aren't useful to us.  We don't need or want to do USB access in the Zune firmware, nor do we  care much about the stuff linked on that wiki page since they won't be usable in rockbox.  With that in mind, please try to limit discussion in this thread to things that are helpful to rockbox development, such as how to get a bootloader running on the Zune.

zivan56:
I did some testing with Visual Studio and the SDK.  The API provided by the OS is very basic, and appears incapable of displaying forms or a console application.  So the only way to get feedback back onto the screen is via a messagebox (which is permanently covered by a loading animation) or by using the ZDK API for drawing/rendering (no font API was provided).  The screen API can clear the screen of the animation, but doesn't allow the messagebox dialog to come to the front.

The device itself resets whenever the application exits or when it detects something is "wrong."  I tried loading HaRET, and that either generated a rare error message or rebooted (it appears to be a random result).  Likewise, I tried to load signed Gigabeat S binaries, all of which caused a reset.

I have no experience in Windows development, so I can't do much.   If somebody knows the Windows API, they could perhaps explore the device using the MessageBox API to get feedback from the device.  Likewise, the ZDK API provides for the controls on the device, none of which work on the dialog.  So something could most likely be developed to explore the ROM/RAM (if readable at all on WinCE) or even load the kernel directly.

These are my observations after a couple of hours of testing.  Should save others some time in terms of figuring out why the device reboots when even a basic application is sent to it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page