Mike's PCjr Page

Brutman wrote: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 ..

Ah, OK. Thanks for explaining about the ROM space! I put both sets of address jumpers back into my schematic. Also, I've still got it hard-wired for an 8k EEPROM. You have a different idea for 16-bit data space, though? I'll try to work out what you're talking about, if I can, but if you have a specific idea for how to modify the design, it'd be easier on me.

The reason why I would lean towards the 32k ROM is that it seemed like the 8k was a bit limiting on the original XT-IDE. Could it be a 16k ROM? Or could it be designed so that one can use a 32k rom and then set a jumper to limit it to 8k, that way each user could decide what works best for them.

Mike, is the main problem with the 'Chuck mod' that it writes the most significant byte followed by the least significant byte? Should it be doing this the other way around? I think I've figured out a way to swap around the outputs of the 74ls138 so that the latches store the least significant bit instead of the most significant bit, but I want to make sure that's actually the way I need to be going with this before I move any further.

Lutiana wrote:The reason why I would lean towards the 32k ROM is that it seemed like the 8k was a bit limiting on the original XT-IDE. Could it be a 16k ROM? Or could it be designed so that one can use a 32k rom and then set a jumper to limit it to 8k, that way each user could decide what works best for them.

"Limiting" is in the eye of the beholder. The current version of my PCjr BIOS (based on Hargle's 0.9 BIOS) is less than 4KB, and the extended INT13 functions required for Win95 are still in there. We definitely won't need those if we get tight on space.

jmetal88 wrote:Mike, is the main problem with the 'Chuck mod' that it writes the most significant byte followed by the least significant byte? Should it be doing this the other way around? I think I've figured out a way to swap around the outputs of the 74ls138 so that the latches store the least significant bit instead of the most significant bit, but I want to make sure that's actually the way I need to be going with this before I move any further.

I explained this earlier. The original design has the 16 bits of latch broken up on two different I/O ports that are not sequential in address space. We could get better performance if the latch was addressed by two I/O ports that had sequential addresses. That enables a 16 bit IN or OUT which is much faster than what is going on now.

The original modification posted by Chuck(G) at VCF swaps two address lines for the entire card. So it corrects the I/O port addressing problem, but it messes up the addressing of the ROM on the chip. I don't want to recreate that on this board.

The original modification posted by Chuck(G) at VCF swaps two address lines for the entire card. So it corrects the I/O port addressing problem, but it messes up the addressing of the ROM on the chip. I don't want to recreate that on this board.

And this is supposedly taken care of in the new schematics that I've posted, or at least that's one of the targets of those new schematics. (I'm hammering out xtide mkII details via email while discussing XTIDEjr here, so it's good we can get some cross-feedback)

We basically have the space from C000:0000 to C000:FFFF

Perfect, that is exactly the information I was looking for. ok, 32k is kinda piggish! consuming 1/2 of all the available ROM space, especially when we don't really need it, is a bit much. We're going with a 32k eeprom on the XTIDE mkII, but we have significantly more ROM space on a PC/XT. I'm fine with 8k, 16k would be lovely though, considering there aren't THAT many more devices that you can attach to a jr that also consume ROM space. The price difference is moot.

I/O port numbers need to be flexible ..

ok, let's simplify it down to 4 addresses for IO and 4 for memory location?

I think we can also remove the jumper for eeprom enable/disable. The card won't work without the eeprom. Well, it would work as a memory expansion, but why bother with just 1/2 of the capabilities?
The only reason we'd need to ever remove the eeprom would be for debugging, and there are plenty of ways of disabling it then.

We should remove the write protect jumper too. The atmel eeproms are really good with software write protect. We won't be able to update the stored FDPT if the eeprom is hammered to write protect.

Remove the IRQ selection jumper.

Brutman wrote:

jmetal88 wrote:Mike, is the main problem with the 'Chuck mod' that it writes the most significant byte followed by the least significant byte? Should it be doing this the other way around? I think I've figured out a way to swap around the outputs of the 74ls138 so that the latches store the least significant bit instead of the most significant bit, but I want to make sure that's actually the way I need to be going with this before I move any further.

I explained this earlier. The original design has the 16 bits of latch broken up on two different I/O ports that are not sequential in address space. We could get better performance if the latch was addressed by two I/O ports that had sequential addresses. That enables a 16 bit IN or OUT which is much faster than what is going on now.

The original modification posted by Chuck(G) at VCF swaps two address lines for the entire card. So it corrects the I/O port addressing problem, but it messes up the addressing of the ROM on the chip. I don't want to recreate that on this board.

Well, the schematics I'm looking at seem to have only modified the addressing on the IDE part of the card. I think they've already fixed that.

Hargle wrote: ok, let's simplify it down to 4 addresses for IO and 4 for memory location?

I think we can also remove the jumper for eeprom enable/disable. The card won't work without the eeprom. Well, it would work as a memory expansion, but why bother with just 1/2 of the capabilities?
The only reason we'd need to ever remove the eeprom would be for debugging, and there are plenty of ways of disabling it then.

We should remove the write protect jumper too. The atmel eeproms are really good with software write protect. We won't be able to update the stored FDPT if the eeprom is hammered to write protect.

Remove the IRQ selection jumper.

Alright, I got those jumpers taken care of.

As for the IO addresses, I'm thinking the most basic first step would be to lock it down to the 300h block of addresses. After that, there are a few options to cut it down to four addresses.

1: Use the lower four available (300h, 320h, 340h, 360h). A7 wired to match low.
2: Use the upper four available (380h, 3A0h, 3C0h, 3E0h). A7 wired to match high.
3: Wire A5 to match low (300h, 340h, 380h, 3C0h).
4: Wire A5 to match high (320h, 360h, 3A0h, 3E0h).

I don't really think it makes sense to lock down A6, but here's what you'd get:
1: A6 wired to match low (300h, 320h, 380h, 3A0h).
2: A6 wired to match high (340h, 360h, 3C0h, 3E0h).

A4 is already locked to low on the schematic.

Well guys, which one of these do you think works the best? I'm kind of leaning toward option 1, A7 wired to match low, since it leaves the default 300h available and also 320h, which is what I wanted to use.

If anybody has a problem with locking it to the 300h range, let me know.

Oh, and I went ahead and locked the ROM down to C0000. I can add a couple of jumpers back in, though, if necessary.

Brutman wrote: "Limiting" is in the eye of the beholder. The current version of my PCjr BIOS (based on Hargle's 0.9 BIOS) is less than 4KB, and the extended INT13 functions required for Win95 are still in there. We definitely won't need those if we get tight on space.

Well, ok put that way I think you are right, 32k would be too much. I'd still lean towards 16k with limiting jumper (if possible) this way people can decide for themselves if they want to waste the address space, but it still leaves the option to write a more complex (functional) BIOS if they want to. However, if it is not possible to cut it in half with a jumper then stick with the 8k.