Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

So I made changes to the following files

config.b
* Added recognition of new CPU arch's
* Keep from clobbering arguments when using buildall.bat

build.bat
* Added recognition of new CPU arch's

buildall.bat
* Added new CPU arch's as build targets

mkfiles/generic.mak
* Added recognition of new CPU arch's and translation to wcc options

mkfiles/watcom.mak
* Added new CPU arch's to fallback arch test

These are the kernels that get compiled out of buildall.bat
KWC18616 MAP84,748  05-02-2013  7:55p
KWC18616 SYS63,028  05-02-2013  7:55p
KWC18632 MAP84,977  05-02-2013  7:55p
KWC18632 SYS67,180  05-02-2013  7:55p
KWC28616 MAP84,748  05-02-2013  7:55p
KWC28616 SYS63,028  05-02-2013  7:55p
KWC28632 MAP84,977  05-02-2013  7:55p
KWC28632 SYS67,180  05-02-2013  7:55p
KWC38616 MAP87,053  05-02-2013  7:54p
KWC38616 SYS62,164  05-02-2013  7:54p
KWC38632 MAP87,282  05-02-2013  7:54p
KWC38632 SYS66,044  05-02-2013  7:54p
KWC48616 MAP84,748  05-02-2013  7:54p
KWC48616 SYS62,068  05-02-2013  7:54p
KWC48632 MAP84,977  05-02-2013  7:54p
KWC48632 SYS65,948  05-02-2013  7:54p
KWC58616 MAP84,748  05-02-2013  7:54p
KWC58616 SYS62,068  05-02-2013  7:54p
KWC58632 MAP84,977  05-02-2013  7:54p
KWC58632 SYS65,948  05-02-2013  7:54p
KWC68616 MAP84,748  05-02-2013  7:53p
KWC68616 SYS62,068  05-02-2013  7:53p
KWC68632 MAP84,977  05-02-2013  7:53p
KWC68632 SYS65,948  05-02-2013  7:53p
KWC8616  MAP84,748  05-02-2013  7:56p
KWC8616  SYS64,158  05-02-2013  7:56p
KWC8632  MAP84,977  05-02-2013  7:55p
KWC8632  SYS68,358  05-02-2013  7:55p

-L

-L



On Thu, May 2, 2013 at 11:48 PM, Eric Auer  wrote:

>
> Hoi Louis,
>
> please explain the hack / patch: Is the only thing that
> you changed that the kernel is compiled for those CPUs?
> Are there actually any differences between them? I can
> imagine that OpenWatcom makes 186 and 286 the same and
> everything above 386 the same. Unless the kernel would
> contain heavy mathematical processing for which it is
> obvious that above-386 optimizes better ;-) You could
> tell the compiler to produce Assembly output (instead
> of binary) and compare the text. Or you could use some
> debug, disassembler (ndisasm?) or hex editor to compare
> before you UPX things, but of course that is more work.
>
> Thanks for comparing :-) Maybe this is more a topic for
> the kernel list. Note that if "a few" bytes are really
> only 10 or so, all this is probably more an "academic"
> exercise. Things get more exciting once you can save at
> least a cluster of disk space or a paragraph of RAM :-)
>
> Regards, Eric
>
> > I hacked the 2041 kernel batch and make files included on the FD 1.1 iso
> to
> > allow the kernel to be built by OpenWatcom as 8086, 186, 286, 386, 486,
> > 586, or 686.  The resulting 686 kernel boots fine in VirtualBox 4.2.12 in
> > OSX 10.8.3 on my 2012 Mac Book Air 13" 4GB.  The resulting kernel is a
> few
> > bytes smaller compressed by upx than kernel installed by the FD 1.1 iso.
> >  I'm going to continue testing.  No source changes were made.  Not sure
> how
> > the changes affect the nasm built files.
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Freedos-user mailing list
> freedos-u...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

On Fri, May 3, 2013 at 4:02 AM, Eric Auer  wrote:

>
> Hi Louis,
>
> if I understand your patch correctly, you only changed the
> build configuration to check how it affects the size of
> the compiled kernel before UPX compression, which also is
> an indicator of RAM size of the kernel? You changed the
> config.b, build.bat, buildall.bat files and generic.mak
> and watcom.mak and the resulting kernel sizes give the
> impression that in fact you only have FOUR distinct CPU
> optimizations, rather than seven cases...
>
> Yes.  And just ran md5sum's against the kernels to verify this

