We all know that ST-506 hard disks are no longer made, and whilst you
can buy working old drives from various sources like EBAY, it would
seem like a much better idea to have some sort of converter that would
allow us to use IDE interface devices.
For example, IDE disks are very cheap, or we could choose to use a
flash memory card connected via an IDE card reader.
So after much Googling here are some potential solutions
a) Howards Super IO controller == S-100 card with IDE interfaces
working with CP/M
http://maben.homeip.net/static/S100/harte%20technologies/cards/Harte%20super%20IO%20controller.pdf
b) MBIUSA's SCSI disk in a box with a ST506 interface out
http://maben.homeip.net/static/S100/disk/mbiusa/ST506%20disk%20emulator%20package.pdf
c) DATEX's flash based ST506 emulator in a half height drive
replacement form
http://maben.homeip.net/static/S100/disk/datastorage.fr/DTX300-ENG2.pdf
Well Datex's product looked great, so I emailed them off for a price.
I optimistically wondered if they could so sale or return. When I
heard the price of 1500 EURO (lets call that 1500 Dollars) I felt
quite faint.
So I checked MBIUSA, their price was 2000 US Dollars
Finally Howards card is only about 500 US dollars. But it does not
have Cromemco Cromix drivers that I need. I want to convert my
recently re-united Cromemco systems from faulty ST506 disk to
something preferably solid state.
So unless I spend at least 1500 Dollars it seems I am going nowhere in
a rush.
So comp.os.cpm, any comments? Are there any other converter cards /
products out there that I have missed. Will a magic Cromix fairy be
able to write some block device drivers?
Any and all answers gratefully received.
marcus.
snip
> So unless I spend at least 1500 Dollars it seems I am going nowhere in
> a rush.
snip
>
> So comp.os.cpm, any comments?
Before the days of integrated parallel controllers on disc drives (SCSI and IDE)
the interface to a disk drive was complicated by the fact that disk interface had
to encode and decode the serial data from the heads. Any emulator for these drives
has to model the circular bit stream (streams in the case of multi-head drives) of
the disk platter and be capable of inserting new sectors on the fly (and writing them
to backing storage), just as the real drive could do.
Then, when you do a seek, you have to fetch the next batch of tracks from backing storage
and repeat the process. You have to maintain multiple streams per head since the head/head
select time was very fast compared to the cyl-cyl time.
The serial data rates are on the order of 10-20MHz for MFM or RLL drives, so all of this
has to be done in something like an FPGA.
This is why (along with relatively low demand) that commercial drive simulators are over a
thousand dollars.
--
Posted via a free Usenet account from http://www.teranews.com
If you are simulating a drive at the drive connector that is true, but
the op wanted a subsystem that he could plug in instead of the drive
controller. A flash drive doesn't need 10-20 mhz serializing of the
data stream. The host adapter is going to feed parallel data to the
cpu or dma controller, from the host adapter to the flash or ide drive
it can stay parallel. There is no reason to slavishly imitate the
characteristics of a physical drive. Let the electronics on an ide
hard drive serialize the data, the data from the ide drive is in just
fine condition (except when you have to do 16 bit to 8 bit conversion
for 16 bit ide). Wasn't there a design that even did away with that by
just masking the upper byte and using the lower 8 bits of every
transfer?
There used to be available a z80 socket piggyback board like the
copower board that offered an ide port, came from somewhere in
Germany.
If you use a CF card they know 8bit mode so it's a trivial interface
to a S100 bus (about 8 peices of ttl glue).
If you use an IDE drive and simply ignore D8-15 it's as simple as the
CF save for you loose half the space (no biggie). FYI: all the
command and status action is done in 8bits D0-7.
>There used to be available a z80 socket piggyback board like the
>copower board that offered an ide port, came from somewhere in
>Germany.
GIDE, Tilmen Reh.
Allison
>Actually this post is going to ask everybody some questions but lets
>present the problem and the partial solution.
>
>We all know that ST-506 hard disks are no longer made, and whilst you
>can buy working old drives from various sources like EBAY, it would
>seem like a much better idea to have some sort of converter that would
>allow us to use IDE interface devices.
>
>For example, IDE disks are very cheap, or we could choose to use a
>flash memory card connected via an IDE card reader.
>
>So after much Googling here are some potential solutions
>
>a) Howards Super IO controller == S-100 card with IDE interfaces
>working with CP/M
>http://maben.homeip.net/static/S100/harte%20technologies/cards/Harte%20super%20IO%20controller.pdf
No longer available. and far more than you need.
>b) MBIUSA's SCSI disk in a box with a ST506 interface out
>http://maben.homeip.net/static/S100/disk/mbiusa/ST506%20disk%20emulator%20package.pdf
>
>c) DATEX's flash based ST506 emulator in a half height drive
>replacement form
>http://maben.homeip.net/static/S100/disk/datastorage.fr/DTX300-ENG2.pdf
>
>Well Datex's product looked great, so I emailed them off for a price.
>I optimistically wondered if they could so sale or return. When I
>heard the price of 1500 EURO (lets call that 1500 Dollars) I felt
>quite faint.
You are paying for a lot of electronics.
>
>So I checked MBIUSA, their price was 2000 US Dollars
>
>Finally Howards card is only about 500 US dollars. But it does not
>have Cromemco Cromix drivers that I need. I want to convert my
>recently re-united Cromemco systems from faulty ST506 disk to
>something preferably solid state.
But you cant buy one.
>So unless I spend at least 1500 Dollars it seems I am going nowhere in
>a rush.
>
>So comp.os.cpm, any comments? Are there any other converter cards /
>products out there that I have missed. Will a magic Cromix fairy be
>able to write some block device drivers?
I'm not sure there are many cromix users out there. IT's also open as
to how much info is available to the potenital cromix block device
driver writer.
Allison
>>c) DATEX's flash based ST506 emulator in a half height drive
>>replacement form
>>http://maben.homeip.net/static/S100/disk/datastorage.fr/DTX300-ENG2.pdf
>>Well Datex's product looked great, so I emailed them off for a price.
>>I optimistically wondered if they could so sale or return. When I
>>heard the price of 1500 EURO (lets call that 1500 Dollars) I felt
>>quite faint.
That sounds about right to me.
> You are paying for a lot of electronics.
Even if it isn't that much electronics, the demand is low, and
it takes some time to design and debug. They probably work a
little to satisfy the original specs. a little closer than
you actually require, too.
Another possibility is to match the S100 interface to the controller
card. IDE pretty much implements the original IBM ISA bus disk
controller interface, though without the address decode logic.
The data bus and a few lines of the address bus go right up the
cable (with a little buffering). If you could match that to the
S100 controller interface, you could do it at that level, instead
of the ST506 interface level.
That may or may not be easier than writing the Chromix driver.
It should take a lot less electronics than the ST506 interface.
-- glen
> Finally Howards [S-100 IDE] card is only about 500 US dollars. But it does not
> have Cromemco Cromix drivers that I need. I want to convert my
> recently re-united Cromemco [Cromix] systems from faulty ST506 disk to
> something preferably solid state.
>
> marcus.
The poster actually asks two questions.
On the one hand, the apparent question is "what can I use to covert an
old hard drive controller which used ST-506 type MFM hard drives, to
use more recent IDE hard drives, or to use Flash-type mass memory?"
That's a pretty tough technical issue. As has been said in reply, a
"converter" of that sort is not common and is expensive when
available. It's a complicated design, not at all easy in hardware, and
may require software changes anyway. It's on a par with "I want to run
my gasoline-type car on diesel. Is there a diesel to gasoline
converter?" Lack of customers, and the complications of design, are
why any available solutions are a few thousand dollars. That's
actually cheap, for the kind of support you'd need to make one of
these work in any running system.
On the other hand, the poster says they want to upgrade a Cromemco-
based, S-100 based system which runs Cromix (a Unix derivative) on an
ST-506 based controller; to use of a S-100 controller which uses IDE
hard drives, or solid state drives. That is a VERY different question,
and the hardware needed amounts to "just" another S-100 card, but more
software changes to Cromix. The benefit is that you'll have a
sustainable result, you'll be able to accomodate larger and a greater
variety of more recent drives, AND you may get performance improvement
(whatever that is worth).
Incidently, most flash memory is not generally appropriate for this
use, because it's generally slow and because in most cases it has
limited write cycles. Put another way, you'll wear out the flash cards
from all the writes you'll do in memory swapping in Unix-like
operating systems They work better for intermittant use and one-write,
many-read applications like cameras, audio players, etc. That said,
there ARE some solid-state hard drive capable technologies out there:
but not likely specific to MFM hard drive replacements. Easy question
to ask, tough to answer, depends on the particulars of use. CP/M
doesn't mind limited write cycles, it runs entirely in RAM!
As for IDE S-100 drive controllers, there are a few around but they
are not cheap. IDE came out just as S-100 was declining, if not after.
There are some IDE add-on designs (GIDE) and a bit of CP/M software
for them, which are Z80 specific. An IDE interface for S-100 is MUCH
easier than an MFM to IDE converter. But someone would have to write
the Cromix drivers and boot to accomodate the different drive, with
different cylinders, sector size, heads. If you have a Cromix system
in operation already, then someone can test an IDE controller and
drive on that system and develop such drivers, if they know how to do
that, if they have the time and interest.
I don't see any other choices. An expensive drive converter to IDE,
which may or may not work 100%; or make or buy an IDE S-100 card and
write some Cromix drivers for it. And I'd stick to hard drives, not
solid state stuff; in any event it's no easier to implement than an
IDE solution.
Herb Johnson
Herbert R. Johnson, New Jersey USA
<a href="http://www.retrotechnology.com/herbs_stuff/"> web site</a>
<a href="http://www.retrotechnology.net/herbs_stuff/"> domain mirror</
a>
my email address: hjohnson AAT retrotechnology DOTT com
if no reply, try in a few days: herbjohnson ATT comcast DOTT net
"Herb's Stuff": old Mac, SGI, 8-inch floppy drives
S-100 IMSAI Altair computers, docs, by "Dr. S-100"
What is failing on the old ST drives? Is it the circuitry or the
actual drive? If it is the drive, can you not replace the mechanical
part with something newer? I don't know too much about how the insides
of hard drives work, but looking at them they all seem to controllers
on the outside that just connect with a ribbon style connector to the
actual drive.
You may need some conversion going from the MFM circuitry to the IDE
mechanics, but it seems it should be possible.
Bill H
(snip)
> What is failing on the old ST drives? Is it the circuitry or the
> actual drive? If it is the drive, can you not replace the mechanical
> part with something newer? I don't know too much about how the insides
> of hard drives work, but looking at them they all seem to controllers
> on the outside that just connect with a ribbon style connector to the
> actual drive.
> You may need some conversion going from the MFM circuitry to the IDE
> mechanics, but it seems it should be possible.
It might be possible for two drives of similar model, but then
they would also be of similar age. That didn't usually happen,
though. AT least in the later years the IDE drives would have
matched a similar RLL model, not the MFM version. That would
also be true for the corresponding SCSI drive. For example,
the ST251N, a 40MB SCSI drive, would not match a 40MB MFM
drive, but might match a 40MB IDE or RLL drive.
-- glen
More information that may be of use:
I found the following information, nothing new but interesting. The
interesting part is the WD 1003 entry, MFM and RLL are WD1003
compatible. Ok now skip down to IDE where it says that the WD1003 is
actually mounted on the hard drive and the the drive itself (not the
IDE adapter on the drive) could be MFM or RLL.
So I would think technally you could isolate the WD1003 portion from
the harddrive and cable right into the HD using your MFM or RLL
controller on your computer.
MFM and RLL
MFM and RLL are actually coding principles for the hard disks. They
are not interface standards. The coding occurs from controller to the
hard disk. As a coding principle, RLL was more effective than was MFM,
so in the "old days" you could experiment using RLL controllers to MFM
disks.
WD 1003
MFM as well as RLL are WD1003 compatible, meaning that the standards
would work with the at that time most widely used controller chip from
Western Digital.
ST 506
ST 506 is an interface, which was used both with RLL and MFM. There is
serial connection from controller to disk. The ST 506 controller
functions as a converter from the serial read/write head data to the 8
or 16 bit parallel bus. ST 506 was the most widespread controller
standard before IDE.
IDE
Integrated Device Electronics. Under the IDE standard, the controller
chip WD 1003 is mounted directly on the hard disk, not on the IDE
adapter. This means that the conversion to parallel data is already
done on the disk. Because of the short serial cable, this increases
the transfer speed significantly relative to MFM and RLL. IDE is a
simple adapter. The adapter itself contains only amplifying circuits
to/from the I/O bus. Therefore it is inexpensive. The IDE controller
does not care whether the hard disk works internally with MFM or RLL
coding.
Bill H
(snip)
> IDE
> Integrated Device Electronics. Under the IDE standard, the controller
> chip WD 1003 is mounted directly on the hard disk, not on the IDE
> adapter. This means that the conversion to parallel data is already
> done on the disk. Because of the short serial cable, this increases
> the transfer speed significantly relative to MFM and RLL. IDE is a
> simple adapter. The adapter itself contains only amplifying circuits
> to/from the I/O bus. Therefore it is inexpensive. The IDE controller
> does not care whether the hard disk works internally with MFM or RLL
> coding.
Or any other coding that one might think of. One reason IDE got
popular was that it allowed drive makers to use better coding,
without requiring the user or software to change. (Until drives
got too big for the register size.) Among others, changing the
number of sectors per track between inner and outer cylinders,
but mapping those back to some constant values.
The IDE cable length is limited because it really is the ISA
bus, at least the data lines.
-- glen
Even if this is true, there could be another way to implement a working
emulation of an old drive. Think about emulating it with a modern PC
(via software), and connect the old computer to that PC's I/O card ...
Regards
Peter
--
My new project: Try http://www.z80.eu for CP/M computer infos.
>> Even if it isn't that much electronics, the demand is low, and
>> it takes some time to design and debug. They probably work a
>> little to satisfy the original specs. a little closer than
>> you actually require, too.
>> Another possibility is [...]
> Even if this is true, there could be another way to implement a working
> emulation of an old drive. Think about emulating it with a modern PC
> (via software), and connect the old computer to that PC's I/O card ...
It might be possible. I believe the data rate is 5Mb/s, which would
require a 10MHz sampling rate, and 10MHz D/A on the output to send back.
(Actually, the signals only have two levels, so A/D and D/A is a little
more than should be needed.)
Reading would be somewhat easier than writing, the PC has to generate
the data waveform, but only needs to detect the slow seek pulses.
It might be that off the shelf PC hardware, such as A/D and D/A boards,
and the appropriate software could do it.
-- glen
Lars
[snip]
> In my case the conversion was easy because the ST506
> was controlled by the Western Digital WD1003 attached to the back of
> the drive. It provided a simple 8 bit parallel interface to the host
> computer. This in fact was an 8 bit version of the IDE standard (not
> surprising since Western Digital was one of the main authors of the
> IDE spec!!!). The GIDE interface converts the 16 bit IDE to an 8 bit
> interface and the drive address is completely user selectable, so I
> was able to make it the same as the interface to the WD1003.
Your fix is interesting to hear about. I strongly suggest you contact
Tilmann Reh, or the German computer club which is/was offering the
GIDE. Give them more info about what you did. They will make that info
available to others. Or give the info to me, and I'll pass it along.
(I was first to sell the GIDE in the USA, that's why I'm asking.).
Very few buyers of the GIDE have provided software or results in
return.
I know about Cromemco hardware. It's highly likely he is using a
Cromemco STDC card, or a Cromemco WD-II card: the person posting can
reply to this. Either way, these are S-100 cards which implement a MFM
disk controller on the S-100 bus They are not parallel interfaces to
an external SCSI to MFM, or external SASI to MFM, card like the
Western Digital WD 1003 or similar cards. Information about the STDC
and WD II are available in the Cromemco manuals, and those are
available on some Web sites if you search appropriately.
> If you don't have a WD1003 and you still want to use CROMIX, you
> options it appears are expensive. I might suggest that you consider
> using an operating system that you can get the source code for and
> have the ablitiy to write drivers. I would suggest switching to ZSDOS....
>
> Lars
If he wants to run CROMIX, or recover files from Cromix, changing the
OS won't help. There is nothing wrong with wanting to run CROMX on
newer hardware. To be brief about it, all this stuff was DESIGNED to
be upgraded.
>Lets see if I understand the problem. You have an ST506 on a Cromemco
>computer running CROMIX. The ST506 is becoming unreliable and you
>want to upgrade to IDE drives and you still want to run CROMIX.
>Problem is you don't have the ability to write an IDE driver for
>CROMIX.
>BTW I have a homebrew Z80 that had an ST506 attached. Like you the
>drive started getting bad sectors that I had to map as bad and soon I
>had lost 2 MB of disk space. I replaced the ST506 with an IDE drive.
>To do this I purchased the GIDE interface offered by the KC computer
>club in Germany. This interface in in the form of a daughter card
>that plugs into the Z80 socket on the CPU board. I think is cost
>about $45 US. In my case the conversion was easy because the ST506
>was controlled by the Western Digital WD1003 attached to the back of
>the drive. It provided a simple 8 bit parallel interface to the host
>computer. This in fact was an 8 bit version of the IDE standard (not
>surprising since Western Digital was one of the main authors of the
>IDE spec!!!). The GIDE interface converts the 16 bit IDE to an 8 bit
>interface and the drive address is completely user selectable, so I
>was able to make it the same as the interface to the WD1003. It
>turned out all the commands were identical between the WD1003 and
>IDE. I only needed to change one bit in the BIOS to get the GIDE to
>work because the WD1003 numbered sectors from 0 while the IDE starts
Humm, I have at least three woking WD1003s and they are 16bit ISA.
Specifially BOTH IDE and WD1003 use a 16bit data path and an 8bit
control/status path. They are from the bus side essentially the same
as a IDE drive in signals required however.
I wrote an article for TCJ eons ago about using the WD1002S- W2XA
(PC-XT 8bit ISA) controller as a component for putting HD on 8bit
systems. The board is similar but not the same as the WD1003
which is the prototypical IDE command set and interface.
Now if you designed and interface to use a 1003 for an 8bitter (byte
swaping) teh interface should drive an IDE directly.
However, This is not the case with the user of a S100 based Cromix
system. He's using an integrated controller not unlike Teltek, Konan
or Compupro Disk3. There were others that were similar though none
were the same.
Allison
Marcus, this is similar to the issue I encountered when I bought my first
IMSAI. The drives were dead and I realized that all things mechanical will
fail if given enough time. So I ruled out upgrading to a newer drive.
Instead I built an S-100 Flash ram card and wrote the software to load/save
files. That was my first step, more of an experiment really. I use my PC
as a terminal and I also realized that technology changes and it would be
best to simply have a fast connection with my PC and let the PC companies
handle the new interfaces as the come out. So I built a high speed
bidirectional parallel interface. I wrote assembly software for both ends
that traps a specified CPM drive designator and routes it out to the
parallel lines that in turn are routed to a specified drive on the PC side.
I can read/write files to floppies, my hard drive, read files from a CD, and
even read/write from from my USB keychain jump drive. It's all easy because
the drivers are built into the PC and all you have to do is interface with
the PC. Once you're there, you can do anything. I can't handle subdirs
yet, as CPM doesn't support them. The config file on the PC side contains
the mapping of CPM drives to drive/paths on the PC, so technically you can
read/write to subdirs, you just can't change them on the fly from CPM.
Hope this helps.
-J
I plead ignorance when it comes to Cromemco hardware. At one time I
know that there was a fanatical following for all things Cromemco in
the 80's especially in the Bay area. Perhaps someone out there has
the details for writing CROMIX drivers. In that case using the GIDE
interface and CROMIX is a managable and inexpensive project and would
only require a bit of coding and getting a GIDE board
Lars.
(snip)
> This in fact was an 8 bit version of the IDE standard (not
> surprising since Western Digital was one of the main authors of the
> IDE spec!!!).
Well, IDE is pretty much the PC/AT disk controller moved
into the drive. Since WD made PC/AT disk controller board and
disk controller chips, it isn't too surprising.
> The GIDE interface converts the 16 bit IDE to an 8 bit
> interface and the drive address is completely user selectable, so I
> was able to make it the same as the interface to the WD1003. It
> turned out all the commands were identical between the WD1003 and
> IDE. I only needed to change one bit in the BIOS to get the GIDE to
> work because the WD1003 numbered sectors from 0 while the IDE starts
> at 1.
Hmm, that is interesting.
> If you are so lucky as to have a WD1003 attached to your ST506 you can
> probably do the whole conversion to IDE for under $100 US plus a
> couple of weekends of you time with a debugger to find the bits you
> need to change. You also need to have some code that executes at boot
> time to set the geometry of your IDE drive to match the ST506 for this
> to work. Thus you will be limitied to 10 MB even if the IDE drive is
> bigger.
Other than the sector numbering, the conversion should be
pretty easy. Not so much hardware required.
I thought I once knew that IDE would do 8 bit transfers,
but I haven't thought about that for a while now. That would
have been needed for XT compatibility.
-- glen
In addition to the GIDE interface, you may want to check
archives of this group from March of 2003 re. XTIDE.
>Sorry about any misunderstandings - the controller card I used was a
>WD1002-05 not a WD1003. My memory just isn't as good as it used to
>be. The WD1002-05 had the footprint of a 5 1/4" drive and could
>control 3 MFM harddrives and 4 floppy drives. It interfaced to the
>host computer through an 8 bit parallel interface using a 40 conductor
>ribbon cable. The interface (aside from being 8 bit rather than 16
>bit) was 95% compatible with IDE (commands and status in IDE are only
>8 bit). Besides numbering sectors differently, some of the bits in
>the status words were different but those bits were not used by the
>ST506 software, so the change over to IDE was very simple. In my case
>the board was mounted to the bottom of the harddrive.
thats was what used to be called a host interface, part numbers like
1001-HDO and others like it.
The command set was defined by the wich controller chipset was used
WD had two, one was 8bit bus the other was 16bit. Commands between
the two wer 90% the same.
>I plead ignorance when it comes to Cromemco hardware. At one time I
>know that there was a fanatical following for all things Cromemco in
>the 80's especially in the Bay area. Perhaps someone out there has
>the details for writing CROMIX drivers. In that case using the GIDE
>interface and CROMIX is a managable and inexpensive project and would
>only require a bit of coding and getting a GIDE board
>
>Lars.
Cromemco was a very well done S100 system than had multiple CPU
choices. I believe Z80, 68000 and 8088 were amoung them.
Allison
IDE specification has 8bit transfer in it. However other than some
small (laptop) and a few oddball drives it was generally not
implemented. CF however does implement it.
Allison
Funny I implemented a similar thing using Eproms and
built in programmer over two decades ago and several times since.
I've also used flashram/EEproms and ti works well.
> That was my first step, more of an experiment really. I use my PC
>as a terminal and I also realized that technology changes and it would be
>best to simply have a fast connection with my PC and let the PC companies
>handle the new interfaces as the come out. So I built a high speed
>bidirectional parallel interface. I wrote assembly software for both ends
>that traps a specified CPM drive designator and routes it out to the
>parallel lines that in turn are routed to a specified drive on the PC side.
>I can read/write files to floppies, my hard drive, read files from a CD, and
>even read/write from from my USB keychain jump drive. It's all easy because
>the drivers are built into the PC and all you have to do is interface with
>the PC. Once you're there, you can do anything. I can't handle subdirs
>yet, as CPM doesn't support them. The config file on the PC side contains
>the mapping of CPM drives to drive/paths on the PC, so technically you can
>read/write to subdirs, you just can't change them on the fly from CPM.
CP/M is easy as the calls and the tables are exposed even if you do
not have the BIOS source. I've been doing container files on host
systems as well.
The real problem here is not the drive or the potential substitute but
the OS and the file device driver. I don't know if Cromix has the
same level of documentation as CP/M provided.
Allison
>
>Hope this helps.
>
>-J
>
> IDE specification has 8bit transfer in it. However other than some
> small (laptop) and a few oddball drives it was generally not
> implemented. CF however does implement it.
Maybe in the early days when 8088 machines were still around.
If CF does it, that should help. How about PCMCIA disks? (Though
I don't believe I ever saw one.)
-- glen
>no....@no.uce.bellatlantic.net wrote:
>(snip)
>
>> IDE specification has 8bit transfer in it. However other than some
>> small (laptop) and a few oddball drives it was generally not
>> implemented. CF however does implement it.
The writes are slow and limited in number.
>Maybe in the early days when 8088 machines were still around.
Thats where a lot of my sub 40mb drives came from. Most had adaptor
cards that did the byte translation.
>If CF does it, that should help. How about PCMCIA disks? (Though
>I don't believe I ever saw one.)
There were PCMCIA disks but I've never had the cance to use one.
Allison
>>>IDE specification has 8bit transfer in it. However other than some
>>>small (laptop) and a few oddball drives it was generally not
>>>implemented. CF however does implement it.
(and)
> The writes are slow and limited in number.
My understanding is that the Flash File System is
designed to spread the writes around, such that blocks
are used somewhat evenly. Normally a directory block would
be written very often, and a file block much less often.
The device driver would have to implement that, and most likely
CP/M and Cromix don't.
But if I remember it, the number isn't that small, maybe 10000,
and it would last quite a while on such a system. Small CF
cards are pretty cheap now. I bought a 1GB card for about $15,
smaller ones should be even less.
-- glen
CF cards have a built-in microcontroller that does wear levelling for you, so
you don't have to worry about it. (Specifically because they're pretending to
be hard disks, that don't suffer from this issue.)
I'm pretty sure SD cards do this too (but I can't find any references right
now). SD cards also support an SPI interface, which out to be relatively
trivial to hook up to a low-end processor...
--
┌── dg@cowlark.com ─── http://www.cowlark.com ───────────────────
│ "Feminism encourages women to leave their husbands, kill their children,
│ practice withcraft, destroy capitalism and become lesbians." --- Rev. Pat
│ Robertson
>no....@no.uce.bellatlantic.net wrote:
>(snip)
>
>>>>IDE specification has 8bit transfer in it. However other than some
>>>>small (laptop) and a few oddball drives it was generally not
>>>>implemented. CF however does implement it.
>(and)
>
>> The writes are slow and limited in number.
>
>My understanding is that the Flash File System is
>designed to spread the writes around, such that blocks
>are used somewhat evenly. Normally a directory block would
>be written very often, and a file block much less often.
>The device driver would have to implement that, and most likely
>CP/M and Cromix don't.
can't speak for cromix but CP/M does not. Also when writing to a disk
CP/M hits the directory block the most (read and write) as thats where
Allocation info is stored.
>But if I remember it, the number isn't that small, maybe 10000,
>and it would last quite a while on such a system. Small CF
>cards are pretty cheap now. I bought a 1GB card for about $15,
>smaller ones should be even less.
Actually believe it's more like 100,000 write theses days.
Allison
The first is correct, the second isn't. All that load leveling is done
internally, just as you are not told and need not care what the real
number of sectors and cylinders is inside an IDE drive.
<snip>
> >> So unless I spend at least 1500 Dollars it seems I am going nowhere in
> >> a rush.
>
> >> So comp.os.cpm, any comments? Are there any other converter cards /
> >> products out there that I have missed. Will a magic Cromix fairy be
> >> able to write some block device drivers?
<snip>>
> CP/M is easy as the calls and the tables are exposed even if you do
> not have the BIOS source. I've been doing container files on host
> systems as well.
>
> The real problem here is not the drive or the potential substitute but
> the OS and the file device driver. I don't know if Cromix has the
> same level of documentation as CP/M provided.
>
> Allison
>
> >Hope this helps.
------------------
Driver Manuals were available from Cromemco for Cromix, Cromix+ and
UNIX.
mike
First a Big thanks to all for replying. Allison (last post). You
are my hero. Now did you write up /document your design.
Actually for me though it wont totally help, because as I said at the
top of the post I dont really have access to the Cromix
Block driver sources, I dont think they were ever sold (though the
Character IO and SMD disk drivers were I think).
Anyway, I have done more research ...
Looks like a number of people are working on
a) floppy drive emulators in solid state
b) Piggy back boards
My website is now suitably updated
http://maben.homeip.net/static/S100/disk/index.html
In particular I have got hold of a Z80 piggyback device whereby you
remove your Z80 and put it onto the piggyback board that will then
plug
into (I hope) my Z80 CPU card. The piggyback contains some
electronics and a SD slot which is accessible by port IO out / in
instrucions.
SO: my cunning plan would be
a) install the card in a Z80 only cromemco CPU
b) cross fingers that it works
c) write a small assembler program to read any file and output it byte
by byte onto the flash card
d) find a utility that can read the card on my PC as a byte stream
this would at least enable data transfer if not disk emulation.
On the cromemco I would hope to be able to ftar up complete
directories and so I would be saving just 1 unix compatible
tar file which would then be sort of easier to unpack.
Thats the rough idea, of course I have no time to implement it just
yet, but one day.
The lack of time is why I stil l prefer a turnkey solution and not at
an outrageous price!
Lastly if anybody will or can provide same just think what a new
generation of quiet S-100
systems we could breed. My current test system is sort of noisy on its
own, but when those
hard drives are started (complete with large hurricane style cooling
fan) it gets rather noisy.
Solid state would eliminate all of that.