What ISRs need to be implemented before continuing past the step of setting up an IDT?

You can do a lot of work before having to enable any IRQ and implementing their routines, for e.g. paging and memory management.

But if you want to start from there, I'd say keyboard and PIT are good choices.

I would think the minimum amount of ISRs would be the same as the minimum IDTs witch is 48 edfed posted IDT+ISR example in my question on the IDTs

http://board.flatassembler.net/topic.php?p=109628#109628

That post has a demo IDT + ISR... hope this helps?

EDIT:
The first 32 are CPU expectations, eg:
If the CPU finds an invalid opcode it sends an interrupt to IDT 6 that that calls your ISR
and you handle what you want it to do

And the other 16 are for the PIC controller eg:
If you press a key it sends a signle to IDT that signal to IDT 33 and calls your ISR and you
handle what it does with it.

The last 16 are called also called IRQ, the keyboard is placed at IRQ 1 (starting at 0)

[Tyler shudders] I know. I haven't even made a physical memory manager, more less enabled paging. I need to start a thread on paging, surprise surprise, I don't get paging either. Doesn't make sense. How, using specific names of structures, do you find the physical address pointed to in a page directory and table?

19 , 32 are reserved, only 19 are used, one of them, int 9, is considered obsolete by Intel and has been re-reserved by them.

Correct, I was simply meaning that you have to put 32 expectation slots, because they still are expectations even if they are not yet used...

IRQs are working, I've remapped and unmasked, what am I missing?

Proper ISRs, so that it doesn't go kaboom when an IRQ is fired.

And keep all your IRQs masked for now, and only unmask those you actually want to enable (and have an ISR for).

ManOfSteel,

Does iret qualify for proper ISR? Without EOI it even chokes PIC (if ICW1.AEOI isn't set) on first IRQ0 so it doesn't bother again.

Exceptions, OTOH, are different beasts. Handlers for several of them need to get rid of error code before iret. Alas, this wouldn't help if something really bad (from #DE to #MC) happens — most faults/aborts are too persistent to be handled as simple as that.

Send the proper EOI (slave/master) and then do an iret(d).

Since I'm short on time I can't verify, but you may want to stop software interrupts (cli) when entering the ISR and enable (sti) them when you're done.
You should also save/restore clobbered registers.

ManOfSteel,

I know about PIC programming enough, thanks.

My comment was about "proper ISRs" and "kaboom": unwanted interrupts are pretty easy to handle/ignore, exceptions aren't. And you can't mask them neither via cli (it doesn't mask even software-generated interrupts, i.e. int n), nor PIC/APIC.

Most of exceptions are faults, so simple handler like iret will restart the very same instruction that causes exception generation, in the identical context, thus generating it again.

baldr, as I said I was very busy that day. I didn't even realize I was replying to you. I thought it was Tyler asking about ISRs, EOI, etc. so I didn't understand the meaning of your post in the right context.
My answer was very simple: I was talking about IRQ ISRs only and I never mentioned exceptions! And of course you are totally right about removing the error code for some exceptions. You can also have a common routine that handles all the exceptions, and you can push a "virtual" error code for those exceptions that don't have one and clean 2 dwords when leaving the common routine.

Oops. I was wondering why no one was telling me why IRQs aren't working. I just now realized that I said the IRQs are working. They're not.

About handling IRQs and Exceptions, does iret restore the old esp, or do I have to remove the error code? And my other question, do IRQs pass error codes?

What do you mean, "old esp"? If your handler catches interrupt during less-privileged code execution, then yes, iret restores esp.

Error code is specific to exception.