davecb@yunexus.YorkU.CA (David Collier-Brown) (11/01/90)
henry@zoo.toronto.edu (Henry Spencer) writes: | You don't get hardware docs | for them. In fact, more often than not there *are* no hardware docs to be | had, no matter how cozy you are with the manufacturer: there are a couple | of gnomes chained in a back room who hack the 8088 assembler code in the | on-board ROM until it works -- hack as in "hacked to pieces with an axe" -- | and that ROM code is the only documentation on how the board really works. | Rotsa ruck trying to write a driver from that. Realize, please, that many AT peripherals have little intervention by the main cpu, and those which do tend to have rather small roms which are about half-full of code... | (I haven't tried this myself, but people who have tell me that it really | is that bad.) I've worked on AT and PC ROMSs in a past life, and the code quality is at least horrible and may extend as far as ``frightening''. I wrote PC-class machine BIOSs in Donald Knuth's WEB, and had to be quite carefull (:-)) To get the code to even land at the proper addresses was hard, and there were problems even when it did so. However, ``any problem in computer science can be solved with one more level of indirection'' (Morven's Metatheorum). One can at least write a device drive that talks a simplified bus language with a cheap 808X processor to drive the peripherals. If I only had a small number of peripherals to consider, I'd consider disassembling the 8088 code to sequences of C (yes, I've had to do so in the past) and running that, less any timing loops. The sequences in question are **small**. --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave or just Willowdale, Ontario, | postmaster@{nexus.}yorku.ca CANADA. 416-223-8968 | work phone (416) 736-5257 x 22075
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/03/90)
On 1 Nov 90 14:32:26 GMT, davecb@yunexus.YorkU.CA (David Collier-Brown) said:
davecb> henry@zoo.toronto.edu (Henry Spencer) writes:
[ .. about the problems with plentiful and cheap AT peripherals ... ]
henry> You don't get hardware docs for them. In fact, more often than
henry> not there *are* no hardware docs to be had, no matter how cozy
henry> you are with the manufacturer: there are a couple of gnomes
henry> chained in a back room who hack the 8088 assembler code in the
henry> on-board ROM until it works -- hack as in "hacked to pieces with
henry> an axe" -- and that ROM code is the only documentation on how the
henry> board really works. Rotsa ruck trying to write a driver from
henry> that.
Well, this is a problem with anybody's boards, not just the funny ones
in the PC/AT market. IBM does pretty good documentation on their boards
and peripherals, but because they have had legal problems about it.
Other big-name companies are not as good, and even if they do write
documentation, it is often exceedingly hard to get at, and even if you
get it, what you really have to work around are the microcode or design
bugs -- just consider the problems with the VGA ones, or those in the
750 microcode. I don't find AT boards all that more difficult to work
with than say DEC ones. Also, they are often based on "well" documented
chips, and they usually provide direct access to those chips.
The peripherals in the PC/AT market are not just boards -- also cases,
power supplies, monitors, hard discs, floppies, etc..., that just by
virtue of being sold to a large and competitive market are easier to
find and cheaper to buy than the same things as relabelled for say the
MacIntosh market. A lot of people stuff into Suns and other minis hard
drives that they buy in the PC/AT market, for near-wholesale prices.
davecb> Realize, please, that many AT peripherals have little
davecb> intervention by the main cpu, and those which do tend to have
davecb> rather small roms which are about half-full of code...
This is also true -- black boxes.
henry> (I haven't tried this myself, but people who have tell me that it
henry> really is that bad.)
It's pretty bad, but more power to disassemblers and bus watchers! :-/.
davecb> I've worked on AT and PC ROMSs in a past life, and the code
davecb> quality is at least horrible and may extend as far as
davecb> ``frightening''.
This is not especially true of PC/AT microcode and systems software.
Unfortunately. A lot of big-name manufactuers are reluctant to release
engineering documentation, such as source code, also because it is often
so poor in quality. Well, talent, taste and discipline are the scarcest
commodities in any branch of engineering or architecture...
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk