Thread
SCSI to IDE, z-80 conv:Prototype, looking for a project lead
There was a thread on 68KMLA that originally talked about this board,
it was the board that used age appropriate parts.
Board is not ready yet, They are $20 bucks a piece, he has 4 PCB's left.
Here is his email to me:
--------------------------------------------------------------
Sorry for the late reply.
Yes, there are four of the SCSI to IDE PCBs left. Are you interested in building a prototype? I know the board works well enough to run a basic debug monitor but needs a project lead with enough skills and experience to complete build and test and also work on the firmware.
The PCBs are normally $20 each plus shipping but if there is a project lead volunteer or someone who can bring this to completion, I will send them a PCB for free.
Thanks and have a nice day!
Andrew Lynch - LYNCHAJ@YAHOO.COM
----------------------------------------------------------
I wouldn't be much help on this project,
i bet some of you might be, if you are interested?
it was the board that used age appropriate parts.
Board is not ready yet, They are $20 bucks a piece, he has 4 PCB's left.
Here is his email to me:
--------------------------------------------------------------
Sorry for the late reply.
Yes, there are four of the SCSI to IDE PCBs left. Are you interested in building a prototype? I know the board works well enough to run a basic debug monitor but needs a project lead with enough skills and experience to complete build and test and also work on the firmware.
The PCBs are normally $20 each plus shipping but if there is a project lead volunteer or someone who can bring this to completion, I will send them a PCB for free.
Thanks and have a nice day!
Andrew Lynch - LYNCHAJ@YAHOO.COM
----------------------------------------------------------
I wouldn't be much help on this project,
i bet some of you might be, if you are interested?
I was hoping you'd jump in and take the lead! 
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.
HEH! :approve:
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 >
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
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
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.
) 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.
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.
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.
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.
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.)
(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.
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.)
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 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.
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 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.
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.
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.
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.
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.
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
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.
Subject: Re: SCSI to IDE/SD bridge board project
Date: December 4, 2012 11:21:32 PM EST
To: RobJ , jwsmail@jwsss.com, douglas_goodall@mac.com, Andrew Lynch
|| There are many sources for the PLCC-44 sockets and Z80 CPU.
I was sure there would be; I was just having trouble finding them - and
being reasonably sure what I'd found was the right thing.
|| Here is Jameco, Digikey, and Futurlec links but are probably also
|| available locally or through any other electronic supply house.
Thank you! The Web URLs themselves are of little use (Jameco and
Digikey, in particular, have improved their websites to the point where
they refuse to work at all for me; Futurlec may work, even though
they're in the US - I need to investigate further), but the part
numbers embedded within some of them are very helpful.
|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.
Well, speaking personally, the project is not "get this piece of
electronics working as soon as possible, everything else can fall by
the wayside". I consider things like helping you people to the extent
that I can and you want to to be a perfectly fine part of it.
/~\ 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
Date: December 4, 2012 11:21:32 PM EST
To: RobJ , jwsmail@jwsss.com, douglas_goodall@mac.com, Andrew Lynch
|| There are many sources for the PLCC-44 sockets and Z80 CPU.
I was sure there would be; I was just having trouble finding them - and
being reasonably sure what I'd found was the right thing.
|| Here is Jameco, Digikey, and Futurlec links but are probably also
|| available locally or through any other electronic supply house.
Thank you! The Web URLs themselves are of little use (Jameco and
Digikey, in particular, have improved their websites to the point where
they refuse to work at all for me; Futurlec may work, even though
they're in the US - I need to investigate further), but the part
numbers embedded within some of them are very helpful.
|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.
Well, speaking personally, the project is not "get this piece of
electronics working as soon as possible, everything else can fall by
the wayside". I consider things like helping you people to the extent
that I can and you want to to be a perfectly fine part of it.
/~\ 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
I’m very aware of the board capabilities and that is using sudo-DMA. I have the Z53C80 working on my Heathkit system (picture attached) using the sudo-DMA capability but it is running under the 8051 core.
On 1/6/13 4:12 PM, "alan@alanlee.org" wrote:
Few clarifications:
1) There is no termination - passive or active - on the current board design. You will need to use external termination resistor packs at the ends of the chain.
2) The Z53C80 is essentially just a PHY. It has no intelligence beyond a simple DMA initiator and counter to allow a bus master to sequentially clock out/in a series of data bytes to/from the bus. Beyond that it presents just a simple register interface to allow cycle status to be read and set and generate an interrupt on change.
3) The DMA feature is not connected as there is no DMA engine on the current board.
Bascially it's a Z80, 32K RAM, 32K ROM, UART, SCSI PHY, and bit-bangable IDE, SD card, and SCSI.
-Alan
On January 6, 2013 at 6:53 PM Norberto Collado wrote: > Hello Andrew, > > How much it will cost to get a SCSI2IDE pcb board along with the external > termination and any rework instructions? If you are planning to spin the > board, please add the termination resistors along with the termination > diode. Also add a 3 POSITION 6 PIN SLIDE DIP SWITCH to select target SCSI ID > during arbitration if possible. The target ID could be code hardwire and I > think this is the design intend. I will be interested on this new pcb board. > > Now that our Z67-IDE+ SCSI/SASI board is fully functional, I will have > "some" cycles to play with the SCSI2IDE board in target mode to enable it to > work with our Heathkit systems. Not sure what this group has accomplished so > far in FW to leverage, but the plan will be to do the following; > > 1. Enable the Serial Port for debugging > 2. Enable the 82C55 to write and read to the CF card or IDE drives via the > serial port (Pressing the "ESC" key enables the Menu). On power-on it will > scan the IDE bus and display hard drive information and slave ID. > 3. Enable the Z53C80 arbitration and to read and write to the CF card or IDE > drive > 4. Test and debug with the Heathkit systems to support SASI commands. Boot > HDOS and CP/M. > 4. Test and debug with the PC via Windows XP to support required SCSI-1 > commands. Boot Windows. > 5. Write code in assembly language. I will like to leverage on any code > already writing to support such board if possible. > > On the SD support, I will pass due to lack of experience in using it. > Perhaps next year! > > I'm not sure how the Zapple code comes into play with the SCSI2IDE board!!! > Does it allows me to download the hex file to the board via the serial port? > > Is there information on the board Memory/IO map and Interrupts? > > Also I see two 50 pin connectors, one for the SCSI-1 connection, but I'm > confused on the second 50 pin connector and its intend. > > Thanks, > > Norberto > > > > On 1/6/13 6:21 AM, "Andrew Lynch" wrote: > > > Hi Douglas! Thanks! Yes, I think adding the SCSI to IDE/SD to the existing > > N8VEM SVN tree would be a good idea. Maybe it would help elevate the > > visibility of the project a bit. > > > > We've made some real progress on this project in recent months and I would > > like to see if finally come to fruition. Every day that goes by diminishes > > the amount of real SCSI-1 drives remaining for the vintage/legacy/classic > > computers. Especially Wayne has made real progress checking out the IO > > subsystems so I am feeling good we can make this work. > > > > So far, I think the SCSI to IDE/SD needs a couple of hardware changes. > > First the U33 footprint needs to fixed (done) and optional pull-up resistors > > on the SCSI pins (next hardware version). However these are easily worked > > around with the existing prototypes. I think the key to getting over the > > rest of the issues on the board is to the Z53C80 SCSI controller. Assuming > > it is responsive and functioning writing the Z80 assembler code to use the > > SCSI controller in target mode is going to be a big job. > > > > Thanks and have a nice day! > > > > Andrew Lynch > > > > -----Original Message----- > > From: Douglas W. Goodall [mailto:douglas_goodall@mac.com] > > Sent: Tuesday, January 01, 2013 9:17 PM > > To: Andrew Lynch > > Subject: Re: lost emails on SCSI to IDE/SD converter project > > > > On 1/1/2013 5:42 PM, Andrew Lynch wrote: > >> Hi Douglas! Thanks! Rob is working on his SCSI to IDE/SD prototype > > board > >> and having some issues getting it started. > > I have been in contact with Rob on and off. > >> Does the current Zapple debug > >> monitor require either of the UART or the Z53C80 to be present in > >> order to boot? I don't think so but would like to double check. > > I have a vague recollection that having a UART is helpful if you want to > > interact with Zapple. > > > > I don't think that Zapple does anything with the SCSI chip though. > > > > Attached is the source code of the version of Zapple for the SCSI2IDE board, > > and the binary, and the doc (pdf). > > > > I think we should have an svn repository for the SCSI2IDE project, so that > > the various people working on it can post their work, both to take advantage > > of source code control, but also so we can access each other's work > > > > Files having to do with the project are in the wiki, here... > > http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=SCSI%20to%20IDE > > %2FSD%20prototypes > > > > By the way, I am happy to provide a SCSI I Terminator to any of the people > > working on the project for free. > > I just want to ask for shipping. You can announce this if you like. > > > > Thoughts? > > > > Respectfully, > > Douglas > > > > P.S. I am working with Wayne on the SCSI2IDE firmware. I just sent him a > > Micropolis SCSI I Hard Drive in a powered chassis to use as a SCSI I > > reference subsystem. I am also working on a modest operating system for the > > board. > > > > > >> It sounds like Rob's 8255 is broken although there may be an issue > >> with the PCB or some other part. I reworked the PCB and fixed a bunch > >> of problems but who knows what's still lurking in there. > >> > >> Thanks and have a Happy New Year! > >> > >> Andrew Lynch > >> > >>> -----Original Message----- > >>> From: Douglas W. Goodall [mailto:douglas_goodall@mac.com] > >>> Sent: Tuesday, January 01, 2013 6:44 PM > >>> To: Andrew Lynch > >>> Subject: Re: lost emails on SCSI to IDE/SD converter project > >>> > >>> Andrew, > >>> > >>> I have all the email traffic saved. Can you describe what your missing? > >>> > >>> I will dig it up and provide it. Assuming the emails in question came > >>> my > >> way > >>> originally. > >>> > >>> I will send a picture of the SCSI board signon asap. > >>> > >>> Douglas > >> > > > >
Yes, pin 26 TERMPWR should not be connected to VCC and left open; great catch. On the other pins stated below based on the NCR documentation;
“On the single-ended signals, all odd numbered lines plus 20, 22, 24, 28, 30 and 34 are connected to ground on the controller and pin 25 is left open”.
Norberto
On 1/10/13 5:02 PM, "Alan Hightower" wrote:
I'm not sure where the last wiki update came from but it points out a problem. Pin 26 should not and cannot be a board power supply. It is termination power only. If you have a long cable with passive networks at both ends, SCSI supply is only guaranteed to provide enough power to handle peak switching loads from the pull ups. There's some margin but not enough to handle the hundreds of mV the emulator board pulls. If someone tries to power their emulator from it, they will eventually burn up the termination reg on their host controller.
Also pin 25 should be left un connected and not to ground. I've seen devices short pin 25 and 26 together. Pins 23, 24, 27, and 28 should also be open.
-Alan
Sent from my iPad
On Jan 10, 2013, at 7:26 PM, "Andrew Lynch" wrote:
Thank you very much Wayne! Your efforts have tremendously moved the S2I project forward! The wiki page is great!
All the recent interest has caused a bit of upsurge in interest in the S2I project in general. So far I have sent out three of the remaining four prototype PCBs. Hopefully this means we can continuing build and test and get some more diverse working systems out there to “shake down” the prototypes.
I really appreciate your leadership on the S2I project. This is going to benefit the wider hobbyist/vintage/classic computer community for many years to come.
Thank you!
Andrew Lynch
From: Wayne Warthen [mailto:wwarthen@gmail.com]
Sent: Thursday, January 10, 2013 1:03 AM
To: Andrew Lynch
Cc: Norberto Collado; Douglas Goodall; mouse@netbsd.org; Charles Phillips; jwsmail@jwsss.com; Alan Hightower; leonb@swiftdsl.com.au; nestor ruiz; Clem Maloney; Geoffrey Reed; Matthew Hudson; Ryan Wallmow; cotsco@frontiernet.net; Miro Svetlik; ..I'd rather be coding ASM!; Bob Devries; Marc Holz; Mark H. James; Mark Martin; RobJ; Bob Grieb
Subject: Re: lost emails on SCSI to IDE/SD converter project
Hi Folks,
I have posted a couple things to the Wiki tonight.
The file http://n8vem-sbc.pbworks.com/w/page/62549548/S2I%20Status is a document describing the status of the S2I Firmware Project. It includes how to build and use the firmware. It needs a lot more work, but should get folks going.
More importantly, the file http://n8vem-sbc.pbworks.com/w/file/62549540/S2I%20Firmware.zip is an archive with the firmware source and full build environment along with the current firmware build.
Everything is still really rough, but the rate of progress on this seems to be increasing. The firmware is definitely now monitoring the SCSI bus and appears to be accurately following bus signals. In theory, I am only a few hours away from adding enough code to prove that a SCSI command/response can be completed. See below for a sample of a test run of the firmware.
Contributions of any kind are welcome!
Thanks,
Wayne
“On the single-ended signals, all odd numbered lines plus 20, 22, 24, 28, 30 and 34 are connected to ground on the controller and pin 25 is left open”.
Norberto
On 1/10/13 5:02 PM, "Alan Hightower" wrote:
I'm not sure where the last wiki update came from but it points out a problem. Pin 26 should not and cannot be a board power supply. It is termination power only. If you have a long cable with passive networks at both ends, SCSI supply is only guaranteed to provide enough power to handle peak switching loads from the pull ups. There's some margin but not enough to handle the hundreds of mV the emulator board pulls. If someone tries to power their emulator from it, they will eventually burn up the termination reg on their host controller.
Also pin 25 should be left un connected and not to ground. I've seen devices short pin 25 and 26 together. Pins 23, 24, 27, and 28 should also be open.
-Alan
Sent from my iPad
On Jan 10, 2013, at 7:26 PM, "Andrew Lynch" wrote:
Thank you very much Wayne! Your efforts have tremendously moved the S2I project forward! The wiki page is great!
All the recent interest has caused a bit of upsurge in interest in the S2I project in general. So far I have sent out three of the remaining four prototype PCBs. Hopefully this means we can continuing build and test and get some more diverse working systems out there to “shake down” the prototypes.
I really appreciate your leadership on the S2I project. This is going to benefit the wider hobbyist/vintage/classic computer community for many years to come.
Thank you!
Andrew Lynch
From: Wayne Warthen [mailto:wwarthen@gmail.com]
Sent: Thursday, January 10, 2013 1:03 AM
To: Andrew Lynch
Cc: Norberto Collado; Douglas Goodall; mouse@netbsd.org; Charles Phillips; jwsmail@jwsss.com; Alan Hightower; leonb@swiftdsl.com.au; nestor ruiz; Clem Maloney; Geoffrey Reed; Matthew Hudson; Ryan Wallmow; cotsco@frontiernet.net; Miro Svetlik; ..I'd rather be coding ASM!; Bob Devries; Marc Holz; Mark H. James; Mark Martin; RobJ; Bob Grieb
Subject: Re: lost emails on SCSI to IDE/SD converter project
Hi Folks,
I have posted a couple things to the Wiki tonight.
The file http://n8vem-sbc.pbworks.com/w/page/62549548/S2I%20Status is a document describing the status of the S2I Firmware Project. It includes how to build and use the firmware. It needs a lot more work, but should get folks going.
More importantly, the file http://n8vem-sbc.pbworks.com/w/file/62549540/S2I%20Firmware.zip is an archive with the firmware source and full build environment along with the current firmware build.
Everything is still really rough, but the rate of progress on this seems to be increasing. The firmware is definitely now monitoring the SCSI bus and appears to be accurately following bus signals. In theory, I am only a few hours away from adding enough code to prove that a SCSI command/response can be completed. See below for a sample of a test run of the firmware.
Contributions of any kind are welcome!
Thanks,
Wayne
*** hey guys, if you have any spare cash to throw toward this project, the main man is in need, anything will help at this point.
----->
Hi Charles! I think we are getting close to a S2I demonstration in the near future. I would like to respin the prototype board with all the fixes so far and get another small batch of 10 for the builders. There have been many improvements such as optional termination, fixed SCSI connection, new option jumpers, better layout, etc.
Would you be able to do some fund raising on 68KMLA? A bunch of $5 and $10 donations would go a long way. As a rough estimate I’ll need about $200 for 10 new PCBs. It normally takes about three weeks from time of delivery. I would prefer to provide the boards to the builders for free since it is using their time to build and test. Otherwise I’ll provide the PCBs as normal N8VEM boards ($20 each) to cover expenses.
I think these PCBs are going to be close to if not fully production representative. Hopefully they will be very helpful for those vintage 68K Macs, Amiga 1000’s, Atari ST’s, ancient DEC’s, etc who depend on SCSI-1 drives. You can gather the funds or just have them send to me at LYNCHAJ@YAHOO.COM (PayPal) with “S2I prototype boards fund” in the subject line.
Any and all help greatly appreciated. Thanks and have a nice day!
Andrew Lynch
----->
Hi Charles! I think we are getting close to a S2I demonstration in the near future. I would like to respin the prototype board with all the fixes so far and get another small batch of 10 for the builders. There have been many improvements such as optional termination, fixed SCSI connection, new option jumpers, better layout, etc.
Would you be able to do some fund raising on 68KMLA? A bunch of $5 and $10 donations would go a long way. As a rough estimate I’ll need about $200 for 10 new PCBs. It normally takes about three weeks from time of delivery. I would prefer to provide the boards to the builders for free since it is using their time to build and test. Otherwise I’ll provide the PCBs as normal N8VEM boards ($20 each) to cover expenses.
I think these PCBs are going to be close to if not fully production representative. Hopefully they will be very helpful for those vintage 68K Macs, Amiga 1000’s, Atari ST’s, ancient DEC’s, etc who depend on SCSI-1 drives. You can gather the funds or just have them send to me at LYNCHAJ@YAHOO.COM (PayPal) with “S2I prototype boards fund” in the subject line.
Any and all help greatly appreciated. Thanks and have a nice day!
Andrew Lynch
**** read above post **** This project Needs some cash to move this project forward,
(Its finally aggressively moving along)
(I just sent the most I could humanly come up with because I feel the priority of this project is very high)
To: LYNCHAJ@YAHOO.COM
Amount: $50.00 USD
Sent on: January 14, 2013
Subject line of your payment email: S2I prototype boards fund
Message in your payment email: I sent you about the most I (personally) can scrounge up this month, thanks sir hope it helps. This project is really top priority! I can't think of any single project that has more real world use then this.
(Its finally aggressively moving along)
(I just sent the most I could humanly come up with because I feel the priority of this project is very high)
To: LYNCHAJ@YAHOO.COM
Amount: $50.00 USD
Sent on: January 14, 2013
Subject line of your payment email: S2I prototype boards fund
Message in your payment email: I sent you about the most I (personally) can scrounge up this month, thanks sir hope it helps. This project is really top priority! I can't think of any single project that has more real world use then this.
** read above posts if you can donate, please do. **
-------- Original Message --------
Subject: RE: lost emails on SCSI to IDE/SD converter project
Date: Mon, 14 Jan 2013 21:03:42 -0500
From: "Andrew Lynch"
To: "'Ryan Wallmow'"
Cc: "'Rob Jarratt'" , "'Wayne Warthen'" , "'Norberto Collado'" , "'Douglas Goodall'" , , , , "'nestor ruiz'" , "'Clem Maloney'" , "'Geoffrey Reed'" , "'Matthew Hudson'" , , "'Miro Svetlik'" , "'..I'd rather be coding ASM!'" , "'Bob Devries'" , "'Marc Holz'" , "'Mark H. James'" , "'Mark Martin'" , "'Bob Grieb'"
Thank you Charles! I very much appreciate your efforts!
Have a nice day!
Andrew Lynch
SENT: Monday, January 14, 2013 5:07 PM
TO: Ryan Wallmow
CC: Rob Jarratt; Wayne Warthen; Andrew Lynch; Norberto Collado; Douglas
Goodall; mouse@netbsd.org; jwsmail@jwsss.com; Alan Hightower;
leonb@swiftdsl.com.au; nestor ruiz; Clem Maloney; Geoffrey Reed; Matthew
Hudson; cotsco@frontiernet.net; Miro Svetlik; ..I'd rather be coding
ASM!; Bob Devries; Marc Holz; Mark H. James; Mark Martin; Bob Grieb
SUBJECT: Re: lost emails on SCSI to IDE/SD converter project
i am trying hard to get some more donations for this project!
On Jan 14, 2013, at 5:04 PM, Ryan Wallmow wrote:
With all this talk lately, I might have to work on mine again, I left
mine with all the sockets installed, but I hadn't yet started to
purchase components due to lack of funds and time, now that things have
changed, it gives me reason to go for it again ;-)
Good work everyone!
On Mon, Jan 14, 2013 at 3:58 PM, Rob Jarratt wrote:
This sounds like great progress! I need to find my last component and
then work out how to use the programmer to get the board to do something
(and find the time to do it!)
Regards
Rob
FROM: Wayne Warthen [mailto:wwarthen@gmail.com [2]]
SENT: 14 January 2013 02:22
TO: Andrew Lynch
CC: Norberto Collado; Douglas Goodall; mouse@netbsd.org [3]; Charles
Phillips; jwsmail@jwsss.com [4]; Alan Hightower; leonb@swiftdsl.com.au
[5]; nestor ruiz; Clem Maloney; Geoffrey Reed; Matthew Hudson; Ryan
Wallmow; cotsco@frontiernet.net [6]; Miro Svetlik; ..I'd rather be
coding ASM!; Bob Devries; Marc Holz; Mark H. James; Mark Martin; RobJ;
Bob Grieb
SUBJECT: Re: lost emails on SCSI to IDE/SD converter project
More progress this weekend. Still a long way to go, but this is good
stuff. I have been able to exchange data with a host initiator to the
point where the host knows the target is there and basic information
like it's name and capacity. Here are links to some pictures I just
posted on the Wiki. I can see the host asking for a "READ DATA" command
now, but have not had time to implement it, but very close.
LUN Discovery.jpg shows my test harness (Sergey's Xi8088 running a
Future Domain SCSI Controller). Notice that the SCSI device has been
detected and identified!
By the way, I am desperately seeking a good SCSI-1 reference...
Thanks,
Wayne
-------- Original Message --------
Subject: RE: lost emails on SCSI to IDE/SD converter project
Date: Mon, 14 Jan 2013 21:03:42 -0500
From: "Andrew Lynch"
To: "'Ryan Wallmow'"
Cc: "'Rob Jarratt'" , "'Wayne Warthen'" , "'Norberto Collado'" , "'Douglas Goodall'" , , , , "'nestor ruiz'" , "'Clem Maloney'" , "'Geoffrey Reed'" , "'Matthew Hudson'" , , "'Miro Svetlik'" , "'..I'd rather be coding ASM!'" , "'Bob Devries'" , "'Marc Holz'" , "'Mark H. James'" , "'Mark Martin'" , "'Bob Grieb'"
Thank you Charles! I very much appreciate your efforts!
Have a nice day!
Andrew Lynch
SENT: Monday, January 14, 2013 5:07 PM
TO: Ryan Wallmow
CC: Rob Jarratt; Wayne Warthen; Andrew Lynch; Norberto Collado; Douglas
Goodall; mouse@netbsd.org; jwsmail@jwsss.com; Alan Hightower;
leonb@swiftdsl.com.au; nestor ruiz; Clem Maloney; Geoffrey Reed; Matthew
Hudson; cotsco@frontiernet.net; Miro Svetlik; ..I'd rather be coding
ASM!; Bob Devries; Marc Holz; Mark H. James; Mark Martin; Bob Grieb
SUBJECT: Re: lost emails on SCSI to IDE/SD converter project
i am trying hard to get some more donations for this project!
On Jan 14, 2013, at 5:04 PM, Ryan Wallmow wrote:
With all this talk lately, I might have to work on mine again, I left
mine with all the sockets installed, but I hadn't yet started to
purchase components due to lack of funds and time, now that things have
changed, it gives me reason to go for it again ;-)
Good work everyone!
On Mon, Jan 14, 2013 at 3:58 PM, Rob Jarratt wrote:
This sounds like great progress! I need to find my last component and
then work out how to use the programmer to get the board to do something
(and find the time to do it!)
Regards
Rob
FROM: Wayne Warthen [mailto:wwarthen@gmail.com [2]]
SENT: 14 January 2013 02:22
TO: Andrew Lynch
CC: Norberto Collado; Douglas Goodall; mouse@netbsd.org [3]; Charles
Phillips; jwsmail@jwsss.com [4]; Alan Hightower; leonb@swiftdsl.com.au
[5]; nestor ruiz; Clem Maloney; Geoffrey Reed; Matthew Hudson; Ryan
Wallmow; cotsco@frontiernet.net [6]; Miro Svetlik; ..I'd rather be
coding ASM!; Bob Devries; Marc Holz; Mark H. James; Mark Martin; RobJ;
Bob Grieb
SUBJECT: Re: lost emails on SCSI to IDE/SD converter project
More progress this weekend. Still a long way to go, but this is good
stuff. I have been able to exchange data with a host initiator to the
point where the host knows the target is there and basic information
like it's name and capacity. Here are links to some pictures I just
posted on the Wiki. I can see the host asking for a "READ DATA" command
now, but have not had time to implement it, but very close.
LUN Discovery.jpg shows my test harness (Sergey's Xi8088 running a
Future Domain SCSI Controller). Notice that the SCSI device has been
detected and identified!
By the way, I am desperately seeking a good SCSI-1 reference...
Thanks,
Wayne
Even $5 bucks would help, this project is hot.
Need to get on it, while the Firmware/Hardware guys are motivated.
LYNCHAJ@YAHOO.COM (PayPal) with “S2I prototype boards fund” in the subject line.
Need to get on it, while the Firmware/Hardware guys are motivated.
LYNCHAJ@YAHOO.COM (PayPal) with “S2I prototype boards fund” in the subject line.
Hi Folks,
Just another quick progress report. I managed to get a few hours of uninterrupted time yesterday and continued to have more success.
Although the code is a complete disaster, I now have full read/write functionality. I am running the SCSI2IDE from my Xi 8088 with a Future Domain adapter that has a boot ROM. I am able to run DOS from the SDSI2IDE with no problems. Reading and writing data between the host and my CF card seems to be rock solid. I even ran an Adaptec utility that does a read/write test and it worked fine. At present, I am dumping a lot of diagnostics with every command including portions of data, so it is very slow. Additionally, I have not implemented the pseudo-dma mode. I am nowhere near working on performance -- that comes last.
The only anomaly I have observed is that DOS 6.22 FDISK reports "No space for DOS partition on drive" when I try to use it to create a primary partition. However, I am completely successful if I use DOS 3.3 FDISK to create the partition, then use DOS 6.22 to format the partition and make it bootable. I see odd command requests from the host when trying to use DOS 6.22 FDISK to create the partition and suspect there is something about the ROM in my adapter that is problematic for newer versions of DOS. To be clear, the command requests are valid SCSI commands, it is just that they don't make sense given what FDISK is supposed to be doing.
I will try to get the code straightened out enough to post an update on the Wiki in the next few days. We are very close to the point where it will be helpful to get others running this "alpha" code on a variety of different systems for compatibility testing. I'm hoping some of you folks can help with that.
Thanks,
Wayne
Just another quick progress report. I managed to get a few hours of uninterrupted time yesterday and continued to have more success.
Although the code is a complete disaster, I now have full read/write functionality. I am running the SCSI2IDE from my Xi 8088 with a Future Domain adapter that has a boot ROM. I am able to run DOS from the SDSI2IDE with no problems. Reading and writing data between the host and my CF card seems to be rock solid. I even ran an Adaptec utility that does a read/write test and it worked fine. At present, I am dumping a lot of diagnostics with every command including portions of data, so it is very slow. Additionally, I have not implemented the pseudo-dma mode. I am nowhere near working on performance -- that comes last.
The only anomaly I have observed is that DOS 6.22 FDISK reports "No space for DOS partition on drive" when I try to use it to create a primary partition. However, I am completely successful if I use DOS 3.3 FDISK to create the partition, then use DOS 6.22 to format the partition and make it bootable. I see odd command requests from the host when trying to use DOS 6.22 FDISK to create the partition and suspect there is something about the ROM in my adapter that is problematic for newer versions of DOS. To be clear, the command requests are valid SCSI commands, it is just that they don't make sense given what FDISK is supposed to be doing.
I will try to get the code straightened out enough to post an update on the Wiki in the next few days. We are very close to the point where it will be helpful to get others running this "alpha" code on a variety of different systems for compatibility testing. I'm hoping some of you folks can help with that.
Thanks,
Wayne
Woo Hoo! I am doing somersaults and back flips with joy! This is GREAT!
Wayne are you able to boot your PC using the S2I? It sounds like you can.
This is really fantastic news! Booting MS-DOS 3.3 basically proves this is working beyond any doubt.
Are you using the latest ROM for the Future Domain SCSI adapter?
It may be one of the earlier ones. I recall there are problems with some of the versions. I am assuming you have a Future Domain TMC-850?
http://www.vintage-computer.com/vcforum/archive/index.php/t-2178.html
However, I would not get worried about the TMC-850, if MS-DOS 3.3 boots and works OK then we are good.
Yes, soon the compatibility testing begins in earnest. I would like to see the board spread out to other machines for gather compatibility testing.
Once you are ready, I would like to start recruiting some Mac and Amiga fans to do some compatibility testing. I am sure they’ll throw some real curve balls.
THANK YOU THANK YOU THANK YOU THANK YOU!
Great job! You just made my day! Have a nice day!
Andrew Lynch
Wayne are you able to boot your PC using the S2I? It sounds like you can.
This is really fantastic news! Booting MS-DOS 3.3 basically proves this is working beyond any doubt.
Are you using the latest ROM for the Future Domain SCSI adapter?
It may be one of the earlier ones. I recall there are problems with some of the versions. I am assuming you have a Future Domain TMC-850?
http://www.vintage-computer.com/vcforum/archive/index.php/t-2178.html
However, I would not get worried about the TMC-850, if MS-DOS 3.3 boots and works OK then we are good.
Yes, soon the compatibility testing begins in earnest. I would like to see the board spread out to other machines for gather compatibility testing.
Once you are ready, I would like to start recruiting some Mac and Amiga fans to do some compatibility testing. I am sure they’ll throw some real curve balls.
THANK YOU THANK YOU THANK YOU THANK YOU!
Great job! You just made my day! Have a nice day!
Andrew Lynch
Yes, this is going very well.
Yes, I can use DOS 3.3 on Xi 8088 to partition, format, and boot from SCSI2IDE. Fully functional in all respects, just a bit slow due to rampant diagnostic messaging at this time to the serial port. I can format and boot on DOS 6.22, but have issues just with FDISK. I owe Norberto a log, but have run out of time today...
I am using the a TMC-860 with ROM v6.01. If there are sources of newer/different versions of the ROM, I will happily try them. I will mention that the ST125N disk Douglas provided me DOES work with this setup including FDISK. So, it is probably something that can be resolved, but unfortunately, I cannot actually see the command flow between the ST125N and my Xi 8088.
I have just posted my latest firmware on the Wiki. I am indeed ready for others to start doing some very preliminary compatibility testing. I need to know what areas of the protocol might need work and it will likely vary between hosts. We need to caveat everything with saying that it is very slow right now. Gobs of diagnostics and I have not even implemented pseudo-dma.
Thanks,
Wayne
Yes, I can use DOS 3.3 on Xi 8088 to partition, format, and boot from SCSI2IDE. Fully functional in all respects, just a bit slow due to rampant diagnostic messaging at this time to the serial port. I can format and boot on DOS 6.22, but have issues just with FDISK. I owe Norberto a log, but have run out of time today...
I am using the a TMC-860 with ROM v6.01. If there are sources of newer/different versions of the ROM, I will happily try them. I will mention that the ST125N disk Douglas provided me DOES work with this setup including FDISK. So, it is probably something that can be resolved, but unfortunately, I cannot actually see the command flow between the ST125N and my Xi 8088.
I have just posted my latest firmware on the Wiki. I am indeed ready for others to start doing some very preliminary compatibility testing. I need to know what areas of the protocol might need work and it will likely vary between hosts. We need to caveat everything with saying that it is very slow right now. Gobs of diagnostics and I have not even implemented pseudo-dma.
Thanks,
Wayne
There is S2I information on the N8VEM wiki here including a parts list.
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=SCSI%20to%20IDE%2FSD%20prototypes
At the moment it is just the name of the parts although as the number of working boards grows I suspect we'll get a more detailed parts list. It depends a bit on the style of the builder and what parts they already have available. It is a fairly simple design so there is a lot of latitude regarding parts. Everything should be available at Digikey, Jameco, Mouser, etc. The Z53C80 is available at Digikey for sure plus eBay and UTsource.net plus other distributors. That's probably the most challenging part and that's fairly common still.
I hope this helps! Please let me know if you have any other questions! Thanks and have a nice day!
Andrew Lynch
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=SCSI%20to%20IDE%2FSD%20prototypes
At the moment it is just the name of the parts although as the number of working boards grows I suspect we'll get a more detailed parts list. It depends a bit on the style of the builder and what parts they already have available. It is a fairly simple design so there is a lot of latitude regarding parts. Everything should be available at Digikey, Jameco, Mouser, etc. The Z53C80 is available at Digikey for sure plus eBay and UTsource.net plus other distributors. That's probably the most challenging part and that's fairly common still.
I hope this helps! Please let me know if you have any other questions! Thanks and have a nice day!
Andrew Lynch
This sounds like absolutely great progress! My intended application is with DEC MicroVAXen so that should be a bit different to the systems mentioned so far.
I have two hurdles to cross before I can get a working board.
The first is the 1.8432MHz oscillator. I have had a devil of a time sourcing this part. In the end I had to pay through the nose for Digikey to ship them from the US and answer all sorts of export control questions. Appeal to Andrew on this: where possible please design future boards with parts that are more commonly available, in particular this part seems to be more readily available in a large DIP14 package rather than DIP8.
The second is the EPROM Programmer. I was given something not so long ago which I hope will work, but I need to put together a machine with a parallel port first. I have seen some discussion about this over the last couple of days, and it seems to be a bit of a problem, a cheap USB solution that works on 64-bit Windows would be great if anyone knows of one.
Regards
Rob
I have two hurdles to cross before I can get a working board.
The first is the 1.8432MHz oscillator. I have had a devil of a time sourcing this part. In the end I had to pay through the nose for Digikey to ship them from the US and answer all sorts of export control questions. Appeal to Andrew on this: where possible please design future boards with parts that are more commonly available, in particular this part seems to be more readily available in a large DIP14 package rather than DIP8.
The second is the EPROM Programmer. I was given something not so long ago which I hope will work, but I need to put together a machine with a parallel port first. I have seen some discussion about this over the last couple of days, and it seems to be a bit of a problem, a cheap USB solution that works on 64-bit Windows would be great if anyone knows of one.
Regards
Rob
Thanks Rob! That’s good news! I suspect if you have a full can 1.8432 oscillator you could make that work too. Attach some stiff 24 gauge wire to the pins and line them up with the socket pins 1, 4, 5, and 8. The relative order of the pins are identical for half and full sized can TTL oscillators. That is unfortunate you could not find one locally. I checked with Farnell UK and they only offer the SMD versions of the oscillators. Those might work too but would be a real PITA to adapt. I wonder if there are some UK and/or European builders who would have some more ideas for part sources.
Regarding the DEC MicroVAX testing that would be super! Programming the EPROM/EEPROM should be not too hard since the parts are common-as-dirt 27C256 or 28C256 chips. Personally I recommend the el-cheapo Willem Programmers on ebay. They are practically disposable they are so inexpensive. However I use mine quite a bit and it is indispensable which is amazing for something that cost so little. There are USB only programmers as well but those tend to be a bit more expensive – relative to this job I doubt there is any real difference since every model will support such common chips. Probably worth it in the long term. Personally I have several programmers for different jobs. Nothing beats the Data IO 29B for the *really* old stuff.
By the way, I know your S2I is almost done and running but for anyone else on this email distribution list… if you have an S2I board that you are not using or for whatever reason cannot get around to build and test PLEASE PLEASE return the board to me or another builder so we can utilize it. I am getting *MANY* requests for the prototypes to support testing so it is a shame to leave even these crude S2I prototypes just gathering dust somewhere. I will be glad to cover shipping if that’s an issue.
Thank you very much! Have a nice day!
Andrew Lynch
Regarding the DEC MicroVAX testing that would be super! Programming the EPROM/EEPROM should be not too hard since the parts are common-as-dirt 27C256 or 28C256 chips. Personally I recommend the el-cheapo Willem Programmers on ebay. They are practically disposable they are so inexpensive. However I use mine quite a bit and it is indispensable which is amazing for something that cost so little. There are USB only programmers as well but those tend to be a bit more expensive – relative to this job I doubt there is any real difference since every model will support such common chips. Probably worth it in the long term. Personally I have several programmers for different jobs. Nothing beats the Data IO 29B for the *really* old stuff.
By the way, I know your S2I is almost done and running but for anyone else on this email distribution list… if you have an S2I board that you are not using or for whatever reason cannot get around to build and test PLEASE PLEASE return the board to me or another builder so we can utilize it. I am getting *MANY* requests for the prototypes to support testing so it is a shame to leave even these crude S2I prototypes just gathering dust somewhere. I will be glad to cover shipping if that’s an issue.
Thank you very much! Have a nice day!
Andrew Lynch
Hi! Who has a working S2I unit or is close to a working unit?
As I recall, only Wayne and Douglas have working units.
However, I think there may be others who are close.
Does anyone else have a working S2I board or something close?
Please let me know if you need any help procuring parts, making updates, or
anything else.
It would be very beneficial if we could get more units into service to
conduct some additional testing with the latest firmware from Wayne.
http://n8vem-sbc.pbworks.com/w/page/62549548/S2I%20Status
As I understand it, the current firmware emulates a basic 20 MB SCSI drive
with some common parameters.
It may not be fast at the moment but there are many things which can be done
to improve speed.
However I would like to find out what sort of basic compatibility the S2I
has and/or what can be done to improve compatibility as necessary.
Optimizations can wait! For instance, the Z80H CPU *starts* at 8 MHz but is
capable of up to and beyond 20 MHz operation without issue.
Please let me know if you would like be removed from the email distribution
list.
Thanks and have a nice day!
Andrew Lynch
As I recall, only Wayne and Douglas have working units.
However, I think there may be others who are close.
Does anyone else have a working S2I board or something close?
Please let me know if you need any help procuring parts, making updates, or
anything else.
It would be very beneficial if we could get more units into service to
conduct some additional testing with the latest firmware from Wayne.
http://n8vem-sbc.pbworks.com/w/page/62549548/S2I%20Status
As I understand it, the current firmware emulates a basic 20 MB SCSI drive
with some common parameters.
It may not be fast at the moment but there are many things which can be done
to improve speed.
However I would like to find out what sort of basic compatibility the S2I
has and/or what can be done to improve compatibility as necessary.
Optimizations can wait! For instance, the Z80H CPU *starts* at 8 MHz but is
capable of up to and beyond 20 MHz operation without issue.
Please let me know if you would like be removed from the email distribution
list.
Thanks and have a nice day!
Andrew Lynch
Hi Rob! Thanks! Yes, the current firmware is IDE only at the moment. In fact, I strongly recommend using an IDE/CF adapter. The SD is currently not supported but hopefully will be soon. However I suspect the SD will have noticeably reduced performance relative to the IDE/CF due to the serialized nature of SD.
One day something I would like to know is if the 8-bit mode common on many CF cards would provide a more efficient storage mode and/or speedier interface. I have heard although do not know for a fact that the 8-bit IDE/CF mode has quite a bit less overhead and complexity.
Not only is the 8-bit IDE/CF interface much simpler the achievable throughput is actually higher than the regular 16-bit mode. I know that may sound a bit paradoxical but I think it is true. Fortunately we are using a PPIDE interface so either mode is possible. However, this is just a curiosity for now and we should continue to focus on compatibility testing.
Thanks and have a nice day!
Andrew Lynch
One day something I would like to know is if the 8-bit mode common on many CF cards would provide a more efficient storage mode and/or speedier interface. I have heard although do not know for a fact that the 8-bit IDE/CF mode has quite a bit less overhead and complexity.
Not only is the 8-bit IDE/CF interface much simpler the achievable throughput is actually higher than the regular 16-bit mode. I know that may sound a bit paradoxical but I think it is true. Fortunately we are using a PPIDE interface so either mode is possible. However, this is just a curiosity for now and we should continue to focus on compatibility testing.
Thanks and have a nice day!
Andrew Lynch
On 1/26/2013 4:47 PM, Andrew Lynch wrote:
However I suspect the SD will have noticeably reduced performance
relative to the IDE/CF due to the serialized nature of SD
SD /can/ support 4-bit nibbles at a 50 MHz clock rate. That's a 25 MByte
per second transfer rate. I think newer devices can go double data rate
beyond that...
Plus it has zero rotational latency and zero seek times.
That's pretty respectable compared to IDE disks.
Rob Doyle
However I suspect the SD will have noticeably reduced performance
relative to the IDE/CF due to the serialized nature of SD
SD /can/ support 4-bit nibbles at a 50 MHz clock rate. That's a 25 MByte
per second transfer rate. I think newer devices can go double data rate
beyond that...
Plus it has zero rotational latency and zero seek times.
That's pretty respectable compared to IDE disks.
Rob Doyle
Ummm... well... I seem to have the SD card fully functional now.
I am fairly mystified by this. I know what I did wrong in the code, but it really doesn't explain what I was seeing with my logic probe. I intend to do some voltage checking when I have a bit more time.
Regardless, I think we can basically check one more subsystem off as tested! In fact, the SD card driver is now fully functional and the S2I firmware can use either the IDE device or the SD Card device for storage. I will post updated firmware in the next few days.
Also, I quickly checked the config latches. They absolutely work, but noticed that I need to read the port twice if I change the shorting blocks without a power cycle. On the first port read after moving the shorting blocks, I get the previous value. On the second read, I get the updated value. Is that expected???
Thanks,
Wayne
I am fairly mystified by this. I know what I did wrong in the code, but it really doesn't explain what I was seeing with my logic probe. I intend to do some voltage checking when I have a bit more time.
Regardless, I think we can basically check one more subsystem off as tested! In fact, the SD card driver is now fully functional and the S2I firmware can use either the IDE device or the SD Card device for storage. I will post updated firmware in the next few days.
Also, I quickly checked the config latches. They absolutely work, but noticed that I need to read the port twice if I change the shorting blocks without a power cycle. On the first port read after moving the shorting blocks, I get the previous value. On the second read, I get the updated value. Is that expected???
Thanks,
Wayne
I went over the firmware, I dont know jack about the Z80, and too bad its not in C or some other high level language.
Would have been nice, because I could have gotten the parts count down by compiling for a processor thats integrated, like a PIC or AVR. But... Something is better than nothing.
Might check and see if we can get these ICs in SMD packages to miniaturize the board.
Would have been nice, because I could have gotten the parts count down by compiling for a processor thats integrated, like a PIC or AVR. But... Something is better than nothing.
Might check and see if we can get these ICs in SMD packages to miniaturize the board.
That's actually a disadvantage - those are not easily obtainable in small quantities (ie, not 100,000+), or indeed much at all it seems. Those that are are NOS, generally only have a handful in supply, and are expensive.
/ETA/ Also, the Z53C80, IIRC, tops out at ~1.5MB/s
Wow, that's disappointing 
You're a bit familiar with AVRs iirc; would a faster AVR help there at all?
I have a few of the CURIO SCSI ICs, but no docs
You're a bit familiar with AVRs iirc; would a faster AVR help there at all?I have a few of the CURIO SCSI ICs, but no docs
Yes, but they only top at 20mhz, His code is timed at 16Mhz. unless we go AVR32 which is ARM based. And if thats the case, there are much better ARMs than the AVR32.
Now im sure there are multiple ways at making his routines much more efficient and speeding up the system. AVR8s these days are system-on-chips that are much faster than what they had then... So its possible to speed it up given if the code was made more efficient (C isnt my strongpoint).
Now im sure there are multiple ways at making his routines much more efficient and speeding up the system. AVR8s these days are system-on-chips that are much faster than what they had then... So its possible to speed it up given if the code was made more efficient (C isnt my strongpoint).
Regarding the "speed" question (along with the "uses a hard to find SCSI chip" objection), any design which requires the microcontroller to bit-bang the SCSI bus directly is inevitably going to suffer some performance issues. The reason why SCSI chips like the 53c80 and friends exist is because SCSI has very specific and rigorous requirements for the generation and handling of handshaking and arbitration signals, and if you're not going to invest in a fair amount of logic in a state machine which the provides buffers and triggers to offload some of that handshaking overhead the CPU is going to be spending a *lot* of its time either polling for activity or running precise timing loops to hold X wire high or low for however long the protocol calls for.
Here's the original draft specification for the SCSI interface. It *is* complicated, more complicated than most 8 or 16 bit CPU buses. This is why IDE seemed like a good idea when it came along: it's actually a simplified subset of an already simple 16 bit bus.
An MCU, even if it's one that *almost* manages one instruction per cycle like AVR (or even ARM), is going to be working pretty hard just watching the bus pins and keeping track of what phase of the conversation it's in at any given time. If you want good performance (without going ridiculously overboard on the CPU) it would help a *lot* to have some of the bus handler in hardware. (That design that Techknight was playing with uses a second AVR as the bus handler, which is a clever idea that moves hardware complexity into software, but it still leaves you with one core that's having to spend most of its time listening to and triggering pins with just enough left over to shove semi-decoded data out the back door to the other AVR. That's not a recipe for "fast". Even *with* a SCSI ASIC to get speeds in the 1Mbyte/sec-plus territory you'll probably be needing a pretty darn fast CPU and/or DMA. And this is ignoring the fact that you're having to deal with the overhead of having to talk out the other side to the IDE/SD/USB/whatever drive and doing the necessary command translation.)
Anyway, having a bus handler in hardware which isn't a hard to find EOL IC is what leads us back to CPLDs/FPGAs. But FPGAs/CPLDs aren't magic; you'll still need a hardware design for the state machine to program into the devices. In casual Googling I have yet to find *anyone* who's "open-sourced" code for making a SCSI MAC, let alone a complete target out of CPLDs/FPGAs. (The closest I came is a confusing thread about making an ASCI-SCSI adapter for Atari ST machines out of CPLDs, which may well be a promising start.) One approach would be to try to find documentation/schematics for *very old* SCSI target devices (I.E., early SCSI hard drives, especially those ones utilizing SCSI-to-MFM adapter boards) and use an example which does SCSI with discrete TTL as a starting point. Quick googling turned up schematics for some primitive SCSI (and SASI) *host adapters* out there that fit into a dozen or two TTL devices, presumably the hard drive side isn't much harder. (And the manual/schematic for one may well be out there. It looks like based on the few board photos I've seen that a lot of the early formatter boards lacking ASICs used Zilog Z8 CPUs as the go-between for the TTL-decoded SCSI bus and the hard drive controller, which is convenient given the Z8 is vaguely comparable to an 8-bit PIC or AVR in capabilities.) From this point the project branches depending on whether you're using a CPLD or an FPGA:
CPLD: You figure out what triggers and buffers would make your life easier, pick the optimal bus design for presenting the simplified bus to the MCU of your choice (you'll still need one), and see how compressed you can make things. If you *really* want fast you still might need to consider working, say, an SRAM chip into the design so both SCSI and IDE transfers (if that's what you go with) can use DMA, in which case your CPLD(s) will need to arbitrate that too.
FPGA: With a roomy enough device you could put your bus handler and the softcore of your choice on one chip. (And presumably you'll choose a softcore that has high-level language support and lets you turn the clock speed up to eleven. Heck, if you want to keep the "hardware design" super-simple maybe you cram two softcores together and duplicate the "dual-CPU" nature of that AVR design. To speed things up massively you could have them share memory instead of having to communicate over a narrow bus, for instance. Heck, use three. One driving the SCSI MAC, one doing command translation, and a third driving the storage bus...)
So... did I have a point? Oh, yeah. Talking about CPLDs and FPGAs is all great, but what seriously needs to be kept in mind is that they don't significantly reduce the number of "moving parts" in the design. (And massively optimizing for performance will increase it that much more.) All they do is compress a bunch of discrete logic into a single package: you still need to design that logic. I've read the thread on the VCF discussing the board that's the subject of this thread, and while I roll my eyes where it devolves into a self-righteous flaming match I do sort of understand the frustration that stemmed from and I shake my head myself when people throw out "use an FPGA!" as if it's a magic bullet that makes design problems go away with a wave of a wand. I agree that the Z-80 board here isn't an optimal solution for either performance nor future-proof-y-ness, but I have to give the folks some credit for actually pasting together something that at least partially works and is undoubtedly "educational". Two options for a next step, if someone wanted to take it slow, would be:
A: Interface a chip like 53c80 to a *fast* MCU and code a driver in a high-level language. Or.
B: Take this design (since it does have at least semi-working firmware that exists in source form) and concentrate on building a SCSI ASIC-in-a-CPLD/FPGA that works in place of the 53c80. (This of course could start with a few dozen TTL chips on a breadboard, later translated into a CPLD.)
Success with both A+B results in your dream board that's faster, easier to understand, and doesn't rely on EOL hardware. You don't *have* to do everything at once.
Here's the original draft specification for the SCSI interface. It *is* complicated, more complicated than most 8 or 16 bit CPU buses. This is why IDE seemed like a good idea when it came along: it's actually a simplified subset of an already simple 16 bit bus.
An MCU, even if it's one that *almost* manages one instruction per cycle like AVR (or even ARM), is going to be working pretty hard just watching the bus pins and keeping track of what phase of the conversation it's in at any given time. If you want good performance (without going ridiculously overboard on the CPU) it would help a *lot* to have some of the bus handler in hardware. (That design that Techknight was playing with uses a second AVR as the bus handler, which is a clever idea that moves hardware complexity into software, but it still leaves you with one core that's having to spend most of its time listening to and triggering pins with just enough left over to shove semi-decoded data out the back door to the other AVR. That's not a recipe for "fast". Even *with* a SCSI ASIC to get speeds in the 1Mbyte/sec-plus territory you'll probably be needing a pretty darn fast CPU and/or DMA. And this is ignoring the fact that you're having to deal with the overhead of having to talk out the other side to the IDE/SD/USB/whatever drive and doing the necessary command translation.)
Anyway, having a bus handler in hardware which isn't a hard to find EOL IC is what leads us back to CPLDs/FPGAs. But FPGAs/CPLDs aren't magic; you'll still need a hardware design for the state machine to program into the devices. In casual Googling I have yet to find *anyone* who's "open-sourced" code for making a SCSI MAC, let alone a complete target out of CPLDs/FPGAs. (The closest I came is a confusing thread about making an ASCI-SCSI adapter for Atari ST machines out of CPLDs, which may well be a promising start.) One approach would be to try to find documentation/schematics for *very old* SCSI target devices (I.E., early SCSI hard drives, especially those ones utilizing SCSI-to-MFM adapter boards) and use an example which does SCSI with discrete TTL as a starting point. Quick googling turned up schematics for some primitive SCSI (and SASI) *host adapters* out there that fit into a dozen or two TTL devices, presumably the hard drive side isn't much harder. (And the manual/schematic for one may well be out there. It looks like based on the few board photos I've seen that a lot of the early formatter boards lacking ASICs used Zilog Z8 CPUs as the go-between for the TTL-decoded SCSI bus and the hard drive controller, which is convenient given the Z8 is vaguely comparable to an 8-bit PIC or AVR in capabilities.) From this point the project branches depending on whether you're using a CPLD or an FPGA:
CPLD: You figure out what triggers and buffers would make your life easier, pick the optimal bus design for presenting the simplified bus to the MCU of your choice (you'll still need one), and see how compressed you can make things. If you *really* want fast you still might need to consider working, say, an SRAM chip into the design so both SCSI and IDE transfers (if that's what you go with) can use DMA, in which case your CPLD(s) will need to arbitrate that too.
FPGA: With a roomy enough device you could put your bus handler and the softcore of your choice on one chip. (And presumably you'll choose a softcore that has high-level language support and lets you turn the clock speed up to eleven. Heck, if you want to keep the "hardware design" super-simple maybe you cram two softcores together and duplicate the "dual-CPU" nature of that AVR design. To speed things up massively you could have them share memory instead of having to communicate over a narrow bus, for instance. Heck, use three. One driving the SCSI MAC, one doing command translation, and a third driving the storage bus...)
So... did I have a point? Oh, yeah. Talking about CPLDs and FPGAs is all great, but what seriously needs to be kept in mind is that they don't significantly reduce the number of "moving parts" in the design. (And massively optimizing for performance will increase it that much more.) All they do is compress a bunch of discrete logic into a single package: you still need to design that logic. I've read the thread on the VCF discussing the board that's the subject of this thread, and while I roll my eyes where it devolves into a self-righteous flaming match I do sort of understand the frustration that stemmed from and I shake my head myself when people throw out "use an FPGA!" as if it's a magic bullet that makes design problems go away with a wave of a wand. I agree that the Z-80 board here isn't an optimal solution for either performance nor future-proof-y-ness, but I have to give the folks some credit for actually pasting together something that at least partially works and is undoubtedly "educational". Two options for a next step, if someone wanted to take it slow, would be:
A: Interface a chip like 53c80 to a *fast* MCU and code a driver in a high-level language. Or.
B: Take this design (since it does have at least semi-working firmware that exists in source form) and concentrate on building a SCSI ASIC-in-a-CPLD/FPGA that works in place of the 53c80. (This of course could start with a few dozen TTL chips on a breadboard, later translated into a CPLD.)
Success with both A+B results in your dream board that's faster, easier to understand, and doesn't rely on EOL hardware. You don't *have* to do everything at once.
That's... not really what I meant.
I don't know whether such a thing exists, or I wouldn't be asking: but what I'm imagining is an IC which is set up purely to do fast IO and bit/byte format wrangling from one side t'other. Obviously it would have to be programmed in a fairly low-level way in how to behave - no magic dials.
I don't know whether such a thing exists, or I wouldn't be asking: but what I'm imagining is an IC which is set up purely to do fast IO and bit/byte format wrangling from one side t'other. Obviously
it would have to be programmed in a fairly low-level way in how to behave - no magic dials.Well if there isnt any open source SCSI files for FPGA, perhaps we can do the opposite.
There are Z80 systems for the FPGA. We can take the address decoding, the ROM/RAM/ETC and toss it all on the FPGA, as the libraries are already out there. just have to patch them all together, and map the external I/O to the SCSI IC, and the ATA port.
For simplicity though, once the Z80 project is complete, i guess for a start we could simply implement all the tie-in glue logic, 74 series logic into a CPLD to help reduce the IC count. I am thinking in terms of 2.5" compatibility. Get rid of the UART, and use the PLCC versions of the Z80 and firmware, and SMD RAM. As a start.
There are Z80 systems for the FPGA. We can take the address decoding, the ROM/RAM/ETC and toss it all on the FPGA, as the libraries are already out there. just have to patch them all together, and map the external I/O to the SCSI IC, and the ATA port.
For simplicity though, once the Z80 project is complete, i guess for a start we could simply implement all the tie-in glue logic, 74 series logic into a CPLD to help reduce the IC count. I am thinking in terms of 2.5" compatibility. Get rid of the UART, and use the PLCC versions of the Z80 and firmware, and SMD RAM. As a start.
by: Wayne Warthen https://plus.google.com/u/0/110693559211154577764?prsrc=4
by: Andrew LynchI have posted another very minor S2I firmware update on the Wiki (0.3B). The main difference is that the ROM automatically starts the SCSI Target Mode Command Processor automatically at boot. You can press to access the Zapple prompt.
Here are some more testing observations:
I pushed the CPU speed to 12MHz successfully. I was unsuccessful at 16MHz. My Z80 is rated for 20MHz. I would guess the limiting component is now the EEPROM which is rated at 150ns. Any thoughts on this? I don't see a faster version of the 28C256 available...
DOS 6.22 FDISK now working!!!
The IDE interface is substantially faster than the SD Card interface. I strongly recommend sticking with the IDE interface if possible.
I believe the firmware is definitely ready for serious testing in other environments.
If anyone is building/testing, please keep us posted here!
Thanks,