XXHighEnd - The Ultra HighEnd Audio Player
April 23, 2024, 11:44:23 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: August 6, 2017 : Phasure Webshop open ! Go to the Shop
Search current board structure only !!  
   Home   Help Search Login Register  
Pages: [1]
Author Topic: 04 | What you see in the Disk and Prerequisites to let all work  (Read 5301 times)
0 Members and 0 Guests are viewing this topic.
High Grade Audiophile
Offline Offline

Posts: 16837

View Profile Email
« on: January 22, 2016, 11:51:14 am »

Here is a separate small "Tutorial" about what you will see in the Disk and when.

Let's first look at the situation that we booted from the TRIAL Operating System, which is the only normal OS in there. Thus, this is the only OS which has been installed in a means we are all used to. It only shows a Drive C: and nothing else for local Drives (assumed you did not connect any USB Flash drive etc.) :

(notice that in this example the E:, G:. i: etc. Drives are Network-attached volumes, specific to the situation of the screen shots (over here).

So we see a Drive C: and all the OS files are in there, in the root.

Prerequisite #1 :
The OS must be running "as" Drive C:.
You may wonder whether that can be different, but it sure can and if so, various functionalities do not anticipate that.

It has been said elsewhere, but only if your Explorer shows the situation as shown above, you can quite freely "manipulate" the files when needed (more about that in Tutorials elsewhere).

Now we are going to boot into one of the other OSes on the RAM-OS disk - and now we see this :

See it ?
Now Drive C: does not show the OS files any more. Actually this is a whole different Drive C: now; contents is different, all is different. It *Is* different.
What we saw previously (first screen shot above) we now find on Drive D: :

Compare with the first screen shot and you will agree.

Now watch out : You will see the above under Drive D: only when you just booted. Meaning : regardless of whether this was a boot from a BASE OS or from a RAM OS, this works as long as the HDD is still in. But remove it and you will only see the Drive C: of the screen shot above the last one (but see more below how to re-attach that).

Envision that in this last screen shot situation we booted from MyW10-10586 BASE.

Rule :
Most probably you can do what you want with the highlighted file you see, but it is VERY WRONG to do so. This is because right at this moment the OS runs from that very file.
This is how the general strict rule should get to you that once you booted into one of the other OSes than TRIAL, you should stay veray far away from touching the OS files you see above; you could be running from one of them and things will go wrong badly.
And for the Geeks amongst us : yes it is true that when you run from one of the Memory denoted (thus RAM) Oses, you can again do all what you want. In that case you don't run from any of the OSes you see in that list, because they are all the BASE versions (except the TRIAL version, which you don't see at all, but which *is* the first screen shot.
Still there ? wacko bzz

Prerequisite #2 :

Drive D: MUST be reserved for XXHighEnd and the Boot Menu operations, or otherwise nothing will work. This means that :

- At no circumstance you should allow anything to be named Drive D:.
But watch out with this, because this goes fairly unnoticed. Meaning :
When you in March 2015 ever connected a USB disk to the system and allowed it to be allocated to Drive D: (and which goes unnoticed) but now one year later you connect that disk while the RAM-OS disk is not in the system BUT you are going to attach that later (alwo see more below) then it will be named Drive E: or further down the line in the Alfabeth).
Now you can attach the RAM-OS disk what you want, but it won't be found as it is always looked for under Drive D:.
What this means is that for the future time being, you must watch for the Drive Letter which is assigned for ALL what you mount to the system, and as soon as you see a Drive D:, you must change that (this goes via Explorer - RightClick This PC - Manage - Storage - Disk Management ... normally available in Normal OS only).
If you neglect this, then there *will* be a day that you forgot and run into trouble once you need to save settings or whatever that requires access to the Permanent Storage (which is in the BASE files).

When you booted from a RAM OS (the Memory denoted ones) and you had the HDD removed from the system but want to put it back and "do something with it", then this applies :

1. Put it back in;
2. Start XXHighEnd and RightClick the Stop Button;
3. Choose Boot Into;
4. Press Cancel in there.

This will have caused the HDD to be mounted again and now you will see the Drive D: and you can access it.
There are more means which will automatically mount the RAM-OS HDD, but this is the simplest means without hassle.

Now on to "attaching" to one of the OSes, while being in another ...
Attaching : Connect to an Operating System File which thus contains a full Operating System and which you normally view from a Drive C: and which you now can view from another Drive Letter.
For us, this Drive Letter is always X:

The below assumes that we booted into TRIAL and that *thus* (think about this) the OS Files reside on C:.

Go to the Stop Button, RichtClick it :

... and choose one of the OSes shown in the sub menu at the right hand side.

Assumed we picked MyW10-10074 and this shows for result :

... we now have 10074 under our finger tips in Drive X: :

And you claim to be still there ?

Prerequisite #3 :

Drive X: is reserved for XXHighEnd and it is not allowed to have any other device allocated to Drive X: at any time.
If this happens after all, your settings will not be saved to permanent storage, when you shut down or reboot. Thus :
What we just performed explicitly, is performed internally exactly the same when your Settings need to be saved. That is, when the next is applied as well :

See the X: above the Mouse Pointer;
It is that Drive Letter which is used to Save Settings and which is no different from what you might be using already when using a RAM Disk (which RAM Disk is not the same at all as using the OS booted from RAM).

