bios.1sremmy,
Smatram da bi se i o BIOS-u moglo nesto pametno prodiskutovati. Radio
sam sa Award-om i bilo je problema sa 386. Zasto?
bios.2dejanr,
==========================
ibm.dos/secrets.3 #47, from dave2, 2952 chars,
Wed Jul 11 20:17:05 1990
--------------------------
TITLE: some BIOS ID bytes
ROM BIOS +-- model byte
copyright | +-- submodel byte machine
date | | +-- revision
| | |
00 00 00 AT&T 6300, Olivetti PC
09/02/86 FA 00 00 PS/2 Model 30
01/10/86 FB 00 00 XT-2 (early)
01/10/86 FB 00 01 XT Model 089
05/09/86 FB 01 02 XT-2 (revised)
01/10/84 FC -- -- AT Model 099 (original)
06/10/85 FC 00 01 AT Model 239 6mHz (6.6 max governor)
11/15/85 FC 01 00 AT Model 339, 339 8mHz (8.6 max governor)
FC 01 00 Compaq 386/16
FC 01 03 some Phoenix 386 BIOS
FC 01 81 some Phoenix 386 BIOS
04/21/86 FC 02 00 XT/286
02/13/87 FC 04 00 PS/2 Model 50
02/13/87 FC 05 00 PS/2 Model 60
FC 00 7531/2 Industrial AT
FC 06 7552 "Gearbox"
04/18/88 FC 04 03 PS/2 50Z
01/24/90 FC 01 00 Compaq Deskpro 80386/25e
10/02/89 FC 02 00 Compaq Deskpro 386s, 386SX, 16mHz
06/01/83 FD -- -- PCjr
11/08/82 FE -- -- XT, Portable PC, XT/370, 3270PC
04/24/81 FF -- -- PC-0 (16k motherboard)
10/19/81 FF -- -- PC-1 (64k motherboard)
08/16/82 FF -- -- PC, XT, XT/370 (256k motherboard)
10/27/82 FF -- -- PC, XT, XT/370 (256k motherboard)
? 1987 F8 00 00 PS/2 Model 80
3/30/87 F8 00 00 PS/2 Model 80-041 16mHz
08/28/87 F8 ?? ?? PS/2 Model 80-071 16mHz
? 1987 F8 01 00 PS/2 Model 80 20mHz
09/17/87 F8 01 01 PS/2 Model 80-111 20mHz
? F8 04 ? PS/2 Model 70-121
01/18/89 F8 0B 00 PS/2 Model 70 Portable
04/11/88 F8 09 02 PS/2 Model 70 desktop
02/20/89 F8 0D PS/2 Model 70-A21
09/13/85 F9 00 00 Convertible
2D -- -- Compaq PC (4.77mHz original)
9A -- -- Compaq Plus (XT compatible)
Thanks to blaszczak and sjgrant for their help.
bios.3dejanr,
Danas sam po prvi put u životu video BIOS sa šifrom - ne znaš šifru,
ništa od butovanja PC-ja! A može i što-šta drugo, recimo da isključi
testiranje diskete pri butovanju nego odmah učitava DOS sa diska.
Čega se sve neće setiti?
Dejan
PS Naravno, kada su mi doneli računar nisam znao šifru nego sam
morao telefonirati i čekati pola dana da mi je kažu... u
međuvremenu mi je došlo da rasturim računar i promenim BIOS...
ali sam se uzdržao :)
bios.4godza,
Hello,
ima li neko Phoenix ili neki slican bios za 286 koji ima user defined hard disk
type
bios.5dejanr,
Zna li neko kako se računa checksum bios-a na 386 mašinama? Jedan
moj kolega je došao u situaciju da mora da promeni nešto u tabelama
za diskove i kako god okreneš, nikako da pogodi checksum a kad je
on takav (AMI) BIOS odbija da radi.
Najzad sam mu rekao da u jednom modelu diska poveća broj glava za 4
(što mu je trebalo) a da u nekom drugom "na divlje" smanji za 4. To
je uradilo posao. Ali, voleo bih da znam kako se checksum računa
ako negde zatrebaju veće intervencije...
bios.6alazic,
Cemu sluzi INT. 06 (SW/HW?)
bios.7zzivotic,
>> Cemu sluzi INT. 06 (SW/HW?)
Mislim da je HW i to od disketne jedinice.
Pozdrav, zz
bios.8aleksa,
Sluzi (za 286 i 386) za invalid opcode exception.
Kao SW INT nema bas previse smisla.
bios.9aleksa,
zz, verovatno si mislio na IRQ6 (to je stvarno za floppy
kontroler). IRQ6 se skoro uvek slika u INT 0EH, a ne
u INT 06H (naravno, kad radi normalan BIOS).
bios.10zzivotic,
>> zz, verovatno si mislio na IRQ6 (to je stvarno za floppy..
Da! Nevolja je što sam u poslednje vreme instalirao dosta mrežnih kartica
na različitim računarima pa čim neko pomene "a šta je INT.." meni je prva
asocijacija "mora da traži slobodnu IRQ liniju" :))
Pozdrav, zz
bios.11vkostic,
Treba mi BIOS za 386 masinu. Ploca je DTK 386 na 25 MHz sa 64K cache.
Originalni DTK BIOS pravi problema sa nekom levom LAN karticom, pa bi da
probam neki drugi BIOS.
V.K.
bios.12dejanr,
Mislim da je ova diskusija sa BIX-a veoma zanimljiva, naročito za one
koji vole da pišu drajvere za tastaturu.
==========
ibm.at/software #2294, from jstivaletta, 2975 chars, Sun Feb 10 12:01:39 1991
Comment(s).
----------
TITLE: Bogus INT 9H handlers
Banyon has told me the following:
"The 8042 or 8742 keyboard controller should not destroy the context of the
output buffer until it has either been strobed, using an output sequence to
port 61H which raises and lowers the strobe line (bit 7)...as follows...
in al,61h
or al,80h
out 61h,al
and al,7fh
out 61h,al
..."
I could not find any documentation on using port 61H to strobe the
keyboard. I did find documentation, however, that stated writing a "1" to
port 61H bit 7 reset timer 0's output latch. Therefore, I performed the
following test.
PAGE
;+---------------------------------------------------------------------------+
;| test keyboard IO port 60h
;+---------------------------------------------------------------------------+
Read60 Proc Near
r60_1:
in al,21h ;Get interrupt masks...
mov [intmask],al ;and save.
or al,0FFH ;Kill all interrupts.
out 21h,al ;...
cli ;We do not want to be interrupted.
r60_2:
in al,64H ;Wait for input buffer full.
test al,1 ; Is it full?
jz r60_2 ; No, wait then keep waiting.
r60_3:
in al,60H ;Get the scan code.
mov [Char], al ;Save it.
call waitabit ;Hang for some time.
in al,60H ;Get the scan code again.
mov [Char+1], al ;Save it also.
r60_4:
mov al,[intmask] ;Allow some interrupts.
out 21h,al ;...
mov al,[char] ;Get the first scan code
call display_hex ;and display it.
mov al,[char+1] ;Get the next scan code
call display_hex ;and display it
xor bx,bx ;Set page.
mov ax,0e0dh ;CR
int 10h ;...
mov ax,0e0ah ;LF
int 10h ;...
jmp r60_1 ;do it all over again
Read60 EndP
On every machine I have tried this on, the first scan code read does not
agree with the second scan code read. I have tested over 20 different
PCs from different vendors. Not one machine tested showed the first scan
code equal to the second scan code. What I mostly saw was make code
break code for the two reads. Are they feeding me a crock or what?
They claim most packages that hook INT 9H read port 60H without issuing
a disable keyboard command to port 64H. They told me the code is correct
because everyone who hooks INT 9H to read the scan code does it this way.
This situation has race condition written all over it. I see it as poor
programming and will not be dissuaded by rhetoric claiming "it must be
right because everyone does it".
What do you think?
P.S. Any PC developers who are writing or have written INT 9 handlers to
preview the scan code at port 60H had better take heed and confirm that
your code is correct. I will be looking for these bad INT 9 handlers and
notifying the companies concerned (such a Borland). Unless or until my
analysis of the situation is proven incorrect, I will be dumping all over
programs containing this race condition. I have some written evidence
that Sidekick is one of those programs. I am going to verify this on
Monday. It's looking good that Borland will receive my first dump.
==========
ibm.at/software #2295, from twagner, 1005 chars, Sun Feb 10 15:39:19 1991
Comment to 2294. Comment(s). More refs to 2294.
----------
> They told me the code is correct because everyone who hooks INT 9H
> to read the scan code does it this way.
They're right, everyone hooking INT 9 reads the scan code this way -
BECAUSE THERE OFTEN IS NO OTHER WAY. I think you're overreacting with
your threat of "I will be dumping all over programs containing this
race condition". Complain with IBM that they didn't get it right the
first time, and only provide the scan code intercept in newer BIOSes.
There really is nothing to it - I have *never* experienced *any* lost
keystroke with several routines intercepting INT 9 and peeking at
port 60. Sure, it would be cleaner to check for an extended BIOS and
hook the INT 15 keyboard intercept if present (I actually do this in
a routine of mine to avoid the port input), but this requires a lot of
additional code, something no one likes in a TSR. Do you actually
know of ill effects of this style of programming? Any real-life
examples (not dummy test programs) of key codes getting lost?
Thomas
==========
ibm.at/software #2296, from terjem, 1163 chars, Mon Feb 11 06:40:14 1991
Comment to 2294.
----------
> TITLE: Bogus INT 9H handlers (Also comment to 2295, twagner)
I believe you are right! I have found that on many new "enhanced" keyboards,
the port 61 strobing does NOT affect the transmitting of new scan codes from
the kbd hw.
After realising this, my Norwegian keyboard driver immediately got the code
to transmit a STOP command via PORT 64, as soon as it gets an interrupt.
(even before reading the scan code!)
The way I see this, the port 61 strobe was only active on the original PC.
> Do you actually know of ill effects of this style of programming?
> Any real-life examples (not dummy test programs) of key codes getting lost?
Yes, I DO!
We had to exchange the kbd controller BIOS on more than 100 PC's last year,
because the combination of 386MAX (or QEMM) with norwegian kbd, would cause
Word Perfect to loose some of the scan codes transmitted from the cursor keys.
With NumLock on, the "Enhanced" kbd has to send 4 scan codes for each press/
release of a cursor key: (224 42 224 72 for cursor up). These 4 codes are
sent back-to-back, so the risk of overrunning the receiver is real, and will
happen on some PC's.
Terje (From Oslo, Norway)
==========
ibm.at/software #2297, from jstivaletta, 694 chars, Mon Feb 11 11:50:47 1991
Comment to 2295. Comment(s).
----------
Yes, I do know of real world problems. Banyon's PCPrint program is
the one I am currently investigating. The solution to reading port 60H
from an INT 9H handler is to simply issue a disable keyboard command (0adh)
to the 8042 command port at 64h prior to doing the IN at 60h. As networks
become more widespread, this race condition will become more evident.
I will be investigating ROM BIOS INT 9H handlers to confirm that they
issue disable/enable commands to the 8042 command port. If any do not,
they will pose a problem. I am confident that they do, but must be
certain. A solution exists and it works. Therefore, I will not be
changing my opinion on bogus INT 9 handlers. Sorry.
==========
ibm.at/software #2298, from twagner, 1676 chars, Tue Feb 12 05:17:15 1991
Comment to 2297. Comment(s).
----------
> Yes, I do know of real world problems
Oh - that's good to know. We're running with a network and German
keyboard drivers, and, as I said, I never experienced problems.
> The solution ... is to simply issue a disable keyboard command...
Hmmm... but what do you do if you discover that you don't want the
keystroke, and have to pass it on to the next in chain? Don't you
have to re-enable the keyboard *before* doing so, causing the same
race condition (or even worse, 'cause you spent a lot of time
shipping the controller commands back and forth)? Or would you simply
leave the keyboard disabled and hope for the next (which doesn't have
to be the BIOS) to re-enable it?
With the tons of TSRs already out *not* caring about keyboard
enable/disable, I'd be very cautious about leaving the keyboard
disabled. Just check all the so-called "expert" books on TSR
programming - their examples all merrily mess with the keyboard ports
without any regard to keyboard disable. Most even keep telling their
readers that you have to acknowledge the keyboard with the OUT to
port 61, even though that was only true on PC/XT class machines (I
don't know what prompted IBM to give up this simple and reliable
scheme).
What do you think of this solution:
IF the BIOS does not support keyboard intercept
THEN you can be 99.9% certain that it is an XT type machine,
and you can peek at port 60h with no ill effects, since
the keyboard will wait for an acknowledge through port 61h;
ELSE do not use port I/O at all, but instead hook into the INT 15
keyboard intercept.
Does anyone know of AT BIOSes *not* supporting the keyboard intercept
hook?
Thomas
==========
ibm.at/software #2299, from jstivaletta, 1534 chars, Tue Feb 12 08:10:05 1991
Comment to 2298. Comment(s). More refs to 2298.
----------
The IBM AT ROM BIOS disables/enables the keyboard in their INT 9h handler.
If you want to pass control down the chain it is not necessary to enable
the keyboard. The ROM BIOS will enable the keyboard when it is done. There
is a potential problem with multiple INT 9 handlers and a handler that does
not enable the keyboard if it decides to eat the scan code. That is why it
is important that all INT 9 handlers be corrected. It is a shame that this
situation is agravated by the "expert" books, but their writers are developers
no different than us and are entitled to make bad assumptions. You should
notify the Publishers/Writers of those books so that they may correct their
books. I plan on writing an article to be sent to Byte, Dr. Dobbs, Computer
Languages, PC Magazine, etc describing the potentially, pending problems.
I have been told that that we have six major customers complaining about
the PCPrint problem. I have also been told that complaints are coming in
from customers about Word Perfect and some terminal emulator software also.
I have requested more detailed info on reproducing these new problems. I
want to try to reduce the impact of this problem. Customers want their
problems fixed. I can't fix them if the software is not mine.
I have not yet encountered an AT or MC rombios that does not disable the
keyboard before reading port 60h. I will let you know if I do. I will
also mention all the BIOS I have checked by manufacturer and model.
At least this is a problem with a viable solution.
==========
ibm.at/software #2300, from twagner, 1991 chars, Tue Feb 12 19:12:54 1991
Comment to 2299. Comment(s).
----------
> That is why it is important that all INT 9 handlers be corrected
Ah, but that's why I suggested using the INT 15 keyboard intercept
instead of disabling the keyboard. All INT 9 handlers being
corrected - not in your lifetime. If some other TSR is eating
keystrokes because it reads port 60, you can tell the customer to
complain with the author of that TSR. If your program kills all TSRs
down the chain, your customer will complain with *you* and tell *you*
to fix it, no matter how often you explain to him that it's all the
fault of the other TSRs sloppy programming (at least that's my
experience even with knowledgeable customers).
The keyboard intercept INT is called by the BIOS *after* it has
disabled the keyboard, so there is no danger of race conditions with
this method, and you're not adding any additional delay to the INT 9
processing chain.
After thinking about it for a while, I'd strongly recomend against
using the keyboard disable method. If any TSR should pop up that
doesn't know about this (and 95% of all TSRs out today, and likely
out the next 5 years, don't know), the machine will drop dead, and
even the three-finger-salute won't revive it. I'd say most users
would rather accept a few lost keystrokes. Why not use the INT 15
intercept instead? Are there any known problems with it?
> so that they may correct their books
The books I found on a first look that recommend reading port 60 in
the INT 9 chain of a TSR are
- The MS-DOS Encyclopedia (Microsoft Press; R. Duncan, ed.),
- Undocumented DOS (Addison Wesley; A. Schulman et al),
- Turbo C Memory-Resident Utilities (MIS Press; Al Stevens).
At least the first two are reference works any serious TSR programmer
will consult. Well, you could try getting them changed (good luck),
but what about those issues already sold? We'll have to live with
this style of programming for years to come. I'd say you'd be better
off with a scheme that doesn't break existing and future programs.
Thomas
==========
ibm.at/software #2301, from roedy, 382 chars, Tue Feb 12 19:37:47 1991
Comment to 2298. Comment(s).
----------
AT BIOSs not supporte the keyboard intercept? Certainly
all the NEW ones do. However an old XT or AT will give you
10 times the headache of a new one with software compatibility.
Boy have I poured wasted hours into old machines trying to get
software to work. You can tell the owners this, but they would
sooner throw consulting money down the tube that upgrade the
motherboard.
==========
ibm.at/software #2302, from roedy, 211 chars, Tue Feb 12 19:38:53 1991
Comment to 2301. More refs to 2301.
----------
What is really infuriating about working with these old machines
is usually you simply cannot get them working 100%. Then the
customer refuses to pay anything at all -- no matter how much
time you have put in.
==========
ibm.at/software #2303, from roedy, 276 chars, Tue Feb 12 19:40:34 1991
Comment to 2300. Comment(s). More refs to 2300.
----------
Perhaps what we need is a keyboard driver that replaces the BIOS,
that is loadable as a TSR. Other TSRs can then relax and know the
basic functions are all available and can be trusted to work properly.
If anyone has trouble, just tell him to put this driver in config.sys.
==========
ibm.at/software #2304, from jstivaletta, 805 chars, Tue Feb 12 20:46:06 1991
Comment to 2300. Comment(s).
----------
I agree. I would use INT 15h function 4Fh. I have no plan on ever using
INT 9h unless I'm running on an XT or some AT BIOS that doesn't support INT15h
I have yet to find an AT BIOS that did not support INT 15h keyboard intercept.
We still have customers in the field complaining about losing characters
however. So I still have to deal with their problem. I am going to try
an INT 9h handler that disables the keyboard, calls the next INT 9h handler,
and then enables the keyboard when the call returns. I am running a test
over next 2 days and then we will send the TSR to the six customers who are
losing characters. I hope it will resolve their problems for the time
being as we work on a better solution.
In the mean time. I still think developers should be made aware of the race
condition.
==========
ibm.at/software #2305, from jstivaletta, 473 chars, Tue Feb 12 21:08:30 1991
Comment to 2301.
----------
Fortunately, when we have a customer that has an older BIOS with a bug, we
will send him a BIOS update. If it is a newly discovered bug, I fix it,
burn new PROMs and have support send him the PROMs. Those fixes then
become part of the next official customer release. Unfortunately, there
is nothing I can do to correct the current set of problems.
You can go a long way correcting old BIOSes with MASM, Sourcer, a PROM
burner and a good understanding of the ROMBIOS.
==========
ibm.at/software #2306, from twagner, 417 chars, Wed Feb 13 10:49:16 1991
Comment to 2303. Comment(s).
----------
> Perhaps what we need is a keyboard driver that replaces the BIOS
It's already here - try KEYB US. Installs as a TSR, and supplies all
necessary functionality (intercept, keyboard disable etc.). However,
it won't completely solve the lost keystroke problem with "old style"
TSRs peeking at port 60. You can be sure it will re-enable the
keyboard if you disabled it - but only if the next TSR chains to it.
Thomas
==========
ibm.at/software #2307, from twagner, 542 chars, Wed Feb 13 10:49:31 1991
Comment to 2304. Comment(s).
----------
> I still think developers should be made aware of the race condition.
I agree 100%. I didn't believe there being a problem at first. In my
programs, I usually avoided peeking at the port more out of a gut
feeling than out of knowledge of real dangers. I knew about port 60
being unlatched by reading it, but, well, nobody types *that* fast.
Lately I even wrote a keyboard interceptor with port peek - everybody
does it, and it seems to work, so why worry... I'll rewrite it to use
the INT 15 hook ASAP.
Thanks for your contribution
Thomas
==========
ibm.at/software #2308, from roedy, 146 chars, Wed Feb 13 17:23:22 1991
Comment to 2306. Comment(s).
----------
How big is KEYB US compared with what say an equivalent assembler
program by Twagner would be? As I remember these KEYB things are
Pantagrulian.
==========
ibm.at/software #2309, from jstivaletta, 176 chars, Wed Feb 13 19:47:22 1991
Comment to 2307. Comment(s). More refs to 2307.
----------
Expert touch typists can type very fast. Hopefully, we will not have too
many problems. My INT 9H handler seems to be running fine and may
quiet some customer complaints.
==========
ibm.at/software #2310, from jstivaletta, 1006 chars, Wed Feb 13 20:21:19 1991
Comment to 2307.
----------
To sum up what I know to date, It seems the IBM XT latches the port at
60H until the keyboard is strobed or an enable command is sent to the 8042.
The IBM AT, however, did not keep the keyboard strobe, therefore, only
enabling and disabling the keyboard commands sent to the 8042 now work.
Since reading port 60H was safe on the IBM XT, it became standard programming
practice to peek at 60H to view the scan code. In fact that was the
only way to preview the scan code on the IBM XT. Peeking at port 60H is
seen as a standard technique. It very rarely causes problems on the IBM AT
and compatibles. When it does, it can be very perplexing to vendors and
their support organizations. I think that interrupt rich environments such
as networks, faster 8042s and faster keyboard processors are beginning
to reveal the problem.
I've heard from a vendor that they have customers running on a network who are
complaining of losing characters when using Word Perfect while printing to
the resident printer.
==========
ibm.at/software #2311, from terjem, 647 chars, Thu Feb 14 03:39:27 1991
Comment to 2308.
----------
; How big is KEYB US compared with what say an equivalent assembler
The KEYB program IS written in assembler (but not very *good* assembler).
It uses approx. 4-6 kB depending on version/language, and it is maybe 50%
larger than the old language-specific programs (KEYBNO.COM here in Norway).
My norwegian driver, with dead keys, national letters etc. uses 512 bytes,
but this is achieved by chaining to the bios for those keys that are the
same in Norway as in USA.
My guess would be that a good programmer could do a total replacement of
KEYB US in 1-2kB. (There is a LOT of different key combinations to support!)
Terje (From Oslo, Norway)
==========
ibm.at/software #2312, from terjem, 542 chars, Thu Feb 14 03:39:44 1991
Comment to 2309.
----------
> Expert touch typists can type very fast. Hopefully, we will not have too
That's not the main problem: The problem is the keys that generate multiple
scan codes for each press/release. These codes are sent at approx. 10000baud,
with very little delay between them, i.e. 1000 codes/second.
The problem first appeared here when we got slow 386-SX (16MHz) machines,
and used QEMM386/386MAX. The virtualization of the interrupts would increase
the latency to the point where cursor keys started generating digits.
Terje (From Oslo, Norway)
bios.13.bale.,
Da li neko ima EMS driver za KT NEAT ploču? Valjda
se zove 'emm.sys'.
.bale.
bios.14macak,
Kao prvo ZDRAVO!!!
Koliko sam razumeo,.bale.,imas DTK NEAT plocu.
Ja imam 386sx plocu i dobio sam driver koji se zove 'nemm.sys'
(od NEAT EMS DRIVER).
Ukoliko te interesuje ostavi mi poruku.
macak
bios.15.bale.,
To nije bilo za mene, nego mog druga. Našao sam ono što sam tražio.
Hvala.
Regards from .bale. !
#8*)+-<
bios.16bojanp,
Potreban mi je BIOS za XT-a, koji podrzava enhanced keyboard.
Nabavio sam novu tastaturu a moj BIOS iz '84 je ne podrzava.
Pozdrav Bojan
bios.17dherceg,
PROBLEM SA AMI BIOS 286 i AMI BIOS 386 i QEMM 5
-----------------------------------------------
Na dva računara sa AMI BIOS (radi se o 286 i 386SX) imam sledeće probleme:
NA AMI 286 RAČUNARU:
- pri instalaciji QEMM 5 računar se blokira
- PARADOX ne prepoznaje 4Mb memorije EXTENDED, iako postoji na ploči
- WINDOWS takođe ne prepoznaje 4Mb
- WP51 isto tako
NA AMI 386SX RAČUNARU:
- QEMM 5 takođe blokira kada se instalira, računar ima 2Mb koji se ne mogu
koristiti
Da li je stvar u BIOS-u, i kako se može ispraviti da radi?
Windows je instaliran sa originalnih disketa, pa opet ništa -> problem je u
računaru.
HELP!
bios.18mjova,
> PROBLEM SA AMI BIOS 286 i AMI BIOS 386 i QEMM 5
> Na dva računara sa AMI BIOS (radi se o 286 i 386SX) imam sledeće probleme:
> NA AMI 286 RAČUNARU:
....
> Da li je stvar u BIOS-u, i kako se može ispraviti da radi?
> Windows je instaliran sa originalnih disketa, pa opet ništa -> problem je u
> računaru.
Pa vidiš, sličan problem (možda) video sam na 386SX (DTK ploča).
Radilo se o tome da je QEMM pronalazio VGA ROM dužine 24 kb a ne
32 kb. Pri svakom pristupu ekranu (sem pisanja texta) dolazilo
je do blokiranja računara. Kada smo dodali parametar EXCLUDE=xxxx-yyyy
(x-y adresa ROM-a) sve je proradilo, možda je nešto slično i kod tebe.
Ovaj novi QEMM traži i rupe u BIOS-u, ako je nešto pogrešio onda sistem
verovatno zato pada.
mjova
bios.19nkbog,
> NA AMI 286 RACUNARU:
>
> - pri instalaciji QEMM 5 racunar se blokira
QEMM na 286 !!??? (QRAM moze, ali QEMM NIKAKO)
> NA AMI 386SX RACUNARU:
>
> - QEMM 5 takode blokira kada se instalira, racunar ima 2Mb koji se ne mogu
> koristiti
Koliki je AMI BIOS? Lako moze biti problem da ti je BIOS 64k, mada bi QEMM
to trebao da OK resi. Ako je tu problem, izbaci blok memorije od F000-F800 sa
EXCLUDE. Da li ti ploca ima SHADOW RAM ili nesto slicno? Ako ima iskljuci.
Najvaznije: Kako se manifestuje zaglavljivanje racunara? Treba jos malo
informacija.
NB.
bios.20ppekovic,
Kako da softverski uključim/isključim NumLock???!!!
Paya
bios.21dejanr,
>> Kako da softverski uključim/isključim NumLock???!!!
VKostić, KBSTAT. Prijatno!
kbstat.combios.22bulaja,
> Kako da softverski ukljucim/iskljucim NumLock???!!!
Lako, samo promeni Shift status bajt na adresi 0:418h, tj. setuj peti
bit za ukljucenje NumLocka (i obrnuto za iskljucenje). Evo rasporeda
statusnih bitova:
0:418h - Shift Status
bit 0 - Right Shift
1 - Left Shift
2 - Ctrl
3 - Alt
4 - Scroll Lock
5 - Num Lock
6 - Caps Lock
7 - Ins
Sve ovo se moze naci i u Norton Guideu za assembler na low memory
usage, a tamo mozes naci i objasnjenja drugih statusnih registara
tastature.
Bulaja
bios.23beast,
Za taj kbstat je potrebno 6 kb?
Evo malo manji programčić,koji iskljucuje samo numlock,ali to
je ppekovic i hteo.
numlock.combios.24ppekovic,
Hvala svima za NUM LOCK ON/OFF
Paya
P.S. Bulaja, ne radi sistem sa 0:0418, proveri. I logično je što ne radi,
razmisli.
.,
bios.25.bale.,
Kad smo već kod Norton Guide-a, da li neko ima verziju od 1. maja '88. Ja imam
dosta fajlova za njega, ali i verziju od avgusta '87, koja neće da radi :(((
Lepo ostane rezidentan, ali kada treba da se aktivira na odgovarajući taster,
on samo bipće... A to bi mi tako značilo... :(
Regards from .bale. !
#8*)+-<
bios.26ppekovic,
Evo na kraju rešenja za NUM LOCK ON/OFF, možda nekome
zatreba. Bulaja je bio blizu, pogrešio za jedan bajt. Dakle, nije
rešenje u adresi 0:0418h nego u 0:417h.
NUM LOCK se uključuje ako se sadržaj 0:0417h OR-uje sa
00100000b.
Isključuje se, naravno, sa AND 11011111b.
Inače, značenje pojedinih bitova je sledeće:
bit 0 - desni SHIFT
bit 1 - levi SHIFT
bit 2 - CTRL
bit 3 - ALT
bit 4 - SCROLL LOCK
bit 5 - NUM LOCK
bit 6 - CAPS LOCK
bit 7 - INSERT
Paya
bios.28nkbog,
Jeste da nam je Norton Guide cesto jedini izvor INFS, ali, dok u njemu se
adrese u LOW memoriji pisu 0:417, primetio sam da se u vecini programa (pa i u
BIOS-u) obicno pise 40:17. Ovako je po mom misljenju i bolje, (eh segmenti,
segmenti ;).
NB.
p.s. kad smo kod izvora INFS, evo spiska prekida iz februara 1991.
(PUNO veceg od ovog na Sezamu).
bios.29majkl,
O softverskoj kontroli NumLock-a je već bilo reči. Problem koji
se tu javlja su led diode koje ne reaguju na prosto menjanje sadržaja
0:417h. Rešenje je objavljeno u okviru "bajtova lične prirode":
program numl;
uses dos;
var
regs : Registers;
begin
memŠ0:$417Ć:=MEMŠ0:$417Ć XOR 32;
intr(09,regs);
end.
Pozdrav, Majkl
bios.30bulaja,
> O softverskoj kontroli NumLock-a je vec bilo reci. Problem koji se
> tu javlja su led diode koje ne reaguju na prosto menjanje sadrzaja
> 0:417h. Resenje je objavljeno u okviru "bajtova licne prirode":
Meni radi bez ikakvih problema, tj. promenim stanje u 0:417 i odmah se
upali lampica i NumLock radi.
bios.31dejanr,
>> Meni radi bez ikakvih problema, tj. promenim stanje u 0:417 i odmah se
>> upali lampica i NumLock radi.
Koliko se sećam, ovo rešenje u većini slučajeva radi na AT+ mašinama,
ali se često desi da sledeći pravi pritisak na NumLock loše reaguje ili
da bude sličnih peripetija. Zato je najbolje koristiti rešenje iz
"Bajtova".
bios.33alexa,
Datoteka inter291.zip se nalazi u R:\IBMPC\MISC podeljena u
3 dela, kao int291_1.zip, int291_2.zip i int291_3.zip.
Hvala na prilogu.
bios.34jgolub,
Kao sto ste mogli primjetiti svi koji ste probali ZX SPECTRUM
simulator on na neki nacin "blokira" tastaturu (NumLock se ne moze
mijenjati) ali omogucava detektiranje vise tastera pritisnutih
odjednom. To sto mene zanima je "stos" kako to izvesti posto mi
treba za neke odredjene stvari.
Hvala.
Pozdrav, Jerko #:)
bios.35miro,
Evo ti jedan moj modul gde se moze videti kako se registruju
pritisnute tipke bez obzira na to koliko ih je do sada vec
pritisnuto.
Nadam se da ce ti pomoci.
IMPLEMENTATION MODULE RKeyb;
IMPORT
Lib,
RCash,
Terminate;
FROM SYSTEM IMPORT
DI, (* Disable interrupts *)
GetFlags,
SetFlags,
In,
Out;
TYPE IPROC = PROCEDURE ( (* flags : *) BITSET ); (* Interrupt Proc
*)
VAR Irpt[0:0], (* Interrupt table *)
SaveIrpt : ARRAY [0..10] OF IPROC;
InstalledTick : BOOLEAN;
(*# save *)
(*# call(reg_saved => (ax, bx, cx, dx, es, di, ds, si) ) *)
(*# call(interrupt => on ) *)
PROCEDURE Int9(flags : BITSET);
(* Keyboard HardWare interrupt. *)
VAR sc: SHORTCARD;
Released : BOOLEAN;
BEGIN
Released:=FALSE;
sc:=In(60H);
IF sc > 128 THEN
DEC(sc, 128);
Released:=TRUE;
END;
IF sc=ScanCode THEN (* pass only for expected Scan Codes *)
sc:=In(61H); (* sa ovog porta stizu scan codes *)
Out(61H, SHORTCARD(BITSET(sc)+{7})); (* ove tri linije koda *)
Out(61H, sc); (* opsluzuju *)
Out(20H, 20H); (* interrupt controler
*)
IF Released THEN (* if key was released then do what
you want to do *)
MojProcReleased;
ELSE
MojProcPushed; (* else, key was pressed, do... *)
END;
ELSE
SaveIrpt[09H](flags);
(* Chain old Int 9. *)
END;
END Int9;
PROCEDURE Install();
VAR fl : CARDINAL;
BEGIN
Installed:=TRUE;
fl:=GetFlags();
DI;
SaveIrpt[9H]:=Irpt[9H];
Irpt[9H]:=Int9;
SetFlags(fl);
END Install;
PROCEDURE Reset();
VAR fl : CARDINAL;
BEGIN
IF Installed THEN
fl:=GetFlags();
DI;
Irpt[9H]:=SaveIrpt[9H];
SetFlags(fl);
Installed:=FALSE;
END;
END Reset;
BEGIN
Installed:=FALSE;
Terminate.Install(Reset);
END RKeyb.
(* A sada ide definicioni modul *)
DEFINITION MODULE RKeyb;
VAR ScanCode : SHORTCARD;
(* u ovu varijablu upises scan-code koji te zanima
a ako nemas tabelu scan-codes poslacu ti i to,
mrzi me sada da kucam
*)
Installed : BOOLEAN;
PROCEDURE Install();
PROCEDURE Reset();
END RKeyb.
bios.36dejanr,
==========
ibm.at/software #2382, from chill, 1034 chars, Sun May 5 15:26:24 1991
Comment to 2381. Comment(s).
----------
The IBM AT Technical Reference manual is the definitive
source for the CMOS stuff.
To access the CMOS, just send the address to access to the
I/O port at 70h, and read or write the data at 71h. For example:
mov dx,70h ;CMOS address port
mov al,10h ;address byte 10h in CMOS RAM
out dx,al
inc dx ;CMOS data port
in al,dx ;read diskette drive type byte
The address scheme goes something like this;
00-0d real-time clock information
0e diagnostic status byte
0f shutdown status byte
10 diskette drive type byte (drives a & b)
11 reserved
12 fixed disk type byte (types 1-14)
13 reserved
14 equipment byte
15 low base memory byte
16 high base memory byte
17 low expansion memory byte
18 high expansion memory byte
19 disk C extended byte
1a disk D extended byte
1b-2d reserved
2e-2f CMOS checksum
30 low expansion memory byte
31 high memory byte
32 date century byte
33 information flags for POST
34-3f reserved
*note: the checksum does not include values of CMOS RAM above
address 2dh
Chris
bios.37alexa,
> The IBM AT Technical Reference manual is the definitive
> source for the CMOS stuff.
Jeste, ako hoćete da vam aplikacije rade na svim AT mašinama;
razni proizvođači računara, kao i autori BIOSa, dodavali su
razne stvari; da i ne pominjemo ona 'reserved' područja.
Tu se nigde (ako se ne varam) ne govori u user-defined tipu
diska (čiji se parametri smeštaju u CMOS), o mogućnosti
da se u CMOSu specificira 'zamena' prve i druge disketne
jedinice, o novim mašinama koje imaju extended CMOS (XCMOS) u
koji se upisuju SETUP parametri za programabilne VLSI čipove
iz raznih AT chipset-ova itd.
bios.38nkbog,
Manifest pokazuje da ima neceg i na adresama do 7f - uglavnom nule, ali
ima i dosta nenula (koji izraz). Da li neko ima nestandardniji spisak iz
CMOS-a. J
NB.
bios.39alexa,
> Manifest pokazuje da ima neceg i na adresama do 7f
Ako se ne varam, originalni AT ima CMOS samo do adrese 3f.
bios.40nkbog,
>> Manifest pokazuje da ima neceg i na adresama do 7f
>Ako se ne varam, originalni AT ima CMOS samo do adrese 3f.
Znam, zato sam i pitao da li neko ima nestandardniji spisak.
NB.
bios.41jgolub,
>>u ovu varijablu upises scan-code koji te zanima
>>a ako nemas tabelu scan-codes poslacu ti i to,
>>mrzi me sada da kucam
Ne, nemam ih i bio bih ti vrlo zahvalan.
Inace hvala na proceduri, mada cu morati malo obnoviti znanje iz
Pascala (kojeg vec najmanje 3 godine uopce ne koristim) ali nema
veze.
Ako sam ja dobro shvatio, tastatura salje jedan kod kad
pritisnes neki taster, a drugi kad ga otpustis i to nezavisno dali
je koji vec stisnut i na taj nacin zamjenom vektora sa BIOS
procedure mozes postici ocitavanje pritiska vise tastera odjednom.
Dali grijesim?
Pozdrav, Jerko #:)
bios.42miro,
>>Inace hvala na proceduri, mada cu morati malo obnoviti znanje iz
>>>>Pascala (kojeg vec najmanje 3 godine uopce ne koristim) ali nema
>>>veze.
Nije Pascal, nego Modula 2, ali nema veze. Inace, tastatura na
svaki pritisak ili otpustanje salje scan code, s tim sto je scan
code otpustanja nekog tastera za 128 veci od scan code-a
pritiskanja. Zatim se ti scan codovi obradjuju handlerom hardware
interrupta 9 (to se vidi iz procedure). Originalni handler ce
ignorisati pritisnuta dva char tastera ili nesto slicno (reagovace
samo na jedan taster ili kombinacije sa Ctrl, Alt i Shift). Ako
napises svoj handler koji ce presretati stari handler, mozes da
trazis da se odradi bilo sta, u zavisnosti od pritisnutih ili
otpustenih tastera (bilo jedan ili vise njih istovremeno, i nije
uopste bitno da li je to Ctrl ili slicno, vazno je samo da je to
DUGME :) na tastaturi)
Scan codes dobijas u pondeljak, sve mi ja na poslu a upravo sam
stigao kuci sa sajma tehnike.
Pozdrav, Miro.
bios.43mmihajlovic,
Jos malo o kontroli Lock statusa. Prilozen je asemblerski
program za punu kontrolu Lock indikatora. Program koji je dao
Majkl, (u TP) naravno radi sta treba ali je malo dug (za moj
ukus) za tako jednostavnu operaciju. Prilozeni program je dug
168 (170) bajta i daje punu kontrolu svih Lock statusa. Licno
nisam imao problema sa sinhronizacijom Lock indikatora, bez
obzira da li je neki keybxx drajver bio prisutan ili ne. U
svakom slucaju INT 09H se moze primeniti (odnosi samo 2 bajta),
ukoliko se za to ukaze potreba.
MM
lock.asmbios.44majkl,
Kako se ne radi o tsr programu svaka dužina ispod 2K je jednako
dobra, jer će biti zauzet jedan klaster na disku.
Mogućnost da se nešto izvede iz viših programskih jezika je
uvek interesantna, jer se to onda lako uklapa u ozbiljniji projekat.
Pozdrav, Majkl
bios.45mmihajlovic,
Slazem se, svakako, ali moras priznati da je lepse videti duzinu 168
umesto npr 1569 kad das DIR.
MM
bios.46ivan.s,
Pisem jedan rezidentan program, i treba mi rutina koja koja
proverava da li je kurzor vidljiv na ekranu.
Kurzor se moze uciniti nevidljiv na nekoliko nacina : moze se
postaviti u 25. red, moze se iskljuciti pomocu Int 10, func 01,
Set Cursor Size (postavljanjem 5 i 6 bita CH ili CL na 10).
Pozicija kurzora i stanje kurzora moze se procitati pomocu Int
10, func 03, ili na adresama 0:450h-0:45f (pozicija) i 0:460h
(stanje - Cursor End\Start Scan line\state).
Medjutim Int 10, func 03, samo procita ono sto pise na pomenutim
adresama. Stanje 0:450-460h azurira BIOS prilikom poziva Int 10,
func 1, 2. Medjutim ima programa, koji ne koriste Int 10, i iskljuce
kurzor, a da BIOS (pa onda ni moj program :((( ) to ne zna.
Jedan od takvih je Norton Editor, pa Norton Guide itd.
Dakle treba mi neka sekvenca IN\OUT komandi, koja ce direktno od
graficke kartice saznati da li je kurzor vidljiv ili ne.
bios.47mmihajlovic,
> Pisem jedan rezidentan program, i treba mi rutina koja koja
> proverava da li je kurzor vidljiv na ekranu.
> ...
> Dakle treba mi neka sekvenca IN\OUT komandi, koja ce direktno od
> graficke kartice saznati da li je kurzor vidljiv ili ne.
Ne postoji opsti metod za odredjivanje da li je kursor vidljiv ili ne.
samo VGA adapter omogucuje citanje za to neophodnih CRTC registara.
Za ostale adaptere se moras osloniti na podatke iz BIOS segmenta 40h.
Jedini generalno citljivi CRTC registar je onaj za poziciju kursora
(CRTC index 0Eh=high byte, 0Fh=low byte).
Kursor je nevidljiv u slucaju:
a) kad je njegova pozicija izvan skrina (check video page)
b) start scan linija kursora >= 20h
c) start scan linija > end scan linije
Za dobijanje pozicije kursora treba proveriti BIOS bytes 40:50=X,
40:51=Y ili CRTC.0F=low byte, CRTC.0E=high byte i uporediti sa CRTC base
(CRTC.0D=low byte, CRTC.0C=high byte ili pomocu BIOS 40:62).
Za dobijanje start/end scan linija kursora treba koristiti CRTC.0A=start,
CRTC.0B=end ili BIOS bytes 40:60=end, 40:61=start.
MM
bios.48ivan.s,
>> samo VGA adapter omogucuje citanje za to neophodnih CRTC registara.
>> Za ostale adaptere se moras osloniti na podatke iz BIOS segmenta 40h.
Na zalost, sasvim si u pravu :(( Izgleda da za moj problem nema resenja.
Naime podaci iz BIOS segmenta 40h nisu uvek azurni. Radim sa
najmanje dva programa, koji ustanove da rade sa Herculesom, i
onda kurzor ukljucuju/iskljucuju pomocu IN/OUT direktno kod
graficke kartice. Tako BIOS nema pojma da je stanje kurzora
promenjeno.
Prljavo pisani programi su oduvek zagorcavali zivot onima koji
pisu TSR programe. :(( U svakom slucaju, hvala na pomoci.
bios.49adulic,
>> Na zalost, sasvim si u pravu :(( Izgleda da za moj problem nema resenja.
A zašto ne probaš ovo : ako ne znaš (tj. ako program ne 'zna') da li
je kurzor uključen ili isključen, prvo ga na trenutak uključi, pa isključi.
Tada ćeš znati da je sigurno isključen, tj. u nevidljivom delu ekrana.
I obrnuto.
U svakom slučaju, stanje kurzora će biti onako kako ti odrediš da bude
posle probe.
AD
bios.50ivan.s,
>> U svakom slucaju, stanje kurzora ce biti onako kako ti odredis da bude
>> posle probe.
Evo sta moj program radi (izmedju ostalog) : iskljuci hardverski
kurzor, i preuzevsi int 10, sam na mestu kurzora ispisuje nesto
drugo (ja ne volim da mi kurzor trepce; moj program ustvari samo
promeni atribut karaktera na mestu kurzora u inverse ako je bio
normal i obrnuto - tako izgleda da je kurzor pun blok koji ne
trepce - kao u Norton Editoru).
Zato je vrlo bitno da moj program zna kada je kurzor iskljucen i
da ga onda ne iscrtava.