On 25 Aug 2012 at 10:58, Alexis Kotlowy wrote: Just about any CF card can be set to operate in 8 bit mode. Same goes for Microdrives. So the circuitry can be very simple indeed if all you are going to use are the CF cards. --Chuck

and do, Hi Dave! Thanks! Yes, that's why I would keep the new board 16 bit so that it is compatible with a broad range of IDE devices including CF *and* parallel IDE drives. Also the extra features of the XT-IDE V2 would be useful like the option UART for remote booting from a serial port server. Apparently the XT-IDE V2 remote boot feature works pretty well and can be used to generate boot disks on a machine that has none. The Apple ][ can boot from a serial port as well so this is a neat feature to have. In addition, the optional ROM is helpful for booting systems or adding specific capability. I'd like to keep the design as general as possible just like the GIDE since then it can be used on a variety of systems. I am thinking of calling it the ZIDE to distinguish it from the GIDE since there are some important differences. I am still thinking this over and may do this project. However there are a lot of other important projects underway at N8VEM like the S-100 80386 CPU board, S-100 VGA, and the MC68040 SBC that are taking precedence right now. I am thinking though that the ZIDE would be a fairly small project though. It is pretty simple and just a conversion of the already well proven XT-IDE V2 design. Thanks and have a nice day! Andrew Lynch

On 08/24/2012 11:00 PM, Chuck Guzis wrote: You said "just about any CF card can be set to operate in 8-bit mode". Because it's COOL. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On Sat, Aug 25, 2012 at 12:33 AM, Chuck Guzis <cclist at sydex.com> wrote: I was thinking this was more about drives on the small side - CF Type III and Kittyhawks - sub-2.5" rotating memory with standard interfaces - those are still cool, aren't they? -ethan

On 25 Aug 2012 at 0:42, Ethan Dicks wrote: I believe they're all 8-bit capable (not certain about the Kittyhawk).. I keep hearing that microdrives aren't meant to be run on a continuous basis, but I've had a Seagate 5GB ST1 drive running 24/7 here since....it says February, 2008 without a tingle. So maybe they're good for continuous use... --Chuck

On Sat, Aug 25, 2012 at 1:35 AM, Dave McGuire <mcguire at neurotica.com> wrote: Interesting to hear that. I have two 20MB drives and didn't get any 40MB drives long ago when I had the chance. Apparently, I chose wisely (plus 2x 20MB cost me less than 1x40MB, the largest factor in my decision). Yep. I have one on my IDE64. Much fun. -ethan

Hi I've written up a preliminary schematic for the ZIDE circuit. It is similar to the XT-IDE V2 in most ways but with a few differences. The ROM has changed from a 8KB-32KB EPROM/EEPROM to a 2KB EPROM/EEPROM. This is because the address space of a Z80 is much smaller than the 8088 and generally you don't need large ROMs. 2KB of optional read/write EEPROM or read only EPROM should be sufficient. The ISA bus signals are slightly different than the Z80 so I did a little conversion of signals. For instance, the ISA RESET and IRQ signals are all active-high where on the Z80 they are active low. Also the ISA MEMR*/MEMW*/IOW*/IOR* have to be converted to Z80 MREQ*/IORQ*/RD*/WR* The interrupts on Z80 are simpler too. However since the Z80 will be in shim socket I am thinking the RESET* and INT* signals will have to come from open collector gates to accommodate whatever the host machine is already doing on those signals. If anyone wants to take a look at the schematic please contact me offline. However, I am keeping the 16 bit IDE interface regardless. It makes no sense to me to restrict compatibility of the ZIDE to small percentage of IDE/CF devices and effectively lock out so many still useful IDE drives. Thanks and have a nice day! Andrew Lynch

On 08/25/2012 08:59 AM, Andrew Lynch wrote: I'd make the rom phantomable even for 8088. ISA is nearly multibus signals save for the screwed up interrupt lines. Its a fully decoded bus. However Z80 only needs a few gates to get decoded signals. Depends on mode. They can be as complex as you would like and can use. And be strapable for OPEN. many of the host machines the INT line was NOT open collector. Reset is INPUT to the IDE device not outputs so open collector are only needed if there will be two drives and not on the Z80 since as the source of those drove the ZIDE. Interrupts are not used in the early ZIDE as all the systems were polled IO and the status register is tested and available that way. If your using interrupts then the interrupt source (host system) will likely be TTL and not open collector making it a not bus able but a into the card logically ORed with the host sources and then put back out to the Z80 and TTL. IN Z80 and 8088/86 world interrups are handled very different. Z80 it can be a fixed address (loc 66H) 8080 Vectors (RST0-7 or CALL NNNN), OR Z80 vector mode (low byte INT vector + Highbyte int register= ISR). The 8088 wants a 8bit vector to point into the low memory int map. Again for z80 since the IO is PIO it makes little sense to mess with interrupts as status check is easy and the response time of IDE is faster than Z80 for data available or written as the device is buffered (usually much more than a sector even in the oldest ones). ZIDE was simple device that did the 8:16 conversion for the data bus and in such a was that sequenced read and write to one address did the lifting. In that it was a very simple device. the whole 8:16 conversion was due to two things sub 60mb drives existed then and people never though of tossing the high byte for simplicity. It does not impact CF comparability or the few rare hard disks that did do 8bit mode at the hardware interface level. One thing to remember is this. IDE drives unless they are very old and under 100M are bigger than any Z80 OS can use in any practical way. Using only the Low 8bits for a drive of 500MB means you have sectors of 256bytes and 250MB of space and CP/M 2 is limited to 16 drives or 8mb or 128MB, MPM or CPM plus ups that to 512M (16x32MB) but the WHOLE Walnut creek CDrom with duplicate files removed is less than that and that is the for the most part whole CP/M free software world. Oh and doing a directory of a drive that take a while, a whole pot of coffee while. FYI try to find drives less than 500MB that are not questionable though I have a box load of 40 to 420meg drives. NOTE: using newer drives in the 500MB and larger, the cache on board is large enough to hold at least 128K and some as large as 1MB, so their access time for any sector read is likely going to be fast for the first sector and in cache for the rest after that. Don't use skew as it's pointless and tends to scatter the data. Also use larger allocation blocks like 8K as that means fewer seeks and directory reads adding speed. Also drive in the 500MB and larger especially 1Gb and larger have internal LRU seeks to try and anticipate the next read and have that in cache. Reading and writing to cache is faster than old school MFM interfaces and drives. For CF and later this is even better. GIDE performance was limited to Z80 PIO speeds and that was in the around 190Kbytes second for a 4mhz part and over 470KB/S for a 10mhz part (without waits). The reason for this is the sector silo is easily as fast as the execution speed for a INIR or OUTIR and those are 21cycles (5.25US per byte@ 4mhz without waits). In reality it's slower due to status checking before and after and system overhead but the disk buffers are fast. When compared to the easier and somewhat simple 8255 PPI interface that holds speeds to under 20K bytes second as readign and writing the 8255 imposes a lot of software overhead.. Doing the above without 8:16 translation impacts the performace near zero and in some cases can help as the hardware to go from z80 to IDE is a few gate s and inverters plus a LS245 bus buffer. Most of the drives the data interface and IO address low order decode is internal and faster than most Z80s (io access time 125ns for old drives and faster for the 33mhz and 66mhz IDE) Allison