Hi.

Well, the PCBs for the 64MB memory boards are in manufacture at the moment. I will have a few in a couple of weeks, which will be built and tested, then assuming everything is OK a batch will be made immediately afterwards. The first run, which will probably be 35 (which the the number I have parts on hand for) should be available around the first week in april or thereabouts.

The cost will be £100 plus shipping, which will, as per the tuners, be £5 for the UK, £7 for europe, and £10 for the rest of the universe.

I intend this project to be self-funding, unlike the tuner kits which were, frankly, a money-pit. What this means is that I will make smallish batches, sell them out, and make more using the income from the previous lot. To this end, I will take firm orders rather than potential interest offers, and make a new batch when there are enough to make it viable. I would expect this will be anything upwards of 25 at a go.

The boards will be added to the website when they're available. I have been wondering whether I should accept orders via email from the BBS, but I'm not sure of the best way to do it. What would be ideal from my point of view is an order accompanied by payment, on the understanding that the boards would take up to about 6 weeks to ship from any particular moment (this gives time for the PCBs to be made and built, since I'm not doing it myself), but I can understand that people might not think this ideal from their point of view. Any suggestions or preferences?

The turnround time on these thing will be much better than the tuner kits, since the bill of materials is much simpler (8 ram chips, 16 capacitors, 4 resistors, a dip switch, and a PCB), and there is nothing on it that should present much availability problem. That said, things have a habit of proving me wrong on this sort of matter

IN addition to the above, there remains one slight problem. This upgrade requires some reasonably skilled and careful solder work to fit, and will be MUCH harder to remove than attach. The PCB is designed to fit over the test pads on the bottom of the MK2/2A motherboards, which are then soldered through the mating holes on the memory board. There are about 50 holes that need to be dealt with in this way. If a mistake is made, the unsoldering process would be annoyingly fiddly.

For a MK2A board, one patch wire (RA3) will need to be brought from the CPU to a pad on the memory expansion board to give the full 64MB, otherwise only 48MB will be available.

For a MK2, in addition to the patch wire the onboard ram will need to be disabled. This could be done either by lifting a pin on each ram chip and connecting it to +3.3V to disable the chip, or preferably by removing the chips completely. The latter method avoids capacitively loading the data and address busses excessively, which might possibly cause problems under some circumstances.

Now, while there are certainly quite a few members of this board who could do this work easily, I'm sure there are many more who would not feel too confident in their abilities on a job like this. Also, I'm equally sure there are some who would feel confident, but would be wrong

I'm not sure what the best method to deal with this is. I don't really have time to sit here fitting memory boards, unfortunately, as I need to attempt to earn some sort of living. I would think that various BBS members may well wish to offer their services, presumably for a fee, and I have no problem with this. However, obviously I can't offer a guarantee on the functionality of an empeg I haven't dealt with myself.

I would suggest that if people do offer a fitting service, it would make sense to ship only the motherboard rather than the complete unit, wherever possible, as the costs involved would be kept to a minimum.

Any questions or insults?

pca

I think it all sounds reasonable!

Now IIRC, these boards do not work with players with already upgraded memory (e.g. 32MB)?

Maybe Eutronix or other skilled members around the globe can do batch orders directly from you? That way, we'd at least save on shipping (instead of me paying for a board to be shipped to me, then I have to ship to Eutronix or whoever is offering the service in addidtion to return shipping.)

Oh yes. I forgot to include that as well... I don't mind paying in advance and waiting upwards of 6 months.

will the players be able to handle more fids after that memory-upgrade ?
i have just crossed that line where the database can't be built anymore...

I'm up for at least one, and I would be willing to pre-pay.
However, my life is crazy these days, and I'd really like to hear that someone is willing to do the fitting for me before I commit.
I can probably do the solder work, but I'd rather not.

How many tracks do you have? Do you have a Mk2 or a Mk2a?

its a mk2a, the highest fid i had on it when it stopped to work was 701f (that is, 701f0 and 701f1).
in the serial-output it would always say:
! playerdb.cpp : 182:Failed to build dynamic database (status=0xc004401a).

i think i really tried everything - reinstalling different player-software-versions (v1.03, v2.0 betas) and those fsck-procedures, but nothing did help.
there was no other way than deleting the last fids i added, after doing that it worked again.

From what I understand, it should fix the rebuild problem, but not the memory of a root playlist shuffle.

Have you run fidsift.sh on your player?

Also, I'm equally sure there are some who would feel confident, but would be wrong


Surely you're not referring to ME are you?



tanstaafl.

I am willing to offer my soldering/board fitting services. The fee will be devised based on the amount of effort required to fit the board.

i just tried fidsift.sh - no luck.
same problem as before, surprisingly just after crossing the 6fff-border...!

Oh, that's probably the empeg player software's upper limit.. 0x6fff.

Roger? Peter?

Ooops. Sorry - I wasn't paying attention.

I currently run my empeg with 0x86f2[01] as the highest FID. There are a few tricks to getting this to work happily:

step 1) Sync as normal, knowing that emplode will crash anyway. The files are copied up, and the FIDs and supporting information is built correctly. The player will attempt to build the databases, but will fail.

