From: muta...@gmail.com   
      
   On Friday, December 2, 2022 at 1:23:12 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
      
   > for high density ones. But apparenty Chi-Writer issued   
   > an OS call per sector and DOS/BIOS was too slow to immediately   
   > write next sector after previous one and had to wait full   
   > revolution. Here blame was shared by DOS/BIOS and Chi-Writer,   
   > IIUC it was possible to do full track read/writes using BIOS.   
      
   Crikey - you expect the OS to be so fast that it can get   
   the next sector ready? I'm not trying to compete in that   
   market.   
      
   > And do not be fooled by emulation. When you run Hercules   
   > emulated CPU may be 20 MIPS. But major part of mainframe   
   > is I/O subsytem and using Hercules you are in fact using   
   > I/O subsystem of modern OS. There is some overhead to   
   > emulate IBM CKD discs, but compared to overhead for CPU   
   > emulation I/O overhead is tiny. So in Hercules you get   
   > excelenet I/O performace. There is no way that real 20   
   > MIPS mainframe could match that. Similar things applay   
   > to Bochs: in Bochs emulated CPU is quite slow while I/O   
   > runs with all modern improvements. There is good chance   
   > that program which runs fast enough under Bochs would be   
   > dog slow on real hardware, even with faster hardware   
   > processor.   
      
   I run PDOS on real hardware too. The bottleneck (for the   
   work I do) is in the GCC optimized compiles, not I/O.   
      
   But yes, I agree that the OS should do caching to allow   
   the application to bottleneck on CPU (actually, memory   
   access I think). PDOS doesn't do that caching, but   
   real I/O hardware is compensating for that currently.   
      
   I'm still more interested in bugs and theory than   
   performance.   
      
   > > Memory size: 00019a10 (104976.)   
      
   > Late Microsoft COMMAND.COM is 54619 bytes. Earlier were much   
   > smaller (but had less functionality). COMMAND.COM from   
   > early FreeDos is 67399 bytes. This one is probably larger   
      
   Sure. I'm not competing there. I'm happy to link in the   
   entire C library.   
      
   I didn't know in advance how big things would be.   
   Now I know.   
      
   > > The latter wastes about 15k on big buffers that it doesn't   
   > > really need. But 15k isn't going to make or break this design,   
   > > so I'm not attempting to save that. I need to upgrade from   
   > > RM16, it's as simple as that. PDOS isn't designed for 640k.   
   > > Microsoft and Freedos can have that market.   
      
   > I see. So you want PM16 and bigger machines? Or just assume   
   > at least 32 bits with resonable amout of memory?   
      
   I want both solutions.   
      
   32-bit won't run my 16-bit MSDOS executables that "follow the rules".   
   Yes, I understand that I can recompile from source, but I want both   
   things to work.   
      
   I want my 16-bit programs that "follow the rules" to work on   
   MSDOS in 640k, work on a Turbo 186 with access to 16 MiB   
   of memory, and work on an 80386 with access to 256 or   
   512 MiB depending on whether I choose PM16 or PM32 with   
   the D-bit set to 16-bit. And a theoretical 4 GiB on other hardware   
   too. I may or may not do 80286 too, using a triple-fault to get   
   back to RM16 quickly so that I can continue to make BIOS   
   calls. I researched timings previously and triple fault is fine.   
      
   I guess that is something I am doing - fleshing out combinations.   
   That's why I am also interested in running on other systems like   
   the Amiga (68020, not sure about 68000 as it requires extra   
   runtime support functions).   
      
   Basically I want to have a basic OS, that runs anywhere, that   
   can then be used to write a much better OS.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)