ibmapc
Veteran Member
That is strange. When I had a Micro Drive connected to my ADP50L in my 5155, it was MUCH slower than a CF card.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Forthcoming XT-IDE Board - Cast Your Vote
- Thread starter pearce_jj
- Start date
That is strange. When I had a Micro Drive connected to my ADP50L in my 5155, it was MUCH slower than a CF card.
Trixter
Veteran Member
Stranger still is that I saw no appreciable difference between a 256CF and a 340MD in my ADP50.
It's because of the block-mode transfers - the microdrive in questions supports 16-sectors per IRQ, meaning DMA controller needs to be programmed only once to do 8k.
To add, the XTIDE Universal BIOS is quite heavy for an 8088 (compared to, for example, the IBM/Xebec source) - because of the generalisations necessary, there's a lot of jumps involved in just checking the IDE status register within the read or write transfer loop. So block mode helps with DMA so dramatically because it reduces not only the DMA programming but also the iterations through the IDE wait function. For example, for memory-mapped mode the CF card transfer rate can be improved (on a 4.7MHz XT) by about 20% by hard-coding the control register ports and ready checks in the ide_transfer module.
Part of my plan for this card is to have an optional TSR to handle Int13h read and write functions in a highly specific (and hence fast) way. This is really specific to compact flash media, since even with a 16-sector block mode, the DMA and polling overhead is almost insignificant with the microdrive (~2%).
To add, the XTIDE Universal BIOS is quite heavy for an 8088 (compared to, for example, the IBM/Xebec source) - because of the generalisations necessary, there's a lot of jumps involved in just checking the IDE status register within the read or write transfer loop. So block mode helps with DMA so dramatically because it reduces not only the DMA programming but also the iterations through the IDE wait function. For example, for memory-mapped mode the CF card transfer rate can be improved (on a 4.7MHz XT) by about 20% by hard-coding the control register ports and ready checks in the ide_transfer module.
Part of my plan for this card is to have an optional TSR to handle Int13h read and write functions in a highly specific (and hence fast) way. This is really specific to compact flash media, since even with a 16-sector block mode, the DMA and polling overhead is almost insignificant with the microdrive (~2%).
Last edited:
Shadow Lord
Veteran Member
Looks very nice! Will the assembled version have the switch and jumper pins for the light installed? Do you know what the final price is going to look like shipped to USA?
RWallmow
Veteran Member
I am also liking what I see, and would also like to know about price to USA ;-)
Yes, that board just isn't finished yet
Don't know final prices yet - following a couple of leads on it at the moment.
General update on this as it has been a while.
I've built three prototypes of the V2 board; the time has been absorbed by working on the CPLD logic. Yesterday I built a version that seems to work well in all three modes and seems stable. Wow, this could actually be finished, I thought.
But then I programmed the other two cards with the same XSVF file. Neither work, both return garbled drive ID string. All three cards use CPLDs from the same batch, and all three worked (and continue to work) exactly the same with all prior builds. It's very puzzling.
Please post if you have any experience with such problems!
I've built three prototypes of the V2 board; the time has been absorbed by working on the CPLD logic. Yesterday I built a version that seems to work well in all three modes and seems stable. Wow, this could actually be finished, I thought.
But then I programmed the other two cards with the same XSVF file. Neither work, both return garbled drive ID string. All three cards use CPLDs from the same batch, and all three worked (and continue to work) exactly the same with all prior builds. It's very puzzling.
Please post if you have any experience with such problems!
Chuck(G)
25k Member
What does your simulation output look like? You may be running afoul of simple timing variations in a batch of CPLDs.
Thanks, TBH I'm not too familiar with simulation. The timing output suggests it should be usable to clock speeds of 70MHz or so, which I had presumed to mean there would be enough head-room.
In case you (or anyone!) fancies a look, the ISE files are here.
In case you (or anyone!) fancies a look, the ISE files are here.
I went back to earlier code and ran through each logic change one-by-one.
Issues seem to appear in testing DMA signals against a DMA-ENABLE DIP switch, so the board can't co-exist with another disk controller that uses DMA channel 3.
Question: Is this an issue?
Issues seem to appear in testing DMA signals against a DMA-ENABLE DIP switch, so the board can't co-exist with another disk controller that uses DMA channel 3.
Question: Is this an issue?
Quick update: I found a couple of minor logic errors in the CPLD design, and after weeks of starring at it suddenly the penny dropped... glaring timing issue right there in the mux module. With that sorted the board is now running apparently well, and can now co-exist with another disk controller that uses DMA 3 (provided DMA operation is not enabled on the XF-CFv2 board, of course). I'll post sources tomorrow.
i did not see my post saying how much money and when.,
Somewhere I have some 2764 eproms
they were given away as that lost "tracebility" from a government projest
I need liuk fining them
20-25 years ago this would have been an easy project to finish / build.
But now at 76 wnd eyes getting worse and worse. I would have to go for a finished pcb.
I have small IDE drives.
I am assuming that the OS / dod version may limit the size., I know DOS has a 2,048 limit.
but I used a 4g drive as two partitions.
my recent project was making a boot floppy with usb support
Usually w98 dos but I tested it with dos 6,22
It might even work on an xt/pc If I had an isa card.
Somewhere I have some 2764 eproms
they were given away as that lost "tracebility" from a government projest
I need liuk fining them
20-25 years ago this would have been an easy project to finish / build.
But now at 76 wnd eyes getting worse and worse. I would have to go for a finished pcb.
I have small IDE drives.
I am assuming that the OS / dod version may limit the size., I know DOS has a 2,048 limit.
but I used a 4g drive as two partitions.
my recent project was making a boot floppy with usb support
Usually w98 dos but I tested it with dos 6,22
It might even work on an xt/pc If I had an isa card.
NobodyIsHere
Veteran Member
- Joined
- Dec 21, 2006
- Messages
- 2,410
Hi
The XT-IDE V2 PCBs should be here next week. I am estimating ~7 Aug or so. These are the DIY hobbyist home brew boards you build yourself.
Please contact me at LYNCHAJ@YAHOO.COM if interested. I am keeping a waiting list but there should be enough PCBs for everyone and a few extras.
Thanks and have a nice day!
Andrew Lynch
The XT-IDE V2 PCBs should be here next week. I am estimating ~7 Aug or so. These are the DIY hobbyist home brew boards you build yourself.
Please contact me at LYNCHAJ@YAHOO.COM if interested. I am keeping a waiting list but there should be enough PCBs for everyone and a few extras.
Thanks and have a nice day!
Andrew Lynch
NobodyIsHere
Veteran Member
- Joined
- Dec 21, 2006
- Messages
- 2,410
Hi
I just got a notification and the XT-IDE V2 PCBs will be arriving tomorrow. Everything will be the same as before so please contact me at LYNCHAJ@YAHOO.COM if interested in participating in this batch. Thanks to all who have made the XT-IDE project a success and good luck to the new projects!
Thanks and have a nice day!
Andrew Lynch
I just got a notification and the XT-IDE V2 PCBs will be arriving tomorrow. Everything will be the same as before so please contact me at LYNCHAJ@YAHOO.COM if interested in participating in this batch. Thanks to all who have made the XT-IDE project a success and good luck to the new projects!
Thanks and have a nice day!
Andrew Lynch
sergey
Veteran Member
I am wondering if anyone tried or have some thoughts on connecting Compact Flash cards to a 8-bit ISA using either Memory Mode or I/O mode, that support 8-bit operation (instead of the true IDE mode that requires 16-bit)?
It looks like it is very simple to interface an CF card using one these two modes. Basically only CS logic is required - something like one 74LS688 (Add another 74LS688 and an EEPROM or Flash ROM for the BIOS extension).
Here is a schematics for connecting CF card to a microcontroller in Memory Mode (just to show required signals): http://www.walrus.com/~raphael/pdf/compactflashOnPicArticle.pdf . By the way what is Memory Mode for CF card doesn't have to be memory mapped I/O on computer side - it is completely possible to use 8 I/O ports instead. (Though memory mapped I/O might have some advantages - less [or no] wait cycles and possibility to use string instructions).
Disadvantages:
- Won't support DMA (since it is only supported in true IDE mode), and potentially will be a bit slower.
- This approach is CF-card specific, and won't work with regular IDE drives (but IDE disks are obsolete anyway, and CF cards are not and they are cheaply available).
It looks like it is very simple to interface an CF card using one these two modes. Basically only CS logic is required - something like one 74LS688 (Add another 74LS688 and an EEPROM or Flash ROM for the BIOS extension).
Here is a schematics for connecting CF card to a microcontroller in Memory Mode (just to show required signals): http://www.walrus.com/~raphael/pdf/compactflashOnPicArticle.pdf . By the way what is Memory Mode for CF card doesn't have to be memory mapped I/O on computer side - it is completely possible to use 8 I/O ports instead. (Though memory mapped I/O might have some advantages - less [or no] wait cycles and possibility to use string instructions).
Disadvantages:
- Won't support DMA (since it is only supported in true IDE mode), and potentially will be a bit slower.
- This approach is CF-card specific, and won't work with regular IDE drives (but IDE disks are obsolete anyway, and CF cards are not and they are cheaply available).
Chuck(G)
25k Member
Doesn't pearce_jj's XT-CF board do just that? I believe it supports both 8-bit DMA and programmed I/O modes. 3 ICs--you can't get much simpler than that.
ChrisCwmbran
Experienced Member
I suggested in the IRC channel perhaps more jokingly than anything at the time that what I would ideally like is one of these boards that has sampled sounds for the hard drive spinning up, and seek sounds from say an ST-225, but thinking about it more, I really like the idea. I know at least one of the floppy emulators on the market emulates floppy sounds.
How hard would this be to achieve?
How hard would this be to achieve?