Job done, many thanks
The Mac Windom download for DSD appears to be corrupt. I kept getting an error (attached ) when trying to burn the .img file onto the SD card. Then I just downloaded the Windows version onto my mac hard drive and copied the individual files over and got booted into windom that way. Why is there is a separate method for the Mac that appears to not work?
I am still having issues trying to get wisdom loaded on my DSJ. I have tried 3 different USB sticks ranging from 8Gig to 32, slow fat 32 format, unplugged the Ethernet cable from the DSJ, unplugged it for 5 minutes, restored defaults and still have not been successful. I am out of ideas on what else to do. Is there a way to test the actual USB port on the DSJ to make sure itās not malfunctioning?
If you have a card smaller than 8gb try that. If you have an option for regular FAT try that also.
The smallest usb stick i have is 8. I can run to the store tomorrow and see if they have a 1 or 2 gig thumb drive.
I saved a bunch of old 2 and 4GB sticks just for firmware updates. Most updates for gear rarely ever even come close to that. It seems the oldest FAT you can use is best. If Mac try MSFAT. Always use the option to eject the card and wait ten seconds before removing or when the light stops flashing on the stick if equipped. Make sure the files have been unzipped before moving them to the stick if you hadnāt done that.
Use your 8gb card. Download the Yale version for your Jr. install Yale. If that goes well then try to upgrade to Windom once again. Remember to power down after the upgrade, pull the usb thumb drive out, then power up.
Thanks! I will give it a shot tomorrow.
@erniejade
Itās not USB stick issue. I have suspected that might be USB issue ,been bought and replaced at least five USB sticks still not worked out.
check out my way at post#233
Good luck
Ah okā¦the resistor thing seemed as if itās custom tweaked.
Would be great if PSA could send a definitely correctly loaded DS for trial to customers who get nuts with this matterā¦just to rule this out.
The issue in my case being that it was the exact same card that Iād loaded it from multiple times, worked every time (did the whole flashing-load cycle when using the card vs. just a boot), and a week in, on reboot - the sound changed completely. So it was correct files (on a card from PS, actually) all along - but in some cases, they donāt always have the same sonic result apparently.
I was going to go over on that Monday to borrow a DS with a good load, but then I didnāt need to.
In a bigger industry, considerable efforts would be taken to find out about it, and I guess it would be possible to catch influences as time goes byā¦but in a small company it might be difficult to allocate resources of that extent necessary.
My best guess is that there is an issue related to all of the code failing to āoverwriteā. Unless the DAC (Sr. in my case) just blinks and never loads anything at all, I donāt think your experience (and mine with Redcloud to Snowmass 3.0) is reflective of bad code or messed up SD cards (or USB sticks). Rather, again, I believe there is a failure to complete all of the necessary changes to the firmware. I did not experience a material degradation in sound when I had issues. Rather the sound was just kind of āMehā; and I did not hear the positive improvements others reported ā until the third cycle involving RC to SM, to RC and back again. I know some are getting the SD cards or USB sticks messed up in some cases and are unable to do the firmware update at all. I can understand that. I canāt understand the experience we shared ā where all of the code does not ātakeā so to speak. You would think a less then 100 percent transfer of the code would wreak havoc with the sound or brick the kit, but no.
Re the last of your post:
The bootloader isnāt overwritten during a user update process so bricking isnāt likely.
The FPGA hardware wonāt boot without good CRCs. The DS (and DS Jr) will play sound indefinitely (almost) perfectly even if the control/display processor isnāt there or isnāt doing anything. The Jr also has the option of automatic input selection so the FPGA can be more independent there. The control processor is needed for the display and UI interactions. If the display is correct then the code is probably loaded correctly: any bad sound is probably caused by doing things too often or not often enough and generating noise. Thereās also the possibility of it banging the crap out of the FPGA causing noiseā¦ But if we knew exactly what is going on it probably would be fixedā¦
Could you explain/expand on that?
We can keep going on and on. What we really need is a fix by PSAudio.
Given the current form a date for a fix would be great place to start.
E.g. the differences between the sounds of the various Snowmass releases was in part the rates of accessing the display.
KeithLeeTW. This worked perfectly. Thank you! About to give it a listen after a reboot.
i.e. PIC code stuff?
Yep, thatās what I was trying to say.