16 Nov
2005
16 Nov
'05
8:15 p.m.
Most of the PCI prototyping boards that I've seen are either outrageously
expensive or absolutely bare (i.e. no interface logic at all)--and still
not that inexpensive.
Does anyone know of a reasonable (<$100) PCI prototyping kit with a
reasonable amount of interface logic built on?
Cheers,
Chuck
16 Nov
16 Nov
9:55 p.m.
On 11/16/05, Chuck Guzis <cclist at sydex.com> wrote:
Most of the PCI prototyping boards that I've seen
are either outrageously
expensive or absolutely bare (i.e. no interface logic at all)--and still
not that inexpensive.
Does anyone know of a reasonable (<$100) PCI prototyping kit with a
reasonable amount of interface logic built on?
Altera MAX II kit?
Last time I check it was $150 but you get a CPLD and other logic on board too.
Cheers,
Chuck
17 Nov
17 Nov
2:33 p.m.
>>>> "9000" == 9000 VAX
<vax9000 at gmail.com> writes:
9000> On 11/16/05, Chuck Guzis <cclist at sydex.com> wrote:
> Most of the PCI prototyping boards that I've
seen are either
> outrageously expensive or absolutely bare (i.e. no interface logic
> at all)--and still not that inexpensive.
>
> Does anyone know of a reasonable (<$100) PCI prototyping kit with
> a reasonable amount of interface logic built on?
9000> Altera MAX II kit? Last time I check it was $150 but you get a
9000> CPLD and other logic on board too.
If you don't want to mess with CPLDs or FPGAs, there's PLX, which
makes a variety of PCI to xxx interface chips. For modest
performance, there's PCI to ISA (alternatively, to a "generic" bus),
PIO mode only.
paul
4:47 p.m.
Another (cheaper) PCI prototyping board is available from Quancom:
www.Quancom.com
PCIPROTO - PCI Prototype Card with PCI Decoder chip
http://www.quancom.com/qprod01/eng/pb/pci_prototype_card.htm
No experience [yet] with it, just found it in our own internal
investigations.
Bruce
----- Original Message -----
From: "Paul Koning" <pkoning at equallogic.com>
To: <cctalk at classiccmp.org>
Sent: Thursday, November 17, 2005 7:33 AM
Subject: Re: Cheapest PCI prototyping?
>>>> "9000" == 9000 VAX <vax9000 at gmail.com> writes:
9000> On 11/16/05, Chuck Guzis <cclist at sydex.com> wrote:
> Most of the PCI prototyping boards that
I've seen are either
> outrageously expensive or absolutely bare (i.e. no interface logic
> at all)--and still not that inexpensive.
>
> Does anyone know of a reasonable (<$100) PCI prototyping kit with
> a reasonable amount of interface logic built on?
9000> Altera MAX II kit? Last time I check it was $150 but you get a
9000> CPLD and other logic on board too.
If you don't want to mess with CPLDs or FPGAs, there's PLX, which
makes a variety of PCI to xxx interface chips. For modest
performance, there's PCI to ISA (alternatively, to a "generic" bus),
PIO mode only.
paul
16 Nov
16 Nov
10:34 p.m.
Don't know about cheapest, but it's one. I doubt you'll find
anything under $100 simply because making small runs of PCI cards is
expensive (multi-layer, beveled slot edge, none-rectangular route).
Google has a number of hits for "pci fpga prototype".
Somewhere I swear I saw a PCI card that had a minimal FPGA for the
bus interface, and a reasonable prototyping area. It struck me as odd
that someone would want to use 0.1" centered proto area, since there are
very few chips one would want to use on a PCI bus that are available in DIP.
<URL: http://www.opencores.org/projects.cgi/web/iiepci/overview >
--jc
Chuck Guzis wrote:
Most of the PCI prototyping boards that I've seen
are either outrageously
expensive or absolutely bare (i.e. no interface logic at all)--and still
not that inexpensive.
Does anyone know of a reasonable (<$100) PCI prototyping kit with a
reasonable amount of interface logic built on?
Cheers,
Chuck
10:38 p.m.
Here's the one I was thinking of. But it's still $400.
<URL: http://www.techniprise.com/pci_protoboard.htm >
--jc
Chuck Guzis wrote:
Most of the PCI prototyping boards that I've seen
are either outrageously
expensive or absolutely bare (i.e. no interface logic at all)--and still
not that inexpensive.
Does anyone know of a reasonable (<$100) PCI prototyping kit with a
reasonable amount of interface logic built on?
Cheers,
Chuck
17 Nov
17 Nov
5:06 p.m.
Chuck Guzis wrote:
Most of the PCI prototyping boards that I've seen
are either outrageously
expensive or absolutely bare (i.e. no interface logic at all)--and still
not that inexpensive.
Does anyone know of a reasonable (<$100) PCI prototyping kit with a
reasonable amount of interface logic built on?
You don't get anything or $100. But the board the PCI-Core from
Opencores was made on (memec insight) is around $200, and even a
nicer one (from avnet, actually, memec is part of avnet in the meantime)
is just 300-400. Both have some sram/dram, v24, and some usefull stuff too.
6:29 p.m.
On 11/17/2005 at 10:06 AM e.stiebler wrote:
You don't get anything or $100. But the board the
PCI-Core from
Opencores was made on (memec insight) is around $200, and even a
nicer one (from avnet, actually, memec is part of avnet in the meantime)
is just 300-400. Both have some sram/dram, v24, and some usefull stuff
too.
Sigh. It's about what I thought. I'm just looking for faster data transfer
than what ISA will get me. Not much faster--about 4 MB/sec.
Ideas?
Cheers,
Chuck
6:51 p.m.
Chuck Guzis wrote:
On 11/17/2005 at 10:06 AM e.stiebler wrote:
What do you like to attach to it ?
You don't get anything or $100. But the board
the PCI-Core from
Opencores was made on (memec insight) is around $200, and even a
nicer one (from avnet, actually, memec is part of avnet in the meantime)
is just 300-400. Both have some sram/dram, v24, and some usefull stuff
too.
Sigh. It's about what I thought. I'm just looking for faster data transfer
than what ISA will get me. Not much faster--about 4 MB/sec.
Ideas?
1:19 a.m.
On 11/17/2005 at 5:25 PM e.stiebler wrote:
Then get the old memec/insight PCI eval board (spartan
xc2s200?). Should
do the job just fine.
...and there's the rub. I might be better off simply putting together a
dedicated non-PC controller and just spool the data over USB. 9 track
tapes don't hold that much after all--and I'll be streaming pretty much
from BOT to EOT on both read and write.
I need to think about this.
Thanks,
Chuck
1:47 a.m.
"Chuck Guzis" wrote:
On 11/17/2005 at 5:25 PM e.stiebler wrote:
I'm confused (sorry). Are you trying to build a PCI board with a Pertec
interface?
I would think it would be easier to find a small qbus-11, put an 11/73
cpu in it with a built in ethernet and run 2.11bsd. You can image the
tapes and rcp the images to a linux box. pertec interface qbus boards
are not hard to find.
but then again, it would be fun to make a pci board with a pertec
interface... :-)
-brad
Then get the old memec/insight PCI eval board
(spartan xc2s200?). Should
do the job just fine.
...and there's the rub. I might be better off simply putting together a
dedicated non-PC controller and just spool the data over USB. 9 track
tapes don't hold that much after all--and I'll be streaming pretty much
from BOT to EOT on both read and write.
6:01 a.m.
On 11/17/2005 at 8:47 PM Brad Parker wrote:
I'm confused (sorry). Are you trying to build a
PCI board with a Pertec
interface?
Yes, basically--and one that will handle arbitrarily long records (i.e.
much greater than 64K). I've built an ISA Pertec adapter that will do
this, but it's too slow to keep up with a faster drive. I've also built a
PCI version of a sort that uses a PCI card with 2 82C55's on it, but again,
it's not quite fast enough.
I was under the impression that the qbus cards had the 64K record size
limitation.
Cheers,
Chuck
11:35 a.m.
"Chuck Guzis" wrote:
On 11/17/2005 at 8:47 PM Brad Parker wrote:
Ah. I'd love to see the schematics - are they on the web?
I'm confused (sorry). Are you trying to build
a PCI board with a Pertec
interface?
Yes, basically--and one that will handle arbitrarily long records (i.e.
much greater than 64K). I've built an ISA Pertec adapter that will do
this, but it's too slow to keep up with a faster drive. I've also built a
PCI version of a sort that uses a PCI card with 2 82C55's on it, but again,
it's not quite fast enough. I was under the impression that the qbus cards had the
64K record size
limitation.
Probably so.
What's the maximum block size?
If you don't mind discussing it, I'd be interesting to know why you want
such big blocks - are the tapes 'preexisting' and you just want to read
them, or do you want to create tapes with huge blocks? (if so, why?)
Also, what's the aggregate data rate in bytes/second? I assume you want
to 'stream' so the drives don't rock back and forth.
You might be able to get by with one of those little SAM7's cpu's. They
have a usb interface but it's only usb 1.1. Not much interal ram,
however (<64k). Now that I think about it I'm skeptical since you'd
have to buffer from the tape and feed out 64 byte bulk packets - pretty
tight timing wise.
I suspect the $200 pci bus solution might be your best bet cost wise,
but I would think you'd have to have at least a little fifo to buffer as
you arbitrate and burst onto the pci bus. Depending on the cpld/fpga
you might be able to use internal ram and do it all with some simple
verilog/vhdl.
On the read side I think I'd just double buffer and have two registers
in the pci card, one for each buffer, and then status & count for each
one. Very simple. Writing should be the same, again, with the fifo's
which allow you the dma to run ahead.
-brad
5:44 p.m.
On 11/18/2005 at 6:35 AM Brad Parker wrote:
Ah. I'd love to see the schematics - are they on
the web?
No, I did those on pencil and paper. Brutally simple, actually--mostly
receivers and drivers, with latches for holding data and status. Most of
the smarts are in software. With the PCI version, I got wise and moved the
line interface to a separate card so I don't have to redo that part of the
job as my design evolves.
What's the maximum block size?
My design goal is 1MB blocks. That should cover all eventualities.
If you don't mind discussing it, I'd be
interesting to know why you want
such big blocks - are the tapes 'preexisting' and you just want to read
them, or do you want to create tapes with huge blocks? (if so, why?)
The tapes are preexisting--I don't know exactly how long the blocks are
(for the obvious reason that I can't read them without data loss) but the
block size seems to be in the area of 256K or so. Ideally, I'd like to
make copies as well as read them.
Also, what's the aggregate data rate in
bytes/second? I assume you want
to 'stream' so the drives don't rock back and forth.
The data rate is about 1.1MB/sec from what I've been able to determine.
I'd like a bunch of headroom. I'd tried a 16-bit ISA interface (16 bits at
a toss) using PIO, but even with interrupts disabled, I was still losing a
byte now and then, which leads me to suspect that I'm running on the edge.
Peformance on varies wildly between host machines with older Pentiums
generally doing better than 486, Celeron or P3/P4 systems. The code's
32-bit running under a DOS extender (not Windoze).
The ideal solution would be a double-buffered bus-mastering DMA setup.
But I'm getting a little weary of fighting the PC bus battle. If I moved
the whole setup out of the PC box, using a small processor board with a
small hard disk and interfacing via USB or TCP/IP, I'd have a permanent
solution that should work with any host machine. Even with today's
smallest hard disks, I could hold the contents of many tapes on one.
At least that's the way I'm leaning.
Cheers,
Chuck
6:17 p.m.
"Chuck Guzis" wrote:
On 11/18/2005 at 6:35 AM Brad Parker wrote:
I've just never looked into pertec. Is it ttl? It would be interesting
to see what signals you have to wiggle and how the data goes across.
I'm curious how you figured all that out.
Ah. I'd love to see the schematics - are they
on the web?
No, I did those on pencil and paper. Brutally simple, actually--mostly
receivers and drivers, with latches for holding data and status. My design goal is 1MB blocks. That should cover all
eventualities.
yowza - that's huge. I've never heard of anything writing blocks that
big. Mind if I ask *what* wrote them?
The data rate is about 1.1MB/sec from what I've
been able to determine.
I'd like a bunch of headroom. I'd tried a 16-bit ISA interface (16 bits at
a toss) using PIO, but even with interrupts disabled, I was still losing a
byte now and then, which leads me to suspect that I'm running on the edge.
Interesting. Seems like 1MByte/sec might be an ISA maximum
(http://www.evaluationengineering.com/pctest/articles/e707data.htm)
Using a 32 bit dos extender seems like the way to go - a hard loop. But
once you go to disk all bets are off. I can see how that might end up
being a loose.
I wonder if you just added a fifo to cover the time interrupts might
steal... you could do that in a cpld these days. yea, ok, sorry. I
just had to say it.
The ideal solution would be a double-buffered
bus-mastering DMA setup.
yes, on pci. but I think you'd still need a fifo to cover the arbitration.
If I moved
the whole setup out of the PC box, using a small processor board with a
small hard disk and interfacing via USB or TCP/IP, I'd have a permanent
solution that should work with any host machine. Even with today's
smallest hard disks, I could hold the contents of many tapes on one.
Well that makes sense. If you used something like a BrightStar
IPEngine, you'd have a PPC which will run linux next to a nice FPGA
which has some SRAM next to it. With that you could easily make an
interface which would pull all the data and you could stream it over
ethernet using tcp so you would not loose any data. You shouldn't need
a disk.
But for the same money you could buy a nice pci card with an fpga.
I'd go with an IPEngine style solution but that me :-)
Thanks for letting me kibitz. Very interesting. I'd enjoy hearing more
about the actual pertec interface.
-brad
6:28 p.m.
Brad Parker wrote:
without a small buffer for sure ...
PCI/FPGA/SDRAM. You can read in the whole tape in locally ;-)
USB is to slow for this, you need at least USB2. And then, you dont get
to many cheap small controllers with USB2. Or you just go backwards to
the idea before, get an 8051 with USB, a FPGA&SDRAM, read in the whole
tape, and transfer it slowly over ...
Cheers
I've just never looked into pertec. Is it ttl? It would be interesting
to see what signals you have to wiggle and how the data goes across.
I'm curious how you figured all that out.
probably reading the manuals ?
;-)
yowza - that's huge. I've never heard of
anything writing blocks that
big. Mind if I ask *what* wrote them?
We did sometime pretty bg block directly via DMA fro a data acquisition
system
>The data rate is about 1.1MB/sec from what I've
been able to determine.
6250*175 ?
I'd like a
bunch of headroom. I'd tried a 16-bit ISA interface (16 bits at
a toss) using PIO, but even with interrupts disabled, I was still losing a
byte now and then, which leads me to suspect that I'm running on the edge.
Interesting. Seems like 1MByte/sec might be an ISA maximum I wonder if you just added a fifo to cover the time
interrupts might
steal... you could do that in a cpld these days. yea, ok, sorry. I
just had to say it.
Just in case, with an FPGA you get the FIFO closer by ;-)
The ideal solution would be a double-buffered
bus-mastering DMA setup.
yes, on pci. but I think you'd still need a fifo to
cover the arbitration. If I moved
the whole setup out of the PC box, using a small processor board with a
small hard disk and interfacing via USB or TCP/IP, I'd have a permanent
solution that should work with any host machine. Even with today's
smallest hard disks, I could hold the contents of many tapes on one.
Well that makes sense. If you used something like a BrightStar
IPEngine, you'd have a PPC which will run linux next to a nice FPGA
which has some SRAM next to it. With that you could easily make an
interface which would pull all the data and you could stream it over
ethernet using tcp so you would not loose any data. You shouldn't need
a disk.
6:36 p.m.
On 11/18/2005 at 1:17 PM Brad Parker wrote:
I've just never looked into pertec. Is it ttl? It
would be interesting
to see what signals you have to wiggle and how the data goes across.
It's single-ended OC TTL with 220/330 termination. Very "dumb" interface
with no handshaking--just strobes from the drive. On read, the drive
presents data and says "here it is" and on write the drive says "I'm
grabbing the data that you've hopefully set up already". Commands
basically involve asserting a number of signals corresponding to what you
want to do and then pulsing the "IGO" line for at least a microsecond.
Status lines take two forms--one type is static (e.g. write enabled), the
other is pulsed during the course of an operation (e.g. there was a parity
error on that frame). You even have to furnish the parity bit for writes.
There is a brief description of the signals in the back of one of the
Overland data drive manuals and I think I've seen another document on the
web.
Well, like I say, I want to stew on this one awhile.
Cheers,
Chuck
9:01 p.m.
It occurred to me that maybe I'm trying to shoot a duck with a howitzer.
A 16-bit ISA implementation with FIFO should have enough moxie to sustain
the data rate I'm looking at using DMA transfers. Normally, this would
limit one to 128K transfers, but the 8237 DMAC has the auto-initialize
function, so I should be able to pull data out of the DMA buffer fast
enough to handle any length record. Circular buffering of a sort. A 512
word FIFO would allow for almost a millisecond of latency, so even if I had
to do without autoinitialize, I should be able to, even under Windoze
(perish the thought!).
This would simplify design and implementation tremendously.
Whatcha think?
Cheers,
Chuck
19 Nov
19 Nov
2:01 a.m.
"Chuck Guzis" wrote:
This would simplify design and implementation tremendously.
fifo's are generally the rubber band which make these 2nd order
system work (and oscillate :-)
I'd still go with the simple, controlled dos-extender solution but I
would not be suprised if you could get it work under winders also.
-brad
5:12 a.m.
On 11/18/2005 at 9:01 PM Brad Parker wrote:
I'd still go with the simple, controlled
dos-extender solution but I
would not be suprised if you could get it work under winders also.
Although I've written my share of NT and 2K/XP (they're not exactly the
same) drivers, I still love the "down and dirty" of using a DOS extender to
get the 32 bit flat addressability and just banging on the ports.
I'll work out the schematics fer real this time and post them after I've
prototyped the thing up. No sense in scanning something that doesn't work
right. Normally, I'd wirewrap the thing, but I'm thinking about using a
PCB prototyping service. Has anyone tried PCB123?
Cheers,
Chuck
3:26 a.m.
Ah. I'd love to see the schematics - are they on
the web?
No, I did those on pencil and paper. 
20 Nov
20 Nov
12:44 a.m.
Ah. I'd love to see the schematics - are they on
the web?
No, I did those on pencil and paper.
18 Nov
18 Nov
3:02 p.m.
>>>> "Brad" == Brad Parker
<brad at heeltoe.com> writes:
Brad> "Chuck Guzis" wrote:
> On 11/17/2005 at 5:25 PM e.stiebler wrote:
>
>> Then get the old memec/insight PCI eval board (spartan
>> xc2s200?). Should do the job just fine.
> ...and there's the rub. I might be better off simply putting
> together a dedicated non-PC controller and just spool the data
> over USB. 9 track tapes don't hold that much after all--and I'll
> be streaming pretty much from BOT to EOT on both read and write.
Brad> I'm confused (sorry). Are you trying to build a PCI board with
Brad> a Pertec interface?
Brad> I would think it would be easier to find a small qbus-11, put
Brad> an 11/73 cpu in it with a built in ethernet and run 2.11bsd.
Brad> You can image the tapes and rcp the images to a linux box.
Brad> pertec interface qbus boards are not hard to find.
Or some other OS, and copy the data with DECnet. Linux supports
DECnet, after all...
paul
6985
days inactive
6989
days old
25 comments
9 participants
participants (9)
-
ard＠p850ug1.demon.co.uk -
bkr＠WildHareComputers.com -
brad＠heeltoe.com -
cclist＠sydex.com -
emu＠ecubics.com -
jcwren＠jcwren.com -
mouse＠Rodents.Montreal.QC.CA -
pkoning＠equallogic.com -
vax9000＠gmail.com