3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
623498bd71a46d16bcef211e743a9bed  kwc38616.sys
c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

69eb7732f791db340632f722c9dbce16  kwc8632.sys
f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
1e4fd656603fd09171d9d85631e77045  kwc28632.sys
b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for
the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't
know much about 586+ arch's but can use the instructions in special
situations.  And this makes sense when you consider when Watcom fell out of
favor commercially and probably saw it's last real optimizer work.


> Kernels without FAT32:
>
> 086: 64158 bytes
> 186: 63028 bytes (286 same)
> 386: 62164 bytes
> 486: 62068 bytes (586 and 686 same)
>
> Kernels with FAT32:
>
> 086: 68358 bytes
> 186: 67180 bytes (286 same)
> 386: 66044 bytes
> 486: 65948 bytes (586 and 686 same)
>
> [SNIP]

 Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
in the kernel now and possibly the string functions.  But just an idea
right now.

-L
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

What's the difference between wcc & wcc386?  I noticed that wcc386 adds
-5s, -5r, -fp5 (-6 equivalents) for stack, register and fpu optimization.
 Does wcc386 generate code that could be used in the kernel?

-L


On Fri, May 3, 2013 at 5:57 AM, Louis Santillan  wrote:

> On Fri, May 3, 2013 at 4:02 AM, Eric Auer  wrote:
>
>>
>> Hi Louis,
>>
>> if I understand your patch correctly, you only changed the
>> build configuration to check how it affects the size of
>> the compiled kernel before UPX compression, which also is
>> an indicator of RAM size of the kernel? You changed the
>> config.b, build.bat, buildall.bat files and generic.mak
>> and watcom.mak and the resulting kernel sizes give the
>> impression that in fact you only have FOUR distinct CPU
>> optimizations, rather than seven cases...
>>
>> Yes.  And just ran md5sum's against the kernels to verify this
>
> 3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
> 40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
> 2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
> 623498bd71a46d16bcef211e743a9bed  kwc38616.sys
> c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
> c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
> c3a607792ba8a0c8c8705dd370180619  kwc68616.sys
>
> 69eb7732f791db340632f722c9dbce16  kwc8632.sys
> f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
> 1e4fd656603fd09171d9d85631e77045  kwc28632.sys
> b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
> e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
> e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
> e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys
>
> ...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for
> the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't
> know much about 586+ arch's but can use the instructions in special
> situations.  And this makes sense when you consider when Watcom fell out of
> favor commercially and probably saw it's last real optimizer work.
>
>
>> Kernels without FAT32:
>>
>> 086: 64158 bytes
>> 186: 63028 bytes (286 same)
>> 386: 62164 bytes
>> 486: 62068 bytes (586 and 686 same)
>>
>> Kernels with FAT32:
>>
>> 086: 68358 bytes
>> 186: 67180 bytes (286 same)
>> 386: 66044 bytes
>> 486: 65948 bytes (586 and 686 same)
>>
>> [SNIP]
>
>  Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
> in the kernel now and possibly the string functions.  But just an idea
> right now.
>
> -L
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

I'll have to post my files when I get back from Disneyland tonight.  Some
initial thoughts about the byte savings, things like LEA got and loop
unrolling got super efficient with later processors.  It wasn't just about
the new instructions but upgrades & new forms of old instructions. TASM
used to be real good about picking efficient opcodes.

-L

On Friday, May 3, 2013, Tom Ehlert wrote:

