🚀 go-pugleaf

In article <1992Aug6.154949.164290@dstos3.dsto.gov.au> egg@dstos3.dsto.gov.au writes:
>
>>No Josh, your wrong.  Some VGA board create a vertical retrace interrupt
>>whenever they enter the retrace period.  A program would merely have to
>>trap the interrupt to know when the retrace period is happening.  The
>>program could carry on doing its own thing until it gets the interrupt,
>>then it can update the screen.  No polling required.
>>I don't think the timer interrupt trick would work, even though the
>>interrupt could be generated 60Hz (or 70Hz), it still would not inform
>>the program that it is a safe time to write to the VGA.
>>
>>I have tried the retrace interrupt a little, without any real success,
>>an I would also like to know how to enable the retrace interrupt, and
>>how to signal to the VGA that the interrupt had been recieved.
>
>I beleive its not a good idea to use the vertical retrace interrupt because
> according to "Programmers Guide to PC and PS2 video systems" hardware
>interrupts on IRQ2 cannot be distinguished from Vertical interrupts. I'm not
>that cluey on the subject but if its in the book ??? Apparently bus versoins
>of the Microsoft mouse cause this problem, and possibly other hardware that
>use IRQ2. If you are still keen on using it, The book shows you how.
>
>Themie

I used to do quite a bit of low-level programming on the C64 and I remember
back then, we had only one IRQ line.  But we used this one interrupt
to do everything from I/O timing to raster synchronization.  Having only
one IRQ line meant that we had to daisy chain all our service routines,
and each would have to check various registers to see if the IRQ was
indeed for it.  If not, it would pass control down to the next interrupt
handler in the line, and so on.  So, I'm wondering (as I haven't been
programming IBM clones for very long) whether the same can't be done for
MS-DOS machines.  It should be a trivial task.

Phat.

In article <1992Aug6.154949.164290@dstos3.dsto.gov.au> egg@dstos3.dsto.gov.au writes:
>
>>No Josh, your wrong.  Some VGA board create a vertical retrace interrupt
>>whenever they enter the retrace period.  A program would merely have to
>>trap the interrupt to know when the retrace period is happening.
>
>I beleive its not a good idea to use the vertical retrace interrupt because
> according to "Programmers Guide to PC and PS2 video systems" hardware
>interrupts on IRQ2 cannot be distinguished from Vertical interrupts. I'm not
>that cluey on the subject but if its in the book ???

Shouldn't you be able to distinguish interrupts based on the status of
the CRT controller register? There's a bit which is set during the
vertical blank, and reset otherwise. It seems to me that the interrupt
service routine could check the value of this bit; if the bit is set, it
would assume that the interrupt was generated by the video card, if
reset it would assume that the IRQ was generated by some other hardware
and chain to the next ISR in the vector chain. Not foolproof, but might
be useful in certain situations where the chances of other hardware
causing the IRQ are small or the other hardware has a positive method
for determining whether or not IT caused the interrupt.

For example, the Microsoft InPort card (a.k.a. the bus mouse card) has
an Interrupt Identification Register which can be checked to determine
if the InPort card (mouse) has caused an interrupt since the last time
it was checked. Other hardware (UARTs, for example) have similar
capabilities.

In article <1992Aug6.154949.164290@dstos3.dsto.gov.au> egg@dstos3.dsto.gov.au writes:
>
>>No Josh, your wrong.  Some VGA board create a vertical retrace interrupt
>>whenever they enter the retrace period.  A program would merely have to
>>trap the interrupt to know when the retrace period is happening.  The
>>program could carry on doing its own thing until it gets the interrupt,
>>then it can update the screen.  No polling required.
>>I don't think the timer interrupt trick would work, even though the
>>interrupt could be generated 60Hz (or 70Hz), it still would not inform
>>the program that it is a safe time to write to the VGA.
>>
>>I have tried the retrace interrupt a little, without any real success,
>>an I would also like to know how to enable the retrace interrupt, and
>>how to signal to the VGA that the interrupt had been recieved.
>
>I beleive its not a good idea to use the vertical retrace interrupt because
> according to "Programmers Guide to PC and PS2 video systems" hardware
>interrupts on IRQ2 cannot be distinguished from Vertical interrupts. I'm not
>that cluey on the subject but if its in the book ??? Apparently bus versoins
>of the Microsoft mouse cause this problem, and possibly other hardware that
>use IRQ2. If you are still keen on using it, The book shows you how.
>
The problem is that for the interrupt controller was changed somewhere when 
the XT became the AT or something like that.  The original set of hardware
interrupts were limited from IRQ0 to IRQ7, however, they found that add in
cards needed more interrupts, so they added a second interrupt controller 
to give people IRQ8 through IRQ15.  However, to stay compatable with the 
original hardware, they daisy chained the new controller onto the old 
controller via IRQ 2.  The net result is that any IRQ above 7 also generates 
an IRQ 2.  

Given that background, if you have a network adapter (or some other hardware)
that uses an IRQ above 7, then you can't be sure that when you receive an IRQ
2 that it's the video card or not.  

Maybe at that point you could poll the adapter to see if it is the video card,
and if not, pass it on to the old handler? 

