Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have experiemented with some of my machines and none of them support the E820 with greater than 20 bytes being returned. I still need to look at my wife's laptop (brand new HP Pavillion). I have run a test on:
Bochs 2.2.1: Only reports available RAM and nothing else, and 20 bytes
Bochs 2.3: More comprehensive report, though only 20 bytes.
Virtual PC: Comprehensive report, though only 20 bytes.
VMWare 5.5.2: Comprehensive report, though only 20 bytes.
DOSBox 6.5: No report, but says it returns 1D7h bytes, weird!
MSI MB with AMD 3000+: Comprehensive report, only 20 bytes.
ASUS MB with AMD 2000+: Comprehensive report, only 20 bytes.
Once I clean up the code (FASM code) I will post it here so others can run the test on their systems to see if any of the system out there are supporting 24 bytes or not.
Last edited by smiddy on Wed Nov 15, 2006 10:22 am, edited 2 times in total.
none of them support the E820 with greater than 20 bytes being returned
.
"All parts should go together without forcing. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1975
ACPI 3.0 specs INT 15h AX=E820h as having extended attributes, which extends the record size to 24 bytes. None of the tested items returned (indicated inthe ECX) more than 20 bytes, except for DOSBox, which gave a really weird answer and no descernable data.
I ran the test on my wife's laptop and it doesn't provide more than 20 bytes per record either (I'll have to get the BIOS date and specifics to post them here later this evening). I'll post the code tonight and instructions on its use. I'll also post an example output so you will know what to expect.
Please use this code to test your systems to see if you have a machine capable of INT 15h AX=E820 with extended attributes. Nothing Ive tested has the extended attributes. The following are two different results, one based and run off DOS and the other booted directly:
I see:
----------------------------------------------
Test E820 boot v1.00
Any key
----------------------------------------------
When I pres a key nothing happens.Tried with qemu, bochs and on my laptop.
"All parts should go together without forcing. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1975
Please describe to me how you setup the system. I assume you put the BootE820.bin onto a floppy and then copied the E820.EXE there also, correct? It looks like the boot program isn't recognizing the E820.EXE program since it doesn't count the number of sectors it read for the program. Additionally, if the boot program doesn't recognize the E820.EXE file from the root directory of the floppy, then it will just hang and do nothing else. If for some reason the E820.EXE is written to the floppy directory structure in lower case it will not recognize it either (non-DOS FAT12 standard).
I don't have a floppy.I'm using a USB stick.Would you change the drive number to 0x80 and replace int 13h AH=2h to int 13h AH=42h and post it, please.
"All parts should go together without forcing. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1975
You're certainly welcome to do that yourself. The current FASM compiler can be found here. Also, I am not certain about your convention on the drive numbering since I haven't used USB Flash drives before. Also, I'm not familiar with that INT 13h call, so I would have to research it further before implementing it. Or perhaps you can explain it further?
However, if you can make a floppy image for Bochs and QEMU it should work. Though I already know Bochs doesn't support the new extended attributes and suspect QEMU is the same. If you can boot DOS you can simply run the file too.
I've never experienced with FASM.Is the syntax similar to NASM?
"All parts should go together without forcing. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1975
USB will probably not work, but you may be lucky and your USB emulates floppy, but its not the drive number thats the problem, as it gets this from Bootblock, but its more likely that the Fat code needs to be for fat16, rather than floppy fat12 for USB to work, as most emulate hdd.
May a ISO for cd burn would be good, or a dos com prog, so you can sys file your usb fob and run the com file from the prompt.
I had a post about that USB booting a while ago.My MBR is using this int 13h AH=42h extended function and it boots from the USB stick smoothly on all laptops I've tested.The problem is with the Desktop PCs.
I read trough the smiddy's code and found that NASM is equal to FASM .I will replace the Ah=2h function with AH=42h and will post the sorce and the binary here.
By the way Qemu's output is the same as Bochs's.
"All parts should go together without forcing. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1975
muisei wrote:I had a post about that USB booting a while ago.My MBR is using this int 13h AH=42h extended function and it boots from the USB stick smoothly on all laptops I've tested.The problem is with the Desktop PCs.
Maybe laptops are more likely to emulate floppys, as your more likely to use a USB floppy drive from laptop
muisei wrote:I had a post about that USB booting a while ago.My MBR is using this int 13h AH=42h extended function and it boots from the USB stick smoothly on all laptops I've tested.The problem is with the Desktop PCs.
Maybe laptops are more likely to emulate floppys, as your more likely to use a USB floppy drive from laptop
I would more guess the dates on the BIOSes themselves, since laptop bioses have to take more things into account than desktop bioses, if only because they're usually using more recently developed mobile cpu's and are required to have functioning power control. I wasn't sure whether USB devices would be able to use int13/ah=42 but your message confirms this for me. That's good.
.I will replace the Ah=2h function with AH=42h and will post the sorce and the binary here.
