From: alankorr <alankorr_at_subdimension.com>
Date: Fri, 11 Jan 2002 12:39:38 GMT

[Stuart]
1. The current behaviour of the jukebox's software sucks
when it halts music playback to perform certain tasks such
as reading a textfile or connecting to USB etc. Is there any
reason that (at least some of) these things cannot be
performed in parallel in our version of the software?

[I]
well, reading a textfile, why not... when connecting to USB,
never ! you will have conflicts between PC and SH1 transfers
so we need to block all SH1 transfers. By the way, when you
connect your PC you will surely add new MP3 songs or remove
or modify some, so we will need to reboot it to take account
of the new MP3 songs.

[Stuart]
2. Also, I take it that the memory is kept charged during a
poweroff to retain volume settings and song resume. If this
is the case, then this could easily be extended to playlist
resume after poweroff, and other annoying features.

[I]
No, it uses some reserved sectors in harddisk to retain
settings and song resume. Other extensions could be done of
course.

[Stuart]
These facilities could be improved further by storing state
to the harddisk
to survive battery removal. This would of course introduce a
slight user
education (i.e. don't wipe files under the XXX directory -
or perhaps just a
hidden root file) and could even be optional.

3. Archos themselves have two versions of the firmware - one
for each of the two jukebox models. Do they truly differ so
much? (I appreciate that footprint size can be an issue, but
that can be controlled during the build
process).

[I]
They really do. To have the same firmware for JBP/R will
double some part of the software and waste space for MP3
streams. It is silly to have code and static data we don't
need for one model.

[Stuart]
I'm aware that the LCD components differ between the models,
but apart from that and the obvious recording functions, are
they not more similar than dissimilar? Excuse my naivety
here, I'm sure I could learn Swedish before I could
understand a electronic schematic diagram and any
accompanying datasheets :) I guess footprint

[I]
schematics are really different. I saw a shematics for
MAS3507 (the one used by JBP) from other projects and found
it doesn't use the same pin to raise an exception for
example than MAS3587 (the one used by JBR) does. So i
suspect a lot of thing to be different to handle (especially
MAS3587 uses the pin /EOD for playing AND recording MP3
streams transfer between it and SH1).

[Stuart]
4. There was talk recently of being careful with the mods
created by the esteemed members of this community,
especially regarding frying one's harddisk or ide
controller. How serious are these concerns? I have only just
received my device and am loathe to risk any damage in the
name of scientific endeavour, open-source or not. Did anyone
attempt to recover a 'fried disk' with the (maxtor?)
low-level formatting tool recently posted? Any successes?

[I]
My advise would be : during development never transfering or
rebooting unless you plug in DCIN to be sure your harddisk
is not underpowered because of malfunctioning batteries
would be a requirement, but you have a more recent JBP/R so
maybe this issue is out of date. Normally when our software
is downloaded and doesn't use IDE, it would be safe to
unplug DCIN. Another point is to have a robust exception
table during development to avoid crashing with a random
execution.

/alan

 


_____________________________________________________________________
// free anonymous email || forums \\ subZINE || anonymous browsing
            subDIMENSION -- http://www.subdimension.com
Received on 2002-01-11