Hey old forum I'm surprised is still on the go

So my beater '03 GTI finally bit the dust, and I'm about to transplant my empeg out of it and into an '09 Honda Fit. Thankfully the Fit doesn't use the stock stereo to control half the car, and the car will take a DIN dash kit, so I can keep my museum-piece stereo going.

I haven't had the player apart in probably 10 years, other than reseating the IDE cable a couple of times. Knowing the spinning rust HD's inside are well over a decade old and running low on space, I figure maybe it's time to give the player a refresh.

To upgrade the storage, I'm thinking of using a 44 pin->SATA adapter plus either a spare 240gb SSD or 500gb HDD that I've got kicking around the house. Hopefully everything mechanically fits, I'm sure I can make it fit if it doesn't. Anyone using these adapters successfully and able to comment?

Also, I'm reading that the players struggle if you've got a lot of files on the player due to memory limitations. Looks like I can stack chips for 32MB (which looks easy enough to do) or buy a memory expander board for 64MB. I'll probably just install what I can get my hands on more easily - anyone happen to have some MK2A EDO chips or a memory expander board taking up space in their closet?

Thanks!

Do not use a SATA adapter, SATA drives will not work properly on the empeg even through an adapter. It must be an IDE PATA drive.

If you want to go with a solid state drive, your best bet is a CF adapter. CF cards are just like IDE PATA drives in terms of the pinouts and the way the firmware addresses them, so they will work best with the empeg. (Also don't go with SD either, it has other problems.)

I was happy with the following:

Adapter:
https://www.amazon.com/gp/product/B0036DDXUM/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

Card:
https://www.amazon.com/gp/product/B00NUB2TWI/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

A couple notes about that CF adapter:
- It doesn't have a master/slave jumper. Instead, you plug the CF card into the adapter's Slave Slot or the adapter's Master Slot to switch it back and forth.
- I don't trust the CF card's ability to stay in the slot with the empeg riding in a bumpy car. It's only held in by the friction of the pins themselves, there's no clamp mechanism. So I put a piece of strong tape across the top to keep it parked in the slot.

Regarding size: CF cards only get up to the range of about 128-512 or so, it's hard to find anything bigger. Your best bet is a single CF card of about 128gb or 256gb. Make sure it's not a "CFast" card because those aren't the same as CF/IDE/PATA either and will have the same problems that SATA or SD would.

Make sure to use Mark Lord's latest files for setting up the new drive.

Also do not attempt to upgrade the RAM of the empeg player, it is risky (it can brick your player) and it won't help any of the issues. At most, upgrade the drive to a solid state CF and call it good.

Most likely the rotary encoder is the thing that will give you the most trouble out of everything.

Hey, thanks for the info.

CF cards are rare and expensive for their size and I'd have to buy new ones, trying to avoid that. I noticed Mark Lord is successfully running a MSATA->PATA adapter in his current install. I'll try and figure out what chipset is in his and look for a "normal SATA" converter with the same chip.

I briefly looked at a PATA<->SD converter, but saw someone had no success with it, and the converter was overwriting the partition table of the SD card every time it was powered on... too sketchy for me.

I'm good at SMT soldering, I can confidently upgrade the RAM without breaking the player, but if it doesn't help the player software cope better with having lots of files on the thing then I won't bother.

And yeah, the rotary encoder sucks I don't use it, other than pushing it to shuffle/unshuffle playlists or using it to get into and navigate Hijack. I've got the Empeg sitting beside a standard headunit and fed into its CD changer input.

Suitable CF cards are NOT rare at all -- very commonly available (eg. Amazon). They are more expensive than some other options, but they are the ONLY media that is pretty much guaranteed to work in the empegs.

Roger (not me) did get lucky with an mSATA adapter though.

Cheers!

I have to point out that I've not tested it thoroughly, though...

Ok, I was going by your post here. Didn't work, eh?

https://empegbbs.com/ubbthreads.php/topics/361709/2013_Impreza_Wagon_install#Post361709

I'll see if I can find what Roger's using. Hey Roger, what adapter are you using?

And yeah, I withdraw the "rare" part of my statement about CF cards, but damn they're expensive per Gb - $117 for a 128gb card is more than this cheap bastard wants to spend. It's a shame the IDE<->SD adapters are so sketchy, because a 128gb Samsung MicroSD card is 18 bucks!

Interestingly, I can buy a 320gb WD PATA drive for about the same price as a 128gb CF card.

Heavens! I had no recollection of ever trying that! But I guess it did work. Wonder where that adapter is now? The mSATA drive is now in a SATA enclosure in one of the notebook computers here.

But in the 5-years since that was posted, CF Cards have gotten a lot bigger, quicker, and cheaper. And based on recent research/experiments by several of us here in 2019, CF-Cards are the recommended solution. The adapters for those are as cheap as US$2 (eBay).

Cheers

Found it: JM20330 bridge chip.
So.. perhaps any style SATA adapter with that exact chip might also work, including for full-size SATA SSDs ?

Cool, thanks for posting that!

The common cheap ones from 10 different manufacturers on Amazon all seem to use the same chip, same signals seem to come out the same sides of the chip and the parts surrounding the chip look roughly the same.

I'll nab one and see what happens.

Also, just to confirm: no point in upgrading the memory of a player, it won't do anything to help the player handle more songs?

I think more memory is good if it works -- I did upgrade three of my players to have more RAM, but since then have removed it from two of them (stability issues). It is very difficult to install so that everything still works reliably long-term.

The third player here, still has the full upgrade in it (a PCATS board, I forget what the total is but I think it has 32MB now).

Let us know how that works out. I suspect that these chips also have internal firmware, and compatibility may also depend upon the exact firmware version included.

Just ordered this one, I'll have it in a couple days:

https://www.amazon.ca/QNINE-Laptop-Adapter-Convert-Vertical/dp/B074KXB1GZ

SATA TX/RX lines match the JM20330 pinout. They've no doubt got an internal ROM in them that does everything, but at least it's internal to the chip so whoever assembles adapters can't mess it up.

Since you've upgraded a couple players + you're in Canada, any chance you've got a couple extra DRAM chips kicking around? I'll buy a couple off you if you do. Pretty confident I can do it and make it work reliably

Okay, I dug through some boxes here and found RAM chips compatible with the Mk2a. These can be stacked and used per the BBS thread on that subject: https://empegbbs.com/ubbthreads.php/topics/196380
https://empegbbs.com/ubbthreads.php/ubb/download/Number/3299/filename/214166-rita1.jpg

You'll need to wire the bank enable line and flash the updated e000 segment to enable the extra bank(s). I suppose I ought to include that flash segment in the bigdisk builder stuff.. but for now it ain't there. Hijack kernels >= v389 automatically detect/enable extra RAM banks.

You can have a pair of chips -- PM me with mailing info and I'll post them to you.

Cheers

Correction: the units I had trouble with were the ones with the PCATS memory expansion board. The one with one extra layer of stacked chips has been trouble-free.

Now that you've got me going on this again, I may as well stack chips on another of my Mk2a units. Heading for the soldering bench shortly.

Okay, that took a bit longer than expected, but still okay. I had one bad data pin, and ended up just redoing all of the pins on both chips AGAIN to cure it.

My mistake was starting out with the 0.1mm tip on the iron. Duh.. too small to hold solder or heat. So when I went around the pins again I had the 1/32" tip on instead. Worked beautifully! So now I have two players with 32MB RAM. Yay!


https://empegbbs.com/ubbthreads.php/topics/196298/5

Yeah, that was an inexcusable 136 minutes. In that amount of time I might have been able to figure out how to get the cover off the empeg.

tanstaafl.

Did you ever try these in your player? Keen to hear how successful this is..

Right now it + the empeg + the RAM that mlord sent me are all sitting in a box, because I'm moving houses.

Give me about a month and I'll have an answer

Also, the Honda Fit that I'm throwing this thing in eventually won't fit the stacked head unit + Empeg combo that I've run in the past few cars I've owned.

Might have to track down a tuner and amplifier and run the Empeg solo.

Update: RAM upgrade successful!

And the HD adapter doesn't work. Empeg won't see any drives. Won't work with a USB-to-44 pin adapter that I have, either. Drive spins up but no HD found in either case. Guess the little "QC control" sticker on the thing doesn't mean anything.

Since it'll be a while before it gets stuffed in a vehicle, I just bought a couple more of the things off Aliexpress.

The empeg will not work with a USB-to-44 pin adapter. The empeg will not work with a IDE-to-SATA adapter. Make sure to try getting the player working with the original Winchester IDE PATA drive that it came with first, before trying fancy stuff like drive adapters.

If you are using a proper IDE PATA drive, and the player can't see any drives, then look for the possibility that it has a problem with the IDE cable or the header as described here: http://www.riocar.org/FAQ/8/221.html#221

Once you have the player working with a regular drive, then, if you wish to update it to a solid state drive, it must be a IDE PATA drive of some kind, and your best bet at this time is to use a CF adapter. I have described and linked them in my first reply at the top of this thread, here: https://empegbbs.com/ubbthreads.php/topics/372225/Re:_Time_to_refurbish_my_MK2A.#Post372225

As Mark Lord taught us, the reason that a CF adapter works is because it is, at the low level, an IDE PATA interface. Things like USB adapters and SATA adapters will not work because they don't properly emulate and IDE PATA interface. (Note: There is a type of newer compact flash drive called "CFast" which also won't work because it, too, is not an IDE PATA device. The only kind of CF device that will work in the empeg is a regular CF card like the one I linked above.)

