Re: Ortonview PCB
 

I spent a bit more time thinking about this, its likely not going to be a complete fix even if it does give an improvement, as the first NENIN of each frame is still going to arrive at a random point in the xout cycle.

If we try it then I think the length of NENIN and spaces between NENIN should be a multiple of 500ns, as we only want to avoid the one out of four clock cycles that cause the issue.

Another thought is if we can find some way to delay NENIN by one clock cycle, but only if NENIN is raised during the clock cycle that causes the problem. Maybe that could also work with 4.43316MHz.

Re: Ortonview PCB
 

I've been thinking about this, and it occurs to me that at 4.433619MHz the SC/MP is being effectively "overclocked", and maybe the timing of the bus arbitration logic just doesn't work much above the "official" max speed on 4MHz. This wouldn't have been noticed by or bothered SoC when originally designing the MK14 because NENIN wasn't used, and when developing the VDU they dropped the frequency to 4MHz anyway to simplify the timing for the video generation so attempting to get it to work above 4MHz might be a bit of a waste of time, or at very least require more complicated logic to compensate for shortcomings in the SC/MPs internal logic. It's possible the timing of switching off the address buffers and the other signals and the is controlled by "propagation delay" that runs out of room at higher frequencies. The data sheet gives a fairly narrow range of acceptable clock frequencies (2-4 Mhz) so maybe the internal logic isn't entirely synchronous as it tends to be in more modern CPUs.

Re: Ortonview PCB
 

At 4 MHz there is a single point in the write cycle where raising NENIN will result in the NWDS floating high slowly while A10 rises earlier. This is around the rising edge of xout just prior to NWDS driving low. If we detect RFLG during at rising edge of NADS we might use this to block NENIN for one cycle of xout. The challenge would be to do this with a single chip, possibly a dual JK or JnotK could do this and would not need an RC delay.

At 4.433619MHz there are two points that are a problem, rising edge of xout just prior to NADS rising and also rising edge of xout just prior to NWDS driving low. Again this might be possible with a dual JK or JnotK.

Having two problem points is probably why the 80 ns delay is not working at 4.433619 MHz as it just shifts NENIN from one first problem point to the second.

Both of the above were seen using 40ns delay from rising edge of xout to rising edge of NENIN.

This would be a different method than that used by SoC, but might then support both 4.0 and 4.433619 MHz crystals.

I’ll post some scope plots later when I have time to get the laptop online as I don’t know how to get plots from the usb stick with the ipad.

Re: Ortonview PCB
 

This is the plots showing the two sets of timing at 4.433 MHz for NENIN that causes NWDS to rise slowly and A10 changes while NWDS is low.

NWDS is yellow, A10 is purple, blue arrow shows NENIN rising edge trigger.

Also included with NWDS yellow and NADS purple for reference to these two timing positions.

Re: Ortonview PCB
 

At 4.0 MHz there is only one timing that causes A10 to rise before NWDS.

Re: Ortonview PCB
 

I'm wondering if we should do more testing to see if the original A8-A11 capacitors work equally well when 4.00MHz / 4.43MHZ clocks are in use in the MK14. I'm not sure but I think Slothie has been using a 4.43MHz clock from the beginning.

If they do work equally well with either clock frequency then we may have to reluctantly accept that the capacitor fix is the more broadly effective and pragmatic one, no matter how technically offensive we may find it.

Re: Ortonview PCB
 

The only problem I have with the capacitor idea is the thought that it might load the bus with too much capacitance, the data sheet specifies a maximum of 75pF for outputs other than XOUT. Not sure if too much capacitance would harm the 8060 or if is a signal integrity issue.

Re: Ortonview PCB
 

Attached might work to synch NENIN to XOUT and also block NENIN at the end of NADS and beginning of NWDS.

It shouldn't matter that this also blocks NENIN during a read cycle at the same two points.

Re: Ortonview PCB
 

I got round to testing the circuit in #488 and with the simple loop using ILD at B10 there is no sign of corruption at F10. This was at both 4MHz and 4.433619MHz.

Though this seems to work at both frequencies it does need NADS from the MK14 and I think Sirius or Slothie mentioned this might not be available on the earlier MK14 revisions.

