SCSI to IDE, z-80 conv:Prototype, looking for a project lead

Let me know. Since my SCSI adapter I tried to make FAILED. lol. Can you get the schematics/Code from him? That would be extremely helpful on my end.

just email the guy, he knows of this post.

I was hoping you'd jump in and take the lead!

Let me know. Since my SCSI adapter I tried to make FAILED. lol.

Click to expand...

No failure, you gained valuable knowledge in the attempt and that will be directly applicable to picking up the ball where it was positioned on this other project. Cross pollination of the two strains may lead to a hybrid that works, even in that case that this variant of the project should fail as well.

The National Treasure[/i] Ben Gates"] [paraphrasing Thomas Edison, about invention of light bulb] I didn't fail, I found 2,000 ways how not to make a light bulb; I only need to find one way to make it work.

Click to expand...

HEH! :approve:

Perhaps the designer could be invited on here to spread the word. Obviously if the adapters worked well, he'd have a captive market as I'm sure many of us would buy several @ $20 each, along with the Amiga market too.

JB

that price might just be for the bare PCB, parts might be up to you and extra...

IIRC, that price was for the bare development boards, Production boards would be less, I'm sure Byrd knows that.

Current price of parts calculation for determining an estimated kit price would be an interesting exercise. |)

Original discovery of project by krye: I've been looking into SCSI hard drive alternatives...



p.s. BTW, krye, that topic should have been posted in Peripherals, not in the lounge.

< mod mode >

Any project or subject that's "on topic" for the 68kMLA should be posted anywhere other than the Lounge and Trading Post.

Reasons:

The Lounge, by definition, is meant for OT discussion.

The Trading Post is obviously not the place for such posts, but the other reasons below apply to it as well.

These two forums are Bot Free and invisible to outsiders, therefore:

__It makes it easier for members to internally search for such posts within the barracks for starters, more importantly:

__it makes it possible for the troops to dredge up info in older topics while doing general searches on Google, etc.

__It makes it possible for lurkers to see such posts, so they can enlist in order to join into the discussion if interested or have good info to add.

__It makes it possible, and much more likely, for others who haven't discovered the barracks yet to find us when searching from the outside . . .

. . . yadda, yadda, yadda . . . just do it! :beige:

< /mod mode >

Hi

Thanks for the link as I am able to see the discussion. I am active on vintage-computer.com forums related projects (XT-IDE, AT2XTKBD, etc) and home brew computing projects. However, I am not a "Mac Person" and would not be a suitable fit on a Mac related forum.

There are a vintage-computer.com forum threads to give background on the SCSI to IDE/SD project. It was supposed to be general in nature to support not just Mac but Amiga, Sun, DEC, various synthesizers, sewing machines, photocopiers, test equipment, and a variety of other equipment that are dependent on scarce and rapidly diminishing SCSI-1 drives.

http://www.vintage-computer.com/vcforum/showthread.php?22906-SCSI-1-to-from-IDE-drive-converter/page3&highlight=scsi2ide

http://www.vintage-computer.com/vcforum/showthread.php?24021-Scsi-to-IDE-converter&highlight=scsi2ide

The schematics, PCB layout, debug/monitor software, photos, build instructions, parts lists, etc are found on the N8VEM wiki in the Board Information -> Other -> SCSI to IDE/SD folder. Also the complete KiCAD EDA file set is in the same directory under Other- KiCAD. All information is free (beer & speech) and publicly available.

The SCSI to IDE/SD board is PCB only. The builders would have to assemble the board themselves using commonly available parts from Jameco, Digikey, etc. It is designed to be simple to assemble and reliable. At least the one board that I know to have been built and tested seems to confirm it. However it is still in the prototype phase and would still likely have changes before a final board went to manufacturing.

Please note this is an amateur, volunteer, non-profit, hobbyist project so please be careful to set expectations appropriately at 68kmla. I am not interested in any commercial aspects nor willing to build and test, supply components, partially or fully assembled units, etc. Basically all there is available are the PCBs with design information and any other fellow builders to complete the project.

Thanks and have a nice day!

Andrew Lynch

Heh! Looks like I posted the reasons for keeping discussion out in the open just in time.

Thanks for the link as I am able to see the discussion.

Click to expand...

Welcome aboard as a lurker, Andrew. Thank you very much for your efforts and for being so helpful in this project turnover.

