Ortonview PCB

[Mark1960]

I’m using 4MHz, no buffers, no capacitors and #692 firmware.

My MK14 issue VI has a socket for the crystal, so I can try 4.433619 to check if we can set a delay that works for both.

Maybe I should socket the preset so it can be removed and measured.

[Mark1960]

Originally Posted by Slothie

I was wondering if we could use the rising edge of NADS to gate NENIN, as every read/write operation is always preceded by NADS, the downsides to this is that it is an ugly kludge, and that executing DLY statements would probably break it, as I don't beleive the SC/MP processes any memory cycles during a DLY. Also the original board didn't need NADS, so we shouldnt need it. I get the feeling that our friends at SoC might have had to do some "fine tuning" of their circuit to get it to work. It seems to me it is using NENIN in a way it wasn't intended to be used, ignoring NENOUT and NBREQ. Although you shouldn't be able to break the system by just asserting NENIN at an inopportune moment.

It seems the 8060 doesn’t respond to NENIN as quickly as it is implied in the datasheet, I’ll need to think again about how the multiprocessor can control bus access without the impact of delay from NENIN to NENOUT.

I was thinking we could detect a write cycle using NADS and RFLG, and hold off until NWDS rising edge, but not even sure if that would be early enough detection of a write cycle after seeing how late NWDS can start after NENIN is raised.

For the SoC vdu to work it must be down to timing of NENIN from XOUT, I don’t see any other inputs from the MK14 that could be used.

[Slothie]

It seems really odd to me that the 8060 will release the drive of the address lines without pulling the NWDS high first, or at least at the same time!

[SiriusHardware]

just tried taking out the buffers and installing the links and it doesn't make a difference.

At least you can now be sure that whatever causes your problem, it is not the buffers.

[SiriusHardware]

I was thinking we could detect a write cycle using NADS and RFLG, and hold off until NWDS rising edge

One potential problem there is that NADS was not officially available on the edge connector on early original MK14s. I always thought it first appeared on issue III onwards but somewhere back in the mists of time someone seemed to contradict that idea. Next time I have my issue II out of storage I will make a point of metering that out.

[Mark1960]

It seems I was chasing two issues. A tight loop with ILD at B10 was changing both F10 and B30. Adding an RC delay fixed the spurious writes to F10 but not B30, that turned out to be a faulty RAM chip, also found another faulty ram chip while swapping out to get it working. So far thats 3 out of 10 bad from the last set from utsource. I've put them to one side to test in more detail later.

Attached circuit, using a 10k multiturn preset and 470pF. With 0 ohm the delay from xout rising edge is 48ns and still shows spurious writes to F10.

Increasing resistance to increase the delay and the spurious writes to F10 stop at about 180 ohm. This gives a delay of 70ns from rise of Xout to rise of NENIN.

i also increased the delay further to the rising edge of the next xout cycle and beyond, but could not reintroduce the fault, so I think further investigation is needed.

[Mark1960]

Scope plots of A10 and NWDS with 180 ohm, 70ns delay.

[SiriusHardware]

Nice work Mark, I will start to build this mod onto my board. It certainly looks as though it is shifting the relative timing of NWDS and the address bus change to good effect.

With regard to AM9111s, it is not so unusual to get a bad one, they are getting on a bit now. I don't imagine the sellers have the means to test each and every type of chip which comes their way. If they buy in a few tubes of NOS ICs, it is not unreasonable to hope that they will be OK if they look as though they haven't ever been used.

One of four of the ones I ordered from the German source pointed to by circuitryboy a while back was also dud, but promptly replaced with two, not just one, by that source. Both replacements were good, I offered to send one back, the seller declined, so I would not hesitate to use them again- unfortunately, they didn't have any more stock of AM9111 when I last checked.

[SiriusHardware]

I could not reintroduce the fault, so I think further investigation is needed.

Strange, but maybe this is accounted for by the fact that the edge of NENIN as applied to the MK14 is now synchronized to the system clock, whereas previously, it was not. Maybe we should just accept that it works, and not over-think it too much. Do your timing values also work with a system with a 4.43MHz clock, or might they need to be adjusted to work equally well with both 4.00MHz and 4.43MHz?

[Slothie]

Well I'm in a position to try this out on my MK14 which is 4.433619MHz, I've got mine wired up with an inverter from a 74HCT02 and a 10k trimmer & 47pf cap. I will change the cap to 18pF like Marks and see if I can get it to work. I will probably change mine to use the other half of the 74ls74 as an inverter like Mark because its one less chip and probably what I will want to end up with in the end. I can then thrash the card and make sure that memory is reasonably stable in various configurations.

[Mark1960]

My sketch schematic has the wrong values, I used 470pf and a 10k multiturn preset.

Minimum resistor that seemed to fix the corruption was 180ohm and didn’t seem to have an upper limit, maybe 220 would be a good choice. It did seem to drift slightly after running for a while and needed a slight adjustment.

47pF might work with preset adjusted to 1.8k.

I was using 4MHz crystal on the MK14 but can easily swap to 4.43316 to see if that affects the delay required.

Second half of the 74hct74 was just to buffer the RC delay instead of adding an extra chip.

Maybe let me experiment with the white band before you release a new layout. I’m wondering if a 74hct74 clocked by the serial clock of the PIC would work. Then one 74hct74 chip could fix two issues if the spare 74hct02 gate were used to buffer the RC delay.

[Slothie]

I'm not going to rush out a new PCB for a little while

I haven't got the change to work for me yet, but I haven't got the right values of capacitor or played with it for long enough. I will probably re-wire my setup to match your since you are having better fortune. I'm a bit sceptical about how accurate the values on my cheapo ceramic capacitors are, so I might get some from a more reputable source than ebay! Either that or cobble together some kind of capacitance meter.

I don't think the buffers are adding value, so unless things change they'll be plenty of room on the PCB for other bits and peices!

[SiriusHardware]

Finally managed to find a sole 74HCT74 so I'll set about building the mod tomorrow. I'll start with 470pf / 220R since these are values which work for Mark, allowing a slightly higher resistance than the apparent 'threshold' value of 180R.

[Mark1960]

It looks like the mod works at 4MHz but not at 4.43316MHz.

More plots attached. NWDS in yellow, Xout in purple. Using persistence to show multiple traces of NWDS.

1. 70ns delay at 4MHz. You can see the occasional late rise of NWDS floating high instead of pulling high on the rightmost trace.

2. 74ns delay at 4MHz. NWDS is always pulling high.

3. 74ns delay at 4.43316MHz. NWDS always floats high at the right trace.

4. 88ns delay at 4.43316MHz

5. 100ns delay at 4.43316MHz

[Mark1960]

I should really take some plots of NWDS and A10 instead of xout, maybe tomorrow, just wanted to give Slothie a heads up that he might be wasting his time with the mod at 4.43316MHz.

[Mark1960]

I’ll check if I have any crystals somewhere between 4.0 and 4.43316, I might have a 4.192 somewhere, if not then I might try 3.5768.

If anyone has any ideas why it won’t work at 4.43316, but works at 4.0, then maybe we can design an experiment to investigate the possible causes.

Also still not sure why a 290ns delay from rising edge of xout is still working but 40ns is a problem. Any ideas?

[SiriusHardware]

Because once a NENIN-out from the OrVw is in progress, SC/MP activity is suspended? So as long as you delay the initial rising edge of NENIN input to the MK14 past any NWDS pulses which may still be in progress, how much you delay it beyond that initial critical time period does not matter so much?

[Slothie]

I've spent all day fighting with my Bitscope BS05U trying to get some readings when I realised that the bandwidth is 5MHz and it seems incapable of sampling at the advertised 20Ms/s so taking meaningful measurements with it are pretty futile. My cheapo logic analyser does a better job at showing timings, but I know its idea of logic levels isn't quite what other devices on the board are so precise measurements with that are not possible. I really need a 20MHz scope or similar, which I have in storage so I'm not inclined to buy another even if I could afford it. The days of cheap £20 scopes on eBay seem to be in the past too!
Looks like I'm just going to have to put the thinking cap on instead, or hope someone else with suitable gear has an epiphany. I will be getting a 4MHz crystal at least, if the Ortonview can be stabilised at that frequency it will be good enough for me, and arguably would be more "authentic" to the MK14 VDU experience!

[Mark1960]

Originally Posted by SiriusHardware

Because once a NENIN-out from the OrVw is in progress, SC/MP activity is suspended? So as long as you delay the initial rising edge of NENIN input to the MK14 past any NWDS pulses which may still be in progress, how much you delay it beyond that initial critical time period does not matter so much?

Looking at the scope plots in #474.

There are two clock cycles during each NWDS cycle, but there are multiple images of NWDS relative to NENIN, each separated by the xout period of 250ns.

At 4MHz, the delayed rise of NWDS seems to be due to NENIN rising less than 80ns after the rising edge of the clock cycle that triggers the start of NWDS. This is possibly the hold time for NENIN to the input of the NWDS internal state machine of the 8060.

At 4.43316MHz, there is an extra NWDS cycle to the right, which always shows a slow rise time. This cycle starts one full cycle of xout later than NENIN, so this might be failing to meet the setup time for NENIN to the input of the NWDS internal state machine of the 8060.

I’ll try to verify these slow rising NWDS with the rise of A10, just to make sure I’m monitoring the right problem.

If 40ns delay after rising edge of clock is a problem, then a 290ns delay will have NENIN rising 40ns after the following clock edge. I still can’t think why this doesn’t cause the same problem. Just a wild guess but it might be that the timing of the next NENIN cycle by the PIC relative to the cycle time of the 8060 will prevent the NENIN arriving at a bad time for the 8060.

I wonder if this means there is a possible PIC firmware fix by shortening or lengthening the time that NENIN is active by one or two cycles. I think shortening NENIN by 250ns might be similar to the clock delay.

Is the length of NENIN a multiple of 1us, the same as the 8060 microcycle?

I should also add a warning not to delay NENIN too far, as this does not disable the 8060 before the PIC starts driving the address bus. I have crashed the MK14 a couple of time, luckily without any permanent damage so far.

[Mark1960]

Originally Posted by Slothie

I've spent all day fighting with my Bitscope BS05U trying to get some readings when I realised that the bandwidth is 5MHz and it seems incapable of sampling at the advertised 20Ms/s so taking meaningful measurements with it are pretty futile.

It might be possible to get 20Ms/s only in single channel, 10Ms/s in dual channel, 5Ms/s in four channels. I think I’ve seen this in the small print for a few of the cheap scopes.