82c55 IDE adapter

[Ed Brindley]

As per comments in the Fuzix thread, I had a go at coming up with a schematic for a 82c55 IDE adapter for the RC2014.

It's a clone of Philip's YAZ180 design with added '688 based address decoding (thanks to PianoMatt and various S100 designs. I looked at this one: https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:ramfloppy:printing_ecb-ramf-r11.sch.pdf), and a 40pin IDE connector.

One thing I'm not sure about is the IDE INTRQ signal. Attaching this directly to the Z80s interrupt line seems like a bad idea if we want to be able to use the Z80 in interrupt mode 2, which is ideally what you'd want to do when using the Z80 peripheral chips, the CTC, SIO etc.

I'm wondering if attaching it is necessary? Other designs seem to not connect it, e.g. ECB diskio https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:diskio-v3:ecb_diskio_v3_-_schematics_-_color_1.0.pdf

All comments welcome! I knocked it up quickly so will definitely be some errors...

Cheers,
Ed

[codifies]

I did wonder about different strategies for putting the interrupt vector on the lower half of the address bus without using loads or logic, while not (hopefully) needed for this I was wondering if anyone had had any thought about elegant ways to do this...

[phillip.stevens]

On Tuesday, 12 September 2017 07:08:17 UTC+10, Ed Brindley wrote:

As per comments in the Fuzix thread, I had a go at coming up with a schematic for a 82c55 IDE adapter for the RC2014.

It's a clone of Philip's YAZ180 design with added '688 based address decoding (thanks to PianoMatt and various S100 designs. I looked at this one: https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:ramfloppy:printing_ecb-ramf-r11.sch.pdf), and a 40pin IDE connector.

Looks very good!

Some review points.

• The 82C55 RESET is a positive signal, unlike the Z80 /RESET signal. (Perhaps steal the interrupt inverter?).
  
• My errata. I just remembered the PDF I gave as input is a little bit dated (wrong). I connected DA0 and DA1 each on the wrong pin of the IDE connector, so they are reversed. But, as I noted, it is easy to change pin-out with software defines. The driver defines shows exactly how mine are really connected. Either way, doesn't matter.

One thing I'm not sure about is the IDE INTRQ signal. Attaching this directly to the Z80s interrupt line seems like a bad idea if we want to be able to use the Z80 in interrupt mode 2, which is ideally what you'd want to do when using the Z80 peripheral chips, the CTC, SIO etc.

I'm wondering if attaching it is necessary? 

The interrupt is unnecessary for the IDE interface, IMHO. All the drivers I've seen don't use it, and I didn't use it either. Since modern PATA drives have large caches (by our standards) they tend to respond pretty quickly. Since we're using PIO Mode (the slowest mode for the drive) I guess there's nothing to lose by doing the standard polling method. 

I implemented the interrupt just to keep the interface general. I wanted to have some method of having something at the other end of the cable being able to interrupt the CPU. And I had an inverter gate spare to make it line up with the Z180 interrupt /INT0. In my next revision of hardware, I'll be changing the /INT0 handling again, because my current implementation doesn't support the 82C55 interrupt pin, which is useful for keyboard scanning, etc (which was another oversight).

I'm not sure how to handle this on the Z80, because there are not so many interrupt lines available. Perhaps just a jumper...?

All comments welcome! I knocked it up quickly so will definitely be some errors...

Final comment. I decided to use the 44pin lap-top IDE pin-out, because it carries power for the drive, and is physically smaller. This made the solution 1 cable, rather than needing to power the drive from a separate molex connector and power supply. The 44pin interface also helps for transporting data, as I have some old USB external lap-top drives, which I can use to simply move data between PC and Z80. And, the result looks really tidy, IMHO.

Looking forward to getting a RC2014 IDE interface soon. ;-).

[PianoMatt]

I was thinking about this yesterday when I was messing about with the CF card in RomWBW. Basing it on this design would maintain compatibility with the RetroBrew designs and thus RomWBW.

Have you started a layout for it? If you decide not to let me know and I'll have a crack at it

PianoMatt

[Ed Brindley]

Hi Matt,

Yeah I've started the layout, but going down to London for the Hackaday unconference has got in the way of me finishing it off!

Screenshot attached of current state of play. I'd started ripping up a few tracks and rerouting things so there's a few tracks missing!

