Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?
I'm not sure how you can say the FreeDOS project isn't interested in a BC5 kernel. because I was around when the kernel was ported to MSVC, BC5, OW (in that order) The BC5 makefiles I found in the kernel sources I didn't write. Bart last worked on them 9 years ago. right. an since OW became an *free* option, MSVC and BC were dropped Bit rotten for sure the last time I checked bits don't rot 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. all great - and so far off reality that is isn't even funny. is was never even discussed, let alone agreed upon. I've done a couple of simple tests and I am getting 32-bit register code from my copy of BC5. of course this is a huge step towards 'built in USB, 64 bit, bla' 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. OW outputs enough 32-bit real mode code to get the job done. is the BC5 code smaller/faster in a significant way ? 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. it was a pleasure ;) tom -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ 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?
Hi! Your vision on DOS is somewhat, well, interesting ;-) So there is a lot to chat about, although I am not sure if the KERNEL list is the right place for this topic. DPMI: I would expect performance gain to be minimal. Maybe there could be Low/HMA/UMB memory savings with a different architecture. Hard to say. Well there could, but why would it matter? More heavy DOS software normally uses DOS extenders / DPMI anyway, which means it does not care about how much low DOS RAM is free. The HMA is mostly used for the kernel and buffers, so as long as the kernel fits in there, no others have a heavy need for it. Only a few drivers may use it UMB style. Also, caches put bigger buffers in XMS, not needing HMA. Finally UMB is mostly used for drivers: You could write drivers that use DOS extenders / DPMI if you really have a lack of space. Actually the simulation of SoundBlaster 16 that comes with SoundBlaster PCI works like that. Probably also some commercial NTFS drivers, because NTFS is complex and you do not want to spend 100s of kilobytes of DOS memory only for loading a filesystem driver... USB, PXE and CD/DVD/BD drivers as drivers / in memdisk: I lean this way too w/respect to drivers. Built-in's biggest advantage is You still have to configure built-in drivers, you only avoid the risk that you forget to include the file in your boot disk ;-) 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. Networking in DOS means that your app has a compiled-in network stack which communicates with a packet driver to get the low-level hardware stuff done. You often have a small buffer for that and little concurrency. There may be a bit of IRQ and DMA, but big operating systems are more relaxed about juggling with multiple streams of net data with support from complex chips on your network card. Note that this is just an educated guess: Ask our experts! 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 No switch: The kernel does not network at all and there is only one app at a time using the network. Depending on how your packet driver and network stack library work, you do not need many steps of copying either and the transfer to or from a buffer is unlikely to be a big bottleneck with modern CPU, I think. However, as said, you probably work with little bits of data and small buffers in DOS, because you may have less orchestration between stack and driver. reference to the same ... 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 That problem far much more trivial than you might think: USB 2 and 3 are controlled in ways that differ a lot from USB 1, so many drivers simply do not talk USB 2 or 3 at all. This is not like AGP, PCI or PCIe where you flip a few bits and suddenly I/O to your graphics card is fast. It is more like the difference between paged graphics at a000:0 and a linear framebuffer, to stay in the example. However, there is no linear USB. Talking USB the 2 or 3 way is just a quite different language, but as you know, at least one shareware driver speaks it and knows the dialect of at least some relatively widespread chips... working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play Enjoy :-) And maybe do some benchmarks. Even the shareware driver should work long enough for that - I think it just blocks after a while after each boot, but is not locked in terms of how many days or years you have it installed. 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... 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. Uhm no. You do not agree ;-) Yes the kernel should speak both MBR and GPT. Something about 4k sector size is also a good idea. However, El Torito is only so-so as CD/DVD/BD driver and Jack's drivers are probably better. It would be fun from an academic point of view to have ElTorito-ISO9660-GPT in a kernel, but even Linux works great with kernels-without-any- disk-drivers when you put the drivers in the boot-ramdisk to load them as separate files from there. DOS with MEMDISK is basically the same. Having (separately loaded) drivers for ISO9660 (we do, even with long file name support) and UDF (only experimental and abandoned??) is indeed important for DOS. Also, somebody may want to undust the old EXT2 semi-drivers called LTOOLS, they probably still have some sort of ancient limitation such as lacking LBA support or getting
Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?
I still think having true functions in batch files would be a good thing turn batch files into more capable language On Tuesday, May 21, 2013, Eric Auer wrote: Hi! Your vision on DOS is somewhat, well, interesting ;-) So there is a lot to chat about, although I am not sure if the KERNEL list is the right place for this topic. DPMI: I would expect performance gain to be minimal. Maybe there could be Low/HMA/UMB memory savings with a different architecture. Hard to say. Well there could, but why would it matter? More heavy DOS software normally uses DOS extenders / DPMI anyway, which means it does not care about how much low DOS RAM is free. The HMA is mostly used for the kernel and buffers, so as long as the kernel fits in there, no others have a heavy need for it. Only a few drivers may use it UMB style. Also, caches put bigger buffers in XMS, not needing HMA. Finally UMB is mostly used for drivers: You could write drivers that use DOS extenders / DPMI if you really have a lack of space. Actually the simulation of SoundBlaster 16 that comes with SoundBlaster PCI works like that. Probably also some commercial NTFS drivers, because NTFS is complex and you do not want to spend 100s of kilobytes of DOS memory only for loading a filesystem driver... USB, PXE and CD/DVD/BD drivers as drivers / in memdisk: I lean this way too w/respect to drivers. Built-in's biggest advantage is You still have to configure built-in drivers, you only avoid the risk that you forget to include the file in your boot disk ;-) 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. Networking in DOS means that your app has a compiled-in network stack which communicates with a packet driver to get the low-level hardware stuff done. You often have a small buffer for that and little concurrency. There may be a bit of IRQ and DMA, but big operating systems are more relaxed about juggling with multiple streams of net data with support from complex chips on your network card. Note that this is just an educated guess: Ask our experts! 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 No switch: The kernel does not network at all and there is only one app at a time using the network. Depending on how your packet driver and network stack library work, you do not need many steps of copying either and the transfer to or from a buffer is unlikely to be a big bottleneck with modern CPU, I think. However, as said, you probably work with little bits of data and small buffers in DOS, because you may have less orchestration between stack and driver. reference to the same ... 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 That problem far much more trivial than you might think: USB 2 and 3 are controlled in ways that differ a lot from USB 1, so many drivers simply do not talk USB 2 or 3 at all. This is not like AGP, PCI or PCIe where you flip a few bits and suddenly I/O to your graphics card is fast. It is more like the difference between paged graphics at a000:0 and a linear framebuffer, to stay in the example. However, there is no linear USB. Talking USB the 2 or 3 way is just a quite different language, but as you know, at least one shareware driver speaks it and knows the dialect of at least some relatively widespread chips... working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play Enjoy :-) And maybe do some benchmarks. Even the shareware driver should work long enough for that - I think it just blocks after a while after each boot, but is not locked in terms of how many days or years you have it installed. 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... 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. Uhm no. You do not agree ;-) Yes the kernel should speak both MBR and GPT. Something about 4k sector size is also a good idea. However, El Torito is only so-so as CD/DVD/BD driver and Jack's drivers are probably better. It would be fun from an academic point of view to have ElTorito-ISO9660-GPT in a kernel, but even Linux works great with kernels-without-any- disk-drivers when you put the drivers in the boot-ramdisk to load them as separate files from there. DOS with MEMDISK is basically the same. Having (separately loaded) drivers for ISO9660 (we do, even with long file name