> > Kernels with FAT32:
>
> > 086: 68358 bytes
> > 186: 67180 bytes (286 same)
> > 386: 66044 bytes
> > 486: 65948 bytes (586 and 686 same)
>
>
>
> > It is interesting that even 186 instructions do make a
> > quite big difference and that there is a difference at
> > all between 386 and 486. With 186, you get pusha and
> > popa, shift/rotate by fixed numbers of bits.
> ENTER
> LEAVE
>
> > In the past, we compiled kernels for 8086, 186 and
> > 386 separately afair. I guess we got lazy and have
> > dropped 186 because very few users have 186/286 as
> > their CPU? They either have modern or REALLY old.
> this is not about 'lazy'
> it's easier for the user to select between 2 choices then between
> 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
>
> there's not much use for a 186 kernel as NOBODY has 186/286 machines
> these days,
>
> > Also, we keep offering 8086 compiles for the sake
> > of good old times and for people with emulators.
>
>
>
> > The 386 optimization is useful and we already used
> > it: Having 32 bit computations helps even for DOS.
> > There are also some new bit string opcodes, SETCC
> > (conditional set a byte)
> nothing of this is used by the compiler
>
> >  JCXZ
> was always supported
>
> >  and near conditional
> > jumps and loops that are supported starting at 386.
> *far* conditional jumps started with 386.
>
> however what *IS* used by wcc is
>the additional FS and GS register
> some (few)
>  push DWORD constant
>
> what would be useful, but is not used by WCC
>  dword arithmetic
> filesystem code uses long variables everywhere
>
>
>
> > Your 486 to 686 kernels are the same size and 486s
> > only XADD and BSWAP (and CMPXCHG). It is impressive
> > that those actually make any (100 byte) difference!
>
> strange enough, compiling here with -3 and -6 makes exactly no
> difference. using watcom 1.9
>
> could you post the compiled files, or even
>
>   for %i in (*.obj) do wdis -l -a -s %i
>
> for -3 and -6 and show us the differences ?
>
>
> > Maybe your compiles assume that 486 does and 386
> > does not have FPU? That would not be very accurate.
> pointless as the kernel doesn't use any FPU code
>
>
>
> > As with 286, the news in 586 is mostly protected
> > mode related (simply speaking). Neither CMPXCHG8B
> > nor the time stamp counter nor CPUID bothers DOS.
>
>
> > The main news in 686 would be CMOV, a conditional
> > MOV, but looking only at kernel sizes, it is likely
> > that the compiler just does not use CMOV for 686.
> > It is odd to get exactly the same size otherwise.
> it doesn't use cmov
>
>
> > For even newer CPU, you could use FPU and vector
> > (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+,
> > SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions
> > but it is highly unlikely that those make any DOS
> > difference. At most they could speed up memmove.
> as the kernel doesn't much memcpy/memmove, you can't accelerate it
> by any significant amount.otherwise we *would* have
>   rep movsD
>
> tom
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

Haha...I'd be interested if you ever developed a 586 core at 1GHz that
could utilize DDR-3 upto 4GB.


On Sat, May 4, 2013 at 1:43 AM, ht-lab  wrote:

> On 03/05/2013 15:55, Tom Ehlert wrote:
>
> >> In the past, we compiled kernels for 8086, 186 and
> >> 386 separately afair. I guess we got lazy and have
> >> dropped 186 because very few users have 186/286 as
> >> their CPU? They either have modern or REALLY old.
> > this is not about 'lazy'
> > it's easier for the user to select between 2 choices then between
> > 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
> >
> > there's not much use for a 186 kernel as NOBODY has 186/286 machines
> > these days,
> Really, NOBODY.
>
> Hans
> www.ht-lab.com
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

Whoops, didn't realize that I replied to fd-user instead of kernel.

One other note, all kernels are slightly bigger withe options I set.

-L

-- Forwarded message --
From: Louis Santillan 
Date: Sun, May 5, 2013 at 9:01 AM
Subject: Re: [Freedos-user] Any interest in 486, 586, 686 kernels?
To: "Discussion and general questions about FreeDOS." <
freedos-u...@lists.sourceforge.net>


Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles.  Read (
ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections
2.3.x & 3.5.  Enlightening and disappointing.  There does not seem to be a
way to get 32-bit instructions out of wcc as Tom had mentioned.  3.5
recommends

"The recommended options for generating the fastest 16-bit Intel code are:
Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6
Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5
486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3
386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3
286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2
186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87
8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87"

-ot of -onatx & -zp8 contradict the original makefile's code -os & -zp1
(optimize execution time vs. executable size & align on byte vs. 8-byte,
respectively).  Also, the -fp*'s opts don't apply and wcc barfs on -oi+.

So in mkfiles\watcom.mk I added some code to add -6-onaxlkh-ei (for 686).
 This will reorder instruction significantly and replace some call nears
with jmps in a comparison of 386 timed code vs. 686 timed code.  Code is
larger on the 686 side.

So far, not very impressed with OW 1.9's optimizer. Rather minimal
improvements.  Anybody play with BCC 5.5 & HX-DOS recently?

-L



On Sat, May 4, 2013 at 3:27 AM, Tom Ehlert  wrote:

> Hallo Herr Louis Santillan,
>
>
> > https://sites.google.com/site/lpsantil/Home/386DIS.ZIP
> > https://sites.google.com/site/lpsantil/Home/686DIS.ZIP
> > https://sites.google.com/site/lpsantil/Home/PATCHES.ZIP
> > https://sites.google.com/site/lpsantil/Home/kernels.zip
>
> the differenz is an empty memdisk.lst (for whatever reason)
> everything else is *identical*
>
> I'm not impressed
>
> Tom
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Freedos-user mailing list
> freedos-u...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

See inline...

On Sun, May 5, 2013 at 9:43 AM, Bernd Blaauw  wrote:

> Louis Santillan schreef op 5-5-2013 18:28:
> > Whoops, didn't realize that I replied to fd-user instead of kernel.
> >
> > One other note, all kernels are slightly bigger withe options I set.
>
> I guess it depends on what the compilers do:
> [1] optimize for certain processor architecture(s)
> [2] also keep backwards compatibility or not with lowest desired level
>
> if [2] then the binary might be larger on disk.
>
> If someone likes a real challenge, a smaller kernel can be produced
> using UPX --8086 --lzma --ultra-brute
> (instead of UPX --8086 --best) but the end-result is not bootable,
> requiring a decompressor stub. Savings is about 3KB disk footprint.
>

Why does it fail?  Relocation?


> As for the MEMDISK support there's additional support implemented at
> https://github.com/PerditionC/fdkernel but it requires me to first
> create additional testcases using some kind of floppy image file.
> Basically it allows specifying a CONFIG.SYS line at Syslinux menu so you
> can alternate memory driver in a menu for example, or specify UMB
> regions, that kind of stuff
>
>
What were the 0xDC change mentioned in the readme?
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

fdoos.org seems to be down at the moment.  Forgot to mention that in case
Jeremy is around.


On Sun, May 5, 2013 at 8:42 PM, Louis Santillan  wrote:

> See inline...
>
> On Sun, May 5, 2013 at 9:43 AM, Bernd Blaauw  wrote:
>
>> Louis Santillan schreef op 5-5-2013 18:28:
>> > Whoops, didn't realize that I replied to fd-user instead of kernel.
>> >
>> > One other note, all kernels are slightly bigger withe options I set.
>>
>> I guess it depends on what the compilers do:
>> [1] optimize for certain processor architecture(s)
>> [2] also keep backwards compatibility or not with lowest desired level
>>
>> if [2] then the binary might be larger on disk.
>>
>> If someone likes a real challenge, a smaller kernel can be produced
>> using UPX --8086 --lzma --ultra-brute
>> (instead of UPX --8086 --best) but the end-result is not bootable,
>> requiring a decompressor stub. Savings is about 3KB disk footprint.
>>
>
> Why does it fail?  Relocation?
>
>
>> As for the MEMDISK support there's additional support implemented at
>> https://github.com/PerditionC/fdkernel but it requires me to first
>> create additional testcases using some kind of floppy image file.
>> Basically it allows specifying a CONFIG.SYS line at Syslinux menu so you
>> can alternate memory driver in a menu for example, or specify UMB
>> regions, that kind of stuff
>>
>>
> What were the 0xDC change mentioned in the readme?
>
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

I apologize for mis-posting to fd-user previously.

On Thu, May 16, 2013 at 10:47 AM, Tom Ehlert  wrote:

> Dear Louis,
>
> a few points
>
> a) the FreeDOS project isn't very interested in a BC5 compiled
> kernel because BC5 isn't freely available/open source;
> I also doubt the output of BC5 will be significant better then the OW
> output.
> feel free to experiment, but don't expect us to be excited ;)


I'm not sure how you can say the FreeDOS project isn't interested in a BC5
kernel.  The BC5 makefiles I found in the kernel sources I didn't write.
 Bart last worked on them 9 years ago.  Bit rotten for sure and OW became
usable in that time.  So yes, priorities change, but I'm taking the posted
FreeDOS Roadmap, as goals and stretch goals for the project.  I read
(paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit
& 64-bit support, device driver imports, automated regression testing. I've
done a couple of simple tests and I am getting 32-bit register code from my
copy of BC5.  The Roadmap is reason enough for me, personally, to continue
to 'experiment' as you say.  There's no way of getting 32-bit real mode
code from OW.  So for now, until someone teaches OW some new tricks, I'll
work with BC5.



> > So, something in the make files/build files is skipping building a
> concrete
> > GLOBAL for ReturnAnyDosVersionExpected for BC5.  There's a MAIN define
> > checked but the build process doesn't seem to get defined anywhere. :/
>
> b) when trying to port the kernel to a new compiler, you should be
> able to fix such issues yourself. generate assembler output, see what
> is wrong. you will need this as the FreeDOS uses the
>  'interesting memory model (TM)'


Again, I'm not doing any porting.  And I do intend to work this issue.
 However, software development, like many human endeavors, is best done
collaboratively & socially, IMO.  If someone in the last 9 years has
compiled the kernel with BC5, they might have tips for me.  Heck, I
remember when the kernel was TASM/BC only, and only a select few could
afford to contribute.  I advocated back then (almost 15 years ago) for
porting to open tools.  I'm glad the early FreeCOM/Kernel developers had
made the effort to port to open tools.


> > Need to do more digging.
> c) no need to write 'need more digging' type of mails. use your
> twitter account for that.
>

I don't have a twitter account.  Feel free to filter emails from me to your
spambox.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

On Sun, May 19, 2013 at 7:06 PM, Eric Auer  wrote:

>
> Hi Louis,
>
> sort of a long response - it seems hard to make a short point here:
>
> > FreeDOS Roadmap, as goals and stretch goals for the project.  I read
> > (paraphrasing): built-in networking, built-in USB, integrated DPMI,
> 32-bit
>
> The fd32 project works or worked on the DPMI aspect. As far as I
> remember, the performance gain was minimal, but consider interest
> in terms of style to consider a protected mode kernel which has
> both DPMI and VM86 visibility. It would be a sort of DOSBOX then.
>

I would expect performance gain to be minimal.  Maybe there could be
Low/HMA/UMB memory savings with a different architecture.  Hard to say.


> Regarding built-in networking and USB, I am personally more for
> the existing loadable driver model. The BIOS gives you enough
> support to reach the point where you can load drivers in config
> sys. Even when booting via network (PXE) or from CD/DVD/BD, you
> can still use a MEMDISK (bootable ramdisk) to get started...
>

I lean this way too w/respect to drivers.  Built-in's biggest advantage is
simplicity in user configuration. However, networking seems to be lacking
throughput speed with either mTCP or Watt32 apps.  I'm not sure if it's a
packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue.  My
guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy
networking, and the switch between kernel and app.  I've seen some
reference to the same issue on USB drivers as well (USB 1.1 speed from USB
2.0 devices or 3.0 devices).  And there seems to be 3 ways to get USB
working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method.  I need to play with
those.



> On the other hand, I think it would be an interesting experiment
> to have a kernel which can load files from at least the root dir
> of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can
> directly interpret GPT partition tables. The latter would have
> significant practical use. Not the former: When you boot from
> CD/DVD/BD, you do typically want a writeable ramdisk anyway, so
> you can just as well boot with the help of a MEMDISK which lets
> you load DOS CD/... drivers from there, making drivers for that
> as fixed parts of the kernel less interesting. Also, they are
> harder to update than separate drivers and you cannot easily
> skip them at boot to save DOS memory.
>

Yes! I agree!  The FD Kernel needs to speak MBR, GPT, ISO9660 & UDF
(including El Torito), NTFS, Ext2/3/4 to stay relevant.  Probably HFS+ as
well.  Linux and/or FUSE should be helpful here.



> Good question whether you want built-in USB: I would say no, you
> already need the BIOS to help to boot from USB. After that, you
> want a modular system of USB drivers (unless the BIOS provides
> support for all relevant USB devices) to let you access disks,
> sticks, mice, keyboards and so on. Also, devices for which there
>

I'd want FD to be USB-ready (built-in or driver) for Floppy,
Zip/Jaz/SparQ/LS-120 (similar drives), HDD, CD/DVD/BD, mice,
gamepads/joysticks, keyboards.



> is no popular DOS or BIOS interface, such as network or sound,
> cannot have kernel drivers in a useful way. For networking, the
> packet driver interface is just one facet in a complex world, we
> could think about some additions to make it easier to write new
> drivers or to do common things with the network. For sound, the
> lack of popular interfaces means that you basically have to use
> protected mode to simulate a popular HARDWARE (SoundBlaster etc)
> and then let your actual driver play whatever the soundblaster
> would have played given the detected I/O with the simulation.




