A new S-100 Prototype board to interface with IDE hard disk drives and CF cards
monahanz
allows one to interface with standard IDE hard disks. Since the old
ST-506 type drives are getting hard to find these days (and the ones
we have are often on their last legs), I felt it would be useful to be
able to use the abundant supply of IDE drives. They are more reliable
and quieter too. Also because there are now many simple IDE to
Compact Flash converter cards I incorporated this on the board as
well. So I can boot CPM3 quickly and silently on my system without a
floppy etc.
The board uses a simple 8255 three port IO chip to interface to the
IDE socket. The board uses only 4 I/O ports. The design is based on
earlier work of others.
I have posted a description of all this on www.S100Computers.com at:-
http://s100computers.com/My%20System%20Pages/IDE%20Board/My%20IDE%20Card.htm
I have included a simple test program (with source) to read, write
sectors and diagnostics for any drive.
I have included a simple CPM3 BIOS driver (with source) so those that
know CPM3 and want to quickly get a system up and going.
I have also include a simple program to write the CPM3 boot sectors
to a drive/card as well as a simple CPM3 boot loader.
Later I will try and write a step by step account of bringing CPM3 up
on Flash cards like this but what is there should be able to get
veterans going.
Andrew Lynch (at N8VEM) see (http://n8vem-sbc.pbworks.com/) and I, are
in the process of having a few commercial quality S-100 cards made for
ourselves. If others are interested in obtaining a bare card, let
Andrew or I know. Please note these would be bare cards, a schematic
and that’s it. Building the board and implementing CPM etc., you are
on your own. This is not a project for first timers.
Rolf Harrmann
On Fri, 6 Nov 2009 11:16:38 -0800 (PST), monahanz wrote:
>I have posted a description of all this on www.S100Computers.com at:-
>http://s100computers.com/My%20System%20Pages/IDE%20Board/My%20IDE%20Card.htm
thanks for your Info.
Rolf
All...@localhost.net
It's almost easier to interface IDE/CF to S100 without 8255. It saves
a 40 pin chip and also requires less bit twiddling as all either IDE
or CF is is a series of registers. Having been through the exercise
the more direct interface has a much faster IO rate.
Also CF can do 8bit (rather than 16bit) IO and that also makes the
interface dirt simple for CF only and the result is very fast and easy
build using a few TTL to decode block address, io read and write
plus buffering the split bus to the common IO bus of the CF.
Allison
monahanz
> On Fri, 6 Nov 2009 11:16:38 -0800 (PST), monahanz
>
>
>
>
>
> <mona...@vitasoft.org> wrote:
> >Over the past two weeks I put together an S-100 prototype card that
> >allows one to interface with standard IDE hard disks. Since the old
> >ST-506 type drives are getting hard to find these days (and the ones
> >we have are often on their last legs), I felt it would be useful to be
> >able to use the abundant supply of IDE drives. They are more reliable
> >and quieter too. Also because there are now many simple IDE to
> >Compact Flash converter cards I incorporated this on the board as
> >well. So I can boot CPM3 quickly and silently on my system without a
> >floppy etc.
>
> >The board uses a simple 8255 three port IO chip to interface to the
> >IDE socket. The board uses only 4 I/O ports. The design is based on
> >earlier work of others.
>
> >I have posted a description of all this onwww.S100Computers.comat:-
>
> >I have included a simple test program (with source) to read, write
> >sectors and diagnostics for any drive.
> >I have included a simple CPM3 BIOS driver (with source) so those that
> >know CPM3 and want to quickly get a system up and going.
>
> >I have also include a simple program to write the CPM3 boot sectors
> >to a drive/card as well as a simple CPM3 boot loader.
>
> >Later I will try and write a step by step account of bringing CPM3 up
> >on Flash cards like this but what is there should be able to get
> >veterans going.
>
> >Andrew Lynch (at N8VEM) see (http://n8vem-sbc.pbworks.com/) and I, are
> >in the process of having a few commercial quality S-100 cards made for
> >ourselves. If others are interested in obtaining a bare card, let
> >Andrew or I know. Please note these would be bare cards, a schematic
> >and that’s it. Building the board and implementing CPM etc., you are
> >on your own. This is not a project for first timers.
>
> It's almost easier to interface IDE/CF to S100 without 8255. It saves
> a 40 pin chip and also requires less bit twiddling as all either IDE
> or CF is is a series of registers. Having been through the exercise
> the more direct interface has a much faster IO rate.
>
> Also CF can do 8bit (rather than 16bit) IO and that also makes the
> interface dirt simple for CF only and the result is very fast and easy
> build using a few TTL to decode block address, io read and write
> plus buffering the split bus to the common IO bus of the CF.
>
>
> - Show quoted text -
Allison I considered a straight 7400's IC chip layout and while most
of the IDE commands are 8 bits the actual sector data is sent/read as
16 bits and so will have to be latched on each read/write. Others
have done it without a 8255 type chip such as here:-
http://www.retroleum.co.uk/electronics-articles/an-8-bit-ide-interface/
There are a number of ways to skin that cat!
Alternatively you can really keep it real simple and just waste the
upper 8 bits of sector data and read in 2x512 byte sectors. Since the
IDE allows multiple sector reads the software overhead would probably
not be that bad. I just have not had the time to count clock cycles
etc.
I just opted for an 8255 approach because I knew the chip well. Is
there faster, probably yes, but I can tell you my running CPM3 here
right now is night and day different from an old ST-506 not to mention
a floppy!
Thanks for the suggestion however.
John
Barry Watzman
it was pure 8-bit. Most CP/M systems (and S-100 systems) do not use
extended addressing.
> and that�s it. Building the board and implementing CPM etc., you are
monahanz
> Very interesting and potentially useful, but it would be more useful if
> it was pure 8-bit. Most CP/M systems (and S-100 systems) do not use
> extended addressing.
>
>
>
> monahanz wrote:
> > Over the past two weeks I put together an S-100 prototype card that
> > allows one to interface with standard IDE hard disks. Since the old
> > ST-506 type drives are getting hard to find these days (and the ones
> > we have are often on their last legs), I felt it would be useful to be
> > able to use the abundant supply of IDE drives. They are more reliable
> > and quieter too. Also because there are now many simple IDE to
> > Compact Flash converter cards I incorporated this on the board as
> > well. So I can boot CPM3 quickly and silently on my system without a
> > floppy etc.
>
> > The board uses a simple 8255 three port IO chip to interface to the
> > IDE socket. The board uses only 4 I/O ports. The design is based on
> > earlier work of others.
>
> > I have posted a description of all this onwww.S100Computers.comat:-
>
> > I have included a simple test program (with source) to read, write
> > sectors and diagnostics for any drive.
> > I have included a simple CPM3 BIOS driver (with source) so those that
> > know CPM3 and want to quickly get a system up and going.
>
> > I have also include a simple program to write the CPM3 boot sectors
> > to a drive/card as well as a simple CPM3 boot loader.
>
> > Later I will try and write a step by step account of bringing CPM3 up
> > on Flash cards like this but what is there should be able to get
> > veterans going.
>
> > Andrew Lynch (at N8VEM) see (http://n8vem-sbc.pbworks.com/) and I, are
> > in the process of having a few commercial quality S-100 cards made for
> > ourselves. If others are interested in obtaining a bare card, let
> > Andrew or I know. Please note these would be bare cards, a schematic
> > on your own. This is not a project for first timers.- Hide quoted text -
>
> - Show quoted text -
Barry I did not mean the actual data from the ports need to be 16 bits
wide (ie IEEE-696 SIXTN low etc) what I ment to say was the address
of the ports utilize both the upper and lower address lines. So you
can use any old CPU with the card by setting the port switches to
00xxH. I have it so that if anybody wanted to use say an 8086 with
DOS, they counld use a port like 02F0H (or something like that which
was used in the old PC's -- forgot the exact ports block!). Sorry for
the confusion.
I am currently using the board with a standard Intersystems Z80 System-
II board.
David Knoll
> Barry I did not mean the actual data from the ports need to be 16 bits
> wide (ie IEEE-696 SIXTN low etc) what I ment to say was the address
> of the ports utilize both the upper and lower address lines. So you
> can use any old CPU with the card by setting the port switches to
> 00xxH. I have it so that if anybody wanted to use say an 8086 with
> DOS, they counld use a port like 02F0H (or something like that which
> was used in the old PC's -- forgot the exact ports block!). Sorry for
> the confusion.
> I am currently using the board with a standard Intersystems Z80 System-
> II board.
I think the concern was to do with the differing behaviour of the x80
processors with regard to A8-15 when asserting an I/O address. According
to the datasheets I have:
- 8080/8085: A8-15 repeats A0-7
- Z80/Z180 using IN A,(n)/OUT (n),A: A8-15 carries the contents of A
- Z80/Z180 using IN r,(C)/OUT (C),r: A8-15 carries the contents of B
- Z180 using IN0/OUT0: A8-15 are zero
--
David Knoll
Anti-spam: Change 'news' to 'david' for my real address.
monahanz
Good point David, I'll set it so with a jumper only 8 (bits are read)
as an option.
All...@localhost.net
<mon...@vitasoft.org> wrote:
>On Nov 6, 12:59�pm, Alli...@localhost.net wrote:
>> On Fri, 6 Nov 2009 11:16:38 -0800 (PST), monahanz
>>
>>
>>
>>
>>
>> It's almost easier to interface IDE/CF to S100 without 8255. �It saves
>> a 40 pin chip and also requires less bit twiddling as all either IDE
>> or CF is is a series of registers. �Having been through the exercise
>> the more direct interface has a much faster IO rate.
>>
>> Also CF can do 8bit (rather than 16bit) IO and that also makes the
>> interface dirt simple for CF only and the result is very fast and easy
>> build using a few TTL to decode block address, io read and write
>> plus buffering the split bus to the common IO bus of the CF.
>>
>> Allison- Hide quoted text -
>>
>> - Show quoted text -
>
>Allison I considered a straight 7400's IC chip layout and while most
>of the IDE commands are 8 bits the actual sector data is sent/read as
>16 bits and so will have to be latched on each read/write. Others
>have done it without a 8255 type chip such as here:-
>http://www.retroleum.co.uk/electronics-articles/an-8-bit-ide-interface/
I am familiar, I tried it and it was about 3x slower for PIO transfers
due to the extra but twiddling.
>There are a number of ways to skin that cat!
>
>Alternatively you can really keep it real simple and just waste the
>upper 8 bits of sector data and read in 2x512 byte sectors. Since the
>IDE allows multiple sector reads the software overhead would probably
>not be that bad. I just have not had the time to count clock cycles
>etc.
I have tried that. The overhead is zero as the command allows for
number of sectors to read. The cost is tossing half the storage
but even small drives are bigger than needed.
>I just opted for an 8255 approach because I knew the chip well. Is
>there faster, probably yes, but I can tell you my running CPM3 here
>right now is night and day different from an old ST-506 not to mention
>a floppy!
Big time better. IDE compared to my Teletek board and quantum D540
31mb drives is far faster, quieter and cooler. Going to CF was the
next and easiest step as it eliminated the 8-16bit transfer problem.
The CF parts are easier as transfers can be done as 8bit (it's a mode
bit) and being both smaller and lower power is convenient.
Performance for both CP/M2 and 3 are much better and the old floppy
space issues are no longer an issue.
The last s100 board I did was to have a CF, 2 serial ports and boot
rom on one board as that reduces the whole system to CPU, RAM and the
disk/IO card. Since I can get 32 to 128mb CF cards both easily and
cheap the side effect is all those 500mb and smaller IDE drives I've
saved up are unused and I have a boatload of them.
>Thanks for the suggestion however.
I figured it would save the cost of the LSI, though they are still
easy to get.
Allison
>John
All...@localhost.net
Then youhave S100 Z80 board that by option emulate 8080 IO addressing
(echo A0-7 to a8-15). Most S100 boards do that though having said
that a comprehensive list of those that don't will appear. Its
definately a situation that requires an integrators attention or all
mannor of errors appear.
Allison
lynchaj
Hi Allison! Thanks! Do you have the schematics for your CF, dual
serial, boot ROM combination board? May I use them to build an N8VEM
S-100 board? That sounds like a really useful board for S-100 home
brew builders.
Thanks and have a nice day!
Andrew Lynch
monahanz
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Not to labor the point Allison, but what I was thinking of was there
has to be some kind of time hit with the drive reading contiguous two
sectors instead of one. Admittedly you could do a block port input
(INDR) if you have a Z80, of both sets of 512 bytes but would the head
read times be grater than or less than the CPU hit time of reading
lower and upper 8 bits from two ports.
I suppose if I had to, and in a perfect world one would latch in the
upper 8 bits to a small onboard RAM chip, and after block inputting
(INDR) the lower 8 bits then do the same from the local stored RAM.
DMA is another option of course but I would be scared to try that
since I have multiple (8 & 16 bit) master/slave CPU on my system.
monahanz
>
> - Show quoted text -
Allison one further point. By CF card do you mean Compact Flash card.
If so that is what I am using here. The current layout has an IDE set
of connectors that allow you to insert a small IDE to CF card adaptor
board. The are very common, cost $8 from Newegg and at the same time
allows oone to yae a cable for an "old fashioned' calssical IDE
drive. Andrew and I considered adding a CF connector directly to the
board but the pins are real close and probably woukd require surface
mount soldering skills. The adaptor card already does this and costs
about what a bare CF connector would cost.
glen herrmannsfeldt
(big snip)
> Not to labor the point Allison, but what I was thinking of was there
> has to be some kind of time hit with the drive reading contiguous two
> sectors instead of one. Admittedly you could do a block port input
> (INDR) if you have a Z80, of both sets of 512 bytes but would the head
> read times be grater than or less than the CPU hit time of reading
> lower and upper 8 bits from two ports.
I believe it is usual for the drive to buffer the whole track,
maybe even the whole cylinder. It seeks to the appropriate
track and starts reading, even if it isn't yet the desired sector.
After one revolution, it will have the whole track, but not in
the original order. When the desired track has been read, it
is supplied to the host. The rest of the sectors are available
when needed.
-- glen
glen herrmannsfeldt
> If so that is what I am using here. The current layout has an IDE set
> of connectors that allow you to insert a small IDE to CF card adaptor
> board. The are very common, cost $8 from Newegg and at the same time
> allows oone to yae a cable for an "old fashioned' calssical IDE
> drive. Andrew and I considered adding a CF connector directly to the
> board but the pins are real close and probably woukd require surface
> mount soldering skills. The adaptor card already does this and costs
> about what a bare CF connector would cost.
The CF interface is very similar to the IDE interface.
IDE is supposed to allow 8 bit transfers, but it seems that
most drives forgot to implement that part. As I understand it,
it is part of CF and CF cards to reliably implement it.
If you want to transfer all the bytes from an IDE drive, you
have to latch the high byte somewhere and then read it later.
With CF, just read bytes one at a time.
-- glen
All...@localhost.net
wrote:
>On Nov 7, 9:29�am, Alli...@localhost.net wrote:
>> On Fri, 6 Nov 2009 13:18:37 -0800 (PST), monahanz
>Hi Allison! Thanks! Do you have the schematics for your CF, dual
>serial, boot ROM combination board? May I use them to build an N8VEM
>S-100 board? That sounds like a really useful board for S-100 home
>brew builders.
Sorry not that version. It was built to support a commercial user
(process control) and they own the design. I plan to work up a
similar but not same when (non paying) time permits.
However you have the core ideas if you don't use an 8255 for the
interface. Serial is a Z80 SIO and rom with disable bit is no new
idea.
Allison
All...@localhost.net
<mon...@vitasoft.org> wrote:
>
>Not to labor the point Allison, but what I was thinking of was there
>has to be some kind of time hit with the drive reading contiguous two
>sectors instead of one. Admittedly you could do a block port input
At 5400 rpm not enough to be significant.
>(INDR) if you have a Z80, of both sets of 512 bytes but would the head
>read times be grater than or less than the CPU hit time of reading
>lower and upper 8 bits from two ports.
the real time consumed is the PIO loop to read the disk then the
LDIR from buffer to DMA address after deblocking is done.
>I suppose if I had to, and in a perfect world one would latch in the
>upper 8 bits to a small onboard RAM chip, and after block inputting
>(INDR) the lower 8 bits then do the same from the local stored RAM.
>DMA is another option of course but I would be scared to try that
>since I have multiple (8 & 16 bit) master/slave CPU on my system.
Not needed. arrange two latches so they are read/written
sequentially. GIDE did that in trivial amout of logic, so small
it was put in a small PAL. There are discrete designs as well.
Like I said though CF has a 8bit wide mode (memory mode)
that makes the interface trivial.
Allison
All...@localhost.net
Yes most IDE HD (at elast the larger ones) buffer for the read ahead
and implment a LRU strategy for old cache retention. That allows
one sector to be read and likely Nmany sectors are waiting in the
buffer (varies from 32k old drives to as large as 16mb in newer
drives) so that the next read is likely the nest sector and a seek
will not be needed. It's invisible to the programmer.
Allison
All...@localhost.net
When I fould out that was the case I switched to CF over IDE
as the interface is trivial. Using a CF to IDE adaptor make the
mechanical interface wirewrapable for normal humans.
Allison
All...@localhost.net
<mon...@vitasoft.org> wrote:
>On Nov 7, 10:20�am, monahanz <mona...@vitasoft.org> wrote:
>> On Nov 7, 6:29�am, Alli...@localhost.net wrote:
>>
>> > >> Also CF can do 8bit (rather than 16bit) IO and that also makes the
>> > >> interface dirt simple for CF only and the result is very fast and easy
>> > >> build using a few TTL to decode block address, io read and write
>> > >> plus buffering the split bus to the common IO bus of the CF.
>>
>> > - Show quoted text -
>>
>Allison one further point. By CF card do you mean Compact Flash card.
>If so that is what I am using here. The current layout has an IDE set
>of connectors that allow you to insert a small IDE to CF card adaptor
>board. The are very common, cost $8 from Newegg and at the same time
>allows oone to yae a cable for an "old fashioned' clssical IDE
>drive. Andrew and I considered adding a CF connector directly to the
>board but the pins are real close and probably woukd require surface
>mount soldering skills. The adaptor card already does this and costs
>about what a bare CF connector would cost.
The CF -> IDE adaptors are just pinout adaptors. I ahve a box load
to make it easier to use CF as I can wire wrap a 40pin header (.100
spacing) but not CF connectors. However the interface to the CF does
not use the D8-D15) pins and when I command it I only use the lower
8bits (still 512 sectors) as the CF supports that and most IDE HD do
not.
Granted doing it your way allows most any IDE drive but one 64MB
CF mounted on the S100 card is easer to power, dead silent, fast and
runs cold. IDE drive still requires power (some need +5 and +12) and
not as easy to put right on a S100 card. Also with CF I can use an
USB to multi-memory card adaptor and program the initial system from
my linux box. For many that would solve the chicken and egg issue
of a first time system boot.
Allison
monahanz
Glen that's interesting, I did not know that. Could you explain more?
Normally for an IDE drive the sector data is sent out as 16 bits wide.
When I read from a CF card (via the IDE->CF adaptor board) it’s the
same way. Unfortunately I don’t have a schematic for these plug-in $8
boards.
To get the CF card specification apparently it costs $100! See
http://www.compactflash.org/
So is there a way to output a command to a CF card so that it provides
the all 512 bytes sequentially on just the lower 8 bits, (i.e. two Z80
LDIR instructions could be used).
monahanz
> On Sat, 7 Nov 2009 10:29:32 -0800 (PST), monahanz
>
>
>
>
>
>
Glen that's interesting, I did not know that. Could you explain more?
Ole Christensen
> Unfortunately I don’t have a schematic for these plug-in $8
> boards. To get the CF card specification apparently it costs $100! See
> http://www.compactflash.org/
Try Google with: "OEMCFlashPMv12.0"
<ole>
glen herrmannsfeldt
>> Unfortunately I don?t have a schematic for these plug-in $8
>> boards. To get the CF card specification apparently it costs $100! See
>> http://www.compactflash.org/
> Try Google with: "OEMCFlashPMv12.0"
There is also useful information at:
http://www.allpinouts.org/index.php?title=CompactFlash
-- glen
All...@localhost.net
There isn't much on the board a VOM can't discover. All the boards I
have only have a voltage regulator to run the CF at 3.3V and activity
leds. There is no intelligence, buffering or any fancy pinswapping.
>To get the CF card specification apparently it costs $100! See
>http://www.compactflash.org/
There is plenty of free data elsewhere.
>
>So is there a way to output a command to a CF card so that it provides
>the all 512 bytes sequentially on just the lower 8 bits, (i.e. two Z80
>LDIR instructions could be used).
Yes.
For IDE without 8255 see
http://www.hanssummers.com/computers/cpcng/ide/
Han's does a great job of illustrating how it's done.
Then look at http://piters.tripod.com/zxcf.htm granted it's for a ZX
but thats Z80 and you only need S100 bus translation. It's really
trivial.
Hope that helps you simplify or at least capitalize on the CF
ease of interface.
Allison
glen herrmannsfeldt
>>To get the CF card specification apparently it costs $100! See
>>http://www.compactflash.org/
> There is plenty of free data elsewhere.
Such as: http://www.compactflash.org/cfspc4_1.pdf
-- glen
Steven Hirsch
> monahanz wrote:
>
>> Unfortunately I don�t have a schematic for these plug-in $8
>> boards. To get the CF card specification apparently it costs $100! See
>> http://www.compactflash.org/
>
> Try Google with: "OEMCFlashPMv12.0"
All links dead...
Steven Hirsch
Gone: 404
Would someone who managed to grab this or the currently non-existent spec from
Sandisk please mail it to me as an attachment?
TIA!
Steve
Ole Christensen
> Ole Christensen wrote:
>> monahanz wrote:
>>
>>> boards. To get the CF card specification apparently it costs $100! See
>>> http://www.compactflash.org/
>>
>> Try Google with: "OEMCFlashPMv12.0"
>
> All links dead...
Not true...!
http://apac.sandisk.com/Assets/File/OEM/Manuals/OEMCFlashPMv12.0.pdf
show up as #3 on my Google and works perfect...
<ole>
All...@localhost.net
wrote:
it's 9mb can you mailer handle that?
Allison
Ole Christensen
In using Google for "cfspc4_1.pdf"
http://www.diskusjon.no/index.php?act=attach&type=post&id=195565
show up as #1...!
how hard can it be...
<ole>
All...@localhost.net
That works for me but it's Steve asking.
Steve, if that doen't work for you I can sent that as well.
Allison
monahanz
> On Sun, 08 Nov 2009 17:10:00 +0100, Ole Christensen
>
>
>
>
>
> >Alli...@localhost.net skrev:
> >> On Sun, 08 Nov 2009 09:21:02 -0500, Steven Hirsch <snhir...@gmail.com>
> >> wrote:
>
> >>>>> There is plenty of free data elsewhere.
> >>>> Such as:http://www.compactflash.org/cfspc4_1.pdf
> >>> Gone: 404
>
> >>> Would someone who managed to grab this or the currently non-existent spec from
> >>> Sandisk please mail it to me as an attachment?
>
> >>> TIA!
>
> >>> Steve
>
> >> it's 9mb can you mailer handle that?
>
> >> Allison
>
> >In using Google for "cfspc4_1.pdf"
> >http://www.diskusjon.no/index.php?act=attach&type=post&id=195565
> >show up as #1...!
> >how hard can it be...
> ><ole>
>
> That works for me but it's Steve asking.
>
> Steve, if that doen't work for you I can sent that as well.
>
>
> - Show quoted text -
Thanks guys, got it. Gee there is a lot there! Actully more than I
have the stomach for right now. At first glance it does seem that
somehow you can communicate just over an 8 bit line for sector data.
However there is a lot of detailed documentation there. Does anybody
know if its just a question of software commands or would hardware
changes to certain pins also be required. I.e. could one configure
the card to 8 bit mode just using these IDE adaptor cards. If so it
might be interesting to see how a dual read of a high/low 16 bit port
for a sector compares with an 8 bit Z80 LDIR driven read from one
port.
Anybody hazzard a guess.
lynchaj
[snip]
>
> Yes.
>
> For IDE without 8255 seehttp://www.hanssummers.com/computers/cpcng/ide/
> Han's does a great job of illustrating how it's done.
>
Hi Allison! Thanks! I used a similar variation of that design for
the N8VEM DiskIO board. Personally, I find it a bit finicky although
it works better if you qualify the IDE READS and WRITES with the IDE
chip select signals (CS1 & CS0). I found that out the hard way! I
recommend the design we used on the XT-IDE project as that has proven
to be fairly reliable.
None of these IDE interfaces are going to be speedy but they do work
and there are costs and benefits to any approach. I like the 8255
solution because it offers a lot of flexibility while using only 4 IO
addresses. It would be trivial to convert the S-100 IDE design to any
of the IDE designs (Hans Summers, XT-IDE, or the 8255 approach). They
all do things in a similar fashion.
> Then look athttp://piters.tripod.com/zxcf.htmgranted it's for a ZX
> but thats Z80 and you only need S100 bus translation. It's really
> trivial.
>
> Hope that helps you simplify or at least capitalize on the CF
> ease of interface.
>
> Allison
I agree that CF on an S-100 board promises to make booting old systems
*much* easier and it is a worthwhile project. Simplifying the issues
with drives and booting promises to bring a lot of broken and
partially working S-100 systems back into the fold. Not to mention
more quiet and using a lot less power.
There are several N8VEM builders using CF with their DiskIO boards and
I suppose one day I'll convert too. It is especially appealing as the
space available on my workbench shrinks.
All...@localhost.net
wrote:
>On Nov 7, 9:10�pm, Alli...@localhost.net wrote:
>[snip]
>>
>> Yes.
>>
>> For IDE without 8255 seehttp://www.hanssummers.com/computers/cpcng/ide/
>> Han's does a great job of illustrating how it's done.
>>
>
>Hi Allison! Thanks! I used a similar variation of that design for
>the N8VEM DiskIO board. Personally, I find it a bit finicky although
>it works better if you qualify the IDE READS and WRITES with the IDE
>chip select signals (CS1 & CS0). I found that out the hard way! I
>recommend the design we used on the XT-IDE project as that has proven
>to be fairly reliable.
>
>None of these IDE interfaces are going to be speedy but they do work
>and there are costs and benefits to any approach. I like the 8255
>solution because it offers a lot of flexibility while using only 4 IO
>addresses. It would be trivial to convert the S-100 IDE design to any
>of the IDE designs (Hans Summers, XT-IDE, or the 8255 approach). They
>all do things in a similar fashion.
With Z80 PIO at 4mhz the extra code to twiddle the 8255 does
significantly slow things. The CF approach is fastest with 8bt reads
as teh input loop is minimal and can run as fast as z80 goes. The
difference is a Z80/4mhz tight PIO loop can do more that 60kB/S where
the 8255 loops is far longer and limits are less than 20kB/S. When
you consider other overheads (deblocking) and all that does make a
difference when doing compiles and other big tasks.
I like to run 6-10mhz Z80s and then you get to IO speeds that are
fas enough to really sing. My favorite brand of fun with Z80 is going
as fast as possible with CP/M 2 or 3.
Allison
s100guy
>
> I like to run 6-10mhz Z80s and then you get to IO speeds that are
> as fast as possible with CP/M 2 or 3.
>
> Allison
Exactly! I've got a prototype SBC running here on my desk at 10 MHz,
with a 1MB ram-disk (battery backed) and IDE interface (of the type
described by Phil Ruston on his Web site). It is all TTL with no
exotic programmable parts (except the 32k EPROM). Fully static RAM.
Perhaps the most difficult part to find is the DART, or SIO for the
dual serial ports (one is the console). They aren't too common these
days, but can be found. IMO, it is most effective to put a small (by
today's standards -- 2 GB) CF module on the IDE interface using one of
those CF to IDE adapters. I run CPM 2.2 on it with A: the ram drive
and B: and C: on the CF module. It is currently 2 PCB cards (roughly
5"x6" -- thanks Dr. Acula!!! *grin*), and I'm going to put it on a
single PCB soon, along with a connector for one of those uDrives (4D
Systems) that takes a micro SD chip. That provides easy file
transport between a PC and the Z80.
Very nice system!
Roger
James Moxham (Dr_Acula)
working some time ago. Though I think the N8VEM group is fast catching
up with real IDE drives and I think that means CF should be a
relatively easy step.
New DART 'A' chips available from futurlec http://www.futurlec.com/ICZ80Series.shtml
They also come up on ebay from time to time including faster ones.
Re SD cards, the propeller group have a two propeller chip solution
working that emulates the SIMH and uses the same 1meg and 8meg drive
images. I'm deep inside the code trying to get it onto one propeller
chip though struggling a bit with 32 bit propeller assembly.
There is Juha's SD driver code on the N8VEM site in more familiar 8080/
Z80 assembly.
And as Roger says, the uDrive which translates a micro SD card into
easy to understand serial instructions. But it is max 115kbaud serial
so equivalent to only about 10kbytes per second.
So some options for a S100 prototype board might be real IDE, CF IDE,
SD card directly and SD card via a 4dsystem's uDrive.
Greegor
> monahanz <mona...@vitasoft.org> wrote:
>
> (big snip)
>
> > Allison one further point. By CF card do you mean Compact Flash card.
> > If so that is what I am using here. The current layout has an IDE set
> > of connectors that allow you to insert a small IDE to CF card adaptor
> > board. The are very common, cost $8 from Newegg and at the same time
> > allows oone to yae a cable for an "old fashioned' calssical IDE
> > drive. Andrew and I considered adding a CF connector directly to the
> > board but the pins are real close and probably woukd require surface
> > mount soldering skills. The adaptor card already does this and costs
> > about what a bare CF connector would cost.
>
> The CF interface is very similar to the IDE interface.
>
> IDE is supposed to allow 8 bit transfers, but it seems that
> most drives forgot to implement that part.
There were a VERY FEW 8088 based IBM XT class PC's
made that used "8 bit IDE" controllers and drives.
YEARS before the big popularity of IDE.
May as well have been a proprietary interface.
Probably all scrapped long ago.
John Elliott
: On Nov 7, 3:18?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
:> IDE is supposed to allow 8 bit transfers, but it seems that
:> most drives forgot to implement that part.
: There were a VERY FEW 8088 based IBM XT class PC's
: made that used "8 bit IDE" controllers and drives.
You're talking about XTA, which uses (a subset of) the same physical
hardware but has a completely different command/register set. The optional
'8-bit transfer' mode in ATA uses the same commands and registers as normal,
but the drive sends data in 8-bit bytes rather than 16-bit words. Yes, it's
confusing.
--
John Elliott
Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show
glen herrmannsfeldt
> Are you sure? Isn't "IDE" just another name for ST-506?
IDE is, pretty much, ST-506 with the controller that went
with the PC/AT. That is, a 16 bit controller.
Fairly similar to the XT controller, but not exactly.
It was usual for 8 bit boards to work in 16 bit systems,
as they would not pull down a certain pin if they couldn't
do 16 bit cycles. I think some 16 bit boards could do 8 bit
cycles, but I am not sure which or how many.
-- glen
Tom Lake
"Edmund H. Ramm" <ehr...@dk3uz.ampr.org> wrote in message
news:hd9vrj$a8c$1...@dk3uz.ampr.org...
> In <288c6850-5e5b-4cf8...@j19g2000yqk.googlegroups.com>
>
>> There were a VERY FEW 8088 based IBM XT class PC's
>> made that used "8 bit IDE" controllers and drives.
>> YEARS before the big popularity of IDE.
>
> Are you sure? Isn't "IDE" just another name for ST-506?
No. ST-506 interfaces had all the logic on a controller board
as opposed to IDE in which the logic is all on the drive itself
and the connector on the motherboard is just that - a connector
rather than an interface.
Tom Lake
Barry Watzman
In the early XT's and even AT's, the disk controller was an ISA card
that connected to one or more drives. But the controller was on the ISA
card.
In "IDE", the controller is part of the drive. What we call an "IDE
controller" or "IDE Port" (usually on the motherboard, but can be on an
ISA or even PCI card) is just a glorified parallel port that talks to
the controller, which is part of the drive.
Why was this done? Why was the actual controller moved to and made part
of the drive?
Because by making the controller part of the drive, the controller can
do things that a controller which was not part of the drive cannot do.
For example, a controller that is not part of the drive is bound by the
classical assumption that the disk is composed of platters divided into
sectors as you would divide a pie into slices. However, when the
controller is part of the drive, the controller can work with the drive
in any way that the drive manufacturer wants. For example, not all
tracks have the same number of sectors. And when a sector is becoming
defective, it's data can be moved ("relocated")(as long as this is done
before the sector fails completely) to "spare" sector. And interleave
can be dealt with much more effectively, because the controller, being
part of the drive, can know the capabilities of that drive intimately,
and can be optimized to get the maximum performance and capacity out of
that particular drive, and it's particular platters (to the extent the
even different drives of the same model, coming off the same assembly
line one after the other, behave differently .... each controller being
optimized to the specific characteristics and defects of the platters
and heads in that particular drive).
Something to understand in an IDE controller is that the controller is a
computer (literally, with it's own processor, operating system and
memory) that lies between the IDE ***PORT*** and the actual drive
mechanism. The "drive" that this controller presents to the IDE
***PORT*** of the host PC is a total fiction that does not bear any
resemblance to what is physically present in the actual drive mechanism.
The number of heads, cylinders and sectors is "made up" ... for the
benefit of the host PC and it's operating system (DOS or Windows or
{whatever} (even Linux or Mac OS)). The controller is part of the
drive, made with the drive. But what the computer (the PC) sees is a
fiction fabricated for it (the PC) by the controller, and bears no
resemblance to the physical reality of the drive mechanism (the actual
platters and heads).
s_dub...@yahoo.com
>
> - Show quoted text -
I have one of those, is a 'IDE Drive on a card', (not the HardCard
product tho, which I also have) I think it was a Tandy product, did
Radio Shack make an XT clone? I got mine off of Ebay, they are rare
and pricey. Anyway, the seller claimed it would work in an XT, and it
does. I pulled the hard drive off it and put in a 810mb laptop IDE
drive with an 8k cache buffer. It's _fast_ with data in cache. It is
a short, half length card with a bracket to hold an IDE hd. Obviously
I'm only accessing a portion of the drive. It is set up as a dual
boot, msdos 3.3 or cp/m-86.
The HardCard product is an 8bit ISA full length card with the hard
drive also on it. I don't know if it is truely IDE, there's no way to
remove the hard drive from card on that. HardCard's in the 16bit AT
class are more common, not usable in an XT.
Wasn't it the case that a low level format shouldn't be done on a IDE?
Steve
Greegor
> Greegor <greego...@gmail.com> wrote:
>
> : On Nov 7, 3:18?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> :> IDE is supposed to allow 8 bit transfers, but it seems that
> :> most drives forgot to implement that part.
>
> : There were a VERY FEW 8088 based IBM XT class PC's
> : made that used "8 bit IDE" controllers and drives.
>
> You're talking about XTA, which uses (a subset of) the same physical
> hardware but has a completely different command/register set. The optional
> '8-bit transfer' mode in ATA uses the same commands and registers as normal,
> but the drive sends data in 8-bit bytes rather than 16-bit words. Yes, it's
> confusing.
I repaired one Japanese made XT clone computer
like that and saw this on an Epson XT clone, also
Japanese in a market dominated by Taiwan.
It wasn't confusing to me.
Is there any information about how
many XTA drives were made and when?
Were they mostly Japanese (premium)
makes like Fujitsu and Epson?
But to get back to the larger topic here, were
these drives with this 8 bit IDE XTA used
on any later models of CP/M computer?
They haven't been produced for over 20 years, right?
My impression is that while this might have been
an OPTION, it was an option when the drives
were ordered from the factory, not an option
that could actually be selected in the field.
Were there any drives that had this mode
selectable in the field?
glen herrmannsfeldt
(snip)
> In "IDE", the controller is part of the drive. What we call an "IDE
> controller" or "IDE Port" (usually on the motherboard, but can be on an
> ISA or even PCI card) is just a glorified parallel port that talks to
> the controller, which is part of the drive.
Glorified is a little off. It is pretty much buffers that run the
ISA bus directly to the drive. Well, the data bus and three
address bus lines. That is why the length limit is so strict.
> Why was this done? Why was the actual controller moved to
> and made part of the drive?
> Because by making the controller part of the drive, the controller can
> do things that a controller which was not part of the drive cannot do.
> For example, a controller that is not part of the drive is bound by the
> classical assumption that the disk is composed of platters divided into
> sectors as you would divide a pie into slices. However, when the
> controller is part of the drive, the controller can work with the drive
> in any way that the drive manufacturer wants.
That is the way it ended up, but I am not so sure that was the
idea from the beginning. IDE came out very early in the AT years.
Also, if that was the goal it wouldn't have been so hard to make
an external controller board that did that, and I believe that
some even did. The AT and many early clones only had a fixed
set of drive (cylinder, head, sector) entries in a table, maybe
about 50. As far as I remember, the early drives didn't have all
that much computing power, either. Maybe enough for a simple
remapping of Cylinder-Head-Sector values.
> For example, not all
> tracks have the same number of sectors. And when a sector is becoming
> defective, it's data can be moved ("relocated")(as long as this is done
> before the sector fails completely) to "spare" sector. And interleave
> can be dealt with much more effectively, because the controller, being
> part of the drive, can know the capabilities of that drive intimately,
> and can be optimized to get the maximum performance and capacity out of
> that particular drive, and it's particular platters (to the extent the
> even different drives of the same model, coming off the same assembly
> line one after the other, behave differently .... each controller being
> optimized to the specific characteristics and defects of the platters
> and heads in that particular drive).
Wow, I forgot about choosing the interleave when formatting ST-506
style drives. I do remember trying different interleaves on my
first one.
I believe on the early IDE drives I had that there were spare
sectors on each track, or maybe each cylinder. That is as far
as it would go in relocation. I think only at the time of a
(drive specific) low level format.
> Something to understand in an IDE controller is that the controller is a
> computer (literally, with it's own processor, operating system and
> memory) that lies between the IDE ***PORT*** and the actual drive
> mechanism. The "drive" that this controller presents to the IDE
> ***PORT*** of the host PC is a total fiction that does not bear any
> resemblance to what is physically present in the actual drive mechanism.
> The number of heads, cylinders and sectors is "made up" ... for the
> benefit of the host PC and it's operating system (DOS or Windows or
> {whatever} (even Linux or Mac OS)). The controller is part of the
> drive, made with the drive. But what the computer (the PC) sees is a
> fiction fabricated for it (the PC) by the controller, and bears no
> resemblance to the physical reality of the drive mechanism (the actual
> platters and heads).
I still remember using SCSI disks with SunOS, which required the
cylinder-head-sector values. Unix likes to keep data within cylinders,
but even fairly early, earlier than IDE, SCSI disks hid the actual
values.
-- glen
John Elliott
: But to get back to the larger topic here, were
: these drives with this 8 bit IDE XTA used
: on any later models of CP/M computer?
I've got an Amstrad PCW hard drive accessory that uses XTA.
: My impression is that while this might have been
: an OPTION, it was an option when the drives
: were ordered from the factory, not an option
: that could actually be selected in the field.
: Were there any drives that had this mode
: selectable in the field?
The Seagate ST351A/X. It could be switched between ATA and XTA using a
jumper.