OK - when you get a chance just use the query out command in the monitor and write a 1 to port 0x00ff0034 and see if the LED changes - pretty simple to test from monitor.
On Tuesday, June 10, 2014 3:41:09 PM UTC-5, monahanz wrote: > > Have not had software to test the board with the 68k. One worry Wilcox > had a strange resistor + cap on the schematic for D0 (only) in his book. > Traveling so no access but find the schematic near the end of the book > John > > John Monahan ([email protected] <javascript:>) > On Jun 10, 2014 1:28 PM, "yoda" <[email protected] <javascript:>> wrote: > >> Hi John >> >> Have your tried changing drives with the 68K board? - I think I see the >> same problem - have not put the logic analyzer on it yet. We may need to >> update the IDE board in the future because it is so close to the leading >> edge - the inversion of the clock signal gives plenty of margin. BTW, I >> almost have the IDE working with the 68K board and will be getting CP/M 68K >> running shortly after that. >> >> Dave >> >> On Monday, June 9, 2014 6:31:29 PM UTC-5, monahanz wrote: >>> >>> Thomas, this kind of thing was one of the reasons why the S100 bus >>> IEEE-696 standard was setup. A number of the early Z80 boards (like the >>> Cromemco and TDL Z80 boards) did not shoehorn some of the signals well to >>> work with other boards. The IEEE spec specifies that the main Read/Write >>> strobes rise and fall (or fall & rise) completely within the window in >>> which the address lines are stable. If you look at our Z80 board page you >>> will see that the pDBIN and pWR* strobes meet this criteria. See here:- >>> >>> http://s100computers.com/My%20System%20Pages/Z80%20Board/ >>> Z80%20CPU%20Board.htm >>> >>> >>> >>> Scroll down to “status signal decoding”. It looks like you can get away >>> with it at 2MHz but I’m afraid at higher speeds it will catch up with you. >>> I run the above Z80 board at 10MHz (+2 I/O wait states). >>> >>> >>> >>> The easiest way to take care of the above problem is to latch the >>> address lines on the CPU board, the early boards did not and delay the R/W >>> strobes with a few gates. That’s what is done on our Z80 board. This >>> apparently minor point, caused me no end of problems getting the 80386 to >>> work on the bus. It took two prototype versions to have a pWR* strobe meet >>> the above criteria and work reliably with new and old S100 RAM boards. >>> >>> >>> >>> John >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* [email protected] [mailto:[email protected]] *On >>> Behalf Of *Thomas Owen >>> *Sent:* Monday, June 9, 2014 3:23 PM >>> *To:* [email protected] >>> *Subject:* [N8VEM-S100:4095] Re: CF IDE card checkout and final >>> assembly problem >>> >>> >>> >>> Dave (yoda), >>> I like your suggestion and in fact, it works perfectly as well. By >>> using that inverted clock falling edge (inverted) into the flip flop you >>> are clocking signals well after they are established. >>> >>> I will take some screen shots in the morning and post. >>> >>> Thanks again to all, >>> Thomas >>> >>> 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]. >>> 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.
