Re: [Freedos-user] Problem with UIDE

[Bernd Blaauw]

Op 19-5-2011 2:28, Alain Mouette schreef:
> I managed to make a Boot CD that works almost in all machines. The only
> one that is not working is "Virtual PC 2007". it locks uppun execution
> of JEMM386 from a CD image. XMGR is used because it is required by UIDE.

Technically UIDE doesn't require XMS nor an XMS manager if omitting the 
caching function.
The /N1 /N3 /B parameters should do fine, for example perform a F5 clean 
boot, then:
DEVLOAD UIDE.SYS /D:FDCD0001 /N1 /N3 /B



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Alain Mouette]

Hi Japheth,

I am glad that you are here, it is nice to have our little family 
mantaining contact.

I managed to make a Boot CD that works almost in all machines. The only 
one that is not working is "Virtual PC 2007". it locks uppun execution 
of JEMM386 from a CD image. XMGR is used because it is required by UIDE.

Image of the screen: 

Image of the CD that I used: 


The problem only happens booting from the ISO, and my problem is making 
a distribution CD with FreeDOS...

Alain

Em 18-05-2011 02:05, japhethx gmail escreveu:
>> 1). NOEMS is rarely used, and a lot of things don't handle it well.
> ...
>   >  ... I wouldn't do this. Just load a XMS
>> driver only (and not via "NOEMS").
>
> NOEMS is ok and safe, the switch which causes problems with some programs is
> FRAME=NONE.
>
>> 2). Actually, I've noticed JEMM386 will hang if you aren't careful,
>> esp. on newer machines due to memory conflicts.
>
> True. In v5.74, there's a tool MEMSTAT which will tell what parts of the
> BIOS-ROM region ( which is E000-, not just F000- ) are to be excluded
> to be safe.

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[japhethx gmail]

> 1). NOEMS is rarely used, and a lot of things don't handle it well.
...
 > ... I wouldn't do this. Just load a XMS
> driver only (and not via "NOEMS").

NOEMS is ok and safe, the switch which causes problems with some programs is 
FRAME=NONE.

> 2). Actually, I've noticed JEMM386 will hang if you aren't careful,
> esp. on newer machines due to memory conflicts.

True. In v5.74, there's a tool MEMSTAT which will tell what parts of the 
BIOS-ROM region ( which is E000-, not just F000- ) are to be excluded 
to be safe.


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE: Solved

[Alain Mouette]

Thanks to all of you that have helped me with this problem. It could 
have taken ages to test and understand what was happening...


Many Thanks to Eric Auer who had a LOT of patience with me, I manage to 
make it run. So here is my minimalistic setup. I hope that someone can 
publish it somewhere...


1) Have a directory with the all the CD content, let's call it 
/mnt/dados/CDROM, inside it create a single directory called 
"*isolinux*" (I was not able to change it's name)


2) Have a bootable floppy, that includes the CDROM driver. Create an 
image in the .../CDROM/FreeDOS directory with

*dd if=/dev/fd0 of=FreeDOS.img*

3) Download Syslinux from 
, in a temporary 
directory. Copy the files core/*isolinux.bin* and memdisk/*memdisk* into 
the .../CDROM/isolinux directory (no subdirectories).


4) in the isolinux directory create this *isolinux.cfg* simple file
---isolinux.cfg
*default FreeDOS
label FreeDOS
kernel /isolinux/memdisk
append initrd=/FreeDOS/FreeDOS.img
*--

5) create the .ISO with mkisofs:
*mkisofs  -R -v -V FreeDOS-1.x   \
-b isolinux/isolinux.bin -c isolinux/boot.cat\
-no-emul-boot -boot-load-size 4 -boot-info-table \
-o /mnt/dados/FreeDOS-1.x.iso\
/mnt/dados/CDROM
*
That is all folks, I am amazed how this simple thing gets overly complex 
in all explanations in the internet!!!


Alain

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Single Stage to Orbit]

On Tue, 2011-05-17 at 19:04 +0200, Bernd Blaauw wrote:

> JEMM is at 5.74 

Thanks for that one, switching to JEMMEX just solved a problem where
Bochs would barf if EMM386.EXE was loaded. 
-- 
Tactical Nuclear Kittens



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Jack]

Alain et al,

>> I do need as much conventional memory as I can get, and even the it is a
>> tight fit...
>>
>> So everyone belives that
>>   JEMM386 X=TEST NOEMS
>> is safer? if so, I will change...
>
> My point was that ACPI tables (and/or too aggressive searching by FD
> [J]EMM386?) makes it necessary to either avoid X= I= or use both with
> "=TEST". At least, from my limited experience, that's the case. It's
> worth a try, at least, but who knows honestly.   :-P

For the record, I use V6.22 MS-DOS (compatible with my equally
old V4.0 Windows/NT!), and I have always loaded JEMM386 with a
NOEMS command.   No problem!   Seems to work O.K., as I expect
it should, since I run no "VERY old" EMS programs!

In your case, if "conventional" memory is a concern but upper-
memory is not, you can try loading JEMM386/JEMMEX like this:

DEVICE=C:\DOS\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS

This specifically tells JEM386/JEMMEX to "map" upper-memory in
only the "monochrome video" (black-and-white) graphics area at
B000h thru B7FFh, which nobody uses now due to COLOR displays!
All other upper-memory address space, C800h thru EFFFh, is NOT
used, due to the X= and NOEMS commands.This gives you only
32K of upper-memory, but it may be SAFER than I=TEST, etc.

Also, as you can see Lucho doing in his "boot" diskettes, what
about providing users the CHOICE of loading JEMM386/JEMMEX, or
UMBPCI?   Although UMBPCI cannot run on "absolutely" all chip-
sets and mainboards, it has never "failed" me or others in its
memory-test procedures.   Might SAVE your CD "boot" scheme, on
a system that otherwise cannot use JEMM386/JEMMEX.

Jack R. Ellis


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Bernd Blaauw]

Op 17-5-2011 20:41, Alain Mouette schreef:
> Well, so it is a BIOS bug, and that is the end of research in this
> direction...
>
> Either syslinux (that seems to be better but for which I need help) or
> RDISK+SUBST (that I know, but may be a bit clumsy)

ok, made a very basic ISO generation batchfile, as DOS ports of MKISOFS 
(or GENISOIMAGE) exist, whatever floats your boat :)
Hopefully you can see the directory structure from it, as well as how to 
call MKISOFS (both your and my method)
Not going to post isolinux.cfg here, can be a pretty long textfile. I'll 
test if the ISOs work sometime tomorrow.

Bernd


@echo off
if "%1"=="" goto help
goto verify
:verify
for %%x in ( %1 %1\CONTENTS %1\CONTENTS\ISOLINUX ) do if not exist 
%%x\NUL MD %%x
if exist %1\CONTENTS\ISOLINUX\NUL goto filecopy
echo Failed to create directory structure at %1
goto end

:filecopy
for %%x in ( isolinux.bin isolinux.cfg memdisk fdboot.img ) do if not 
exist %1\CONTENTS\ISOLINUX\%%x copy A:\%%x %1\CONTENTS\ISOLINUX\%%x
if not exist %1\CONTENTS\ISOLINUX\FREEDOS.IMG a:\diskcopy A: 
%1\CONTENTS\ISOLINUX\FREEDOS.IMG /o /x /d
goto branch

:branch
CDD %1
for %%x in ( *.iso ) do del %%x
if "%2"=="" goto direct
goto isolinux

:direct
echo Creating bootable ISO9660 image, using 1.44MB Floppy Emulation mode
a:\mkisofs -b isolinux/freedos.img -o %1\cd1.iso contents
goto succes

:isolinux
echo Creating bootable ISO9660 image, using Syslinux and 360KB image file
a:\mkisofs -no-emul-boot -b isolinux/isolinux.bin -o c%1\cd1.iso contents
goto succes

:succes
echo Bootable ISO9660 file created succesfully as %1\CD1.ISO
CDD -
goto end

:help
echo Please run this file as follows:
echo.
echo %0 [directory] [isolinux]
echo.
echo Where directory is any new or existing directory on harddisk or 
ramdisk.
echo example #1 : %0 C:\CDTEST   (uses floppy emulation for BootCD)
echo example #2 : %0 C:\CDTEST ISOLINUX  (creating no-emulation for BootCD)
echo.
goto end

:end


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Rugxulo]

Hi,

On Tue, May 17, 2011 at 3:15 PM, Alain Mouette  wrote:
> (top posting to make it shorter)
>
> I do need as much conventional memory as I can get, and even the it is a
> tight fit...
>
> So everyone belives that
>   JEMM386 X=TEST NOEMS
> is safer? if so, I will change...

My point was that ACPI tables (and/or too aggressive searching by FD
[J]EMM386?) makes it necessary to either avoid X= I= or use both with
"=TEST". At least, from my limited experience, that's the case. It's
worth a try, at least, but who knows honestly.   :-P

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Bernd Blaauw]

Op 17-5-2011 20:41, Alain Mouette schreef:

Alain, can I privately send you a complete disk image sometime tomorrow 
by email? Would be 1.44MB, maybe slightly smaller if compressing first.
It would replace your own floppy image directly, you can still use your 
own method of ISO generating.
Basicly it ends up with BIOS --> CD --> 1.44MB image --> Syslinux --> 
Memdisk loading 360KB image as A:
As the 1.44MB image was loaded as well as boot image, I guess it will 
end up as B:.
However, current testing shows that recent FreeDOS kernel + recent 
Syslinux/Memdisk seems to trash access to B:, not related to JEMM, UIDE 
or whatever. Getting an abort/retry/fail.
Access to the data part of CD should be fine though.

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Eric Auer]

Hi Alain,

> (I hope this messags comes though, 5th try...)

One got automatically blocked because it had a (too big)
attachment, and I think that is good. I see you already
transferred the same information without attachments :-)

Eric


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Eric Auer]

Jack,

>> ==>> so, imho, the drive A: is disapearing when UIDE is loaded. It looks
>> like an interaction between the BIOS boot driver that creates A: for the
>> CD boot image and UIDE :(
> 
> I wrote UIDE to be a "standard" system driver, not a "CD boot" driver,
> and I was unaware that BIOS "CD boot" drivers set the CD to be used as
> the A: drive.   How they do this, and what hardware access schemes are
> used, are unknown to me.   So, I am not surprised that the BIOS "boot"
> driver conflicts with UIDE, if both run on the same system.

The BIOS CD boot system can be accessed via an int 13 extension
so it should be easy to get status information. However, if you
look at the (syslinux related) memdisk / isolinux / eltorito.sys
driver source codes, you see that BIOSes tend to have (sort of)
messy implementations of something which could be easy: You have
a floppy image on the CD/DVD and that mimicks, with BIOS help,
the A: drive. As it is typically used to boot "big" OSes which
do not use much of the BIOS, switching back to accessing actual
floppies might be broken. Also, there might be an interaction
between whether or not you have an actual floppy drive, too.



Alain, a safer way to boot with a virtual boot floppy might be to
use ISOLINUX with MEMDISK. The latter loads "like a Linux kernel"
(from the view of the ISOLINUX boot loader) and then loads a disk
image (e.g. floppy, can even be GZIP compressed etc) and BOOTS it.

As booting happens only after loading the floppy into RAM (hence
the name memdisk) you do not have to worry about breaking access
to the BIOS CD/DVD boot system by loading DOS drivers later. Also
nice is the fact that the MEMDISK ramdisk will be writeable, so
you can put temp files there. Of course they are lost on reboot.

Regards, Eric

PS: You can also use the mentioned eltorito.sys driver (tiny) to
access the CD/DVD with BIOS support, but as that only works when
you booted from that CD/DVD, you may want to ignore this and use
UIDE as CD/DVD in all situations, or select in a config sys menu.



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Alain Mouette]

(top posting to make it shorter)

I do need as much conventional memory as I can get, and even the it is a 
tight fit...

So everyone belives that
   JEMM386 X=TEST NOEMS
is safer? if so, I will change...

Thanks,
Alain

Em 17-05-2011 16:35, Rugxulo escreveu:
> Hi,
>
> On Tue, May 17, 2011 at 10:45 AM, Alain Mouette  wrote:
>>
>> I am encountering a strange problem with UIDE. It happens with some
>> machines but not all, one of the failing machine is nearby so I can make
>> more tests easely...
>>
>> I am using UIDE and XMGR from 10-May-11, I made my config from your
>> example (whole file attached), jemm386 is 572 dated 13mar2008 (complete
>> config at the end):
>> device=a:\dos\xmgr.sys /B
>> device=a:\dos\jemm386.exe I=TEST NOEMS
>> device=a:\dos\xmgr.sys
>> device=a:\dos\uide.sys /D:CDROM
>>
>> It works ok booting from floppy and from hard-disk, but it does not work
>> when booting from the CDROM. It stops with this screen and the HD led on:
>> 
>
> Definitely try latest JEMM386 5.74, but honestly, I think the problem
> is two-fold (blindly guessing, so I could be wrong):
>
> 1). NOEMS is rarely used, and a lot of things don't handle it well. I
> think this means VCPI is still available as well as UMBs but not EMS.
> In other words, I guess? you're trying to save precious conventional
> memory by using JEMM386 while only using XMS (no EMS). Honestly,
> unless you really *need* that much conventional memory free (unlikely,
> as FreeDOS is pretty efficient), I wouldn't do this. Just load a XMS
> driver only (and not via "NOEMS").
>
> 2). Actually, I've noticed JEMM386 will hang if you aren't careful,
> esp. on newer machines due to memory conflicts. In particular, your
> "I=TEST" parameter is pretty dangerous. I think typically it works
> better if you do "X=TEST I=TEST" (or maybe even not at all). Lemme
> search my old mails for a sec ...
>
> Apparently, BioMenace (DOS game, now freeware, see 3D Realms site)
> needs both EMS (hence EMM386) and XMS and (at least for my other,
> older P4) "X=TEST I=TEST NORAM". Normal JEMM386 loading just hung, and
> anything else didn't give it enough EMS to load to E1L3 without
> crashing the program due to insufficient memory. I blame ACPI, natch.
>
> P.S. Maybe I'm way off, and I know you're talking about a vaguely
> different problem, but just keep in mind, EMM386 can be tricky on
> newer hardware with weird memory configs (ACPI). That's the whole
> point I was trying to make, however futile it may seem. (You can also
> run "JEMM386 LOAD" at any time but that doesn't give you UMBs. JEMMEX
> doesn't let you run as pure XMS only.)
>
> --
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Christian Masloch]

> You can also
> run "JEMM386 LOAD" at any time but that doesn't give you UMBs.

A program modifying DOS's internal data which could effectively link in  
new UMBs is easy enough to write, provided that the kernel's handling of  
the UMA is compatible enough to that of the MS-DOS kernel.

Regards,
Christian

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Rugxulo]

Hi,

On Tue, May 17, 2011 at 10:45 AM, Alain Mouette  wrote:
>
> I am encountering a strange problem with UIDE. It happens with some
> machines but not all, one of the failing machine is nearby so I can make
> more tests easely...
>
> I am using UIDE and XMGR from 10-May-11, I made my config from your
> example (whole file attached), jemm386 is 572 dated 13mar2008 (complete
> config at the end):
> device=a:\dos\xmgr.sys /B
> device=a:\dos\jemm386.exe I=TEST NOEMS
> device=a:\dos\xmgr.sys
> device=a:\dos\uide.sys /D:CDROM
>
> It works ok booting from floppy and from hard-disk, but it does not work
> when booting from the CDROM. It stops with this screen and the HD led on:
> 

Definitely try latest JEMM386 5.74, but honestly, I think the problem
is two-fold (blindly guessing, so I could be wrong):

1). NOEMS is rarely used, and a lot of things don't handle it well. I
think this means VCPI is still available as well as UMBs but not EMS.
In other words, I guess? you're trying to save precious conventional
memory by using JEMM386 while only using XMS (no EMS). Honestly,
unless you really *need* that much conventional memory free (unlikely,
as FreeDOS is pretty efficient), I wouldn't do this. Just load a XMS
driver only (and not via "NOEMS").

2). Actually, I've noticed JEMM386 will hang if you aren't careful,
esp. on newer machines due to memory conflicts. In particular, your
"I=TEST" parameter is pretty dangerous. I think typically it works
better if you do "X=TEST I=TEST" (or maybe even not at all). Lemme
search my old mails for a sec ...

Apparently, BioMenace (DOS game, now freeware, see 3D Realms site)
needs both EMS (hence EMM386) and XMS and (at least for my other,
older P4) "X=TEST I=TEST NORAM". Normal JEMM386 loading just hung, and
anything else didn't give it enough EMS to load to E1L3 without
crashing the program due to insufficient memory. I blame ACPI, natch.

P.S. Maybe I'm way off, and I know you're talking about a vaguely
different problem, but just keep in mind, EMM386 can be tricky on
newer hardware with weird memory configs (ACPI). That's the whole
point I was trying to make, however futile it may seem. (You can also
run "JEMM386 LOAD" at any time but that doesn't give you UMBs. JEMMEX
doesn't let you run as pure XMS only.)

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Alain Mouette]

Well, so it is a BIOS bug, and that is the end of research in this 
direction...

Either syslinux (that seems to be better but for which I need help) or 
RDISK+SUBST (that I know, but may be a bit clumsy)

Thanks,
Alain

Em 17-05-2011 15:05, Jack escreveu:
>
> Alain,
>
>> I just foud how to make it work (kind of...)
>>
>> I boot normally, single-stepping, loading all *except UIDE*, than I do:
>> SET COMSPEC=C:\COMMAND.COM   (it's the same)
>> C:
>> DEVLOAD A:\DOS\UIDE.SYS /D:CDROM
>>
>> it loads, and I can access drive C:, but if I access A: it locks just
>> the same, with the HardDisk led on.
>>
>> ==>>  so, imho, the drive A: is disapearing when UIDE is loaded. It looks
>> like an interaction between the BIOS boot driver that creates A: for the
>> CD boot image and UIDE :(
>
> I wrote UIDE to be a "standard" system driver, not a "CD boot" driver,
> and I was unaware that BIOS "CD boot" drivers set the CD to be used as
> the A: drive.   How they do this, and what hardware access schemes are
> used, are unknown to me.   So, I am not surprised that the BIOS "boot"
> driver conflicts with UIDE, if both run on the same system.
>
> If you still want to use UIDE (or UIDEJR) in your CD download process,
> you can load it as follows --
>
>  DEVICE[HIGH]=C:\DOS\UIDE.SYS /N2
>
> The /N2 switch tells UIDE not to handle any CD/DVD drives, thus you do
> not need a /D: switch either.   This should allow your "boot" A: drive
> to go on being used.After users have downloaded all they need from
> your CD, they can then change UIDE to handle regular files from the CD
> by getting rid of /N2 and re-adding a /D: device name.
>
> Jack R. Ellis
>
>
> --
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Alain Mouette]

Em 17-05-2011 14:04, Bernd Blaauw escreveu:
>
> I've recently encountered the same issue, not sure if it's purely
> limited to booting from CD-ROM.
> In my case I tend to use Syslinux -->  Memdisk -->  Disk Image ( -->
> bootsector -->  kernel -->  config.sys -->  shell -->  autoexec.bat -->
> commandline)

Do you mean that this should work, or this from your other message:

 > Most fun part is having your floppy image, which contains Syslinux
 > and a smaller floppy image. Then you'd have CD -->  1.44MB image -->
 >  Syslinux -->  small image

In either case, is there a clear tutorial about how to make it? I did a 
little digging with google, but most syslinux explanations are unclear, 
complex and for other situations :(

> 1) Does loading everything except UIDE work for you?

Yes

> 2) Does loading everything except UIDE work for you, if you later load
> UIDE from the commandline? DEVLOAD UIDE.SYS /D:CDROM

Lock the same, if I change comspec it works intill i try to use A:

> 3) If you replace the XMGR/JEMM386/XMGR by Japhet's JEMMEX, does that
> work? ofcourse still load UIDE from config.sys

No difference

> 4) If you replace the XMGR/JEMM386/XMGR by Japhet's HIMEMX + JEMM386,
> does that work? ofcourse still load UIDE from config.sys

Will do it today

> 5) Does the same behaviour happen under MSDOS? Slightly more difficult
> question ofcourse, but FreeDOS kernel/shell occasionally is easy to
> hang/crash, SHELLHIGH is a culprit at times, for example.

withou any dos high the result does not change...

> I think JEMM is at 5.74 by now, can't hurt to use latest version I guess.

Found it! it is not mirired ad ibiblio...
I will test it today

Thanks,
Alain

>
> This should work:
> DEVICE=A:\DOS\HIMEMX.EXE
> DEVICE=A:\DOS\JEMM386.EXE I=TEST NOEMS
> DEVICE=A:\DOS\UIDE.SYS /D:CDROM
> DOS=HIGH,UMB
> DOSDATA=UMB
>
> Or:
> DEVICE=A:\DOS\JEMMEX.EXE I=TEST NOEMS
> DEVICE=A:\DOS\UIDE.SYS /D:CDROM
> DOS=HIGH,UMB
> DOSDATA=UMB

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Alain Mouette]

Em 17-05-2011 14:02, Tom Ehlert escreveu:
> Hi Alain,
>
> most likely UIDE disturbs the BIOS boot drive emulation
> I have no idea if UIDE can work around this.
>
> you can work around this by
>
> create a virtual disk
> copy A: to virtual disk (including autoexec.bat)
> so that A: is no longer needed
>
> execute autoexec.bat from virtual disk
>
> only then
>DEVLOAD a:\dos\uide.sys /D:CDROM

Yes, that is consistent with my last experiment, How do you recomend to 
create a RAMdisk and use it as A: ?

I know there are a few options, but which one will work better with 
FreeDOS, specialy that I have to create it with another letter, fill it 
up, change it to A: later on ??

Alain

>
>
>
> am 17. Mai 2011 um 17:45 schrieben Sie:
>
>> Hi Jack,
>
>> (I hope this messags comes though, 5th try...)
>
>> I am encountering a strange problem with UIDE. It happens with some
>> machines but not all, one of the failing machine is nearby so I can make
>> more tests easely...
>
>> I am using UIDE and XMGR from 10-May-11, I made my config from your
>> example (whole file attached), jemm386 is 572 dated 13mar2008 (complete
>> config at the end):
>> device=a:\dos\xmgr.sys /B
>> device=a:\dos\jemm386.exe I=TEST NOEMS
>> device=a:\dos\xmgr.sys
>> device=a:\dos\uide.sys /D:CDROM
>
>> It works ok booting from floppy and from hard-disk, but it does not work
>> when booting from the CDROM. It stops with this screen and the HD led on:
>> 
>
>> Please help, I am trying to make a universal installer...
>
>> Alain
>> --
>
>> menucolor=10
>> menu
>> menu ┌───┐
>> menu │ Disco de instalaçäo do FreeDOS │
>> menu │ │
>> menu │ │
>> menu │ │
>> menu │ 1. Driver de CD: UIDE (padräo) │
>> menu │ 2. Sem CD-ROM │
>> menu │ │
>> menu └───┘
>> menu
>> menudefault=1,5
>
>> 1? echo Driver: UIDE
>> 2? echo Driver: Sem CD
>
>> screen=0x12
>> dos=high,umb
>> buffers=15,0
>> files=100
>> fcbs=4,0
>> lastdrive=Z
>
>> 1? device=a:\dos\xmgr.sys /B
>> 1? device=a:\dos\jemm386.exe I=TEST NOEMS
>> 1? device=a:\dos\xmgr.sys
>> 1? device=a:\dos\uide.sys /D:CDROM
>
>> 2? device=a:\dos\himem.exe
>> 2? device=a:\dos\emm386.exe NOEMS X=TEST
>
>> country=055,850,a:\dos\country.sys
>> shell=A:\command.com A:\ /E:1300 /p

>
> Mit freundlichen Grüßen/Kind regards
> Tom Ehlert

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Jack]

Alain,

> I just foud how to make it work (kind of...)
>
> I boot normally, single-stepping, loading all *except UIDE*, than I do:
>SET COMSPEC=C:\COMMAND.COM   (it's the same)
>C:
>DEVLOAD A:\DOS\UIDE.SYS /D:CDROM
>
> it loads, and I can access drive C:, but if I access A: it locks just
> the same, with the HardDisk led on.
>
> ==>> so, imho, the drive A: is disapearing when UIDE is loaded. It looks
> like an interaction between the BIOS boot driver that creates A: for the
> CD boot image and UIDE :(

I wrote UIDE to be a "standard" system driver, not a "CD boot" driver,
and I was unaware that BIOS "CD boot" drivers set the CD to be used as
the A: drive.   How they do this, and what hardware access schemes are
used, are unknown to me.   So, I am not surprised that the BIOS "boot"
driver conflicts with UIDE, if both run on the same system.

If you still want to use UIDE (or UIDEJR) in your CD download process,
you can load it as follows --

DEVICE[HIGH]=C:\DOS\UIDE.SYS /N2

The /N2 switch tells UIDE not to handle any CD/DVD drives, thus you do
not need a /D: switch either.   This should allow your "boot" A: drive
to go on being used.After users have downloaded all they need from
your CD, they can then change UIDE to handle regular files from the CD
by getting rid of /N2 and re-adding a /D: device name.

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Bernd Blaauw]

Op 17-5-2011 19:40, Alain Mouette schreef:
> I boot normaly, single-stepping, loading all *except IEDE*, than I do:
> SET COMSPEC=C:\COMMAND.COM   (it's the same)
> C:
> DEVLOAD A:\DOS\UIDE.SYS /D:CDROM
>
> it loads, and I can access drive C:, but if I access A: it locks just
> the same, with the HardDisk led on.
>
> ==>>  so, imho, the drive A: is disapearing when UIDE is loaded. It looks
> like an iteraction between the BIOS boot driver which creates A: for the
> CD boot image and UIDE :(
>
> For reference, I created the iso in Lunix with:
> mkisofs -pad -R -v -A "FreeDOS" -b FreeDOS/FreeDOS.img -V FreeDOS-c11 -o
> /mnt/dados/Segurver/FreeDOS-c11.iso /mnt/dados/CDROM

Ouch, it seems like you're creating a CD with read-only 
floppy-emulation, which means your floppy is a part of the CD that is read.
I guess CD drivers might reset the layout or something of the floppy 
part, causing DOS to no longer being able to find that floppy part in 
the location where it's expected.
The FreeDOS CD, as well as most Linux CDs, have been using ISOLINUX 
(from SYSLINUX program) for quite a few years now, along with the 
MEMDISK program which makes sure you get a writeable A: in system memory.
Basicly it copies the floppy image to RAM.

If you boot with F5 , skipping all drivers, then DEVLOAD A:\DOS\UIDE.SYS 
/N1 /N3 /B /D:CDROM , does everything work?
And does everything work if changing memory drivers like I suggested?

Another option is using a RAMDISK yourself, which means:
1) Load XMS driver ( anyone know a decent ramdisk driver for 
conventional memory ramdisks? never had much luck with TDSK)
2) Copy files to it
3) Set comspec to it
4) Continue batch file
5) Load UIDE driver

However it still doesn't guarantee A: will remain readable.

Most fun part is having your floppy image, which contains Syslinux and a 
smaller floppy image. Then you'd have CD --> 1.44MB image --> Syslinux 
--> small image

In short, I'm not sure if read-only floppy-emulation is supposed to 
remain usable after loading a CD driver. Only CD I know which uses it is 
the Windows 98 installation CD.

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Alain Mouette]

Hi Bernd, Hi Jack,

Em 17-05-2011 14:04, Bernd Blaauw escreveu:
> Op 17-5-2011 17:45, Alain Mouette schreef:
>> I am using UIDE and XMGR from 10-May-11, I made my config from your
>> example (whole file attached), jemm386 is 572 dated 13mar2008 (complete
>> config at the end):
>> device=a:\dos\xmgr.sys /B
>> device=a:\dos\jemm386.exe I=TEST NOEMS
>> device=a:\dos\xmgr.sys
>> device=a:\dos\uide.sys /D:CDROM
>>
>> It works ok booting from floppy and from hard-disk, but it does not work
>> when booting from the CDROM. It stops with this screen and the HD led on:
>> 
>>
>> Please help, I am trying to make a universal installer...
>
> Alain,
>
> I've recently encountered the same issue, not sure if it's purely
> limited to booting from CD-ROM.
> In my case I tend to use Syslinux -->  Memdisk -->  Disk Image ( -->
> bootsector -->  kernel -->  config.sys -->  shell -->  autoexec.bat -->
> commandline)
>
> 1) Does loading everything except UIDE work for you?
> 2) Does loading everything except UIDE work for you, if you later load
> UIDE from the commandline? DEVLOAD UIDE.SYS /D:CDROM
> 3) If you replace the XMGR/JEMM386/XMGR by Japhet's JEMMEX, does that
> work? ofcourse still load UIDE from config.sys
> 4) If you replace the XMGR/JEMM386/XMGR by Japhet's HIMEMX + JEMM386,
> does that work? ofcourse still load UIDE from config.sys
> 5) Does the same behaviour happen under MSDOS? Slightly more difficult
> question ofcourse, but FreeDOS kernel/shell occasionally is easy to
> hang/crash, SHELLHIGH is a culprit at times, for example.
>
> I think JEMM is at 5.74 by now, can't hurt to use latest version I guess.
>
> This should work:
> DEVICE=A:\DOS\HIMEMX.EXE
> DEVICE=A:\DOS\JEMM386.EXE I=TEST NOEMS
> DEVICE=A:\DOS\UIDE.SYS /D:CDROM
> DOS=HIGH,UMB
> DOSDATA=UMB
>
> Or:
> DEVICE=A:\DOS\JEMMEX.EXE I=TEST NOEMS
> DEVICE=A:\DOS\UIDE.SYS /D:CDROM
> DOS=HIGH,UMB
> DOSDATA=UMB

I just foud how to make it work (kind of...)

I boot normaly, single-stepping, loading all *except IEDE*, than I do:
   SET COMSPEC=C:\COMMAND.COM   (it's the same)
   C:
   DEVLOAD A:\DOS\UIDE.SYS /D:CDROM

it loads, and I can access drive C:, but if I access A: it locks just 
the same, with the HardDisk led on.

==>> so, imho, the drive A: is disapearing when UIDE is loaded. It looks 
like an iteraction between the BIOS boot driver which creates A: for the 
CD boot image and UIDE :(

For reference, I created the iso in Lunix with:
mkisofs -pad -R -v -A "FreeDOS" -b FreeDOS/FreeDOS.img -V FreeDOS-c11 -o 
/mnt/dados/Segurver/FreeDOS-c11.iso /mnt/dados/CDROM

Thanks,
Alain


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Tom Ehlert]

Hi Alain,

most likely UIDE disturbs the BIOS boot drive emulation
I have no idea if UIDE can work around this.

you can work around this by

   create a virtual disk
   copy A: to virtual disk (including autoexec.bat)
   so that A: is no longer needed

   execute autoexec.bat from virtual disk

   only then
  DEVLOAD a:\dos\uide.sys /D:CDROM

Tom



am 17. Mai 2011 um 17:45 schrieben Sie:

> Hi Jack,

> (I hope this messags comes though, 5th try...)

> I am encountering a strange problem with UIDE. It happens with some 
> machines but not all, one of the failing machine is nearby so I can make
> more tests easely...

> I am using UIDE and XMGR from 10-May-11, I made my config from your 
> example (whole file attached), jemm386 is 572 dated 13mar2008 (complete
> config at the end):
> device=a:\dos\xmgr.sys /B
> device=a:\dos\jemm386.exe I=TEST NOEMS
> device=a:\dos\xmgr.sys
> device=a:\dos\uide.sys /D:CDROM

> It works ok booting from floppy and from hard-disk, but it does not work
> when booting from the CDROM. It stops with this screen and the HD led on:
> 

> Please help, I am trying to make a universal installer...

> Alain
> --

> menucolor=10
> menu
> menu ┌───┐
> menu │ Disco de instalaçäo do FreeDOS │
> menu │ │
> menu │ │
> menu │ │
> menu │ 1. Driver de CD: UIDE (padräo) │
> menu │ 2. Sem CD-ROM │
> menu │ │
> menu └───┘
> menu
> menudefault=1,5

> 1? echo Driver: UIDE
> 2? echo Driver: Sem CD

> screen=0x12
> dos=high,umb
> buffers=15,0
> files=100
> fcbs=4,0
> lastdrive=Z

> 1? device=a:\dos\xmgr.sys /B
> 1? device=a:\dos\jemm386.exe I=TEST NOEMS
> 1? device=a:\dos\xmgr.sys
> 1? device=a:\dos\uide.sys /D:CDROM

> 2? device=a:\dos\himem.exe
> 2? device=a:\dos\emm386.exe NOEMS X=TEST

> country=055,850,a:\dos\country.sys
> shell=A:\command.com A:\ /E:1300 /p


> --
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Bernd Blaauw]

Op 17-5-2011 17:45, Alain Mouette schreef:
> I am using UIDE and XMGR from 10-May-11, I made my config from your
> example (whole file attached), jemm386 is 572 dated 13mar2008 (complete
> config at the end):
> device=a:\dos\xmgr.sys /B
> device=a:\dos\jemm386.exe I=TEST NOEMS
> device=a:\dos\xmgr.sys
> device=a:\dos\uide.sys /D:CDROM
>
> It works ok booting from floppy and from hard-disk, but it does not work
> when booting from the CDROM. It stops with this screen and the HD led on:
> 
>
> Please help, I am trying to make a universal installer...

Alain,

I've recently encountered the same issue, not sure if it's purely 
limited to booting from CD-ROM.
In my case I tend to use Syslinux --> Memdisk --> Disk Image ( --> 
bootsector --> kernel --> config.sys --> shell --> autoexec.bat --> 
commandline)

1) Does loading everything except UIDE work for you?
2) Does loading everything except UIDE work for you, if you later load 
UIDE from the commandline? DEVLOAD UIDE.SYS /D:CDROM
3) If you replace the XMGR/JEMM386/XMGR by Japhet's JEMMEX, does that 
work? ofcourse still load UIDE from config.sys
4) If you replace the XMGR/JEMM386/XMGR by Japhet's HIMEMX + JEMM386, 
does that work? ofcourse still load UIDE from config.sys
5) Does the same behaviour happen under MSDOS? Slightly more difficult 
question ofcourse, but FreeDOS kernel/shell occasionally is easy to 
hang/crash, SHELLHIGH is a culprit at times, for example.

I think JEMM is at 5.74 by now, can't hurt to use latest version I guess.

This should work:
DEVICE=A:\DOS\HIMEMX.EXE
DEVICE=A:\DOS\JEMM386.EXE I=TEST NOEMS
DEVICE=A:\DOS\UIDE.SYS /D:CDROM
DOS=HIGH,UMB
DOSDATA=UMB

Or:
DEVICE=A:\DOS\JEMMEX.EXE I=TEST NOEMS
DEVICE=A:\DOS\UIDE.SYS /D:CDROM
DOS=HIGH,UMB
DOSDATA=UMB

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Problem with UIDE

[Alain Mouette]

Hi Jack,

(I hope this messags comes though, 5th try...)

I am encountering a strange problem with UIDE. It happens with some 
machines but not all, one of the failing machine is nearby so I can make 
more tests easely...

I am using UIDE and XMGR from 10-May-11, I made my config from your 
example (whole file attached), jemm386 is 572 dated 13mar2008 (complete 
config at the end):
device=a:\dos\xmgr.sys /B
device=a:\dos\jemm386.exe I=TEST NOEMS
device=a:\dos\xmgr.sys
device=a:\dos\uide.sys /D:CDROM

It works ok booting from floppy and from hard-disk, but it does not work 
when booting from the CDROM. It stops with this screen and the HD led on:


Please help, I am trying to make a universal installer...

Alain
--

menucolor=10
menu
menu ┌───┐
menu │ Disco de instalaçäo do FreeDOS │
menu │ │
menu │ │
menu │ │
menu │ 1. Driver de CD: UIDE (padräo) │
menu │ 2. Sem CD-ROM │
menu │ │
menu └───┘
menu
menudefault=1,5

1? echo Driver: UIDE
2? echo Driver: Sem CD

screen=0x12
dos=high,umb
buffers=15,0
files=100
fcbs=4,0
lastdrive=Z

1? device=a:\dos\xmgr.sys /B
1? device=a:\dos\jemm386.exe I=TEST NOEMS
1? device=a:\dos\xmgr.sys
1? device=a:\dos\uide.sys /D:CDROM

2? device=a:\dos\himem.exe
2? device=a:\dos\emm386.exe NOEMS X=TEST

country=055,850,a:\dos\country.sys
shell=A:\command.com A:\ /E:1300 /p


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user