XT-IDE on PCjr

[Brutman]

On a PCjr 0x208 to 0x2F7 are open and 0x300 to 0x3CF are open. The only thing in the middle of any of that vast address range is the serial port.

On a PCjr any address between C000:0000 and C000:FFFF is available for BIOS ROM expansion. Although the Tech ref says the address space from D000:0000 to E000:FFFF is reserved for cartridges, I know that these addresses appear on the bus because my Western Digital 8003 Ethernet card maps itself in at D000:0000 for 8KB. (I need to verify this in the schematics too, just to be safe.)

Given that we have a wide array of I/O space and ROM space to choose from we should not be restricting ourselves to three switches through the existing hole of a particular sidecar. Three switches are not enough and people might be using a different sidecar shell that does not even have the hole.

We should be providing the same 16 selections that the XT-IDE provides, with the selection that overlays the onboard serial port considered to be a known user error. For an 8KB ROM we should be allowing the user to choose any 8K window in the range of C000:0000 to C000:FFFF and D000:0000 to D000:FFFF.

Swapping A0 and A3 should *only* be done on the data latches from the drive to make them appear linear in I/O port address space. I really don't want to see the "Chuck" mod duplicated entirely - as implemented on the existing XT-IDE it also swaps addressing for the ROM extension, meaning that you have to munge the binary for the EPROM before you download it. That's ugly and it's just going to lead to problems.

And I know I pointed this out before, but we really need 512 bytes or 1KB of RAM on the card too to avoid memory map conflicts with the BASIC interpreter and other reserved areas. We can either force that RAM into the existing 8KB address space that we are thinking of or extend the address space to something like 10KB, which still allows smaller ROM extensions to sneak into the unused space.

Sorry guys, but we need to make sure these high level problems are addressed first before drawing schematics.

[jmetal88]

Swapping A0 and A3 should *only* be done on the data latches from the drive to make them appear linear in I/O port address space. I really don't want to see the "Chuck" mod duplicated entirely - as implemented on the existing XT-IDE it also swaps addressing for the ROM extension, meaning that you have to munge the binary for the EPROM before you download it. That's ugly and it's just going to lead to problems.

The ROM extension is completely separate from where the lines are swapped on my schematic. Just look, you'll see it.

[jmetal88]

Sorry guys, but we need to make sure these high level problems are addressed first before drawing schematics.

That part doesn't make sense to me. Why not address them while drawing the schematic? It's not that hard to rework things in KiCad.

[jmetal88]

We should be providing the same 16 selections that the XT-IDE provides, with the selection that overlays the onboard serial port considered to be a known user error. For an 8KB ROM we should be allowing the user to choose any 8K window in the range of C000:0000 to C000:FFFF and D000:0000 to D000:FFFF.

I guess I don't understand the purpose of making the card that flexible, but if you really think it'll help, I'll put all the selections back in.

Do you want to use DIP switches like the original XT-IDE called for, or jumpers like the XT-IDE version 2 schematic has?

EDIT: Well, if you really want every single 8k block in that range available, I guess DIP switches would make it a lot easier on the end users.

[Brutman]

The ROM extension is completely separate from where the lines are swapped on my schematic. Just look, you'll see it.

Well, let's back up a step further. Given that we just need two consecutive I/O ports can we make the logic even simpler? All that the BIOS cares about is that the ports are linear in address space; the particular starting port address does not matter. We are seeking BIOS level compatibility, not register level compatibility.

So taking that into account, can the design be made simpler? That's a rhetorical question - I'm not sure that it can. The point is that we don't have to just copy the bit swapping in the original mod. Once we understand why the modification was done (which we do) then we can design a better solution.

And that's what I mean by having the high level design questions worked out first before worry about things like layout. (Although yes, the layout will influence some of the design.) The presumption that we were using a specific sidecar was premature and makes the important parts of the card more constrained than they should be even for people who don't have that particular sidecar shell. The extra memory is another item we should be researching; it might be overkill, and I don't think that anything is a done deal yet.

As for the card flexibility - we need to keep as much flexibility as possible. There is nothing more maddening than not being able to fit things into the machine because of mapping conflicts.

[jmetal88]

Oh, yeah, the layout, I agree doesn't need to be done yet. I just did one because someone asked. It's just you said schematic instead of layout in your post and that didn't make much sense to me.

EDIT: And I wasn't assuming everyone would have the same sidecar, I just thought a layout like that would make it easier for those of us that do have the Booster.

[jmetal88]

Anyway, here's one with all your available addresses, using 8 DIP switches. I've attempted to leave it with one resistor pack as well, but I don't know if that will cause issues, for example, with some pins being pulled permanently high by being connected directly to VCC.

I don't know what I would need to do to simplify the consecutive addressing, I'd need some help with that. As you know, I'm pretty inexperienced (considering my RAM upgrade was the first bit of hardware I ever designed).

As for adding the RAM, are you sure we need to? As Hargle said, the Atmel EEPROMs are byte writeable without erasing the whole thing, and there's room in the current EEPROM for the tables. Of course, if you're genuinely worried about using up the write cycles (although I think that chance is slim) or if you think we'll really have enough extensions to use up that 8k, we can still add it.

[alanh]

You shouldn't run inputs directly to Vcc. The resistors are there to limit current to under what the part can sink. You'll need another network with the addition of the dip switches.

[jmetal88]

You shouldn't run inputs directly to Vcc. The resistors are there to limit current to under what the part can sink. You'll need another network with the addition of the dip switches.

OK, thanks for clarifying that for me! I thought I remembered hearing something like that before, but I wasn't sure.

[jmetal88]

Alright, here's my most recent mistake fixed.