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