From: muta...@gmail.com   
      
   On Friday, March 24, 2023 at 1:37:40 AM UTC+8, wolfgang kern wrote:   
      
   > >> So what is the UEFI equivalent to INT13 and how can I make it boot my    
   > >> old stuff from either CD or USB ?    
   >    
   > > As mentioned, if all you need is a bit of code loaded,    
   > > you don't need to anything at all except plonk a    
   > > bootx64.efi into \efi\boot of a FAT-formatted disk.   
      
   > here I have my first problem:    
   > with a new assembled PC I get a main-board with a CD that contains only    
   > a few drivers for windoze loonix and Mac, nothing boot able on it.    
   > the HDs are all empty, not formatted in any usable mode.    
      
   You have an existing PC, right?   
      
   So ignore the CD that came with the new PC.   
      
   On your old PC create a FAT-formatted USB stick,   
   or Joliet CD.   
      
   With the bootx64.ef on it.   
      
   And then boot from CD or USB stick (you may need to go   
   into the BIOS settings to choose to allow booting from   
   those devices).   
      
   > So it would need me to buy a win11-DVD which I wont ever do.    
   > any suggestion ? I'd need a boot able formatting tool first.    
      
   What do you currently use?   
      
   If you want to use someone else's OS that is capable of   
   formatting a disk and also capable of booting on UEFI,   
   and it can't be Windows, and it can't be Linux, I am not   
   familiar with that market. FreeBSD? PDOS/386 only   
   works with a BIOS system currently. PDOS-generic will   
   do UEFI but it is still proof-of-concept. It will basically   
   reuse the existing code though, so it shouldn't be a   
   big deal. The big deal is me trying to get it to do   
   unusual things like running 32-bit code in 64-bit mode   
   before taking it out of POC.   
      
   > Next demand would be a tool which can create folders.    
      
   That tool is normally called an OS, but there are some   
   tools called "mtools", and a fairly recent public domain   
   version too, that do that to a disk image.   
      
   On PDOS/386 I can make that disk image an actual   
   raw disk, which is what I use for formatting.   
      
   The tools are included on the PDOS/386 image.   
      
   They're written in C90 so you can run them on any other   
   system you can find (after recompilation).   
      
   > And then such a tool must be able to copy my OS-boot-image    
   > into a bootx64.efi perhaps at a certain offset dunno yet how    
   > .efi files were organized (I may find some info on the net)    
   > but the hex-dumps below show that you created M$ PE-files.    
      
   Yes, there is no choice. You need to create a PE executable.   
      
   It's just a normal PE executable, with the sole exception that   
   the subsystem number is set to 10. So that's one byte that   
   needs to change (plus the checksum, as that byte is included).   
      
   The linker will do this for you.   
      
   It's unclear to me what restrictions you are introducing,   
   or why, but I know of two linkers that produce 64-bit   
   PE files, both running under Windows, and neither   
   supplied with any version of PDOS. But if you just   
   want a single binary with 100k of "ret" or "nop" or x'00',   
   I can provide that for you.   
      
   > one more problem: my OS-images incl. boot-part are just a bunch of    
   > consecutive sectors (can be seen and stored as .bin files)    
   > no header, no redirection, very own checksum algo.   
      
   That can be embedded in the PE file. It's just code.   
      
   But you would need to take care of relocation yourself   
   if you are just zapping bytes instead of using a linker.   
      
   > > # So for testing, comment out the jmp and add 2 rets   
   > dup 64 ret ;wouldn't one be enough?    
      
   I didn't know the syntax.   
      
   > ;where would this return go to ?   
      
   The BIOS.   
      
   That above code is entered (from UEFI) via a call.   
      
   There will be 2 parameters (in registers, not on the   
   stack - that's the Microsoft 64-bit calling convention).   
      
   You would normally never return.   
      
   I returned just for illustration purposes.   
      
   And looped for illustration purposes too.   
      
   > so I assume the first 64 bytes are special purpose ?    
      
   No. If it was 64 bytes, that was just an accident. I just   
   typed in ret and then used micro-emacs and did ctrl-y   
   a large number of times so that you had some space   
   to zap.   
      
   > [...]there is no assembler :) and rare ever will be.   
      
   You want to enter machine code, right?   
      
   So all I did was make space for testing purposes.   
   I used serial port as an example. I am guessing you   
   can send a single byte to the serial port in that   
   amount of space.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)