On Fri, Dec 28, 2012 at 10:21:43PM -0500, Mouse wrote:
Not that it makes much difference to me personally, but
when I see a
problem I can hardly help thinking about possible ways to solve it.
Sounds like good nerding! :-)
Might you be able to get around that by requiring the
end user to set
the vendor and device ID? Anything from a bank of switches to a serial
port on the side could be used for the purpose.
Interesting... This is nicely evil!
But I'm
sure there are people - a substantial fraction of this list, to start
with - for whom a documented PCI interface is plenty good enough.
*Documented* is certainly the way to go. In that case it would help if the
interface were a lot easier than the uPD765 (which is needlessly unpleasant
to program).
If you're willing to require special SW, it seems
to me your "bigger
problem with PCI" just evaporated. What am I missing?
I'm thinking mainly of percentages. I'd like something which 90% of users
can use with existing drivers, and only have things get ugly 10% of the time.
But then
again, I'm into emulators so I'm obsessed with making one
thing look like another thing so it works with whatever you have
already.
Then a PCI card would be fine, since the emulator can trap the ISA
access and map it into the corresponding PCI access, no?
Yeah I was talking blearily... I didn't mean that the FDC will be for use
under emulation (although of course I'll use it that way), but that since what
I do all day is emulation anyway I like cases where the new thing works just
like the old thing, only better, unless there's a good reason for it not to.
So I'd rather make a new ISA FDC that works like old ISA FDCs, and a new USB
FDC that works like any USB drive, rather than a new thing that doesn't work
like anything and only talks to the one utility program that knows about it.
John Wilson
D Bit