Finally, the int 8 h is passed.

Abstract:
Bytes ---------------------------------------------------------------------------------------
 

Recently, we have been tossing int8h, and we have already registered the endpoint address of the interrupt handler at. explicitly calling int8h can be transferred to the interrupt handler, but it cannot be automatically interrupted.
  Later, I found the answer in the book of my predecessors. "Speaking of EOI, if you have programming experience in real mode, you should be familiar with it. When the processing of each interruption ends, you need to send an EOI to 8259A to continue to accept the interruption ".
  So I added two lines of code in the program:
  Mov al, 20 h
  Out 20 h, al
  The compilation test showed that 18.2 interruptions were run every second.
  Bytes ---------------------------------------------------------------------------------------

Lecture
The following is the error code:
-------------------------------------------------
% Include "echoinit. mac"
% Include "./echon. mac"; these two header files are multi-line macros I have written. They are used to implement functions similar to C-language printf and have been specially tested. No problem
Org 0x7c00
Enter: jmp start
Handler: echon 'Hello oranges world'
The iret; handler tag is the int 8 h interrupt handler, and the expected effect is to repeatedly print 'Hello orangesworld' from top to bottom'
     But nothing actually works.
Start: echoinit; this macro is initiated by the echon macro and is defined by myself.
Setup:
Mov ax, 0; register the interrupt handler entry address at the 8*4 Memory Address
Mov ds, ax
Mov bx, 32
Mov word [bx], handler-$
Mov word [bx + 2], 07c0h
; Int 8 h; if this line is not commented, the figure 1 will appear. ---> This indicates that the processing program interrupted during 8 h is successfully installed.
Jmp $
Times 510-($-enter) db 0
Dw 0aa55h
-------------------------------------------------

Figure 1 ()

 The expected result is that 'Hello orangesworld' is repeatedly printed from top to bottom. It is clear that the cpu does not respond to the 8253A channel 0, which is constantly interrupted by the 8th.
 The first thought (I found it on the internet) was to forget to add sti, which caused global interruption shielding. So I added an sti to open the interrupt, compile the test, and display the screen:

Figure 2 ()
 Is it exactly the same as Figure 1? But don't forget: Figure 1 is the result obtained by manually calling int8h. The code corresponding to Figure 2 has commented out the int 8h and added an sti. This shows that sti has produced results. It does make the cpu respond to int8h interruption! But the effect is not good: the cpu is turned off after only one response.
 I thought about it: it is probably a problem with the bochs Virtual Machine. To achieve single-step debugging, it may constantly use cli commands to block interruptions. So I tested it with bochs without debugging, and the same picture is still displayed.
 I don't have to worry about it. I thought there may be problems with bochs without debugging functions. So I installed freedos on bochs and wrote another program (because my echon macro cannot be used in com files ), compile it into the boot.com file for testing. The following code is used:
Bytes ---------------------------------------------------------------------------------------
Entrance: jmp setup
Handler:
   Movax, 0xb800
   Moves, ax
   Mov byte [es: di], dl
   Adddi, 2                      Es: the memory address that di points to the next character on the screen.
   Inc dl     ; Dl auto-increment 1, which produces the effect of a, B, c, d, e...
   Iret
Setup:Mov dl, 'B'
   Movdi, 0                     Initialize es: di points to the memory address corresponding to the first character on the screen
   Movbx, 32                  The interrupt table for 8 hours is at 0000 h: 0020h.
   Movax, 0
   Movds, ax
   MovWord [ds: bx], handler-entrance + 100 h; register the entry address of the interrupt handler to the interrupt vector table
   Movax, cs
   Movword[Ds: bx + 2], ax
   Sti
Jmp $
Bytes ---------------------------------------------------------------------------------------
 The result of the Code is: a, B, c, d, e .....
 Compile nasm-o boot.com boot. asm
 Dos test:

Sorry! Only when the first letter is changed to B, the screen will be motionless! Obviously, the cpu is switched off after only one 8-hour interruption.

 This series of failures led me to re-doubt the problem on my own code, so I roughly looked at the 8259A Interrupt Controller principle: IR0 connected to the 8253A 0 channel clock interruption, the highest priority, when the bios is turned on, the disconnection code of IR0 is set to 8 hours .... the eight digits of IMR correspond to IR0 ~ IR7 switch...
 Is the corresponding bit of IMR blocking the int 8 h, because the IMR port is 21 h, I added an inal, 21 h in the Code, after compilation bochs debugging, after this command is executed, the info cpu displays: al = b8, that is, the IMR value is 10111000.The value 0 corresponding to IR0 indicates that int8h interruption is not blocked! Ah, I was so desperate at the time. I don't want to learn the microcomputer principle 8259A from the ground up!
 At this time, I turned to the books of my predecessors and learned that there is also EOI in the world...
 Lucky...
 After the program runs normally:
 

It is the program under dos. It starts with B, c, d, e .... the garbled characters below can be understood: after al exceeds 256, it is no longer an ascii valid value (in fact, it is a dynamic printing process, but it is too troublesome to make gif files)

It's the program under bochs. I wrote an h before it, but where do I care! After waiting for such a long period of time, the screen suddenly jumped to the front and grabbed it.
 Now let's look back at the previous weird phenomenon: the cpu shuts down after an eight-hour interruption. The reason is nothing more than sending an EOI to 8259A at the end of the interrupt processing program, so it cannot continue to accept the interruption... so it is a dumb fire. This EOI has nothing to do with the INTA signal of the cpu, I used to just use int8h in another program, and the result was a huge discount)
An Introduction to the 8259A encountered a video, is the computer principle of JI da, can also talk about: http://www.xuexun.com/C_23660.shtml