PDA

View Full Version : Ferguson BigBoard 1



enrico
February 14th, 2010, 12:53 PM
Hi at all, i updated my website http://elazzerini.interfree.it about this SBC z80 based.
Pls let me know suggestions, and also othe useful info.
Regards
Enrico

pavery
February 14th, 2010, 01:27 PM
Hi Enrico

It sounds like you need help to get your Ferguson BigBoard working. I've been through a similar experience with my Kaypro II recently (http://www.vintage-computer.com/vcforum/showthread.php?19237-Kaypro-PIO-puzzle)(which has a similar board to the BigBoard I understand).

I'm not a full-blown expert, but am willing to try. I'm sure others will chip in if we get stuck. :)

Firstly, I'd like to verify Reset.

Philip

Chuck(G)
February 14th, 2010, 03:46 PM
The Big Board is very similar to the Xerox 820 (Model I)--Xerox licensed the BB design for the 820. The BB II is a bit different.

Micro Cornucopia was one of the magazines that featured quite a bit of BB content.

Dr_Acula
February 14th, 2010, 08:40 PM
I see down the bottom of your webpage the testing you have done. Any input from anyone who has a board similar to this will be extremely helpful. I build boards from new, so maybe I can't give as much specific advice, though many boards I design don't work straight away so I've got good at debugging.

That scope trace shows a clock that looks fine and a reset signal that also looks fine.

Well, next step is drastic but I've done it several times. Take a 555, configure it to produce a square wave every 20 seconds and feed it into the clock of the Z80. You clock it at 0.05 hz. That gives you enough time to run around with the logic probe and you should see the first byte in the eprom being loaded. If it loads the second byte, then it processed the first instruction and that means a lot of things are working.

Hopefully you have an eprom with the right data. Do you have an eprom reader?

Chuck(G)
February 14th, 2010, 08:57 PM
Fortunately, it's easy with a Z80 to figure out what's happening or not happening.

What do the waveforms on pin 17 (NMI) 27 (M1) 18 (HALT) and 19 (MREQ) look like? Is M1 pulsing (i.e. executing instructions)?
Similarly, NMI\ should be high, as should HALT\.

enrico
February 17th, 2010, 09:28 AM
Well, i just today check the signal you asked for. They are at this link http://elazzerini.interfree.it/Test2.htm.
I saw your jet leg is almost 9 to 12 hours ahead. I was asking if someone of you would help me if i could get a skype web cam and connect via internet.
All schematics of my SBC are here p://elazzerini.interfree.it/Big_Board_1980.pdf pages 2-01 and A-01.
Thanks for all your cool support.
Enrico

Chuck(G)
February 17th, 2010, 10:05 AM
Enrico, your traces show me that at least the Z80 is operating normally--it appears to be executing instructions and is not halted. It does not appear to have NMI asserted, which is also good.

I use this document (http://bitsavers.informatik.uni-stuttgart.de/pdf/ferguson/Big_Board_1980.pdf) for my reference.

At this point, I'd probably hook a logic analyzer to the Z80 and trigger off of M1 to see what was getting through to the Z80 in the way of instructions. If you do not have access to one, you may want to use this simple setup (http://developer.berlios.de/projects/tfla-01/). It's probably adequate for this job.

One place that I would start looking is at the buffers to the Z80 (U83, U65, U78, U79, U82). A failure in any of these would produce the problem you're seeing.

Hardware debugging long-distance is very difficult and time-consuming (just ask Lorne). Perhaps another member would have the time, but it's not possible for me at this point.

enrico
February 17th, 2010, 11:57 AM
Dear Chuck would you so kind to write directly to me for explain better http://developer.berlios.de/projects/tfla-01/ ?
elazzeriniATinterfree.it (change AT with @). It seems something to load and use a parallel port to get more logic states, but i need to understand better.
Thanks Enrico

pavery
February 17th, 2010, 12:05 PM
One place that I would start looking is at the buffers to the Z80 (U83, U65, U78, U79, U82). A failure in any of these would produce the problem you're seeing.

Hardware debugging long-distance is very difficult and time-consuming (just ask Lorne). Perhaps another member would have the time, but it's not possible for me at this point.

I can put some time into this one, Chuck(G). While I don't have your level of expertise, I worked my way around my Kaypro board with a multitude of faults. Further study of the BB schematics show this to very similar to the Kaypro II.

Enrico: I don't have Skype. What I propose is I give you pin numbers of i/cs to test, and you report back with results. Do you have a logic probe? This makes it easier at my end - just reply with HI, LO or pulsing.

After carefully reading your web-site, (and what you indicate from above regarding the Z80 signals), I would like to confirm the Monitor EPROM is being enabled at bootup. I noted you have inserted a replacement *special* eprom which doesn't access RAM, perhaps just loops on its self? Could you please place the probe on pin 18 of U67 (2716 EPROM) and press Reset. What is the signal? Also, do the same for pin 20 please.

Thanks
Philip

enrico
February 17th, 2010, 12:57 PM
I WISH TO THANKS YOU BOTH FOR YOUR KIND SUPPORT!

For Chuck: i got a look to the digital analyzer. It'd be a cool thing. Maybe more useful if you wish to make some accurate adjustment between the signals state looking well what chip could take more late or so on. And then i'd need to build the little interface. Then i'd need to study deeply the Z80 to know what have to happen time by time at each front of clock signal. While i can just understand something of all this, ALL this one is very hard and so far from my each thing i do everyday (job, wife, son, tax, etc.).
Anyway i WISH to thank for ALL your suggestions that internet make so close to me.

Would be more useful to take images from what are the state of all other signals: address bus, data bus and control signals (RD,WR,IORQ???) directly to the CPU and after when they are buffered from the chips you write prior (U83, U65, U78, U79, U82).
I remember just now that some of address bus or data bus seem to me a little strange. I mean some of them maybe was always to high or low level and they not switched fine. I'd have to check better. But if i not remember wrongl they remained in the same level EVEN i taken away the buffering chip like U83 or U65, U78 or U79. I repeat: i have to check again better.

For Pavery: it's natural that BB schematics is very similar to the Kaypro II: Kaypro was born from or maybe has been copied fron the BB1. Then WOW: "What I propose is I give you pin numbers of i/cs to test, and you report back with results" this would be the best for me, but i not have any logic probe. Would be so hard to build one? Where i could find a schematic?

About your affirmation: I would like to confirm the Monitor EPROM is being enabled at bootup. I noted you have inserted a replacement *special* eprom which doesn't access RAM, perhaps just loops on its self? My answer is what Gary E Kaufman [gkaufmanATthe-planet.org] written back to me on the last month 2010: "The Big Board does an interesting trick at startup - it copies the EPROM to DRAM and then does a bank swap. If the dram is not functioning correctly or the swap does not occur it will crash. I have appended the code of an alternate "debug" eprom that uses the video memory only. It will not let you boot, but will let you do a memory test and debug". So this sounds good to bypass RAM problem and check the other parts of the PCB.

An the end: Could you please place the probe on pin 18 of U67 (2716 EPROM) and press Reset. What is the signal? Also, do the same for pin 20 please. Sorry i have not any probe.

Would be more simple to exchange email privately? elazzeriniATinterfree.it

Enrico

Chuck(G)
February 17th, 2010, 01:26 PM
Dear Enrico, the idea behind a logic analyzer such as that on the berlios site is that it captures the state of several signals at the same time and can be set to begin capture upon the transition of one or more of these signals.

As an example, if you wanted to see the first instruction that was read by the Z80, you could set the sample lines on the M1 and D0-7 signals and then trigger on the transition of the M1 line from high to low. D0 through D7 would then show what data was being presented at that moment and you could then tell what instruction was being executed. Even better, the logic analyzer continues to capture data until the buffer is full, thus you can see the activity of the data lines for several throusand cycles. A very handy device to own in these situations.

Another devices is an In-Circuit Emulator (ICE) that takes the place of your Z80 chip and allows you to examine and control the Z80 with another computer.

If you are using the "standard" 2716 EPROM with the Big Board Monitor software, I note that the first task performed is the clearing of the display memory to spaces. Since that isn't happening, the failure is probably somewhere between the Z80 and memory.

pavery
February 17th, 2010, 01:43 PM
"What I propose is I give you pin numbers of i/cs to test, and you report back with results" this would be the best for me, but i not have any logic probe. Would be so hard to build one? Where i could find a schematic?
I think you'd be best to buy a probe. They aren't expensive and yet are an excellent troubleshooting tool. IMHO for most faultfinding, they have 4 advantages over a scope (particularly for beginners): they are far cheaper, easier to interpret signal levels, have a 'memory' function (which only expensive, hi-end scopes have), have audible output so you can use eyes to keep test probe on i/c pin without diverting away to see scope.


Would be more simple to exchange email privately? elazzeriniATinterfree.it
No, I think it's fine to keep it on the Forum. Others may learn things as we go along, or we may need help at some stage. Experts could read past notes and offer opinions.

Philip

enrico
February 17th, 2010, 02:13 PM
For Chuck. What you told is GREAT and this affascinate me. If i had not all heavy things to do i'd running to find the way to build it NOW. The idea that it is possible to read each byte while is presented on the data bus and match all with the eprom firmware is very cool. Also to get control from an external computer take me to think how would be cool to do experiment. So i can understand well what great experience may you done to say: If you are using the "standard" 2716 EPROM with the Big Board Monitor software, I note that the first task performed is the clearing of the display memory to spaces. Since that isn't happening, the failure is probably somewhere between the Z80 and memory. So this take to think to the ALL TTL chips (U83, U65, U78, U79, U82) that interface the CPU with the logic IC around.
Let me ask: maybe are you more familiar to check those PCB with those instruments than to use a logic probe so your suggestion go in this sense?

To use a logic probe seems more simple and cheap ( few euro on ebay) than to build the The Fabulous Logic Analyzer #1. But the results seem so very different.
Anyway let me go to bed it's midnight here in italy. I hope tomorow to gain pictures of address bus, data bus and control signals (RD,WR,IORQ???) directly to the CPU and after when they are buffered from the chips you write prior (U83, U65, U78, U79, U82) and with them aboard and out of their sockets to understand what happend.

Let me say that 1 year ago i take away ALL chips and checked each wire following the schematics and verifing nothing of wrong. I read also the eprom so i have its contents and i remember to tried to disassembe it.

Regards COOL friends
Enrico

Chuck(G)
February 17th, 2010, 03:09 PM
Enrico, I just an old engineer and there never was a problem locating the right tool for the job (providing it was my employer's job!). So I'm used to using the best tool for the job.

My problem with a logic probe is that it will tell you nothing more than your scope will tell you already--and with less detail. A logic analyzer just seems to me to be the right tool for the job, but that is not to say that you cannot locate the fault some other way--it simply takes longer and involves much more exercise of the stuff between your ears. Do compare the contents of the EPROM that you read with the EPROM listing at the end of the Bitsavers document.

I am certain that pavery can take good care of you.

enrico
February 19th, 2010, 09:56 AM
At this link http://elazzerini.interfree.it/Test3.htm you can find the pics i done in each pin of the ic (U83, U65, U78, U79, U82) indicates from chuck. I say again the reference for schematics of the sbc http://elazzerini.interfree.it/Big_Board_1980.pdf pages 2-01 and A-01
Thanks
Enrico

enrico
December 9th, 2010, 02:09 PM
Hello, there are great news on my card.
Thanks to a dear friend more experienced than me, using a digital analyzer has determined what the z80 processor was doing making sure that there was a sporadic error in copying the contents of the ROM into the DRAM. In practice, there were 74LS157 IC instead of the 74157 IC consequently there was not enough current to drive the 32 DRAM chips. In fact, this seems like a design error cause the 74157 has a maximum fanout of 10, while memory chips are 32 x 4116. It would be enough buffer chips to provide more current to drive the IC memory. At the time have been replaced with 74157 and everything seems to reset correctly. Finally, it appeared the prompt but strangely had the same bit wrong. It was re-verify the welds of the character generator EPROM. At the time the card is still under repair from my precious friend: it seems to be malfunctioning strobe the keyboard. I look forward to further developments.
Updates on my website: http://elazzerini.interfree.it
I'm looking for more cards, addons, microcornucopia magazine, user's and CP/M diskettes, and all stuffs, information, testimonials, suggestions, etc..
Enrico - PISA - ITALY
Email: elazzerini AT interfree DOT it

Chuck(G)
December 9th, 2010, 02:33 PM
To be totally consistent, you probably want to use a 74S157 or 74AS157 or even a 74F157 chip instead of the older and slower (and more power-hungry) 74157.

And 4116 memory chips are MOS, so require much less drive current than normal TTL, so the fanout doesn't matter that much. However, they are a highly capacitive load, which can raise problems with getting a good clean drive waveform.

For whatever it's worth.

enrico
December 10th, 2010, 11:20 AM
Thanks Chuck for your response, you could explain better differences between the chips? From the datasheet I found on the internet that a 74LS157 and 74157 have the same typical 9ms delay, the first 49mW and an IoL = 8mA while the second 150mW and IoL = 16mA. Where exactly, the difference? Here the datasheet:
http://enricolazzerini.interfree.it/DM74157.pdf
http://enricolazzerini.interfree.it/DM74AS157.pdf
http://enricolazzerini.interfree.it/DM74F157.pdf
http://enricolazzerini.interfree.it/DM74S157.pdf
http://enricolazzerini.interfree.it/DM74LS157.pdf
In any case, the replacement of the 74LS157 with the same numbers of74157 has solved the problem, but is this enough?
Thanks
Henry

Chuck(G)
December 10th, 2010, 11:40 AM
Hi Henry,

To begin with, the plain-Jane 157 is old late 1960's/early 70's technology. In spite of the seemingly-identical function, all of these devices are implemented in very different ways internally.

The versions with an "S" in their part numbers employ Schottky diode clamping, that limits undershoot (important when you're driving capacitive or inductive loads) and generally improves the performance speed.

"L" implies a low-power version, as you can see with the maximum output drive current (Io).

"AS" is advanced Schottky--a low fanin (input current), but the fanout (output current) is just as high as the old plain version.

"F" (stands for "fast") is a logic implementation originated by Fairchild and precedes "AS" and has characteristics somewhere between LS and AS.

I'm certain this information is on the web somewhere.

enrico
December 11th, 2010, 12:27 PM
Hello Chuck, thanks for the clarification. It would be too complex to read all the datasheets and see technological change

as a result of which it was possible to obtain the differences between S, AS, F, etc.. But from what I can I know the

parameters to be checked to decide to use one of these in place of 74157 should be the IoL (output current at low level) and the total delay. I do not know what makes sense to consider the consumption of the chip. In the schematic of bigboard 1 both 74157 chips (U57 and U58) allow to address the memory cell in which it will store the data
so their outputs act on DRAM's ports A0-A6 (A7-A13). This means that each output pin of the 74157 "sees" the same pin of ALL 32 chip 4116. If you go to

the datasheet of 4116 it shows that a ii(L) = input leakage current can be max 10microampere multiply by 32 chips = 0.32mA. How is it that the datasheet of 74LS157:
IOH = HIGH Level Output Current = -0.4 mA
IOL = LOW Level Output Current = 8 mA
seem values compatible with the absorption of DRAM chips. Instead it was necessary to replace JUST 2x74LS157 with 2x 74157 IC to can access correctly in write mode to the locations and to ave the clear screen and the bigboard's prompt.

Enrico

Chuck(G)
December 11th, 2010, 01:26 PM
That Iol for the 4116 is the "maximum", not the average, so you're still well within the static current margin.

No, what you have to worry about is C(iA), the input capacitance of the address lines. A quick look at the datasheet shows between 4-8 pF for the TI TMS4116. Since you have 8 chips in a row, you're looking at between 32-64 pF, which is a pretty heavy capacitive load for an LS157 at 4MHz! It was the practice back then to insert small resistors in series with the address lines to damp the effects of a capacitive load, but it's still asking a lot.

Back when I was designing with these DRAMs, I'd specify the "S" part. Of course I would not have used the 74xxx part, because by the time 4116s became available it was obsolete technology.