If everything is kept through-hole and socketable as it appears to be in that picture, I'd buy 2! Soldering so easy a caveman could do it. )

After skimming the thread, $50 for a bi-directional bridge adapter? That is awesome! WAY cheaper than the Acard, and a lot more possibilities.

While I would be happy to see *any* workable solution that could be built for a reasonable price, I still think this just screams to be done with an FPGA. A single chip could implement the entire converter, and the design could be changed on the fly by updating the code. Prices are reasonable now and dropping all the time.

this just screams to be done with an FPGA

Click to expand...

As a counterpoint, pre-assembled FPGA dev boards with enough free cells to implement a SCSI host controller + simple microcontroller start at around $50, you'll have to find one that can drive 5v logic (or you'll need to graft on some external circuitry), and it also might be hard to find a cheap one that has enough free I/O pins for the job. (SCSI to SDcard in serial mode... probably not a problem, SCSI to parallel IDE? Problem.) Once you have the design down and can churn out a finished board then the limitations of the dev boards become less important, but realistically you'll probably have to find a mail-order sweatshop that'll do the soldering for you instead of just selling bare boards. I know some people can solder fine-pitch QFPs by hand but I doubt it's *anyone's* idea of a good time.

I'm all for consolidating the unit into something small enough to fit into PowerBooks/Duos some day, but let's get something/anything up and running before worrying about the "best way" do do it in the long run.

techknight an the rest of the tech/dev support troops have a ways to go before we talk about anything "better" than a homebrew kit that is actually working.

If you start with a Z80 based board and work out the code, can it later be moved to an FPGA? Or are these two completely different and incompatible approaches?

Or are these two completely different and incompatible approaches?

Click to expand...

There is free source code available to embed most 8 bit CPUs into a decent size FPGA. (Z-80 cores in particular seem to be a dime a dozen.) So no, there's no technical barrier to developing the board using discrete components, perfecting the firmware, and then synthesizing the whole mess into an FPGA. The difficult part would probably be finding/developing the FPGA code to emulate the SCSI controller chip, not the CPU. There is *one* SCSI chip project listed on opencores.org and it's unfinished/defunct.

I know some people can solder fine-pitch QFPs by hand but I doubt it's *anyone's* idea of a good time.

Click to expand...

Heh, Weirdo.

