SCSI to IDE

Tony Duell ard at p850ug1.demon.co.uk
Wed Dec 1 13:34:30 CST 2010


> 
> 
>     Tony, you live in the seventies ;oD
> 
> > You know as well as I do that the cost of the chip is not the major cost
> > for a 1-off (or small run) project like this.
> 
>     No, but the sum of all chips maybe are :)

OK, I meant the total compoent cost. If that was the primary design 
criterion in all cases, we would have many fewer embedded PCs, for example.

> 
> > You might well have Z80s, EPORms, RAMs, etc in the junk box (I certainly
> > do), but not the latest microcontroller
> 
>     I have many microcontrollers in my junk box, and it doesn't need to be 
> the latest.
> 
> > You may well feel it's a lot easier to solder up a handful of DIL
> > packages on stripboard than a fine-pitch SMD packge that requires you you
> > to design a PCB first . This in turn may entail obtianign suitable CAD
> > tools, something to run them on, and finding a PCB manufacturer (or
> > buying the equipoment to do it at home).
> 
>     :oO
> 
>     - There are microcontrollers powerful enough for this task, and they are 
> all DIP

I do not dispute htat. My main comment was to the poster who suggested an 
ARM-based microocntroller (I have never seen seen such a device in a DIL 
package)

>     - I can design a PCB at home using free tools (Kicad rulez!)

For the nth time, the machien it runs on (and I susepct the OS it runs 
under) are not free. 

>     - I can make boards good enough for fine pitch SMD at home (see my page, 
> http://tabalabs.com.br/eletronica/tts/index.htm) and the equipment is all 
> made from junk.

Excellent (I am not being sarcastic). Hwoever, building that equipment is 
a project in itself (albeit an interesting one). If you just want to make 
up a SCSI-drive rpelacement or whatever, why should you _have_ to make 
the PCB stuff first?

> 
>     Maybe it is time for you to update your prototype methods :)

Why? As I said in anotehr message, thsi is a hobby, why shouldn't I do it 
the way I enjoy?

> 
> > You may well know the assmbly language for the Z80, and have the
> > assembler, etc. Not so fo rthe microcotnroller.
> 
>     I know the asm for the Atmel microcontrollers. Also, I have the original 

Fine. I was ismpoly pointing out that there are people who ar 
expeerienced in (say) Z80 assemblet and not AVR. In which case, for a 
hobby project, why not use the former?

> (and free) assembler from Atmel. BTW, the programmer is also cheap, 5 
> resistors on your parallel port can do the task. BTW, there are lots of 
> compilers for atmel microcontrollers, and they run on windows, DOS and even 
> linux.  Since they are portable, I can do development on my Octane (Irix) or 
> in my PA9000. (still OS-Less)

Looking around, I don;t think I can see _one_ machine here that could be 
used for that. You mention a programmer conissiting of a few resistors 
ona a parellel port. I've  got pletny of GPIB ports here, but I guess 
that's not what you meant. OK, what about an HP9817 with an HP98522 GPIO 
card? It probably could program an Atmel processor, but I'll bet the 
software doesn't exist...

> 
> > It's a darn sight easier to debug something when you know what it should
> > be doing and can see what it is doing. The former is much easier to
> > determine for a Z80 than many modern processors (where the instructions
> > are not necesarily executed one at a time in the order you expect). The
> > latter is also much easier to do on a system with external program memory
> > where you cvan conenct a logic analyser to the ROM address lines.
> 
>     In modern processors I can use cheap debug tools (which are CHEAP, look 
> for the price of the AVR Dragon which is an excellent USB programmer and 
> debugger via 1-wire. Ah, cheaper than my cheap logic analyser). And I can 

OK, so firtly you have to buy this tool [1] and secondly I need a USB 
host to control it. 

[1] You could claim I need to buy the logic analyser too. But a logic 
analyser is a much more general purpose device, useful for many things. 

> use (free) simulators to see the code running on my screen.

I'd much rather know what my hardware is actually doing than what some 
simulator things it's doing. The fewer uncertainties the better!

> 
> > If you want a design to last as long as the classic computer it's
> > connected to, I would certainly go with the Z80 + memory solution. Z80s
> > are very common. The microcontroller may be common _now_, but whata bout
> > next year. There are som many fariants with different memory sizes,
> > internal peripherals, etc that several times I've needed to find a
> > replacement for something made a few years ago onlky to find that that
> > particualr chip is rarere than hen's teeth. Oh, there are 'improved
> > versions', but they are not drop-in replacements.
> 
>     Tell me a microcontroller that was common yesterday and isn't today. 

6303 in one of its many varieants? 7811? COP400? 3870? Do I have to list 
any more?

> > I also feel that this idea of always making everything as cheap as
> > possible is a big mistake. It seems to lead to poorly made products with
> > all sorts of corners cut. As I have said many times before, I can think
> > of plentyy of examples where the cost to do it properly would add perhaps
> > \pounds 1.00 od xomponents. Say that translates into \pounds 10.00 by the
> > time you've added in all the otehr costs. That increase in selling price
> > would not have stopped me buying the product. But when I see how many
> > corners havec been cut, I am not goign to be happy, I am not going to buy
> > any more products from that company, I am goign to tell my friends to
> > look elsewhere too.
> 
>     Of course, as fewer devices on board, lesser problems of design, 
> manufacture and repair I'll have. I'd prefer to use an internal program 

Actually I disagree with that. It's often easier to repari something with 
lots of parts, where yoy only have to replace the one bit that's failed. 
Which would you rather have to fix? An HP9830 (lots of TTL), a Sinclear 
Spectrum (custom ULA) or a modern PC motherboard.

-tony




More information about the cctech mailing list