Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!zephyr.ens.tek.com!gvgpsa!gold.gvg.tek.com!grege
From: grege@gold.gvg.tek.com (Greg Ebert)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: 8-bit xfer to 16-bit memory
Message-ID: <1802@gold.gvg.tek.com>
Date: 14 Dec 90 23:09:07 GMT
References: <1990Dec14.195053.5270@amd.com>
Organization: Grass Valley Group, Grass Valley, CA
Lines: 32

In article <1990Dec14.195053.5270@amd.com> phil@brahms.amd.com (Phil Ngai) writes:
>I was looking at Ed Solari's AT Bus Handbook and it seems to
>indicate that a bus master which does an 8-bit transfer to
>a 16-bit memory must use the slow 8-bit transfer timing
>instead of the faster 16-bit timing. Is this true? Why?
>What would happen if you used the fast 16-bit timing instead
>of the slow 8-bit timing?
>
>Anyone have a phone number for Mr. Solari?
>
>--

It dates back to the 8-bit PC and PC/XT days. The 8088 ran slower I/O cycles,
so all 8 bit devices (which dont yank on IOCS16) are given the same amount of
time as the 8088 gave them without having to yank on -IOCHRDY. Although most 
8-bit devices *should* work with a shorter cycle time, you cannot 
*guarantee* it.

There is no mistake in the Solari book. The same info is stated in the AT
Technical Reference Manual, but without any explanation.

If you think THIS is silly, I guarantee you would have a coronary if you knew
half of the monkey business regarding the keyboard controller. Sorry about
the flame, but the PC 'architecture' makes my skin crawl.

----- Boycott redwood products ---------------------------- Recycle -----
"Thou shalt abide by The GNU Manifesto"                          #####
{uunet!tektronix!gold!grege}     Register to vote, then        ##  |  ##
grege@gold.gvg.tek.com           vote responsibly             #    |    #
							      #   /|\   #
Support high oil prices, waste tax $$ on war, evade domestic   #/  |  \#
problems, and die young on foreign soil- Just say YES to Bush   #######