VOGONS


Reply 20 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
pentiumspeed wrote on 2020-10-07, 00:28:
Darry, […]
Show full quote

Darry,

Make sure you have storage disk (not removable) bit set in CF cards. That shows the issues I had with CF cards. Find 2GB or 4GB CF and do a test on a slot 1 machine, by using DOS and prepare them for bootable and if they boot in DOS, might work in your VS-880EX.

Ones that works:
Transcend
Industrial grade CF cards.
Swissbit 8GB CF

Cheers,

That is a very good point . I was lucky enough to have Sandisk CF cards that were old enough to be supported by the Sandisk utility to set the fixed (non removable) bit . Unfortunately, this did not help on the Sandisk card (VS-880EX still freezes shortly after boot). I might buy a few of those you recommended, but I would like to avoid Ebay due to huge amounts counterfeit cards being reportedly sold there .

It is interesting to note that all the CF (including the one whose fixed bit I changed) cards AND the SSDs that freeze the VS-880EX at boot cause exactly the same behaviour : the unit freezes while flashing its disk activity light constantly . This leads me to believe that the primary issue responsible for the symptoms observed is likely something other than the fixed (non removable) bit . I would, however, not discount the possibility that this bit may cause other issues if it is not set to the VS-880EX's liking .

I am guessing that all the older CF cards, the SSDs and that monstrous contraption that worked all have something in common . I really wish I could determine what that is .

So many variables and only so much cash to throw around at things to try, 🤣 . I really hope this ends being useful to someone other than me .

Cheers (I literally have a pint of beer beside me as I'm writing this)!

EDIT : I ordered some of these https://www.amazon.ca/Bodawei-Extreme-Compact … /dp/B07GCNMWX8/ . If the VS-880EX does not like them, I can always shove them in my Canon 40D . TBH, I would not be surprised if these are either NOS or built using recycled used flash memory .

Reply 22 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++

I received two FC-1307A based microSD to IDE adapters (one 44-pin and one 40-pin) . Both of them have the same issue as the FC-1307 based microSD to CF adapters . One way to work around the wiping issue is to create a FAT32 or NTFS primary partition of any size at the beginning of the "drive ". Unfortunately the VS-880EX is unhappy if the first partition is not a FAT12 or FAT16 one that it can use.

The 8GB industrial CF cards do work, so that is a relief, but is still not quite the commodity (SD/microSD) solution that I was hoping for .

EDIT : I also tried creating an extended partition at the beginning of the disk using those FC-1307A based adapters. That survives a power-cycle UNLESS the next primary partition on the disk happens to be a FAT12 or FAT16 one, in which case everything is wiped . I have no idea who was responsible for what passed as quality control on this FC-1307(A) design, but a ball was definitely dropped somewhere .

Reply 23 of 38, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

Looks like you have make do with CF or SSD with ATA to SATA bridge chip (I like the Startech version which uses Marvell chipset which is very well made). Why does watts matters? Just put in a small power supply to supply 5V direct from DC in jack instead of SV-880 motherboard's power circuits. Best solution really.

SD was not designed like hard drive in mind all along since it was very specialized interface way before SATA came up (history). unless someone develops a high quality hard drive emulation chipset in hardware to work with SD and completely fool the computer into thinking it is real hard drive. Which is tricky due to NAND technology is not made for 512 sector in mind, also needs large buffer (64MB or more) to hide the blocky writes and self trimming, NAND need to be erased in blocks just to rewrite few bytes, a very hard part to do properly. The CF chipset were made in mind as hard drive emulation properly and the NAND chips were naked, no interface at all. Besides, FAT 16 was not in mind when SD came out as well. USB storage is similar but it was made like a hard drive in mind.

SD has a chipset built in very specialized that requires a SD chipset + driver on the motherboard to interface with SD's controller and in turn SD's controller interfaces with the non-standard NAND chips. Honestly, SD is rather bad as a storage disk in mind.

Cheers,

Great Northern aka Canada.

Reply 24 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
pentiumspeed wrote on 2020-10-08, 20:42:
Looks like you have make do with CF or SSD with ATA to SATA bridge chip (I like the Startech version which uses Marvell chipset […]
Show full quote

Looks like you have make do with CF or SSD with ATA to SATA bridge chip (I like the Startech version which uses Marvell chipset which is very well made). Why does watts matters? Just put in a small power supply to supply 5V direct from DC in jack instead of SV-880 motherboard's power circuits. Best solution really.

SD was not designed like hard drive in mind all along since it was very specialized interface way before SATA came up (history). unless someone develops a high quality hard drive emulation chipset in hardware to work with SD and completely fool the computer into thinking it is real hard drive. Which is tricky due to NAND technology is not made for 512 sector in mind, also needs large buffer (64MB or more) to hide the blocky writes and self trimming, NAND need to be erased in blocks just to rewrite few bytes, a very hard part to do properly. The CF chipset were made in mind as hard drive emulation properly and the NAND chips were naked, no interface at all. Besides, FAT 16 was not in mind when SD came out as well. USB storage is similar but it was made like a hard drive in mind.

SD has a chipset built in very specialized that requires a SD chipset + driver on the motherboard to interface with SD's controller and in turn SD's controller interfaces with the non-standard NAND chips. Honestly, SD is rather bad as a storage disk in mind.

Cheers,

My initial goal was to get it working by using for commodity parts for "consumables" (hard drives and flash chips die and wear out eventually). (micro)SD card availability made it the obvious first choice. CF long-term availability is unlikely, so I would no longer call them commodity. Finding compatible ones is not that easy and it is essentially impossible to know how long they will last (SMART does not work on the industrial ones that are compatible).

My revised goal was to find a way to get the "consumable" variable out of the way, so using an SSD with high endurance and reliability seemed like a way to solve the problem for life . SSDs are known to be reliable and the write endurance of even a basic one would likely be enough for a lifetime of use . Again, compatibility was an issue . I essentially found one family of still available SSDs whose controller is liked by the VS-880EX and that is the Samsung 860 EVO series . I have tested it fully now and it works well, using external power . I may yet consider feeding it external power or even tapping the 5V rail on the VS-880EX PSU directly . I would prefer to avoid external power as having two power feeds on a single device feels kind of clunky (maybe I'm just being stubbornly pedantic).

When the FC-1307(A) SD to IDE/CF adapters work, they work very well indeed. I have tested them in cameras and PCs . Unfortunately it works so well in most use cases and is so cheap that there is practically no competition left on the market (except maybe very high end/sensitive applications). If you happen to hit a bug with it, as I have, there are essentially no alternatives, except maybe the slower FC1306T based units that are now rare .

Current NAND flash memory is inherently unreliable, the controller used, whether in a CF or SD card is responsible for shielding the block device user (PC, phone, camera, etc) from this unreliability, among its other functions. This works well for storage in multiple devices, including in phones/tablets, which use eMMC (which is essentially SD compatible) .

I am no expert on low level flash storage tech (or any low level storage tech), but other than the added latency of an SD to CF conversion, and other potential performance/speed issues, I do not see why a reliable solution could not exist . Unfortunately, I could not find one . That said, I would have preferred if something like SMART telemetry existed for SD cards .

Cheers!

Reply 25 of 38, by Oetker

User metadata
Rank Oldbie
Rank
Oldbie

I have a Compaq SFF PC that uses the same 50-pin connector for its slimline CD drive (which I don't own). It's not clear to me what the extra 6 pins are for, any idea what they are used for in your case? Maybe extra power/ground?

Reply 26 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++

As a curiosity, the FC1306T actually made it into an actual Korg product (SD card reader board in the Korg PA50SD keyboard).

https://www.partsisparts.net/catalog/korg-pa5 … ly-530000001638

Reply 27 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
Oetker wrote on 2020-10-08, 22:00:

I have a Compaq SFF PC that uses the same 50-pin connector for its slimline CD drive (which I don't own). It's not clear to me what the extra 6 pins are for, any idea what they are used for in your case? Maybe extra power/ground?

I would guess that they are not used .

Reply 28 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++

Today I unsoldered the 64KB firmware chip from one of my FC1307A converters and dumped it .

The contents of the flash chip exactly matches that posted here : https://goughlui.com/2019/02/03/tested-generi … dapter-sd35vc0/

I was hoping that firmware might be different, possibly better than mine, but that turned out not to be the case, unfortunately .

Reply 29 of 38, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

That means nobody yet to develop a ATA to SD properly. SD commands very proprietary are different from ATA which is raw ISA bus that depends on the CPU and BIOS, DOS to do the job then again a chip to translate between two. This means a little chip had to emulate most of that again and then translate to SD communication and programming to "program" the SD correctly. Hence the issues of too many translation layers can become a issue unless one get it right or timing issues trips the VS-880 up rather than the SD itself as issue?

Unless one designs much faster, low latency ATA-SD hardware using class 10 UHS high speed SD instead of slow SD.

Are you using slow SD ( they are that slow, slower than IDE when writing, why not use class 6 10 or U1 or U3 SD? This means using either SDHC, SDXC, or SDUC. They are high capacity but you can partition small partition use FAT16 on a SDXC 32GB card?

Also, SD are not made for busy access that disk based storage does, CF is half way between dumb nand and smart SSD that do trim and OS is the other half that does talks to the SSD to keep it healthy via trim. SD does not and is not a disk in mind, SD was just merely like USB stick and as a carrier to transfer and store infrequently used data that cameras, etc and transferring data between computers are perfect in mind not as a disk.

Second, does not need driver as long as 98 knows how to access PCMCIA slot using dumb adapter to access CF easier. That another reason you have better luck with SSD and CF. EVO 860 is very well made SSD that works so well, and should work well with WD blue 3D nand, Micron SSD and Intel SSD since these several were made and designed themselves, tested carefully. Not those third party where one get turnkey controllers, ready to roll firmware and garbage NAND chips with little quality and poorly tested. That exactly what it is, low quality third party SSDs with funny sounding brands.

Cheers,

Great Northern aka Canada.

Reply 31 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++

My plans for cleanly setting up my VS-880EX will have to wait, as the part I am waiting for from Japan took two weeks to move from the post office to whatever the next step is . According to tracking, it left Japan on the 18th and has been somewhere in limbo between Japan and Canada for over 3 days . That's EMS in the time of COVID . Strangely enough, the VS-880EX itself took something like three days to arrive from Japan using either DHL or Fedex (I forget which).

Anyway, I have decided that I had waited long enough and installed the VS-880EX with a CF card and adapter hanging off a ribbon cable . It's not pretty, but it is reversible and it works fine .

At first listen, it does seem to be quieter than the DPS12 and it's headphone out is significantly more powerful . It is also quite a complicated beast to operate as a recorder (not that the DPS12 was simple, but this is a whole new ballgame) . I will probably just use it as a mixer/digitizer for now .

Reply 32 of 38, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Regarding the behaviour of the FC1307 based adapters; the partitions/MBR don't actually get wiped, at cold-power-on the adapter (for whatever reason, I haven't narrowed it down by testing things like different partition setups) just starts returning a 512 byte ATA IDENTIFY response at the beginning of returned data. For example if you read 1 sector (512 bytes) starting at LBA 0, you only get the ATA IDENTIFY response. If you read 2 sectors (1024 bytes) starting at LBA 0, you get 512 bytes of ATA IDENTIFY response followed by the contents of LBA 0 (the contents of LBA 1 are not returned).
So the BIOS tries to boot by reading LBA 0 and receives the ATA IDENTIFY data instead... which it doesn't recognize.

The adapter reverts back to proper operation if LBA/sector 0 is written. So repartitioning "fixes" it, and is able to work because it uses the ATA IDENTIFY command (the only correctly working command!) to determine the disk's capacity. If you can boot to an EFI shell you can use it to read two sectors from LBA 0 and write the second returned sector back to LBA 0, then the disk should be bootable.

It's also possible to confirm the partitions are not wiped by taking the SD card out of the adapter and checking it on a different PC.

Reply 33 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
jmarsh wrote on 2020-11-11, 03:34:
Regarding the behaviour of the FC1307 based adapters; the partitions/MBR don't actually get wiped, at cold-power-on the adapter […]
Show full quote

Regarding the behaviour of the FC1307 based adapters; the partitions/MBR don't actually get wiped, at cold-power-on the adapter (for whatever reason, I haven't narrowed it down by testing things like different partition setups) just starts returning a 512 byte ATA IDENTIFY response at the beginning of returned data. For example if you read 1 sector (512 bytes) starting at LBA 0, you only get the ATA IDENTIFY response. If you read 2 sectors (1024 bytes) starting at LBA 0, you get 512 bytes of ATA IDENTIFY response followed by the contents of LBA 0 (the contents of LBA 1 are not returned).
So the BIOS tries to boot by reading LBA 0 and receives the ATA IDENTIFY data instead... which it doesn't recognize.

The adapter reverts back to proper operation if LBA/sector 0 is written. So repartitioning "fixes" it, and is able to work because it uses the ATA IDENTIFY command (the only correctly working command!) to determine the disk's capacity. If you can boot to an EFI shell you can use it to read two sectors from LBA 0 and write the second returned sector back to LBA 0, then the disk should be bootable.

It's also possible to confirm the partitions are not wiped by taking the SD card out of the adapter and checking it on a different PC.

Nice to see someone looking else at this . Thank you for analysis and explanation . I always tested through the FC1307, so I never noticed the partitions were still there . Assuming the FC1307 is hot-swap capable on the SD card side , I wonder how it would react to being powered up without the SD card and then having the card "inserted". If that bypasses the issue, it might hopefully be used as the basis of a hardware-assisted workaround .

If it is necessary to read two sectors starting at LBA0 and rewrite the second of the two to LBA0 at every boot, it is, unfortunately, not very practical , but it is great to know what is actually happening .

As a workaround, having a non FAT12/FAT16 primary partition as the first partition seems to mitigate the issue, AFAICR . Unfortunately, this is not a viable option for some applications, like in the Roland VS-880EX .

Thank you very much for sharing this .

Reply 34 of 38, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

I figured out the behaviour 4 years ago, trying to use an SD->SATA adapter to run a linux box. Couldn't find any similar information on the web so thought I just had a dud device. Wasn't until today when I saw the adapter in my spares box and noticed it used a FC1307 chip that I realized it was the same issue as what you were describing.

If I had to guess, the adapter may be trying to read the first FAT32 partition to match its emulated C/H/S values with those stored in the BPB, and assuming the disk is uninitialized if it can't find one (with fallback code that only checks for NTFS). This is particularly dumb in my case because it's using a SATA interface (which doesn't support C/H/S addressing), but not surprising since it still identifies as "FC-1307 SD to CF Adapter", "V1.1", "Rev 1.1".
I do know it's not as simple as having a non FAT12/16 primary partition, because it doesn't like EXT2/3/4 partitions or a non-MBR (i.e. GPT) partition table either.

Reply 35 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
jmarsh wrote on 2020-11-11, 04:45:

I figured out the behaviour 4 years ago, trying to use an SD->SATA adapter to run a linux box. Couldn't find any similar information on the web so thought I just had a dud device. Wasn't until today when I saw the adapter in my spares box and noticed it used a FC1307 chip that I realized it was the same issue as what you were describing.

If I had to guess, the adapter may be trying to read the first FAT32 partition to match its emulated C/H/S values with those stored in the BPB, and assuming the disk is uninitialized if it can't find one (with fallback code that only checks for NTFS). This is particularly dumb in my case because it's using a SATA interface (which doesn't support C/H/S addressing), but not surprising since it still identifies as "FC-1307 SD to CF Adapter", "V1.1", "Rev 1.1".
I do know it's not as simple as having a non FAT12/16 primary partition, because it doesn't like EXT2/3/4 partitions or a non-MBR (i.e. GPT) partition table either.

I just tested the hotswap thing and that does not work .

- I did test with a 2GB microSD card, in MBR, by creating a 32MB NTFS primary partition at the beginning of the card and a FAT16 primary active partition on the remainder of the card, and that survives a power-cycle . I also tested with GPT and had the same results .
- I also did test with a 2GB microSD card, in MBR, by creating a 128MB (32MB was too small for Windows 10 to let me format as FAT32) FAT32 primary partition at the beginning of the card and a FAT16 primary active partition on the remainder of the card, and that too survives a power-cycle . I also tested with GPT and had the same results .
- Finally, in GPT, I tested a FAT16 partition spanning the whole card, and that too is still visible after a power cycle .

So at least, in MBR, as long as the first primary partition is FAT32 or NTFS, you can have other FAT16 partitions on the card. GPT just seems to work for me .

EDIT : In one of my previous posts I refer to the firmware my adapter has. AFAICR, it is 1.2 . If you have 1.1 , it may explain the difference in GPT behaviour .

Reply 36 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
darry wrote on 2020-11-11, 05:54:
I just tested the hotswap thing and that does not work . […]
Show full quote
jmarsh wrote on 2020-11-11, 04:45:

I figured out the behaviour 4 years ago, trying to use an SD->SATA adapter to run a linux box. Couldn't find any similar information on the web so thought I just had a dud device. Wasn't until today when I saw the adapter in my spares box and noticed it used a FC1307 chip that I realized it was the same issue as what you were describing.

If I had to guess, the adapter may be trying to read the first FAT32 partition to match its emulated C/H/S values with those stored in the BPB, and assuming the disk is uninitialized if it can't find one (with fallback code that only checks for NTFS). This is particularly dumb in my case because it's using a SATA interface (which doesn't support C/H/S addressing), but not surprising since it still identifies as "FC-1307 SD to CF Adapter", "V1.1", "Rev 1.1".
I do know it's not as simple as having a non FAT12/16 primary partition, because it doesn't like EXT2/3/4 partitions or a non-MBR (i.e. GPT) partition table either.

I just tested the hotswap thing and that does not work .

- I did test with a 2GB microSD card, in MBR, by creating a 32MB NTFS primary partition at the beginning of the card and a FAT16 primary active partition on the remainder of the card, and that survives a power-cycle . I also tested with GPT and had the same results .
- I also did test with a 2GB microSD card, in MBR, by creating a 128MB (32MB was too small for Windows 10 to let me format as FAT32) FAT32 primary partition at the beginning of the card and a FAT16 primary active partition on the remainder of the card, and that too survives a power-cycle . I also tested with GPT and had the same results .
- Finally, in GPT, I tested a FAT16 partition spanning the whole card, and that too is still visible after a power cycle .

So at least, in MBR, as long as the first primary partition is FAT32 or NTFS, you can have other FAT16 partitions on the card. GPT just seems to work for me .

EDIT : In one of my previous posts I refer to the firmware my adapter has. AFAICR, it is 1.2 . If you have 1.1 , it may explain the difference in GPT behaviour .

I have some more experiences with an FC1307A based adapter . If I create a FAT16 primary partition using Easus Partition Master rather than Windows 10 Disk Management or Linux fdisk, it seems to be perfectly accessible after a power cycle !

The only difference I see at first glance (there may be others) is the offset of the partition from start of disk . It is either 63 or 64 (depending if I choose optimize for SSD) when using Partition Master, and 128 when using Easus Partition Master Windows 10 disk management console .

Last edited by darry on 2020-11-26, 01:55. Edited 1 time in total.

Reply 37 of 38, by yawetaG

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2020-11-25, 00:30:

I have some more experiences with an FC1307A based adapter . If I create a FAT16 primary partition using Easus Partition Master rather than Windows 10 Disk Management or Linux fdisk, it seems to be perfectly accessible after a power cycle !

The only difference I see at first glance (there may be others) is the offset of the partition from start of disk . It is either 63 or 64 (depending if I choose optimize for SSD) when using Partition Master, and 128 when using Easus Partition Master .

Could you try using GParted Live for creating the partition? It has some advanced options for formatting disks for systems other than Windows or Linux.

AFAIK Windows Disk Management is and Linux fdisk may be optimized for working with Windows (Linux fdisk being specialized in easily creating a dual boot system with Windows).

Reply 38 of 38, by darry

User metadata
Rank l33t++
Rank
l33t++
yawetaG wrote on 2020-11-25, 07:36:
darry wrote on 2020-11-25, 00:30:

I have some more experiences with an FC1307A based adapter . If I create a FAT16 primary partition using Easus Partition Master rather than Windows 10 Disk Management or Linux fdisk, it seems to be perfectly accessible after a power cycle !

The only difference I see at first glance (there may be others) is the offset of the partition from start of disk . It is either 63 or 64 (depending if I choose optimize for SSD) when using Partition Master, and 128 when using Easus Partition Master .

Could you try using GParted Live for creating the partition? It has some advanced options for formatting disks for systems other than Windows or Linux.

AFAIK Windows Disk Management is and Linux fdisk may be optimized for working with Windows (Linux fdisk being specialized in easily creating a dual boot system with Windows).

I did not try GParted Live , but I did give Linux Fdisk another shot under a Centos 7 VM . I set partition type to 6 (FAT16) and used mkfs.vfat -F 16 to force the creation of FAT16 filesystem (mkfs apparently does not rely on the partition type set by fdisk to choose between FAT12/16/32) . The resulting primary FAT16 partition is still accessible after a power cycle on the Fc1307A adapter . Clearly, I did something differently than the last time that I tested .