I think Jim Hall's suggestion of a virtualized OS is more applicable here.
 Something like MOL (Mac On Linux), or QEMU User Space Emulation (ala Wine)
with device redirection to generic hardware might be best.


>
> > & 64-bit support, device driver imports, automated regression testing.
>
> Some automated or semi-automatic quality checks seem interesting.
> One could think of code style checks, audits, automated comparison
> of how well different artificial test cases or real software runs
> work with different kernel (micro-) versions in some VM etcetera.
>

Just need people to start writing tests. :D



>
> Regarding 64 bit support, there are some experiments with letting
> DPMI drivers use more than 4 GB of RAM. To make better use of it,
> you would have to define new interfaces (XMS, EMS, DPMI, VCPI...)
> and hope that DOS software would be written which uses them.
>

I've seen cwsdpmi r7 supports upto 64GB address space.  Some new interfaces
might be nice to program to, but I'd advocate step one to be making use of
such extensions transparent to old programs.  I'd only count on BIOS or
other specialty hardware/firmware developers to be interested in such new
interfaces.


> Just using 32- or 64-bit calculations (not RAM addresses) is another
> story: Probably the kernel can be smaller by using more 3

Re: [Freedos-kernel] Free tools for FreeDos

[Louis Santillan]

You may wish to speak to the bttr folks
(http://www.bttr-software.de/),
especially if your tools are DOS generic. They've started hosting DOS tools
like yours.  Also talk to Rugxulo as he has upload access to ibiblio,
especially if the source is FreeDOS and GPL/OSS compatible.

-L
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] [Freedos-devel] Regarding Issue with FreeDOS.

[Louis Santillan]

Autoexec.bat and config.sys would likely be useful here, especially to
understand the value of LASTDRIVE and to know if any other disk drive
drivers are installed (CDROM, SATA, USB, Zip, etc.).

Ideally, everyone matches MS-DOS, so knowing what functest returns there
might help.

On Sunday, September 14, 2014, Anil Nair  wrote:

> Hello All,
>
> We were working on PDOS development particularly interrupt number Int
> 21/AH=0Eh(Select Default Drive). While testing the PDOS function i came
> across a particular behaviour in FreeDOS, according to the description
> given in the documentation "http://www.ctyme.com/intr/rb-2570.htm";
>
> "Return: AL = number of potentially valid drive letters".
>
> When tested using a function PDOS returns,
>
> Booting from Hard Disk...
> welcome to PDOS-16
> welcome to pcomm
>
> C:\>functest
>
> The return value is x 4 x
>
> C:\>
>
> While testing the same behaviour in FreeDOS,
>
> C:\DEVEL\PDOS\SRC>functest
>
> The return value is x 5 x
>
> C:\DEVEL\PDOS\SRC>
>
> Is this expected? Please let me know if anybody needs more details.
>
> --
> Regards,
> Anil Nair
>
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] EXT3 support

[Louis Santillan]

Hiren's BootCD has had something called Paragon Mount Everything 3.0.
Or are you interested in writing a new driver?

On Fri, Aug 14, 2015 at 1:28 PM, Ralf Quint  wrote:
> On 8/14/2015 12:38 AM, Daniel G. wrote:
>> Greetings,
>>
>> I was reading the FreeDOS development wish-list and adding ext3
>> support to the FreeDOS kernel is on the list.  Is anyone working on
>> this at this time?
>>
> Doubtful. It's more likely just wishful thinking from someone who
> doesn't know what all might be involved in actually implementing this...
>
> Ralf
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> --
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] EXT3 support

[Louis Santillan]

Maybe, but ext3 was designed as a multithreading FS.  The
multithreading becomes single threading so performance would far
worse, and possibly even worse than FAT16/32 or ext3 over redirector.

On Fri, Aug 14, 2015 at 3:00 PM, Till  wrote:
>
> Quoting João Jerónimo :
>
>> Wouldn't it be better to use a redirector? This can be done with a TSR.
>>
>> João Jerónimo
>>
>
>
> A TSR redirector would be great for assigning an EXT3 drive to a drive
> letter for standard I/O operations.  However a kernel driver would
> allow freeDOS to boot and run from an EXT3 journaling partition, I can
> only imagine that the benefits from this would be huge.
>
>
>
> --
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

[Louis Santillan]

Method 1 is the traditional DOS way of installing software.

Maybe some advanced usage of JOIN & SUBST is what you are looking for?

Another alternative (though slightly messy) would be to combine
Methods 1 & 4.  By that, I mean, leave the *.bats in C:\DOS.  The
*.bats will temporarily create a new Environment & PATH extended as
the application expects and then remove the adjustment.  This will
slow down many types of computing, as HPA mentioned, SW builds come to
mind

-L.

On Tue, Nov 29, 2016 at 2:54 PM, Mateusz Viste  wrote:
> On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
>> But why the batch file in the first place?  It truly makes no sense: it
>> pollutes the namespace equally, and can just cause problems (e.g. in the
>> case of more than 9 arguments.)  Not to mention slowing down a make.
>
> Here's the thing: I, as a user, store lots of useful software on my PC.
> Many of these programs are so useful that I like to have them available
> immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
> QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
>
> To achieve this, I know of four ways. Each comes with some limitations.
>
> Method 1: Store every program in its own directory, and add each
> directory to the %PATH%. Problem: obviously the environment will get very
> bloated, very fast. Besides, some programs come with add-on tools that I
> do not want to be available from within my path.
>
> Method 2: Trim out the programs from everything besides a single exe, and
> put them all in a single directory declared in my %PATH%. But this poses
> two problems that I cannot live with: first, not every program can be
> trimmed out to a single executable file (data files, config files, etc),
> and second - almost all programs come with their respective README files
> and other valuable documentation that I really want to keep within the
> vicinity of the executable (ie. in the same directory).
>
> Method 3: Store each tool in its own directory, and place a COPY of its
> executable inside a directory in the %PATH%. Well, this is just messy -
> upgrading the program needs to think about replacing the executable each
> time in both places, and it's simply a waste of disk space.
>
> Method 4: Keep each program in its own directory with all its original
> files, and only store *.bat "links" in a single directory somewhere in
> the PATH. This mitigates the troubles of methods 1 and 2, at the cost,
> unfortunately, of *.bat's own limitations (max 9 args and '=' processing
> weirdness).
>
> The method 4 is what I started doing back in the nineties, and as of
> today I still didn't find a better (or let's say, less worse) way. That's
> a lifetime project it would seem.
>
> The method 4 is also something that I implemented last year inside FDNPKG
> (the FreeDOS package manager), but since I discovered recently how oddly
> the '=' character is processed in %1-like arguments (there's a separate
> thread about that on freedos-devel), I will have to figure out some
> improved method... first thought pointed to computing some COM loader
> relying on INT21,4Bh but that's far less trivial than the current batch
> method, and hobby time is scarce.
>
> Mateusz
>
>
> --
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] How do I compile just the bootsector and kernel?

[Louis Santillan]

See the FreeDOS Spec [0].  OpenWatcom C/C++ (1.9?) (and by extension
WASM/JWASM? for ASM??) and NASM (no version either though many are
based on 0.98.x) are the reference compilers/assemblers/linker.

I was able to able to compile a recent kernel version with the
non-reference compiler Borland C/C++ 4.5.2 (the last Borland C/C++
compiler to support DOS compiling executables).  I had to make minor
changes to the Makefiles to successfully compile the kernel.  See the
mailing list archives for my notes.

[0] http://wiki.freedos.org/wiki/index.php/FreeDOS_Spec#Programming_tools

On Wed, Jan 4, 2017 at 11:17 PM, Mateusz Viste  wrote:
> On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote:
>> Of all the many files in the FreeDOS sourcecode, which files will I need
>> if I just want to compile the bootsector and the kernel?
>
> You'll need the source files present in the "KERNEL" package,
> unsurprisingly. You can also fetch these sources on-line here:
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/
>
>> And also, what is the recommended free compiler (I'm
>> not about to spend money to buy one) for use in compiling the FreeDOS
>> bootsector and kernel?
>
> The FreeDOS kernel can supposedly be compiled with the following
> compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C.
> >From those, I have tested successfully Open Watcom and Turbo C 2.01. Both
> are free (no cost). Using Turbo C requires to change a few lines of
> comments though, as I wrote here the 26th November of last year (still
> not fixed on SVN).
>
> Mateusz
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel