15 May
2014
15 May
'14
10:47 a.m.
Hi all,
I just saw Josh Dersch's message thread right before I came here to talk
about another upgrade I did to my HP16700A.
I replaced the SCSI hard drive with a SCSI2SD. The device worked out of
the box with just a regular off-the-shelf microsd card.
I've used both the windows and linux software for firmware-upgrading and
configuration and they work quickly and without fuss or drivers.
The primary boot device was configured to SCSI ID 6. (and so I adjusted
the ID of the SCSI2SD to match)
I replaced the drive with the SCSI2SD device. I booted the HP off an
external scsi cdrom drive, using the official HP media, and the entire
installation process succeeded, all without user intervention. The whole
process took about an hour. This installed HPUX 10.20 onto the SCSI2SD.
I tested the data rates from an ubuntu PC with an adaptec card, and I was
getting between 720KB/s - 820KB/s. This is slower, but there's room for
optimization via software upgrade. (and even higher speeds available with
newer uC or FPGA, if there's a future version)
The logic analyzer definitely runs SLOWER with the SCSI2SD....perhaps in
the neighborhood of 75% of the original speed.
I haven't made up my mind whether I'll keep the modification, try another
device, wait for upgraded software, or maybe just keep it as a spare.
I *will* say that imaging the SD and producing a copy means you can
instantly (as fast as a PC can copy to the microsd card) get back to
factory default. This might be useful, especially with those that like to
tinker!
I've also had discussions with the developer, Michael McMaster, who is
very responsive.
The shipping from Australia was around $15 and took one week to the East
Coast US.
I'm going to type up a blog post or two on my website once I finish it.
I just went to the hardware store last night, and I think using some
standoffs and new screws that the SCSI2SD will mount nicely to the factory
hard drive mounting plate.
I think that this device would be perfect for those older devices where
the speed requirements are much less. The other thread mentions the A3000
-- yes, I think it might be ideal.
Keith M
techtravels.org
15 May
15 May
11:50 a.m.
On May 15, 2014, at 1:47 PM, Keith Monahan <keithvz at verizon.net> wrote:
Hi all,
I just saw Josh Dersch's message thread right before I came here to talk
about another upgrade I did to my HP16700A.
Oh, that's a neat idea. I need to get one of those one of these days,
though I don't find myself needing a logic analyzer as much as I used
to.
I tested the data rates from an ubuntu PC with an
adaptec card, and I was
getting between 720KB/s - 820KB/s. This is slower, but there's room for
optimization via software upgrade. (and even higher speeds available with
newer uC or FPGA, if there's a future version)
I don't think an FPGA is really necessary to maximize the speed (though a
simple CPLD or one of the really tiny FPGAs they're calling CPLDs these
days might be a boon for sync mode). However, I would love to work with
the guy to bring it to a real microcontroller that has a proper multi-bit
SD controller and external bus interface, like one of the STM32 family,
instead of those dreadful PSoC chips. Maybe I'll drop him a line...
The logic analyzer definitely runs SLOWER with the
SCSI2SD....perhaps in
the neighborhood of 75% of the original speed.
I haven't made up my mind whether I'll keep the modification, try another
device, wait for upgraded software, or maybe just keep it as a spare.
I *will* say that imaging the SD and producing a copy means you can
instantly (as fast as a PC can copy to the microsd card) get back to
factory default. This might be useful, especially with those that like to
tinker!
That is really excellent, especially for those of us with machines that
have built-in SD readers (which are often quite fast).
I've also had discussions with the developer,
Michael McMaster, who is
very responsive.
Good to know. I hope he's interested in working on a next generation!
I think that this device would be perfect for those
older devices where
the speed requirements are much less. The other thread mentions the A3000
-- yes, I think it might be ideal.
Yeah, a logic analyzer has some real bandwidth requirements. An A3000
and a Mac Plus really don't. Hopefully, a new generation will enable
at least 10 MT/s sync mode (not that most SD cards will run that fast,
but at least transferring out of the chip...).
Really cool. So glad someone stepped up to the plate and did this!
The guy who ships has it more right than the guy who spends forever
overoptimizing it and never getting it out the door.
- Dave
8:36 p.m.
On 2014-05-15 14:50, David Riley wrote:
On May 15, 2014, at 1:47 PM, Keith Monahan <keithvz
at verizon.net> wrote:
Huh? You apparently don't know what a PSoC is. It's a hybrid
programmable logic device and micro-controller. There are several
programmable logic blocks called UMBs inside the PSoC - each roughly
equivalent to a 22V10 SPLD. A PSoC has more macro cells than many CPLDs
and by far more data pump logic to/from the rest of the device. And the
micro-controller side is a "real microcontroller" - in fact the same
micro-controller core as your STM32 - an ARM Cortex M3. It does have a
proper multi-bit SDIO core, however it requires logic support from UMBs
and there may not be enough left over after the SCSI data pump.
Yes, I agree a discrete CPLD/FPGA + STM32 would be better performing
solution, however it would be more than twice the cost of a PSoC 5 in
just those ICs alone. I don't agree a standalone STM32 having to
bit-bang the SCSI side would perform better. Michael did a fabulous job.
I had started a design like it that evolved from a MachXO2+SiLabs M3
into a single PSoC 5, but Michael beat me to the finish line.
-Alan
I tested the data rates from an ubuntu PC with an
adaptec card, and I was getting between 720KB/s - 820KB/s. This is slower, but there's
room for optimization via software upgrade. (and even higher speeds available with newer
uC or FPGA, if there's a future version)
I don't think an FPGA is really necessary to maximize the speed (though a simple CPLD
or one of the really tiny FPGAs they're calling CPLDs these days might be a boon for
sync mode). However, I would love to work with the guy to bring it to a real
microcontroller that has a proper multi-bit SD controller and external bus interface, like
one of the STM32 family, instead of those dreadful PSoC chips. Maybe I'll drop him a
line...
8:52 p.m.
On May 15, 2014, at 11:36 PM, Alan Hightower wrote:
Oh, then they've improved greatly since last I worked with them...
When Cypress was pushing them on our company, they were just a
bizarre proprietary core with an assembly of peripherals that
you could switch out. That was... 2008? Geez, that was 6 years
ago. So okay, maybe they've improved, and I forgot how long it's
been since I wrote them off.
I don't
think an FPGA is really necessary to maximize the speed (though a simple CPLD or one of
the really tiny FPGAs they're calling CPLDs these days might be a boon for sync mode).
However, I would love to work with the guy to bring it to a real microcontroller that has
a proper multi-bit SD controller and external bus interface, like one of the STM32 family,
instead of those dreadful PSoC chips. Maybe I'll drop him a line...
Huh? You apparently don't know what a PSoC is. It's a hybrid
programmable logic device and micro-controller. There are several
programmable logic blocks called UMBs inside the PSoC - each roughly
equivalent to a 22V10 SPLD. A PSoC has more macro cells than many CPLDs
and by far more data pump logic to/from the rest of the device. And the
micro-controller side is a "real microcontroller" - in fact the same
micro-controller core as your STM32 - an ARM Cortex M3. It does have a
proper multi-bit SDIO core, however it requires logic support from UMBs
and there may not be enough left over after the SCSI data pump. Yes, I agree a discrete CPLD/FPGA + STM32 would be
better performing
solution, however it would be more than twice the cost of a PSoC 5 in
just those ICs alone. I don't agree a standalone STM32 having to
bit-bang the SCSI side would perform better. Michael did a fabulous job.
I had started a design like it that evolved from a MachXO2+SiLabs M3
into a single PSoC 5, but Michael beat me to the finish line.
I don't think you'd have to bit-bang the SCSI if you had a CPLD
to do the transaction for you on the parallel bus. Does the
current rev of PSoC have a parallel bus with data ack? Seems
like that would probably solve the problem without significant
architectural changes.
Don't get me wrong, I think his design is pretty great. I just
figure that's where most of the bottleneck is coming in. And,
unlike everyone else (including me), he got it out the door
instead of optimizing it to death in his head. :-)
- Dave
9:14 p.m.
On 5/15/2014 11:52 PM, David Riley wrote:
Don't get me wrong, I think his design is pretty
great. I just
figure that's where most of the bottleneck is coming in. And,
unlike everyone else (including me), he got it out the door
instead of optimizing it to death in his head. :-)
The creator explained the bottlenecks, which seem simple enough to me:
* He's using the 1-bit interface instead of the 4-bit. (I seem to recall
the 4-bit sdcard interface has some proprietary undocumented nature to
it, but that's not the only hurdle related to using the 4-bit interface)
* He's not using the maximum frequency on the SDCARD. The current uC
implementation is driving things around 15mhz (performance numbers on
his site were taken @ 18mhz, which is why he is seeing slightly better
numbers) The sdcard interface can do 25mhz.
* Not all cards are made equal, especially when it comes to
"erase-block-size", and small writes can force the card to (internally)
re-write much larger blocks. Using SMALLER cards which have smaller
erase-block-sizes will actually perform better than using the latest
fattest cards.
Keith
10:24 p.m.
On 5/15/2014 10:14 PM, Keith Monahan wrote:
On 5/15/2014 11:52 PM, David Riley wrote:
But small cards are hard to find, at least for me in Canada.
Don't get me wrong, I think his design is
pretty great. I just
figure that's where most of the bottleneck is coming in. And,
unlike everyone else (including me), he got it out the door
instead of optimizing it to death in his head. :-)
The creator explained the bottlenecks, which seem simple enough to me:
* He's using the 1-bit interface instead of the 4-bit. (I seem to recall
the 4-bit sdcard interface has some proprietary undocumented nature to
it, but that's not the only hurdle related to using the 4-bit interface)
* He's not using the maximum frequency on the SDCARD. The current uC
implementation is driving things around 15mhz (performance numbers on
his site were taken @ 18mhz, which is why he is seeing slightly better
numbers) The sdcard interface can do 25mhz.
* Not all cards are made equal, especially when it comes to
"erase-block-size", and small writes can force the card to (internally)
re-write much larger blocks. Using SMALLER cards which have smaller
erase-block-sizes will actually perform better than using the latest
fattest cards. Keith
16 May
16 May
7:06 a.m.
On May 16, 2014, at 12:14 AM, Keith Monahan <keithvz at verizon.net> wrote:
On 5/15/2014 11:52 PM, David Riley wrote:
If you?re doing one bit, you can run in MMC mode which I believe is easier. Real SD mode,
which supports your choice of 1 or 4 bits, requires speaking a packet based I/O protocol
(think MSCP, sort of) which includes a rather complex initialization handshake. It?s all
documented, but it?s a fair amount of work.
Don't get me wrong, I think his design is
pretty great. I just
figure that's where most of the bottleneck is coming in. And,
unlike everyone else (including me), he got it out the door
instead of optimizing it to death in his head. :-)
The creator explained the bottlenecks, which seem simple enough to me:
* He's using the 1-bit interface instead of the 4-bit. (I seem to recall the 4-bit
sdcard interface has some proprietary undocumented nature to it, but that's not the
only hurdle related to using the 4-bit interface)
* He's not using the maximum frequency on the SDCARD. The current uC implementation
is driving things around 15mhz (performance numbers on his site were taken @ 18mhz, which
is why he is seeing slightly better numbers) The sdcard interface can do 25mhz.
Or 50 MHz, if it supports high speed mode, and that?s correctly implemented in both card
(usually not a problem) and controller (may be a problem). An oddity of high speed mode
is that the signalling levels are the opposite of standard speed mode (data is latched on
falling edge vs. rising edge, or the other way around).
paul
15 May
15 May
11:40 p.m.
hey turned cctalk to chinese?
On 16-05-14 05:36, Alan Hightower wrote:
On 2014-05-15 14:50, David Riley wrote:
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
On May 15, 2014, at 1:47 PM, Keith Monahan
<keithvz at verizon.net> wrote:
Huh? You apparently don't know what a PSoC is. It's a hybrid
programmable logic device and micro-controller. There are several
programmable logic blocks called UMBs inside the PSoC - each roughly
equivalent to a 22V10 SPLD. A PSoC has more macro cells than many CPLDs
and by far more data pump logic to/from the rest of the device. And the
micro-controller side is a "real microcontroller" - in fact the same
micro-controller core as your STM32 - an ARM Cortex M3. It does have a
proper multi-bit SDIO core, however it requires logic support from UMBs
and there may not be enough left over after the SCSI data pump.
Yes, I agree a discrete CPLD/FPGA + STM32 would be better performing
solution, however it would be more than twice the cost of a PSoC 5 in
just those ICs alone. I don't agree a standalone STM32 having to
bit-bang the SCSI side would perform better. Michael did a fabulous job.
I had started a design like it that evolved from a MachXO2+SiLabs M3
into a single PSoC 5, but Michael beat me to the finish line.
-Alan
I tested the data rates from an ubuntu PC with an
adaptec card, and I was getting between 720KB/s - 820KB/s. This is slower, but there's
room for optimization via software upgrade. (and even higher speeds available with newer
uC or FPGA, if there's a future version)
I don't think an FPGA is really necessary to maximize the speed (though a simple CPLD
or one of the really tiny FPGAs they're calling CPLDs these days might be a boon for
sync mode). However, I would love to work with the guy to bring it to a real
microcontroller that has a proper multi-bit SD controller and external bus interface, like
one of the STM32 family, instead of those dreadful PSoC chips. Maybe I'll drop him a
line...
15 May
15 May
9:07 p.m.
On 5/15/2014 2:50 PM, David Riley wrote:
That is really excellent, especially for those of us
with machines that
have built-in SD readers (which are often quite fast).
Yeah, I think this is discussed on the other thread too (and I mentioned
it originally), but it's a point worth repeating:
Let's say you want to back up your logic analyzer drive. Just pop out
the sd card, and plug it into your regular PC. Image the whole thing
using dd, pipe it through gzip or similar, and then store the image.
Then, let's say you're messing around with the configuration, and screw
everything up, bam --- just reflash the sdcard with the original image,
and bob's your uncle.
I don't know what the lifetime on these flash cards are, but you could
also replace on nearing end of life.
Yeah, a logic analyzer has some real bandwidth
requirements.
Well yes and no. The main problem with the speed of the flash is just
that the OS is stored on it, and there's plenty of accessing when moving
through the GUI. The HP 16700A and similar units have a fully blown
multitasking windowed OS. So when you load one screen, or go to another,
or whatever, you're hitting the disk.
The actual capture happens all in memory, there's nothing (AFAIK)
streaming to the disk.
Really cool. So glad someone stepped up to the plate
and did this!
The guy who ships has it more right than the guy who spends forever
overoptimizing it and never getting it out the door.
Yes, me too! If I have to buy another one down the road, that's fine
with me....next gen hardware or whatever.
I think in terms of future proofing, getting rid of spinning rust is a
pretty high priority, and I like modern solution meets retro computing
even if it's not fully optimized, yet.
Thanks
Keith
2:22 p.m.
On Thu, May 15, 2014 at 11:47 AM, Keith Monahan <keithvz at verizon.net> wrote:
I just saw Josh Dersch's message thread right
before I came here to talk
about another upgrade I did to my HP16700A.
I replaced the SCSI hard drive with a SCSI2SD. The device worked out of
the box with just a regular off-the-shelf microsd card
[...]
The logic analyzer definitely runs SLOWER with the
SCSI2SD....perhaps in
the neighborhood of 75% of the original speed.
I need a hard drive for a 16700, which I got dirt cheap used because it
"didn't work". That's because it was configured with the option that
provided with an external SCSI drive rather than internal, and the dim
bulbs at the surplus place had already separated the drive from the
analyzer. I still don't understand why they almost always split up things
that belong together.
I was thinking about trying the SCSI2SD, or buying an Addonics ADSALVD160
or Acard AEC-7732 SCSI-to-SATA adapter for use with a SATA SSD. It's good
to hear that the SCSI2SD works, but I think I'll try the Addonics.
Eric
4:36 p.m.
On Thu, May 15, 2014 at 2:22 PM, Eric Smith <spacewar at gmail.com> wrote:
I was thinking about trying the SCSI2SD, or buying an Addonics ADSALVD160
or Acard AEC-7732 SCSI-to-SATA adapter for use with a SATA SSD. It's good
to hear that the SCSI2SD works, but I think I'll try the Addonics.
Are there any expected benefits of using a SCSI-SATA adapter and a
SATA drive over just sticking a SCSI drive in the 16700A? I have just
stuck with using 68-pin SCSI drives with 50-68 pin adapters as
replacements for missing drives in 16700A analyzers. That has been a
cheap solution.
I suppose a SATA drive and adapter would be quieter than a lot of the
SCSI drives I have. It would certainly be larger, though I'm not sure
if that if often necessary. I wonder if it would make any operations
noticeably faster on the 16700A.
Just wondering if you get much in return for spending $130 or so for
an adapter instead of going with native SCSI in this application.
5:25 p.m.
On 2014-05-15 17:36, Glen Slick wrote:
Just wondering if you get much in return for spending
$130 or so for
an adapter instead of going with native SCSI in this application.
I can tell you how nice it is to make backups, if you can take an
sd-flash, "dd" it on your server, and zip it.
It is a method for a backup, which is actually so easy, that you
actually start doing backups again ;-)
Cheers
6:11 p.m.
On Thu, May 15, 2014 at 5:36 PM, Glen Slick <glen.slick at gmail.com> wrote:
On Thu, May 15, 2014 at 2:22 PM, Eric Smith
<spacewar at gmail.com> wrote:
Aside from not liking being dependent on electromechanical devices that are
at the far end of the bathtub curve, perhaps not.
I can understand wanting to use period peripherals on one's old computers,
but for test equipment I'm more worried about reliability.
I was thinking about trying the SCSI2SD, or buying an Addonics ADSALVD160
or Acard AEC-7732 SCSI-to-SATA adapter for use with a SATA SSD. It's
good
to hear that the SCSI2SD works, but I think
I'll try the Addonics.
Are there any expected benefits of using a SCSI-SATA adapter and a
SATA drive over just sticking a SCSI drive in the 16700A? 
6:54 p.m.
On 15/05/14 7:36 PM, Glen Slick wrote:
On Thu, May 15, 2014 at 2:22 PM, Eric Smith
<spacewar at gmail.com> wrote:
Yeah. SCSI drives are already hard to find.
--Toby
I was thinking about trying the SCSI2SD, or buying an Addonics ADSALVD160
or Acard AEC-7732 SCSI-to-SATA adapter for use with a SATA SSD. It's good
to hear that the SCSI2SD works, but I think I'll try the Addonics.
Are there any expected benefits of using a SCSI-SATA adapter and a
SATA drive over just sticking a SCSI drive in the 16700A? I have just stuck with using 68-pin SCSI drives with 50-68 pin
adapters as
replacements for missing drives in 16700A analyzers. That has been a
cheap solution.
I suppose a SATA drive and adapter would be quieter than a lot of the
SCSI drives I have. It would certainly be larger, though I'm not sure
if that if often necessary. I wonder if it would make any operations
noticeably faster on the 16700A.
Just wondering if you get much in return for spending $130 or so for
an adapter instead of going with native SCSI in this application.
8:53 p.m.
On 5/15/2014 5:22 PM, Eric Smith wrote:
I was thinking about trying the SCSI2SD, or buying an
Addonics ADSALVD160
or Acard AEC-7732 SCSI-to-SATA adapter for use with a SATA SSD. It's good
to hear that the SCSI2SD works, but I think I'll try the Addonics.
There are several different solutions out there. Quite frankly, I just
picked one because it was semi-easily available, had published open
source code online, and the creator emailed me back that someone had
successfully used it with an HP16601A (or similar). It also had VERY
recent development work on it, which is a plus, because I know how these
projects can go stale. Some of mine have.
I thought my chances of quick success was good. And was right, this
thing pretty much worked out of the box without little to no fiddling
around. Very sweet for a project like this.
Besides, I *really* like supporting folks that step up and do this type
of thing. Sure, it's often sort of first-gen hardware, and there are
usually bugs to work. And so on. But the code is field upgradable over
USB without a programmer, so that's a plus too.
That was my thought process on selecting this one. And realistically,
I'll probably end up buying a few others if they can easily be ordered.
Please post if you try the Addonics with your results!
Thanks
Keith
16 May
16 May
9:13 p.m.
On Thu, May 15, 2014 at 9:53 PM, Keith Monahan <keithvz at verizon.net> wrote:
On 5/15/2014 5:22 PM, Eric Smith wrote:
I was thinking about trying the SCSI2SD, or buying an Addonics ADSALVD160
The Addonics ADSALVD160 arrived today. It turns out (not too surprisingly)
that the Addonics product is an OEM'd Acard AEC-7730A, though at a much
lower price than I was able to find for the Acard ($125ish vs. $250ish). I
haven't actually tested it in the logic analyzer yet, as I haven't yet
received the 50 IDC male to 68 SCSI male adapter I ordered. I intend to
first test it with a spare 2.5-inch SATA drive, and if that works, get a
relatively low-capacity SATA SSD to install "permanently".
or Acard AEC-7732 SCSI-to-SATA adapter for use
with a SATA SSD. It's good
to hear that the SCSI2SD works, but I think I'll try the Addonics.
Please post if you try the Addonics with your results!
3818
days inactive
3825
days old
18 comments
10 participants
participants (10)
-
alan＠alanlee.org -
bfranchuk＠jetnet.ab.ca -
emu＠e-bbes.com -
fraveydank＠gmail.com -
glen.slick＠gmail.com -
keithvz＠verizon.net -
paulkoning＠comcast.net -
simski＠dds.nl -
spacewar＠gmail.com -
toby＠telegraphics.com.au