I've gone for both a 40 pin and 44 pin connector so everyone should be happy. The 40 pin is a right angle on on the edge so you could use it with a CF adapter.

Re the pin assignment, I went with Philip's variation (see the Fuzix thread for details) so you would have to swap a couple of the RomWBW defines around... Now thinking that maybe should just go with the same as the other RetroBrew interfaces though.

Cheers,
Ed

[PianoMatt]

I might have a go at doing a layout for the DIP40 version. I've got a few of them laying around, and Mouser still stocks them.

[phillip.stevens]

Ed,

 

I've gone for both a 40 pin and 44 pin connector so everyone should be happy. The 40 pin is a right angle on on the edge so you could use it with a CF adapter.

Sound like the best plan, to cover both options.

 

Re the pin assignment, I went with Philip's variation (see the Fuzix thread for details) so you would have to swap a couple of the RomWBW defines around... Now thinking that maybe should just go with the same as the other RetroBrew interfaces though.

I've checked out the RetroBrew solution, and they use an PPIDE adapter mini-board which avoids the "lock-in" created by the inverters on the 82C55 input pins, for their SBCs. So their main on-board 82C55 Parallel Port interface is just straight pins.

The IDE interface is created by another PPIDE mini-board adapter attached in between the 82C55 and the IDE drive, and it carries the inverters necessary to drive the IDE bus. Since the PPIDE mini-board is a special purpose interface they don't care about Mode 1 applications (keyboard scanning, CRT, parallel printing), or Mode 2 applications (Floppy Controller) so they just "numbered off" the interface pins, using Port C for control.

The current RetroBrew PPIDE mini board uses exactly the same pin-out solution as Paul Stoffregen, and Peter Faasse before him, leaving PC0, PC1, and PC2 for the IDE address pins (non-inverted). This adapter mini-board can only do Mode 0, for IDE, which is ok for this application.

Therefore, IMHO, if you're building your 82C55 board exclusively to be an IDE interface then you're best to follow along with Peter's, Paul's, and RetroBrew's solution. Otherwise (because you're not proposing a PPIDE adapter in between), keep PC2, PC4, and PC6 for the IDE address pins and keep your interface general purpose.

Either way, it is just a redefinition of the pins in the driver.

Related to the IDE interface. AA from z88dk has finished a z88dk-lib tool, which enables third party libraries to be installed into your z88dk installation, and eases inclusion and linkage of these libraries into projects. I'm currently finishing ChaN's FatFs code port in my z88dk-libraries repository, and have it connected to my diskio layer. This means as soon as your 82C55 board is finished, we can move the diskio support to rc2014, and then compile a FatFs implementation. The software heavy lifting  is done.

Cheers, Phillip

[Ed Brindley]

Thanks Philip,

At the moment just going for an IDE interface, so have reverted to the RetroBrew pinout. Figure if need one for general purpose use can spin another PCB.

I've inverted the reset line and have swapped DA0/DA1 around from previous schematic.

Cheers,
Ed

[PianoMatt]

I'm going to pretend I didn't just spend an hour and a half doing exactly the same schematic as you Ed

Matt

[phillip.stevens]

Hi Ed,

 

At the moment just going for an IDE interface, so have reverted to the RetroBrew pinout. Figure if need one for general purpose use can spin another PCB.

Looks good! 

But, for the cost of four jumper-holes, it seems like a bit of a waste to PLAN to build two PCBs.

Why not put in some jumper-holes and trace-cut options to allow the PC4 and PC6 to be swapped around with PC0 and PC1 (on the input side of the inverters)?

It would save creating another SKU, and give you some flexibility to use your PPI board for multiple purposes.

The IDE interface is created by another PPIDE mini-board adapter attached in between the 82C55 and the IDE drive, and it carries the inverters necessary to drive the IDE bus. Since the PPIDE mini-board is a special purpose interface they don't care about Mode 1 applications (keyboard scanning, CRT, parallel printing), or Mode 2 applications (Floppy Controller).

The current RetroBrew PPIDE mini board uses exactly the same pin-out solution as Paul Stoffregen, and Peter Faasse before him, leaving PC0, PC1, and PC2 for the IDE address pins (non-inverted).

Just because Peter and Paul didn't think forward to other applications, doesn't mean we have to blindly follow in their footsteps. ;-)

Cheers, Phillip

 

[PianoMatt]

Are the other modes of operation that the 82C55 is capable of useful in the context of an IDE interface?

Cloning the DiskIO board makes sense to me,because it makes it easier to implement RomWBW on the RC. It'd be great to see the RC become officially supported by RomWBW, and adding the standard IDE interface to the RC arsenal could bring us one step closer.

[phillip.stevens]

Are the other modes of operation that the 82C55 is capable of useful in the context of an IDE interface?

Hi Matt,

what you're asking is actually backwards, IMHO.

The IDE interface is a very specific implementation based on the use of a 8255 parallel port interface chip that was designed to be very general in nature.

The question to ask, IMHO, is actually "If I'm building an interface board with a 8255 on it, why would I lock myself into just building it for one single application, when it is possible to allow it to be very general?"

 

Cloning the DiskIO board makes sense to me, because it makes it easier to implement RomWBW on the RC. It'd be great to see the RC become officially supported by RomWBW, and adding the standard IDE interface to the RC arsenal could bring us one step closer.

Cloning RomWBW is no easier or harder with a slightly different pin-out for the 8255. We're talking two bits here.

You still need to compile RomWBW for our specific addressing IO_BASE addressing. That will change depending on where the 8255 card is located.

The other changes in the source code are very simply moving two bits in the 8255 to IDE assignment. It is that easy.

On the topic of what else an 8255 can do, the data sheet has some examples.

They include:

• Keyboard and Display Interface (Mode 1)
  
• Parallel Printer Interface (Mode 1)
  
• CRT Controller (Mode 1)
  
• Floppy Disc Interface (Mode 2)

All of these examples (and there are others, but I'm getting long winded), are enabled just by swapping PC0 for PC4, and PC1 for PC6 on the 8255 interface hardware, and moving two bits on the RomWBW software defines.

Cheers, Phillip

[PianoMatt]

I think it would definitely be easier to keep the board dedicated to IDE in all honesty. The form factor of the cards is very small, so trying to squeeze all the extra stuff on there to support IDE as well as general purpose use is difficult. Sounds like what you want is a general purpose 82C55 board with PA, PB and PC all broken out. Maybe give it a go yourself?

PianoMatt

[Ed Brindley]

Hi Phillip,

Thanks for the critique.

Will add some jumpers to swap those round and send it off to get a PCB made. Hopefully I've not missed anything else, although wary as I've not prototyped this!

Will be interesting to see what kind of performance you get vs bit banging the compactflash card in 8 bit mode. I expect it's not going to make any difference at all.

What speed do you run the Z180 on your YAZ180? I was looking at an S100 82c55 design, and they'd added some logic to latch signals to enable it to work on buses > 8Mhz.

Matt, yes our schematics are almost identical! Ah well, it's never wasted time if you're enjoying it / learning IMO :)

Cheers,

Ed

[phillip.stevens]

Hi Ed,

 

Will add some jumpers to swap those round and send it off to get a PCB made. Hopefully I've not missed anything else, although wary as I've not prototyped this!

Fingers crossed for you. 

Will be interesting to see what kind of performance you get vs bit banging the compactflash card in 8 bit mode. I expect it's not going to make any difference at all.

I don't really know, but I expect you're right. The throughput will be strongly limited by the Z80 bus, and therefore back to clock speed.

I should do some file read / write tests, now I have an accurate clock, and FatFs file system.

PJRC has this to say "The faster version was used in a project that sustained reads of 24 kBytes/sec, while also doing some serial communication, with a 14.7456 MHz system clock. The normal version is believed to be able to read at about 16 kBytes/sec, but this hasn't been verified."

 

What speed do you run the Z180 on your YAZ180? I was looking at an S100 82c55 design, and they'd added some logic to latch signals to enable it to work on buses > 8Mhz.

I'm running my YAZ180 at 18.432MHz Phi. The 82C55 works ok with this, provided you use 2 wait states for I/O. With exception of the APU, it is the slowest device on the bus. The Z180 is very flexible in this regard, allowing wait states for RAM and I/O to be separately specified.

Keeping the Phi below 20MHz means that I can run zero wait state RAM and Flash, and also I can get away with the internal clock at 2xPhi, overclocking the core to 36.864MHz.

To get the Am9511A APU to understand writes I have to halve the Phi to 9.216MHz because it needs 30ns of /CS hold after /WR is released. The Z180 has a special E-Clock timing to support this. But, at 18.432MHz, the /CS hold is 27ns, (1/2 Phi) which is not enough... Doh!

Now that I am reminded about this, the 82C55 also has special /WR timing requirements...

Originally I had it broken, and this is the fix.

The 82C55 needs "tWA" (Address Stable after /WR) to be 20ns. This means the /CS must be generated from just the address lines in Z180 world.

Don't incorporate the /IORQ line in the /CS calculation, or the /CS will be tied to the /WR (/IORQ) timing, rather than to the address validity timing.

The Z180 only promises 5ns of tAH hold time but, since I've buffers on the lower address lines that hold the previous state until driven to a new state, it works out ok.

The Z80 promises 1/2 Phi of address validity after /WR and /IORQ, so if you just use addresses to generate /CS then it is sweet.

I use EEPLD to generate /CS, so I could be as complex as I wanted to generate these, and originally I used the /IREQ as part of the calculation.

Now, I've removed it and just have a NOT /MREQ term (so that the /CS is not needlessly triggered).

See CUPL attached for more clarity.

Got my fingers crossed it works out.

Soon as you see the board, I'll copy the z88dk 8255 -> ide -> diskio drivers over to the RC2014 target.

Cheers, Phillip

[phillip.stevens]

Doh. See the correct CUPL attached for more clarity.

Cheers, Phillip

[phillip.stevens]

Hi Ed,

Will be interesting to see what kind of performance you get vs bit banging the compact flash card in 8 bit mode. I expect it's not going to make any difference at all.

Well the question is intriguing enough to make it worth a bit of an investigation. So, I took my `diskio.c` test program, put in some timing captures and increased the sector count to 32 (512 byte) sector writes and reads. And the results are in.

Kingspec-SSD KSD-PA18.6-XXXMS    16kB W/R in    14 /256th of a second or 292kB/s.

that seems like quite fast... so lets try an old IBM drive.

IBM-Travelstar DBCA-206480       16kB W/R in 15-21 /256th of a second or 195kB/s to 273kB/s.

Here's an excerpt from the IBM-Travelstar tests, showing the variability of the result.

Note the drive is synced between each write and read, so it not just reading cached data.

**** Test cycle 2 of 3 start ****

 disk_initalize(0) - ok.

**** Get drive serial number ****

 disk_ioctl(0, ATA_GET_SN, 0xA083) - ok.

Serial number of the drive 0 is          HR0RRQG3912.

**** Get drive size ****

 disk_ioctl(0, GET_SECTOR_COUNT, 0x8191) - ok.

Number of sectors on the drive 0 is 12685680.

**** Get sector size ****

 disk_ioctl(0, GET_SECTOR_SIZE, 0x8195) - ok.

 Size of sector is 512 bytes.

**** Multiple sector write test ****

 disk_write(0, 0xA083, 1, 32) - ok.

the 16kB write time taken was 0 + 15/256 seconds

 disk_ioctl(0, CTRL_SYNC, NULL) - ok.

 disk_read(0, 0xA083, 1, 32) - ok.

the 16kB read time taken was 0 + 16/256 seconds

 Data matched.

 disk_write(0, 0xA083, 1, 32) - ok.

the 16kB write time taken was 0 + 21/256 seconds

 disk_ioctl(0, CTRL_SYNC, NULL) - ok.

 disk_read(0, 0xA083, 1, 32) - ok.

the 16kB read time taken was 0 + 17/256 seconds

 Data matched.

 disk_write(0, 0xA083, 1, 32) - ok.

the 16kB write time taken was 0 + 21/256 seconds

 disk_ioctl(0, CTRL_SYNC, NULL) - ok.

 disk_read(0, 0xA083, 1, 32) - ok.

the 16kB read time taken was 0 + 17/256 seconds

 Data matched.

Impressive!

[Tom Szolyga]

There may be an error in this version of the schematic.  It looks like the connections to Vcc and GND in the address decoding section were switched.  As the schematic is I think the 82C55 will be selected only when /M1 is active or LOW or equal to gnd.

Best regards,

Tom

[Ed Brindley]

Thanks Tom, 