step 2) Drop to shell on the player. Set the filesystems to read/write. Run fidsift.sh. This will rebuild the directory structure and move the files around on the music partition(s).

step 3) Set the filesystems read/write again (fidsift.sh resets to read-only) and run the player application from the command line. It will rebuild the databases and save them to disk.

step 4) Set all filesystems to read-only, exit shell and reboot.

While this may be crude, I have been doing it successfully for quite some time now, and I have been pushing the FID count to insane levels. I was also doing this long before the memory upgrade as well. The only trick there was that I enabled swap, just in case. I do not enable swap anymore...

cool, that worked for me - thanks !

maybe this is a good hint for the FAQ..?

Greetings!

Cool! No worries.

Parts of it are in the FAQ, but I do not know if it references the high FID count issue. I am sure that the process could be cleaned up and streamlined a bit - I was kind of distracted when typing that out.

Basically, the player application is able to rebuild beyond that high FID point, but the sync procedure cannot. Emplode times out and crashes, while the player attempts to build the databases, but never saves them to disk. I am guessing that there is a test for the FID number being above a certain point or it is beyond the amount of memory allocated.

Either way, the practical aspect is that you can push the player further, but you have to be prepared to manually rebuild the databases. The fidsift.sh is actually optional - the databases will rebuild properly, but I like having the directory structure neat and it avoids any glitches.

So, the trick is:

a) sync normally, knowing it will crash.
b) let the player try to complete building, knowing it will not save the database
c) drop to shell
d) read/write the partitions
e) fidsift.sh for cleanliness
f) read/write the partitions
g) run player from command line
h) allow player to rebuild databases, this time it will save them
i) quit the player application (q or control-c)
j) set the filesystems to read only
k) exit and reboot

By the way, welcome to the wonderful wacky world of unexplored territory!!! I suspect that you may see some strangeness in the dynamic data associated with files that are "over the edge", but I have never experimented to prove it. You should not notice any trouble with general use of the player though.

One other random emplode glitch that most people do not see. If you try to sync a huge number of playlists, you will also crash emplode. Again, I suspect that it is based on the memory allocated as opposed to a specific check. I found this trying to rebuild a large-FID player from scratch. The number of playlists (the first items sync'ed) overwealmed emplode in rather amusing ways...

I wonder how pervasive the 0x6fff (or 0x7000) test is in the player software.. is it only in one place, near to the actual disk access code... ?

Cheers

I can practically see the wheels turning in Mark's head.

Do I sense some experiments approaching?

Greetings!

To be perfectly honest, I never tried it. I usually use Windows 2000 (now XP) to sync over USB. I never really bothered trying to get jemplode to work with that combination.

It might work, given that it seems to be more of an emplode issue than the player app. This is based on the player app being able to rebuild the database from command line, but not from (an aborted) sync.

Ah, good.

So, Peter.. care to save me some time poking and prodding.. I just need the approximate code offset from the beginning of the player binary.. I can indeed find it on my own, but what a waste of time if some kind soul could look it up in the map/source ..

Cheers

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.

I've a cat on my lap, and cannot move to reach for an appropriate player at the moment, but the general strategy here is to just run the player binary under strace, and observe when it reads/writes the fids area of the dynamic data partition. Based on what that tells me, I'll either just go fishing directly, or instrument the kernel to automatically catch it and dump a traceback.

Between those two methods, I'll have a very good approximation of where the read/write dynamic fid code is within the player's memory space, and from there can track it back to the executable. Once in the right area, it hopefully will just be a matter of looking backwards in the binary for the fated 0010 and 0070 values.

This may take a while until I actually get set up and do this, so others are more than welcome to have a go at it on their own. If/when I do it, I'll be targeting v3a8.

Cheers

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

Oh, well that's pretty trivial, isn't it!

In v3a8 that sequence occurs exactly once, at offset 0x017b95a.

Cheers

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

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...

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

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:/#

---

<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.

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

And why does this all appear to be Big-Endian byte order? I though we were using little-endian mode in the Empeg?

Cheers

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

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.

Agreed. Consider this my yippie/me too post.

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.

Mmm... soldering near food and plates!

Well, where else would you see chips? You have potato chips, corn chips, memory chips...

He's a chip off the old block isn't he?

My apologies if I don't find that very amusing... I'm not feeling very chipper at the moment.

You had to chip in with that comment, didn't you?

I know, it was kind of a chip (cheap) shot, but I didn't think I could count on someone else doing it for me.

I can't believe I started this...

I was starting to feel guilty about the string of puns, but I'd wager a couple poker tokens that it was just the chipotle in the burrito I had for dinner.

Or maybe it was the Tostitos.

Greetings!

I do not want this to be lost. Could someone with just a hex editor under windows be able to modify the correct point in the player binary to make this happen? And would the same offsets apply? I am running 2.01, and I did not see that pattern at the mentioned location.

Oh heck, I'll just write an empeg app to do it correctly for whatever unit it gets run on.

Hahahahahaha! I knew it was just a matter of time...