(Of course, that's just jealousy talking. I'm at the end of the spectrum where I have to take a Valium and breathe into a paper bag for five minutes before I touch a soldering iron to anything I care about, even if it's just pasting in a through-hole DIP socket. Of course, the *really* tense moments came earlier, whilst desoldering snipped pins to make room for the socket in the first place.)

Soldering fine-pitch SMT stuff by hand is a piece of cake, I do it on a regular basis and personally would rather do that than spend the time soldering a gazillion separate pins with a soldering iron. I can understand why many fear it though, it took me a while to take the plunge but once I did I didn't look back.

Search youtube for reflow soldering, there are lots of videos. Dab on the solder paste, plop the parts in place with tweezers and fire up the hotplate (or modified toaster oven). When the paste melts into liquid solder and flows, shut it off and let it cool. Inspect closely for bridges and clean up any that formed with some wick and presto, it's done. If you get a solder template made it's even easier but so far I've only done it by hand. Temperature controlled hotplate cost me about 40 bucks to build but I've seen it done with an electric griddle. Even small scale production runs are possible since depending on the size of the hotplate, numerous boards can be reflowed at once. Different, yes, hard, no.

As I said earlier though, I would love to see *any* dependable, working, open source SCSI-to-whatever converter come onto the scene. Once the basics are done, others can build upon it.

I tell you, every time I see those videos of people deftly dropping an SMT chip on glistening solder pads and instantly forming a perfect bond it reminds me of tasks like juggling or making a pizza crust by spinning and tossing it in the air. Someone who's good at it can make it look so easy, but when you try it yourself... balls flying everywhere, pizza dough on the ceiling, dogs and cats living together, mass hysteria, etc, etc. One of these days I suppose I need to man up and try it.

As to the practicalities of the project itself, if the goal were limited to plain old 5mb/sec "slow SCSI" it's probably *just possible* that you might be able to pull off a converter entirely in software using, say, one of the faster AVR or PIC variants. They can bitbang "pretty fast"... and, look, in fact, someone has actually implemented a SCSI device using them. It's a fairly high parts-count device because he's using discrete 74LS-series parts to buffer the SCSI connector, but other than that it looks pretty simple. It does split out the functions between *two* CPUs, basically one handling the SCSI port and the other acting as "the drive"... it might be worth looking at the source code, as I wouldn't rule out *possibly* being able to compress it down to one if you were using media that natively is "semi-intelligent" and supports LBA, like an SD card.

(Edit: The designer of the RAM disk I linked to has already expanded it into a device which takes a PC card. So basically the work is already done. Converting from PC card to IDE is trivial.)

Newer versions use the 75LVD chip for the SCSI transceivers. I built that guys version into a smaller form factor, but as i said previously it failed. The hardware is proven working in his environment so the only explanation is my board layout wasnt up to par.

I may take a look at this project, but I dont really see any code, has any been developed? is it working? not working? etc...

But i may stick with Micha's idea and just layout a new board being 4 layer. Best way I know to do that....

Or since ive better familiarized with eagle, may just open his existing project file in eagle and rework the board for CF.

I tell you, every time I see those videos of people deftly dropping an SMT chip on glistening solder pads and instantly forming a perfect bond it reminds me of tasks like juggling or making a pizza crust by spinning and tossing it in the air. Someone who's good at it can make it look so easy, but when you try it yourself... balls flying everywhere, pizza dough on the ceiling, dogs and cats living together, mass hysteria, etc, etc.

Click to expand...

LOL, I know what you mean. I used to feel the exact same way until I tried it--it's really not too bad. What makes it all work is the flux, especially if you add more of it. Once you get the hang of it, everything just kind of flows into place on its own. it's way more convenient to do SMT chips than soldering a ton of through hole pins.

Are you sure your board layout is the reason that it failed? Board layout can be critical, but more than once I've been pulling my hair out trying to get something working only to realize I've set one or more of the fusebits wrong in the AVR or plugged something in backwards. Depending on what it's doing, you may be able to tweak things a bit to get a less than perfect PCB layout working. A bypass capacitor tacked on in strategic locations can work wonders. Are you sure you used the correct 74xx parts for the buffer logic? The the letters in the middle, LS, S, ALS, HC, etc matter in many cases.

I built that guys version into a smaller form factor, but as i said previously it failed. The hardware is proven working in his environment so the only explanation is my board layout wasnt up to par.

Click to expand...

I guess hadn't realized that the thing I linked to was the source of the project you'd been working on. (I didn't chase down the old thread.) If I had oodles of time (which I don't) and the appropriate legacy hardware to fiddle with it would be totally fun to try poking at something like this myself; I'm still sort of wondering if it might be possible to compress a working model down to one AVR instead of two. (Doing so would probably come at a significant performance loss, but elderly Macs don't push SCSI particularly hard in the first place.)

