#249507 - 21/02/2005 13:05
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Oh, actually..
Does anyone out there have a binary for ltrace that will run on the empeg? This would save a LOT of time, and pretty much solve the problem in one step.
Cheers
|
|
Top
|
|
|
|
|
#249508 - 21/02/2005 13:08
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
Okay, good. I suppose it occurs in two places: one where the data is written, and another in the code that reads the dynamic data.
No, one place, where a class called Blockfile is set up that has both read and write methods. If you search for the two consecutive words 0x00001000 0x00007000 and patch the second one, you have solved the problem (well, if if in the kernel you then frob read/writes to the partition so that ones beyond the end read/write somewhere else). No stracing required.
Peter
|
|
Top
|
|
|
|
|
#249509 - 21/02/2005 13:14
Re: memory boards nearing actuality
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Oh, well that's pretty trivial, isn't it!
In v3a8 that sequence occurs exactly once, at offset 0x017b95a.
Cheers
|
|
Top
|
|
|
|
|
#249510 - 21/02/2005 13:17
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
I imagine we could just replace the 7000 part with ffff, and leave it at that.. the kernel won't allow it to write out of bounds within the partition (I wrote that code), so then it's just a question of what the player will do when a read/write fails.
If it just takes it in stride, then we're done. If not, I can have hijack return good status (and zeros for data on reads) for out-of-bounds accesses to the dynamic data from the player binary (only).
EDIT: the idea here being that we'd like the player to just use the space available, and in the future we may have a replacement partition scheme that simply allocates a larger dynamic data partition. Some people can do that themselves now, even.
Cheers
Edited by mlord (21/02/2005 13:23)
|
|
Top
|
|
|
|
|
#249511 - 21/02/2005 13:27
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
|
Quote:
Some people can do that themselves now, even.
True! But I must admit that I dread the thought of rebuilding the music partition again. Still, it would be worth it for the future! 
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs
|
|
Top
|
|
|
|
|
#249512 - 21/02/2005 13:29
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
in the future we may have a replacement partition scheme that simply allocates a larger dynamic data partition
Most people with more than 0x7000 FIDs have two drives, which means the dynamic data partition's counterpart on the second drive is entirely unused...
Edit: And moreover, it's just occurred to me that most people with more than 0x7000 FIDs have big drives, so that the bit of fdisk code that allocated the dynamic data partitions as 16Mbytes rounded up to the nearest cylinder may already have allocated a significantly larger space. On one 30Gb drive I've got here, the cylinder size is 16,065 sectors, so a 16Mbyte partition would be three cylinders, or 48,195 sectors, or enough for FIDs up to 0xAC43 without any repartitioning or Hijack work except patching the player binary.
Peter
|
|
Top
|
|
|
|
|
#249513 - 21/02/2005 13:34
Re: memory boards nearing actuality
[Re: peter]
|
carpal tunnel
Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
|
I was wondering about that. Could that be tapped into?
I would think it would be a lot easier just to have a larger initial partition (if possible). Given the significantly larger hard drives out there today (compared with the original 6GB drives of the Mark 1), the extra partition space is not really going to hurt capacity much.
But going to the second drive (if available) would prevent people from having to rebuild partition tables and starting over.
Hmmm... Tradeoffs either way...
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs
|
|
Top
|
|
|
|
|
#249514 - 21/02/2005 15:42
Re: memory boards nearing actuality
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Mmm.. I think it might be overly complex (and therefore error-prone) to try and remap accesses to a second drive -- we're talking raw disk access here, and the player has only open()ed one partition for I/O. I don't think I want to try and trick it over to another disk.
But your point about partition overspill is a good one. That's free space that has zero risk associated with it.
Paul: show us your /proc/partitions data from one of your players, please
(you can grab it with either ftp or web access to your player).
Peter, how do you think the player s/w might respond to an error accessing the dynamic data? Will it just ignore it on writes, and use default (zeros?) data on reads, or will it get really peeved?
If it just takes it all in stride, then a simple binary player patch to 0xffff will work for everybody, rather than having to actually calculate the sectors available and using that value for a patch. Mind you, writing a quick app (in hijack even) to do the latter is not a really big deal for at least 20 people on this BBS.
Cheers
|
|
Top
|
|
|
|
|
#249515 - 21/02/2005 16:02
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
|
Greetings! See below. This drive was partitioned manually using Roger's updated guide. Code:
empeg:/# cat /proc/partitions
major minor #blocks name
3 0 97685784 hda
3 1 1 hda1
3 2 40162 hda2
3 3 24097 hda3
3 4 97578810 hda4
3 5 24034 hda5
3 6 16033 hda6
3 64 97685784 hdb
3 65 1 hdb1
3 66 40162 hdb2
3 67 24097 hdb3
3 68 97578810 hdb4
3 69 24034 hdb5
3 70 16033 hdb6
empeg:/#
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs
|
|
Top
|
|
|
|
|
#249516 - 21/02/2005 16:08
Re: memory boards nearing actuality
[Re: pgrzelak]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
3 3 24097 hda3
Bingo, your dynamic partition is 48,194 sectors long. A patched binary, and then 0xAC420 of FID goodness are all yours.
Peter
|
|
Top
|
|
|
|
|
#249517 - 21/02/2005 16:19
Re: memory boards nearing actuality
[Re: peter]
|
carpal tunnel
Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
|
<homer>Mmmmmm. Tasty FID goodness...</homer> Still, I wonder what happens at FID 0xAC430. This is a good sign! I also had the player console open (serial) while testing a track that was over the 0x6FFF boundary. No console error messages or warnings. The player app did increment the play count on the track data screen, but the data did not survive a reboot. Kind of expected.
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs
|
|
Top
|
|
|
|
|
#249518 - 21/02/2005 16:22
Re: memory boards nearing actuality
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
With player-2.01, one should find 0000 7000 at offset 0x00f4dde.
Change that to get instant higher fid capacity.
Peter, what should the new value be?
000A C420, or C420 000A ??
Cheers
|
|
Top
|
|
|
|
|
#249519 - 21/02/2005 16:23
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
And why does this all appear to be Big-Endian byte order? I though we were using little-endian mode in the Empeg?
Cheers
|
|
Top
|
|
|
|
|
#249520 - 21/02/2005 16:27
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
And why does this all appear to be Big-Endian byte order? I though we were using little-endian mode in the Empeg?
We are. Why is it all appearing in 16-bit quantities? You should be changing the 32-bit, word-aligned, quantity 0x00007000 to 0x0000AC42 (not 0x000AC420).
Peter
|
|
Top
|
|
|
|
|
#249521 - 21/02/2005 16:30
Re: memory boards nearing actuality
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
In v3a8 that sequence occurs exactly once, at offset 0x017b95a
That post was upthread a bit, but I've just realised that can't be the right address -- it's not word-aligned.
Peter
|
|
Top
|
|
|
|
|
#249522 - 21/02/2005 18:10
Re: memory boards nearing actuality
[Re: peter]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Quote:
If you were Pim or possibly Mark or some other devious person,
Well, being called a devious person on the same line as Mark is about the ultimate flattery 
Quote:
you could maybe think about shuffling FIDs about so that only playlists -- whose dynamic data isn't used -- are given FID numbers above 0x6FFF.
You're talking mp3tofid here. I must say, when handling such large amounts of data is when mp3tofid has its advantages:
- it is not bothered with 0x6FFF limits
- it creates a fidsifted directory structure by default
- it creates a player database that is ready to run
Reserving low fid numbers for tunes is doable, but there's hardly any benefit. One of mp3tofid's disadvantages is the lack of dynamic data feedback. Play count is unreliable and marking is useless even below 0x6FFF.
Pim
|
|
Top
|
|
|
|
|
#249523 - 21/02/2005 18:43
Re: memory boards nearing actuality
[Re: mlord]
|
member
Registered: 30/06/1999
Posts: 179
Loc: Switzerland
|
In Antwort auf:
Does anyone out there have a binary for ltrace that will run on the empeg? This would save a LOT of time, and pretty much solve the problem in one step.
You probably won't need it anymore. But in any case and maybe for further projects you can download ltrace from my server. It should run on a stock empeg player. http://www.empeg.homelinux.com/ltrace.zip
|
|
Top
|
|
|
|
|
#249524 - 21/02/2005 18:58
Re: memory boards nearing actuality
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
It may be word aligned once loaded into ram. The offsets within the ELF don't correspond to those within main memory, of course.
Cheers
|
|
Top
|
|
|
|
|
#249525 - 21/02/2005 21:54
Re: memory boards nearing actuality
[Re: pca]
|
carpal tunnel
Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
|
I'm shocked that you're not getting more replies here... This is HUGE. I'm going to email a few buddies and let them know. If someone is setting up shop in the US, I might have a handful of player to ship at once.
_________________________
Brad B.
|
|
Top
|
|
|
|
|
#249526 - 22/02/2005 10:37
Re: memory boards nearing actuality
[Re: SE_Sport_Driver]
|
carpal tunnel
Registered: 17/01/2002
Posts: 3996
Loc: Manchester UK
|
Quote:
I'm shocked that you're not getting more replies here
I think the price tag might have something to do with that. It's a heck of a lot of money for something that only a seemingly small group of people would benefit from.
_________________________
Cheers,
Andy M
|
|
Top
|
|
|
|
|
#249527 - 22/02/2005 19:32
Re: memory boards nearing actuality
[Re: SE_Sport_Driver]
|
enthusiast
Registered: 11/06/2003
Posts: 384
|
Quote:
I'm shocked that you're not getting more replies here...
Didn't realize that it would be "proper" to express interest at this point, especially given that PCA isn't asking for it, and we did that a while ago when the idea was first floated.
|
|
Top
|
|
|
|
#249529 - 24/02/2005 14:22
Re: memory boards nearing actuality
[Re: pca]
|
carpal tunnel
Registered: 25/06/1999
Posts: 2993
Loc: Wareham, Dorset, UK
|
I'll be installing these in Europe/UK for those wanting it, but after I have tried one out and assessed how difficult it will be. Rate/hr will be the same as for the tuner kits.
I must admit, it's a pretty neat looking bit of stuff. I'm impressed. I am trying to persuade Patrick to bring a bucketload with him to the empeg meet in July, so you should be able to buy one (or more) then at the meet. Please note that neither he nor I will be installing these at the meet (alcohol + fine mechanical assembly work + SMD based soldering = expensive disaster), but those of you wanting a buy + plus install should consider leaving your player with me at the event for a later install and test.
_________________________
One of the few remaining Mk1 owners...  #00015
|
|
Top
|
|
|
|
|
#249531 - 24/02/2005 15:36
Re: memory boards nearing actuality
[Re: JBjorgen]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
Mmm... soldering near food and plates!
|
|
Top
|
|
|
|
|
#249532 - 24/02/2005 16:01
Re: memory boards nearing actuality
[Re: tman]
|
carpal tunnel
Registered: 15/08/2000
Posts: 4859
Loc: New Jersey, USA
|
Well, where else would you see chips? You have potato chips, corn chips, memory chips...
_________________________
Paul Grzelak
200GB with 48MB RAM, Illuminated Buttons and Digital Outputs
|
|
Top
|
|
|
|
|
#249533 - 25/02/2005 05:58
Re: memory boards nearing actuality
[Re: pgrzelak]
|
carpal tunnel
Registered: 13/02/2002
Posts: 3212
Loc: Portland, OR
|
Quote:
Well, where else would you see chips? You have potato chips, corn chips, memory chips...
You keep going with those, and you'll have a chip to knock off my shoulder, too!
|
|
Top
|
|
|
|
|
#249534 - 25/02/2005 11:20
Re: memory boards nearing actuality
[Re: canuckInOR]
|
carpal tunnel
Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
|
He's a chip off the old block isn't he?
_________________________
Brad B.
|
|
Top
|
|
|
|
|
#249535 - 26/02/2005 03:29
Re: memory boards nearing actuality
[Re: SE_Sport_Driver]
|
carpal tunnel
Registered: 13/02/2002
Posts: 3212
Loc: Portland, OR
|
My apologies if I don't find that very amusing... I'm not feeling very chipper at the moment.
|
|
Top
|
|
|
|
|
#249536 - 02/03/2005 03:02
Re: memory boards nearing actuality
[Re: canuckInOR]
|
addict
Registered: 03/08/1999
Posts: 451
Loc: Canberra, Australia
|
You had to chip in with that comment, didn't you?
_________________________
Owner of Mark I empeg 00061, now better than ever - (Thanks, Rod!) - and Karma 3930000004550
|
|
Top
|
|
|
|
|
|
Previous Topic
Index