Thoughts?



Matt Smith
msmith@peruvian.utah.edu
Student - University of Utah Department of Computer Science

>I beleive its not a good idea to use the vertical retrace interrupt because
> according to "Programmers Guide to PC and PS2 video systems" hardware
>interrupts on IRQ2 cannot be distinguished from Vertical interrupts. I'm not
>that cluey on the subject but if its in the book ??? Apparently bus versoins
>of the Microsoft mouse cause this problem, and possibly other hardware that
>use IRQ2. If you are still keen on using it, The book shows you how.
>Themie

I found the book I was muttering about - I had all the details wrong. It is
put out by McGraw Hill, and is titled "EGA/VGA A programmer's Reference Guide."
The author is Kliewer. It *is* filled with typographical errors, so I still
don't suggest anyone buy it. But on pg. 195-199 there is a lot of detail on
writing code to accept and recognise the Vert. Interrupt. Different hardware,
the book warns, does it differently. There are also (ASM) coding examples,
and a wealth of info about EGA and VGA register programming.

I've never done it. To be honest, the book convinced me that I didn't need
to do it. Not with the amount of work required to cover various kinds of
hardware out there. Once enabled, you get interrupts at 0a, and you
have to ask the display board if it caused the interrupt or not. You have
to do special things to clear the interrupt, and the special things seem
to depend on the board.

Good luck. But what is wrong with just painting your images as you generate
them, possibly waiting for the beginning of VR by polling, if you really
need to?
--
He is a slave to a sign who uses or worships a significant thing without
knowing what it signifies.			-Augustine
smayo@wang.com

In article <bskoir.71t@wang.com>, smayo@wang.com (Scott Mayo) writes:
|> 
[ lots deleted ]

|> hardware out there. Once enabled, you get interrupts at 0a, and you
|> have to ask the display board if it caused the interrupt or not. You have
|> to do special things to clear the interrupt, and the special things seem
|> to depend on the board.
|> 
|> Good luck. But what is wrong with just painting your images as you generate
|> them, possibly waiting for the beginning of VR by polling, if you really
|> need to?
|> --

Well for me anyway, I wish to add colour cycling within a multi-
program (sort of multitasking) environment.  Any time wasted 
polling is taken away from the other programs.  Also I was using
polling for page flipping for video mode Y (well similar to Y),
and I tested it out on a 486DX-33 and the polling appeared to work
incorrectly, I got lots of flicker.  But the same program worked
fine on my 386DX-25 and any slower machines I ran it on.  So 
possibly the vertical int will solve the problem.

    SPHINX

====================================================
=== Kill others only if you wish to be killed.   ===
===                                       SPHINX ===   
====================================================

>No Josh, your wrong.  Some VGA board create a vertical retrace interrupt
>whenever they enter the retrace period.  A program would merely have to
>trap the interrupt to know when the retrace period is happening.  The
>program could carry on doing its own thing until it gets the interrupt,
>then it can update the screen.  No polling required.

egg@dstos3.dsto.gov.au writes:
>I beleive its not a good idea to use the vertical retrace interrupt because
> according to "Programmers Guide to PC and PS2 video systems" hardware
>interrupts on IRQ2 cannot be distinguished from Vertical interrupts. I'm not
>that cluey on the subject but if its in the book ??? Apparently bus versoins
>of the Microsoft mouse cause this problem, and possibly other hardware that
>use IRQ2.

This is true of any type of card, no two devices on the ISA bus can
generate the same IRQ.

ptran@watserv1.uwaterloo.ca (Phat H Tran) writes:
>I used to do quite a bit of low-level programming on the C64 and I remember
>back then, we had only one IRQ line.  But we used this one interrupt
>to do everything from I/O timing to raster synchronization.  Having only
>one IRQ line meant that we had to daisy chain all our service routines,
>and each would have to check various registers to see if the IRQ was
>indeed for it.

The problem is electrical, because of the way the ISA bus is designed
you risk serious damage if two devices on the bus share the same interrupt.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //

In article <1992Aug8.100417.7375@zooid.guild.org> Ross Ridge <ross@zooid.guild.org> writes:
>
>This is true of any type of card, no two devices on the ISA bus can
>generate the same IRQ.

Really? Then why can my COM1:, which is on the motherboard, coexist with
my COM3:, which is on a separate modem card? Both generate IRQ4.

>The problem is electrical, because of the way the ISA bus is designed
>you risk serious damage if two devices on the bus share the same interrupt.

What's your source for this?

Ross Ridge <ross@zooid.guild.org> writes:
>This is true of any type of card, no two devices on the ISA bus can
>generate the same IRQ.

tmkk@uiuc.edu (Khan) writes:
>Really? Then why can my COM1:, which is on the motherboard, coexist with
>my COM3:, which is on a separate modem card? Both generate IRQ4.

Because you never use them them at the same time.  If your modem and
on-board serial port generate IRQ4 at the same time they'll short each
other out.

>>The problem is electrical, because of the way the ISA bus is designed
>>you risk serious damage if two devices on the bus share the same interrupt.
>
>What's your source for this?

It's a well known limitation of the IBM PC bus.  

								Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //