All,
Thanks for your help everyone, in getting this nailed down!!!
--
Jim Lilly - Team Z
http://www.zonelabs.com/store/content/company/teamzBios.jsp
Using - Virtual Access(OLR), ZAP 4.5, WinXP Pro w/SP1
http://www.virtual-access.org
On Fri, 12 Mar 2004 15:24:58 CST, Jim Lilly wrote:
I've found FreeDOS hangs in booting off a ZIP 100 IDE disk formatted
FAT32, but boots fine off another ZIP disk formatted as FAT.
If I remember correctly, FAT32 volumes must be at least 128 MB in size.
Lucho
On 2004-03-13, Eric Auer wrote:
Default BPB for drive X: according to Bootfix 1.1 by Arkady:
512 by/sec, 4 sec/clust, 1 boot sector, 188 sec/fat, 2 FATs,
0 / 195016 sectors, 0x.f744 hidden sectors (this is the
partition position, looks completely wrong under the assumption
that ZIP disks
Hi Arkady,
pressing ^Z
in non-empty line does nothing (except that line end is ignored),
only first
^Z on line is processed as end of input.
Strange, but under MS-DOS I get same behavior. Another bug in MS-DOS?
I think this is the correct behaviour, IIRC in theory in text files an
Hi!
12--2004 14:13 [EMAIL PROTECTED] (Alain) wrote to
[EMAIL PROTECTED]:
A Some very ols OS used ^Z do know the end of the stream and thus close
A the file. This behaciour can still be found in MS-DOS with the command:
A copy con: file
A where ^Z terminates the input.
Should be copy con
Hi,
On Fri, 12 Mar 2004 14:03:44 +0300 (MSK), Arkady V.Belousov wrote:
- /Odrive - use fixed drive number (in hex) in boot sector.
If this switch is intended for compatibility with DR-DOS, drive number
should be given in decimal. Support for hex with '0x' and/or '$' prefix
can be a nice
Hi!
12--2004 19:34 [EMAIL PROTECTED] (Michal H. Tyc) wrote to
[EMAIL PROTECTED]:
- /Odrive - use fixed drive number (in hex) in boot sector.
MHT If this switch is intended for compatibility with DR-DOS, drive number
MHT should be given in decimal. Support for hex with '0x' and/or '$' prefix
MHT
- /Odrive - use fixed drive number (in hex) in boot sector.
MHT If this switch is intended for compatibility with DR-DOS, drive number
MHT should be given in decimal. Support for hex with '0x' and/or '$' prefix
MHT can be a nice extension, though :-)
Inconsistent: address in /L option is
Hi!
12--2004 14:34 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to
[EMAIL PROTECTED]:
- /Odrive - use fixed drive number (in hex) in boot sector.
MHT If this switch is intended for compatibility with DR-DOS, drive number
This is rather functional compatablity, not syntaxtical.
Hi!
12--2004 15:24 [EMAIL PROTECTED] (Jim Lilly) wrote to
[EMAIL PROTECTED]:
JL What needs to be tested in the areas of FAT32 SYS booting code?
JL I've found FreeDOS hangs in booting off a ZIP 100 IDE disk formatted
JL FAT32, but boots fine off another ZIP disk formatted as FAT.
Get
Eric,
inline for easier discussion
Also, per your request I try copybs;
could you try with COPYBS from the SYSLINUX package?
Whether the ZIP disk is FAT -or- FAT32 formatted, I get;
D:\Downloadcopybs X: logfile.txt
ERROR: Boot sector read failed
I tried two different ZIP 100 disks, one
Arkady,
This is FAT16, so FAT size here should
be 190 sectors.
Hmmm, THAT particular disk should have been FAT32or I got confused.
Under which OS you run BOOTFIX?
WinXP Pro, and it's HD is NTFSfwiw.
--
Jim Lilly - Team Z
Arkady,
Yes, something is wrong.
I tried the only updating the boot sector using FreeDOS' SYS and got;
D:\Download\FreeDOSsys X: BOOTONLY
FreeDOS System Installer v2.9, Sep 24 2003
Processing boot sector...
Reading old bootsector from drive X:
Divide overflow
WinXP throws up an error
Arkady,
In prior message, ZIP disk was formatted FAT. Tried again with one as
FAT32 get same message.
--
Jim Lilly - Team Z
http://www.zonelabs.com/store/content/company/teamzBios.jsp
Using - Virtual Access(OLR), ZAP 4.5, WinXP Pro w/SP1
http://www.virtual-access.org
Hi Jim,
Yes, something is wrong.
I tried the only updating the boot sector using FreeDOS' SYS and got;
D:\Download\FreeDOSsys X: BOOTONLY
FreeDOS System Installer v2.9, Sep 24 2003
Processing boot sector...
Reading old bootsector from drive X:
Divide overflow
WinXP throws up an error message
Steve,
You really should be doing all of this stuff from a successful boot of some
stable DOS system ... and definitely outside of Windows XP.
That's for tomorrow morning, I'm getting ready to hit the sack. But I did want
to try several approaches from within WinXP first, as your new tool
Hi!
9--2004 08:30 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
Wrong. Should be: #if defined (__TURBOC__) __TURBOC__ = ...,
LG Borland C has also the manifest constant __BORLANDC__ which is
LG 0x200 for 2.0
[...]
...and in BC3.1 value of __BORLANDC__ equal to value
Hi!
7--2004 18:23 [EMAIL PROTECTED] (Matthias Paul) wrote to
[EMAIL PROTECTED]:
MP of DR DOS unless you would special case them. On the other hand, always
MP using the new form on any DOS 3.31+ the least does not cause any problems
MP under DR DOS, PC DOS or MS-DOS, even if the disk is smaller
On Mon, 8 Mar 2004 00:21:41 + (GMT), Bart Oldeman wrote:
Hmm. Further testing seems to reveal that this whole bit isn't valid, as
findfirst is not the same as a dir!
ie. this whole bit needs to be deleted.
/* Lixing Yuan Patch */
if (bAllowWildcards)/* for find first */
{
Hi!
8--2004 14:57 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
And this will be another mistake: in C/C++ standard `char' may be
signed, and _it is_ (by default) in BC. (But not in OW, BTW). Stupid, but
this is so.
This (troubles with sign extension) is why I
!
8--2004 20:46 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA like that, your software should do the right thing both when compiled
EA with TC and with BC - use an #ifdef __TURBOC__ ...
Wrong. Should be: #if defined (__TURBOC__) __TURBOC__ = ...,
where ... is a version of
Hi!
8--2004 21:34 [EMAIL PROTECTED] (Michal H. Tyc) wrote to
[EMAIL PROTECTED]:
#define isalnum(c) (_ctype[(c) + 1] (_IS_DIG | _IS_UPP | _IS_LOW))
BTW, BC anyway defines _ctype only as 128-byte table. :(
MHT Really? At least in BC 3.1, it is a 257-byte table (a zero
Ops, sorry, really
Wrong. Should be: #if defined (__TURBOC__) __TURBOC__ = ...,
where ... is a version of BC, which presents new style
absread()/abswrite().
Borland C has also the manifest constant __BORLANDC__ which is
0x200 for 2.0
0x400 for 3.0
0x410 for 3.1
0x452 for 4.0
0x460 for 4.5
0x500 for 5.0
0x520 for
On Sun, 7 Mar 2004, Luchezar Georgiev wrote:
The following log comment is slightly incorrect:
prf.c
Log Message:
Borland C (unlike Turbo C) didn't like this pseudo register use.
Actually, *both* Turbo and Borland C didn't like it!
This is strange. The old code has been there for
On Sun, 7 Mar 2004 16:37:43 + (GMT), Bart Oldeman wrote:
Actually, *both* Turbo and Borland C didn't like it!
This is strange. The old code has been there for ages even when we
compiled with Turbo C by default.
Yes, but the bug didn't reveal until MENUCOLOR and the 8-bit strings it
allows
On 2004-02-27, Alain Mouette wrote:
True that once long time ago it was discussed that the rebooting
method of jumping to certain BIOS point wasn't safe in the sense
that wasn't portable across BIOSes, but it was s long time ago
that I may be wrong.
Thanks :)
Well, it _allways_ was
On 2004-03-02, Luchezar Georgiev wrote:
Now you can exit any primary shell that allows that (all I've tried
but 4DOS do) and specify another one.
Yup. Sometimes, in particular during testing and in embedded system
applications it is very convenient that you can safely EXIT the
primary shell.
On Sun, 7 Mar 2004, Luchezar Georgiev wrote:
EXACTLY! Now I see that put_unsigned() and put_string in prf.obj have a
CBW instruction that does just that! So, what do you suggest? I think that
we can just apologise to KR and change c in put_console() to char.
or cast to unsigned char. That's
On 2004-02-25, Arkady V.Belousov wrote:
There is such (current) order of source and target in SYS:
SYS {options} targetdrive:
SYS {options} sourcedrive: targetdrive: [bootsector.file]
SYS {options} sourcepath targetdrive: [bootsector.file]
But there also possible to handle
Hi!
5--2004 19:31 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA Hi Arkady, for FAT32 drives, WinDOS returns on int 21.32 (get BPB),
EA when you use it as get default BPB, that:
EA - root dir size would be 512 entries
EA - FAT1x size would be as FAT32 size
What if FAT size
On Thu, 4 Mar 2004 09:28:29 +0100 (CET), Steffen Kaiser wrote:
The FSF boycotts Amazon (http://www.gnu.org/philosophy/amazon.html) and I agree with them, so I won't follow your advice :)
Well, this is kidding.
No, the smiley here is just to say sorry to Aitor :) Otherwise I'm *serious* here, no
On Wed, 3 Mar 2004, Luchezar Georgiev wrote:
On Tue, 2 Mar 2004 21:06:03 + (GMT), Bart Oldeman wrote:
at first sight it looks good to me, thanks! The one thing I saw that might
have to be changed is the location of the new stack. Since RBIL table 1690
(very end of interrupt.g)
On Wed, 3 Mar 2004 13:01:22 + (GMT), Bart Oldeman wrote:
Yes we should care! This area is used by all sorts of TSRs and network
redirectors that live under DOS. These fixed locations cannot be changed
without breaking apps that rely on undocumented DOS in various ways.
I see. Do you mean that
Hi,
Luchezar Georgiev escribio':
On Wed, 03 Mar 2004 18:16:40 +0100, Aitor Santamari'a Merino wrote:
Most is described in books such as Undocumented DOS.
Would be good to read, but not available here :-(
Of those many undocumented books series by A. Schulmann, only
UndocDOS was available in
Hi!
1--2004 18:11 [EMAIL PROTECTED] (Steve Gibson) wrote to
[EMAIL PROTECTED]:
RBIL says, that INT21/440D/CX=x84A expects BH on input (with some lock
level - what is it?). How be with this? Also, is it valid to perform
CX=08xA (not 48xA) on FAT32? Also, in current SYS there are no INT13
access;
Hi!
1--2004 10:54 [EMAIL PROTECTED] (Steve Gibson) wrote to
[EMAIL PROTECTED]:
Is using INT25/CX= always safe for all partitions - including small
(32M) and diskettes?
SG Yes, on all logical devices, so long as you have a FAT32-capable OS (ver
SG 7.0 or later)
I.e. using INT25/CX=-1
Hi!
1--2004 21:15 Arkady V.Belousov wrote to
[EMAIL PROTECTED]:
AVB __O\_/_\_/O__
AVB D-25-
AVB INT 25 - DOS 1+ - ABSOLUTE DISK READ (except partitions 32M)
AVB
Hi!
1--2004 19:40 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA Hi, about the DOS uses 'int' 0x25/0x26 as CALL FAR, so you have to POPF
EA when you call it through INT thread:
EA Several compilers TRANSPARENTLY handle this.
Of course, they (should) transparently handle this
On Mon, 1 Mar 2004, Arkady V.Belousov wrote:
__O\_/_\_/O__
int absread(int DosDrive, int nsects, int foo, void *diskReadPacket);
#pragma aux absread = \
int 0x25 \
sbb ax, ax\
parm [ax] [cx] [dx]
Hi!
1--2004 20:03 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
#pragma aux absread = \
int 0x25 \
sbb ax, ax\
modify [si di bp] \
Isn't there should be added POPF after INT 25h/26h?
I mean, POP (for example, pop ax,ax).
BO there
Hi!
1--2004 21:05 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO In the current sys it simply happens to work since the int 25/26 is
BO followed by mov sp, bp.
- BP itself should be preserved somewhere (because modify[]). Where if not
on stack?
BO that's a question for me
Hi!
1--2004 23:08 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA Bad news for UNDELETE that Borland C (not Turbo C) seems to have an
EA absread() which auto-decides about access style. Using the 32 MB
EA style for drives which Borland C detected as 32 MB with int 21.1c
EA will
Bart Oldeman wrote:
Why not use the I/O stack (char_api_tos)? When process0 terminates the
this may be possible but tricky in C. As the code must make sure it
doesn't use any stack that it relies from before int21/ah=4b after
int21/ah=4b.
I don't understand:
When process0 is about to be
Hallo Bart and Steffen,
It goes all the way back to kernel 2024a released Apr 16 2001. Before that
kernel there was a p_0() function in task.c.
Around that time we were making huge gains in the memory usage of the
kernel. First Tom implemented HMA support (before that the resident part
of the
On Sat, 28 Feb 2004 05:57:07 +0100 (MET), Eric Auer wrote:
if the old shell EXITs that does not necessarily mean that it FAILED.
Maybe the user simply selected something as shell which does allow him to exit.
So it is POSSIBLE that the user next wants to use the same shell again. Or
a typo in the
Luchezar Georgiev wrote:
I tried to change user_r-CS and user_r-IP, but the linker complained.
Well, but because those two are assigned to the terminate address of
process0, you must initialize them. Regardless from where you start the
Load-Process0 function.
Um, BTW: process0 must also have a
Following this discussion I looked at when and why I removed the
code we're talking about from HMA_TEXT.
It's not as easy as a mere code save.
It goes all the way back to kernel 2024a released Apr 16 2001. Before that
kernel there was a p_0() function in task.c.
Around that time we were making
On Thu, 26 Feb 2004 20:22:03 +0300 (MSK), Arkady V.Belousov wrote:
1. _How_ to perform reboot process?
2. How to be with (write delayed) caches?
OK, OK, you're both right - won't reboot right away! ;-)
1. command.com should prevent (if possibly) to exit from primary copy.
Would be good, but not
On Thu, 26 Feb 2004, Luchezar Georgiev wrote:
On Thu, 26 Feb 2004 08:48:17 +0100 (CET), Steffen Kaiser wrote:
As you showed, the reloading of the shell is performed by the kernel
in MS DOS. I do not suggest to copy this behaviour
Neither do I. ROM-DOS expects the user to type a new shell
Hi!
BTW, for checking target drive validness I add next code (where
`drive' is a drive letter):
__O\_/_\_/O__
{
static char src [] = :\\, dst [SYS_MAXPATH] /*= */;
src [0] = drive;
truename (dst, src);
if (dst [0] =
On Tue, 24 Feb 2004 14:22:36 + (GMT), Bart Oldeman wrote:
Good catch! I have now integrated your patch collection.
Thank you, Bart! I saw the patches in the CVS list.
Except that I opted to simply do
nasm -D_INIT -fobj -o iasmsupt.obj asmsupt.asm
This really doesn't make the makefile more
Hi!
23--2004 09:03 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to
[EMAIL PROTECTED]:
else if (memicmp(argp, BOTH, 4) == 0 !both)
- AIU, there should be stricmp() (or third parameter of memicmp() should be
increased to include zero byte)?
KJD Could, but its more of, are exact arguments here
Luchezar Georgiev escreveu:
Thanks - I just found and fixed it, see below!
It's allways amazing how small are the fixes for complex bugs like that ;-)
Good night now (here it's 10:10PM anyway), and have good (unbugged) dreams,
Alain
---
SF.Net
Hi!
16--2004 19:11 [EMAIL PROTECTED] (tom ehlert) wrote to Eric Auer
[EMAIL PROTECTED]:
EA Hi Tom, I think it is not ridiculous to have FAT32 on 186:
EA You can have 33 MB FAT32 partitions. Useful for embedded systems.
te a) I can't see where this would be useful (to format 33 MB with FAT32)
Here are my latest news. If I compile ALL the kernel for 80186, and ONLY the fmemcpy function in main.c for 80386 (using #pragma option -3 and -1, all the other functions in main.c are compiled for 80186 too), it crashes! I tried all other possible combinations, and it turned out that it doesn't
Hi!
13--2004 11:43 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to FreeDOS-kernel
[EMAIL PROTECTED]:
LG Did you receive or read the following message of mine I sent yesterday
LG morning?
LG http://sourceforge.net/mailarchive/message.php?msg_id=7191320
LG Do I need to re-send it? Because I can now
Hi!
14--2004 00:11 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA Hi, Arkady reminded me that fat32lba boot sector stores fat_secshift at
EA offset 0x68 of the boot sector, thus overwriting CODE !? This would break
EA metaboot (generic loader for MetaKern menu entries)
On Thu, 12 Feb 2004 13:34:33 +0300 (MSK), Arkady V.Belousov wrote:
Unfortunately, I don't know, how to turn return target processor option
back - target may be 386, but it may be also 8086. Probably, next (after
fmemcpy() definition) should work:
#ifdef __BORLANDC__
# pragma option -3.
#endif
Hello Luchezar,
LG Maybe later I could try it too... but first I must learn
LG Bochs!
try
DEVICE=C:\NUMEGA\S-ICE.EXE /TRA 30 /SYM 400
DEVICE=C:\system\himem.sys /TESTMEM:OFF
DEVICE=C:\NUMEGA\umb.sys
...
installhigh=
UMB.SYS is the s-ice UMB provider,
On Thu, 12 Feb 2004 16:41:58 + (GMT), Bart Oldeman wrote:
yes, please send me a minimal failing kernel + mapfile + minimal
config.sys and the command you're installing high (which should also be as
small as possible and open source).
Please leave kernel.sys *uncompressed*. This is very
On Wed, 11 Feb 2004, Luchezar Georgiev wrote:
INIT_FMEMCPY: |INIT_FMEMCPY:
enter 8,0|pushBP
mov DX,4[BP] |mov BP,SP
mov EAX,0Ah[BP]|
Hi!
8--2004 15:12 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to FreeDOS-kernel
[EMAIL PROTECTED]:
- if ((mode CDS_MODE_CHECK_DEV_PATH) (result IS_DEVICE)
- !(result IS_NETWORK) dest[2] != '/' !dir_exists(dest))
+ if ((mode CDS_MODE_CHECK_DEV_PATH)
+ ((result
Hi!
8--2004 16:48 [EMAIL PROTECTED] (Bart Oldeman) wrote to
FreeDOS-kernel [EMAIL PROTECTED]:
As to the other funny printf patch, it's only a temporary solution
until I find the reason why Borland 80386 build hangs if any INSTALL=
commands were processed, just before kernel() enters...
BO try
On Fri, 06 Feb 2004 17:56:04 -0200, Alain wrote:
[...] aPack-ed programs can be freely distributed for
non-commercial purposes, but otherwise require a license
(the fee is $29 for individual users and $95 for companies,
see http://www.ibsensoftware.com/products_aPACK.html).
i'm a little worried
Hello Eric,
EA Hi Tom, you are completely wrong about that virus. That it SEEMS
EA to come from Bart, Joe, MartinS, Brian, Jeremy, ... only means
EA that SOMEBODY is infected who knows all their addresses.
I wrote:
I assume at least one of you has both me ([EMAIL PROTECTED]) and above
adresses
Eric Auer wrote:
Hi Tom, you are completely wrong about that virus. That it SEEMS
to come from Bart, Joe, MartinS, Brian, Jeremy, ... only means
that SOMEBODY is infected who knows all their addresses. Modern
viruses scan the system for addresses and randomly select one
address as target and
Hi Lucho,
I've now prepared the precompiled kernel binary (OpenWatcom 1.2,
FAT32, 8086) in ROMDSK this way. [...]
Just for My Information: Aren't Fat32 versions to be compiled in 386
mode (and fat16 in 8086) ?
IIRC this was discussed here and the consensus (more or less) was that a
machine
)
Subject: Re: [Freedos-kernel] Installing FreeDOS on a FAT32 partition 1024
Cyl...
On Thu, 5 Feb 2004, Martin Bogomolni wrote:
dd if=/dev/zero of=/dev/hda bs=512 count=63 (kill trk0)
fdisk the system to make a 16MiB partition on /dev/hda1, filesystem type 0x0b
mkdosfs -F32 /dev/hda1
Before I get flamed... (caught my typo too late. -sigh-)
MiB (Mibibyte/Mebibyte) == 2^20 bytes
KiB (Kibibyte/Kebibyte) == 2^10 bytes
-Martin
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools
Hi!
4--2004 12:27 [EMAIL PROTECTED] (Bart Oldeman) wrote to
FreeDOS-kernel [EMAIL PROTECTED]:
very welcome (plus the 1.3 KB saving from aPack ;-) And Borland C++ 5.2
is still used by Datalight for their ROM-DOS, so albeit inferior to
Watcom, it can't be ignored, can it? The more so as I'm
1001 - 1070 of 1070 matches
Mail list logo
