there are a few contraptions out there by which you can connect a CF or SD card to a Commodore 64, presumably an IDE drive too. Try ide64.org for starters. There was another one on Epay recently, which I think used an MMC/SD card. The notion of adding such a device to an old puter has intrigued me also. Old RLL/MFM drives are a waste of time IMHO, and new IDE drives probably won't work, provided you even had an IDE interface (they do exist for XT class machines, but most of mine have proprietary buses). I know this is a broad question, but to what degree can an FPGA take the place of early custom ic's? Say for instance you wanted to replace the video ic like a NEC uPD7220 and couldn't find a replacement, or the custom video or sound ic in a Mindset or Atari ST. --- Tony Duell <ard at p850ug1.demon.co.uk> wrote: ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

Roger Merchberger wrote: Okay, now I've got to ask: Anything like this for a 1981 8088 PeeCee? -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Want to help an ambitious games project? http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/

I am pretty sure some later PC BIOSes (not XT ones, specifically) allowed booting from a hard disk. More exactly, what was added was the search for extension ROMs. No IBM PC or XT motherboard BIOS knew anything about hard disks. But the later ones searched for extension ROMs before booting, and if any were found, a routine in each extension ROM was executed. This routine could re-direct software interrupt vectors to point to routines in the ROM, in particular, the bootstrap vector could point to a routine in an extension ROM that would attempt to boot from a hard disk before falling back to the standard floopy drive boot routine. -tony

On Fri, 5 Aug 2005, Jim Leonard wrote: There are ISA adapters for PCMCIA. There are adapters to plug CF into PCMCIA dlots.

On Sun, 7 Aug 2005, Jim Leonard wrote: YES. There are, or at least WERE, 8 bit ISA PCMCIA adapters. That would certainly reduce the I/O bottleneck, but 4.77 MHz will never be "fast". -- Grumpy Ol' Fred cisin at xenosoft.com

On Mon, 15 Aug 2005, Jim Leonard wrote: I YOUSTA have an 8 bit ISA card with a PCMCIA slot on the back. There was also an ISA card with a cable to a PCMCIA slot in a holder that mounted in place of a 3.5" drive. ISTR the name as being something like "DataBook Thin Card Drive". The machine that it's in is not very conveniently accessible, but I might be able to get at it in a few weeks. If so, I'll dig it out, and confirm what it is. One of the San Jose surplus places (Halted? Haltek? HSC?) used to carry them, 15? years ago. There were also some IDE PCMCIA interfaces. Dunno whether an 8 bit IDE card would work with one of those. I remember some 16 bit ISA disk controllers that claimed to be able to maintain a 1:1 interleave, but no 8 bit ones. IIRC, Speedstor or Spinrite would do a test of different interleaves to try to find the optimum. -- Grumpy Ol' Fred cisin at xenosoft.com

Yes, from what I rememebr, a CF card can be made to look very much like an IDE drive. The IDE interface is very simple (the IDE card in this computer is about 10 TTL chips and a PAL). It should be possible to link an IDE drive to just about any old computer, as the drive (AFAIK) includes a data buffer RAM, it shouldn't matter if the host can't keep up with the data rate. I will admit I've not tried it, though. I suspect the main problem is writing the necessary drivers and getting the OS to recognise the new drive To take my favourite classic, the PERQ. It would be fairly easy to add an IDE drive interface on an OIO (Optional I/O) card. It would also be not too hard to write a program to transfer files between the main (ST506-interfaced) drive and the IDE drive, that is to use the IDE drive as a sort of backing store. It would be a _lot_ harder to get a PERQ to use an IDE drive as the main hard disk. An FPGA is bascially what it says it is. A chip containing arbitrary logic gates (you define the functions when you program the chip) and flip-flops. Programming also defines the internal connections between the gates. You cna make just about any digital function using an FPGA, including, of course, procerssors. If you want to replace an existing chip, of course it's unlikely you'll be able to make a drop-in replacement (you can't assign power pins where you like, often an FPGA has dedicated clock inputs, etc). Another problem is working out the schematic/VHDL 'program' that represents the chip you want to replace. Particularly for custom chips where the full specs may well not be available And another problem is that, no matter waht the manufacturers will have you believe, every FPGA I've seen has interesting quirks. I suspect that if you took the schemaitcs of a TTL-based minicomputer, put them into a schematics capture program and turned the result into an FPGA program, the resulting FPGA would _not_ correctly emulate the original minicomputer. -tony

On 8/4/05, Tony Duell <ard at p850ug1.demon.co.uk> wrote: In this vein, I'm fiddling with CF cards on a variety of machines (C-64 w/IDE-64, SBC-6120 w/IOB-6120 and with external CF interface, Elf 2000 w/ElfDisk board...) and am running into what might be compatibility issues with older CF cards. I've found a variety of web resources googling around, but does anyone have any information about when there might have been a sea change in CF features between the days of 4MB cards and "modern" 512MB cards? Specifically, I have a stack of HP 4MB CF cards that work with many devices. Those and some 8MB and 16MB cards (Kodak, SanDisk, etc, not brandless ones), don't seem to work reliably in some of my devices (IDENT failing, as one example) but in the same device, my Elf2K for example, the 1GB card came right up with the expected manufacturer string. So was there some change starting with, say, 32MB or 128MB cards, about timing or some other issue that might affect something as simple as reading the device registers from the embedded controller? In case it matters, AFAIK, the problems I'm having are only with using a CF card in a strictly 8-bit mode (something that CF cards do that "real" IDE drives do not). I'm not thinking this is something subtle - I'm thinking that someone might remember some warning somewhere about "oh, yeah... don't use 16MB cards in _that_ device... you have to use 32MB or newer". Any and all impressions accepted. I'm not the creator of any of these devices, so I have to kinda nibble around the problem from the edges before I try any sort of attempts at a fix. Of course, a pointer to a white paper on how to talk to CF cards in 8-bit mode would be most welcome. :-) Thanks, -ethan

Ethan Dicks wrote: There is the older CF standard, and the newer CF+ standard. However, both should function identically in "True IDE" mode. Well, the official CompactFlash spec (google for a copy, or email me as a last resort) tells quite a bit, but one must have a grounding in how to communicate with an IDE drive first (to understand the command set and sequence). You can only do 8-bit mode when in CF "memory mapped mode". But, as that requires the same amount of lines and precludes the support of IDE disks in a project, many opt to use True IDE mode. In IDE mode, you have to send and receive data in 16 bit chunks, but I do it with a 8-bit micro, and others have as well. You simply treat the 16 bit data as two IO bytes, and twiddle the IDE lines via a third IO port as needed. Polled IDE mode requires 24 IO lines to operate. Memory mapped 8 bit mode requires almost as many, unless you decide to directly map the 1K CF "window" into your memory map. But, in the end, True IDE mode is simple enough and supports IDE, PCMCIA, and CF options (disk wise). As for the issue you decribed, if you want to mail me a card, I can play with it and see. I did notice an issue with a card previously mailed to me; it did not have an MBR. Many interfaces (mine included), rather assume an MBR as the first sector of the disk. But, some smaller cards opt to forego the MBR, placing the first FS sector as sector 1 of the card. At this point, I don't know how OS's like Windows determine what the FS is on the card, as the FS type is a function of a byte in the MBR (which is missing on those cards). I addressed the issue here by doing using fdisk to delete all partition information, doing a fdisk /mbr (or was is format /mbr), and creating a new partition on the card in a PC with a IDE->CF adapter. Jim -- Jim Brain, Brain Innovations brain at jbrain.com http://www.jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!

Ethan Dicks wrote: Ahh, the memory mapped mode. I'm afraid I will be of little help. Jim -- Jim Brain, Brain Innovations brain at jbrain.com http://www.jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!

Paul Koning wrote: The IDE command registers are all 8-bits wide, but the Data register is 16 bits wide. You have to support a 16 bit transfer in order to get the data from the sector buffer (256 16 bit transfers nets you 512 bytes of data, the IDE std sector). IN the newer 48 bit addressing mode, the LBA registers grow from 8 bits to 16 bits as well. All the IDE code I've looked at does it this way. I believe I have the ATA r4 spec here that states that as well. But, if you've noted a way to switch IDE into 8-bit mode, let me know. Jim -- Jim Brain, Brain Innovations brain at jbrain.com http://www.jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!

Roger> Rumor has it that Jim Brain may have mentioned these words: It's almost time for 48 bit LBA for flashcards, but not quite yet... Curious. I have some code here that usees 8 bit data buffer accesses on one platform, and 16 bit accesses on another. The one I usually run is the 16 bit case, but last I knew the 8 bit case still worked... paul

This thought crossed my mind many moons ago offline, here it is on-list. If the amount of lost time spent reading offtopic and other time wasting threads is were counted up assume 800 readers, 100 full-time, 700 part time 80+ posts a day, 30,000 a year 1 second to read a header, 10 seconds to skim a post 1/3 of posts off-topic and other then time wasted is 100 x 1/3 x 30,000 x 10 / 3,600 ~= 2,800 +700 x 1/3 x 30,000 x 1 / 3,600 ~= 1,900 = 4,700 = 2 1/3 man-Years wasted In effect, the full-time equivalent of two complete engineers is continuously going wasted. That could amount to *a few* open-CatWeasels, Q-IDE controllers, USB 8" drives or whatever. John A. I don't take this too lightly.

For an IDE interface using a home-grown FS, that is a very valid and often usd approach. With IDE drives in the 100s of GB, and considering the application, it's very workable. For CF, though, as you noted, the loss of sneakernet limits the usefulness. -- Jim Brain brain at jbrain.com

That writeup is a bit misleading. If you wire up the ATASEL line low, you cannot do 8-bit transfers. -- Jim Brain brain at jbrain.com