Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[TJ Edmister]

On Wed, 23 May 2012 14:33:00 -0400, Jack  wrote:

>
> Back in 1980, I told an old friend of mine about a 750K video-driver
> package which I had seen (written in "C", of course!), and he noted,
> "They've got GUTS, calling that a DRIVER!"

Wow, that sounds familiar. Was your friend Hal Hardenberg by any chance?

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Diskette "Change Line Capability" Tests.

[Jack]

Re: the thread on this forum about how to test if a diskette will
support a "media change line", I offer the following:

My system has an old 2007 single-CPU Biostar mainboard with a VIA
8237 controller (VIA has now just-about quit offering chipsets!).
My BIOS is from Phoenix and is dated 11-Jan-2007, as I can "read"
 from the addresses slightly beyond F000:0h, the start of my BIOS.

If I specify to the BIOS that my system has NO diskette, and then
boot from my hard-disk, byte 0:048Fh is set to zero.

If I then reconfigure the BIOS to use my diskette, then boot from
hard-disk, byte 0:048Fh is set to 001h, "change line supported".

I might also add, for the benefit of anyone at VirtualBox that is
interested in one MORE "bug", that on my system byte 0:048Fh does
NOT become 007h until the diskette READS something, i.e. the size
of the diskette (720K, 1.44-MB, or Japanese 2.88-MB) is left OPEN
until I actually USE the diskette!

Now, I ask you -- If Eric's and others' comments about using ONLY
the Int 13h calls (to determine diskette media-change capability)
are true, then WHY, in a BIOS dated as late as 11-Jan-2007, would
Phoenix find it NECESSARY to set byte 0:048Fh as they do??   BIOS
writers try to SAVE memory, even more than I do in UIDE, and they
don't give up code space in their ROM chips without good REASON!!

Add to that the data from BIOS Central (which I used to create my
caching driver in 2006); the VirtualBox source file Eric found in
which SOMEBODY at VirtualBox ALSO thought that byte 0:048Fh needs
to contain diskette media-change capability bits; and finally the
fact that, on actual "hardware" PCs, NOBODY has ever told me that
UIDE/UIDE2 have failed to cache diskettes properly, i.e. its code
for detecting and dealing-with diskette changes WORKS!

For all of the above REASONS, I shall again REFUSE to update UIDE
and UIDE2 to use any more Int 13h requests.   In the "real world"
(NOT the "VirtualBox" world), UIDE/UIDE2 run fine, and I now have
enough EVIDENCE of my own to indicate there is NOTHING wrong with
the CHOICE that I made in 2006 to use byte 0:048Fh's data instead
of Int 13h calls.   VirtualBox needs to get FIXED; END of story!!

I do not know when/why having byte 0:048Fh denote diskette media-
change capability was added to the BIOS.   But, I bet that if any
of you ask Phoenix and other BIOS vendors if Int 13h is "the only
way" to test such capability, they may just have REASONS to laugh
your sorry [rear-ends] out-of-town!   What they provide as a real
world "For SALE!" product takes PRECEDENCE, in my mind, over some
rather archaic "IBM AT" BIOS specification!

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] checking virtualbox source codes for floppy and pci speed issues

[Jack]

Eric,

> Yes, 40:8f might be wrong in VirtualBox and yes the
> person who set it to the wrong value may even be in
> your "BIOS Central" style group of 40:8f users.

Did you ever think that such person may have been RIGHT
and all who say "use ONLY Int 13h calls" in determining
diskette media-change capability may be WRONG??

THAT was my point, in my last FD-User post!!   Somebody
besides me, in this event SOMEBODY AT VIRTUALBOX, had a
REASON for setting byte 0:048Fh like they did!   So, my
conclusion that all of your "conventions" on using ONLY
Int 13h may NOT be "cast in concrete" as you may think!

> But for example the IBM PS/2 and PC Technical Reference
> (official 1991 IBM docs) clearly describes 40:8f as
> RESERVED byte in the BIOS Data Area chapter, so you
> are still walking on thin ice with UIDE.  Of course
> the same reference book also describes ints 13.15 &
> 13.16 when it comes to proper floppy change checks.

In light of the above, I don't think I am on thin-ice
at all, and I'm still NOT convinced there is only ONE
"proper" way of testing diskette change-line support.

> Again, using int 13 instead of 40:xx would have
> avoided all UIDE troubles - even on VirtualBox.

Maybe, maybe not.   Other "emulators" and drivers may
be programmed to read the values from 0:048Fh and NOT
issue Int 13h calls, same as me.

> Another interesting thing is that the VirtualBox
> PCI BIOS seems to scan all possible 256 PCI bus
> numbers while it also states that it only has one
> such bus at the moment. MAX_BUSDEVFN could thus
> be lowered to 100h instead of 1h which could
> mean 256 times faster UIDE load times. If this
> is true, PCISLEEP style PCI bus scans would be
> even faster (up to 8 times) compared to even the
> possible 256-fold improvement through VirtualBox
> BIOS tweaking, compared to 3 minutes in UIDE-VB.
>
> Of course it would be interesting to contact some
> VirtualBox experts about whether MAX_BUSDEVFN is
> indeed too high (PS: pcibios.inc and pcibio32.asm
> should probably derive the CL returned by int 1a
> function b101 from MAX_BUSDEVFN for consistency)
> and about whether orgs.asm line 1137 & 1147 CODE
> should be changed, to reflect the missing change-
> line support, or whether only the COMMENT should
> be changed if this bit is about 80 track support
> rather than change line support!

All "speculative" without such info from VirtualBox.
On any "hardware" PC, a UIDE/UIDE2 scan for PCI data
using class/subclass/function data (NOT busses) runs
almost instantaneously, so I see no reason to change
THAT logic in UIDE/UIDE2, either!

You also MIGHT hear from VirtualBox that their setup
of 0:048Fh is in fact CORRECT and some OTHER element
of their program is LOSING the byte!   I.E. they DID
intend diskettes to provide change-line support, and
someone else among their programmers "blew it"!   It
sure seems like their "RIGHT hand does not know what
their LEFT hand is doing", as we say, if your source
code fragment is correct!

