... if an Empeg owner wants to upgrade in the future!!

It seems that Fujitsu has developed the first 2.5" Serial ATA harddisk !

Well, as long as they keep producing the IDE versions too, we should be fine...

Don't look at me - I just upgraded less than a year ago! Tempting, though...

Seriously, the main bottleneck is the IDE bus speed in the empeg. Even if you could find some way to convert the adapter type, you will not see any benefit from the speed. And we are already starting to hit danger points with the size of the hard drive and available memory in the empeg...

I remember a thread regarding the possibility to increase the amount of ram memory in an empeg. Not an easy task, I remember, but if that could be done physically somehow (no clue if it it possible theoretically), then probably a software update would not be totally impossible now that through Karma the code is still being developed to a certain extent...

physically somehow (no clue if it it possible theoretically

I really, really hope that it could be done in theory before in all practicality. (Unless you work for my company, which is selling systems for $30k to house nothing more than 50 million phone numbers..) Sheesh.

Me.

I really, really hope that it could be done in theory before in all practicality.

Ah, if only the marketing people could understand this . . .

Sorry guys, my English is sometimes theoretically and practically awful

Adding RAM yourself is something definately not fun if Patrick said it would be difficult to do!

The relevant thread post are here and here.

Basically on a Mk1 it's quite easy as the IC positions are already there on the bottom, just unfilled. The Mk2 is going to be very difficult as you're reaching the limits of the layout and design. The Mk2A however is technically possible but you'd have to stick the extra RAM on top of the existing chips and then wire in the chip select lines directly to the SA.

Another point was that the protected bootloader does the initialisation of the extra RAM. You can't change the bootloader without opening up the player and shorting the write protection points. I think Mark Lord has mentioned in the past that he would probably be able to change the kernel to do the initialisation for the extra RAM but I can't find the post at the moment.

Thanks Trevor. Interesting threads. Well, definitely not an easy task, maybe in Mark 3....

On that note, have you guys ever found yourself thinking of what you would really like to see in the Mark 3, if it ever ended up being produced?

- Gb Ethernet interface
- WiFi 802.11g
- USB2
- FireWire
- Color LCD Display
- Integrated Radio
- >160Gb HDD (This can be actually achieved easily in few months with current Mark 2, but I was just trying to make this list appealing for Paul too... ).
- Coffee machine.

Ok. I'll stop.

Why, the SATA just means that our large IDE HDDs will be available cheaper

Has really anything been said about a possible development of a Mark 3 at all?

I know anything is possible but, are the any signs in that direction? I just might have missed something, and since I am willing to get an empeg player (I haven't got one jet and I am new here) it would be nice to know if I have to wait a little bit more, or just for ever

Uf, that list of funtionalities is real good. I had a dream.... too!

[Lurch]

...you rang...

[/Lurch]

I hate to say it, but one feature I would want in a Mark 3 would be greater ease for integrating it into existing car stereo systems. Cars today are so unfriendly to third party stereo upgrades that you basically have to rip apart the entire dash(sometimes more) to install the system you want.

Personally, I don't think a mark 3 is the way to go, but better integration with stock HU's is. How about something like the Karma with more gigs (Presumably more gigs in less space is only a matter of time), home and car sleds, the latter with a sophisticated interface with a dashboard display, controls and battery charger: Best of three worlds, home, car and portable.
Ah Well, one can dream!

Yes, something like that would work well in my view. A simple extra display is better than an entire din slot, in these days. I can't imagine how integrated that would be with the factory system, though. I can imagine a separate system which is however easier to install since it does not require a standard din slot... Which is probably better: I may be underestimating this integration aspect, but when I think of integration to factory systems I think of many limitations on the display info available, commands available, etc. ONe think I always liked of the empeg is the player software itself. I would not want to lose something like that, honestly...

Last year in Amersfoort, adding more RAM was discussed as a what-if conversation. With the use of Alpha5, does the player software issue with the use of the additional RAM go away?

If so, anyone with steady enough hands want to try the add-on at this year's meet?

The bootloader isn't changed by upgrades. It's in the bit of the flash that is read only.

I think there were two issues:

(1) bootloader won't "enable" the ram -- fixable in the (Hijack) kernel.

(2) player s/w may not use the extra space (dunno) due to internal assumptions or whatever -- gotta try it and see, I suppose.

-ml

As I understand things, there a 3 issues to solve

1-Physically install the RAM via some soldering magic

2-Flash the boot loader or as Mark suggest solve it in Hijack

3-Make the player software use the extra RAM

AFAIK, the Karma has 32 MB of RAM. V3 software is a branched from the Karma software. So is #3 now solved for the Empeg? Or is there other software that this issue affects?

Karma's have 16MB of RAM...

So is #3 now solved for the Empeg?

Not as far as I know. That particular bit of code isn't (IIRC) shared between the two codebases.

Okay wrong again. I'm still would like to get someone to try to add the RAM. I figure the software issues won't get resolved unless a test is made to install additional RAM. Hugo, Patrick, Rob S, Stu? Any interest in trying this?

I know that RobS was working on adding the extra chips to his Mk1 at one point, but I never did get to adding code to "enable" them in Hijack yet.

cheers

Any idea what the reason was? Or rather a question to which I could understand the answer, would the lack of code share cause #1 and #2 to be a lost cause if done?

I vaguely recall him discussing this at Amersfoort. How's the finger feeling these days? Care to do a little "enabling" if someone is agrees to play hummingbird with a soldering iron.

I might give it a go. I wonder if it would be easier to make up a little daughter board for the extra ram..

-ml

What of Karma's has 16mb of RAM?

I d'o'n't k'n'o'w. I hear his wheel breaks sometimes tho...

Cool! Stu may have some ideas on the daughter board. I'll wait to see who weighs in on the topic.

I forsee a point where I'll need to do something different when I swap in another 80gb. Syncs are becoming a real drag with continual database rebuilds. I think some of my problems may be associated with how I'm tagging but I'm reluctant to re-edit tags and resync again. Is there a way to check how much memory my tags are using up?

Thanks-A

Hmmm. a daughter board, well it would certainly require some support circuitry I would think. I doubt if the lines to the memory chips would be able to drive the cable leading to the daughter board without some kind of buffer arrangement at a minimum. Maybe I'm all wet, but I say stick with direct soldering.

Stu

Hmm... Random thought...

We have seen folks rig up an IDE -> CF interface. Would it be possible / practical to have a CF memory card installed and use it as swap space, configuring the swap to load as part of the boot cycle?

Granted, I would not be willing to sacrifice an IDE drive...

Flash memory has limited erase cycles so you'll wear it out quite quickly if you're using it as swap.