XT-IDE on PCjr

[Hargle]

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.

Even on the XT, where there is the potential for a LOT more conflicts, our 16 possible locations for IO and memory is way overkill. At best, I think I only ever heard of 2 conflicts with NIC devices. The jr is such a closed box that we can limit the scope of ranges safely. whatever though. once we're buying and placing a 3 position dip switch, upgrading it to a 8 switch part isn't really any more overhead. It's a waste, but not worth the fight.

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.

No, we don't. This one I will fight you over.
We point the FDPT to the eeprom. Even the byte at 40:75 (disk drive count) can be set in the eeprom too. That stuff only gets re-written if the drive itself changes or if additional drives are detected in the system (rare).
We need 512bytes of RAM at bootup to receive the IDentify device data to get the drive parameters. We can use system RAM for that (we'll have 640k of it!). That memory is scratchpad anyway and isn't used after we collect the drive parameters. The only data remaining is the status byte (40:8c), which needs to go into RAM. If we can't find 1 stinkin byte to steal from the BDA for that, I will buy you lunch for a year.

We just have to make sure the device can write to itself, and that we use atmel eeproms.

[Brutman]

Even on the XT, where there is the potential for a LOT more conflicts, our 16 possible locations for IO and memory is way overkill. At best, I think I only ever heard of 2 conflicts with NIC devices. The jr is such a closed box that we can limit the scope of ranges safely. whatever though. once we're buying and placing a 3 position dip switch, upgrading it to a 8 switch part isn't really any more overhead. It's a waste, but not worth the fight.

How much of a waste are we talking about here? 3 switches total for I/O port and ROM addressing isn't enough. I'd rather be in the overkill part of the graph than the "this piece of crap is too limited" part. (Which is where the PCjr was born and normally lives, but that's a different problem.)

No, we don't. This one I will fight you over.
We point the FDPT to the eeprom. Even the byte at 40:75 (disk drive count) can be set in the eeprom too. That stuff only gets re-written if the drive itself changes or if additional drives are detected in the system (rare).
We need 512bytes of RAM at bootup to receive the IDentify device data to get the drive parameters. We can use system RAM for that (we'll have 640k of it!). That memory is scratchpad anyway and isn't used after we collect the drive parameters. The only data remaining is the status byte (40:8c), which needs to go into RAM. If we can't find 1 stinkin byte to steal from the BDA for that, I will buy you lunch for a year.

We just have to make sure the device can write to itself, and that we use atmel eeproms.

The current code now always creates the table. I think that creating the table only if it has changed since last time is reasonable. But how are you going to write protect the chip without the jumper? I've been hit a few times by the chip changing contents, and the jumper cures it. Is there a magic sequence of reads or writes that can be used to write protect the chip without using the write protect jumper?

The 512 bytes of RAM is covered already - the system expects to use a 512 byte chunk low in memory (7C00? I forget) to load the boot sector. It didn't conflict with the Jr so I changed the BIOS and did it exactly the same way.

On a moral and philosophical level, I'm not terribly happy with the idea of requiring an EEPROM, or a specific EEPROM at that. ROM should be ROM and RAM should be RAM. The design should provide it's own RAM if needed. That might be too over the top, but if the additional complexity and chip count are minimal then we should include it. I don't mind stealing a byte from an unused interrupt vector, but32 or so is a lot to steal.


BTW, these are exactly the kind of high level design questions that I want to flesh out ...

[alanh]

The EEPROM is used so that the contents can be programmed in-circuit after soldering everything onto a raw board. If you used PROMs or EPROMs, someone would have to gang program a bunch and send them out. Not many people have access to chip programmers.

[jmetal88]

If we do add RAM to the card, I'd like to mention again, we'll have to use a 2k chip. I can't find anything smaller in a DIP package that isn't extremely small (like 64 bytes or 256 bytes) or doesn't have a serial interface.

We can lock it down to 1k or 256k by grounding one or two of the address pins, though.

EDIT: Whoops, I meant 512 bytes, not 256k.

[Brutman]

The EEPROM is used so that the contents can be programmed in-circuit after soldering everything onto a raw board. If you used PROMs or EPROMs, someone would have to gang program a bunch and send them out. Not many people have access to chip programmers.

Hi Alan,

We definitely want an EEPROM so that we can flash the BIOS at a later time. But we have to have a write protect on it because the Amtel part we use is too easy to program accidently - I've had the contents change on me unexpectedly without the write protect jumper in place.

It's a FLASH based device. It's probably never going to wear out in my life time, but I don't like pointing at something that is supposed to be a ROM and treating it as RAM. But, I'm a software person, so maybe I need to get educated. ;-0

[jmetal88]

Mike, here's an updated schematic in which I've added 2k wired as 1k SRAM.

I added address decoding that should be set up so that we have 7k of the EEPROM visible to the system, and the 1k of SRAM accessible directly on top of that.

EDIT: I forgot to add extra decoupling capacitors in that schematic, so just pretend they're there. I'm putting them in my local copy of the schematic now.

[Hargle]

We definitely want an EEPROM so that we can flash the BIOS at a later time. But we have to have a write protect on it because the Amtel part we use is too easy to program accidently - I've had the contents change on me unexpectedly without the write protect jumper in place.

The atmel parts have a really nice software data protection mechanism. When locked, the entire device is read-only until a magic sequence of bytes are written to it.
Then the part becomes byte writable. Reverse the magic sequence of bytes and the device is locked.

The universal BIOS for XTIDE has a flash utility which locks and unlocks atmel devices. All we have to do is port over the lock/unlock (or go read the data sheet and write our own) code and drop it into our BIOS. Upon bootup, we read the ID data from the drive, scoop up the drive parameters. If they have changed from what is stored in the eeprom, we unlock and write, then re-lock the device. Otherwise, no writing is done to the device until a flash BIOS update is being done. In other words, it will likely get written *once* at first boot. Unless you're opening the car up and changing the HDD out every couple days, the device will never be written again.

The XTIDE project was originally plagued by stray writes which corrupted the eeproms, but those eeproms were made by SEEQ and did not support the write protect mechanism. That's when we added the write protect jumper. Switching over to atmel parts proved that we could use the software write protect mechanism instead of the jumper, which made life way better.

So, my vote here is:
1) atmel parts. There may be other compatible parts out there, but both SEEQ and Samsung 28c64's have shown themselves to be junk.
2) no write protect jumper at all. Simplifies the design and provides less methods to hang yourself. Makes flash upgrades easier.
3) no need to add RAM for us, or modify addressing lines or anything else. Also simplifies the design. (sorry jmetal88-looks like you've already done that work)

I don't see the harm in requiring a certain eeprom on our device. They will likely be sold as kits anyway, so just the act of buying one provides you with the part which should certainly last a lifetime.

[jmetal88]

The RAM was actually easier to add than I thought it would be. I would say there's a cost disadvantage, but the RAM chip is $1.25 and the two extra 7400 series chips are on the order of 60 cents each, so I like the idea of leaving it in.

It is a more complex hardware design, but it's a simpler software design - no need to program in a series of magic bits for write protecting before updating the table or anything!

[alanh]

I was thinking the idea of a pre-purchased/packaged kit was definitely out. Too much upfront cost for someone. We could do a group buy on the PCBs, but you'd always want the option of Joe Smith downloading the Gerbers and ordering his own board from a quick-turn house. Then buy the rest with a (eg) Mouser shopping cart. If kits were on the table, you could eliminate a half dozen chips (U1, U3, U8, U12, U15, U16, U18 [-7]) with a single 22v10 [+1].

And leave the WP jumper just so people can use other JEDEC ROM solutions.

[jmetal88]

I was thinking the idea of a pre-purchased/packaged kit was definitely out. Too much upfront cost for someone. We could do a group buy on the PCBs, but you'd always want the option of Joe Smith downloading the Gerbers and ordering his own board from a quick-turn house. Then buy the rest with a (eg) Mouser shopping cart. If kits were on the table, you could eliminate a half dozen chips (U1, U3, U8, U12, U15, U16, U18 [-7]) with a single 22v10 [+1].

And leave the WP jumper just so people can use other JEDEC ROM solutions.

Yeah, that's exactly what I was thinking - I wanted this to be made for home assembly, and I didn't want anything to require programming except the EEPROM (which can be programmed while the board is plugged into the sidecar bus without any special equipment).

That's also why I've assigned two footprints to the 74ls154 in KiCad. The 74ls154s I have on hand are 600 mils wide, but the less expensive one sold by Jameco is 300 mils wide.