[SeaBIOS] Re: SeaBIOS and superformatted floppies

2020-06-22 Thread felix



On Mon 22 Jun 2020 at 10:58, Gerd Hoffmann  wrote:

On Sat, Jun 20, 2020 at 10:12:51PM +0300, Mike Banon wrote:
 > Well, I suspect for these use cases it'll be *alot* easier to add 
emulated harddisk support instead.


 It requires coding for SeaBIOS


Same is true for superfloppy support.  And testing this is much more
difficult.  Physical floppies are pretty much dead these days, and I
doubt qemu can properly emulate all those tricks which superfloppy
formats are using.


That much is true: QEMU only supports logically-addressed disk images 
with a uniform sector size (and probably only 512-byte sectors, I have 
not checked thoroughly). The floppy controller emulation code looks at 
the size of the disk image and tries to match it against a table of 
known geometries I linked in my first message; a matched geometry is 
then presented to the guest – as in, if the guest assumes that 
geometry when accessing the drive, the accesses will be dispatched to 
the expected logical sectors of the image. Some of those known 
geometries correspond to superformats.


Meanwhile in the guest, SeaBIOS does the same thing in reverse: when 
the floppy driver is initialised, a fixed geometry is assigned to each 
floppy drive[0], which is later used to validate CHS addresses and 
convert them into LBA[1], before dispatching the access to the floppy 
driver which converts LBA back into CHS when communicating with the 
hardware[2]. Not only is this back-and-forth rather silly, it causes 
problems when the geometry of the actual diskette in the drive does not 
match this made-up logical geometry, like when a virtual 23 × 80 × 2 
disk image appears in a 1440 KiB drive (which SeaBIOS thinks should 
only ever deal with 18 × 80 × 2 disks).


[0]: 
https://git.seabios.org/cgit/seabios.git/tree/src/hw/floppy.c?h=af0daeb2687ad2595482b8a71b02a082a5672ceb#n109
[1]: 
https://git.seabios.org/cgit/seabios.git/tree/src/disk.c?h=af0daeb2687ad2595482b8a71b02a082a5672ceb#n138
[2]: 
https://git.seabios.org/cgit/seabios.git/tree/src/hw/floppy.c?h=af0daeb2687ad2595482b8a71b02a082a5672ceb#n571



Also: why invest much effort to squeeze a limited amount of additional
capacity out of floppies if you can effectively remove all your 
capacity

issues by just using hd images instead?


In my case, the effort wasn’t all that big; all I did was patch 
SeaBIOS not to convert CHS addresses to LBA and back when accessing 
floppy drives. Less than a 100 lines of code were changed. It’s a 
pretty dirty hack though, and you probably won’t take it, so I wrote 
this report to put the issue on the record so that it can be fixed 
properly. I realise supporting superformats on bare hardware would be 
much more effort and I’m not demanding it done immediately, but 
it’s probably worth having on the record too.


And the reason I want to have large floppy images is that I want to use 
hard disk images for something else.


Regards,
—f

___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org


[SeaBIOS] Re: SeaBIOS and superformatted floppies

2020-06-22 Thread Gerd Hoffmann
On Sat, Jun 20, 2020 at 10:12:51PM +0300, Mike Banon wrote:
> > Well, I suspect for these use cases it'll be *alot* easier to add emulated 
> > harddisk support instead.
> 
> It requires coding for SeaBIOS

Same is true for superfloppy support.  And testing this is much more
difficult.  Physical floppies are pretty much dead these days, and I
doubt qemu can properly emulate all those tricks which superfloppy
formats are using.

Also: why invest much effort to squeeze a limited amount of additional
capacity out of floppies if you can effectively remove all your capacity
issues by just using hd images instead?

> + asking the floppy OS authors to
> release it as an HDD image (how many will do this?).

Don't they already do this?  How do you boot a floppy OS without a
floppy drive?  Don't they have usb stick images for that?  Such an
image effectively is an hd image ...

> Meanwhile, support for floppies is already there - including the
> double sized ones (2.88MB), it just needs an improvement

The superfloppy improvements I remember (probably incomplete):

  (1) Most floppies and drives are tolerant enough for a few extra
  tracks, so use -- say -- 82 instead of 80 tracks.
  (2) Tweak timings a bit to squeeze one or two more sectors on each
  track.
  (3) Use 2048-sized sectors instead of 512 (less sync info needed ->
  more space for data).
  (4) Booting from 2048 sector floppies doesn't work, so use a
  512-sector format for track 0 with boot block and superfloppy
  driver and 2048 for all other tracks.

(1) looks easy, maybe even works without code changes, and given this
is all virtual anyway if we are talking about floppy images you
can probably add more than just 2-3 tracks without much trouble.
(2) has effects on chs calculations, so I guess that one doesn't work
with seabios right now.
(4) is hard for images, and (3) without (4) is useless if you want boot
from these floppies, so I guess that isn't used any more these days?

take care,
  Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org


[SeaBIOS] Re: SeaBIOS and superformatted floppies

2020-06-20 Thread Mike Banon
> Well, I suspect for these use cases it'll be *alot* easier to add emulated 
> harddisk support instead.

It requires coding for SeaBIOS + asking the floppy OS authors to
release it as an HDD image (how many will do this?) . Meanwhile,
support for floppies is already there - including the double sized
ones (2.88MB), it just needs an improvement
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org


[SeaBIOS] Re: SeaBIOS and superformatted floppies

2020-06-19 Thread Gerd Hoffmann
On Thu, Jun 18, 2020 at 01:37:04PM +0300, Mike Banon wrote:
> > there isn't much demand for floppies these days (even emulated floppies).
> 
> And there are no alternatives to "emulated
> floppies" when it comes to filling the free space of your CBFS with
> useful stuff.

Well, I suspect for these use cases it'll be *alot* easier to add
emulated harddisk support instead.  That'll give you more room
without having to hoop through loops to support all those strange
tricks superfloppies are using ...

cheers,
  Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org


[SeaBIOS] Re: SeaBIOS and superformatted floppies

2020-06-18 Thread Mike Banon
> there isn't much demand for floppies these days (even emulated floppies).

I disagree: There's a big demand for emulated floppies thanks to the
unique capabilities provided by them! For example: if KolibriOS
(http://kolibrios.org/en/) supports your Ethernet controller and you
add a KolibriOS floppy, you can access the Internet right from your
BIOS and IRCC chat with your friends (maybe using a custom encryption)
- all while being under an OS that's not vulnerable to the holes of
mainstream OS (like Linux). And there are no alternatives to "emulated
floppies" when it comes to filling the free space of your CBFS with
useful stuff.

Here's my csb_patcher.sh script -
https://review.coreboot.org/c/coreboot/+/33509 . In addition to some
coreboot patches, it offers to download a collection of floppy images
(KolibriOS, FreeDOS, MichalOS, Snowdrop, Fiwix, Memtest, Tatos, Plop,
FloppyBird) and apply the unofficial SeaBIOS patches from here -
https://review.coreboot.org/c/coreboot/+/32351 (advanced_bootmenu,
multiple_floppies, writeprotected_usb), as well as to easily add all
these floppies to a coreboot image after its' compilation. This script
went through 30 revisions and a lot of people already using it,
judging by the feedback - so the installbase of coreboot+SeaBIOS with
emulated floppies should be pretty significant.

So the floppy-related issues like those reported by Felix - are
definitely worth fixing, considering its a core functionality of
SeaBIOS and one of those great features which SeaBIOS can do that
Tianocore couldn't




On Mon, Jun 15, 2020 at 8:07 PM Kevin O'Connor  wrote:
>
> On Fri, Jun 12, 2020 at 08:26:49PM +0200, felix wrote:
> > Hello,
> >
> > Not so long ago, I have stumbled upon some rather disappointing behaviour in
> > the SeaBIOS floppy driver. After some investigations, I concluded it would
> > in fact be worthy of a bug report. So here it is.
> >
> > The problem is that when SeaBIOS starts, it looks up the type of the floppy
> > drive in firmware configuration variables and internally stores a maximum
> > disk geometry corresponding to the type of the drive. This geometry is later
> > used to validate interrupt 0x13 requests and internally convert them to use
> > LBA sector numbers, which are later converted back into CHS when
> > communicating with the floppy controller. This design – apart from being
> > somewhat silly in itself, with the shoehorned CHS-to-LBA-to-CHS conversion –
> > prevents using SeaBIOS’s interrupt 0x13 service with superformatted
> > floppies, i.e. those with geometries larger than typical for the initially
> > detected drive type, even if the drive itself could handle such floppies
> > without problems.
>
> FYI, the SeaBIOS floppy code originates from the legacy "bochs bios"
> implementation, which was only targeted at VM setups.  It has since
> been extended to work on real hardware.  However, the goal has only
> been to get standard setups working as there isn't much demand for
> floppies these days (even emulated floppies).
>
> It's fine if you (or someone else) wishes to submit code to extend the
> floppy code.  I am aware that it isn't fully "standards compliant",
> but no one has yet cared enough to take on the substantial work of an
> upgrade.  If you (or someone else) does wish to take this on, it will
> be necessary to identify several real-world test cases for the floppy
> driver - both for the new features and for existing support.  And be
> willing to run all those test cases.  Testing will be crucial for any
> work as we don't want to introduce a regression as a trade-off to
> adding support for a relatively rare use case
>
> Cheers,
> -Kevin
> ___
> SeaBIOS mailing list -- seabios@seabios.org
> To unsubscribe send an email to seabios-le...@seabios.org
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org


[SeaBIOS] Re: SeaBIOS and superformatted floppies

2020-06-15 Thread Kevin O'Connor
On Fri, Jun 12, 2020 at 08:26:49PM +0200, felix wrote:
> Hello,
> 
> Not so long ago, I have stumbled upon some rather disappointing behaviour in
> the SeaBIOS floppy driver. After some investigations, I concluded it would
> in fact be worthy of a bug report. So here it is.
> 
> The problem is that when SeaBIOS starts, it looks up the type of the floppy
> drive in firmware configuration variables and internally stores a maximum
> disk geometry corresponding to the type of the drive. This geometry is later
> used to validate interrupt 0x13 requests and internally convert them to use
> LBA sector numbers, which are later converted back into CHS when
> communicating with the floppy controller. This design – apart from being
> somewhat silly in itself, with the shoehorned CHS-to-LBA-to-CHS conversion –
> prevents using SeaBIOS’s interrupt 0x13 service with superformatted
> floppies, i.e. those with geometries larger than typical for the initially
> detected drive type, even if the drive itself could handle such floppies
> without problems.

FYI, the SeaBIOS floppy code originates from the legacy "bochs bios"
implementation, which was only targeted at VM setups.  It has since
been extended to work on real hardware.  However, the goal has only
been to get standard setups working as there isn't much demand for
floppies these days (even emulated floppies).

It's fine if you (or someone else) wishes to submit code to extend the
floppy code.  I am aware that it isn't fully "standards compliant",
but no one has yet cared enough to take on the substantial work of an
upgrade.  If you (or someone else) does wish to take this on, it will
be necessary to identify several real-world test cases for the floppy
driver - both for the new features and for existing support.  And be
willing to run all those test cases.  Testing will be crucial for any
work as we don't want to introduce a regression as a trade-off to
adding support for a relatively rare use case

Cheers,
-Kevin
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org