Ortonview PCB

[SiriusHardware]

using the 6116P-4

Not LP-4? If not, maybe that's what's making the difference.

[Timbucus]

Originally Posted by SiriusHardware

Not LP-4? If not, maybe that's what's making the difference.

Just double checked - correct just 6116P-4 - I have been playing most of the day - not had an issue yet - note that I still have the caps as well as the buffers as I had soldered them in as I did not have turned pin strips but, I may take them out and see.

[Timbucus]

Originally Posted by SiriusHardware

Groan, this is awful. Three substantially different results with essentially similar hardware.

Tim: Buffers in, but... capacitors in, or capacitors out? What chip family are your 365s?

Are we all agreed that the classic mode - unbuffered and with capacitors on A8-A11 - is working 100%?

I have been out for most of the day so that is where my testing is going to be for now, in classic (unbuffered) mode. We need to show that there is at least one configuration in which this can be expected to work for all builders / users.

And to confim they are LS365 brand new from Farnell - so in my case both modes seem rock stable.

I can confirm that the jumping in Graphics mode appears when you upgrade an 'A' chip to FW692 from FW352 still so that is consistent.

[Timbucus]

As I said I should have the chips that Slothie recommended by Tuesday so I can swap that out and see of it gets bad.

[Mark1960]

I was wondering if the buffers should have pullups on the inputs if 74hct365 is used instead of the 74ls365. 74ls365 is probably going to be ok without pullups as 74ls ttl inputs tend to float high. I’m not sure if 74hct floats high or low, but always see recommendation to not leave then floating.

[SiriusHardware]

The inputs on the buffers are constantly connected to the PIC address-driving pins which are in input mode, in which they probably exert a weak pullup on the buffer inputs, most of the time. The buffers will translate that to a strong high on all outputs if they are enabled while the PIC pins are still inputs.

[SiriusHardware]

note that I still have the caps as well as the buffers as I had soldered them in

Right, so obviously I am thinking that your flawless operation in buffered mode is actually due to the presence of the capacitors, curing the same problem that they cure in unbuffered mode.

[Timbucus]

Originally Posted by SiriusHardware

Right, so obviously I am thinking that your flawless operation in buffered mode is actually due to the presence of the capacitors, curing the same problem that they cure in unbuffered mode.

Which of course means that they are not really needed. But, at least if you can get the same effect then we can build a stable Ortonview on this card with our capacitor fix.

[SiriusHardware]

Which of course means that they are not really needed

Meaning the buffers, or the capacitors?

I think from the time Mark first suggested the capacitors and wow, they worked, we have been able to say that we have a satisfactorily working version of OrtonView, but it is a fairly unpleasant bodge - you should never have to fix a digital problem by intentionally rounding off the corners on some of the main signal lines.

The buffers are just a (so far, manifestly unsuccessful) attempt at fixing the problem the 'proper' way.

[Timbucus]

Originally Posted by SiriusHardware

Meaning the buffers, or the capacitors?

I think from the time Mark first suggested the capacitors and wow, they worked, we have been able to say that we have a satisfactorily working version of OrtonView, but it is a fairly unpleasant bodge - you should never have to fix a digital problem by intentionally rounding off the corners on some of the main signal lines.

The buffers are just a (so far, manifestly unsuccessful) attempt at fixing the problem the 'proper' way.

The Buffers I meant - I am more pragmatic - it is a Sinclair - the place that stuck variously a Diode, a Transistor an upside down chip and others to 'fix' things... then sent them out the door.

But, I understand the technical challenge to eliminate this dirty workaround.

[SiriusHardware]

As I've pointed out, Karen herself was pragmatic enough to use capacitors to solve unanticipated problems, most notably the ones she placed across the base resistors on the LED / column drive transistors in PIC14, after it turned out that they were not switching fast enough. There's every chance that she would have said 'yep, just go with that', but it is equally possible that she too would have wanted to understand the underlying cause.

I am just curious - as I know Slothie is - to understand why it is necessary to slow down the rate of the change of state of A8-A11 in order to 'fix' the problem, or rather to understand what problem it is which has to be 'fixed' in this way.

The good news is that anyone who just wants a working MK14 VDU can build OrtonView, unbuffered, capacitored and no questions asked, and it should 'just work'. Never mind why it does.

[Slothie]

Well I was just looking at the buses with the logic analyser and was seeing some strange things, on investigation found I had broken the A10 track from the load cap to the buffer, I have now joined the pins with a short wire, and things look much more sensible.

I am seeing NWDS being asserted after NENIN goes high, but NENIN always goes back to '1' within 1uS, and there is no sign of the top 4 address lines being driven until 37uS after NENIN goes high.

As yet, I can't see any other suspicious activity.

However, I mapped the VDU to display Fxx on the top and Bxx on the bottom, loaded the testmem program and ran it. It is quite obvious that random points on the screen (i.e. memory locations) are getting changed from time to time and sooner or later the program gets corrupted and a block of memory gets overwritten, so there must be a rare occurance that I am not able to capture with my logic analyser due to its trigger limitations.

[Mark1960]

Originally Posted by Timbucus

Which of course means that they are not really needed. But, at least if you can get the same effect then we can build a stable Ortonview on this card with our capacitor fix.

Not sure if this is conclusive yet that the buffers are not the reason the original mk14 vdu does not show the memory corruption but it does seem to be pointing in that direction.

I think the remaining possibility is that the original mk14 vdu is synchronized to the mk14 clock, maybe the bad timing of NWDS to address only occurs when NENIN is raised at a certain time in the write cycle.

If the PIC osc in is driven by an external 16MHz clock then I think the PIC osc out would be 4MHZ, but using that to clock the mk14 would mean hacking the mk14 which I’m sure we don’t want to do.

We might try registering the NENIN from the PIC to the XOUT of the mk14 using a 74ls74 or 74hct74. The 250 ns delay this might introduce shouldn’t be a problem.

[SiriusHardware]

I can't quite visualise how that would work (pure digital logic is not my strong point - maybe you can expand on it a bit?)

Another possibility is to somehow multiply the MK14 CLK-OUT signal by four and use the resulting 16MHz signal to clock the PIC instead of using a crystal.

[Mark1960]

If NENIN from the PIC is connected to the D input of one half of a 74ls74, then XOUT from the MK14 connected to the clock input of the 74ls74, and the Q output of the 74ls74 then provides the NENIN signal to the MK14. That way the NENIN to the 8060 always changes at the same time relative to the rising edge of the 8060 clock.

I’m not sure if the original MK14 vdu changes NENIN relative to the rising edge or the falling edge of the clock. I’ll take another look at the schematic for the MK14 vdu and see if I can figure that out.

[Mark1960]

In the MK14 vdu, MK14 XOUT is buffered but not inverted the provides clock input to a 74ls74 configured as divide by two, so I think NENIN should be timed relative to the rising edge of XOUT.

Then there is a delay between the rising edge of XOUT and NENIN, propagation time of IC4 74ls74, IC3 74ls93, IC6 4040, two gates of IC7 74ls04 or 74l04, one gate of IC2 74ls20, RC 4.7k and 82 or 100pF, IC5 74ls4011, and Q4 BC239.

I don’t want to try and calculate that delay, maybe Tim could measure from rising edge of XOUT clock to rising edge of NENIN on an original or replica MK14?

Probably better to use a monostable to generate a delay of that order of magnitude, I’ll take a look through some datasheets.

[SiriusHardware]

I understand a little better now, but what about a case like Slothie's where the OrtonView and MK14 are not only unsynchronised but running at very different speeds (OrtonView nominally 4MHz, derived from 16MHz, but the MK14 is running at a significantly different frequency (4.43MHz)?

If the problems are related to the phase relationship between the two clocks you would think they would be much more exaggerated when the two clocks are quite different. (I can appreciate that even two '4MHz' clocks running independently will not be exactly the same frequency and will shift in and out of phase all the time.)

[Mark1960]

Originally Posted by SiriusHardware

I understand a little better now, but what about a case like Slothie's where the OrtonView and MK14 are not only unsynchronised but running at very different speeds (OrtonView nominally 4MHz, derived from 16MHz, but the MK14 is running at a significantly different frequency (4.43MHz)?

I don’t think it would matter that the clocks are different, just that NENIN is raised at a particular time relative to the clock of the 8060. If the corrupted write cycles are caused by NENIN timing.

I took a look through some datasheets for monostables, the fairchild AN-366 is a good reference.
http://www.scarpaz.com/Documents/AN-366.pdf

One of the problems to watch out for is that most of them will trigger on release of the clear input, though the 74ls423 is meant to fix that. We might be able to synch the NENIN to a time relative to the 8060 clock using a single 74ls423.

74ls74 is more common, so maybe rather than sourcing a specific part we should stick to the 74ls74 as I described earlier, followed by an RC delay, and use the second half of the 74ls74 as a buffer following the RC.

[SiriusHardware]

Well. I've just spent quite a while with OrtonView in 'classic' mode.

-Buffers bypassed.
-4 x 150pF, then 4 x 220pF from A8-A11
-Graphics mode, pointing at 0200-03FF

Sorry to have to say that even in this mode the content of the extra-extra memory (the 6116) is not as stable as I would like.

I've slowed down the uploader so that it loads code reliably even when the VDU is enabled and I have tested that by loading alternate programs into the 'normal' MK14 RAM - loads code first time every time there. But if I repeatedly load one or other of our test images into 0200->, what I tend to see is the image building up line by line on the screen but I also often see a pixel or two well away from the area which is being loaded into, changing, maybe once per upload.

More often than not these are the same two or three bytes which keep getting boinked during uploading, and this is interesting, if I swap my other spare EL6116LP-10 RAM in, then a different two or three bytes tend, consistently, to be the unstable ones, the ones which are getting changed when code is being written to some other address in the chip.

By now you'll be thinking I must have a bucketload of slightly duff RAM. I know I'm starting to think that way.

If I put any of the Hitachi 6116LP-3 ICs in the system still goes bananas but I am willing to bet that if I put them in my Maplin Z80 CPU board they will all work. I do also have a chip test built into my device programmer, which includes a test for 6116s, so I will give them a run through.

I'm going to have to have a hunt around for a third brand / type of RAM, ideally non-LP, to see what that does.

The strange thing is that the EL6116LP-10 on my original 'bridge' board never suffered from this problem - unfortunately I can't try that original IC in this setup because it is soldered pins-flat onto the underside of the bridge board.

[SiriusHardware]

Looking at my bridge board again, it has 4K7 pullups on both NRDS and NWDS so I may as well try reducing the NRDS pullup (currently 10K on the new board) to 4K7, and also there is no pullup on the CE pin of the 6116, it is pulled up or down solely by the action of the output of the address decoder on my original PCB.

The address decoder on the original bridge board also happens to be a 74LS rather than 74HCT as presently fitted on the Slothie-OrtonView.

While I can't imagine any of these things making a huge difference, I suppose they are there to be eliminated from enquiries.