goings@felix.UUCP (David Goings) (09/12/90)
I have been trying to get OS2 v 1.2 up and running an a 386SX clone machine. The loader and kernal seem to run just fine. The problems I'm having are with my ATI VGA-16 Bios V3m-1.06 and a mono card. 1. On booting up the system, it will not load the PMSHELL.EXE reliably. Sometimes it gets past loading the mouse driver and COM02.SYS etc., then When PM tries to load I get TWO BEEPS. shortly there after It freezes up and The FAT red button comes into action. - My work around - I map the PROTOSHELL statement to CMD.EXE and Load either SHELL OR PMSHELL BY hand. 2. When I do finally get the PM up and running if I run CodeView, (/2 etc...), I get the top 6 lines of the screen on the mono card (I.E. Display) and maybe 3 at the bottom. The middle is blanked out or has random characters. My conclusion is that some one in OS/2 land is using the mem. 3. If I can not successfully start PM, I have through experimentation determined that removing the file OS2.INI in the OS2 directory will cause PM to rebuild it, but all of my Groups and Settings are nuked. So I rebuild it and it works for a while. But when Mars and venus get aligned, I'm back where I started.(i.e. no apparent reason). 4. CHCP gives me the following message: there is no codepage prepared for this display adapter. Summary: Has anyone out there successfully got the ATI VGA-16 and a mono card to work successfully together under 1.2. How do you Keep PM up and running. ????????? P.S. The ATI support personnel told me this gem: You have to set the ATI board up for 8-bit bus use if there is a mono board in the system. Why ? A sixteen bit board cannot share a data path with an 8 bit board. Hmmm..... Well why can I run Codeview for windows on the mono board with no problems? and From what I remember B000:0000 has noth'n to do whith A000:0000 and beyond. (i.e. the VGA memory mapping in VGA mode could care less about the mono address space.). Thanks Dave G.
guy@contact.uucp (Guy Lemieux) (09/15/90)
>The ATI support personnel told me this gem: >You have to set the ATI board up for 8-bit bus use if there is a mono board >in the system. Why ? A sixteen bit board cannot share a data path with an >8 bit board. A recent posting in a newsgroup might provide your solution. In summary to what follows, the AT bus is at fault. With a 16 bit card installed, the AT bus treats the whole 128k block (A000:BFFFF for example) as a 16 bit data path. Thus, 8 bit cards will be fed 16 bit data. This doesn't seem to explain why your mono card will work with windows, however. Another possible explanation might have something to do with protected mode. I am including the contents of that posting so you may more easily understand what I am getting to. I understand what is going on, but cannot convey the information to you any easier that the way it is presented here. Guy Lemieux guy@contact.uucp From: rick@pcrat.uucp (Rick Richardson) Newsgroups: comp.unix.sysv386 Subject: Re: Adaptec SCSI and Hayes JT FAX 9600 Summary: Mixed Success rate, theory proposed Date: 12 Sep 90 13:55:39 GMT I recently posted the following query, and got back several responses by mail and news. First, the query and summaries of the replies, then my theory. Note that I did get a response from Doug Pintar who has not had a problem with this configuration. Me: | We have a customer with an Adaptec SCSI controller who is | trying to install a Hayes JT FAX 9600 fax board in his system. | The system crashes or locks up when the Hayes board is installed. Daniel Zuccarelli: | I had the identical problem described above when trying to install the | JT FAX 9600 in an 80386DX NCR machine. The problem is with the JT FAX | card and the way it handles memory references. It ignores the control line | that says this is a memory reference and just fires off the shared ram address | being on the address bus with a read or write signal. This is fine except | that on 1 Meg multiples of the shared ram address it also responds as if it | were being accessed. Robert Lin: | Rick, this excerpt from UniFax manual page 24 may help you with your | current problem with the JT9600 fax board: | "A long outstanding bug in the Hayes/Quadram JT9600 board interfers | with any use of 16bit DMA. This means the Hayes card cannot be used | in systems which have other cards that use it. For example the | Adaptec 1540/1542 SCSI hard disk controller." Doug Pintar: | I'm running a Hayes JTfax 9600 & Adaptec 1542B (have also used an A) on a | Micronics 25MHz (cache) motherboard from Gateway 2000 with NO problems at | all! Everything just came up and ran the way the FAX/ix documentation said | it would, and I was able to send a FAX the first time I tried. (Congrats, | BTW, this is almost a rarity in the Unix world [more's the pity]). Perhaps | there's some problem between the VGA and the SCSI/HAYES. This has been known | to happen -- some boards jam the bus into 16-bit mode whether they want to | be or not, and 8-bit things break. Stuart Lynne: | The problem is that the JTFax board will respond to addresses like 0x1cc000, | 0x2cc000, etc, even though it should only respond to 0x0cc000. In other | words, even though it is an 8 bit board that *should* be incapable of | responding to a 16 bit address request, it does. My latest theory: The Hayes JT FAX 9600B (aka Quadram JT FAX 9600) is an 8 bit card. Many of the replies seem to indicate that some sort of aliasing is going on. However, on the XT portion of the AT bus, the read/write signals are called SMEMR and SMEMW, and are supposed to be guaranteed active (by the motherboard) only in the first 1MB of address space. An 8-bit card doesn't have access to the upper address lines (which are on the AT portion of the bus), so it is pretty obvious why SMEMR and SMEMW must be defined this way (the AT portion of the bus has MEMW and MEMR, which are active for all addresses). So, it is difficult for me to believe that aliasing is going on, unless the motherboard is at fault. I think Doug may have hit the nail on the head, or pretty close. Its interesting to note that he runs a similar configuration without problem. Coincidentally, PC Magazine, Sept 25, 1990 has an article on page 443, "Facing the Truth About 16-bit VGA Display Adapters", which shed even more light on the problem. Its not clear to me whether the Adaptek or the VGA adapter or some other device is the source of the problem, but the theory goes like this: There's a signal, MEM-CS16, on the AT portion of the bus which a peripheral card must assert in order to switch the bus from 8 bit to 16 bit transfers. The peripheral card is supposed to decode address lines LA17-LA23 (also on the AT portion of the bus) and assert MEM-CS16 to request a 16 bit transfer. I don't know whether the bus timing allows for qualifying LA17-LA23 with additional lower order address lines. Without additional qualification of the address, a 16 bit card, such as the Adaptek or some VGA adapters, can only decode to a granularity of 128 kbytes. What happens, then, is that any 16 bit card located within A000:0000 to BFFF:0000 forces the bus into 16 bit mode for that entire range of addresses. Likewise, a 16 bit card located within C000:0000 to DFFF:0000 will jam the bus into 16 bit mode for that entire range of addresses. This is bad news for any 8 bit card that is located within the same 128k range as a 16 bit card, since it can deal only with 8 bit transfers. The solution appears to be to disable 16 bit operation of the VGA or other 16 bit card, or to move things around such that all 8 bit cards with mapped memory are in one of the 128k segments by themselves. If this theory is correct, then I would blast IBM's design as being utterly wasteful of the available address space. I'm sure that will popularize the theory, as IBM bashing is the second favorite sport here (after ISC/SCO bashing). :-) :-) BTW, the story has a happy ending, as the customer who reported the problem in the first place just moved the JT FAX over to a different machine which has a Future Domain SCSI controller. Thanks to everybody who responded, especially our esteemed competition. Its this spirit of cooperation that sets UNIX people apart from the norm!!! -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output Guy Lemieux guy@contact.uucp