Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

On Bootable CD's Floppy Emulation

- - - - -

  • Please log in to reply
101 replies to this topic

#51
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

You were too terse, Rloew, sorry. Would you please elaborate?

I created Floppy disks with FAT16 and FAT32 formatting.
FAT16 is bootable and works fine with no obvious issues under DOS 7 or Windows 9x.
FAT32 is bootable and works with DOS 7 but crashed Windows 9x when accessed.

Which sizes had the images?

I did not use Images.
I was using a real 1.44MB Floppy which cannot hold an entire FAT16 or FAT32 Partition.
I Quick Formatted it with my RFORMAT Program knowing that not all of the Space actually existed.
I was more interested in seeing if DOS or Windows would access the portion I used correctly.
I used 8192 Sectors and 70000 Sectors as the defined sizes.

The 36MiB El Torito limit remains, but the DDO approach can get you to 2GiB, or more with Patches.

By DDO here you mean reanimatolog's BCDW 1.50Z, right?

I was being more general, but yes.

It's also possible to boot those images by chainloading using GRUB4DOS (or with GRUB4DOS --> memdisk), from anywhere, including a just booted CD-ROM. This is also something you would classify as using a DDO, so it's not that different, inprinciple. I'm mentioning it here just for the sake of completeness. And then there's also Plop, too... but that I have no 1st hand experience with. In any case, the goal would be to boot a floppy image as near 700 MB GB as feasible, but not bigger, because that's the most common size of inexpensive CD-Rs.

I don't consider chainloading to be a DDO as long as the chainloader does not hook Interrupt 13. I interpret a DDO to be software, excluding firmware, that Hooks the Interrupt 13 Call before the OS is Booted.
You already have a solution for 700MB (not 700GB). I was also thinking of DVDs and Blu-Rays.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.


How to remove advertisement from MSFN

#52
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

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:

title Mount Image
find --set-root --ignore-floppies /whatever.ima
map /whatever.ima (fd0)
map --hook
chainloader +1

This has the effect of mounting the image, then booting again from the device it had just booted, not from the image.
Yet, in my Eee PC 900 which has no floppy, when the prompt returns I then have an A: (which is the image, now mounted). Now, whatever is done to the disk gets imediately saved to the image, so that all changes are permanent. To unmount, the only option is to reboot the system.
The emulation is not perfect, however, because on attempting to SYS it, the system files get transferred, but the boot sector is not written to, presumably because the emulation does not cover int 26 too. But SYS terminates without complaining, that is, fails silently.

You should familiarize yourself with GRUB4DOS, RLoew... it's very powerful and versatile. There's an online manual for it which is good enough for you to get the gist of it: Grub4dos Guide. 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.

Attached Files



#53
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag

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 :ph34r: (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 Files



#54
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#55
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

@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. :thumbup
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 ( :puke: ), 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. :wacko:

@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. :)

#56
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag

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. :wacko:

http://reboot.pro/14/page__pid__133740__st__30 :whistle:

jaclaz

#57
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

http://reboot.pro/14/page__pid__133740__st__30 :whistle:

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

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.

#58
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag

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?. :unsure:

Experiment #2 :ph34r: :
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

:whistle:

jaclaz

#59
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

True enough. But since:

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. :D

#60
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

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. :)

#61
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag
@dencorso
I am posting here, though maybe it would be more pertinent to the "super-floppy" thread. :unsure: 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. :w00t:

;)

jaclaz

P.S.:
Consider this an early pre-release version :ph34r: , 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 :ph34r: and 7 should work allright also :unsure: 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.

Edited by jaclaz, 29 July 2011 - 07:55 AM.


#62
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag
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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#63
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

@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! :thumbup

@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. :yes:

#64
M()zart

M()zart

    Member

  • Member
  • PipPip
  • 275 posts

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. :yes:

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

#65
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

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. :D

#66
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag
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 :w00t::
  • How many ROOT directory entries do we expect? (usually it's 512 if F8 media, 224 if F0, dencorso's image has 272 :w00t:)
    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 :ph34r: :
  • 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 ...

Edited by jaclaz, 30 July 2011 - 06:03 AM.


#67
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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!

Edited by Drugwash, 29 July 2011 - 07:15 AM.


#68
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag

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 :whistle: 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

#69
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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.

#70
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag

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)? :unsure:

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)

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):

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 :thumbup found how evidently a number of BIOS programmers did not make:

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:

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


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

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

#71
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag

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... :blink: 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]

Edited by Drugwash, 04 January 2012 - 09:16 PM.


#72
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,026 posts
  • OS:none specified
  • Country: Country Flag

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... :blink: 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:

....
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. :w00t:
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).

Edited by jaclaz, 29 July 2011 - 11:12 AM.


#73
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
If you checked out UltraISO you'd notice that is the "friendly name" by which a file system is selected. Currently it doesn't respond to image file loading because I was too tired this morning at 6 so I had to wrap and go to sleep (yeah, bad habit, I know...). But when working, it should just be the friendly correspondent of OEM string.
Sectors are not 'small' or 'large', but the count is 16bit (when sector count doesn't exceed 0xFFFF) or 32bit when it does. So I'd rather modify to 16bit/32bit than use a misleading denomination (which actually made me wonder at first glance what this small/large is all about). Same goes for 'Sectors before' - I kept wondering what that meant until I found documentation that called it as it should: hidden.
Anyway, the source is bundled in the exe so it can be easily modified and recompiled if it's so critical. ;)
Beer is still not out of my system... for the simple reason I'm still pouring it in. :D

#74
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

@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?

Close. My entire DDO is in the El-Torito loader. I will probably switch to Floppy Emulation so the Real Floppy Drive will appear as B:.

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. :yes:

Unfortunately El-Torito emulation is Read-Only, even on BD-RE so you would have to customize your Win 98SE to the target machine on another medium, transfer it to a CD/DVD/BD, boot it and load it into a RAMDisk to run.

A much more complex DDO, similar to my BOOTMAN series, would be needed to Write to the CD/DVD/BD, and it would wear out much faster than Flash Drives.

There is also no need to use extended Floppy emulations as you can load a minimal system out of a standard Floppy Image and load your RAMDisk from an ISO-9660 FS.

@drugwash: There is probably only limited need for these extended emulations. It would be needed for transparency when working with Computers already having 24 Hard Drive Partitions defined. For me, the exercise gave me the information I needed to add an additional 256TiB to the data handling capacity of DOS.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#75
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,780 posts
  • OS:98SE
  • Country: Country Flag

Donator

@Drugwash: It's wonderful to have you fully back! :thumbup

Even if jaclaz already gave a pointer for the El Torito Standard, here's it again, just in case. A very simplified and handy version of ISO9660 is here, too, as also is Andrew Smith's Supplement to it the El-Torito Standard, although I don't think we'll be needing either for the following comments and considerations:
i) The El-Torito Boot CD/DVD is simplicity itself. Remember all Optical Media sectors are 2048 bytes ( = 0x800 bytes, in hexadecimal). El-Torito follows ISO9660 and its predecessors in counting the Optical Medium's sectors starting from 1. So one goes to sector 17 (= 0x11) and reads one sector. The first 80 bytes of this sector contain the El-Torito "Boot Record Volume Descriptor", the contents of which are described in Figure 7, p. 13 of the Standard. Of relevance, there's only one pointer, a dword (= 4 bytes) at offset 0x47 (or absolute disc offset 0x8847), which contains the *sector number* of the next structure, which is the "Booting Catalog".
ii) So, by getting the value at the absolute disc offset 0x8847 and multiplying it by 0x800, one gets the actual address of the "Booting Catalog", goes there and reads one sector. This sector contains two structures: the first 32 bytes are the "Validation Entry", which must be there, but is otherwise irrelevant to this nutshell description. Its contents are detailed in Figure 2, p. 9 of the Standard. The next 16 bytes are the really relevant structure, called "Initial/Default Entry", the contents of which are described in Figure 3, p. 10 of the Standard. Of relevance, there's only one pointer, a dword (= 4 bytes) at offset 0x08 (of this latter structure, in reality at offset 0x28 from the start of the sector), which contains the *sector number* of the next structure, which is the actual "boot diskette image or no-emulation boot code". Observe that the "Initial/Default Entry" only provides a pointer to the boot diskette image, and says nothing about it's size, which must be obtained from the image's BPB, at the boot sector.
Also in the" Initial/Default Entry" are the "Boot Indicator", which must be 0x88 and the "Media Type" byte, about which lots have already been said. There's also the "Load Segment", which is the segment of the Real Mode conventional memory where the boot sector(s) will be loaded (and that means 0x07C0 when left zeroed!) and the "Sector Count", whic is the number of *512 bytes* sectors from the image (which is presumed to be the image of a diskette, hence the 512 bytes sectors) to be loaded before transferring control to that code for booting the emulated diskette.
iii) Last, but not least, since I'm being punctilious here, all optical media are "discs", while their magnetic counterparts are "disks"... go figure! :wacko:

And, in what regards FAT, the English Wikipedia page and the Starman's Pages should be enough for almost all purposes. Note, however, that we're beyond both when we create 36 kiB, 100 kB or 127 kiB FAT-12 diskette images.

My own way of creating FAT-12 images uses the following principles:

There are 4078 possible values representable in a FAT-12. This means (2^12) - 18, which is a pessimistic view, because it excludes 0, 1, and all values from 0xFF0 to 0xFFF, inclusive. See notes 10 and 11 in the File Allocation Table English Wikipedia page. Now, since the first possible cluster is 2, by definition, then the last one is 4079 (in doubt count your fingers from one hand, starting from two, and you'll arrive at 6! So, considering that there are really 5 fingers, when one starts from two, one always arrives at total count plus one, and 4078+1 = 4079). And 4079 is 0xFEF, which is the last value meant to be used. So far, so good.

However, the various OS use different maximum numbers of clusters for FAT-12: LINUX uses 4084 (see note 9 in the File Allocation Table English Wikipedia page), while Windows 9x/ME uses 4095 and MS-DOS uses 4086, according to RLoew's findings (this post). This really boils down to the fact that there can be no more than 12 sectors per FAT-12. With 4086 we'd have 4086 clusters * 1.5 bytes per cluster = 6129 bytes. Adding 3 to that (the first three default bytes, usually 0xF0 0xFF 0xFF), we get 6132 bytes or 11.9765 sectors of 512 bytes, hence 12 sectors at most.

So, what then, is the biggest FAT-12 volume one may ever create? RLoew found out that using the "Large Sectors" count (or "Sectors 32", that is BPB+0x20) works, so we may have much more than 65536 sectors by setting BPB+0x13 to zero and using BPB+0x20 instead. So the limit is how many sectors the FAT-12 can hold. I settled on 4078 clusters * 32 kiB per cluster, so, to me, the maximum possible volume will have a net total of 133,627,904 bytes. But the filesystem structures do use space also, and we already know we need 25 sectors (1 boot sector plus 2 FATs) and the space for the root directory (which size is undefined, in principle). So, what I have been doing is to round the filesystem space to one cluster, and that gives me 64 -25 = 39 sectors for the directory, which would mean 39 *(512/32) = 624 directory entries (because each entry has 32 bytes)... Now, if I limited myself to 512 directory entries that would leave 7 unaddressable sectors in the cluster I set aside for the filesystem, as jaclaz led me to realize. So, the space needed to create a 133,627,904 bytes disk image is 133,660,672 if we wish to have a round number of clusters, which would be 4079. Of course I've made some decisions that lead to this particular value, so with different decisons it'll vary somewhat, but not much.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN