Sure thing John! It's going to bug me for a while though - I'm a bit anal
;^o
On Mon, May 18, 2015 at 9:03 PM, John Hupp <free...@prpcompany.com> wrote:
> I also tried, by the way, mscdex + uide.sys, which did not work.
>
> Thanks, Don, for working with me all the way through and contributing many
> good ideas!
>
>
> On 5/18/2015 5:33 PM, John Hupp wrote:
>
> Continuing to think in other directions at the moment, I tried mscdex + a
> cdrom driver of unknown origin named ide-cd.sys (dated 1998). Those two
> worked.
>
> Then I tried shsucdx + ide-cd.sys and those two worked.
>
> I wish I knew the origin of ide-cd.sys (or maybe I don't want to know),
> but I'm ready to call this the best and cleanest solution on this rig.
> Maybe I can do better on my next build.
>
> On 5/18/2015 4:58 PM, John Hupp wrote:
>
> It seems that the latest xcdrom.sys (which I have been using) is the same
> version as on a Freedos 1.0 install I had some long time ago. But the
> current shsucdx is 2011 instead of 2006 on Freedos 1.0.
>
> So I tried the same xcdrom + shsucdx pair copied from that working
> install. But it produces the same error as originally reported without the
> redundant pairs of commands workaround.
>
> On 5/18/2015 4:32 PM, John Hupp wrote:
>
> I rem'ed out the uide.sys line after both the original and the latest
> available update yielded the same error. After that I began working on the
> best setup with the last xcdrom.sys.
>
> I've been assuming that we are dealing with uide/xcdrom bugs here rather
> than a shsucdx bug.
>
> I have not tried any other cdrom drivers or cdx programs.
>
> On 5/18/2015 4:14 PM, Don Flowers wrote:
>
> are you using only xcrdom.sys or combining it with UIDE or UDVD? I prefer
> UIDE instead of xcdrom.sys on my IDE drives, and on one of my quirkier
> machines shsucdx doesn't work but shcdx86.com does.
>
> On Mon, May 18, 2015 at 4:02 PM, John Hupp <free...@prpcompany.com> wrote:
>
>> You're right, I get exactly the same result if I rem out that line.
>>
>> I then arrive at this as the most economical working configuration:
>>
>> =======================
>> REM (some commands)
>>
>> SHSUCDX /QQ /D3
>>
>> REM (some commands)
>>
>> DEVLOAD /Q /H C:\FDOS\BIN\XCDROM.SYS /D:FDCD0001 /H
>> SHSUCDX /D:FDCD0001,X /Q
>>
>> DEVLOAD /Q /H C:\FDOS\BIN\XCDROM.SYS /D:FDCD0001 /H
>> SHSUCDX /D:FDCD0001,X /Q
>> =======================
>>
>> But SHSUCDX /D then reports X: and Y: as the drive assignments, and only
>> Y: works. X: produces the error I first reported.
>>
>> So it's not entirely clean and clear, but have I just arrived at the best
>> workaround?
>>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