Yes I've got that the wrong way round! 

Awaiting a few bits then going to try it on breadboard before I commit to a PCB.

Thanks,

Ed

[Ed Brindley]

That's faster than I imagined.

So regarding the z88dk stuff, there's the 82c55 driver then diskio layered over that as an abstraction and c interface, then FatFS on top of that?

And you could theoretically build this into a CP/M program? (the COM file would have to reside on a normal CP/M formatted drive, but you could load data in-program from a FAT partition on a different drive?)

Cheers,

Ed

[phillip.stevens]

Hi Ed,

 

That's faster than I imagined.

Yes, it is faster than I imagined too. By 10x what PJRC mentioned on his web site. The performance is purely driven by the number of reads and writes to the 82C55, so I used the Z80 ini and outi to great benefit, allowing me to run the interface more efficiently than PJRC was doing with his 8051 code. And, I've specifically written only byte and sector transfer routines, and tried to optimise for that. PJRC went about it a bit differently.

 

So regarding the z88dk stuff, there's the 82c55 driver then diskio layered over that as an abstraction and c interface, then FatFS on top of that?

It is actually driven by ChaN's FatFs. This is a library written by a Japanese benefactor, which has all the latest FatFs stuff in it, including exFAT, and all of the LFN and Unicode tables. This library relies on a standardised set of diskIO calls that, once they're passing the provided test code, enables you to run ChaN's FatFs library with confidence that nothing is broken.

Unfortunately, sdcc (used in the z88dk) doesn't have the ability to put functions and data into sections by itself. This means that the single file (ff.c) library fills up a lot of space, because the linker can't decide which sections to abandon.

The only short term (actually medium to long term) fix is to scatter ChaN's work down into individual function files, so that the z88dk linker can decide which functions are being used, and which ones can be abandoned. This, I've now done partially and it is working enough to at least pass the basic tests.

I'll be checking this segmentation work further soon, and hopefully getting some performance figures too.

 

And you could theoretically build this into a CP/M program? (the COM file would have to reside on a normal CP/M formatted drive, but you could load data in-program from a FAT partition on a different drive?)

Yes. Absolutely.

Actually I have a cunning plan, and that is to build a "modern" CP/M2.2 platform with FAT32 disks, and memory banking similar to ZDOS, potentially looking quite a bit like (if not the same as) FUZIX, that can run CP/M applications without all the mucking about with inefficient file types and other limitations from the 1980s. Admittedly, one should produce running code before one mouths off about stuff. But, it is a medium - long term outcome focus for me.

Will be interesting to see what kind of performance you get vs bit banging the compact flash card in 8 bit mode. I expect it's not going to make any difference at all.

Well the question is intriguing enough to make it worth a bit of an investigation. So, I took my `diskio.c` test program, put in some timing captures and increased the sector count to 32 (512 byte) sector writes and reads. And the results are in.

Kingspec-SSD KSD-PA18.6-XXXMS    16kB W/R in    14 /256th of a second or 292kB/s.

that seems like quite fast... so lets try an old IBM drive.

IBM-Travelstar DBCA-206480       16kB W/R in 15-21 /256th of a second or 195kB/s to 273kB/s

On this topic, I got enthusiastic, and tested both these drives (and another Samsung from 2006 I had to hand) using my USB<->PATA mini external drive. Because it is a USB interface, it is not exploiting all the benefits of PATA-IDE, but still there's no finesse to the outcome.

