Mike's PCjr Page

Did anyone back in the day make an external DMA controller attachment? From the tech reference, it appears that the FDC and the sidecar connector were designed to allow for this provision.

Some of the Racore/Rapport expansion units had DMA and a replacement floppy controller. I've never seen it as a stand-alone sidecar or option though.

It's really not needed except that it might make some disk I/O during UART activity possible. We still have the problem of the keyboard using NMI instead of IRQ 1. It would make for faster hard disk access compared to programmed I/O, but I think the memory trick that our IDE controller is as fast as it is going to get and DMA would not help it.

In theory, an expansion that adds a DMA controller could allow DMA 1, 2 & 3 to be used by another device on that expansion or attached via its own bus. If it were used in conjunction with IBM's diskette drive controller, the diskette drive controler would use DMA 0.

IBM's pinching a few pennies on a deserialization circuit for the keyboard really hit home in other areas.

By the way, in the section on the main site, it says "The NMI interrupt has the highest priority as it is directly connected to the 8088 CPU. This interrupt can not be deferred or ignored, so keyboard processing will preempt all other activity on the system including other interrupts. Even when interrupts are disabled using the CLI command an NMI interrupt can still occur." However, Port A0 can mask/disable NMI interrupts on the PC or PCjr, and must do so for diskette data transfers. I think it would be better to say "The NMI interrupt has a higher priority than any of the numbered interrupts to the 8088 CPU. Keyboard processing will preempt all other activity on the system including other interrupts except the diskette drive, which the BIOS will give higher priority by disabling NMI during diskette data transfers."

The very next line in the paragraph is:

(There is a way to disable the keyboard entirely so that it does not generate any interrupts.)

That makes it clear that although the NMI interrupt has the highest priority, it can be supressed by effectively disconnecting the input to it.

Is there a reason why you chose to quote most of the paragraph, and not the next line? With the full paragraph the only improvement you would be making is to explicitly point out the address of the port that is used to enable/disable inputs to the NMI line.

That sentence is odd, since what the system is doing is disabling the interrupt. The keyboard still functions and still generates the NMI, but it does not reach the CPU while NMIs are masked by port A0. The keyboard latched bit at port 62h can tell the system that there was a missed key while NMIs were ignored and the error beep will sound. It may be nitpicky, but its more accurate to the Technical Reference.

That is ok, I found your quoting of everything except the last sentence (which was relevant to the criticism) odd ... The system is not "disabling the interrupt." It is more like "rewiring" to misroute what should have been an interrupt.

Your comment is noted but it is not my intention to rewrite the Technical Reference manual - I provide a higher level description of how the mechanism works. There is enough there for an interested read to say "ok, time to dig deeper".

Brutman wrote:Some of the Racore/Rapport expansion units had DMA and a replacement floppy controller. I've never seen it as a stand-alone sidecar or option though.

It's really not needed except that it might make some disk I/O during UART activity possible. We still have the problem of the keyboard using NMI instead of IRQ 1. It would make for faster hard disk access compared to programmed I/O, but I think the memory trick that our IDE controller is as fast as it is going to get and DMA would not help it.

Agreed. I think a proper keyboard controller that talks IR to a normal IRQ would be a nice addition to the jr. I've been toying with that idea for a project.