One last thing to watch out for :
If that X: shown in the last screen shot is a C: or something else, then STILL when you attach to another Operating System File (like we just did) that message "Asked for volume attached as Drive X:" appears. But now it is not for real and you can see it by the X: Drive not appearing in Explorer.
Read : If you can't find the X: Drive, the "Copy Settings to" field will not contain the X:. And :
This is the most correct for the TRIAL Operating System (it has no "external Permanent Storage" and "it can not boot from RAM".
wacko bzzwackowacko bzz

Prerequisite #4 :

Any Operating System that can be booted from RAM and which is about the BASE OSes you see in the Boot Menu, *NEEDS* to save to Drive X: and its XX folder as shown in the last screen shot.

And while we are at it anyway :

Prerequisite #5 :

Any OS which does not *HAVE* external persistent storage, because it is the storage itself, like our TRIAL OS, is NOT ALLOWED to have a Drive X: in mentioned field because it implies an anomaly (unjustified message that volume is attached etc.).

Last one :

Prerequisite #6 :

The XX folder of all the OSes involved on our RAM-OS disk, needs to be named exactly the same. This is for technical reasons of attaching and detaching and more.

N.b.: Detaching a previously explicitly attached OS is necessary because it implies "flusing" of the applied data; it is the same as we "eject" an USB drive etc.
The situations which imply automatic attaching will also (under the hood) automatically detach. However, when we attached explicitly ourselves like what we did above as our last exercise, requires explicit detaching just the same :

See at the mouse pointer and also notice the check mark in the left hand side of that menu (indicating that that OS file is now attached). Clicking that option and this should occur :

... and now you can remove the HDD from the system, if you like.

Last small note :
When the system just booted from RAM, you can freely remove the HDD. BUT :
When you did not Attach explicitly but used the "Boot into ..." menu option instead so that implies an attachment just the same, *and* you then change something somewhere on the HDD ... there is no explicit means to "flush" while Windows 10 does not understand that any HDD has been attached and the eject option is greyed out. This is a more dangerous situation and or you must let stay in the HDD or you must explicitly attach one of the OS volumes ("without reason") afterwards and then detach.

For the Stealth III LPS PC :
W10-14393.0 - July 17, 2021 (2.11)
XXHighEnd Mach III Stealth LPS PC -> Xeon Scalable 14/28 core with Hyperthreading On (set to 14/28 cores in BIOS and set to 10/20 cores via Boot Menu) @~660MHz, 48GB, Windows 10 Pro 64 bit build 14393.0 from RAM, music on LAN / Engine#4 Adaptive Mode / Q1/-/3/4/5 = 14/-/0/0/*1*/ Q1Factor = *4* / Dev.Buffer = 4096 / ClockRes = *10ms* / Memory = Straight Contiguous / Include Garbage Collect / SFS = *10.13*  (max 10.13) / not Invert / Phase Alignment Off / Playerprio = Low / ThreadPrio = Realtime / Scheme = Core 3-5 / Not Switch Processors during Playback = Off/ Playback Drive none (see OS from RAM) / UnAttended (Just Start) / Always Copy to XX Drive (see OS from RAM) / Stop Desktop, Remaining, WASAPI and W10 services / Use Remote Desktop / Keep LAN - Not Persist / WallPaper On / OSD Off (!) / Running Time Off / Minimize OS / XTweaks : Balanced Load = *62* / Nervous Rate = *1* / Cool when Idle = n.a / Provide Stable Power = 1 / Utilize Cores always = 1 / Time Performance Index = Optimal / Time Stability = Stable / Custom Filtering *Low* (16x) / Always Clear Proxy before Playback = On -> USB3 from MoBo -> Lush^3
A: W-Y-R-G, B: *W-G* USB 1m00 -> Phisolator 24/768 Phasure NOS1a/G3 75B (BNC Out) async USB DAC, Driver v1.0.4b (16ms) -> B'ASS Current Amplifier -> Blaxius*^2.5* A:B-G, B:B-G Interlink -> Orelo MKII Active Open Baffle Horn Speakers. ET^2 Ethernet from Mach III to Music Server PC (RDC Control).
Removed Switching Supplies from everywhere (also from the PC).

For a general PC :
W10-10586.0 - May 2016 (2.05+)
*XXHighEnd PC -> I7 3930k with Hyperthreading On (12 cores)* @~500MHz, 16GB, Windows 10 Pro 64 bit build 10586.0 from RAM, music on LAN / Engine#4 Adaptive Mode / Q1/-/3/4/5 = 14/-/1/1/1 / Q1Factor = 1 / Dev.Buffer = 4096 / ClockRes = 1ms / Memory = Straight Contiguous / Include Garbage Collect / SFS = 0.10  (max 60) / not Invert / Phase Alignment Off / Playerprio = Low / ThreadPrio = Realtime / Scheme = Core 3-5 / Not Switch Processors during Playback = Off/ Playback Drive none (see OS from RAM) / UnAttended (Just Start) / Always Copy to XX Drive (see OS from RAM) / All Services Off / Keep LAN - Not Persist / WallPaper On / OSD On / Running Time Off / Minimize OS / XTweaks : Balanced Load = *43* / Nervous Rate = 1 / Cool when Idle = 1 / Provide Stable Power = 1 / Utilize Cores always = 1 / Time Performance Index = *Optimal* / Time Stability = *Stable* / Custom Filter *Low* 705600 / -> USB3 *from MoBo* -> Clairixa USB 15cm -> Intona Isolator -> Clairixa USB 1m80 -> 24/768 Phasure NOS1a 75B (BNC Out) async USB DAC, Driver v1.0.4b (4ms) -> Blaxius BNC interlink *-> B'ASS Current Amplifier /w Level4 -> Blaxius Interlink* -> Orelo MKII Active Open Baffle Horn Speakers.
Removed Switching Supplies from everywhere.

Global Moderator
Pages: [1]
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.094 seconds with 20 queries.