It will be very slow, depending on the CF Card. Just wait for it. Eventually it should say "Done!" on the serial port (and on the front panel display!) and then drop to a (bash) command prompt.

More expensive CF cards boasting very fast sustained WRITE speeds will be quicker there. Using the v6 builder will also be MUCH quicker than the other choices too.

Here (attached this time, rather than inline) is the actual/recommended v6 builder script. I should have posted this one earlier instead of v3. If you have a quick peek, you should be able to see exactly what it is doing at any point.

Builder V6 seems to be much better! Thank you so much!

I was having trouble with builder V3 on the CompactFlash drive. It was doing the same problem as before, where when the builder was done there wasn't any "fids" or "var" folder. But now, with Builder V6, it looks like those folders are getting created and all looks well on the flash drive. Thanks!

I'm still having an issue that I think is non-builder-related, though.

I went forward with installing everything on the CompactFlash drive and in theory the unit seems to work as expected, though I haven't tried using Emplode on it yet. My intention is to copy all the files from the old drive to the new drive at the shell prompt, with both drives plugged in as master/slave.

I'm running into a problem when I'm trying to copy files from the prior drive to the new drive. I set the new drive as slave and the old drive as Master, and then try to set the drives read-write and copy the contents of "var" over. When trying to set read-write it tells me that it "can't find /drive1 in /etc/fstab or /etc/mtab", and when I try to copy files, it says "read only file system".




Any ideas?

Attached is a full session log output including the FSTAB output, if that's helpful.

Thanks so much for all the help you're giving on this thread!

Oh hey, it looks like I don't have the same problem if I swap the order: New disk is primary, old disk is slave.

Trying that now.

Edit: Yeah all the copies work if I boot the new drive (destination drive for the copies) as master and the old drive (source drive for the copies) as slave. No problems so far, all file copies are humming along nicely.

Okay, good! That saves me from having to explain how it works in more detail than is usually necessary!

How is the CF Card working for you now, Tony?

It's worked perfectly so far. I got these:

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

BigDisk Builder V6 worked fine, applying the player worked fine, applying the latest Hijack worked fine. I was able to copy all of the FIDs, all of the VAR folder, and the dynamic data partition, all over from the old drive to the new drive, from the empeg shell prompt. Everything works as expected so far, and I got no error messages during the copying process, as long as I had the master/slave order set so that the old drive was slave, and the new drive was master.