The earlier circuit with an RC delay only works at 4MHz, but it does seem to work in a similar way as the original mk14 vdu with its RC delay in the NENIN circuit.

Does anyone have a more comprehensive test routine that I could key in?

I’ll post some scope shots later.

Re: Ortonview PCB
 

My Issue II has a connection for NADS on the edge connector, but the documentation says it should not be available until Issue III.

https://www.vintage-radio.net/forum/...1&postcount=38

Re: Ortonview PCB
 

Given that issue II, III did not even have contact fingers on the underside of the rear edge connector to route the address, data and control signals to, I suppose the presence or absence of NADS on the top side of the edge connector is the least thing that the owner of any early issue MK14 has to worry about when trying to connect a VDU, whether original or OrtonView.

For any original machine which does have contact fingers on the PCB underside at the rear edge connector (Issue IV, V?) the need to add just one more wire link to one more contact finger will not be too upsetting.

Re: Ortonview PCB
 

Good work!

I'm thinking its not bad to have to use NADS, since none of the signals were available on the edge connector per se, so to have to wire one extra signal we are still in the spirit of the thng. If we were hoping to make it 100% functionally equivalent then we'd have to replicate the circuit in a CPLD or something.

This is the program I have been using - it is set here to reside in the ram/io and use variables in the ram/io but write to 0xB00-0xBff. by setting the Ortonview to display both pages you can see the obvious corruption in 0xF** which should not be written to at all. It should be simple to change to move or write to different locations:

Re: Ortonview PCB
 

Oh, the original files:

Re: Ortonview PCB
 

;D YAY

Well I wired up Marks circuit from #488 and have run the test under various scenarios and it all seems to be working fine, the code will now run in F20 with its variables, writing to B00-BFF with no visible corruption, and also the other way round, or from e80 etc.

I'm running firmware #692 at 4.433619MHz. Looks like I might not need those 4MHz crystals I bought after all...

Given the elegance of the design it seems that it will provide the necessary synchronisation. I suppose we need to test that things like running a DLY instruction won't break it due to the lack of NADS pulses. I must confess I haven't got my head round how the dual latch works, but it seems it does.

Its especially nice that its a one-chip solution to the problem, and a chip that is still readily available!

Re: Ortonview PCB
 

I'm away from Moon Base Alpha just now so I won't be able to throw Mark's patch together until next week, but it all sounds very hopeful.

Oh, but... were you both testing with no fudge capacitors on A8-A11? I know Mark won't have had capacitors fitted, but Slothie?

Re: Ortonview PCB
 

No capacitors! No buffers, I took your suggestion and made them "pluggable".

Re: Ortonview PCB
 

I don’t have capacitors fitted, but I did have a scope probe on A10. I’ll try again with the scope probes removed.

Also need to fit the 8154 and key in Slothie’s test code, and maybe also try with the extra extra 1.5k ram.

Operation of the circuit is as follows, hopefully this doesn’t cause more confusion.

NADS low presets the first flip flop, which holds clear low on the second flip flop, holding 8060 NENIN low.

NADS stays low until after the XOUT rising edge keeping the first flip flop set.

After NADS returns high, the first flip flop remains set, keeping clear low on the second flip flop and 8060 NENIN remains low.

On the next XOUT rising edge the first flip flop is cleared, this releases clear on the second flip flop, but too late for XOUT to clock in NENIN from the PIC, so again NENIN to the 8060 remains low.

Then on the next rising edge of XOUT, NENIN from the PIC can be clocked through to the 8060.

The extra connection from /Q of the second flip flop to clear of the first flip flop ensures that after NENIN to the 8060 has been raised, NADS can not set the first flip flop. This relies on the “feature” of the 74x74 where both clear and preset low will hold both the Q and /Q outputs high.

Re: Ortonview PCB
 

Adding scope plots for 4MHz

Blue arrow marks NENIN to 8060 rising edge on the trigger input.
Yellow is NWDS
Purple is A10

Re: Ortonview PCB
 

And the same at 4.433MHz

Re: Ortonview PCB
 

I will have to dig my items out on the weekend, desolder the caps and try the patch - well done Mark.