XT-IDE on PCjr

[Hargle]

OK, well, BIOS support was just a thought. I know I'd be able to come up with a small .COM or .EXE which could handle a clock myself, but if one of you wants to come up with a .SYS file for me (I'm still not that great at coding anything), for more transparent operation, that would be great!

Yeah, I've written a couple .sys files in my past, it's not that much different than writing an .exe, just a lot more painful to debug.

If we can get the data out of the CC and into the machine even earlier by adding BIOS support for it, we will most certainly do that. I'm just not sure if we need any DOS hooks to get the date+time updated. If we do, then .sys, if not, then BIOS. I haven't looked at get/set date+time functions in years though. I wanna say that no DOS hooks are required...

And for Mike, the mod for moving the data into two 8 bit registers does so by swapping address bits 0 and 3.
This messes up the IDE shadow registers, but it's not that big of a deal.

Formerly, the shadow registers looked like this:
Data register: base+0 (this is a 16 bit port on AT+ machines, but not for us)
features: base+1
sector count: base+2
LBA Low:base+3
LBA Mid:base+4
LBA high:base+5
Device:base+6
status:base+7
data2:base+8 (for 8 bit machines to get the 2nd data byte)

Now things look like this:
Data0: base+0
data1: base+1
features: base+8
sector count: base+2
lba Low:base+a
lba mid:base+4
lba high:base+c
device:base+6
status:base+e

[alanh]

Stupid question.. but if the register maps are changing so that IDE drive regs are no longer mapped 1:1 into I/O space, why map them in I/O space at all? 8-bit I/O access always adds 4 wait cycles. If you left a hole in the ROM image, decoded the IDE chip selects to the base of the hole and masked off the ROM, you could do 1 wait fetches from RAM. Of course decoding that strictly with 74xx ala A.Lynch style would be painful. Of course DMA would do the same thing on non-PCjrs if there were support for it.

[Brutman]

Alan,

Not a stupid question at all - I've been talking to Jeff (Hargle) about a memory mapped version of the XT-IDE for two years ...

• XT-IDE is mostly register level compatible; for commands it works but for data it is broken because a 16 bit read of the data register would pick up a bad byte. So we're not running Spinrite or any other program that demand exact IDE register compatibility.
• The good 8 bit SCSI cards memory map their registers avoiding the wait state. (I though I/O space adds only one wait state, not four. Memory mapped should be 25% faster than I/O mapped.) Even just moving the single data register to a memory mapped address would be far faster because the majority of the time is spent reading and writing that register.
• It's a PCjr - we are borked on compatibility in so many ways. I think that shooting for BIOS level compatibility (and not register level) is all that we need. (SCSI based machines prove this.)

I'm not a EE .. but I'm trying to keep up. I was making notes on the pinouts and ATA specs last night and looking at your most recent schematic. I like the PAL idea because it cuts down on the chip count and makes trace routing easier. What does it take to program them? (I'm still in the market for an EPROM/EEPROM programmer.)


Mike

[alanh]

Many PROM programmers will also do common PAL types (Rs, Ls, and Vs which are R+Ls). But to be sure you have to check with the manufacturer's specs. I got a surplus ChipMax 2 USB programmer relatively cheap that will do most.

I'm not sure how the wait state generator on the Jr behaves. For 5150/60 and most clones, 8-bit I/O cycles generally add 4 wait states. I seemed to recall 8-bit memory cycles defaulted to less (1 wait?), but I'm having trouble confirming that. Since the Jr has no shortened wait state indicator signal unlike ISA, memory access is only an improvement if the default is less. The tech ref makes mention that system RAM adds only 2, but it's unclear if that is a special case for addresses under 128K.

I discovered a logic error in my PLD statements on the schematic shortly after I posted it. I'll leave it to you as an exercise to find which ones.

[jmetal88]

I'm not sure how the wait state generator on the Jr behaves. For 5150/60 and most clones, 8-bit I/O cycles generally add 4 wait states. I seemed to recall 8-bit memory cycles defaulted to less (1 wait?), but I'm having trouble confirming that. Since the Jr has no shortened wait state indicator signal unlike ISA, memory access is only an improvement if the default is less. The tech ref makes mention that system RAM adds only 2, but it's unclear if that is a special case for addresses under 128K.

I'm not sure about that either, but I do know programs that load above the 128k system RAM run a lot faster than programs loaded within the 128k.

[jmetal88]

I'm not a EE .. but I'm trying to keep up. I was making notes on the pinouts and ATA specs last night and looking at your most recent schematic. I like the PAL idea because it cuts down on the chip count and makes trace routing easier. What does it take to program them? (I'm still in the market for an EPROM/EEPROM programmer.)

This guy came up with a DIY GAL programmer. It'd be an interesting project to build and try out, I think.

http://elm-chan.org/works/pgal/report_e.html

[Hargle]

Stupid question.. but if the register maps are changing so that IDE drive regs are no longer mapped 1:1 into I/O space, why map them in I/O space at all? 8-bit I/O access always adds 4 wait cycles. If you left a hole in the ROM image, decoded the IDE chip selects to the base of the hole and masked off the ROM, you could do 1 wait fetches from RAM. Of course decoding that strictly with 74xx ala A.Lynch style would be painful. Of course DMA would do the same thing on non-PCjrs if there were support for it.

Two reasons:
1) Speed isn't an issue. I'm perfectly happy with the performance that the original XTIDE provides. The "chuck mod" increases the speed drastically. Increasing it even more by reducing 4 wait cycles is merely additional frosting on a heavily iced cake already. I mean, c'mon. it's a PCjr. I'm not going to be streaming 1080p video off it! If it's faster than a floppy, and bigger than 360k, I'm pleased.

2) I was hoping to re-use proven technology to speed up the process of the development and reduce the amount of board re-spins. No one had yet done a memory mapped version of the XTIDE to prove it out, and not being a HW guy, I didn't know what was involved in making that happen. We got so hung up on feature creep on the XTIDE that we spent the first 6 months spinning our wheels. I was trying to avoid that here.
Now that we have more HW guys on board, and the board is pretty much being completely redesigned anyway, memory map away!

Not trying to dissuade going a mmap route, just explaining why IMO, it wasn't necessary.

[Brutman]

Jeff,

You have not experienced joy until you have seen a PCjr do sequential reads at 300KB/sec. Yes, that kilobytes ...

(My SCSI adapter uses memory mapped I/O, and it can do that.)

Yes, the XT-IDE is better than a spinning floppy disk. But if the design work isn't that much more I think that memory mapping is worth the effort. Especially since we don't need perfect IDE register level compatibility in the BIOS. But not being a hardware person either, as long as we have something where we can do 16 bit reads and writes I'm quite happy.

[jmetal88]

I think I could shift the IDE addressing into memory space pretty easily, at least with the 74xx version of the board. I don't have much experience with coding for GAL chips, so I couldn't be sure anything I'd code for that would actually work until I tried it. I'll give it a shot later this evening.

[jmetal88]

Alright, here we go. This one takes up 16k of ROM space, which should be selectable anywhere within the C and D areas of memory space (I'm hoping I didn't make any errors there).

This one leaves the bottom 8k as ROM, 16 bytes above that as IDE access, and 16 bytes above that I chose to use to access an RTC chip. Using this design has brought the number of DIP switches down to three.

Please excuse the fact that I have not changed the number of decoupling capacitors or actually added the clock chip into the circuit yet.