Re: Ortonview PCB
 

I connected a 74hct74 as in #446, so synch the rising edge of NENIN to rising edge of Xout, but with no improvement. If anything it is now more repeatable.

I think next attempt is to synch to the falling edge of clock.

Re: Ortonview PCB
 

Keep up the good work, Mark. This problem will fall eventually, as long as we keep hacking away at it.

Re: Ortonview PCB
 

I tried syncing to the rising edge as well, I even made a post about it with a video 2 days ago but I either stuffed up making the post or it got deleted. With the "testmem" program assembled to run at E80 and using variables in the I/O RAM and writing only to Bxx (i.e. no writes to Fxx) the memory in Fxx can clearly be seen to be being corrupted, except this time it seems more "regular" and evenly spread across the page, whereas before the corrupted locations seemed to bunch around F00 and F80 locations. It did seem to be happening more though.

https://youtu.be/Zwh369ewhzc

Re: Ortonview PCB
 

I notice you still have the buffers installed - my problems, although undoubtedly exaggerated by having no power supply to the 6116(!!) seemed a lot worse when the buffers were installed, I had rows of characters rolling at that point.

I would suggest simplifying it to the 'no buffer' arrangement while trying these other tweaks - I think that's probably how Mark has his configured at the moment anyway.

Re: Ortonview PCB
 

Thats a good point, it didn't occur to me. I'm also going to try putting in an inverter for the clock signal, got to get the glue gun warming up!

Re: Ortonview PCB
 

just tried taking out the buffers and installing the links and it doesn't make a difference. Sorting through my chips for something I can use as an inverter now!

Re: Ortonview PCB
 

Inverted XOUT with a 74HCT02 NOR gate and it doesn't appear to have made a difference.

Re: Ortonview PCB
 

I don’t have the buffers fitted and no capacitors on the address lines.

I was using a tight loop using ILD on B10, This gives unwanted writes to both F10 and also B30, and I can see the early rise of both A10 and A5 on the scope. Also I can see the NENIN is definitely rising on the rising edge of xout, so the synch to xout was working.

I was going to try the second half of the 74hct74 as an inverter, input to preset, output from Q and all other inputs grounded. As Slothie already tried an inverter without success I’ll skip that.

Next attempt is RC from Q output of 74hct74 to clock second half of 74hct74. D and preset held high and clear to PIC NENIN. I think a 100pF cap and a 5k preset should give me a 0 to 250ns range.

Re: Ortonview PCB
 

Hmm variable delay. Well that would certainly give the opportunity to see if it is the delay between XOUT and NENIN,

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.

Re: Ortonview PCB
 

Oh for the record, I am operating at 4.433619Mhz with no capacitors and no buffers. Firmware #692.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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!

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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?

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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!

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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?

Re: Ortonview PCB
 

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?

Re: Ortonview PCB
 

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!

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

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.