XT-IDE on PCjr

[MattCarp]

It's funny how, when presented with a blank sheet of paper and then challenged with something you've never done before [in another domain] they look intimidating and impossible. However, Mike you've made a custom enclosure seem very feasible. Probably the hardest thing is what tool do you want to use to draw it - Google SketchUp, Adobe Illustrator, whatever!

I was more comfortable with a parallel port!

I think if the enclosure is thought through to support a certain set of enhancements, allow room for a disk drive (or two? a 5.25" and a 3.5" would be really nice?), a power supply and n ISA slots, you'll have a winner.

As far as what those enhancements are, I think you've got a good list. What I'd do is create the board in such a way that people can select what they want, and then they can solder up just those modules.

My preference really was a sidecar, as a standalone enclosure makes me think I should just use my XT. However without ethernet, the value of an IDE+memory is limited. I think ethernet is a stretch at this time due to power requirements (Silicon Labs chip) or 8-bit (CS8900 chip) limitations. Even if those were addressed, software would still be challenge.

[Lutiana]

Personally I think the ideal for me would be a sidecar with an IDE controller that drives an SD of CF card for storage (2gb would be plenty of space), a NIC and possibly the RAM. If I have to power it with a 12v 1a wall wart thats ok. Paralell is nice, but not really all that neccesary with ethernet and mass storage.

Though the idea of an aditional enclosure is also appeals as an idea, I can't help but think my desk space is at a premium these days and a sidecar just takes up way less space. I also think that a sidecar would ultimatly be cheeper that a whole other enclosure, and it would be aesthetically more pleasing too.

In all honesty I am quite torn between the two ideas and can really see the advantages to either approach, I'd like one of each please

[jmetal88]

Mike, I'd still like to hear what specifically your ideas for changes in addressing and adding the onboard RAM for the drive tables would be.

For example, do you think we should just assign the RAM a block of IO address space, or what?
EDIT: I guess not IO space, although I'm not sure how much room the address tables take up, but is there a specific memory area you're looking at?

[Brutman]

I haven't had a lot of time to think about this, but here is the high level view of what needs to be fixed:

• The XT-IDE has to "borrow" memory that is reserved in the memory map. The location is supposed to be reserved for the BASIC interpreter. I have no idea if this memory is actually in use and thus we have a conflict with interpreted BASIC, or if the memory is not actually being used. But to be safe, the XT-IDE should provide its own memory. I think 64 bytes would cover everything that we need, but we can live it up and make it 1KB. ;-0 It has to be in the memory map, not I/O space.
• The way the latching is done on the data register gives us two, non-sequential I/O ports that we have to read to get a 16 bit word from the drive. If the two ports were correctly arranged, we could do the 16 bit read with a single instruction. That would speed things up quite a bit.

I know how to fix both problems. I just need to get the original schematics, load the tools, and start making some alterations.

Hargle (a new member) is responsible for the BIOS that I started with. I'm sure he has some good thoughts on what to do.


Mike

[jmetal88]

Alright. Well, looking at available SRAM chips, I think it'd be easiest (and cheapest) to use half of a 2k 2016 SRAM for the 1k of storage. I was looking at 1k SRAM chips, and at least from Jameco, there are only 1kx4 SRAM chips available, not 1kx8. I'm going with Jameco here not just because I like them, but because the BOM for the original XT-IDE lists Jameco part numbers.

EDIT: But yeah, I'm thinking we should get a working JR-IDE schematic put together before we do a whole lot else.

[Hargle]

Hi all.
Time for me to jump in and stir some more things up.

The XT-IDE has to "borrow" memory that is reserved in the memory map. The location is supposed to be reserved for the BASIC interpreter. I have no idea if this memory is actually in use and thus we have a conflict with interpreted BASIC, or if the memory is not actually being used. But to be safe, the XT-IDE should provide its own memory. I think 64 bytes would cover everything that we need, but we can live it up and make it 1KB. ;-0 It has to be in the memory map, not I/O space.

Mike mentioned this earlier in the thread, but there's one minor update to his comment that I need to fix.

The atmel 28c64 parts are actually byte writable without having to erase the entire device (or a block in it), so it actually would be very, very feasible to store the FDPT data inside the eeprom itself. We would have to have enough free code space to port over the software data protection lock/unlock code from the flash program, but that's pretty small. This removes the need for additional memory and simplifies the design, but does tie the device to only work with any eeprom that shares this particular ability to do byte updates. BIOS would then ID the drive, and only ever update the FDPT if it is different than what was stored in the eeprom. We get something like 10k or 100k write cycles to the device, so I doubt anyone is going to swap their drives THAT often! We could also have data stored in the eeprom for the NIC device, if it needed to be programmed with a MAC address or whatever.

We'd still need to steal a byte or two for status though. I gotta think we can find at least 2 in the BDA that we can hijack.

[jmetal88]

Man, I really wish there was something I could do to help speed this along. All I can do though is schematic capture and PCB layouts.

Anybody have any more implementation comments?

[Hargle]

well, just for banter (Mike just started a new job, so I can see why there hasn't been a lot of activity here).

I have an "all of the above" vote.
While not personally interested in a full ISA bus expansion device for the PCjr (I already have a PC, XT, and Tandy 1000 for that), I don't see why we can't pursue multiple designs, including a massive expansion bus.

I think a sidecar with XTIDE and memory would be perfect. Removing the PCB from a 128k sidecar and then replacing it with an XTIDEjr and 512/640k upgrade makes the most sense to me as a quick, easy, low risk first product. I was hoping to install a hitachi 3k8 microdrive in it, or CF. I'd even be willing to dremel out the back of the sidecar so that CF could be inserted and removed.

Other ideas:
Redesign the internal 64k expansion card. Could we move all the memory onto that thing instead of putting it into a sidecar?
How about a new card there with the clock calendar bolted on too? It seems a clock calendar would be easier to maintain (not that batteries die THAT often) if it were just inside the box, not inside a sidecar.

Can we design an ethernet card that goes in the modem slot? Does an RJ45 connector fit through the back of the machine where a modem's RJ11 would go?

Anyway, PCBs are reasonably cheap to make. Even if it costs $50 each just to make 10 prototypes and we do 3 different prototypes of 3 different products, there are still people willing to pay for it because these things just don't exist now, so there is no target price point to try and reach, so don't need to try and shoehorn everything into the ultimate product.

[jmetal88]

Unfortunately, there are only 8 address lines on the 64k expansion slot - It's interfaced with the DRAM controller on the motherboard, so we couldn't really do any more RAM expansion than we already have on the stock card. I don't think we could get a calendar on there either, for the same reasons, although it would be dead simple to put a calendar in the modem slot, providing one doesn't mind taking up address space that could go toward a second serial port.

[Hargle]

Can ethernet+CC be done in the modem slot? How many IO addresses are needed for each?
Do we need a CC if we have ethernet? I mean, wouldn't the time be updated automagically when you log into a remote computer? I thought I remember netBIOS doing that.