Mike's PCjr Page

But anyway, you may be right about the modem slot. I was just thinking it might be convenient if the UART was already in the XT-IDE V2 schematic.

I could be wrong - I heard about an earlier version of the BIOS code that used an existing serial port, including special high speed cards that might be on various systems. If it is on the board I'd be worried about conflicting with other serial ports installed in the machine.

Either way, it's still useless on a PCjr. The BIOS expects an 8250 and the machine is too slow to drive anything above 2400 or 4800 bps. (Hitting the keyboard would cause you to drop bytes.) Addressing for COM1 is setup for the modem slot. COM2 is on the motherboard. I have the schematics for a homebrew kit for a COM port in the modem slot - I'll dig it up.

Alright, here's a quick schematic capture I did in KiCAD, set up for the PCjr, with 512k SRAM, and converted to PDF.

Please let me know if you spot any errors. It looks alright to me, but I know I tend to overlook my own mistakes from time to time.

Alright! I managed to get a sidecar board template together with the proper measurements (drill size, hole spacing, etc), or at least as close as I can get them. I've verified this by printing it out on my laser printer, cutting it to size, cutting out the holes, and fitting it in a sidecar shell (while stuck to the back of an existing sidecar board). I might be off by a fraction of a mm or so, but since it fits without distorting the paper, I think it's OK.

gorgeous.
I wish i were a hardware guy so i could appreciate this more.

Couple things:
1) I think we can dump conn_4. It's a standard molex 12v power connector for attaching 3.5" drives-mostly for PC folks. No room or juice for 3.5" drives in this design.
2) the eeprom socket is for a 32k eeprom, but can go down to the stock 8k eeprom used on xtide with a couple jumpers. If there really is room for us to consume 32k of space, I'm all for it. There's all kinds of fun stuff we can do in that ROM space, but it truly is overkill. I haven't looked at a memory map on the jr for a long time to know if we can or should suck up that much space. We can simplify the design some by locking it down to a specific eeprom size, but i don't know what is appropriate.
The cost difference between an 8k eeprom and a 32k is only about a buck or so, so that point is moot.
3) do we need any LEDs for an internal device? I guess a header for routing an LED external somehow could be interesting.
4) this design has jumper blocks for selecting up to 16 different IO and memory addresses. May be overkill to allow that many config options. This somewhat goes back to #2 above. If we can narrow the whole thing down to maybe 4 different spots to decode at, we can simplify things a little bit.
5) how many more jumper headers can we remove? There's options for IRQ 1,2,7. Since we're pretty much a closed box, can we narrow that down even further? Can we get rid of the k5 and k6 connectors? these route the "chuck mod" in and out of the design (I haven't honestly followed this mod through to know exactly what it does) but again, since we're a closed box and we know we want the mod, i wonder if we can't just lock this stuff down and eliminate a couple more jumpers and headers.

Alright, getting rid of k5, k6, the LED, and the Molex connector was easy work. I think we need to come to some kind of consensus as to which base addresses and IRQ to use if we lock those down, though.

What do you think about locking it to IRQ 1? That's a PCjr exclusive, so I'm pretty sure nothing else will be using it.

I'd like to hear Mike's suggestion on this and the base address.

Well, to kick things off, I'm suggesting an IDE base address of 320h. From what I've read online, that was a common base address for XT disk controllers, and also it's less likely to interfere with the common default of 300h for network cards (in case someone's using an ISA adapter).

If there's a problem with that, let me know. I'm still looking into the EEPROM base address situation.

Alright, I think the address D0000 should be OK for the EEPROM, the PCjr tech ref says that's 'reserved for future cartridges'. I went ahead and locked it down to the 8k EEPROM on my design. You could actually put a 32k EEPROM on the board in place of the 8k if you needed to, but only 8k would be available.

I am gonna say lets plan on putting the 32k ROM on the thing, and have it all available. Rather have too much space than too little, plus I think it leaves things a bit more open for software improvements.

Also, does your design have enough space to add a RTC option?

I don't think we should be touching any cartridge space. I'm not even sure cartridge space addresses make it out to the expansion bus - if I were IBM I wouldn't have done that. Check the wiring diagrams to see if it is even possible. Another small glitch - cartridges don't use the standard BIOS checksum - you need to use the CRC algorithm in the tech ref.

I'm not happy about 32K compared to 8KB. Seems kind of piggish. We basically have the space from C000:0000 to C000:FFFF for all of the possible ROM BIOS extensions. Burning 32KB for something where we know 8KB works is bad. It makes it harder to add other devices if we do that.

If we do the 'Chuck mod', I don't want to mimic what he did exactly because that messes up the addressing on the whole card, not just the register space. We should just be aiming to ensure the 16 bit data latch to the drive is in consecutive I/O addr space, and in the right order. Memory mapped would be 20% faster, but I/O ports are fast enough.

The current code doesn't use IRQs at all. And I doubt we'll ever need an IRQ.

I/O port numbers need to be flexible ..