Jack R. Ellis


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] checking virtualbox source codes for floppy and pci speed issues

[Eric Auer]

Jack,

Yes, 40:8f might be wrong in VirtualBox and yes the
person who set it to the wrong value may even be in
your "BIOS Central" style group of 40:8f users. But
for example the IBM PS/2 and PC Technical Reference
(official 1991 IBM docs) clearly describes 40:8f as
RESERVED byte in the BIOS Data Area chapter, so you
are still walking on thin ice with UIDE.  Of course
the same reference book also describes ints 13.15 &
13.16 when it comes to proper floppy change checks.

Again, using int 13 instead of 40:xx would have
avoided all UIDE troubles - even on VirtualBox.

Another interesting thing is that the VirtualBox
PCI BIOS seems to scan all possible 256 PCI bus
numbers while it also states that it only has one
such bus at the moment. MAX_BUSDEVFN could thus
be lowered to 100h instead of 1h which could
mean 256 times faster UIDE load times. If this
is true, PCISLEEP style PCI bus scans would be
even faster (up to 8 times) compared to even the
possible 256-fold improvement through VirtualBox
BIOS tweaking, compared to 3 minutes in UIDE-VB.

Of course it would be interesting to contact some
VirtualBox experts about whether MAX_BUSDEVFN is
indeed too high (PS: pcibios.inc and pcibio32.asm
should probably derive the CL returned by int 1a
function b101 from MAX_BUSDEVFN for consistency)
and about whether orgs.asm line 1137 & 1147 CODE
should be changed, to reflect the missing change-
line support, or whether only the COMMENT should
be changed if this bit is about 80 track support
rather than change line support!

Eric


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] checking virtualbox source codes for floppy and pci speed issues

[Jack]

Eric,

> Next topic, the floppy change line problems for UIDE:
>
> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/floppy.c?rev=40754#L982
>
> VirtualBox does indeed report "without change line"
> for floppy in int 13.15 and does indeed report that
> no change line status is available in int 13.16, so
> UIDE which only looks for "known changed" status as
> opposed to int 13.16 results which are "NO status"
> is expected to be in trouble...

Only when the BIOS data-table tells UIDE/UIDE2 (A) one or two
diskettes are present, and (B) one or both of those diskettes
have change-line support.

> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/orgs.asm#L1104
>
> Interestingly, 40:8f is set to 00, 07, 70 or 77 based
> on whether you have A: or B: or both and this is also
> described as "determined, multi-rate, chgline". This
> could be a BUG in VirtualBox, given the int 13.15 and
> int 13.16 code described above...

"Determined, multi-rate, chgline"??

I say again:  "Determined, multi-rate, AND CHANGE-LINE"??!!

So, irrespective of all the supposed "pundits" on this forum
who say UIDE/UIDE2 ought to use ONLY the Int 13h calls, when
finding if a diskette has change-line support, it seems that
SOMEBODY at VirtualBox deemed it NECESSARY to post a CHANGE-
LINE SUPPORTED bit at 0:048Fh!!

A CHANGE-LINE SUPPORTED bit at 0:048Fh!!   How INTERESTING!!

NOT including you, Eric, who took the time to "find out" all
of the above, but I think there are many God-DAMNED BUFFOONS
on this forum who owe ME an APOLOGY

Jack R. Ellis


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] checking virtualbox source codes for floppy and pci speed issues

[Eric Auer]

Hi DOS experts and DOS users,

it may seem a bit odd to see this topic on freedos-user
and not on freedos-devel but it fits the current other
discussions on freedos-user... Also, possible problems
affect FreeDOS users, as the developers of FreeDOS are
not the ones who would fix VirtualBox, they would only
workaround bugs on the DOS side. I browsed through some
of the sources of VirtualBox, which you can find here:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox

You may want to read some notes about DOS and BIOS here:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/notes.txt

(e.g. "MS DOS POWER.EXE depends on STI after int 16.xx"
or bus master disk reads have to use VDS, e.g. in AHCI")



Those who wonder why i440FX and ICH9 have different UIDE
init speeds might be able to find something here, but I
am no expert in PCI bridges and do not know where to look:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/pcicfg.inc

PCI_CFG1equ 0CF8h
PCI_CFG2equ 0CFCh
PCI_FIXED_HOST_BRIDGE_1 equ 12378086h ;; i440FX PCI bridge
PCI_FIXED_HOST_BRIDGE_2 equ 244e8086h ;; ICH9 PCI bridge
MAX_BUSDEVFN equ 1h ; Max bus/dev/fn to search

Both virtual PCI things are implemented here, for experts:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Bus/DevPciIch9.cpp

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Bus/DevPCI.cpp



Note that int 1a.b1 functions use 8 bit bus numbers,
5 bit device numbers and 3 bit function numbers, so
MAX_BUSDEVFN is pretty high, in particular given that
I get the impression that int 1a.b100 reports the bus
number of the last PCI bus as zero, i.e. only ONE bus,
so a MAX_BUSDEVFN of 100h may be enough at the moment?

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/pcibios.inc#L161

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/pcibio32.asm#L142

While it is notable that two implementations exist,
one for real mode 16 bit and one in 32 bit protected
mode, both basically iterate over bus-dev-func with
ALL functions checked even for unused device slots.

The pci_pro_select_reg function does not modify BX,
so apparently the loop in pci_pro_f03 will do 65536
iterations while for example PCISLEEP would take a
much lower 32 to 256 because pcibios_real and there
pci_present report only ONE used bus, not 256 and
PCISLEEP would only look at the 8 functions for the
device slots which HAVE devices, not all 32 devices
that MIGHT be used.

Again, it is not clear to me why i440 or ICH9 would
be faster or slower, e.g. with UIDE, for PCI scans,
but 32-256 iterations of an inline loop in PCISLEEP
are obviously MUCH FASTER than 65536 iterations of
a more complex loop in pcibios.inc or pcibios32.asm

I think it would help if MAX_BUSDEVFN was matched
with the CL (number of last PCI bus in system) in
the int 1a.b101 return value - it seems impossible
to me to have devices installed on any bus beyond
the "last PCI bus in system" location. But is this
a BUG in VirtualBox?



Next topic, the floppy change line problems for UIDE:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/floppy.c?rev=40754#L982

VirtualBox does indeed report "without change line"
for floppy in int 13.15 and does indeed report that
no change line status is available in int 13.16, so
UIDE which only looks for "known changed" status as
opposed to int 13.16 results which are "NO status"
is expected to be in trouble...

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS-new/orgs.asm#L1104

Interestingly, 40:8f is set to 00, 07, 70 or 77 based
on whether you have A: or B: or both and this is also
described as "determined, multi-rate, chgline". This
could be a BUG in VirtualBox, given the int 13.15 and
int 13.16 code described above...



HOWEVER, VirtualBox seems to have TWO versions of the
whole BIOS, so we should also check rombios.c here:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS/

Unfortunately, I failed to download that file via http.
It is a whole BIOS in a single 339 kB C file, plus some
small files for AHCI, APM, SCSI and a boot logo thingy.
Interesting to look at the APM edge between BIOS and VM.

It would be important to read the floppy and 40:xx part
of rombios.c to check what it does with change lines.

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS/ahci.c

The AHCI driver might be interesting to read for our low
level (disk) driver experts out there :-) Same for SCSI.

Regards, Eric


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl042420

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

>> As I just got through noting, in another post, why would the BIOS
>> data include diskette change-line flags if they were NOT intended
>> to be USED??
>>
>> Until someone can positively REFUTE the data offered by the BIOS
>> Central data-table list, my opinion is that neither you nor any-
>> one else can say Int 13h is better or 40:xx is "coffee grounds"!
>
> There is no need to refute anything, it all comes down to the very
> simple fact that IBM documented the mentioned INT13h BIOS calls,
> while vast areas of the BIOS data segment simply are not!!!

And this makes using the BIOS data segment WRONG???

> Comes to show that you are just out to prove another old engineering
> truth, "good is the enemy of great".

NO, you F*g S**t!!   I am simply trying to show that I had to
MAKE A CHOICE, when I wrote UIDE/UIDE2 in 2006.   That CHOICE was
NOT to use DOS/BIOS calls except where NECESSARY, and the data as
noted by BIOS Central for byte 0:048Fh made it UNNECESSARY for me
to issue Int 13h calls!   This keeps UIDE/UIDE2 "generic" for use
across ALL possible DOS variants, which was my MAJOR design goal!
That, sir, IS A CHOICE, NOT any attempt to do as YOU seem to want
to "propagandize"!!   And I still STAND BY that choice, until you
or anyone PROVE to me BIOS Central's data table is INCORRECT!!

> Just as Tom mentioned, this is all going nowhere, "Du hast Recht
> und ich hab meine Ruhe"... :-(

Well, since you both have moved this thread to "another level", I
shall reply by saying only "Zu BEFEHL, Herr OBERST"!!!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Ralf A. Quint]

At 12:31 PM 5/23/2012, Jack wrote:
>As I just got through noting, in another post, why would the BIOS
>data include diskette change-line flags if they were NOT intended
>to be USED??
>Until someone can positively REFUTE the data offered by the BIOS
>Central data-table list, my opinion is that neither you nor any-
>one else can say Int 13h is better or 40:xx is "coffee grounds"!

There is no need to refute anything, it all comes down to the very 
simple fact that IBM documented the mentioned INT13h BIOS calls, 
while vast areas of the BIOS data segment simply are not!!!

Comes to show that you are just out to prove another old engineering 
truth, "good is the enemy of great".

Just as Tom mentioned, this is all going nowhere, "Du hast Recht und 
ich hab meine Ruhe"... :-(

Ralf


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Tom Ehlert]

> Given how UIDE/UIDE2's diskette I-O has never been a problem BUT
> for VirtualBox, I will keep UIDE/UIDE2 as-is.

this is going nowhere. Jack is right and everybody else is a bloody
idiot.

AMEN

Tom





--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

Eric,

>> Apologies, I misread my own source file (early!) this morning.   UIDE
>> and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive
>> A: or B: suipport a media-change line.   Note the BIOS data lists at:
>> 
>
> This document states that bit 0 and 4 indicate change
> line support for drive A: and B: respectively, but
> RBIL states that the bits are about 80 track support.
>
> A safe option would be not to "read 40:xx coffee grounds"
> but instead use the well-documented int 13 interface...

As I just got through noting, in another post, why would the BIOS
data include diskette change-line flags if they were NOT intended
to be USED??

Until someone can positively REFUTE the data offered by the BIOS
Central data-table list, my opinion is that neither you nor any-
one else can say Int 13h is better or 40:xx is "coffee grounds"!

Given how UIDE/UIDE2's diskette I-O has never been a problem BUT
for VirtualBox, I will keep UIDE/UIDE2 as-is.   VirtualBox users
now have the /E switch they can specify with my drivers, and all
other users of hardware PCs and (NOT so "flaky") hardware change
lines will continue to run just fine!

Jack R. Ellis


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

> Jack, PLEASE, don't pull yourself up on the "VirtualBox" issue, it is
> rather a more general problem.
>
> You simply rely on the contents of the memory region rather than than
> properly query system via INT13. And that isn't adding much to the
> logic and overall size of your drivers compared to the indiscriminate
> reliance on the validity of the BIOS data area.

Who says that "properly querying system via Int 13h" IS in fact proper??
Why would the BIOS include the flags at 0:48Fh if the BIOS designers did
NOT intend them to be USED??   And who says it is "indiscriminate", if I
rely on the validity of the BIOS data??   This time, my friend, you have
REALLY overstepped your bounds!!

> Yes, this will be more likely an issue with a(ny) virtual machine
> setup than with a "real iron" box, but then querying the DOS
> interrupt would rather help for example to make use of the floppy
> drive caching in a system with more than 2 floppy drives...

UIDE/UIDE2 are designed to support a maximum of 2 diskettes.   Since
diskettes are no-longer offered for general sale, and people now use
USB devices, etc., I see no reason to worry about 3 or more diskette
systems -- very few ever existed, and they needed special software!!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem

[Jack]

>> You are WRONG, Tom!!
>
> Is he ? or are you being RUDE, Jack?

Tom could have written me privately, before publicly saying UIDE
assumes change-line support, but did not.   I responded in kind!

> Not Tom, but I'd like to learn from /what exact source/ you got the  
> definition for those bits.

My error; the byte accessed by UIDE is 0:48Fh as I noted earlier,
when I also noted the "BIOS Central" website as my source.

> Now, puhlease! don't feel accused - I'm sure you did not make those bits  
> up and that they work in your test machines and even for the bulk of  
> your users.  That you wait for users' complaints before checking the  
> soundness of your assumptions is another question entirely.

Unless "BIOS Central" posts incorrect data, my assumptions WERE sound!

> You are entitled to choose any method that works on recent gear if you
> find it convenient.

Thank you, and so I shall keep UIDE/UIDE2 as-is.

> But rather than pretending to support floppies on the whole range of
> DOS-capable PCs, and claiming that those that do not conform to your  
> model are junk (or is it the users' fault ?) - you /must/ find a way to  
> programmatically assert that your far from universal method /will/ work  
> and take measures otherwise. IMHO you can't leave it to the (clueless,  
> always...) user to assert his or her PC is not conforming to UIDE's  
> model.

There is NOTHING wrong with "UIDE's model", unless you can positively
REFUTE the data provided by "BIOS Central", which is what I used back
in 2006 when I added caching to my drivers.   They have worked on all
"hardware" PCs since then, so I shall NOT assume to be using any "far
 from universal" method.   And, I say again:  Hardware change-lines do
work, have since 1985, and any which do not are a MAINTENANCE problem
for the user, NOT any reason to re-engineer UIDE.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Ralf A. Quint]

At 11:33 AM 5/23/2012, Jack wrote:
>And certainly, it is not impossible to cache floppies.Before the
>debut of VirtualBox, UIDE/UIDE2 had done so successfully, for years,
>without any complaints at all!

Jack, PLEASE, don't pull yourself up on the "VirtualBox" issue, it is 
rather a more general problem.

You simply rely on the contents of the memory region rather than than 
properly query system via INT13. And that isn't adding much to the 
logic and overall size of your drivers compared to the indiscriminate 
reliance on the validity of the BIOS data area.

Yes, this will be more likely an issue with a(ny) virtual machine 
setup than with a "real iron" box, but then querying the DOS 
interrupt would rather help for example to make use of the floppy 
drive caching in a system with more than 2 floppy drives...

Ralf 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem

[Bertho Grandpied]

On Wed, 23 May 2012 09:22:03 Jack <...@earthlink.net> wrote :
> Subject: Re: [Freedos-user] Virtual floppy change problem

> You are WRONG, Tom!!

Is he ? or are you being RUDE, Jack ?

> UIDE has NEVER ignored if a diskette has change-line support!   It
> does in fact check the BIOS data table at 0:448h for bit 0 (change
> line for diskette A:) or bit 4 (change line for diskette B:).   If
> those bits are off, diskette A: or diskette B: will not be
> cached.

Not Tom, but I'd like to learn from /what exact source/ you got the definition 
for those bits. They are not universal, and we need look no further for why 
UIDE floppy caching may fail. Does that reference state that it applies to 
IBM-PC, PC-XT, PC-AT, PS2... or maybe some BIOSes of some particular brand 
and/or period ?

In any case BIOS data byte [40:48] is /not/ documented in Ralf Brown's files, 
nor is it in Michael Tischer's book (other than HD/FD related). I have the 
source listing for a Goupil G5 BIOS ca. 1990 (a very faithful, and one of the 
rare "authorised by IBM", PC-AT clones) - those bits aren't used for disk 
change lines. An authentic IBM AT BIOS is accessible on the net, I haven't 
found the need for fetching it, someone might check there also. 

/Possibly/ those bits were defined as floppy line flags in the PS2 
'compatibility' RM BIOS , I have no idea - having checked a PS2 technical 
manual which unfortunately doesn't have the BDA details.

Now, puhlease! don't feel accused - I'm sure you did not make those bits up and 
that they work in your test machines and even for the bulk of your users . That 
you wait for users' complaints before checking the soundness of your 
assumptions is another question entirely. You are entitled to choose any method 
that works on recent gear if you find it convenient. But rather than pretending 
to support floppies on the whole range of DOS-capable PCs, and claiming that 
those that do not conform to your model are junk (or is it the users' fault ?) 
- you /must/ find a way to programmatically assert that your far from universal 
method /will/ work and take measures otherwise. IMHO you can't leave it to the 
(clueless, always...) user to assert his or her PC is not conforming to UIDE's 
model.

Regards

-- 
Czerno

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

> to make a long answer short:
> in VirtualBox, 40:8f is 00
> again, clearly stating 'change line is not supported'

Maybe for your system, obviously not on Wolfgang's, and
who-knows re: other "C"-based systems with NO reason to
post a BIOS data-table at 0:400!   That is my guess re:
what is occurring.   If VirtualBox were ever to support
diskette change-lines, they MUST offer a correct set of
"change line supported" flags at 0:48Fh.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

> It's not impossible to cache floppies, Jack.  You just need to do it
> differently than you're doing now ...

Back in 1980, I told an old friend of mine about a 750K video-driver
package which I had seen (written in "C", of course!), and he noted,
"They've got GUTS, calling that a DRIVER!"

If I had done your type of diskette caching, your type of re-entrant
driver, and all else you seem to suggest, GUESS what that would add,
to the size of UIDE/UIDE2!!

Since my drivers work in at-most about an 800K-byte DOS system (640K
low-memory plus maybe 160K with "LOL"!), I will keep them SMALL, and
NOT end up with any 64K-byte ATROCITY like at least one I have seen!

And certainly, it is not impossible to cache floppies.Before the
debut of VirtualBox, UIDE/UIDE2 had done so successfully, for years,
without any complaints at all!

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Eric Auer]

Jack,

> Apologies, I misread my own source file (early!) this morning.   UIDE
> and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive
> A: or B: suipport a media-change line.   Note the BIOS data lists at:
> 

This document states that bit 0 and 4 indicate change
line support for drive A: and B: respectively, but
RBIL states that the bits are about 80 track support.

A safe option would be not to "read 40:xx coffee grounds"
but instead use the well-documented int 13 interface...

> And I prefer "emulators" which emulate EVERYTHING, including
> a valid alternate way of determining change-line support!

If VirtualBox believes RBIL, they have to set the bits,
as the virtual floppy supports 80 tracks. If they believe
the website mentioned above, they would have to not set
the bits, as the virtual floppy has no change lines...

>>> But, if what you wrote above is correct, VirtualBox expects
>>> people to use ONLY the "Int 13h" requests, when determining
>>> if a diskette has change-line support.

Yes, and VirtualBox is correct in doing so.

> Linux, or other "C"-based systems.   So, I have never used VirtualBox
> and have NO REASON to study its documentation or sources.   I rely on
> what others tell me about it, and before today NOBODY ever told me it
> positively states 'change line is not supported'.   What part of THAT
> do you not understand??   We all cannot be experts on everything...

There is no need to read VirtualBox docs or sources, just
follow the well documented BIOS int 13 interface, easy...

> I in fact want NOTHING TO DO with "VirtualBox", as it
> too-often proves itself a piece of TRASH!!

It is not the fault of VirtualBox that you relied on some
questionable source of information about 40:xx fields. Of
course RBIL is only 99.9% correct either but I am sure a
lot of sources agree that int 13 is the official disk API.

> I think it is PATHETIC that they
> choose not to support diskette media-changes!

Dosemu also took a while to support it, you could ask
some dosemu expert why they did not immediately do it
but I assume that there are sufficient reasons...

> I say again, apologies for my referencing 0:448h this morning, when I
> should have referenced 0:48Fh as UIDE/UIDE2's source for the diskette
> media-change flags.   However, "suboptimal" has NEVER been a problem

Using flag bits for which conflicting documentation
exists and then blaming others for not implementing
the bits in the way that you would prefer is not a
question of optimal versus suboptimal drivers. There
would be no need to discuss a well-documented int 13.

Sorry if this means that your driver will grow above
the current size limit, but I think it will not: You
can remove the "manual workaround" command line flag
to reduce driver size as soon as you change UIDE to
use reliable int 13 as opposed to unreliable 40:xx.

Eric


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Tom Ehlert]

Jack,


>>> UIDE has NEVER ignored if a diskette has change-line support!   It
>>> does in fact check the BIOS data table at 0:448h for bit 0 (change
>>> line for diskette A:) or bit 4 (change line for diskette B:).   If
>>> those bits are off, diskette A: or diskette B: will not be cached.
>>
>> if UIDE would check INT13/15 if change line is supported, and not
>> cache the floppy if it's not supported everything would be fine (and
>> /N5 not needed).   I can't locate any documentation about 0:448.

> Apologies, I misread my own source file (early!) this morning.   UIDE
> and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive
> A: or B: suipport a media-change line.   Note the BIOS data lists at:
> 

to make a long answer short:

in VirtualBox, 40:8f is 00
again, clearly stating 'change line is not supported'




Tom


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

>> UIDE has NEVER ignored if a diskette has change-line support!   It
>> does in fact check the BIOS data table at 0:48Fh for bit 0 (change
>> line for diskette A:) or bit 4 (change line for diskette B:).   If
>> those bits are off, diskette A: or diskette B: will not be cached.
>
> That is an interesting bug in VirtualBox then (wrong 40:xx data)
> but I support Tom here because int 13 is the "front entrance" to
> knowing if change lines are supported. Whether and how this uses
> the "back office" 40:xx data and whether this data reflects the
> "official" statement returned by int 13 is not always reliable,
> so asking int 13 is probably better ...

Who says there is a "front office" and "back office" way of dealing
with diskette media-changes??   Both seem valid to me!   And if the
two methods do NOT return the same info, we should CORRECT whatever
program (VirtualBox, in this case) which has CAUSED such a problem,
rather than requiring all previously-GOOD software to get changed!

> Also, it would be very easy for UIDE to ask int 13 instead of or
> in addition to 40:48 bits.

Would take more logic, and is NOT needed on any "hardware" PC.   As
I am NOT "working for VirtualBox" (or I damned-well HOPE not!), let
THEM make changes to address the problems they have created!

>> But, if what you wrote above is correct, VirtualBox expects people to
>> use ONLY the "Int 13h" requests, when determining if a diskette has
>> change-line support. And in any event, by indicating NO such support
>> ... they make it impossible for UIDE to cache diskettes ...
>
> Indeed. But it is better to not cache than to damage data.

Another statement on which you can bet your [rear-end]!

> Given the new information from Tom, I agree that it is
> not worth the effort to add heuristic cache flushing,
> as it turned out that it IS possible to detect that no
> change line exists in VirtualBox. So VirtualBox users
> will not enjoy UIDE caching, but please do use int 13
> (instead of or even better in addition to 40:48) for
> the detection of systems without change lines... That
> will protect VirtualBox users from data loss dangers!

So will UIDE/UIDE2 /E, and so I shall leave my drivers as-is.

>> To which I shall add:  Maybe you might have read the UIDE.ASM file
>> before making any BASELESS and WRONG accusations about my drivers!
>
> The sources are circa 4000 lines long and do not even
> mention "change line". Now that you explain how UIDE
> works, I was able to find this snippet:
>
>> mov al,FMCMask  ;Use diskette media-change bits
>> and al,es:[MCHDWFL] ;  for our number of diskettes.
>> I_FScn: testal,001h ;Can next unit signal media-changes?
>> jz sI_FMor  ;No?  CANNOT use this old "clunker"!
>
> where MCHDWFL equ 0048Fh. You claimed that you would
> check 40:48, not 40:8f, but I could not find anything
> in UIDE which checks 40:48 and RBIL does not give any
> meaning for 40:48 either. Looking at RBIL for 40:8f,
> I see that you can check whether drives support 80
> tracks and/or multiple baud rates, but not on XT and
> nothing is said about change lines being flagged by
> this byte according to RBIL.

See my earlier post this morning re: the "BIOS Central" list
of what is present in the BIOS data table at 0:48Fh.I am
not surprised if change-line data is not specified for an XT
as they were not available till 1985, back in the "AT" days!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

>> UIDE has NEVER ignored if a diskette has change-line support!   It
>> does in fact check the BIOS data table at 0:448h for bit 0 (change
>> line for diskette A:) or bit 4 (change line for diskette B:).   If
>> those bits are off, diskette A: or diskette B: will not be cached.
>
> if UIDE would check INT13/15 if change line is supported, and not
> cache the floppy if it's not supported everything would be fine (and
> /N5 not needed).   I can't locate any documentation about 0:448.

Apologies, I misread my own source file (early!) this morning.   UIDE
and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive
A: or B: suipport a media-change line.   Note the BIOS data lists at:


>> My update to UIDE in adding the /E switch was simply to add a mask
>> which is 011h without /E, 000h with /E, to "mask" against the bits
>> at address 0:448h.   This works fine.
>
> I prefer software that works without switches. at least if it can
> handle the situation itself.

And I prefer "emulators" which emulate EVERYTHING, including a valid
alternate way of determining change-line support!

>> But, if what you wrote above is correct, VirtualBox expects people
>> to use ONLY the "Int 13h" requests, when determining if a diskette
>> has change-line support.
>
> wrong.  VirtualBox tells you 'change line is not supported'
> which part of this is difficult to understand?

I run V6.22 MS-DOS and V4.0 Win/NT, that I got "for free" in 1994 and
1998 as a software developer.   I have never run any "later" Windows,
Linux, or other "C"-based systems.   So, I have never used VirtualBox
and have NO REASON to study its documentation or sources.   I rely on
what others tell me about it, and before today NOBODY ever told me it
positively states 'change line is not supported'.   What part of THAT
do you not understand??   We all cannot be experts on everything, and
after all this, I in fact want NOTHING TO DO with "VirtualBox", as it
too-often proves itself a piece of TRASH!!

>> And in any event, by indicating NO such support, as you also wrote
>> above, they make it impossible for UIDE to cache diskettes anyway!
>
> exactly. hands off these floppies.

Thus you "joke" about this being GOOD??   I think it is PATHETIC that
they choose not to support diskette media-changes!!

>>> maybe the real issue is that noone finds the time to do a tiny bit of
>>> debugging the problem but finds a lot of time to write loong
>>> emails
>
>> To which I shall add:  Maybe you might have read the UIDE.ASM file
>> before making any BASELESS and WRONG accusations about my drivers!
>
> neither BASELESS nor WRONG, and neither accusations.  Just stating
> that they behave suboptimal.

I say again, apologies for my referencing 0:448h this morning, when I
should have referenced 0:48Fh as UIDE/UIDE2's source for the diskette
media-change flags.   However, "suboptimal" has NEVER been a problem,
at-least never before VirtualBox, and UIDE/UIDE2 have worked properly
using this scheme for 6 years!

I also say again:  I will NOT add any (large) amount of logic in UIDE
merely to handle one miserable "emulator" program which admittedly is
NOT emulating EVERYTHING!   On any "hardware" PC system, UIDE's logic
for handling diskettes and their media-changes runs fine.

As I want to keep UIDE/UIDE2 simple, I shall leave things as-is.   If
users want to run VirtualBox, they can simply use UIDE/UIDE2 /E which
specifies 'hands off those floppies' (like Tom stated above), exactly
as the writers of VirtualBox intended!   No diskette data errors, and
everybody should be happy!

Jack R. Ellis


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Ralf A. Quint]

At 09:22 AM 5/23/2012, Jack wrote:

>You are WRONG, Tom!!

Sorry, Jack, but he is not

Honestly Jack, please don't explode each time someone is making a 
critical statement. There simply is no reason to get all personal about this...

>UIDE has NEVER ignored if a diskette has change-line support!   It
>does in fact check the BIOS data table at 0:448h for bit 0 (change
>line for diskette A:) or bit 4 (change line for diskette B:).   If
>those bits are off, diskette A: or diskette B: will not be cached.

Beside assuming on my part that 0:0448 is a typo (and you are 
referring rather to 0040:0041, as used in your sources), the problem 
that Tom is trying to make you aware of is that you rely on the value 
in that location regardless of the fact if the system is indicating 
via BIOS interrupt INT13h/15h that the line change status is 
supported in the first place.
And VB is apparently clearly stating when "asked" that it does not 
support the drive change line status, hence you can not rely on those 
bits in the BDA. Simple as that...

Ralf 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[BretJ]

Jack-181 wrote:
> 
> I will NOT cache a drive which cannot tell me when its media has changed,
> and I REFUSE to add all of the
> logic in UIDE that Eric notes the DOS kernel contains, to find out if a
> media-change has occurred using other methods!

It's not impossible to cache floppies, Jack.  You just need to do it
differently than you're doing now.

Probably the simplest thing you can do is an "indirect collaboration" with
DOS.  You can simply ignore the hardware change line completely, like DOS
basically does.  The only time DOS should try to access the boot sector
(sector 0 on a floppy) is when it's trying to figure out if the media has
changed or not, and you can use that as a signal to flush the cache entries
for that disk.  You could even go a step further and compare the cached
sector 0 and the new one to see if the disk has really changed or not, and
not flush the cache if it hasn't, but I'm sure that's "too complicated" for
you to implement.

I can't think of a scenario where that wouldn't solve the problem.  The only
potential issue I can see is if the disk has an MBR or GPT at sector 0
instead of a boot sector, but that shouldn't ever happen on a floppy.
-- 
View this message in context: 
http://old.nabble.com/Virtual-floppy-change-problem-with-VirtualBox-tp33859302p33897120.html
Sent from the FreeDOS - User mailing list archive at Nabble.com.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Tom Ehlert]

Jack,

>>> The "issue" is that VirtualBox is not posting diskette media-change
>>> status in the BIOS data table.
>>
>> the 'issue' is that VirtualBox clearly states
>>   'floppy without change-line support'
>>
>> int13/15 returns '01h floppy without change-line support
>> int13/16 returns '06h change line active or not supported
>>
>> but UIDE ignores this, and relies on change line support anyway.

> You are WRONG, Tom!!

> UIDE has NEVER ignored if a diskette has change-line support!   It
> does in fact check the BIOS data table at 0:448h for bit 0 (change
> line for diskette A:) or bit 4 (change line for diskette B:).   If
> those bits are off, diskette A: or diskette B: will not be cached.
if UIDE would check INT13/15 if change line is supported, and not
cache the floppy if it's not supported everything would be fine (and
/N5 not needed)
I can't locate any documentation about 0:448

> My update to UIDE in adding the /E switch was simply to add a mask
> which is 011h without /E, 000h with /E, to "mask" against the bits
> at address 0:448h.   This works fine.
I prefer software that works without switches. at least if it can
handle the situation itself.

> But, if what you wrote above is correct, VirtualBox expects people
> to use ONLY the "Int 13h" requests, when determining if a diskette
> has change-line support.
wrong. VirtualBox tells you 'change line is not supported'
which part of this is difficult to understand ?


> And in any event, by indicating NO such
> support, as you also wrote above, they make it impossible for UIDE
> to cache diskettes anyway!
exactly. hands off these floppies.

>> maybe the real issue is that noone finds the time to do a tiny bit of
>> debugging the problem but finds a lot of time to write loong
>> emails

> To which I shall add:  Maybe you might have read the UIDE.ASM file
> before making any BASELESS and WRONG accusations about my drivers!
neither BASELESS nor WRONG.
and neither accusations. just stating that they behave suboptimal.


Tom


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Eric Auer]

Jack,

>> the 'issue' is that VirtualBox clearly states 'floppy without
>> change-line support'
>> 
>> int13/15 returns '01h floppy without change-line support int13/16
>> returns '06h change line active or not supported
>> 
>> but UIDE ignores this, and relies on change line support anyway.
> 
> You are WRONG, Tom!!
> 
> UIDE has NEVER ignored if a diskette has change-line support!   It 
> does in fact check the BIOS data table at 0:448h for bit 0 (change 
> line for diskette A:) or bit 4 (change line for diskette B:).   If 
> those bits are off, diskette A: or diskette B: will not be cached.

That is an interesting bug in VirtualBox then (wrong 40:xx data)
but I support Tom here because int 13 is the "front entrance" to
knowing if change lines are supported. Whether and how this uses
the "back office" 40:xx data and whether this data reflects the
"official" statement returned by int 13 is not always reliable,
so asking int 13 is probably better. Also, it would be very easy
for UIDE to ask int 13 instead of or in addition to 40:48 bits.

I remember that DOSEMU also had no change line support back
in version 1.1.3, but reported that correctly via int 13.15
and when you queried int 13.16, it always said "changed"...

> But, if what you wrote above is correct, VirtualBox expects people to
> use ONLY the "Int 13h" requests, when determining if a diskette has
> change-line support. And in any event, by indicating NO such support
> ... they make it impossible for UIDE to cache diskettes ...

Indeed. But it is better to not cache than to damage data.

Back in the DOSEMU 1.1 days, I had an undocumented option
for LBACACHE to cache diskettes even without change line,
but the user had to manually tell the cache each time when
the diskette changed. I have not implemented something a
la "flush on boot sector read" then, because all physical
floppy drives that I had did support the change line and
I only wanted to play with floppy caching myself, did not
suggest to normal users to cache no-change-line drives...

> cache diskettes anyway! I will NOT cache a drive which cannot tell
> me when its media has changed, and I REFUSE to add all of the logic
> in UIDE that Eric notes the DOS kernel contains, to find out if a
> media-change has occurred using other methods!

Given the new information from Tom, I agree that it is
not worth the effort to add heuristic cache flushing,
as it turned out that it IS possible to detect that no
change line exists in VirtualBox. So VirtualBox users
will not enjoy UIDE caching, but please do use int 13
(instead of or even better in addition to 40:48) for
the detection of systems without change lines... That
will protect VirtualBox users from data loss dangers!

> So, I shall amend my earlier post to say that VirtualBox now needs 
> TWO changes:  (A) It needs to provide media-change status for each 
> diskette, and (B) It needs to provide a PROPER BIOS DATA TABLE, as 
> the table bits that are "seen" when VirtualBox runs are INCORRECT!

With change (a) it will support floppy caches better,
but I consider (b) to be low priority, as the normal
way to ask the BIOS about change lines is int 13.



> To which I shall add:  Maybe you might have read the UIDE.ASM file 
> before making any BASELESS and WRONG accusations about my drivers!

The sources are circa 4000 lines long and do not even
mention "change line". Now that you explain how UIDE
works, I was able to find this snippet:

> mov al,FMCMask  ;Use diskette media-change bits
> and al,es:[MCHDWFL] ;  for our number of diskettes.
> I_FScn: testal,001h ;Can next unit signal media-changes?
> jz sI_FMor  ;No?  CANNOT use this old "clunker"!

where MCHDWFL equ 0048Fh. You claimed that you would
check 40:48, not 40:8f, but I could not find anything
in UIDE which checks 40:48 and RBIL does not give any
meaning for 40:48 either. Looking at RBIL for 40:8f,
I see that you can check whether drives support 80
tracks and/or multiple baud rates, but not on XT and
nothing is said about change lines being flagged by
this byte according to RBIL. In other words, it MAY
be the case that most BIOS implementations that you
have seen somehow tell something about change lines
in some 40:xx byte, but it is NOT documented in RBIL
and therefore you should not blame VirtualBox for not
implementing this undocumented flag needed by UIDE.

Eric


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

Tom:

>> The "issue" is that VirtualBox is not posting diskette media-change
>> status in the BIOS data table.
>
> the 'issue' is that VirtualBox clearly states
>   'floppy without change-line support'
>
> int13/15 returns '01h floppy without change-line support
> int13/16 returns '06h change line active or not supported
>
> but UIDE ignores this, and relies on change line support anyway.

You are WRONG, Tom!!

UIDE has NEVER ignored if a diskette has change-line support!   It
does in fact check the BIOS data table at 0:448h for bit 0 (change
line for diskette A:) or bit 4 (change line for diskette B:).   If
those bits are off, diskette A: or diskette B: will not be cached.

My update to UIDE in adding the /E switch was simply to add a mask
which is 011h without /E, 000h with /E, to "mask" against the bits
at address 0:448h.   This works fine.   With /E, the mask prevents
UIDE from "seeing" any change-line bits, so diskettes go uncached.

But, if what you wrote above is correct, VirtualBox expects people
to use ONLY the "Int 13h" requests, when determining if a diskette
has change-line support.   And in any event, by indicating NO such
support, as you also wrote above, they make it impossible for UIDE
to cache diskettes anyway!   I will NOT cache a drive which cannot
tell me when its media has changed, and I REFUSE to add all of the
logic in UIDE that Eric notes the DOS kernel contains, to find out
if a media-change has occurred using other methods!

So, I shall amend my earlier post to say that VirtualBox now needs
TWO changes:  (A) It needs to provide media-change status for each
diskette, and (B) It needs to provide a PROPER BIOS DATA TABLE, as
the table bits that are "seen" when VirtualBox runs are INCORRECT!

> maybe the real issue is that noone finds the time to do a tiny bit of
> debugging the problem but finds a lot of time to write loong
> emails

To which I shall add:  Maybe you might have read the UIDE.ASM file
before making any BASELESS and WRONG accusations about my drivers!

Jack R. Ellis


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos-user Digest, Vol 635, Issue 1

[Bret Johnson]

> I tried using your programs, but for some reason they did not
> work.  When I loaded the usbprint app, I ran this command
> "usbprint status" and it said on the bottom "no printer
> installed" when I clearly had the printer plugged in. I also
> tried it where I loaded it and then plugged in the printer, but
> it still said "no printer installed". Any help would do it!

Was the printer both plugged in and powered on?

The most likely problem is that you have more than one USB host controller.  If 
you simply do a "USBUHCI" or "USBUHCIL" to install the driver for the USB host 
controller, it will only install the driver for the first host controller 
(Index 0).  That may not be the host controller that the printer is plugged 
into.

Start by doing a "USBHOSTS" to see how many UHCI controllers the computer has, 
and then try installing USBUHCIL with the different Indexes (USBUHCIL 
/Index:#), where # are the different indexes (0 through however many 
controllers you have).  That's the "shotgun" approach that will probably get 
you going.  If it doesn't, there are many more extensive troubleshooting steps 
we can perform, but they are complicated to work through.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Eric Auer]

Hi Tom,

thanks for checking the int 13 details on VirtualBox!

>>> I was about to post bugreport at VirtualBox bugtracker, but decided to
>>> double-check the issue first. On my system floppy images change are
>>> correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1.
> 
>> The "issue" is that VirtualBox is not posting diskette media-change
>> status in the BIOS data table.
> 
> the 'issue' is that VirtualBox clearly states
>   'floppy without change-line support'

Then the "bugreport" should be a "feature request":
"Please add floppy change-line support to VirtualBox"

> int13/15 returns '01h floppy without change-line support
> int13/16 returns '06h change line active or not supported
> 
> but UIDE ignores this, and relies on change line support anyway.

That is a bug in UIDE then. I just checked LBACACHE:

It rejects non-change-line floppy drives when asked
to cache floppy (LBACACHE FLOP command line option).
It does this in setup (13.15) so there is no special
handling for 13.16 needed after setup imho... So you
cannot cache floppy on VirtualBox with Lbacache, but
at least you do not get data errors that way either.

Eric


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Tom Ehlert]

>> I was about to post bugreport at VirtualBox bugtracker, but decided to
>> double-check the issue first. On my system floppy images change are
>> correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1.

> The "issue" is that VirtualBox is not posting diskette media-change
> status in the BIOS data table.

the 'issue' is that VirtualBox clearly states
  'floppy without change-line support'

int13/15 returns '01h floppy without change-line support
int13/16 returns '06h change line active or not supported

but UIDE ignores this, and relies on change line support anyway.

maybe the real issue is that noone finds the time to do a tiny bit of
debugging the problem but finds a lot of time to write loong
emails 


Tom


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

[Jack]

> I was about to post bugreport at VirtualBox bugtracker, but decided to
> double-check the issue first. On my system floppy images change are
> correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1.

The "issue" is that VirtualBox is not posting diskette media-change
status in the BIOS data table.   So a cache (like UIDE/UIDE2), that
needs to know when a new diskette is loaded, is NOT being notified,
and the cache will continue to provide data for the PRIOR diskette!
If only the VirtualBox diskette driver is used (no cache), there is
no problem.   To use a cache, or any "subordinate" diskette driver,
posting the BIOS media-change status for a diskette MUST be done by
VirtualBox!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user