please see embedded comments below;
Dick
-----Original Message-----
From: Philip.Belben_at_pgen.com <Philip.Belben_at_pgen.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Wednesday, July 07, 1999 6:59 AM
Subject: Re: OT: A call to arms (sort of)
>
>
>>>And as I invented the term in this thread I get to confirm that Tony is
>>>using the correct definition :-) "Open Hardware" is hardware that is
>>>documented well enough such that anyone can recreate it from the
>>>documentation. This includes VHDL specs, PAL equations, etc.
>>
>> Are you guys familiar with the "Open Hardware Certification Program" (I
>> haven't heard it mentioned)?
>>
>> They've got a list of their own requirements at
>> <http://www.openhardware.org/conditions.html>
>
>
>Thanks, Tom, very interesting URL. I wasn't familiar with it, but it is
quite
>close to my view of "open hardware". I would tend to extend this so that
not
>only are devices supplied with enough info to write drivers, but they are
also
>supplied with enough info to connect them to computers using other buses.
In
>many cases this is the same, but it would help to have a definitive list of
>(say) what features of the bus they need / don't like / can take advantage
of.
>
>To return to Chuck and Tony's definition, yes, very laudable. But I don't
think
>you should _impose_ the requirement that everyone who builds hardware for
the
>open system should make everything public. And I like Dick's idea of
taking an
>existing standard, in the same way that Linux (for example) took the UNIX
>system, so that there is already a wide range of stuff available for your
>system. And users can build as open or closed a system as they like.
>
>Dick, I'm not sure what you meant by buying stuff "that does what you want
but
>doesn't conform to some standard" - that seems to be the opposite way round
to
>our discussion, which was about defining an open bus, and whether kit you
buy
>(which _does_ conform to the standard) will work with the bus we've
defined, or
>whether the differences between our open definition and the standard will
>prevent it.
>
What I meant by that comment was that if you decide on one standard, but a
function you feel you have to have doesn't, or you don't want to buy the
available hardware for some reason, e.g. cost, particularly in the case
where you have another potential solution, e.g. you have something that can
be made to work, you shouldn't be prevented by the standard, or by the lack
of information, from adapting what you want to use. Likewise, if you like
the majority of the signal set on ISA, except you don't like the way
interrupts work, you should be able to make that suit you. Then, supposing
you would also like to use a different interconnection arrangement, say, the
one used with VME, perhaps, then that should be OK too.
The bad thing about any standard is two-fold (at least). First, it prevents
integration errors by ensuring tbat you can plug whatever adheres to the
standard into a standard system and expect it to work, and secondly, itmakes
sure that maufacturers build cards that will work with others' cards.
Unfortunately, the resulting debate in standards committee meetings often
doesn't concern itself with how well something works as much as which mfg
has the largest installed base of "nearly" standard hardware. The problem,
you see, is that in a SCSI standards committee, a single vendor, e.g.
ADAPTEC, with enough installed base to overwhelm the market can defeat the
whole standard.
One point I was driving at was that since the interrupt scheme on ISA is
unpalatable to many, it can be ignored so long as cards being used don't
exploit that feature. There are plenty of video cards which don't use it.
There are simple ways of converting cards which do use it to use the
opposite sense if that's deemed appropriate. It's still easier to patch an
existing board than to reinvent the whole thing.
>
>ISA is a standard - of sorts. You can adopt it, and reap the benefit of
the
>standard, because a lot of kit will work with your system. Or you can
reject
>it, and said kit won't work with your system. You seemed to be suggesting
the
>adoption of a partial ISA standard. And some ISA kit will work with it,
and
>some won't. Fine for true open hardware, since you can tell what will and
won't
>before you buy it. But difficult to use the existing ISA kit with your
open
>bus, since it is the existing ISA kit that is not open, so you can't easily
tell
>whether the ISA card you had in mind will work on the modified bus. So why
>bother with ISA at all?
>
It would not be my choice to adapt cards about which I didn't know enough to
accomplish the task. However, given that much is known about ISA, including
its flaws, I find that signal set a good starting point. If you switch the
connector to be a DIN 41612 type, it's still a decent signal set, and if you
invert the interrupts, and perhaps make them level sensitive rather than
edge triggered, it might even be better. It's just that THIS PARTICULAR
existing "convention" if not standard, will lead to much easy-to-adapt
hardware, thereby leading to a useable test environment virtually right
away, while with other types, more effort is needed.
>
>On this point I agree with Tony. Edge connectors in slots, while fine for
the
>volume market, doesn't help the homebrew hobbyist. So if we choose an
existing
>bus on which to base our new open bus, choose one with indirect connectors,
like
>VME. True, few hobbyists will homebrew _everything_, but by the Chuck/Tony
>definition of open, they should be able to, if they wish.
>
>A system aimed at homebrew also makes it easier for designers to publish
designs
>which other people then build. Kits can be made of standard parts and not
>require custom PCBs. And when the bugs have been ironed out, then the PCB
>design can go off to the mass production plant...
>
>Philip.
>
>
>
>
>
Received on Wed Jul 07 1999 - 13:27:52 BST