I'm saying this completely from ignorance, of course, but looking at the schematic/hardware doc .pdf it appears that the AVR connected to the SCSI PHY is completely dedicated to "low-level bitbanging" the port, doing some simple protocol checks (parity checking?), and communicating "sanitized" data/control words with the "target" AVR over a dedicated high-speed serial bus with control signals. (Which I gather is sort of a communications standard for AVR chips?) I can't help but wonder if you used a single AVR with sufficient SRAM (looks like they're available with up to 8k, vs. the 1k and 4k used here?) if you could timeslice between running the PHY and driving an SD card with the I/O pins you'd otherwise use for inter-AVR communication. I know there can sometimes be significant (and unpredictable) latency when dealing with SD cards, but assuming a Mac has reasonably low expectations and does transfers on a per-sector basis maybe it would be tolerable. "BigMessOWires" talked at length about how the latency of SD cards caused issues with emulating the spinning-disk mechanicals of a floppy drive on his Mac floppy emulator, but SCSI is a higher-level protocol that doesn't have the same constraints. Some of those early SCSI drives (like the ones that were actually an MFM/RLL drive with a converter board) undoubtedly had their own problems with unpredictable latency.

Anyway, blawblawblaw. I don't know snot about AVR programming so don't mind me. I haven't looked at what's actually required from a SCSI PHY, either, so if it has to "automatically" change the state of pins by itself while the "target" CPU is digesting a command it might be an incredibly difficult job to do that "time slicing". It looks like AVRs have the capacity to throw interrupts on pin changes, but I could totally see a problem with "drowning" a single core with interrupt traffic, particularly if there are other devices sharing the SCSI bus.

(Hey, you could use a Propeller! Eight seperate cores!... and probably not enough I/O pins and a few other problems. Never mind.)

Well I am pretty advanced with AVRs, I write alot of weird stuff with AVRs. I have written LED sign controllers, desktop consoles/keypads, Scoreboards, Other various display controllers. Input controllers, Even an MP3 player with IDE support. Then some random systems and control stuff like an Ice machine control board I used an AVR on.

But the problem is, AVR is pretty capped at 20mhz. Some might go higher, but the I/O is limited. That begs the question, Why not use another CPU? why the AVR? Well at the time I was getting into microcontrollers, I had AVRs at hand, and a shitload of them at my fingertips. So I got into programming on the AVR. ASM at first, then BASIC but not C. I should have taken C classes in school but didnt, took basic instead. whoops. Well BASIC will compile on AVR so that works for me. So from that point, I sorta stuck with AVR and became a big AVR fanboy.

Now of course, theres the PIC line too. Which have much higher clock speeds, But they dont have the 1 cycle execution time the AVR has. Maybe newer chips do, I dont know, but PIC is still a choice as they make BASIC compilers for PIC as well.

But with that aside, for these applications, I/O is a big thing.

Propeller would be nice, you can taskroute individual interrupts/subroutines to each core. But the I/O is limited.

HOWEVER.... Something along the lines of a 5V CPLD as an I/O expander would probably be ok. Maybe a dedicated 8-bit parallel bus between the prop and the CPLD, or tie every single available I/O pin on the prop to the CPLD. Who knows. CPLD could provide dual functions. I/O expander and address decoding. You wouldnt need anything as crazy as a FPGA. a Simple CPLD would probably do.

Anyway, Micha's code which my hardware was based on, the 2 AVRs are interconnected via 8-bit parallel bus with some flow control lines, INT/BSY.

James: I tried that, time and time again. I think its the layout as I didnt route the VCC/GND lines sufficiently enough, decoupling caps too far apart. and the CPUs have thier own crystals, 16mhz. Timing should be irrelevent because of the async 8-bit handshake bus. But thats where things fail. The CF card socket didnt pick up the card correctly either, but I havent even gotten to that point yet as I wanted to iron out the bugs.

Also another point to be said, Michas code/design works, is proven. So it has to be me. However in his setup he was using the AHA2940 with linux. I tried AHA2940 and it choked up. So i know its me. If i force parity check off, (fails parity). it will pick up and show the device ID and medium info! but just after the bus release, one of the AVR dies out, wont respond anymore. has to be hard cycled.

But the gadget makes a pretty SCSI activity light though. On a powerbook back when I was debugging it, I set it to the same SCSI ID as the HDD internal. Once the Target sees an ID conflict, it kills itself to avoid it. But the busy LED driven by the SCSI side AVR, still blinks when the HDD is working. lol. so technically the PIA AVR could be a fancy smancy LED activity indicator. lol.

James: I tried that, time and time again. I think its the layout as I didnt route the VCC/GND lines sufficiently enough, decoupling caps too far apart. and the CPUs have thier own crystals, 16mhz. Timing should be irrelevent because of the async 8-bit handshake bus. But thats where things fail. The CF card socket didnt pick up the card correctly either, but I havent even gotten to that point yet as I wanted to iron out the bugs.

Click to expand...

There are some tricks you can try to fix that. It won't be pretty, but it will serve as a proof of concept. Solder some decoupling caps directly across the power pins of each IC. Add additional Vcc/Gnd wires tack soldered from the power and ground input pins to each IC. If you suspect a particular trace is routed too close to something else, cut it at each end and replace it with a piece of wire routed differently. If it works, then it proves that the layout is the only problem. It sounds like you're 90% of the way there, the problems that remain are probably something simple.

In re the shortage of GPIO pins on micros:

Use a micro with inbuilt USB host/USB OTG, and a USB to IDE or CF board (scavenged from a card reader, say). Or skip IDE altogether and use a USB stick.

Now you just need one with that ... and enough pins to bitbang the SCSI side.

Hmm. Still on the IO pin shortage - is dual-ported RAM a possibility? (with parallel IO on one side and serial on the other) I know people use them for A to D and D to A conversion. Or a bunch of mux/demux ICs?

The parity problem I think is because I use a 74 series parity generator, that he used. But i located it clear across the other side of the PCB, with its traces to the transceivers routed around all the other traces, from top to bottom multiple Vias. So, i may have to do a direct connect there.

I should have meandered the traces to make sure all the signals would reach the parity generator at the same time. Oh well.

Sounds good you can count on me for some fund raising, I don't have much these days but I will get some together for you!

I will post this in the thread!

Thanks,

Charles

On Nov 27, 2012, at 7:34 PM, Andrew Lynch wrote:

Hi Charles

Thanks! Actually just keeping the topic alive at 68kmla would be of help in case there is someone there who can and would be able to help us complete the board. This has been an ongoing concern for a couple of years now so I am always looking to boost the team with additional talent. We’ve got great builders on board already but we can always use another set of eyes to help move it along.

Also once this build and test phase is complete I suspect we’ll need another round of prototype boards to incorporate the fixes so far like the termination resistors and a “write prevent” jumper/pull up resistor on the Flash ROM. I think there was another fix that Douglas or someone else found a while back. In any event, there will probably be some minor fund raising for the new boards so some visibility 68kmla, CCTALK, and vintage-computer.com forums would be helpful as well.

I appreciate your interest so far. Thanks and have a happy holidays!

Andrew Lynch

Sent: Tuesday, November 27, 2012 10:46 AM

To: Andrew Lynch

Cc: mouse@netbsd.org; 'RobJ'; jwsmail@jwsss.com; douglas_goodall@mac.com

Subject: Re: SCSI to IDE/SD bridge board project

my personal expertise pretty much ends at assembling a pcb, that I can do.

as far as firmware, I would be pretty much useless, unless someone is motivated enough

to teach me a few things. That would probably detract from the current progress on this project.

In my opinion, it seems like its most of the way there, just needs a little more effort by the right people

and you will have a board that we can all appreciate and seriously use!

Charles

On Nov 24, 2012, at 1:23 PM, Andrew Lynch wrote:

Hi Mouse! If you'd like some help just send an email "reply all" so we can

help share the experiences.

There are many sources for the PLCC-44 sockets and Z80 CPU. Here is Jameco,

Digikey, and Futurlec links but are probably also available locally or

through any other electronic supply house.

PLCC-44 sockets

http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_71618_-1'>http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_71618_-1

http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_71618_-1

http://www.digikey.com/product-detail/en/A-CCS44-Z-R/AE10057-ND/821811

http://www.digikey.com/product-detail/en/8444-11B1-RK-TP/3M4411B1-ND/1026473

http://www.futurlec.com/Sockets/PLCCS44.shtml

Z80 CPU

http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_35705_-1

http://www.digikey.com/product-detail/en/Z84C0008PEG/269-3895-ND/929205

http://www.futurlec.com/ICZ80Series.shtml

Thanks and have a happy holidays!

Andrew Lynch

-----Original Message-----

From: mouse@netbsd.org [mailto:mouse@netbsd.org]

Sent: Saturday, November 24, 2012 11:53 AM

To: Andrew Lynch; RobJ; jwsmail@jwsss.com; douglas_goodall@mac.com;

Subject: Re: SCSI to IDE/SD bridge board project

If there are builders there who would like to work on the SCSI to

IDE/SD bridge project please have them contact me. A suitable builder

would be experienced with electronics project build and test, writing

SCSI and IDE firmware, etc. There are several builders working on the

project already so it won't be like starting from scratch.

One thing Andrew doesn't mention is that an expertise in sourcing parts is

also important. (That's where I'm blocked - I'm having trouble finding

things

like the PGA socket for the SCSI chip, or for that matter a Z80, as

opposed to

any of numerous extended-in-various-ways

Z80 variants.)

/~\ The ASCII Mouse

\ / Ribbon Campaign

X Against HTML mouse@rodents-montreal.org

/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

What things are you having trouble finding? If you have a list of ICs, connectors, and what not, I can check my local parts stores. I have 2 or 3 here in my immediate area with all sorts of bits and bobs. I'm not technically minded, but I wouldn't mind helping by sourcing parts.