4 Dec
2010
4 Dec
'10
6:08 p.m.
Ok guys,
The Good bit....
All this talk of SCSI to whatever got me curious so I started experementing.
What I have so far :
An AVR ATMega1284 (DIP40), connected to an SD card by SPI and to the
SCSI bus via 4 LS chips (1xLS273 and 3xLS240). I currently have
implemented just a few of the SCSI command set, Identify, read, write,
test ready and request sense.
Thist is enough to be able to connect to a PC SCSI card, format the
drive and read and write files to it....heheh I can even boot off it !
I'm using Chan's FatFS, and in this way the drive seen by the SCSI is
actually a large image file on the SD card, I did this as it will make
backing up the drive *MUCH* easier if the target system is not a PC, as
you can simply take the SD card out and copy the image file without
worrying about it's internal structure. In theory this will also make
sharing data between the target system and an emulation running on
something more modern.
There's a couple of pictures here :
http://www.stardot.org.uk/forums/viewtopic.php?f=11&t=3646
The bad bit......
Whilst this all works it's SLOWWWW, using Norton utilities SI, reports
that the disk is 0.2x the speed of an original PC, cirtainly bootup
times are much more akin to what I would expect from a floppy drive :(
So I would sugest that for replacing hard disks that using SCSI->SD is
probably not going to be fast enough.
My next experements are going to center on replacing the SD with an IDE
drive, hopefully this will provide a suitable speed increse, asuming
that this works it should be easy enough to use a CF->IDE adapter board
to use a CF drive instead of an IDE, which will allow the media to be
removable and easiliy swapable.
The other thing I want this to support is 256 byte sectors as some old
machines rely on this, a feature which is supported by some of the early
SCSI/SASI to MFM/RLL boards but very few native SCSI drives, this would
be of perticular intrest to some of the Acorn 8 bit machines.
Comments & sugestions welcome.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
4 Dec
4 Dec
6:34 p.m.
Thist is enough to be able to connect to a PC SCSI
card, format the drive
and read and write files to it....heheh I can even boot off it !
**I AM SPEECHLESS** :oO
Some suggestions:
- Forget bit-bang SPI code. There is a SPI interface on atmega, it makes
things waayy faster
- Forget FAT. Use the SD card as a block device, it will triple the
speed. It won't be readable in PC but will be with a layer of code less.
- Use the fastest processor you can
- Use the internal RAM as a buffer. It will speed things a lot, move the
data to sdcard in the idle times
- Map the entire SD card as a drive, with no translation. E.G.: The
sector 321 of the card is the sector 321 of the SCSI "hard disk"
I'm sure it will be way faster
CONGRATULATIONS! :D
7:46 p.m.
On 05/12/2010 02:34, Alexandre Souza - Listas wrote:
:)
It was helped by already having worked some of it out when writing the
emulation for the RM nimbus hard disk in MESS, which is effectivly
bit-banged SCSI.....
Thist is
enough to be able to connect to a PC SCSI card, format the
drive and read and write files to it....heheh I can even boot off it !
**I AM SPEECHLESS** :oO Some suggestions:
- Forget bit-bang SPI code. There is a SPI interface on atmega, it makes
things waayy faster
Yep using the hardware SPI, it's just the SCSI that I have to do manually.
- Forget FAT. Use the SD card as a block device, it
will triple the
speed. It won't be readable in PC but will be with a layer of code less.
- Use the fastest processor you can
Of course...the Mega 1284 is good to 20MHz
- Use the internal RAM as a buffer. It will speed
things a lot, move the
data to sdcard in the idle times
I may try implementing that one of the reasons for picking the m1284 was
that it has 16K of internal SRAM.
- Map the entire SD card as a drive, with no
translation. E.G.: The
sector 321 of the card is the sector 321 of the SCSI "hard disk"
That's how I tried it initially, so I know it works I just wanted the
FAT because it makes things much more convenient :)
I'm sure it will be way faster
CONGRATULATIONS! :D
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
7:32 p.m.
On 5 Dec 2010 at 2:08, Phill Harvey-Smith wrote:
Comments & sugestions welcome.
Use an ARM CPU. The SD-to-CPU connection is straightforward and you
should have more than enough I/O pins to implement the 4-bit
interface. Since most ARMs have internal PLL clock generators,
getting 60-70 MHz is easy on all but the lowest-end models.
SCSI bus drivers should be OC, not totem-pole (so you can have more
than one device on the bus), so you'll want to use something like an
LS641 for the bus transceiver. You can do active termination with a
2.85V LDO regulator (I like the LM1086) and some 110 ohm resistor
packs.
Many ARMs have built-in external RAM controllers, so adding a few MB
of RAM for cache is easy. Some offer DMA.
--Chuck
P.S. I'm looking forward to Energy Micro's Giant Gecko line with 128K
of RAM on-chip.
7:57 p.m.
On 05/12/2010 03:32, Chuck Guzis wrote:
On 5 Dec 2010 at 2:08, Phill Harvey-Smith wrote:
I had considdered that, however this does mean doing fine pitch smd
work, which whilst not really (yet) a problem for me does serve as a
barrier to some members of this list (and the community in general).
Comments& sugestions welcome.
Use an ARM CPU. The SD-to-CPU connection is straightforward and you
should have more than enough I/O pins to implement the 4-bit
interface. Since most ARMs have internal PLL clock generators,
getting 60-70 MHz is easy on all but the lowest-end models. SCSI bus drivers should be OC, not totem-pole (so you
can have more
than one device on the bus), so you'll want to use something like an
LS641 for the bus transceiver. You can do active termination with a
2.85V LDO regulator (I like the LM1086) and some 110 ohm resistor
packs.
Humm I used LS240s as that was what the sugested interface circuits in
the Adaptec ACB-4000 and Xebec SCSI to MFM boards used, they are 3
state, and I do HiZ them when I'm not driving the bus, I'll have to try
it with another SCSI drive also on the bus tho.
Many ARMs have built-in external RAM controllers, so
adding a few MB
of RAM for cache is easy. Some offer DMA.
Yep, though again at the disadvantage of having to do SM.
P.S. I'm looking forward to Energy Micro's
Giant Gecko line with 128K
of RAM on-chip.
Just googled them, looks cool.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
8:25 p.m.
On 5 Dec 2010 at 3:57, Phill Harvey-Smith wrote:
I had considdered that, however this does mean doing
fine pitch smd
work, which whilst not really (yet) a problem for me does serve as a
barrier to some members of this list (and the community in general).
There seems to be more fear than reality. I'm in my "golden years"
with many pairs of glasses (one I use for walking around, another for
computer use, another for reading music, another for electronics
work...) so my vision's hardly optimal and I have terrible depth
perception and congenital nystagmus.
For the *really* small stuff, I use a stereomicroscope which makes
the end of a soldering iron tip look like baseball bat. But I rarely
have need for that.
For QFP microcontrollers on a prototype, I use an adapter to 0.100"
pin spacing (cheap) for the MCU. The remainder of the board can be
through-hole or even wire-wrap.
Easy to solder one, using only a bit of solder wick to grab any
excess. Strangely, it does not take a fine-point soldering iron tip--
I find a broad chisel-tip.
Note that we're not talking about tiny SMD resistors or BGAs here,
but good-sized ICs.
If I can do it, anyone can.
Another option might be a vintage, but faster CPU like an 80C188,
which can be had in PLCC. Still easy to interface to external memory
and other devices. Familiar instruction set.
But, I'm not the one designing this thing or building it. I've got
my own project list to work on. Your opinion, obviously counts the
most.
--Chuck
8:20 p.m.
Chuck Guzis wrote:
P.S. I'm looking forward to Energy Micro's
Giant Gecko line with 128K
of RAM on-chip.
And 1 MB of flash. I'm using a non-giant Gecko (EFM32G280) in one of my
designs, and am hoping to drop in an EFM32GG280F1024 Giant Gecko to get
more memory. An Energy Micro press release of 19-JUL-2010 said
"Detailed datasheets on the Giant Gecko will be released November 1st
2010", but unfortunately that doesn't seem to have happened yet.
9:34 p.m.
On 4 Dec 2010 at 20:20, Eric Smith wrote:
And 1 MB of flash. I'm using a non-giant Gecko
(EFM32G280) in one of
my designs, and am hoping to drop in an EFM32GG280F1024 Giant Gecko to
get more memory. An Energy Micro press release of 19-JUL-2010 said
"Detailed datasheets on the Giant Gecko will be released November 1st
2010", but unfortunately that doesn't seem to have happened yet.
Sure hope it's not one of those "Real Soon Now" releases...
--Chuck
5 Dec
5 Dec
10:48 a.m.
On 12/4/10, Phill Harvey-Smith <afra at aurigae.demon.co.uk> wrote:
The other thing I want this to support is 256 byte
sectors as some old
machines rely on this, a feature which is supported by some of the early
SCSI/SASI to MFM/RLL boards but very few native SCSI drives, this would
be of perticular intrest to some of the Acorn 8 bit machines.
PET as well - the D9060/D9090 drives had a SASI board and either a 5MB
or 7.5MB MFM drive inside (Tandon TM602S or TM603S) that was presented
as 256 byte blocks. The slowness you describe probably wouldn't be a
problem in this system since even the SASI interface on the "DOS
board" is implemented programmatically in 6502 code.
For the near term, it's convenient that one can drop in an ST225
(formatted to 5MB) or an ST251 (formatted to 7.5MB), but a solid-state
drive emulator would still be nice to have.
-ethan
11:10 a.m.
Okay, a faintly related question to this thing with SD cards.
Are USB pen drives any better at leveling wear than SDHCs? The
reason I ask is that there's a USB 2.0 flash driver available for the
inexpensive AVR90USB162 chip that might also work as a SCSI-emulated
device. Any sort of buffering isn't possible, as the chip only has
512 bytes of SRAM. But there are many other inexpensive USB-capable
microcontrollers as well.
--Chuck
12:05 p.m.
On 05/12/2010 19:10, Chuck Guzis wrote:
Okay, a faintly related question to this thing with SD
cards.
Are USB pen drives any better at leveling wear than SDHCs? The
reason I ask is that there's a USB 2.0 flash driver available for the
inexpensive AVR90USB162 chip that might also work as a SCSI-emulated
device. Any sort of buffering isn't possible, as the chip only has
512 bytes of SRAM. But there are many other inexpensive USB-capable
microcontrollers as well.
Also the AVR90USB162 won't do OTG which is what would be required for it
to talk to a flash drive. However it's bigger brother the USB1287 will.
It could be used with the LUFA library, and I see no reason why it
couldn't be used.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
6 Dec
6 Dec
8:29 a.m.
On 12/5/2010 1:10 PM, Chuck Guzis wrote:
Okay, a faintly related question to this thing with SD
cards.
Are USB pen drives any better at leveling wear than SDHCs? The
reason I ask is that there's a USB 2.0 flash driver available for the
inexpensive AVR90USB162 chip that might also work as a SCSI-emulated
device. Any sort of buffering isn't possible, as the chip only has
512 bytes of SRAM. But there are many other inexpensive USB-capable
microcontrollers as well.
--Chuck
I had been wondering the same thing. I did a bit of internet searching
and found that it appears that the controller inside the USB stick does
do some degree of wear leveling. I thought the following URLs were
pretty interesting.
http://www.corsair.com/_faq/FAQ_flash_drive_wear_leveling.pdf
http://www.pcreview.co.uk/forums/thread-1941484.php
http://blog.ironkey.com/?p=595
I had not thought of the fact that wear leveling has security
implications as indicated here. Surely this is not an issue with
vintage systems though.
http://www.truecrypt.org/docs/?s=wear-leveling
Then I wondered about CF and SD, and found that they appear to be wear
leveled internally as well.
http://superuser.com/questions/17350/whats-the-life-expectancy-of-an-sd-card
I must say that all this makes me feel much better about their potential
use as hard drive substitutes in vintage systems. I also learned that
some of the USB drives have a RAM buffer (512 bytes or so), so one might
not even need to worry much about buffering data in a bridge device. I
do wonder what algorithm they use to decide when to write the RAM to
flash - probably varies some by manufacturer. I do think the bridge
should provide a "flash drive busy" indicator to discourage removal of
the flash device while a write is in progress. The built in LED in most
USB drives might suffice for them, but I don't believe I've ever seen
that in a CF or SD card.
Later,
Charlie C.
5 Dec
5 Dec
2:51 p.m.
Atmel and ST have ARM chips which have an SD port (4bits) - and i
suspect there might be others...
Another option are the PIC24 chips. They have a 8/16 bit master slave
port which could be used for the SCSI interface... I think a device
could be made pretty small with a 28 pin MCU and a microSD socket...
Most likely a bit faster than an AVR solution... And small..
Maurice
On Sun, Dec 5, 2010 at 11:48 AM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 12/4/10, Phill Harvey-Smith <afra at
aurigae.demon.co.uk> wrote:
--
I've clicked for peace! Have you?
www.tenmillionclicksforpeace.org/?sid=80760c414LJa5893tG4095162&s=1
The other thing I want this to support is 256
byte sectors as some old
machines rely on this, a feature which is supported by some of the early
SCSI/SASI to MFM/RLL boards but very few native SCSI drives, this would
be of perticular intrest to some of the Acorn 8 bit machines.
PET as well - the D9060/D9090 drives had a SASI board and either a 5MB
or 7.5MB MFM drive inside (Tandon TM602S or TM603S) that was presented
as 256 byte blocks. ?The slowness you describe probably wouldn't be a
problem in this system since even the SASI interface on the "DOS
board" is implemented programmatically in 6502 code.
For the near term, it's convenient that one can drop in an ST225
(formatted to 5MB) or an ST251 (formatted to 7.5MB), but a solid-state
drive emulator would still be nice to have.
-ethan
3:17 p.m.
On 05/12/2010 22:51, maurice smulders wrote:
Atmel and ST have ARM chips which have an SD port
(4bits) - and i
suspect there might be others...
Do you have part numbers ?
Another option are the PIC24 chips. They have a 8/16
bit master slave
port which could be used for the SCSI interface... I think a device
could be made pretty small with a 28 pin MCU and a microSD socket...
Most likely a bit faster than an AVR solution... And small..
With propper 4 bit SD no doubt, talking to it by SPI is always gonna be
slower, but do those chips actually have the SD protocl built in, IIRC
that was one of those you have to sign an NDA and pay $$$/??? to get
hold of :(
I don't think it's the SCSI interface that is slowing the thing down
TBH, I rather suspect that the SPI-SD is the culpret.
You'd also probably need some interface logic between the slave port on
a PIC, between it and the SCSI data lines. Also the AVR I have used has
a usefull feature where you can tag a bunch of pins and generate an
interrupt when any of them changes, this is how I monitor the reset,
SEL, ACK and ATN pins.
I have a version now designed with IDE and SCSI, time to start building
it up on breadboard....
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
6 Dec
6 Dec
10:34 a.m.
Atmel ?and ST
have ARM chips which have an SD port (4bits) - and i
suspect there might be others...
Do you have part numbers ?
11:08 a.m.
On 6 Dec 2010 at 11:34, maurice smulders wrote:
STM32 series
And many ARM9 MCUs also have the facility (and a bunch of others)
such as the NXP LPC3130.
--Chuck
Atmel ?and ST have ARM chips which have an SD port
(4bits) - and i
suspect there might be others...
Do you have part numbers ? 
3:17 p.m.
On 12/05/2010 06:17 PM, Phill Harvey-Smith wrote:
On 05/12/2010 22:51, maurice smulders wrote:
Having used SD on PIC never had to cough up money. The interface is SPI
and the library is not anything special
at last for the SPI interfaced, the 4bit interface I never looked doing
as the project was cheap, not fast.
Atmel and ST have ARM chips which have an SD
port (4bits) - and i
suspect there might be others...
Do you have part numbers ?
Another option are the PIC24 chips. They have a
8/16 bit master slave
port which could be used for the SCSI interface... I think a device
could be made pretty small with a 28 pin MCU and a microSD socket...
Most likely a bit faster than an AVR solution... And small..
With propper 4 bit SD no doubt, talking to it by SPI is always gonna
be slower, but do those chips actually have the SD protocl built in,
IIRC that was one of those you have to sign an NDA and pay $$$/??? to
get hold of :(
I don't think it's the SCSI interface that is
slowing the thing down
TBH, I rather suspect that the SPI-SD is the culpret.
SD is the slow side.
You'd also probably need some interface logic between the slave port
on a PIC, between it and the SCSI data lines. Also the AVR I have used
has a usefull feature where you can tag a bunch of pins and generate
an interrupt when any of them changes, this is how I monitor the
reset, SEL, ACK and ATN pins.
Yes very likely, or use a PIC24 and take advantage of the pin state
change feature in that flavor.
Allison
4912
days inactive
4913
days old
16 comments
8 participants
participants (8)
-
afra＠aurigae.demon.co.uk -
ajp166＠verizon.net -
cclist＠sydex.com -
csquared3＠tx.rr.com -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
maurice.smulders＠gmail.com -
pu1bzz.listas＠gmail.com