FYI - I am using the 68K running at 6MHz so it is not specific to Z80 - 
Sorry for the mistake above - I had not traced the truth table all the way 
thru - so U7 is not active - I forgot the DO0 comes directly from the buss 
- with the logic analyzer experiment above we should be able to see what is 
going on.  The solution may be another issue - I should have some traces 
tonight when I get home from work.

Dave


On Monday, June 9, 2014 12:25:18 PM UTC-5, monahanz wrote:
>
> This is a real old board, in fact I think it was the first board I laid 
> out (back in 2009), no excuse I know, but I would do it slightly 
> differently now.   
>
>  
>
> For sure mine works fine. I can pip A: to F: with verify with CPM3 no 
> problem with the 10MH Z80 board.  Works with the prototype 80386 fine as 
> well (which is way less forgiving in terms of timing). Never a problem with 
> the 8088, 8086 or 80286 boards. In fact that IDE board is one I can really 
> count on.  So I’m at a loss to understand the problem.  I using two boards 
> labeled Version 02. Hopefully it’s not something about V02a
>
>  
>
> The reason DO0 has its own input and not taken from U7 (the boards 
> bidirectional data bus) Dave  is that I wanted to make sure  the data line 
> would never be “glitched” . The 8255 is always connected to that 
> bidirectional data bus.  When you change modes with the 8255 strange 
> (transient) things happen with the data lines.  This was mentioned in one 
> of the earlier articles mentioned that I based the design on.
>
>  
>
> If there is a race condition, Thomas can you drop the Z80 down to say 2MHz 
> and see if the problem persists.  If a problem we can try delaying U15A’s 
> pin 1 to the FF with a resistor/cap, or using a 74L02.
>
>  
>
> The above said we need to get to the bottom of this because it’s a must 
> that this board is reliable to go forward building these S100 systems.
>
>  
>
> John
>
>  
>
>  
>
> *From:* [email protected] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *Thomas Owen
> *Sent:* Monday, June 9, 2014 9:16 AM
> *To:* [email protected] <javascript:>
> *Subject:* [N8VEM-S100:4063] Re: CF IDE card checkout and final assembly 
> problem
>
>  
>
> John,
>
> It is the newest batch I believe, '02a'.
>
> Thanks
>
> On Sunday, June 8, 2014 7:58:45 PM UTC-4, Thomas Owen wrote:
>
> All,
> I had posted this to the thread dealing with ordering this card, but 
> decided to post a new topic dealing with the problem I have had with final 
> checkout of the board.
>
> During assembly the board passed all the 'in progress' checks.  The final 
> steps were to output to different ports:
>
>
> I have output the following and everything passes:
>
> QO33,80 ; Configures ports A, B and C as output ports
> QO32,2B ; Selects right hand pair of digits
> QO30,01; display 01on right digit pair and work through each bit - all ok
>
> QO32,2c; Selects middle pair of digits
> QO30,01; Should display 01 on middle digit pair, work through each bit - 
> all ok
>
> QO32,2d; Selects left hand pair of digits
> QO31,01; Should display 01 on left digit pair, work through each bit - all 
> ok
>
> All displays are correct.
>
> Now the final step is the Drive Select and that is where I am having 
> trouble:
>
> Board always comes up with 'Drive A' selected
>
> Now,  QO34,0; no change
>
> Reset, start again:
>
> QO34,1; no change
>
> I can never select drive B.   
>
> Several generous members (thank you David Fry) have made suggestions, and 
> here is where I now stand:
>
> My preliminary check this afternoon shows me that there is a timing issue 
> at U15, the 74ls02.  Using my logic analyzer and monitoring the inputs and 
> the output (which clocks the drive select flip flop) I see a big timing 
> difference between SEL_SECOND and WR.
>
> What this means is that the output of the gate never goes high allowing 
> the bit change to effect drive change/selection.
>
> I am going to get some screen shots from the analyzer tomorrow, and if 
> anyone has any suggestions I would greatly appreciate it.
>
> Thanks,
> Thomas
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "N8VEM-S100" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to