What I have not done yet: I have not tried a synch with emplode yet. I have a somewhat large set of tunes to add (several albums' worth), and I'll do that some time when I get a chance, and if that goes smoothly then I'll consider it done.

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.

Thanks so much for your help!

Great. I take it that the screw holes also lined up with the empeg's sled, making it super convenient.

Note that this adapter can accept a pair of CF cards simultaneously,
in place of attaching a second CF card to the other IDE connector
of the empeg (use one method or the other, but not both).

Cheers

Ah, yes. That.

Okay, I have just updated all of the bigdisk images etc.. to include the latest Hijack v524 by default now, saving a step for the next time!

Cheers

Mark, any reason why this wouldn't work?

https://www.amazon.com/dp/B079GSGCJY/

Because a 64gb SD card is really cheap. I only wish the board was setup so that I could cut a slot and expose the card to be accessible from the exterior of Empeg.

How about this?

Those look a bit hit and miss. They seem to use really old controller chips, which is a Very Good Thing(tm) because that means they very likely implement the old PIO protocols correctly -- needed by the empeg.

But they also seem to be limited to no more than 64GB size in SD cards, and probably don't work with SDXC or perhaps even some SDHC cards. Note that there's a cheaper branded copy of the exact same card on Amazon: https://www.amazon.com/Optimal-Shop-Digital-Adapter-Converter/dp/B00DGNYXQ0/

If I could get one here cheaply/quickly enough, I would get one and try it out. But Amazon Canada doesn't have any "local" options -- they all come on the slow boat from Asia.

That just looks like an extension cord for an SDCARD socket. No way to plug it into an empeg.

I actually saw that last night and was thinking the same thing you were.

Mark: Larry's suggesting the extension in conjunction with the SD board I linked to be able to mount the SD card slot on the back of the empeg so that it's removable without opening up the case.

Ah, sure that ought to work (and my apologies to Larry!). In my previous car, I just extended the IDE cable outside of the chassis so that the attached CF-Card would be accessible.

I have "ordered" one of the SD-Card adapters (thanks Roger!) and will try it out Live! at the 21st Anniversary Meet in Cambridge.

Cheers

Is that a big deal? Isn't the IDE bus on the empeg pretty slow anyway?

Same deal as with some modernish SSDs: not well tested on old PIO-only machines such as our empeg! SDXC have higher speed protocols that most machines from the past decade should grok, and reports suggest that at least some of those are not fully backward compatible with the old/slow SPI protocol more traditionally associated with SD-Cards. EDIT: The controller chip on the adapter pre-dates SDXC.

Hey, I was just reading the Amazon reviews!
But we'll find out in a couple of weeks in Cambridge. I have a modern SDXC card as well as some older cards to try out in the adapter.

Ordered! I won't steal your thunder by reporting my results until after the meet. If all goes well, I'll likely order that extension and do some case modification.

By all means please DO report your findings, along with the exact card used in the reader. The more data the better here!

Cheers!

Well, I'm starting out conservative. I dropped a whopping $6.54 for this 32gb card:

https://www.amazon.com/gp/product/B079H5HYC7/

If that works, I'll move to a 64gb card, then 128 if that also goes well.

Well, among other slower cards, I have this 64GB card, which boasts reasonably quick write speeds for US$13.52:

https://www.amazon.com/Samsung-MicroSDXC-Memory-Adapter-MB-MC64GA/dp/B06XFWPXYD

So between us we should get a decent sample set!

Yes, wrong.
When the EmpegUpgrade.exe says it is done, that means it has installed the .upgrade (builder image in this case) onto the empeg. But the empeg then reboots and RUNS the builder, which takes quite a bit more time. So one does have to wait for the bigdisk builder to display "Done!" on the front panel display!

I am thinking about generating improved bigdisk-builder images which also install the final (v2 or v3a11) player software as part of the "builder" process, saving a second time-consuming .upgrade step. Maybe in time for The Meet.

Cheers

So mixed results so far. I installed the little converter and SD card (the card is on the bottom side of the board):



I'm able to run the big disk builder upgrade file, then the player 2.01 upgrade file. After that I can copy music to the drive and play it. Everything is good up to this point. The only problem is that the moment I pull the power, I lose the ability to connect to the SD card. The player says No Hard Disk Found, Contact Support. This seems bizarre, because it was happily playing music seconds before. I've duplicated this behavior with both the 32gb card, and an old 1gb card I had laying around. Seems consistent with what some are reporting in the Amazon comments. I'm wondering if it's just not handling a non-windows filesystem very well?

Boot log:

empeg-car bootstrap v1.02 20001106 (hugo@empeg.com)
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.17-rmk5-np17-empeg55-hijack-v518 (hijack@rtr.ca) (gcc version
2.95.3 20010315 (release)) #2 Tue Jun 3 14:28:51 EDT 2014
Processor: Intel StrongARM-1100 revision 11
Checking for extra DRAM:
c1000000: wrote ffffffff, read e28cc001
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 10101536) 16MB DRAM
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 15000k/16M available (996k code, 20k reserved, 364k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 206f6972 'rio '
Tuner: loopback=0, ID=-1
show_message("Hijack v518 by Mark Lord")
empeg display initialised.
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0004d80).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
ide_data_test: wrote 0x0000 read 0x0000
ide_data_test: wrote 0xffff read 0x0000
ide_data_test: wrote 0xaaaa read 0x0000
ide_data_test: wrote 0x5555 read 0x0000
hda: SINTECHI HighSpeed SD to CF Adapter V1., ATA DISK drive
ide_data_test: wrote 0x0000 read 0x0000
ide_data_test: wrote 0xffff read 0x0000
ide_data_test: wrote 0xaaaa read 0x0000
ide_data_test: wrote 0x5555 read 0x0000
hda: SINTECHI HighSpeed SD to CF Adapter V1., ATA DISK drive
ide_data_test: wrote 0x0000 read 0x0000
ide_data_test: wrote 0xffff read 0x0000
ide_data_test: wrote 0xaaaa read 0x0000
ide_data_test: wrote 0x5555 read 0x0000
hda: SINTECHI HighSpeed SD to CF Adapter V1., ATA DISK drive
ide_data_test: wrote 0x0000 read 0x0000
ide_data_test: wrote 0xffff read 0x0000
ide_data_test: wrote 0xaaaa read 0x0000
ide_data_test: wrote 0x5555 read 0x0000
hda: SINTECHI HighSpeed SD to CF Adapter V1., ATA DISK drive
ide_data_test: wrote 0x0000 read 0x0000
ide_data_test: wrote 0xffff read 0x0000
ide_data_test: wrote 0xaaaa read 0x0000
ide_data_test: wrote 0x5555 read 0x0000
hda: SINTECHI HighSpeed SD to CF Adapter V1., ATA DISK drive
ide_data_test: wrote 0x0000 read 0x0000
ide_data_test: wrote 0xffff read 0x0000
ide_data_test: wrote 0xaaaa read 0x0000
ide_data_test: wrote 0x5555 read 0x0000
hda: SINTECHI HighSpeed SD to CF Adapter V1., ATA DISK drive
ide0 at 0x000-0x007,0x038 on irq 6
hda: SINTECHI HighSpeed SD to CF Adapter V1., 29664MB w/8kB Cache, CHS=60269/16/
63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman (erik@vt.edu)

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:22:06:0
0
Partition check:
hda: hda1
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...attempt to access beyond end of device
03:05: rw=0, want=2, limit=0
dev 03:05 blksize=1024 blocknr=1 sector=2 size=1024 count=1
EXT2-fs: unable to read superblock
Kernel panic: VFS: Unable to mount root fs on 03:05

