[Freedos-user] New FreeDOSers Bi-monthly Reminder

2005-08-01 Thread jp_freedos
/* This is an automated message sent out on the 1st
of each month.  It is automagically downloaded from
http://www.freedos.org/freedos/lists/remind.txt */

MONTHLY REMINDER FOR THE FREEDOS MAILING LIST

Hi! If you are a new reader of freedos-devel (or the other FreeDOS
lists) then, welcome! If you have already been a list member for some
time, then you can skip this as you probably are familiar with its
content anyway.

We have only a few rules for posting to the FreeDOS Mailing list:

1. Please don't swear. We don't want this mailing list to become what
   USENET usually is.

2. Don't post off-topic. Remember, we set up this mailing list to
   discuss FreeDOS issues.

3. No flame wars. If you feel really strongly against what someone has
   said, send a private email.

It would also be nice to send only plain text email messages, rather
than messages formatted in html or MIME encapsulation. This makes it
easier for everyone to read your posts. Above all, html files are real
killers for those who read with speech.

Also provide a bit of context for your reply. Don't be afraid to cite
the text or conversation you are replying to. At the same time, you
should be careful not to cite the whole conversation - just the
relavent bits.

The FreeDOS Project aims to create a free implementation of
MS-DOS. DOS is a popular system, and there is plenty of hardware out
there that supports DOS. The official home of the FreeDOS Project is:

http://www.freedos.org

Visit the FreeDOS Documentation Project (FD-DOC) at
fd-doc.sourceforge.net to learn how to use FreeDOS.

Would you like to contribute to the FreeDOS Project? Jim Hall has
started a Contribution HOWTO, as a place to start. Look for it at the
FD-DOC web site.

Report problems to the bug database at http://www.freedos.org/bugs.

Many programs have already been written for the FreeDOS Project. You
can see which ones by looking at the Maintainers List, which is at
http://www.freedos.org/freedos/software. The Base list shows the FreeDOS
programs that reproduce the functionality of MS-DOS. Yes, some still
need to be written.

If you would like to find some of the other web sites that apply to
FreeDOS, you may want to check out the FreeDOS web ring at
http://www.freedos.org/freedos/webring.

Thanks for taking an interest in FreeDOS!

---

-jh


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

2005-08-01 Thread Michael Devore

At 01:08 AM 7/31/2005 +0100, Gerry Hickman wrote:

Oh good grief.  EMM386 doesn't have the code or capability to mess with 
disk partitions.  Period.


But if drive geometry is being misreported or misunderstood under EMM386 
with VDS (which appears to be the case), then my guess is that it would be 
dangerous to run any kind of disk tool while the system is in that state? 
Even writing a file to a disk could cause corruption.


In the same way that a keyboard driver could be dangerous to run with a 
disk tool if there were a bug in it, or if it caused a normally hidden bug 
in the disk tool to activate.


DOS system code is wide open to corruption from any driver or application, 
a situation generally regarded as one of its biggest faults.


Without a system which displays the symptoms -- which I don't have -- it's 
almost impossible for me to say what's going on.  Likeliest candidate for 
causing the problem is that there is still a conflict with some SCSI 
interfaces and an active VDS (4bh) interrupt.  We know that at least one 
SCSI spec directly conflicted with VDS.  However, other candidates cannot 
be ruled out, or even marginalized.





---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386

2005-08-01 Thread Michael Devore

At 03:38 AM 7/30/2005 +, Mark Bailey wrote:


I see no difference at all with that version, either with the
development kernel/command.com or the stable kernel/
command.com.

Specifically, with
device=a:\himem.exe
device=a:\emm386.exe x=test memcheck vds

vol c: hangs.  Remove vds, it works normally. (development)


Alright, one more time.  I rewrote the VDS routines such that any reserved 
function which was unused (0, 1, 0dh-0ffh) no longer returns an error code, 
but simply sets carry flag and chains to old INT 4bh handler.  That may get 
around a SCSI conflict.  Or not.


In addition, I cleaned up slightly naughty code which re-enabled interrupts 
when returning from the VDS call.  Theoretically, the VDS interrupt might 
have been called with hardware interrupts disabled for good reason.


Will these revisions change anything?  Don't know, but it's the best I can 
do without a misbehaving machine here to test.  Hopefully no new error was 
introduced.  Those with VDS-unhappy machines will need to try it out and 
report back results.


