[jaclaz]

dencorso, on 25 July 2011 - 05:16 AM, said:

For the tests I described in this thread I used GRUB4DOS v. 0.4.4 (2009-03-25) which is now not very easy to find since nufans.net closed. So, for the sake of exact reproductibility, I'm attaching it here, just in case. But I'm being punctilious, really, because the version considered final, available from sourceforge, is 2009-03-31, so probably it would work just as well.

That grub4dos version is SERIOUSLY outdated and BTW has also a number of bugs/limitations (though they do not probably apply to the tests you made), from history:

2009-10-16 Turned off int13/AX=4B01/DL=7F cdrom query which may hang on some machines. Commented out DMA code related to running via KEXEC. Implemented 64-bit int13 memdrive block moving code.
2009-06-20(r68) add (ud) device to access space created with fbinst.
2009-06-11 fixed a bug of missing assignment of ES and BX registers in
int13_handler(asm.S).
2009-05-13 fixed size-wrap-to-0 infinite loop issue in grub_read()(disk_io.c).
2009-05-07(r67) resolved conflict between int10 stack and BIOS Data Area(grldrstart.S).
2009-05-03 fixed a bug in geometry_tune(grldrstart.S, asm.S). zw2312914 report.
2009-04-30 triple mbr without bpb also bootable as a floppy(grldrstart.S).
2009-04-26 added ending CHS calculation for partition entry in mbr of the triple mbr(bootlace.inc).
2009-04-25 bug fix in dd about device length calculation(builtins.c).
2009-04-24 save and restore GDTR in int13_handler(asm.S).
2009-04-06 accept partitions starting in the mbr track(probe_mbr, builtins.c).
2009-04-05 triple mbr floppy partition (fdX,Y) support for some USB BIOSes(disk_io.c).
2009-04-04 fixed partition table entries in the 2nd and 3rd mbr of the triple mbr(bootlace.inc).
2009-03-31(r66) 0.4.4 official release.
2009-03-28 removed the problematic global variable "i"; reduced one open-file step for configfile on cdrom.
2009-03-27 fixed memory overlap issue on "map --rehook".

Don't even THINK of using anything older that 2009-10-16, which can be found here:
http://reboot.pro/15038/page__st__1
(but I am attaching a copy of it, just in case)

What one should really use nowadays - expecially if starting using grub4dos - is LATEST EXPERIMENTAL version, here:
http://code.google.c.../downloads/list
or however a decently recent enough version, suggested is 2011-04-29.


jaclaz

Attached File(s)

•  grub4dos-0.4.4-2009-10-16.zip (821.94K)
  Number of downloads: 21

[rloew]

dencorso, on 25 July 2011 - 05:16 AM, said:

Well, according to your own definition, RLoew, GRUB4DOS is a DDO, since it does hook int 13.
BTW, it can be used to simply mount an image in DOS, with this entry in MENU.LST:

I would agree. At least in the example you gave. It may depend on the GRUB4DOS options used.
A chainloader does not HAVE to use a DDO if it doesn't need to alter the layout or behavior of the Drives.
I have an experimental GPT booter that could be considered a chainloader but is not a DDO.

[dencorso]

@jaclaz: Yes! You're right, of course! I do use 0.4.4 (2009-10-16) everywhere, and that's the one I have in my main machine.
But... The Eee PC 900 is an unfinished machine. I have yet to install XP SP3 in the huge 128 GB RunCore SSD I gave it in replacement for the original (and slow) 16 GB Phison SSD. However, time is a commodity seriously lacking for me, then I didn't come around to finishing it yet. It has, for now, the original Xandros that came with it ( ), Slax 6.1.2, 7pe_x86 and MS-DOS 7.1 inside only, plus GRUB4DOS to manage that mess. And, to my big surprise, I found out, just as I was posting my previous post, that I'd never come around to updating the GRUB4DOS inside, which was the latest version available at the time!
Now, then, nufans.net is officially dead. download.gna.org/grub4dos is outdated and gna.org/projects/grub4dos/ has a very suspect certificate error... The page you pointed to has chenall builds. Where is tinybit's versions repository now? and there're karionix's versions too, isn't it? I've still not made sense of the 0.4.5 versions, but I do know the very initial ones didn't work for me, so I stopped at 0.4.4 (2009-10-16) for the time being, but should get back to it soon (I hope). Please do put me up to date about the repositories, because that's a recent change I wasn't aware of till yesterday.

