Portected mode BIOS 1

[straiph]

Does anyone know how to utilise the BIOS from protected mode.

I have remapped the PICs to interrupt 20h onwards.

I have written a handler which drops to real mode and calls the real mode interrupts and then back.

It works a treat but when I access the drive interrupt (old 13h - new 33h) the drive motor doesnt stop.

The interrupts still work but it looks like i am loosing some functionality on IRQ0 which is used to stop the drive motor.

Can anyone explain why this is and what I need to do to resolve this.

Failing that can anyone provide me with information about replacing the BIOS with 32bit code?

Straiph.
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[straiph]

I have the BIOS32 specification including how to find and use the BIOS32 service directory but I cant find a list of component IDs.

If I cant identifiy the service routine then it is useless to me!

Straiph.
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[straiph]

I have just scanned all my PCs for a bios32 signature in the range of 0E0000h to 0FFFF0h and have not found any.

Does anyone have pseudocode for how DPMI handles real mode interrupt calls from protected mode.

I am really scratching my head - my interrupt handler works fine sometimes for upto a minute.

all the bios calls i make produce expected results.
the irq calls also work fine.

then its just like the PIC stops!

once the keyboard locks up the software interrupts still work fine, the current task is still executing and no exceptions occur.

Has anyone got any ideas?
Straiph
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[AmkG]

I would recommend you write your own IRQ0 handler. It could be that the mode switch is taking too long for the IRQ0 handler and the PIC starts getting confused when it's getting backlogs on IRQ0... I'm not sure if this would solve your problem though. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

Yes, I was thinking that maybe while interrupt handler is busy another irq service flags and is ignored but then once the current service has finished the flagged service does not execute and appears to hang.

I will add a little routine at the end of the interrupt handler to ensure all other flagged irqs are serviced before completion.

But I must admit that disassembling the bios and rewriting the irq handlers into 32bit code sounds alot more efficient.

Thanks
Straiph. 0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[AmkG]

Having a slow IRQ0 WAS an issue on old 80286 and 80386 systems... which is why I thought it wouldn't really solve your problem, because you are not likely to be using an old 80286 or 80386.

I actually started writing a PM IRQ0 and IRQ1 a year or two ago, but the HDD it was on got trashed.... "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

hmm... interesting.

this my be the case as its only a Pentium 200hz. the routine that drops into real mode, calls the interrupt and back to protected mode is pretty lengthy due to the fact i am having to preserve all of the registers, segments and stack etc twice and without using the stack during the mode change, i couldnt do it without self modifying code.

i need to find out the status of the irqs at the end of the interrupt handler. i think we are pretty close to the problem!

disassembling the bios has been on my agenda for sometime now and this seems like a pretty good excuse in anycase writing 32bit irq services must be more efficient.

thanks
straiph
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[AmkG]

I happen to have a copy of a 286XT's BIOS Source... it's pretty informative on what IRQ0 and IRQ1 must do, and how it's been done in BIOS, but it's hard copy and I'm too lazy to type it in. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

I might copy my BIOS to a binary file then disassemble.

And now I have a good excuse to have a crack at writing my own assembler/disassebler!

Do you know where I can find a good flowchart type diagram for encoding and decoding?

I am now staring at about half a dozen coding tables and wondering how to takle the permutations!

0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[AmkG]

Err... disassembly or assembly? I'd think they'd be different... "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

Well, for encoding & decoding I was thinking to develop reference databases that are indexed in both directions.

Then I could encode or decode at will. 0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[Guest_imported]

Try plugging the computer in.

 

[straiph]

Is that a wise decision?

Last time someone plugged something in it took out the control circuit for the cooling system.

This caused the coils to freeze and the coolant pipes burst. With Glycol pouring out everywhere the computers shutdown due to overheating.

After repairing the coolant pipes and draining 3 inch deep of Glycol it took 8 hours to reboot the computer system back to a satisfactory level of operation.

Now with that kind of head f**k to deal with one walks round the computer with hands in pockets and especially avoiding plugging in un-plugged plugs! LOL
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[AmkG]

I don't know if he's insulting you, has difficulty comprehending what's being talked about, or posted the wrong thing in the wrong thread. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[AmkG]

You know what, I suspect Tek-tips is breaking down and putting posts where they shouldn't be going. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

I solved the IRQ issue!

Problem:
If any IRQ requests service while the interrupt line is disabled the PIC sets the disabled bit for that irq! (maybe on second attempt i'm not sure)

Solution:
Once the interrupt handler has completed its current task it then checks the disabled bit for each irq from 015h to 0h. If it finds a disabled irq it clears the disabled bit and calls the interrupt for that irq (which means the interrupt handler will call itself), the interrupt handler only returns to the original program once all irqs are enabled! it seems to work fine although i have to avoid pressing the break key! LOL
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[straiph]

I have resolved the break key issue by setting the PICs to the real mode interrupts while in real mode! (silly me)
0000:0000:0000:0000h
The people who have nothing to say and say it too loud have little knowledge, It's the quiet ones you need to worry about!

 

[John4]

Hi

I am trying to write a bimodal interrupt handler but I
cannot find any sample code.

Where can I find some sample code ?

A bimodal interrupt handler is actually two handlers,
one for the real mode and one for the protected mode.

thanks
John

 

[straiph]

its quite simple really in theory LOL but a dunting feat.

How much do you know about real mode/protected mode IDT & IVT fundamentals?

the IVT is the real mode 'I'nterrupt 'V'ector 'T'able
the IDT is the protected mode 'I'nterrupt 'D'escriptor 'T'able

first I would write the test handler in 16bit real mode. write the insertion point to the IVT and in real mode involk the interrupt. to get it working

once this is done you can create a 16bit code segment in the GDT (Global Descriptor Table) and put a call gate in the IDT to this descriptor. this will execute the same code and will work fine if you are just accessing the ports. the current stack will be used. you cant set any real mode segment selectors as this will cause unrealiable results.

If you have to change the segment selectors then the handler has to check if you are in real mode or protected mode (bit 0 of CR0). push all selectors onto stack. alter all the segment selectors to suit and perform task. pop old selectors of stack. iret

you must also push the general registers that you use before the task then restore before iret.

if you are using BIOS routines you have to drop to 16bit code, actual real mode, perform a far jump to a real mode code segment, create a real mode stack and set all selectors to real mode. perform interrupt then reverse all previous.

I have acheived this using a 16bit code 32bit task but not acheived this using 32bit code 32bit task. only difference was a jump to a 16bit code segment but when in real mode the stack pointer on 'push ax' got corrupted unless it is page alined.

As for examples, I dont know of any. I learned the hard way and have spent alot of effort acheiving my 32bit code 32bit task real mode calls module which also includes BIOS interrupt calls. Without any recognition I'm not just about to hand over the source code to anyone but I am more than happy to give you explanations of how its done.

Any questions?
"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"