Dave, looks like there is a bug in my 68K monitor, I cannot get QO04,22 to even change the LED’s on the parallel port I/O board. Also tried ports 0004, FF0004 etc. Stuck with other things right now so cannot go back to that software right now. Let me know if you fins the same thing John From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of yoda 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. 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 Monahan (mon...@vitasoft.org) On Jun 10, 2014 1:28 PM, "yoda" <yo...@r2d2.org> 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
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: n8ve...@googlegroups.com [mailto:n8ve...@googlegroups.com] On Behalf Of Thomas Owen Dave (yoda), All, During assembly the board passed all the 'in progress' checks. The final steps were to output to different ports:
QO33,80 ; Configures ports A, B and C as output ports QO32,2c; Selects middle pair of digits QO32,2d; Selects left hand pair of digits 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, -- -- |