@RLoew: After getting some sleep, I see I wrote an improbable thing... Int 26 probably is implemented as just one more wrapper around int 13... SYS fails to write the boot sector most probably because it attempts to write directly to the FDD (which isn't there, of course). I didn't look at the SYS binary to ascertain whether this is true, but at least this seems to me make more sense, right now.

[jaclaz]

dencorso, on 25 July 2011 - 02:11 PM, said:

Now, then, nufans.net is officially dead. download.gna.org/grub4dos is outdated and gna.org/projects/grub4dos/ has a very suspect certificate error... The page you pointed to has chenall builds. Where is tinybit's versions repository now? and there're karionix's versions too, isn't it? I've still not made sense of the 0.4.5 versions, but I do know the very initial ones didn't work for me, so I stopped at 0.4.4 (2009-10-16) for the time being, but should get back to it soon (I hope). Please do put me up to date about the repositories, because that's a recent change I wasn't aware of till yesterday.

http://reboot.pro/14..._133740__st__30

jaclaz

[dencorso]

jaclaz, on 26 July 2011 - 01:18 AM, said:

http://reboot.pro/14..._133740__st__30

Did I ever say you rock? Well, you do!

Here's the progress we've made (version 2):
1) The 36 MiB floppy image had to be created by hand, but that's done (by myself), and it's available for download.
2) It was truncated. That's been solved by using DCopyNT (by Jorgen Bosman).
3) The image is empty (at least that's what the FATs say...) so it must be populated): VDM (by jaclaz) / VDK (by Ken Kato) solves that nicely. Moreover, it can also be mounted in True DOS, by using GRUB4DOS (and this is the only way to delete the Recycle Bin that is created once one deletes anything, while working on the image in Windows, by mounting with VDM/VDK).
4) Furthermore, thanks to jaclaz's script, FAT12build.cmd, many other images can be created, as needed.
5) The bootable ISO must be created. That's solved now by using The Free ISO Creator, but the Media Byte must be changed to 3. My little app cheltomb.exe helps changing and checking the Media Byte in a simple way.
6) It may be needed to edit the .ISO, once its created... UltraISO does it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3.
7) I've used Nero 6.6 to burn the ISO onto a physical medium (a mini-CD RW, in my case)... but any burner can do it, so it's not a problem.

[jaclaz]

dencorso, on 26 July 2011 - 01:55 AM, said:

5) The bootable ISO must be created. That's solved now by using The Free ISO Creator, but the Media Byte must be changed to 3.

Or maybe not?.

jaclaz, on 21 July 2011 - 04:57 AM, said:

Experiment #2 :
Try using this app instead of Free Iso Creator:
http://www.nbxsoft.com/
Free Create-Burn ISO
http://www.nbxsoft.c...eateburniso.exe
It should avaoid patching the 0x02 to 0x03

jaclaz

[dencorso]

True enough. But since:

dencorso, on 26 July 2011 - 01:55 AM, said:

6) It may be needed to edit the .ISO, once its created... UltraISO does it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3.

I considered the issue of the Media Byte settled, and I'm not willing to install yet another program just because of the Media Byte. After my next backup I may test it, because then I'll have an easy way to remove it, after testing, unless I decide to keep it. Did you try cheltomb? It makes changing the Media Byte quite easy, if I may say so.

[dencorso]

I've updated cheltomb once more. The new version replaces the old one, on post #47, just in case someone bookmarked that post. The new version does all the previous two did, but also displays the offset within the .ISO image where the Boot Floppy image starts, to help extracting it by hand with an hexeditor, or using the great PartCopy, jaclaz gave me a pointer to, way back when.

[jaclaz]

@dencorso
I am posting here, though maybe it would be more pertinent to the "super-floppy" thread. If needed, please move it there.

Just imagine:
Q.: What do you use to create a FAT 12 or 16 formatted image of a floppy or volume?
A: Excel.



jaclaz

P.S.:
Consider this an early pre-release version , I need some willing tester and some suggestions for "common" formats to include/add.
The "batch file" part is the one that may get a number of improvements, right now it creates a "truncated" image but the good thing is that it needs no "external" utilities (32 bit 2K or XP needed Vista and 7 should work allright also but NOT 64 bit)
If we are allowed to use mksparse and fsz (and dsfi/dsfo) we could make images faster and, besides "truncated" also "sparse" and "full size" (the latter can be done even now with a few lines added to the batch).
The spreadsheets are protected (with no password) to avoid accidentally change formulas/data, but you can unprotect them allright.
Attachment removed, new version a couple posts below.

This post has been edited by jaclaz: 29 July 2011 - 07:55 AM

[rloew]

With a new DDO and a few Patches, I have created a Blu-Ray Disk that boots a 23GB A: Drive. I have solved the LBA issue so it should also work with the 50GB Blu-Ray Disks.

[dencorso]

@jaclaz: Great idea! Let's let this new sub-thread here for now... if it proves to evolve in a direction more apropriated to the Superfloppy thread, then I'll move it there.

@jaclaz and @RLoew: You two bring great news!

@RLoew: Did you go renimatolog's way? I mean: is your new DDO a no-emulation El-Torito loader, which loads the remainder of the DDO?
BTW, do you realize that on a 23 GB Blu-Ray (or even in a 8.5 DVD+R DL) it's possible to create a complete live Win 98SE or ME, with all bells and whistles?
Maybe even with KernelEx and Aurora (= Firefox) 5? That opens all sorts of new possibilities, of course.

[M()zart]

dencorso, on 29 July 2011 - 02:41 AM, said:

BTW, do you realize that on a 23 GB Blu-Ray (or even in a 8.5 DVD+R DL) it's possible to create a complete live Win 98SE or ME, with all bells and whistles?
Maybe even with KernelEx and Aurora (= Firefox) 5? That opens all sorts of new possibilities, of course.

23 GB? I have 1,7 GB hdd on my Windows 98 machine, so even 1,5 GB would be enough for that.

[dencorso]

Sure. But mine is 7 GiB, with my rather big collection of installed applications. What I really meant is no minimization would be needed, in any case.

[jaclaz]

Version 02 added, with a couple formulas fixed and a preliminary provision for the three "max CD super-floppy" formats.
Only the one corresponding to dencorso's image implemented (with a small change).

Open question :

• How many ROOT directory entries do we expect? (usually it's 512 if F8 media, 224 if F0, dencorso's image has 272 )
  Maybe we can change this logic to "proportional to image size, with a minimum of 224"? (and a max of 512 if file is bigger than, say, 100 Mb or something like that?)

A different kind of question, this part is not fully clear to me :

• How should cluster size calculated (vs. image size)?
  
  In dencorso's image there is a 32 sectors cluster, but scrap the "theoretical max size", provided that the actual max number of clusters in a FAT12 is 4086 (and in FAT 16 65526):
  http://www.pcguide.c...artSizes-c.html
  (or what is the actual number) would it make more sense an image around 4086*16*512=33,472,512 instead of the current 37,748,736 (losing 3 Mb of space but have less slack space for DOS smallish files?)
  Or we should forget the whole thing about FAT12 and make the image FAT16?

jaclaz

P.S.: Attachment removed, see a few posts below ...

This post has been edited by jaclaz: 30 July 2011 - 06:03 AM

[Drugwash]

Please, could any of you be so kind and take some time to send me a PM or e-mail with a very detailed description of the goal of this endeavour as well as any usable information that could help me understand the boot process and especially the why of using a huge floppy image instead of the other classical way(s)? Admittedly, I've never delved too far in the boot process so there are many blank spots that need filled with information.
I have however started to build a simple application to create/edit floppy/HDD images, which should ideally avoid the use of that not-so-classy Excel sheet, so any help would be appreciated. In the mean time I'm gathering as much information as possible, but I need time to process since I'm a (very) slow thinker.
Thank you in advance!

This post has been edited by Drugwash: 29 July 2011 - 07:15 AM

[jaclaz]

Drugwash, on 29 July 2011 - 07:14 AM, said:

I have however started to build a simple application to create/edit floppy/HDD images, which should ideally avoid the use of that not-so-classy Excel sheet, so any help would be appreciated. In the mean time I'm gathering as much information as possible, but I need time to process since I'm a (very) slow thinker.

Maybe you could analyze the contents/formula's of the not-so-classy Excel sheet, the idea behind it is exactly that of exploring the logic behind the values that existing apps, like FORMAT, mtools and the like calculate and use, or, if you prefer, have an easy test bed for learning in practice what you are asking for in theory.

jaclaz

[Drugwash]

Oh, but I did. For the alpha version it's been a good start., but after reading a few web pages linked to in this very topic, I got more and more lost in the fog. There's no fixed standards, speculations are being raised and finding a reliable formula for all situations is not an easy task. Moreover, information comes from unknown sources so the level of trust is not too high.
For now, my app can read and display most of the attributes of a floppy image in ima format. I've tested with images created by UltraISO, which is a handy tool I've already had on my system. BTW, how come it has options to create 120MB and 240MB floppy images, while this topic is focused on 36MB images that aren't even listed in UltraISO's options?
Oh and don't worry - all my applications are open-source, therefore free of any charge and only bound by the GPL license - if anyone wondered. I'm poor, but still refuse to pray to the god of money. Anyway, this is off-topic.

[jaclaz]

Drugwash, on 29 July 2011 - 08:36 AM, said:

There's no fixed standards, speculations are being raised and finding a reliable formula for all situations is not an easy task.

Good moorning, Mr. de La Palice!

WHY would we be making speculations and tests, IF there were some actually valid standards (and if they were actually respected by everyone)?

The 36 Mb limit is given by the actual limits of the geometry of 1024/2/36.

What Ultraiso makes is probably another thing, since they also make the Easyboot, it is possible that they use a loader as a no-emulation bootsector and later load the super-flopy image (just like it is perfectly possible with grub4dos and with isolinux/memdisk).

For the record I just checked the El-Torito reference:
http://download.inte.../specscdrom.pdf
and it does state (page 14)

Quote

4.0 INT 13 and CD-ROMs
Once the system has selected the proper boot image, the INT 13 interface must recreate the Floppy/Hard disk. It is the
responsibility of the BIOS to create a valid geometry for the virtual disk and then present this geometry in function 08.
The INT 41 pointer is not valid at this time which means that software that uses INT 41 is not valid on a CD-ROM.
When the boot code is loaded, INT 13 must reverse the CHS addresses it receives creating a valid LBA address which
is then offset by the Load LBA. This procedure can emulate all standard Floppy/Hard disk transactions. The
remainder of this section assumes that the system is using the Initial/Default Entry, or has chosen a Section Entry.
4.1 INT 13 Function 08
This function normally gets the geometry information directly from the selected catalog entry. In the case of a floppy
simulation the geometry is well known and defined as follows:
Size Tracks x Heads x Sectors
1.44 Meg 50 x 2 x 12
2.88 Meg 50 x 2 x 24
1.2 Meg 50 x 2 x 0F

and (page 19):

Quote

1 Byte Boot media type. This specifies what media the boot image is intended to
emulate in bits 0-3. Bits 6 and 7 are specific to the type of system.
Bits 0-3 count as follows:
0 - No Emulation
1 - 1.2 meg diskette
2 -1.44 meg diskette
3 -2.88 meg diskette
4 -Hard Disk (drive C)
5-F-Reserved, invalid at this time
bits 4-5 - Reserved, must be 0
bit 6 - Image contains an ATAPI driver, bytes 8 & 9 refer to IDE interface
bit 7 - Image contains SCSI drivers, bytes 8 & 9 refer to SCSI interface

That can be read as it has been read till now.

rloew found how evidently a number of BIOS programmers did not make:

Quote

0x1=1200 K i.e. 80/2/15
0x2=1440 K i.e. 80/2/18
0x3=2880 K i.e. 80/2/36

but rather:

Quote

0x1=m/2/15
0x2=n/2/18
0x3=o/2/36

For all we know it is very possible that some BIOS programmers actually use (WARNING: just a speculation, as an example):

Quote

0x1=0x2=0x3= it's a floppy type of image, let's consider the first sector of the image as a bootsector and let's get the actual geometry from it's BPB

jaclaz

[Drugwash]

Quote

bit 6 - Image contains an ATAPI driver, bytes 8 & 9 refer to IDE interface
bit 7 - Image contains SCSI drivers, bytes 8 & 9 refer to SCSI interface

I wonder where bit 8 and 9 reside in a one-byte media descriptor... But I'll try to digest that once beer gets out of my system. While I enjoy having fixed my broken roof, have a look at this alpha-stage tool try the newer version below. It can only read and display (partly) floppy image info, for now. It will be able to create/edit one later on when I would have figured out all the pieces of the puzzle.

[attachment removed - new version below]

This post has been edited by Drugwash: 04 January 2012 - 09:16 PM

[jaclaz]

Drugwash, on 29 July 2011 - 10:13 AM, said:

Quote

bit 6 - Image contains an ATAPI driver, bytes 8 & 9 refer to IDE interface
bit 7 - Image contains SCSI drivers, bytes 8 & 9 refer to SCSI interface

I wonder where bit 8 and 9 reside in a one-byte media descriptor... But I'll try to digest that once beer gets out of my system. While I enjoy having fixed my broken roof, have a look at this alpha-stage tool. It can only read and display (partly) floppy image info, for now. It will be able to create/edit one lateron when I would have figured out all the pieces of the puzzle.

That's NOT bit 8 & 9 inside byte #1.
It is actually byte 8 & 9:

Quote

....
8-9 Word Device Specification. For SCSI controllers byte 8 is the LUN and PUN of the CD
Drive, byte 9 is the Bus number. For IDE controllers the low order bit of byte 8
specifies master/slave device, 0 = master.

jaclaz

P.S.: Nice tool, but can we have "standard" names for the fields? (just to avoid misunderstandings)
File system is definitely NOT "Freedos 1.0" or "Windows Vista/7", etc.
Sectors 16 and Sectors 32 are usually referred to as "Small sectors" and "Large Sectors".
"Hidden sectors" are also sometimes referred to as "Sectors Before" (and this IMHO better conveys the idea).

This post has been edited by jaclaz: 29 July 2011 - 11:12 AM