date:20040310

I ran "-dC000:0 " to get some overview here:

C000-C7FF looks to be my 32k Video bios
(starts with 55 AA 40, shows string "VGA Coompatible BIOS")
C800-C81F indeed has something to do with the extra UDMA
(starts with 55 AA 01, shows string "HIGHPOINT", no FF's)
C820-CFFF is empty (all FF)

So could it be that the HIGHPOINT UDMA jumps to somewhere
else for its payload ?
I suppose that the tuny ROM module at C8000 is just HighPoint 
initialisation and its real BIOS is elsewhere. Enclosed is the entire 
contents of this ROM that Erwin sent me. The rest are FFs.

LuchoC000:8000  55 AA 01 E9 6E 1C 48 69 | 67 68 50 6F 69 6E 74 20   U...n.HighPoint 
C000:8010  49 44 45 20 33 36 36 20 | 80 04 F4 17 00 00 74 18   IDE 366 ..t.
C000:8020  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8030  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8040  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8050  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8060  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8070  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8080  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:8090  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:80A0  00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00   
C000:80B0  00 00 00 00 00 00 00 00 | 80 FC C2 0F 84 19 00 60   ...`
C000:80C0  1E 8B EC 8E 5E 14 BE 74 | 18 38 14 74 20 83 C6 44   ^..t.8.t ..D
C000:80D0  3B 36 21 08 72 F3 1F 61 | 83 C4 04 EA 00 00 00 00   ;6!.r..a
C000:80E0  1F 61 CB 80 C1 04 EB 2A | B9 03 00 EB 25 80 FC 0C   .a.*%...
C000:80F0  74 F6 80 FC 47 74 F1 8A | CC 83 E1 3F 80 E9 02 72   t...Gt.?...r
C000:8100  DF 80 F9 02 77 DA F6 44 | 02 06 74 D7 F7 C3 01 00   w..D..t.
C000:8110  75 D1 06 8B F9 D1 E7 FF | B5 03 08 8A 4C 38 51 8B   u...L8Q.
C000:8120  EC 80 66 20 FE 81 4E 20 | 00 02 F6 C4 40 75 26 8A   ..f ..N [EMAIL 
PROTECTED]&.
C000:8130  44 2C F6 E6 8B 7E 14 8B | CF 83 E7 3F 03 F8 4F 8B   D,...~.?..O.
C000:8140  C1 86 C4 C0 EC 06 F7 64 | 06 03 F8 83 D2 00 8A 66   ...d...f
C000:8150  16 8C C1 EB 1A 8E 46 06 | 8B 7E 0A 26 8A 65 02 26   ..F..~.&.e.&
C000:8160  8B 5D 04 26 8B 4D 06 26 | 8B 55 0A 26 8B 7D 08 0E   .].&.M.&.U.&.}..
C000:8170  1F 80 7E 02 70 0F 85 02 | 00 B4 01 88 26 06 00 66   ..~.p...&..f
C000:8180  25 00 FF 00 00 66 D1 E0 | 89 3E 0C 00 89 16 0E 00   %f...>..
C000:8190  89 1E 00 04 89 0E 02 04 | A3 04 04 C7 06 06 04 00   
C000:81A0  80 80 7E 03 00 0F 84 8F | 00 BA 40 00 8E C2 26 F6   [EMAIL PROTECTED]&.
C000:81B0  06 7B 00 20 75 2D A3 3C | 00 8B C1 C1 E9 0C C1 E0   .{. u-.<
C000:81C0  04 03 C3 83 D1 00 A3 38 | 00 89 0E 3A 00 C7 06 3E   ...8...:...>
C000:81D0  00 00 80 EB 5B 8A 46 17 | C0 E0 04 32 E4 89 46 02   [.F2..F.
C000:81E0  EB 56 90 89 0E 30 00 66 | A3 28 00 89 1E 2C 00 C7   .V...0.f.(...,..
C000:81F0  06 2E 00 00 00 C7 06 34 | 00 10 00 C7 06 32 00 00   ...4.2..

[Freedos-devel] Version 1.0

Hi all,

There has been a message today (I just lost it :( ) about FreeDOS 1.0 
and I want to give my opinion:

Only one program is missing and that is a Scan-Disk (written as 2 words) 
utility for Fat32. For what I kow, DOSFSCK is working and need only a 
small fixes in the read sector.

IMHO a working version od DOSFSCK should be included in version 1.0 to 
have a full set of tools.

I don't believ that we will see a working and debugged version of either 
chkdsk or scandisk any time soon ...

Now we have a good FORMAT, and even a EMM386 (will be working soon) :)

Alain

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FREEDOS

2004-03-10 Thread Amy Moffett




TO WHOM IT MAY CONCERN;
 
I HAVE A QUESTION REGARDING FREEDOS AND WETHER OR 
NOT FREEDOS WILL RUN ON FAT 16 HARDDRIVE PARTITION TO 2 GIG OR LARGER WITHOUT 
USING A 'SHARE' PROGRAM OR ANYTHING RELATED. PLEASE CALL ME @ 716-822-8284 M-F 
8AM TO 4:30PM OR E-MAIL ME AT [EMAIL PROTECTED]
my name is amy moffett and i work for colgate 
industries!
thank you!

Re: [Freedos-devel] EMM386 with VCPI for testing

Ho Michael,

first of all, many thanks :)

EMM386 will only allocate VCPI memory from the EMS memory pool.  Making 
it automatically use the XMS memory pool would require backdoor interaction 
> with HIMEM[64] and generally make things quite a bit more complex.
Of course, a DOS extender/extended program can still use XMS in addition to 
> VCPI and many of them do.

I can see aproblem here (or I can have missunderstood): IMHO what will 
be used a lot is UMB+VCPI without EMS. The reason for this configuration 
is whe 1) UMBPCI does not work (new hw), 2) no need for EMS (few 
programs use it) 3) free as much as possible Low-Memory for comon 
programs (EMS takes 64k of UMB)(very often needed). Will this 
configuration work??

Alain



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Version 1.0

On Wed, 10 Mar 2004 14:54:58 -0300, Alain Mouette wrote:

Only one program is missing and that is a Scan-Disk (written as 2 words)
Afraid of the M1CR0$0FT police? ;-) Let's swap the words then and call it 
DISKSCAN!

utility for Fat32. For what I kow, DOSFSCK is working and need only a 
small fixes in the read sector.
If there is a volunteer for this Herculean feat, I'd suggest integrating 
DOSFSCK into DISKSCAN.

IMHO a working version od DOSFSCK should be included in version 1.0 to 
have a full set of tools.
Agreed.
Lucho
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Minor HIMEM64 update

A minor update to HIMEM64, next release slated to be "the" HIMEM, is available in the 
directory at ftp://ftp.devoresoftware.com/downloads via ftp or direct link with most 
browsers.  The files are HIMEM64.ZIP, containing uncompressed HIMEM64.EXE and 
HIMEM64S.ZIP, contain the modified source file HIMEM64.ASM.

The patch is designed to increase compatibility with older software which isn't >64M 
aware, as reported by Eric Auer.  Some of those programs cannot handle the highest 
possible return value of 64M-1K (value 0h) under the older XMS 2.0-level 'query 
XMS memory' function (function 8) and will assume no XMS is available or otherwise 
misbehave.  The patch reduces maximum XMS memory returned by the XMS 2.0 'query XMS 
memory' function to 63M-64K (value 0fbc0h).

If you have an older piece of software which has had problems recognizing XMS memory 
under the latest HIMEM64, you might want to try this version.

The XMS 3.0-level 'query XMS memory' function (function 88h) continues to return the 
full range of XMS memory through 4G.

This patch will be an "official" part of next HIMEM release.




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FREEDOS

Hi Amy,

I am not the official mantainer, but I can assure you that FreeDOS works 
well with both Fat16 anf Fat32. As far as I know there is no knwn bug, 
and I am using it on same machines without problem for quite a while :)

Alain
PS: as you sent your address I am bcc'ing this to you.
Amy Moffett escreveu:

TO WHOM IT MAY CONCERN;
 
I HAVE A QUESTION REGARDING FREEDOS AND WETHER OR NOT FREEDOS WILL RUN 
ON FAT 16 HARDDRIVE PARTITION TO 2 GIG OR LARGER WITHOUT USING A 'SHARE' 
PROGRAM OR ANYTHING RELATED. PLEASE CALL ME @ 716-822-8284 M-F 8AM TO 
4:30PM OR E-MAIL ME AT [EMAIL PROTECTED] 
my name is amy moffett and i work for colgate industries!
thank you!


---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] EMM386 with VCPI for testing

At 02:36 PM 3/10/2004 -0300, Alain wrote:
>Ho Michael,
>
>first of all, many thanks :)
>
>>EMM386 will only allocate VCPI memory from the EMS memory pool.  Making it 
>>automatically use the XMS memory pool would require backdoor interaction 
>> with HIMEM[64] and generally make things quite a bit more complex.
>>Of course, a DOS extender/extended program can still use XMS in addition to 
>> VCPI and many of them do.
>
>I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot 
>is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not 
>work (new hw), 2) no need for EMS (few programs use it) 3) free as much as possible 
>Low-Memory for comon programs (EMS takes 64k of UMB)(very often needed). Will this 
>configuration work??

Depends.  Some extenders have absolutely no problem allocating from XMS if no VCPI 
memory available.  Unfortunately, DOS/4GW, now crowned That Annoying Extender Which 
Grossly Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that 
out and am not sure whether it's due to no memory in VCPI pool, missing EMS page 
frame, or something else.  NOEMS is pretty badly broken in the EMM386 version out 
there anyway, but I've fixed it up some for next patch release.  Now NOEMS allocates 
up to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K 
for a VCPI pool, more if you have fewer UMB's.

The DOS/4GW problem does need to be addressed since it's most popular extender out 
there and a lot of legacy applications use it.   I'm thinking maybe if the residual 
EMS left-over after UMB allocation is too low, I'll have EMM386 by default grab a hunk 
of XMS memory at startup to keep for as VCPI pool.  Biggest hurdle is that this 
behavior is not the most friendly use of memory.  And if I do that, I'll need to 
slightly modify HIMEM again to increase default handles, since it's already pretty low 
without EMM386 grabbing memory.

What would you think about an EMM386 that decided to steal some of your XMS memory at 
startup, just in case a VCPI-using program wanted it later on?  I mean, the memory 
might never be needed if nothing ran which used VCPI, it would just be gone.  Proper 
settings would need some type of command line parameter control, but we really need is 
a basic default for the general Joe and Joyce User who simply sticks NOEMS in there 
and still expects their DOS-extended to run with a DOS extender or related protected 
mode application than can't fallback to XMS allocation.

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Version 1.0



Only one program is missing and that is a Scan-Disk (written as 2 words)
Afraid of the M1CR0$0FT police? ;-) Let's swap the words then and call 
it DISKSCAN!
No, I am afraid of starting another message war. There are some people 
here working in a "scandisk"

utility for Fat32. For what I kow, DOSFSCK is working and need only a 
small fixes in the read sector.
If there is a volunteer for this Herculean feat, I'd suggest integrating 
DOSFSCK into DISKSCAN.
for what I know, it is already working, the problem is just that the 
maintainter doesn't know how and does not have time to learn how to 
write a read/write absolute sector (it has to run on djgpp).

Many people here could help on just this item ;-)

IMHO a working version od DOSFSCK should be included in version 1.0 to 
have a full set of tools.
Agreed.
:) :)

Alain

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing

Hi Michael,
EMM386 will only allocate VCPI memory from the EMS memory pool. Making it
automatically use the XMS memory pool would require backdoor interaction
with HIMEM[64] and generally make things quite a bit more complex.
Of course, a DOS extender/extended program can still use XMS in addition to
VCPI and many of them do.
I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot is
UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not work
(new hw), 2) no need for EMS (few programs use it) 3) free as much as possible Low-Memory
for comon programs (EMS takes 64k of UMB)(very often needed). Will this configuration work??

Depends. Some extenders have absolutely no problem allocating from XMS if no VCPI
memory available.
For what I learned here, if the machine is not in real mode, which is
needed to get UMB, then VCPI is needed. am I wrong?

Unfortunately, DOS/4GW, now crowned That Annoying Extender Which
Grossly Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that
out and am not sure whether it's due to no memory in VCPI pool, missing EMS page
frame, or something else. NOEMS is pretty badly broken in the EMM386 version out
there anyway, but I've fixed it up some for next patch release. Now NOEMS allocates
up to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K
for a VCPI pool, more if you have fewer UMB's.
What is himem+emm386 footprint in memor(low+umb)?

The DOS/4GW problem does need to be addressed since it's most popular extender out
there and a lot of legacy applications use it.
Agreed ;-)

I'm thinking maybe if the residual
EMS left-over after UMB allocation is too low, I'll have EMM386 by default grab a
hunk of XMS memory at startup to keep for as VCPI pool. Biggest hurdle is that
this behavior is not the most friendly use of memory. And if I do that, I'll need
to slightly modify HIMEM again to increase default handles, since it's already
pretty low without EMM386 grabbing memory.

What would you think about an EMM386 that decided to steal some of your XMS memory
at startup, just in case a VCPI-using program wanted it later on? I mean, the
memory might never be needed if nothing ran which used VCPI, it would just be gone.
Proper settings would need some type of command line parameter control, but we
really need is a basic default for the general Joe and Joyce User who simply
sticks NOEMS in there and still expects their DOS-extended to run with a DOS
extender or related protected mode application than can't fallback to XMS allocation.
I think that we should consider a bit who is Averege-Joe and what
machine he may get.

1) if he has no knwledge of dos at all (just a mouse-clicker) and is
just testing, he has a powerfull machine and will not care as long as
everything runs. For him a good installer is the most important thing.

2) for an old-time DOS user that is really using FreeDOS to run old
programs (like Clipper systems) he has at least 4Mb of memory. In this
case it FreeDOS should a) run just out-of-the-box and b) could be
optimised later if this is really needed

2) for small enbedded systems, anything will be highly optimised and
this Joe has the knwledge to do it. So here default are not a problem.

SO: default values should have any value that make the system work
smoothly. It just ocurred to me that these values could be dependant on
the total amount of memory found in the machine. MS-DOS has this in many
places. This way if there is at least 4Mb, a little more in various
tables is wellcome.

Alain

PS What program are usint to write you messages? my Thunderbird is
behaving strangely in the answer screen and I have to break lines manually.

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] re: EMM386 with VCPI for testing


Hi, I removed the C000:8 and "| " strings and did this:
xxd -r dump.txt | ndisasm - | less
At first glance the analyzed payload of this "HighPoint IDE 386" thing
looks like something which hooks int 13h (BIOS disk services) and hides
the first 2 sectors on the disk from the user, both in CHS and LBA mode.
I think the first 2 sectors will contain some kind of driver which you
will only be able to see if you do not boot that HighPoint thing  - or
if you disable it later. Or if you use FreeDOS UDMA driver :-).

Actually the latter is dangerous! Loading the driver makes the drive
contents "jump" back to their original position, which can be very
confusing for all software which accesses the drive.

Eric.

> > So could it be that the HIGHPOINT UDMA jumps to somewhere
> > else for its payload ?
> 
> I suppose that the tuny ROM module at C8000 is just HighPoint 
> initialisation and its real BIOS is elsewhere. Enclosed is the entire 
> contents of this ROM that Erwin sent me. The rest are FFs.
> 
> Lucho

...



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing

At 07:34 PM 3/10/2004 -0300, Alain wrote:
EMM386 will only allocate VCPI memory from the EMS memory pool.  Making it 
>>automatically use the XMS memory pool would require backdoor interaction
with HIMEM[64] and generally make things quite a bit more complex.
Of course, a DOS extender/extended program can still use XMS in addition to VCPI 
and many of them do.
>>>I can see aproblem here (or I can have missunderstood): IMHO what will be used a 
>>>lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI 
>>>does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much as 
>>>possible Low-Memory
>>>for comon programs (EMS takes 64k of UMB)(very often needed). Will this 
>>>configuration work??
>> 
>>Depends.  Some extenders have absolutely no problem allocating from XMS if no VCPI 
>>memory available.
>
>For what I learned here, if the machine is not in real mode, which is needed to get 
>UMB, then VCPI is needed. am I wrong?

No, it's not necessary.  UMB's are mapped at startup by the EMM.  VCPI is simply an 
interface (the 'I' part of the acronym) with EMM386 to make it, among other things, do 
what you want from V86, aka virtual 8086, mode.  V86 is what DOS runs at under EMM386 
rather than real mode.  The EM monitor itself substantially runs in protected mode.

>> Unfortunately, DOS/4GW, now crowned That Annoying Extender Which Grossly 
>> Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that out 
>> and am not sure whether it's due to no memory in VCPI pool, missing EMS page frame, 
>> or something else.  NOEMS is pretty badly broken in the EMM386 version out there 
>> anyway, but I've fixed it up some for next patch release.  Now NOEMS allocates up 
>> to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K 
>> for a VCPI pool, more if you have fewer UMB's.
>
>What is himem+emm386 footprint in memor(low+umb)?

Don't know.  HIMEM conventional memory footprint is low, around 3K(?) someone said a 
while back.  EMM386 is growing and definitely higher than that, although most internal 
tables and structures are in high memory outside of pure DOS.  I did misstate how the 
NOEMS allocation for UMB's works.  Under NOEMS EMM386 allocates enough for the current 
UMB's, plus 32K for VCPI, meaning lower UMB's allocations won't increase the minimum 
VCPI pool size.  Right now, EMM386 shuts off VCPI if there isn't a minimum 32K for 
VCPI after UMB allocation, but I'm probably going to change that since some programs 
will work with a zero-sized VCPI pool.  I think.

>PS What program are usint to write you messages? my Thunderbird is behaving strangely 
>in the answer screen and I have to break lines manually.

I'm using Eudora Pro, plain text, to stop Eric from griping in his enthusiastic role 
as HTML policeman.  Hard line breaks in regular text are generally frowned upon in 
messaging per ancient Usenet rules et al, so I don't use them.  A  few million people 
on the Internet like to gripe about hard line breaks.  And then there's top-posting, 
which I still sometimes do and refuse to stop.  And cap rules.  And style rules.  
Matter of fact, you'd almost think most people out there in the world like to gripe.  
Not me, of course, although naturally I offer many unsolicited suggestions and 
opinions purely for the benefit of others.

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] re: Version 1.0


Hi Alain,

> Only one program is missing and that is a Scan-Disk (written as 2 words) 
> utility for Fat32. For what I kow, DOSFSCK is working and need only a 
> small fixes in the read sector.

I strongly disagree. Our SCANDISK for FAT1x is completely defunct, so we
have no SCANDISK in the meaning of "nice looking user interface to the
CHKDSK and DOSFSCK engines" at all. My DOSFSCK-2.8-FAT32 currently works
okay, but a working 2.10 port would be much better. I hope Imre can find
the time to add working lowlevel disk access drivers to 2.10 (does not
work at all for me for FAT16 in FreeDOS). It would not be THAT hard. Have
a look at my 2.8-FAT32 (can only read, only compiles okay in Turbo C, not
in Borland C, see recent absread discussion) and Imres 2.10, maybe YOU can
help us and provide a working "can read and write all FAT types" 2.10 ...

What else is missing?

Very important to me would be the online TODO list
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/todo/index.php
describing the state of Beta9rc4 because people think (and they are right)
that the TODO list will describe the current version.

Now I already have "offline" knowledge of how far we "really" are:
append is very alpha, maybe even dummy.
atapicdd is pretty alpha
emm386 vcpi is alpha (but great that it is there)
graftabl would probably not be too hard to fix if we knew which codepages
  are missing.
[nansi chaining will be useful as soon as display becomes a sys]
[emm386: h=... should be post 1.0, ram=... and rom=... should be feasible]
[no idea how far keyb is]
[shsucdx /v would not be that hard, but having a cache, especially read-ahead,
 inside the shsucdx itself would be both useful and not easy. Even wif you use
 CDRcache for most of the caching...]
NLSFUNC is missing, but we already have lots of NLS functionality in the
  kernel. I wonder how hard it would be to write NLSFUNC and who can do it.
PRINT/PRINTQ has several TODOs, maybe it needs a new maintainer...?
RAMDISK problems are a bit vague... Maybe even kernel related.
BACKUP / RESTORE (MS file compatible) could be moved to post 1.0 if needed.
DEFRAG - I would like to see an update, I think there have been bugfixes but
  they did not get published yet.
FDISK - The newest 1.21 (?) version seems to be better than 1.20, but I think
  there are still important bugs on some systems. Updates planned?
FORMAT - With all feedback from "Fritz" and Johnson I still could not figure
  out why running FreeDOS FORMAT under Windows creates broken FAT32. All boot
  sector fields look okay for me but still the root directory is accessed at
  the wrong place by Windows.
MIRROR - FAT12 support would be nice. This reminds me that MIRROR (safeformat)
  and UNFORMAT which are builtin in FORMAT has a bug for FAT32...
RECOVER - There are two modes: One zaps the FAT and root dir and tries to
  re-invent a fat based on directory data found by scanning the disk etc.
  (only a "last ch*nce" method). The other which would be more useful would
  be "replace broken sectors by sectors filled with '?'" and should (IMHO!)
  be implemented as an option to XCOPY: Copy files and instead of giving up on
  errors replace broken sectors... Could even delete those files which had no
  errors (the copy of them, that is) in some special mode.
Is UNFORMAT really ready?
FreeCOM should at least fix the following bugs / problems:
  DIR should use ext. free size (can be > 2 GB, but displaying in units of
  kB or even MB would be okay) on FAT32.
  CLS should work properly and without that extra library which it uses.
  Overwriting file by nonexisting file zaps file.
  Context memory has a memory leak.
  Renaming dir with trailing \ makes it disappear.
Then there are some special "resolved" cases in FreeCOM:
  single wildcards not supported
  IF / FOR redirection problems
  I read that 0.82pl3a finally fixes "nonexisting drive reported as out of
  memory", so I suggest that 0.82pl3a should get some PR? Did not hear of it.

UNDELETE is improving thanks to work by Rob, maybe Patric can add FAT32...
  the resident things could be a separate TSR (delete-log and "turn delete into
  move-to-trash, logging original filename") and/or post 1.0 ...
MEM has some wishlist.
MODE should be complete now, except that codepages are only supported for CON.
Kernel COUNTRY= is there with one (not 2) arguments already, and MS syntax for
  MENU could be postponed.

So far for that. If you have some spare time, please visit Bugzilla and check
which of the bugs you can faithfully mark as fixed for current versions!

I think we should get a FULL beta 9 out, but there are a few programs and
not so few features missing for 1.0 ... For the FULL beta 9, I would like to
have:
- a binary-only CD-ROM download
- a full CD-ROM download
- a binary-only (i.e. no sources) 1.44M floppy distro
- ... and a batch script to split that into a 720k floppy distro
- an ODIN version with all executables and as many supplemental files (like
  the help system and NLS) as

Re: [Freedos-devel] EMM386 with VCPI for testing

2004-03-10 Thread Arkady V.Belousov

Hi!

10-Мар-2004 15:54 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:

MD> What would you think about an EMM386 that decided to steal some of your XMS
MD> memory at startup, just in case a VCPI-using program wanted it later on?  I

 As I understand, EMM386 may inserts itself into XMM chain and behave as
XMM over HIMEM. Thus, you will one memory available both through EMS and
XMS, as in QEMM386.




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] EMM386 with VCPI for testing

At 03:38 AM 3/11/2004 +0300, Arkady V.Belousov wrote:
>Hi!
>
>10-íÁÒ-2004 15:54 [EMAIL PROTECTED] (Michael Devore) wrote to
>[EMAIL PROTECTED]:
>
>MD> What would you think about an EMM386 that decided to steal some of your XMS
>MD> memory at startup, just in case a VCPI-using program wanted it later on?  I
>
> As I understand, EMM386 may inserts itself into XMM chain and behave as
>XMM over HIMEM. Thus, you will one memory available both through EMS and
>XMS, as in QEMM386.

No, the memory allocation is quite different.  XMS memory is allocated in discrete 
sizes, with an extremely limited number of handles, and locking a block gives you a 
starting address which references the whole block.  Memory within the block is always 
assumed linear for access.

There is no such thing as an absolute address with EMS other than the 64K page frame 
in low memory and a single 16K (EMS) or 4K (VCPI) block.  As a consequence, you can 
allocate EMS/VCPI memory in a random spray across a memory range without any side 
effects -- you need only track what 4K/16K pages goes with what EMS handle.  EMS 
memory can be, and usually is, nonlinear.

If you start allocating XMS in a random spray to satisfy a number of VCPI 4K requests, 
you immediately fragment its memory pool and require more than a simple array of 
handles to track where things go.  XMS is currently tracked as a position in and a 
length of physical memory per handle, not as a list of varying sized allocations per 
handle (which wouldn't even work for linearity).  The only XMS handle allocation which 
can potentially grow would be the last one on the chain of allocations into the free 
area, the other XMS handle allocations are bounded by their neighbors.

Currently the EMM could use a single chunk of XMS memory and suballocate it into 4K 
and 16K memory allocations as requested for EMS/VCPI memory requests only.  But that 
single chunk would have to be allocated at startup and couldn't change size.  And if 
fact, that's how it does work right now.

What you'd have to do to share EMS and XMS is dynamically support growing and 
shrinking of any arbitrary XMS block that the EMM would use.  It could be done by 
virtualization and dynamically remapping physical to linear memory through the page 
tables with each page change, but it's by no means a simple task and a good bit of the 
code to do it would have to be written from scratch, not to mention side issues.  
Doing all that's a lot of work, well beyond anything I'm ready to take on right now.  
It's much of the reason QEMM used to be able to charge a good price for their memory 
manager over what Microsoft then supplied for free.

There are fairly complex memory allocation issues here, probably beyond the scope of 
me trying to describe them in one message.

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing

Michael Devore escreveu:

At 07:34 PM 3/10/2004 -0300, Alain wrote:

EMM386 will only allocate VCPI memory from the EMS memory pool. Making it
automatically use the XMS memory pool would require backdoor interaction
with HIMEM[64] and generally make things quite a bit more complex.
Of course, a DOS extender/extended program can still use XMS in addition to VCPI and
many of them do.
I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot
is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not
work (new hw), 2) no need for EMS (few programs use it) 3) free as much as possible
Low-Memory
for comon programs (EMS takes 64k of UMB)(very often needed). Will this configuration
work??
Depends. Some extenders have absolutely no problem allocating from XMS if no VCPI memory available.
For what I learned here, if the machine is not in real mode, which is needed to get UMB, then VCPI is needed. am I wrong?
No, it's not necessary. UMB's are mapped at startup by the EMM. VCPI is simply an
interface (the 'I' part of the acronym) with EMM386 to make it, among other things,
do what you want from V86, aka virtual 8086, mode. V86 is what DOS runs at under
EMM386 rather than real mode. The EM monitor itself substantially runs in protected mode.
Some cpu instructions _cannot_ be used in V86 mode in i586 machines. So
if the machine _is_ in V86 someone has to control it, ok? that one is
VCPI, ok?
So if I need UMB without umbpci, I need to put the machine in V86 mode.
What you are saying is that _some_ dos extenders (but not dos4gw) can do
that even without VCPI, ok?
Sorry, but it looks like I missunderstood something somewhere, this is
why I am re-phrasing most of what you say so that I can see where is my
erros ;-)

What is himem+emm386 footprint in memor(low+umb)?
Don't know. HIMEM conventional memory footprint is low, around 3K(?) someone said a
while back. EMM386 is growing and definitely higher than that, although most
internal tables and structures are in high memory outside of pure DOS. I did
misstate how the NOEMS allocation for UMB's works. Under NOEMS EMM386 allocates
enough for the current UMB's, plus 32K for VCPI, meaning lower UMB's allocations
won't increase the minimum VCPI pool size. Right now, EMM386 shuts off VCPI
if there isn't a minimum 32K for VCPI after UMB allocation, but I'm probably
going to change that since some programs will work with a zero-sized VCPI pool.
I think.
So EMM386 has a small code in memory, _plus_ 32k for the VCPI pool. The
diference seems to be that this 32k are hidden somewhere in MS-EMM386, ok?

Alain

[Freedos-devel] Message problem EudoraPro/Thunderbird on this list

Michael Devore escreveu:

PS What program are usint to write you messages? my Thunderbird is behaving 
strangely in the answer screen and I have to break lines manually.

I'm using Eudora Pro, plain text, to stop Eric from griping in his 
enthusiastic role as HTML policeman.  Hard line breaks in regular text 
are generally frowned upon in messaging per ancient Usenet rules et al,
so I don't use them.  A  few million people on the Internet like to gripe 
about hard line breaks.  And then there's top-posting, which I still 
sometimes do and refuse to stop.  And cap rules.  And style rules.  Matter
of fact, you'd almost think most people out there in the world like to gripe.
Not me, of course, although naturally I offer many unsolicited suggestions
and opinions purely for the benefit of others.
Is anyone else using Eudora Pro? Please send me a message with a 
paragraph 3 to 4 lines. When I am answering the message, every paragraph 
opens in one single very long line. All other messages seem to work 
normaly.

Alain




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel




---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] re: Version 1.0

Hi Eric,

Only one program is missing and that is a Scan-Disk (written as 2 words) 
utility for Fat32. For what I kow, DOSFSCK is working and need only a 
small fixes in the read sector.

I strongly disagree.
:( see beloww

Our SCANDISK for FAT1x is completely defunct, so we
have no SCANDISK in the meaning of "nice looking user interface to the
CHKDSK and DOSFSCK engines" at all.
I agree :)

My DOSFSCK-2.8-FAT32 currently works
okay, but a working 2.10 port would be much better.
IIRC ther is some bug in this version that is _not_ related to the dos 
port and it behaves strangely with some fat erros. Again IIRC this is ok 
in next version...

I hope Imre can find
the time to add working lowlevel disk access drivers to 2.10 (does not
work at all for me for FAT16 in FreeDOS). It would not be THAT hard.
That is what I said.

Have a look at my 2.8-FAT32 (can only read, only compiles okay in Turbo C, not
in Borland C,
as dosfsck is a Linux program, it will probably work well only under 
DJGPP. For the Fat32 version this is ok as it need lots of memory anyway.

see recent absread discussion) and Imres 2.10, maybe YOU can
help us and provide a working "can read and write all FAT types" 2.10 ...
I wish I could help. FWIK, you (Eric) have some knowledge about it and 
Andreas has too but he will be too busy in the next few months. I will 
have some free time next month, but I don't even know where to look at 
to start :(

I was just hoping that your previous work with lbacache would make it 
easyer for you ;-)

What else is missing?
is is my particular and very BIASED opinion:

RAMDISK problems are a bit vague... Maybe even kernel related.
XMSDSK is 100% functional and free _can_ be used

FDISK - The newest 1.21 (?) version seems to be better than 1.20, but I think
  there are still important bugs on some systems. Updates planned?
?? are these rally bad or are they related to uncommon file systems?

FORMAT - With all feedback from "Fritz" and Johnson I still could not figure
  out why running FreeDOS FORMAT under Windows creates broken FAT32. All boot
  sector fields look okay for me but still the root directory is accessed at
  the wrong place by Windows.
But I am confident that something will come around soon ;-)

MODE and KEY ...
are underway thanks to Aitor

FreeCOM should at least fix the following bugs / problems:

  Overwriting file by nonexisting file zaps file.
I believe this is fixed

  Context memory has a memory leak.
?? looks bad

  Renaming dir with trailing \ makes it disappear.
?? looks bad

Most other problems I (personaly) don't see as show stoppers

Alain



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] re3: Version 1.0


Hi Alain, sorry, I confused UNDELETE and DOSFSCK. Of course even my DOS
port of DOSFSCK compiles with DJGPP. Only UNDELETE uses Turbo C and will
need an extra #ifdef to compile with proper __BORLANDC__ absread usage.

> > RAMDISK problems are a bit vague... Maybe even kernel related.
> XMSDSK is 100% functional and free _can_ be used

I do not think so. While XMSDSK generally works nice, it has - as any
other ramdisk that I have tested so far - the strange
problem that LCD (interactive change dir) immediately exits to the prompt
when touching it, and even worse, that DPMI16BI compiled programs like the
Jazz Jackrabbit game crash if any ramdisk is present at all (do not even
have to have a reason to touch any file on that ramdisk). Maybe you could
try several ramdisks, several XMS drivers and several kernel versions and
try to find out if any combination works okay for you.

About FDISK 1.21: I only use Linux fdisk, so I do not know. But Bugzilla
has several bug reports about FDISK, please check yourself.

Eric.



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] EMM386 with VCPI for testing

At 12:02 AM 3/11/2004 -0300, Alain wrote:

>>EMM386 will only allocate VCPI memory from the EMS memory pool.  Making it 
automatically use the XMS memory pool would require backdoor interaction
>>with HIMEM[64] and generally make things quite a bit more complex.
>>Of course, a DOS extender/extended program can still use XMS in addition to VCPI 
>>and many of them do.
>I can see aproblem here (or I can have missunderstood): IMHO what will be used a 
>lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI 
>does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much 
>as possible Low-Memory
>for comon programs (EMS takes 64k of UMB)(very often needed). Will this 
>configuration work??
Depends.  Some extenders have absolutely no problem allocating from XMS if no VCPI 
memory available.
>>>For what I learned here, if the machine is not in real mode, which is needed to get 
>>>UMB, then VCPI is needed. am I wrong?
>>No, it's not necessary.  UMB's are mapped at startup by the EMM.  VCPI is simply an 
>>interface (the 'I' part of the acronym) with EMM386 to make it, among other things, 
>>do what you want from V86, aka virtual 8086, mode.  V86 is what DOS runs at under 
>>EMM386 rather than real mode.  The EM monitor itself substantially runs in protected 
>>mode.
>
>Some cpu instructions _cannot_ be used in V86 mode in i586 machines. So if the 
>machine _is_ in V86 someone has to control it, ok? that one is VCPI, ok?
>So if I need UMB without umbpci, I need to put the machine in V86 mode. What you are 
>saying is that _some_ dos extenders (but not dos4gw) can do that even without VCPI, 
>ok?
>Sorry, but it looks like I missunderstood something somewhere, this is why I am 
>re-phrasing most of what you say so that I can see where is my erros ;-)

No, the exceptions generated in V86 due to illegal-for-V86-mode instructions transfer 
back to the EMM which is running protected mode.  The EMM can emulate instructions via 
the exception handler where it is in protected mode and the instructions are legal, if 
the support for that instruction has been coded in.  If the instruction is supported 
and is performed, the EMM then returns control to the program running in V86 mode 
after setting the program's instruction pointer past the failing instruction.  EMM386 
does this with the instructions HLT, and 8- and 16- bit IN or OUT.  I just added 
support in EMM386 for mov eax,cr3 because Microsoft's EMM386 supports that instruction 
(via emulation) in V86 mode and at least one program out there blithely uses that 
illegal instruction when it knows it's in V86 mode.  Which I find disturbing, but what 
can you do?

UMB's don't have much to do with DOS extenders.  I'm not sure I understand what you're 
asking there.  UMB's are extended memory mapped down into DOS memory via the EMM.  You 
allocate and free UMB's via the XMS API.  FreeDOS HIMEM's XMS API doesn't support 
those UMB functions itself, but EMM386 hooks into the XMS allocator chain and adds 
support for UMB's within its own code.  Not the full spec support, but enough to use 
them.  Perhaps later on EMM386 will support full UMB management.

VCPI isn't part of UMB's as there is not a VCPI function which controls or uses them, 
not as anything other than another chunk of memory.  Remember that well before VCPI 
was added to EMM386 this last test release,  EMM386 still created UMB's.

>>>What is himem+emm386 footprint in memor(low+umb)?
>>Don't know.  HIMEM conventional memory footprint is low, around 3K(?) someone said a 
>>while back.  EMM386 is growing and definitely higher than that, although most 
>>internal tables and structures are in high memory outside of pure DOS.  I did 
>>misstate how the NOEMS allocation for UMB's works.  Under NOEMS EMM386 allocates 
>>enough for the current UMB's, plus 32K for VCPI, meaning lower UMB's allocations 
>>won't increase the minimum VCPI pool size.  Right now, EMM386 shuts off VCPI if 
>>there isn't a minimum 32K for VCPI after UMB allocation, but I'm probably going to 
>>change that since some programs will work with a zero-sized VCPI pool.
>>I think.
>
>So EMM386 has a small code in memory, _plus_ 32k for the VCPI pool. The diference 
>seems to be that this 32k are hidden somewhere in MS-EMM386, ok?

No, the 32K is from extended memory, just like the standard EMS memory.  It gets 
swiped from the EMS pool, as needed.  VCPI and EMS memory are a shared pool.  The 32K 
doesn't affect the DOS conventional memory footprint.

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
h

[Freedos-devel] XMSDSK

Eric, please fix manually your strange subject lines (re, re2, re3, re4...)

XMSDSK is 100% functional and free _can_ be used
I do not think so. While XMSDSK generally works nice, it has - as any
other ramdisk that I have tested so far - the strange
problem that LCD (interactive change dir) immediately exits to the prompt
when touching it, and even worse, that DPMI16BI compiled programs like 
the
Jazz Jackrabbit game crash if any ramdisk is present at all (do not even
have to have a reason to touch any file on that ramdisk). Maybe you could
try several ramdisks, several XMS drivers and several kernel versions and
try to find out if any combination works okay for you.
So, as NO RAM DISK satisfies an utility and a game, NO RAM DISK may be 
included in FreeDOS! But this is NOT XMSDSK's fault! It works and is free 
(albeit not open source) so I agree with Alain - if we include UMBPCI, we 
should include XMSDSK too.

Lucho

---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] re: XMSDSK


Hi Lucho!

> So, as NO RAM DISK satisfies an utility and a game, NO RAM DISK may be 
> included in FreeDOS! But this is NOT XMSDSK's fault! It works and is free 
> (albeit not open source) so I agree with Alain - if we include UMBPCI, we 
> should include XMSDSK too.

Please try before shouting. If MS RAMDRIVE in MS kernel with MS HIMEM still
crashes with Jazz Jackrabbit, it is Jazz's fault. But I think that it is
EITHER the XMS driver, the ramdisk driver or the kernel. Not all three of
them and not none of them. We should find and fix this component then. I can
only tell you that I found no working combination yet, but others will have
more components around to compare (e.g. MS kernel and drivers).

We should indeed tell our users about UMBPCI, but we simply MAY not include
it. It is updated too often and the author insists that all mirrors are kept
very up to date. A weekly Ibiblio mirror might be okay, but a CD-ROM image
which is only updated a few times per year is NOT an acceptable mirror for
the UMBPCI author.

Eric.



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] HighPoint UDMA IDE controller