• Please review our updated Terms and Rules here

PCjr owners: ISA bus adapter

Thanks guys ...

I forgot to mention - if anybody sees anything questionable, drop me a message. The last thing I want to do is hose somebody unintentionally ... ;-)
 
mbbrutman said:
I finally got around to reverse engineering and understanding my PCjr bus to ISA bus adapter. The details are here:


People with other machines looking to build an expansion chassis for ISA cards - you may be interested in reading this.
Click to expand...

I will repeat to say good work too...

One question on the webpage is if the NIC has a TP connection why the AUI transceiver is being used...

I've got pinouts for the PC Convertible bus, so that could also be another target system too...
 
Thank you again ...

I would love to have a Convertible tech ref - just missed one on eBay.

As for that specific Ethernet card - it is a Western Digital 8003 variant. It has a twisted pair connector, but it was put on there before the twisted pair standard was finalized and it is not compatible with my more modern hubs. Hence the TP transceiver on the AUI connector.
 
I wonder whether this would work with a CGA card. The CGA does not use any pins that are not available on the PCjr. bus except for OSC and I/O Channel Check. The former can be attached to a crystal. But would it work or would it conflict with the video circuity on the system board?
 
It won't work. Memory references from B800 to C000 are redirected to the system meory. So are the I/O port references.

It makes more sense to add EGA or VGA to a Jr, not CGA. The built-in CGA is better than standard CGA.
 
The problem is not that PCjr. video is better than CGA video, which it is, but that most games around that time period and before use CGA video, which operates in a different way. I/O addresses 03D8h and 03D9h, which the CGA card uses, do not really exist on the PCjr. Only 03DAh is shared, and when read on either the CGA or the PCjr., should return the same information.

Can this memory trap be changed? Ideally a PCjr. should have 640KB of conventional memory and 128KB of video memory. (736KB total). The 640KB of main memory should be contigious from pages 0000 to A000, and the 128KB of video memory should use all of pages A000 and B000. This would also have a huge advantage in that memory operations would take four clock cycles instead of six if the CPU and the video weren't sharing the same banks of RAM. If that could be done, a great deal of incompatibility and speed differences between the two machines could be eliminated.

Since I'm on the subject of undesirable PCjr. behavior, the next thing that should also be eliminated is the "masking" of interruptable inputs (keyboard & serial) that occur during a data transfer from the floppy drive. This is done because the PCjr. does not have a DMA controller, but one can be added via a sidecar (this is sometimes included in second drive additions.) If you add a DMA controller, the masking no longer serves any purpose.
 
Last edited:
If the game designers had coding using the BIOS, this would not be a problem.

Now, poking directly into memory is not strictly using the BIOS, but it works because of the circuitry and can generally be expected to work on any CGA clone. But doing stupid things like plinking the 6845 directly for a simple mode change when the BIOS call is just as fast breaks some software. There were patches for lots of broken software that did that.

Onto the broader philosophy question. The PCjr is what it is. The Tandy guys did it right by moving the video memory window to the *TOP* of memory, where the assumption is that the top is more like 640K, not 128K. That way you get contiguous memory for DOS without the hassle of a device driver.

If you want a machine like that though, why not just get a Tandy or a PC? Without the charming cartridge slots and wireless keyboard of course. By the time you hack a Jr to replace the video subsystem, it's not really a Jr anymore, is it? That was part of my distaste for the VGA sidecar. A Jr with the onboard video neutered and replaced with VGA is just another clone at that point.

The DMA controller is a whole other problem. Adding the DMA controller only helps the floppy drive, nothing else. If won't let you add sound card, hard disk adapter, or any other peripheral that requires DMA. The bus only accommodates one DMA channel, and it's reserved for use with the floppy. And it's wired that way too.

So even when doing serial communications, typing or screen scrolling can cause you to lose characters on the 8250 UART, regardless of DMA or not.

Putting the keyboard on the NMI interrupt instead of IRQ 1 was just dumb ... Polling for the floppy drive is forgivable, as most OSes couldn't make good use of DMA back then anyway. But the keyboard interface to the CPU using NMI was just one shortcut too many.
 
You must log in or register to reply here.
Back
Top