firadisk issue

In E2B, I was previously using this grub4dos line:

map --mem (md)+4 (99)

to create a 2k area of memory as device (99).

 

I would use that memory area to write a firadisk command into, e.g. where %~pnx1 is the WinPE ISO file...

write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:%~pnx1;\n\0 > nul

Now I found a problem with the way some 0.4.6a versions of grub4dos used some areas of memory on certain systems (details are not important, bug was just in a few versions) and so I changed the line in an attempt to try and work around the issue by using a larger memory area so it would work with any version of grub4dos...

map --mem (md)+0x800 (99)

However, it seems that when a Windows OS containing the Firadisk driver is booted (such as Strelec WinPE ISOs), the firadisk driver now does not load the ISO as a virtual CD-rom device any more!

 

This happens with all versions of grub4dos I have tested (about 3 spread out over various dates, both 0.4.6a and 0.4.5c).

 

I am not quite sure why simply defining a larger memory area for device (99) causes the firadisk driver to not work.

Does anyone have any ideas why this is happening?

Which other "intermediate" sizes have you tried?

 

Maybe you just went over some "hardcoded" limit.

 

In decimal that is 4 vs. 2048, anything like 16, 128, 256, 512, 1024 may well be  limited in either grub4dos or firadisk.

 

Most likely 256 (255) aka 0xFF, i.e. a single byte.

 

Wonko

I am testing under VBox, so memory map is  start=800 hex sectors, Length=56B780 sectors, End=56BF80 sectors as shown by displaymem command in grub4dos.

 

Using a size for (99) of 4 sectors and up to 0x7F8 works OK and firadisk loads the ISO, but a size of 0x7F9 and larger causes firadisk to not load the ISO.

 

Attached shows the memory map allocation for sizes 4, 7f8 and 7f9.

 

So the memory position of the bytes written seems to vary, with the bytes for 0x7F9 being at 56B780 and for 0x7F8 being at 56B788...

 

0x56BF78 sectors x 0x200 =  AD7EF000 (4 = OK)

0x56B788 sectors x 0x200 =  AD6F1000 (0x7F8 = OK)

0x56B780 sectors x 0x200 =  AD6F0000 (0x7F9 = FAIL)

 

So a lower memory position seems to fail. Perhaps that memory is getting overwritten by Windows?

Maybe Firadisk assumes that it should look at the very top of memory for the command string?

Found these posts

http://reboot.pro/to...-19#entry125768

http://reboot.pro/to...-19#entry125774

??

Another guess:

Maybe 0x800-0x7F8=8 means something.

 

In binary:
0x800=100000000000

0x7F9=011111111001

0x7F8=011111111000

0x004=000000000100

0x008=000000001000

0x016=000000010000

 

What happens with:

0x005=000000000101

0x007=000000000111

0x7FC=011111111100

?

 

Hypothesis leftmost bit is a flag of some kind, and value must be multiple of 4 or 8

 

Wonko

5 = OK

7 = OK

15 = OK

0x7FC = FAIL

0x7FF = FAIL

larger values = e.g. 0x10000 0x30000 0x8000 all FAIL

These are criteria to detect RAM option.
1. mapped as mem drive in GRUB4DOS
2. is not a CDROM drive
3. drive number < 0x80
4. size < 1048576 (so 1.44 MB floppy image will not be considered)
5. start with "[FIRADISK]"

4. size < 1048576 (so 1.44 MB floppy image will not be considered)

0x7F9=2041*512=1,044,992 would qualify, so maybe there is an 8 sector or 4096 byte "rounding" in the comparison (for whatever reason).

 

The 0x800=2048*512=1,048,576 would be that (using "<" instead of "<=") but up to 0x7FF=2047*512=1,048,064 should "pass through" the check.

 

In any case (as a side note) I thought that the (99)+x is just a pointer where a few settings are written, in an area that Firadisk can access, so I don't understand why the connection with the size of a floppy drive (or of anything else).

 

I mean, for all that matters a single sector would be enough for the amount of data that is written to it, and the 4 is just an arbitrary number, isn't it?

 

Wonko

Yes, that explains it! So it just looks for a disk in the Int13 BIOS table that is smaller than 1MB and then examines the contents.

Thanks!

Allocation size is round up in map --mem command to multiple of 4096 bytes (or 8 sectors).
If you map 0x7F9 sectors and then map --status, you will see it become 0x800 sectors.

I don't really remember what I thought at that time.
Here is a guess.
Previously all map --mem drive would become a drive in Windows.
The option drive will be hidden from Windows and its memory is wasted.
How do I determine which drive is for option ?
Option is supposed to be small.
A small common size of virtual drive is probably the size of floppy disk image.
1048576 is chosen arbitrarily to be cut-off value.

Option can fit in 1 sector but (md)+1 cannot be used because ( )+1 means map the whole partition and it causes error.
4 is just an arbitrary example of small number that is not 1.

That's logical, and since you can specify multiple images which may have long paths it may exceed 512 bytes...

 

(md)0+1 does not work either.

 

P.S. map --mem (md)0x800+4 (99)  is the same as map --mem (md)+4 (99)  since you cannot define the size of memory (it's as big as it is!).

Thanks!

Option can fit in 1 sector but (md)+1 cannot be used because ( )+1 means map the whole partition and it causes error.
4 is just an arbitrary example of small number that is not 1.

Sure  , just in case  :

https://xkcd.com/221/

 

2 or 3 should however work, at least for a "normal" number of images with a "normal" path length and filename.

 

 

 

P.S. map --mem (md)0x800+4 (99)  is the same as map --mem (md)+4 (99)  since you cannot define the size of memory (it's as big as it is!).

Thanks!

If this is the case good ol' 1 may be still game :

map --mem (md)0x800+1 (99) 

 

the " ( )+1" special meaning should not come into play in this case

 

But if everything is rounded up to 8, any value 1 or 2  to 7 will always go to the same address as 8, right?

 

 

Wonko

It just doesn't seem to like 1 !!!

 

2 is OK though.

It just doesn't seem to like 1 !!!

 

2 is OK though.

Good.

 

Maybe even with this "alternate" syntax, the "+1" in itself means "whole thing" somewhere else in the code, anyway it doesn't seem to be causing any actual issues. 

 

Wonko