To test this version of EMM386, amble over to 
ftp.devoresoftware.com\downloads\emm386 and download emmhorse.zip.  As 
before, unofficial release, no exterior version change, no EXE compression.





---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] re: More FreeDOS FDISK tests - failure is repeatable

2005-08-01 Thread Johnson Lam
On Sun, 31 Jul 2005 17:40:56 +0100, you wrote:

Hi Gerry,

 GUI (the current version should be UI)
Sorry, UI

Never mind.

Yes, I'm not against the UI, I'm just saying I've never needed it and 
(in my opinion) it's actually less confusing to use commands only.

Because you're not novice :-)

 2) Jeremy's patched 1.2.1-k, it kills two of my PC's MBR, now I've to
 rebuild everything from scratch
Yeeeouch!

I delete it immediately, horrible

 3) Jeremy's 1.3.0 beta, which never runs on my PC with Error 0
 reading sector 0x3f

He remove the binary from his website

Sorry, I should have made it clear I've only ever used 1.3.0 beta 
included in FreeDOS Beta9SR1. I think you'll find the 1.3.0 beta will 
run fine on the IBM eServer you are testing.

I'm not sure your 1.3.0 beta is the same as mine or not, but I'm sure
the FDISK have many hidden problems

The Error 0 reading sector 0x3f, are you sure that sector is not 
damaged? What is the PC and drive spec? If you type FDISK /STATUS does 
it also give this error?

No. Using FDISK 1.2.1 everything works.
FDISK /STATUS only shows a bunch of message in 1.3.0 beta.

Try different PC and the XEON server, same error.

Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Hard disk drivers

2005-08-01 Thread Johnson Lam
On Sun, 31 Jul 2005 21:40:40 +0100, you wrote:

Hi,

I'm currently writing a project in C using djgpp that runs in DOS and 
hopefully soon in FreeDOS. I notice that hard disk access is poor (noisy and 
frantic, as it is when booting into Windows safe mode).

FreeDOS is DOS compatible, of course not 100% but most of the program
works.

It's because the UltraDMA mode disabled in BIOS, download UDMA2 from
FreeDOS.org and try.

Is disk access better under FreeDOS than MS-DOS, and are there any decent 
drivers or config tweaks you could point me toward, please? As a newbie, any 
hints and tips would be greatly appreciated.

The FreeDOS kernel and command.com was smaller, and boot a lot faster
than MS-DOS.

The only tweak maybe in FDCONFIG.SYS (you can use CONFIG.SYS also):

BUFFERS=-1

will use 6 buffers, otherwise it consume 29 buffers whatever the
number is, why? Have to ask the developers ;-)

Many thanks in advance,

You're welcome.


Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Hard disk drivers - UltraDMA

2005-08-01 Thread Eric Twose

Johnson Lam wrote:

FreeDOS is DOS compatible, of course not 100% but most of the
program works.




Dear Johnson,

Many thanks for your help. The good news is, yes, my program now runs 
successfully under FreeDOS.



[noisy, frantic hard drive] is because the UltraDMA mode disabled in BIOS,
download UDMA2 from FreeDOS.org and try.




Alas, the old  (pre-1997) machine I've set up with FreeDOS reports that my 
c:\ drive (in LBA mode) does not support ultraDMA, so udma2.sys wasn't 
loaded.


Thanks all the same,
Eric T.







---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Hard disk drivers

2005-08-01 Thread Eric Twose

Eric T wrote:

hard disk access is poor (noisy and frantic, as it is when booting into
Windows safe mode).




Bernd wrote:

you could try how your project behaves on a ramdrive.




:) Maybe selectively. Most of the output at the moment is going to a debug 
log file. But the project itself will use most of the available RAM on the 
machine.


[ For what it's worth, the project is called guide (a slightly clumsy 
acronym for graphical user interface desktop environment). It looks like 
Seal has died a sad death, so I thought I'd develop my own from scratch. At 
the moment, I'm head-banging relatively trivial stuff like getting the 
system to recognize mouse events and respond to them; making sure the cursor 
stays in the same part of the system bar when a window's being dragged 
across the screen, and such.]



a diskcache might work, like SMARTDRV or LBACACHE.




Thanks indeed -- SMARTDRV works wonderfully. Now all I have to do is figure 
out how to call SMARTDRV /C when I shut down the project, from within a C 
program, to write to disk anything that's been cached. I've become so used 
to Windows and Microsoft's plonk and play software-writing packages :)


Best Wishes,
Eric T.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

2005-08-01 Thread Gerry Hickman

Hi Michael,

My main point was that the FDISK bug may have been _triggered_ by EMM386 
with VDS, and that if he hadn't been running EMM386 his FDISK tests 
would not have caused a bad partition table. You were saying this:


Oh good grief.  EMM386 doesn't have the code or capability to mess 
with disk partitions.  Period.


Hehe, so who knows:)

Anyway, regarding the VDS and SCSI tests, I posted my findings and 
SysConfig earlier in this thread, and can also test the new EMM386 to 
see if there's any change.


--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] EMM386 'horse' went wild

2005-08-01 Thread Gerry Hickman

Hi,

I tested EMM386 horse with VDS option, and on this system it's still 
total meltdown. All hard drive info misreported. Too scared to continue 
in case can't boot anymore.


Asus A7V333 latest BIOS
Adaptec 29160N SCSI host adapter with 2 x 36Gb drives
FreeDOS Beta9sr1 except HIMEM64 3.10a and EMM386 horse

FDISK and PQMAGIC claim there are no partitions defined and give totally 
crazy readings for physical disk sizes.


FDCONFIG.SYS follows (look out for line wrap):

; rem FDXMS gives VDISK error on some soft reboots
; rem FDXMS gives warning about an interrupt not being supported by EMM386

;device=special\fdxms.sys

DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X

; rem VDS option with EMM386 v2.03 corrupts everything
; rem TESTING VDS option with EMM386 horse
DEVICE=TESTING\EMM386.EXE NOEMS VDS X=TEST /verbose

; rem UMBPCI found to be more stable for UMBs on every system tested
;device=other\umbpci.sys

rem Load the SCSI for 29160N card, wait, we're using INT13 instead!
;device=other\aspi8u2.sys /d

rem UDMA hard drives, don't have any non-SCSI drives in this system
rem Why do some people run non-SCSI drives?
;DEVICE=DRIVER\UDMA2.SYS

rem This is not open source!
DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD

rem This is Microsoft, yikes
devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e

rem This is version from MSCLIENT 3.0, look out for version mismatch
;devicehigh=OTHER\ifshlp.sys

rem lbacache tuns switch is needed for SCSI and UMBPCI
rem but it doesn't seem to be needed on the 29360N card
INSTALLhigh=DRIVER\LBACACHE.COM
SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT

DOSDATA=UMB
DOS=high,UMB
FILES=20
BUFFERS=20
LASTDRIVE=Z



--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386

2005-08-01 Thread kd4d
Hi Michael:

No change with this version...system hangs on vol c: with VDS
option, works without.

Mark Bailey


 At 03:38 AM 7/30/2005 +, Mark Bailey wrote:
 
 I see no difference at all with that version, either with the
 development kernel/command.com or the stable kernel/
 command.com.
 
 Specifically, with
 device=a:\himem.exe
 device=a:\emm386.exe x=test memcheck vds
 
 vol c: hangs.  Remove vds, it works normally. (development)
 
 Alright, one more time.  I rewrote the VDS routines such that any reserved 
 function which was unused (0, 1, 0dh-0ffh) no longer returns an error code, 
 but simply sets carry flag and chains to old INT 4bh handler.  That may get 
 around a SCSI conflict.  Or not.
 
 In addition, I cleaned up slightly naughty code which re-enabled interrupts 
 when returning from the VDS call.  Theoretically, the VDS interrupt might 
 have been called with hardware interrupts disabled for good reason.
 
 Will these revisions change anything?  Don't know, but it's the best I can 
 do without a misbehaving machine here to test.  Hopefully no new error was 
 introduced.  Those with VDS-unhappy machines will need to try it out and 
 report back results.
 
 To test this version of EMM386, amble over to 
 ftp.devoresoftware.com\downloads\emm386 and download emmhorse.zip.  As 
 before, unofficial release, no exterior version change, no EXE compression.
 
 
 
 
 ---
 SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
 from IBM. Find simple to follow Roadmaps, straightforward articles,
 informative Webcasts and more! Get everything you need to get up to
 speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] re: Hard disk drivers

2005-08-01 Thread Eric Auer

Hi Eric,

please do not use HTML mail. Use plain text instead. Thanks...

 I'm currently writing a project in C using djgpp that runs in DOS...
 hard disk access is poor (noisy and frantic, as... Windows safe mode).

Then you should indeed try the UDMA2 driver (only for PCI/newer systems,
and UDMA probably has to be enabled in BIOS first, not supported in SCSI).
This makes reads faster and allows writes to overlap with other work. The
latter can improve the felt write speed a lot.

In addition, you should load a cache. Of course I recommend lbacache :-).
This does not support delayed writes, but on the other hand, things are
safer that way. The cache can be up to 31 MB and you can cache up to 8
harddisks, each of up to 2048 GB (!) size...

It will not make a real difference to use BUFFERS=-1, this only tells Free-
DOS do not use free HMA space for BUFFERS - use as few as possible buffers
instead, which means slightly less overhead (because you already have lba-
cache, the BUFFERs are not really needed anyway). However, unless your CPU
is really slow, having the default number of BUFFERS (e.g. no setting in
config sys) is always okay. Do not forget to load HIMEM and use DOS=HIGH
in your config sys. Best performance is probably WITHOUT EMM386. Basically
depends on the tradeoff between EMM386 gives you fast UMBs and EMM386
puts the system into protected mode and has to create a simulated real
mode environment for DOS, which causes overhead. Main use of UMBs is to
load TSRs and drivers high, to have more RAM free (with DOS=UMB line added
to enable UMB usage). EMM386 also provides several other functions, but UMB
memory is the one which has most impact on everyday apps. Of course you
HAVE to use EMM386 if you have apps which require e.g. EMS memory.

PS: Seal dead? Probably, but you could get the sources of the last version
to revive them instead of rewriting everything, I guess...
SMARTDRV /C is only needed if you enable delayed writes. If you enable them,
you should set SMARTDRV to write buffers before returning to prompt. Then
you are safe as soon as your project returns to the prompt. You can also
invoke FDAPM FLUSH to flush a number of the more common caches like SMARTDRV.

PPS: Acrobat/DOS can do PDF 1.1-almost1.2? Indeed old. But most current
are 1.4 / 1.5? I do not think so. My up-to-1.3 acroread/Linux displays
all files so far. Probably some companies thinking it is new so everybody
must use it to force all others to use it as well, without thinking about
whether 1.4 / 1.5 actually has features which are useful in that context.

Eric

(And try caches of 8 MB first, biggest is not automatically best...
if you use SCSI and loadhigh the cache, use TUNS. You often get a small
speed gain if you use TUNW (option to lbacache). Only if your CPU is
really fast or you want to get more effect from even small caches, add TUNA.)



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Hard disk drivers - UltraDMA

2005-08-01 Thread Johnson Lam
On Mon, 1 Aug 2005 18:54:24 +0100, you wrote:

Hi Eric T.,

Many thanks for your help. The good news is, yes, my program now runs 
successfully under FreeDOS.

Good news, hope you enjoy the feeling.

Alas, the old  (pre-1997) machine I've set up with FreeDOS reports that my 
c:\ drive (in LBA mode) does not support ultraDMA, so udma2.sys wasn't 
loaded.

Too bad, when you got a Pentium II and a not-so-old hard disk, you'll
found UDMA very helpful.


Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDOS FDISK 1.2.1-k not working

2005-08-01 Thread Johnson Lam
On Mon, 01 Aug 2005 20:01:00 +0100, you wrote:

Hi Gerry,

OK, I think this is where we are going wrong on this list with the 
testing (me included). People are posting results without locking down 
versioning. I mean we are all running totoally different versions and 
then wonder why we get different results.



I'm glad this one now starts to make sense. Regarding not being able to 
get 1.3.0 beta, surely it's included in the official Beta9sr1 release?

I got only 1 CD-Writer in my office (notebook's docking station), and
it's always taken by someone. That's why I usually download updated
binary separately.

Anyway, congrats on your new monster FreeDOS eServer! All we need now is 
comments from IBM:)

Thank you again. Maybe IBM didn't mind installing FreeDOS, all we lack
is application.


Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] EMM386 'horse' went wild

2005-08-01 Thread Johnson Lam
On Mon, 01 Aug 2005 23:02:59 +0100, you wrote:

Hi,

My painfully research result, may help you to optimize the CONFIG.SYS:

rem Why do some people run non-SCSI drives?
;DEVICE=DRIVER\UDMA2.SYS

Because SCSI means expensive!!

rem This is not open source!
DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD

But efficient and FREE

rem This is Microsoft, yikes
devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e

If you hate M$, try the OpenSource Resizeable RAMDISK (SRDISK)

BUFFERS=20

BUFFERS=-1


Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user