The IBM-Travelstar (from Oct '99) is being driven to about 10% of capacity by the 82C55, but the modern SSD is running about 1% of capacity (again, on a USB interface). So, don't waste money on SSDs for your RC2014-82C55-IDE interface, I think is the message.

I'll try some C interface (FatFs) speed testing, of file copies, etc, to see how much performance is lost between C wrapped asm diskIO functions, and the FatFs calls.

Cheers, Phillip

 

[Tom Szolyga]

Hi Ed and Phillip,

Have you looked at an app called "RUNCPM"?  There are versions that run on multiple O/Ss;  I have tried the Windows version.  The app runs stock CP/M programs in a window on a PC.  The stock CPM program accesses standard PC files.  There is a directory for each CPM drive.  Ex PC directory A  corresponds to CPM drive A.  I believe RUNCPM does this by replacing the BDOS and BIOS layers in CPM, while running the stock CCP layer.  Seems to me the same think could be done on the Z80 to access media formatted in FATxx fashion.

Thoughts?

Best regards,

Tom

[phillip.stevens]

And you could theoretically build this into a CP/M program? (the COM file would have to reside on a normal CP/M formatted drive, but you could load data in-program from a FAT partition on a different drive?)

Yes. Absolutely.

Actually I have a cunning plan, and that is to build a "modern" CP/M2.2 platform with FAT32 disks, and memory banking similar to ZDOS, potentially looking quite a bit like (if not the same as) FUZIX, that can run CP/M applications without all the mucking about with inefficient file types and other limitations from the 1980s. Admittedly, one should produce running code before one mouths off about stuff. But, it is a medium - long term outcome focus for me.

Have you looked at an app called "RUNCPM"?  I believe RUNCPM does this by replacing the BDOS and BIOS layers in CPM, while running the stock CCP layer.  Seems to me the same think could be done on the Z80 to access media formatted in FATxx fashion. 

Tom,

that I had not seen before, but it looks like exactly the source tree that I'll be leaning on for my cunning plan. Perfect.

Thank you!

That is one of the best things about Z80. It was so popular and successful, you can be sure that you're never the first to attempt something.

Someone will always have done it before.

Cheers, Phillip

[phillip.stevens]

That's faster than I imagined.

Yes, it is faster than I imagined too. By 10x what PJRC mentioned on his web site. The performance is purely driven by the number of reads and writes to the 82C55, so I used the Z80 ini and outi to great benefit, allowing me to run the interface more efficiently than PJRC was doing with his 8051 code. And, I've specifically written only byte and sector transfer routines, and tried to optimise for that. PJRC went about it a bit differently.

Will be interesting to see what kind of performance you get vs bit banging the compact flash card in 8 bit mode. I expect it's not going to make any difference at all.

Well the question is intriguing enough to make it worth a bit of an investigation. So, I took my `diskio.c` test program, put in some timing captures and increased the sector count to 32 (512 byte) sector writes and reads. And the results are in.

Kingspec-SSD KSD-PA18.6-XXXMS    16kB W/R in    14 /256th of a second or about 292kB/s.

I'll try some C interface (FatFs) speed testing, of file copies, etc, to see how much performance is lost between C wrapped asm diskIO functions, and the FatFs calls.

 total_bytes = 0;
 for (;;)
 {
   res = f_read(&FileIn, buffer, sizeof(buffer), &br);
   if (res || br == 0) break;   /* error or eof */
   res = f_write(&FileOut, buffer, br, &bw);
   total_bytes += bw;
   if (res || bw < br) break;   /* error or disk full */
 }

Well a FatFs simple file copy read -> write file produces between 113kB/s and 118kB/s copied, using the Kingspec-SSD

(which will be no different in speed to any other drive in PIO mode).

So the net FatFS read or write rate is about 220kB/s, so we lose about 70kB/s to the C wrapper and file system management for this simple task.

Cheers, Phillip

[Ed Brindley]

Nice work.

Many thanks for your assistance so far, I have it working on breadboard in RomWBW. (It's taken all day... using a PLCC44 to DIP40 adapter contributed to the confusion)

I'm wondering about "The 82C55 needs "tWA" (Address Stable after /WR) to be 20ns. This means the /CS must be generated from just the address lines in Z180 world.

Don't incorporate the /IORQ line in the /CS calculation, or the /CS will be tied to the /WR (/IORQ) timing, rather than to the address validity timing."

It seems to work OK using /IORQ as the CS for the 82c55, and I see the DiskIO V3 design also uses it too... https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:diskio-v3:ecb_diskio_v3_-_schematics_-_color_1.0.pdf

Any thoughts? As it works I'm inclined to leave it...

Cheers,
Ed

[PianoMatt]

Ed, are you using a Z80 or a Z180?

[Tom Szolyga]

HI Ed and Philip,

I entered your schematic into EasyEDA using the 40 Pin DIP 82C55.  I created a PCB using Auto route nd created the FAB output.  (See attached)  Fab'ing the board and shipping to me will take about 2 weeks.

Best regards,

Tom

Tuesday, September 19, 2017 at 4:54:22 PM UTC-7, Ed Brindley wrote: