phil@brahms.amd.com (Phil Ngai) (12/15/90)
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? --
grege@gold.gvg.tek.com (Greg Ebert) (12/15/90)
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 #######
phil@brahms.amd.com (Phil Ngai) (12/18/90)
grege@gold.gvg.tek.com (Greg Ebert) writes: >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. Right, but that's not what I'm asking about. I'm asking about an 8-bit access to a 16-bit memory which does yank on MEMCS16*. Solari indicates it should run at 8-bit speeds even though we know it's a 16-bit device. Why? --
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/20/90)
In article <1990Dec17.171123.18719@amd.com> phil@brahms.amd.com (Phil Ngai) writes: | Right, but that's not what I'm asking about. I'm asking about an | 8-bit access to a 16-bit memory which does yank on MEMCS16*. | Solari indicates it should run at 8-bit speeds even though we | know it's a 16-bit device. | | Why? I think the CPU and memory have to both agree it's 16 bit before they do it. Otherwise it uses the bandwidth and wait states for 8 bit access. That may happen when you do a single byte write to memory, I'm not sure. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me