I also spent some time getting my empeg up and running again over Christmas, as it happens. I'd forgotten how much I love the interface and the crisp VFD display!

So far, I'm also one of the lucky few having no issues with a SATA SSD. I bought a cheap adapter over a year ago to convert an old uSATA laptop drive to 44 pin IDE, with the plan of using it in the empeg, just assuming it would work.

When I actually came on the forum about three weeks ago to remind myself how to install the player and Hijack, I saw all the issues with SATA drives, and figured it would be unlikely to work. I decided to go through the process of installation on the basis that it would give me some confidence that the empeg hardware was still working before buying a CF card, and to my surprise, everything worked flawlessly with the SATA SSD. It's now been through multiple reboots/power offs, has about 50GB of music loaded in multiple syncs, and continues to behave just as expected.

Possibilities that I can see:

- It's actually broken in some way and I just haven't noticed yet.
- The adapter I'm using is better than most. It is, out of sheer coincidence as I just picked a random one, using a JM20330 chip, the same as Mark found worked.
- The changes Mark made in Hijack v526 have indeed made more SSDs work.

Probably not much help, but just another data point to add to the set. A CF adapter is definitely still the safest bet if you just want the empeg to reliably work with a solid-state drive.

P.S. Mark's new Big Disk Builder image is amazing! I hadn't quite appreciated everything it was doing at the time, so I was very surprised to find Hijack and everything else just there and waiting when the process completed!

It's certainly possible that some of Mark's fixes solved the problems with an SSD. Or you have a really good adapter device!

Some of the IDE-SATA adapters out there do work, and others don't. And some of the mSATA-to-IDE adapters also work. Some SD-Card adapters also work, but not many it seems. Sometimes they work only for drives up to 32GB, sometimes for any size drive.

The old Kingspec PATA SSDs work very well, but the newer (since 2014 or so?) PATA SSDs are really native SATA with an IDE/SATA adapter built in, and those do not work.

CompactFlash cards currently have a 100% success rate, as Tony mentioned.

The JM20330 based adapter Mark showed above worked for him, which gave me some hope that the QNINE one I bought off Amazon (which also has a JM20330 on it) would work. The JM20330s have built-in firmware/microcode/whatever, there's no external chip holding firmware that the vendor making the PATA/SATA adapter can fuck up. Snoopstah's success post gives me more hope

I've got one of these old things: http://www.vantecusa.com/products_detail.php?p_id=52

Plugging one of the old Empeg drives into it, my desktop sees the drive OK, so PATA side of the adapter is fine. Two SATA drives I have (256gb SSD, 500mb HDD) work with the SATA side of the adapter. But neither of those drives, through the QNINE adapter and plugged into the PATA side of the adapter, work.

I stole a 40<->44 pin PATA adapter from the junk bin at work, I'll try it tonight in my desktop to see if the QNINE springs to life, but I'm pessimistic.

Greetings Old Ones!

Haven't been around here for many years, but came across a guy from my work who was super into his Rio 600 and it set me digging in my empeg boxes to see what I could throw his way. Ultimately, found my beloved Mk2 and thought of the great community here. Low and behold, she still powers up and works smoothly.

After a bit of poking around here to see what's new, now I wanna get BigDisk installed, but I've nearly forgotten how. At the moment, my biggest problem is lack of a serial port on an old Windows PC. I'm down to having one physical serial port on any of my PC's--and this one is on a Linux box which I've not fired up in years either. Is the only path to doing the upgrade via Wine? Is it possible just via emptool? I tried to see if emplode would run on Win11 (not very hard--it didn't want to) but will pursue getting things going via the Linux platform.

Greetings and Best to all,
Tim

Tim, I used a USB to Serial cable from amazon *https://www.amazon.com/OIKWAN-Converter-Chipset-Cashier-Register/dp/B0BKJKYCJK?s=electronics&th=1

I used it on an old Windows 7 32bit computer. I have used it on a Windows 10 64bit machine and it worked on it as well.
Your mileage may differ, but it worked for me. I have lots of connection issues, but Serial isn't one of them!
Good luck

Thanks! So that really worked? It doesn't appear to be a null modem cable rather than a straight-through...but I guess if you say it worked, who am I to argue.

I am at a bit of an impasse though. I managed to get my Linux box updated and operational. I was encouraged as when I powered it up (with the serial cable I have connected) that the empeg spun up to alertness. Sure enough, jemplode could connect via IP, but did not recognize the serial connection. Low and behold the empeg boot activity and FID error details showed up in an open system terminal!!

So it appears serial communication is occurring. Yet once WINE was finally installed, I could not establish a connection via serial on emplode nor jemplode. Still trying to sort that part out.

Never mind. :-) Apparently, I was one reboot away from comms working.

However, now the upgrade wizard get to where it almost appears to be done and says, "Error "Flash program failed" occurred during stage 0x11"

And now she don't boot. :-( Guess I gotta reflash the original image.

Time to search--shockingly, nothing on the BBS for "0x11" error. Hmmm.

It probably had an issue with that serial adapter. Try a different one, or do it using Linux instead (the download.c tool).

