jls@attctc.Dallas.TX.US (Jerome Schneider) (08/28/89)
> Okay, here goes the age old question of compatibility. Windows 386 does > not work with Award BIOS. Apparently it works with Phoenix. But, I've > read that Phoenix BIOS has shoddy code for BIOS shadowing and that the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > AMI has the same problem. [ .... stuff deleted....] > So, lets [sic] make a survey: Please send Email to me specifying which > 80286 or 80386 bios people use (Phoenix, AMI, AWARD, Quadtel, etc) Let's be careful and identify what the problems are. Shoddy doesn't tell me much :-). In response to another question about 16 bit cards on an AT bus, I did some hardware and timing research. Very briefly, I discovered that the AT bus design forces any card using 16 bit memory read/write to also force ALL other devices within the same 128K byte block to use 16 bit transfers at ONE wait state. (Cards with ROM may have a hard time with one wait state at faster bus speeds (10Mhz)). If you want to know more, look in the AT tech ref. manual and examine the LA17 - LA23 address lines -- they decode one of several 128k blocks of physical memory, but are pushed onto the bus _before_ the other SA0-SA19 lines, and are used to generate a 16 bit transfer request (-MEM_CS16) to the CPU. This makes it very hard for any 16 bit card to AVOID asserting the 16 bit/one wait state signal for all addresses within the entire 128k range, without resorting to timing kludges that may be bus or device specific. With that diatribe over, let's look at shadowing: The concept relies on copying (during boot) the (slower) ROM BIOS on a peripheral to (faster) system RAM memory, then remapping (or enabling) this RAM memory to replace the ROM address space. After copying is complete, write access to the shadowed RAM is usually disabled to simulate the non-volatility of ROM. Before actually booting from a disk, the system BIOS must also scan the high memory (usually blocks C000 to EFFF), looking for ROM BIOS code on peripheral cards, and jump to the initialization code within each located ROM code. Note that the order in which system BIOS scans for peripheral BIOS and maps the ROM into shadow ram is up to the system BIOS manufacturer. For cards that use 8 bit ROM and/or 8 bit read/write memory, this is not a problem. However, most 16 bit cards with shared memory (some new VGA cards, many eithernet cards, and most multiport serial cards, etc) are afflicted with this FORCING 16 bit transfers on all devices in the entire 128k block of addresses. To avoid problems, then, some of these cards do a scan of the address space within their 128k block, and if they discover ANY other ROM or RAM present, simply operate in an 8 bit mode. Some cards try to be a bit smarter, however, and attempt to determine if RAM or ROM found in the 128k block can operate at 16 bit one wait state. If they look at those ROMs before they are shadowed, different conclusions will be drawn than if the ROMs have been copied into shadow ram. To compound this, some of the cards (smart VGA's, for example) try to determine if they have been forced by other devices to use 16 bit transfers, by timing some odd/even address fetches. If shadow code has mapped the VGA ROM into system ram before this, the answer can be different from that obtained if the VGA ROM BIOS initializes before the shadow ram is enabled. What a mess! It is my opinion that these "Shoddy Shadow Ram" problems are partially caused by each of the participants. Since there are no standards, it is difficult to know how to implement shadowing (to scan before or after the rom is copied to ram?), and very difficult for 16 bit devices to coexist peacefully with many other devices. The only solution seems to be using peripherals that can be configured as 8 bit devices, and relying on the shadow ram to speed up onboard ROM execution. In responding to Alex Nghiem's survey, you may wish to identify both 8 bit and 16 bit device shadow problems, so he may correlate this in his BIOS vendor compatibility poll. [I have no affiliation with any BIOS company -- I was just trying to explore compatibility problems before I purchased some hardware. Also, some of my statements are based on vendor documentation rather than detailed observation, so your mileage may vary....] -- Jerome Schneider UUCP: jls@attctc.DALLAS.TX.US (Guest Account) Aspen Technology Group USmail: 1678 Riverside #12/ Box 673 ZIP 80522 Ft. Collins, CO Voice: (303) 484-8466 "To err is human, to Exxon is forever." -anon. -- Jerome Schneider UUCP: attatc.DALLAS.TX.US!jls (guest account) Aspen Technology Group Ft. Collins, CO Voice: (303) 484-8466 (!killer became !attctc on July 3 - if mail bounces, try the other node)
usenet@cps3xx.UUCP (Usenet file owner) (08/30/89)
In article <9140@attctc.Dallas.TX.US> jls@attctc.Dallas.TX.US (Jerome Schneider) writes: >> Okay, here goes the age old question of compatibility. Windows 386 does >> not work with Award BIOS. Apparently it works with Phoenix. But, I've >> read that Phoenix BIOS has shoddy code for BIOS shadowing and that the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> AMI has the same problem. [ .... stuff deleted....] > >> So, lets [sic] make a survey: Please send Email to me specifying which >> 80286 or 80386 bios people use (Phoenix, AMI, AWARD, Quadtel, etc) I don't know where or how this thread started, but I have a related problem. I have a brand new HiTech 386. The relocate program they included is on a DOS 3.1 self-bootable disk. When I try to relocate EGA BIOS after booting with that disk, things work great. However, I also bought DOS 4.01 from a separate vendor, and when I boot from 4.01, relocate claims that I do not have an EGA board and timing tests have convinced me that the ROM has not been copied. Can anyone give me any help with what to do about this? Bill Su su@frith.egr.msu.edu My old .signature got eaten by the loss of my old account. |-(
usenet@cps3xx.UUCP (Usenet file owner) (08/30/89)
In article <4372@cps3xx.UUCP] su@frith.UUCP (William Su ) writes: ]In article <9140@attctc.Dallas.TX.US] jls@attctc.Dallas.TX.US (Jerome Schneider) writes: ]]] Okay, here goes the age old question of compatibility. Windows 386 does ]]] not work with Award BIOS. Apparently it works with Phoenix. But, I've ]]] read that Phoenix BIOS has shoddy code for BIOS shadowing and that the ]] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ]]] AMI has the same problem. [ .... stuff deleted....] ]] ]]] So, lets [sic] make a survey: Please send Email to me specifying which ]]] 80286 or 80386 bios people use (Phoenix, AMI, AWARD, Quadtel, etc) ] ]I don't know where or how this thread started, but I have a related ]problem. I have a brand new HiTech 386. The relocate program they ]included is on a DOS 3.1 self-bootable disk. When I try to relocate ]EGA BIOS after booting with that disk, things work great. However, ]I also bought DOS 4.01 from a separate vendor, and when I boot from ]4.01, relocate claims that I do not have an EGA board and timing ]tests have convinced me that the ROM has not been copied. Can anyone ]give me any help with what to do about this? I should have noted that my computer has (I believe) Award BIOS, so apparently the problem is not limited to Phoenix. Bill Su su@frith.egr.msu.edu My old .signature got eaten by the loss of my old account. |-(