From: muta...@gmail.com   
      
   On Tuesday, July 13, 2021 at 11:55:44 PM UTC+10, Scott Lurndal wrote:   
      
   > >> We have a team of a dozen engineers working on ours.   
   > >   
   > >Ok. (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )   
      
   > Ah, but the "application visible" portion of the BIOS (e.g. the   
   > interrupts that Paul is so fond of) is a very, very small part   
   > of the BIOS.   
   >   
   > The vast majority of it is processor-specific code to initailize   
   > the hardware (memory controllers, mainboard i2c components,   
   > PCI/PCIe controllers (link training, PCI discovery), serialize   
   /deserializers,   
   > processor microcode loading, and a hundred other things that   
   > most people aren't aware of.   
      
   You mentioned the BIOS above - not sure if this means   
   you support 16-bit INT calls - but is there any barrier to   
   you having a little bit of 16-bit code behind those INTs   
   that switches to 32-bit mode to run C code to do all   
   your work?   
      
   > >As for what is required to build a new firmware image, I'm assuming   
   > >that Paul will start with some open source project like Coreboot   
   > >(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers " ...   
   > >offer coreboot alongside their standard BIOS ..." according to   
   > >Wikipedia, which also lists a UEFI BIOS project, TianoCore, among   
   > >others. In other words, if Paul acquires the correct hardware, the   
   > >work of programming both the hardware and non-hardware portions of the   
   > >BIOS or UEFI are done for him.   
      
   > Those have very limited hardware support. Very limited.   
      
   I don't mind paying more for a computer, but I do need to   
   be able to tell someone in the Philippines - go to a computer   
   store and ask for a computer with xyz specs so that I will   
   be able to flash abc so as to support PDOS/386.   
      
   From my initial investigations, it seems that this "very   
   limited hardware support" actually entails "well, there's   
   this one thing, but it doesn't even have a case".   
      
   That's not what I'm looking for. I can put up with only   
   10% of computers being flashable, or maybe even only   
   1%. But computers that don't even have a case don't   
   even appear as a count.   
      
   > Not to mention the SMM code - a significant challenge to develop without   
   > access to proprietary specifications from the mainboard and processor   
   > vendors.   
      
   Everything you have said has suggested that the firmware   
   is off-limits.   
      
   But there is such a thing as an "option ROM". I'm not entirely   
   sure what that is, but do even 10% or 1% of computers allow   
   me to flash one of those?   
      
   As far as I can tell, a BOOTX64.EFI containing maybe   
   3000 lines of code, mainly 64-bit C code, but maybe   
   1000 lines of 16-bit assembler and C, will do what I   
   want, which is to restore a mini-BIOS on a UEFI-only   
   machine. I only need a few interrupts - 13H, 10H   
   and 14H.   
      
   Is there really no way, even on 1% of currently manufactured   
   computers, to get that 3000 lines of code off my hard disk   
   and into the firmware so that I don't need to have any   
   subdirectories at all on my FAT-16 disks? I shipped an   
   image a couple of days ago that only had IO.SYS, MSDOS.SYS   
   and COMMAND.COM. It won't run Win32 programs - you are   
   required to add kernel32.dll and msvcrt.dll yourself, but it   
   does boot and will run a.out programs with nothing further,   
   even though I discourage that.   
      
   I would like that disk image to work, unchanged. It doesn't   
   even use INT 14H.   
      
   Thanks. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)