Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi, 2007/7/23, Bart Oldeman <[EMAIL PROTECTED]>: > Although the ioctl.c restructuring is good, most of the chario.c > savings also help. A lot more could be saved in initdisk.c by using > the fact that the sector size equals 512 (the DOS code cannot assume > that with ram disks etc, but the BIOS code needs to assume 512 because > the BIOS int13 does not support any other size AFAIK -- though I've > heard Aitor claiming some things about an old AT I do not understand > how that can work -- what BIOS interface to use to figure out that > sectors have 1024 bytes?). I put away the case a bit, but at that time I seem to remember that some hints then seemed to suggest that perhaps other sector size was being used, although your argument about the int13 is quite more convincing. With time I ended up believing that it's simple that the BPB is not correct. A pitty that I barely have access back to that machine (and old 286 machine), as I have my old PCs scattered across many different places, where I wanted to test with some disk checking tool created by Arkady long time ago, provided that the tool is still useable. So next time I see a window to acceed this machine, I'll ask Arkady for the tool and check it out. The most surprising test was that the drive could be correctly acceeded if you boot from a floppy, but you CAN'T boot from it. But then it was before I looked over the kernel sources, so could not even figure what was going on. Aitor - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi Bart, > I was looking into merging parts of UNSTABLE a few months ago but > it's a lot of work since I don't like about half of the changes. Actually I think it might take man-months or more to review all the MANY changes between unstable and stable, plus merge all the fixes of stable into unstable first. > or two on FreeDOS. There are funny space savings in text strings just > so that Lucho could get the compressed kernel under 40K. I found one > bug in the inittext.c optimizations by Arkady. And so on. Space should not be everything. But for people who do care a lot about space, it would be better to have several subsystems compile time selectable, for example "any COUNTRY support at all, internal or external" or "FCB support" and so on. Many patches of UNSTABLE are indeed peephole optimizations which can make the code very hard to read. Be glad you did not try to debug CuteMouse, for example ;-). So one has to be very careful / meticulous (?) / thorough / diligent when porting things from the UNSTABLE kernel to the stable / svn trunk "branch". > the BIOS int13 does not support any other size AFAIK I think there were Japanese diskette formats with 1k sector size? Probably not bootable, though. Same for optical WORM drives. > External country.sys and more windows 3.x support never hurt. Yes. Especially the int2f stuff should be reasonably easy to port. > Removing the internal country table makes things a little bit more > dependent (Tom's point of having the internal table is that you don't > need a country.sys file if all you want is the correct date-month-year > display). Of course the internal table is not good for the 40K aim. I do like the internal table a lot and it UPXes well afaik but, as said, one could make the internal table and support for external country sys both a compile time option, including the option to compile a kernel with neither of the two enabled. In either case, there are still - few - unimplemented functions which should be added to stable before we start adding tuning stuff from unstable into stable if you ask me. Bugfixes from unstable are welcome in stable, of course, esp if smallish. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
On 7/21/07, Eric Auer <[EMAIL PROTECTED]> wrote: > Are there any volunteers to maintain the UNSTABLE > branch of the kernel? I was looking into merging parts of UNSTABLE a few months ago but it's a lot of work since I don't like about half of the changes. And after that I ran out of time, and still am, just now spending a spare hour or two on FreeDOS. There are funny space savings in text strings just so that Lucho could get the compressed kernel under 40K. I found one bug in the inittext.c optimizations by Arkady. And so on. Although the ioctl.c restructuring is good, most of the chario.c savings also help. A lot more could be saved in initdisk.c by using the fact that the sector size equals 512 (the DOS code cannot assume that with ram disks etc, but the BIOS code needs to assume 512 because the BIOS int13 does not support any other size AFAIK -- though I've heard Aitor claiming some things about an old AT I do not understand how that can work -- what BIOS interface to use to figure out that sectors have 1024 bytes?). External country.sys and more windows 3.x support never hurt. Removing the internal country table makes things a little bit more dependent (Tom's point of having the internal table is that you don't need a country.sys file if all you want is the correct date-month-year display). Of course the internal table is not good for the 40K aim. Bart - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
On 7/22/07, Eric Auer <[EMAIL PROTECTED]> wrote: > > again, I think that only IRQTEXT is what broke Bochs compatibility. > So I applied a patch (revision 1341) which leaves the other 1325 > changes intact. Jemm FASTBOOT should work with version 1341. > > With the 1325 IRQTEXT, all versions (1325 to 1340) failed in Bochs > at some point around the PostConfig kernel relocate moment, even > if no HMA was available. No idea why - 1341 is based on intuition > and experiments, not on theoretical knowledge why IRQTEXT was bad. The problem was that the irqstacks.asm init (for config.sys STACKS=n where n>0) was setting up the wrong segments for IRQ vectors. It should be correct now in SVN (tested with Bochs). IRQTEXT needs to be present to force the saved IVT vectors to be at 70:100, which is the RBIL documented location; otherwise they are stored somewhere else. Bart - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Eric Auer schreef: > Hi Bernd, > *your KERNEL.SYS in renewed archive works fine, nice job. [ http://www.coli.uni-saarland.de/~eric/ke2007jul21.zip ] *JEMMEX v5.64 can be compressed and works, can't see it listed in MEM /C ( MEM /C /N ) listing though, maybe it\s hiding under SYSTEM :) (UMBs provided, Shellhigh works with Freecom loaded high) *No idea how to get Fastboot working, any reference platform/emulator to see it in action? (didn't try the additional driver as Eric said kernel binary should work out of the box) Bernd - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Eric Auer schreef: > Please test :-) > You relying on me to test or does this new binary work for you in Bochs? >> Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip >> same filename yet updated release? Bernd - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi again, after checking > http://freedos.svn.sourceforge.net/viewvc/freedos?view=rev&revision=1325 again, I think that only IRQTEXT is what broke Bochs compatibility. So I applied a patch (revision 1341) which leaves the other 1325 changes intact. Jemm FASTBOOT should work with version 1341. With the 1325 IRQTEXT, all versions (1325 to 1340) failed in Bochs at some point around the PostConfig kernel relocate moment, even if no HMA was available. No idea why - 1341 is based on intuition and experiments, not on theoretical knowledge why IRQTEXT was bad. Please test :-) > Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip Eric PS: Summary of the 1341 patch: 1. kernel/segs.inc -group LGROUP _IRQTEXT _LOWTEXT _IO_TEXT _IO_FIXED_DATA _TEXT +group LGROUP _LOWTEXT _IO_TEXT _IO_FIXED_DATA _TEXT -segment_IRQTEXTclass=LCODE 2. kernel/irqstack.asm -segment_IRQTEXT +segment_LOWTEXT - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi Bernd,
> Only KERNEL2.SYS works for me, better than the Fastboot supporting
> kernel I downloaded (I think) a while ago.
> KERNEL.SYS in your zip hangs my machine at the HMA/BUFFERS message.
Yes, I have the same problem :-(. What I did to create kernel2 is
to undo the changes of SVN revision 1325:
http://freedos.svn.sourceforge.net/viewvc/freedos?view=rev&revision=1325
This change adds FASTBOOT support but also moves irqstack into
another segment. I have no idea why, but this and all later
revisions crash when the kernel tries to load the shell and/or
tries to move into the HMA (it even happens when no HIMEM is
loaded, though) in Bochs. It never crashes in Dosemu, though!
The only relevant difference I could find is that the DOS_PSP
at 60:0 shows that int 22..24 vectors moved from d1:xx to d4:xx
(and that JFT and SS:SP differ, of course). I did a binary search
to find where the crash got introduced, starting at 1315 and 1333
(1334 is fcbfns.c int 21.29, 1335 is initial lastdrive, 1336/1337
are 8086 compatibility and "cli in int19", 1338-1340 are by me).
It is possible that some OTHER version in 1326-1332 range works.
Bart, as you did most changes in that range, could you please test
and comment? I did not know whether you are on the kernel list,
so I CCed you, just in case...
So what went wrong here? The new IRQ handling / FASTBOOT support?
Or maybe a later revision fixed that and introduced some other
issue, related to the new UPX / exeflat style added there?
> > 1. This should make Robert happy. The kernel now produces messages
> >as "UMBs unavailable!" instead of ("Dutch") "UMB's unavailable!"
> >Dutch is the only language where "plural's" are correct, I think.
> >
> Depends, normally the [s] is added, but some english terms like 'baby'
> are plural with ['s].
> Also depends what the kernel is trying to say:
> *UMB ['s/is] unavailable
> *UMBs unavailable
> *UMBs are unavailable
I would not shorten the "is" into "'s" in any other context than
"it's nice" and similar. Other sounds, hmm, very "spoken language".
But baby never has a plural with 's outside the Dutch language :-p.
Merriam Webster: www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=baby
> > 3. Usage: keybuf=n[,m]
> > Relocate keyboard buffer from the default location at
> > 0x40:0x1e-0x3e to 0x40:n-m...
> what's the benefit of this? a larger keyboard input buffer like
> Dos 7.10 (1024chars) ?
Yes! I did not know MS DOS 7.10 has this, details? Rugxulo uses a
device driver which allocates 0.5k (256 chars) and moves the buffer
there (only works if device ends up in first 65 kB of RAM). I found
out that Bochs uses 40:b9 for VBE, so if I move the buffer there, I
break FDAPM's Bochs-detection, so it crashes in APMDOS mode again
as the Bochs APM BIOS has a bug. Plus VBE stops working ;-). As you
can see, KEYBUF is not super tame. However, 0x120-0x1d0 (maybe even
0x108-0x1e0) works perfectly in all tested contexts, 108 chars is
already much better than the default 16 chars :-).
> offtopic questions: are Japheth's drivers compressed by UPX or
I can gzip them to 2/3 of their normal size, so I would say they
are not compressed at all. You should ask Japheth if this is by
design (cannot be UPXed) or just because he did not compress them.
> A single binary '286 XMS driver' + '386 XMS driver' + '386
> EMS/UMB/VCPI/VDS driver' + '386 XMS/EMS' driver would be fun :)
As said several times, I dislike the "XMS+EMS combined" style
of JEMMEX because you cannot test the XMS/HMA and EMS/UMB part
separately any more. But that may be a question of taste.
If you had a "XMS only" mode in JEMMEX, then it would probably
be a very different implementation compared to a classic HIMEM.
Having built-in 286 drivers does not sound useful to me. The
few people with a 286 should better use special 286 drivers.
Eric
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Eric Auer schreef:
> Hi Rugxulo, Robert, kernel people,
>
Hello Eric,
> branch of the kernel? Rugxulo, KEYBUF should obsolete having a
> "keyboard extender" around. Kernel people, IDLEHALT does not
> obsolete FDAPM APMDOS but it gives you some energy-saving even
> without FDAPM. I hope both can be used in parallel w/o problems.
>
What's a keyboard extender exactly and what does it do?
> Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip
>
Only KERNEL2.SYS works for me, better than the Fastboot supporting
kernel I downloaded (I think) a while ago.
KERNEL.SYS in your archive hangs my machine at the HMA/BUFFERS message.
> 1. This should make Robert happy. The kernel now produces messages
>as "UMBs unavailable!" instead of ("Dutch") "UMB's unavailable!"
>Dutch is the only language where "plural's" are correct, I think.
>
Depends, normally the [s] is added, but some english terms like 'baby'
are plural with ['s].
Also depends what the kernel is trying to say:
*UMB ['s/is] unavailable
*UMBs unavailable
*UMBs are unavailable
> 3. Usage: keybuf=n[,m]
> where n is in 0xac-0xde or 0x106-0x1de range and m is <= 0x200
> Relocate keyboard buffer from the default location at
> 0x40:0x1e-0x3e to 0x40:n-m. The buffer must be more
> than 32 bytes and must not touch offsets 0x100-0x105.
> Default for m is "next multiple of 0x100 after n"
> ...
> A reasonably safe choice should be "keybuf=0x140,0x1c0".
>
what's the benefit of this? a larger keyboard input buffer like Dos 7.10
(1024chars) ?
All in all I'd suggest finding out what changed which makes Bochs and my
system unhappy.
Thanks for having a usable FreeDOS system again. Now to make that DOS
Sioux webserver running from a Ramdisk :)
Slightly offtopic questions: are Japheth's drivers compressed by UPX or
do they support compression? 35KB disksize for a driver is a bit much.
A single binary '286 XMS driver' + '386 XMS driver' + '386
EMS/UMB/VCPI/VDS driver' + '386 XMS/EMS' driver would be fun :)
Bernd
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] fresh freedos svn kernel updates
Hi Rugxulo, Robert, kernel people,
I finally figured out svn at home, so I updated three areas
of the stable "branch" of the FreeDOS kernel in svn. Actually
only UNSTABLE is a branch, stable is the default. Anyway.
The three changes vary a lot in complexity. Fixing language
glitches was easy. The keyboard trick is purely in config.c
and the documentation. The HLT thing was much harder, as two
new global items had to be introduced... The changes are:
1 fixed "Dutch plurals" at various places
2 added IDLEHALT config sys option (see below)
3 added KEYBUF config sys option (see below)
Bart, could you check my lsm / version / history changes and
add your changes to the history file? As "suggested" a while
ago, I added myself to the maintainer list in the lsm. Jeremy,
is that okay? Are there any volunteers to maintain the UNSTABLE
branch of the kernel? Rugxulo, KEYBUF should obsolete having a
"keyboard extender" around. Kernel people, IDLEHALT does not
obsolete FDAPM APMDOS but it gives you some energy-saving even
without FDAPM. I hope both can be used in parallel w/o problems.
Please check / test / comment! Thanks :-)
Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip
Eric
1. This should make Robert happy. The kernel now produces messages
as "UMBs unavailable!" instead of ("Dutch") "UMB's unavailable!"
Dutch is the only language where "plural's" are correct, I think.
2. Usage: idlehalt=n
where n can be -1, 0, 1 or higher (default 0)
Activates built-in kernel energy saving functionality if n is
not 0. Value -1 enables all hooks, 1 enables only "safe" hooks,
CPU halted only if kernel is waiting for CON char device input.
Further hooks for n=-1 and n>0 depend on the kernel version...
...
3. Usage: keybuf=n[,m]
where n is in 0xac-0xde or 0x106-0x1de range and m is <= 0x200
Relocate keyboard buffer from the default location at
0x40:0x1e-0x3e to 0x40:n-m. The buffer must be more
than 32 bytes and must not touch offsets 0x100-0x105.
Default for m is "next multiple of 0x100 after n"
...
A reasonably safe choice should be "keybuf=0x140,0x1c0".
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