Well... I got:
Found empeg unit: entering program mode
Manufacturer=0089, product=88c1
starting erase [Bad result code: 0xa2

That doesn't sound good.

That just sounds like it had a comms error. Still on MS-Win, eh?

Ok. No, this was download.c on Linux Mint.

I'll see about ordering a new null cable.

The cable appears to be working. It could just be perhaps needing a different chipset in the USB-Serial Adapter.

What does 'lsusb' show for the adapter?
If I have a similar one here, I could re-test against it.

Cheers

Nope. That's not it. New null-modem cable does the same thing. It gets about 16-20% through the erase and throws that error. Any other ideas?

This is via a 9-pin to the 9-pin on the empeg.

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0040:073d
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Is that what is reported for ttyS0?

dmesg shows:
[ 0.563684] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

Changed to stty -F /dev/ttyS0 cs8 -parenb -cstopb and tried again.
Still [Bad result code: 0xa2

Tim, is it in a docking sled? If I recall correctly (Mark, correct me if I'm wrong here), the player serial port is 4800bps in the docking sled, and it won't do flash upgrades when docked.

https://riocar.org/FAQ/8/74.html#74
https://riocar.org/FAQ/7/82.html#82

Oh, okay. Not a USB-Serial cable/dongle then? A real, built-in serial port with DB-9 on the computer itself! (?)

Mmmm..

Here (attached) is the download binary I use, which works for me on Linux.

Hey Tony! No sled. Just on the desk.

Sorry sir, I only act like I know what I'm doing on linux. I tried chmod 755 download.bin and trying to launch it says:
download.bin: command not found

./download.bin

Are you trying this on a simulated Linux (eg. "Linux for Windows") or some such trash, or on a native install?

That still gets me. Frequently! I'm no expert on Linux, and my main driver is a Mac these days, and I hardly ever need to do anything at a DOS command prompt any more. Yet still, that's one of those things where, even if you know it, it still seems like it should work without the ./ in the front. Frustrating.

Someday I'll look up WHY it works that way. Still probably won't help me remember.

(Edit: Just did look it up. Supposedly it's a security feature to prevent a malicious program with the same name as a program in the PATH (like LS or MAN etc) from being automatically called in lieu of the real one from the operating system. Microsoft, on the other hand, chose convenience over security when designing their command line syntax.)

Native Mint 20.2 (Uma) install on bare metal.

Ok. Now prompting for an <address in hex>

./download.bin image_file_name 10000 /dev/ttyS0

But you already attempted to use download earlier, so same syntax as before.

(base) time@time-OptiPlex-790:~/Documents/mlord$ ./download.bin ../../Downloads/car2-developer-v2.01-final.upgrade 10000 /dev/ttyS0
Turn on empeg unit now
Found empeg unit: entering program mode
Manufacturer=0089, product=88c1
Starting erase [Bad result code: 0xa2

Yup. Increments to 24% and then errors.

I've even tried briefly shorting the 3v cell on the mainboard and retrying the reset in hopes of forcing a reset, but get the same results.

DOS didn't have directories until 2.x, so commands were always in the current directory (or built-in), so it didn't have a PATH environment variable. Microsoft chose (as they almost always do) backwards compatibility.

Mmm.. So either bad flash, or a bug in the download.c program. I would try just circumventing the failed test, and see how far it gets after that.

Here's a hacked copy of the source code which does that (attached).

Cheers

Mmm.. Okay, Status 0xa2 is composed of these three bits:

0x80 :: Device is idle.
0x20 :: Erase failed.
0x02 :: Prog/Erase attempted on a locked block, operation aborted.

So, probably not bad flash, but something wrong with the programming method. The download.c source code appears to correctly attempt to unlock blocks before erasing them, so this shouldn't be happening. I'll look a little closer to see if Hugo has a bug in there somewhere..

EDIT: Ah. The download.c program is actually sending commands to a firmware blob on the empeg, which is then talking to the flash memory. So if there's a bug, it appears to be in that firmware blob. Ugh.


Or maybe something has gone wrong with the WP input to the flash chip? I think that's only to protect the mysterious firmware blob itself, not the rest of the flash.

Dang, so I have two bricked players? Should I try to get a scope on that WP line... though I don't think I could get it captured correctly as I don't have a digital scope.

Thank you sir! Sadly, I get looped:

(base) time@time-OptiPlex-790:~/Documents/mlord/0x2a bypass$ ./download ../../../Downloads/car2-developer-v2.01-final.upgrade 10000 /dev/ttyS0
Turn on empeg unit now
Found empeg unit: entering program mode
Manufacturer=0089, product=88c1
Starting erase [Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..

Endlessly.

I super appreciate all your help on this! Given the people on this board if anyone can figure it out, it will be this crew. Thank you so much!

So this schematic got me looking... This doesn't seem right: [img:center]https://photos.app.goo.gl/tf78cj6XewCQWWU17[/img] and specifically, [img:center]https://photos.app.goo.gl/D3yvHt1ULpf9Wao88[/img]

It looks like solder paste or some kind of cap leakage seeped under, but there are no obvious sources anywhere near it.

I've flushed with 97% Isopropyl and then some DeoxIT D5 using a 0.3mm syringe and a wee bit of scraping. A flush and then blew it out with air. Looks better, but waiting for it to dry before try again.

<some hours later...>
Same result. Gets to 24% and errors. I don't know what that is under that first row of pins--it is not on any other device on the boards and nothing was ever spilled in there. I've been very careful to treat these with great care even when not in use. Maybe it is not related.

That's v1.00, an earlier version of the firmware blob. Is this a Mk2 "empeg", or a Mk2a "RioCar" ?

I see the IC9 Rev 1.00 sticker there, but one is a Mark 2 empeg player. It is also happening on a Mark 2a player as well. Same pattern of behavior.

My original player (SN 080000404) QA Inspected 15/8/00 is a Mark 2 empeg player with a mainboard version stamped Issue 7 Rev. 1 (c) 2000 with that "IC9 Rev 1.00" sticker.

The second player (SN 010101705) QA Inspected 21/3/01 is a Mark2a RD100-20 RioCar player with a mainboard version identified as Issue 9 Rev. 2 (2000) with the IC9 chip sporting a sticker of "1.02".

Both were previously on a version of Hijack from 2002-2003 era.

Waaaaait, you can't just use a whole ".upgrade" file with download.c... download.c is a fairly raw "rewrite this area of flash" tool, but an upgrade file contains several different chunks of data, some of which are meant to be written into blocks of the flash, some of which are meant to be written to disk. An upgrade file is bigger than the whole of the flash chip.

The command you want is called "upgclient", though I'm not sure where to find it these days.

Peter

The "block is locked" errors you were getting, probably mean that the flash writing wrapped at the flash size, and only the write-protection was saving you from overwriting the essential early blocks of the flash, something which would have bricked the player. Well done "us" (actually it was probably before my time) for adding that failsafe...

Peter

You can split the upgrade file into chunks and use 'download' on each chunk. Here's me doing it about 6 years ago: https://blog.differentpla.net/blog/2019/03/29/empeg-msata/#extract-the-upgrade-file-parts

Caution: this was with the empeg's disk attached to my Linux PC, but with the empeg attached over serial. You want just the 'upgrader' and 'download' steps.

I'm glad somebody's memory is working here! Thanks Peter!

Yes, download.c is normally just for the Linux/Hijack kernel itself, not for the other masses of data blocks that actually get written to the primary hard disk.

<smacks head>
That make some sense. I'll need to parse this out and see where I get. Thanks Peter/Roger/mlord! As ever, you guys are so awesome. Your glorious platform has had me itchy once again for the joy that is the empeg--even after 25 years.

I'm particularly excited to mess with the web empeg interface. Getting these type of updates is so stunning after so much time.

Once I get some free time later today I'll give these steps a whirl. Hope all is well.

Thanks again!
Tim

100% well done! Thanks!!

For this protection, I am very grateful. So stupid that I didn't realize what I was doing myself. 25 years ago I had this process down cold...too much time.

So I got the kernel flashed on both units.

I'm installing the mlord's car2-v21.upgrade presently via emplode on Wine (onto the newer unit with a legacy 60G drive.) Still in the "pumping partition" phase and in the process it did throw an "0000.17 hda: err: stat_err" message on the player screen, even so, things seem to be still progressing.

THANKS AGAIN TO ALL!!!

Success! I've successfully updated player kernels to the latest Hijack 526.

On the Mark 2a previously mentioned, I was getting the hda: err: Stat_err message. Suspecting a HD fail I've tried to recover with Spinrite, but found no issues/errors. I've realigned the pins further and attempted again...this time it went, but in my exuberance, I selected the builder_bigdisk_v21.upgrade and wiped my content. :-(

I know there are explicit warnings that all data will be wiped, but any chance of some kind of a recovery with binwalk or some such tool? It was dumb, but I was so excited it was working I forgot I'd changed from new media back to my disk with content (I was initially trying to get a CF card and/or a M.2 SSD drive going in it and not being successful--which is why I had the builder_bigdisk in the first place.)

On the other (older Mark 2) player, I've installed the latest car2-v21.upgrade w/o issue. Shiny!!!

Huge thanks!!

Wiped, means Wiped!