Interesting. It's as if nothing was ever written to the card during the various install steps. Or perhaps a counterfeit card that has (much) less capacity than advertised, resulting in sector "wrap around" which then destroyed the partition table.

Except you got it with more than one card. So probably not the card.

EDIT: The above boot log is from AFTER installing everything, right?

I have read through some of the Amazon reviews for various versions of this adapter, and the common theme seems to be that the partition table gets rewritten to the SD-Card at power on. Always with exactly one MS-DOS partition populated.

The interesting question then becomes, is the rest of the SD-Card still intact? If so, we could kludge a reasonably simple work-around in Hijack to just ignore the read-in partition table, and instead use either a saved copy or an auto-generated table (partition tables are only 512-bytes long, plus whatever "extended" partitions exist).

I suppose the onboard firmware might be doing something stupid like, "if card isn't something I recognize, then auto-format it at power-on". In which case it's a matter of determining how it "recognizes" the card. Most likely it just looks at the partition table. If that's the case, then we just tell Hijack to offset everything by 1 sector, nothing else required.

If you want to try this, I can provide a suitably hacked kernel, builder image, and car2-software image with that kernel.

Ha! There is already a mechanism to do this kind of thing in the IDE driver in Linux. I added it decades ago to deal with "EZDRIVE" partitioning software that did something similarly silly with the partition table.

So a possible workaround here simply involves enabling that code, and checking for the specific brand/model of SD Card converter. Done. Try this (attached).

Note that this is safe (aka "inactive") for use with regular drives too.

EDIT: Replaced builder+image with a single combined builder image.

I've got another engagement this morning, but I'll try it later today.

Kernel code change to enable the (possible) workaround:

Code:

--- v524/drivers/block/ide-probe.c      2009-09-14 08:39:40.000000000 -0400
+++ hijack-v524+/drivers/block/ide-probe.c      2019-05-25 07:47:10.952063665 -0400
@@ -86,6 +86,20 @@
        printk("%s: %s, ", drive->name, id->model);
        drive->present = 1;
 
+#if FAKE_FDISK_FOR_EZDRIVE
+{
+       /*
+        * Try and deal with SD-Card adapters that rewrite an MS-DOS partition table
+        * at every power-on, by remapping sector 0 to 1.
+        */
+       static const char sintech[] = "SINTECHI HighSpeed SD to CF Adapter";
+       if (0 == strncmp(id->model, sintech, strlen(sintech))) {
+               drive->remap_0_to_1 = 1;
+               printk("[sdcard remap 0->1] ");
+       }
+}
+#endif
+
 #ifndef CONFIG_SA1100_EMPEG
        /*
         * Check for an ATAPI device
--- v524/drivers/block/ide.h    2017-08-06 08:36:18.000000000 -0400
+++ hijack-v524+/drivers/block/ide.h    2019-05-25 07:45:06.083976833 -0400
@@ -41,7 +41,7 @@
 #define INITIAL_MULT_COUNT     8
 #define SUPPORT_SLOW_DATA_PORTS        0
 #define SUPPORT_VLB_SYNC       0
-#define FAKE_FDISK_FOR_EZDRIVE 0
+#define FAKE_FDISK_FOR_EZDRIVE 1
 #define FANCY_STATUS_DUMPS     0
 #define REALLY_FAST_IO         1
 #undef  INITIAL_MULT_COUNT

If you do try it, (re-)download the builder image from my earlier post:
I have updated it to a single image that builds the drive
AND installs v2.01 software in one step.

Just reboot the player once it shows "Done!" on the front panel display.

Note that the combined builder image is a Work In Progress. I will release a more polished version at some point, likely at The Meet.