Re: Ortonview PCB
 

Well the Ortonview shouldn't be driving the NWDS signal at all, so how it can be affecting NWDS I can't see. So the only way that the PIC can be creating invalid writes is to intefere with the address bus while the SC/MP is using the bus or by rogue NWDS pulses coming from the SC/MP while the Ortonview is reading. Very rarely I observed a 1 sample (250nS) pulse when sampling at 4MHz that happens when the NENIN pin is low but has no preceding NADS pulse - I was under the impression that there was always a NADS at the beginning of a memory cycle, although its possible there is not in a r-w operation such as ILD or DLD. I tried sampling faster but didn't manage to capture one of these pulses. I can't remember, however, if this sample was from when running the code in Fxx (probably is, because of all the reads from Fxx) so I need to try to repeat this with the code running in the RAM/IO and see if I can observe these "rogue" pulses.

I really need to make an organised set of observations.

The one thing really puzzling me is that I dont seem to be able to trigger on write pulses to the Fxx area when it is getting corrupted there. Maybe I need to probe the enables on the RAM chips on the MK14 in case there is some interaction between the timings of the decode logic on the Ortonview and the MK14. I need to think how I can do that.

Re: Ortonview PCB
 

I'm assuming (as suggested above) that at the moment Slothie intentionally does not have capacitors on A8-A11 anyway, so any effect due to a capacitor on NWDS would be due to that alone.

Re: Ortonview PCB
 

b****r, why do I keep forgetting that?

Tim is the one with the really fast scope, his is a much higher speed version of mine. Maybe we can drag him in on this.

Re: Ortonview PCB
 

Maybe knock up a little pulse stretcher with a 7412x monotstable, such that a narrow logic-zero pulse on the monostable input makes the monostable generate a longer logic-0 pulse, long enough for the analyser trigger to fire on?

Re: Ortonview PCB
 

Boards arrived late yesterday, almost completed assembly, just a few more parts needed.

I don’t seem to have any 2k7 resistors left, but I can fit 1k2 + 1k5.

I’ll need to substitute BC107 for the transistor in the output, but should be ok for black/white only.

No 220pF caps, just realised the ones marked 220 are only 22pF, but I can try 100pF.

I’m hoping I can find time to finish the assembly today, checking basic functions will probably need to wait until tomorrow.

Re: Ortonview PCB
 

Glad they got there at last. I don't see why BC107 would not work (that takes me back though - projects in Everyday Electronics, etc!). BC182 - BC184 (not 'L', unless you untangle the pinout) would probably work as well. Don't forget that the orientation outline shown on the PCB is incorrect for BC547, probably for other T092 devices as well. if you are using a transistor with the pins lined up e-b-c, 'e' needs to go to the video connector signal pin.

My original build uses 2 x 100pF (in parallel) on each of A8-A11. SMD parts, stacked, as it happens, because we don't have many capacitors in the pF range at work.

Tim gets away with 47pFs in that position so 100pFs may very well work for you. The minimum value which works reliably for me on my original build is 147pF (100 + 47, obviously).

If you don't fit them straight away, you'll be able to see the problems we are trying to find the cause of, but perhaps you'd prefer to have the reassurance of seeing it work properly first.

Re: Ortonview PCB
 

I was planning to start with #352, then move to #692 to show the memory corruption. I’ll try 100pf to see if that improves any, but more interested in experimenting with other possible fixes by synchronizing NENIN to mk14 XOUT.

With the legs on a bc107 in a triangle it should be easy to fit to a bce footprint.

The phono sockets I have fit nicely, I don’t even need to straighten the legs.

I started playing with electronics back in the seventies, mostly practical electronics and practical wireless, I think it was before everyday electronics came out. Used to be able to get bc107/8/9s, resistors, capacitors etc from a couple of audio shops in Darlington. This was a few years before Tandy’s opened. No online shopping and placing mail orders by post was a real pain.

Re: Ortonview PCB
 

Happy to try a scope on something, - that is really the only way but, as it does not have an external trigger trying to capture an event could be tricky. I have used other chips as you know to create a second channel trigger event but, it was pointed out to me that this does not help in the case of runts and out of spec spikes/pulses as they may or may not trigger.

I can also put the HP on the problem to get more accurate diagnosis but, again that may not spot a transient problem caused by signals on the bus fading etc which people seem to be homing in on.

I assume if I desolder my Caps (and patch out the buffers) that it will start to fail - can you confirm Sirius that with the caps yours is stable? I think I have lost the plot about which configuration has the issue :)

Re: Ortonview PCB
 

I can probably try and capture scope plots on NWDS tomorrow if you don’t want to hack your board. I’ll use socket strip for the bus capacitors.

My scope has external trigger, I just need to find my spare probes. Not sure how much the extra trigger will help as we really need to know if we are triggering on runt or normal NWDS. Maybe trigger on NENIN and monitor NWDS and high address line, and repeat until it captures something of interest.

Re: Ortonview PCB
 

Only with two specific 6116 ICs, one being the only one of five otherwise identical RAM ICs which completely works. The other, luckily, is the M5M5117P you loaned me so using one of those would be a good starting point. I have 4 x 220pF in my case but then I always did need a higher minimum capacitance than you.

Just been reading back through the original thread, though, and it seems you had to raise one of the caps to 100pF in order to get yours completely corruption free. The minimum I found I could use was 156pF, not 147pF as I thought.

I've just had another thought about a possible cause for the wide variation in my build's tolerance for different RAM ICs - the linear regulated supply I run my setup on is 7.5V, fixed, regulated. I chose that low voltage to keep the volts drop across the regulator (therefore the watts dissipated in the regulator) at the lowest possible value. I'm wondering now if some of the RAMs draw more current than others, and if they do, whether that is enough to make the 7.5V input supply dip just enough to stop the MK14 regulator from regulating properly.

I'll try a slightly higher input voltage to see if that allows the other RAMs to work: Back shortly.

Re: Ortonview PCB
 

...Nope. That wasn't it.

The same RAMs do and don't work to the same degree when there is plenty of headroom on the input voltage to the regulator.

Re: Ortonview PCB
 

If you have a diode in the supply to the ram you could try linking it out. It might also be worth putting a decoupling cap directly across the ram pins 24 and 12, the traces from the decoupling cap to the ram look a bit long and thin.

Re: Ortonview PCB
 

I believe I mentioned earlier that I don't have a diode in the supply to the RAM, it is fed directly from +5V. Interestingly though, Tim does (or did) have a diode in his +5V supply to the RAM and it seems that on his first attempt his board was working really well in vanilla mode - no buffers, and even with the buffers (with the delay enable mod in place) as long as he still had the caps on A8-A11.

Ref: Supply traces, this was another line of attack I was considering, thickening the supply traces and running them more directly from point to point, but even that would involve cutting the original supply traces to avoid any potential problems caused by the currents going via two paths, one long and one short.

I agree a cap directly on the RAM supply pins would be simpler and faster to try first. I have already populated all of the positions for supply decoupling caps but as you say, none of them are particularly 'close' to the RAM in the electrical sense. The fact that fitting an electrolytic to the rails brought one borderline RAM into the 'fully working' zone does suggest that maybe more can be done in this area.

Re: Ortonview PCB
 

I run mine on a 9V so you could be on to something. ****** didn't refresh the screen so posted without seeing the posts after the pub - ignore me.

Re: Ortonview PCB
 

I don’t think you need to cut traces, multiple paths for supply and ground shouldn’t make any big difference.

Re: Ortonview PCB
 

One other thing I've just noticed about my original build is that I have a 0.1uF across the +5V supply very close to the video output transistor. The video input of my Philips monitor has a (measurable) 75R termination resistor from input to GND so the video transistor will be supplying significant current from 5V.

I may try a close mounted decoupling cap on the video output stage supply on the PCB version as well.

Re: Ortonview PCB
 

I must confess decoupling was a bit of a last-minute affair so I might have missed something. A cap near the output transistor makes sense.

Re: Ortonview PCB
 

I appear to have zero 0.1uF disc ceramics here - typical - but I know I have a component drawer full at work so I'll take the PCB in tomorrow and fit decoupling capacitors directly on the pins of the RAM and the video output stage supply rails.

I might also route the latter more directly back to the +5V / 0V connections at the edge connector so that the fast switching currents for the video output stage aren't travelling out and back down the same tracks as the supply to the ICs.

I don't think the decoupling caps for the PIC and the 74HC02 could be placed any better than they already are, both are sited very close to their respective ICs with short track runs to the supply pins.

Re: Ortonview PCB
 

I tried one last thing - with the monitor connected the output load being driven by the video output stage is 75R (=the resistance of the video input of the monitor) and the 1K emitter resistor in parallel.

If the theory is that the switching currents being drawn by the video output stage are the cause of the problem, then I could have a go to prove this by unplugging the monitor and putting one of the 'bad' RAM ICs in - I don't need to see what's on the output of the VDU to know whether the machine is working, because the MK14 display goes haywire if it is not.

So I tried that, fitted one of the less stable RAMs and unplugged the video output cable so that the load being driven by the video output transistor was a respectable 1K instead of something less than 75R.

Unfortunately, no difference. System is haywire with and without the 75R load of the monitor input connected. I think I'll call it a night and have another go tomorrow with the extra decoupling caps fitted.

Re: Ortonview PCB
 

I now have an ortonview running with firmware #352, random characters on the tv and the mk14 display is not correct due to the longer delays in #352. All as expected on reading the original mk14 vdu thread. I get a white bar about half character wide down the left edge of the tv, probably picture adjustment but I’m going to ignore that for now and switch to firmware #692.

I didn’t fit the extra extra ram yet, so I may add the 8154 and try Slothie’s ram test from there.

Re: Ortonview PCB
 

We didn't persevere for long with #352 because of the really heavy system slowdown it caused - going back though the old thread it held NENIN high for a very high percentage of the time, even more so than the SOC VDU.

Fortunately, Karen to the rescue, she found a way to keep NENIN active for a far smaller percentage of the time, hence the 'fast' versions we have now, culminating in #692.

The white bar, LHS, is a by product of the UART being used to generate the video bit stream - when first enabled at the beginning of each line it unavoidably generates a 'bit of white' until such time as the output can be turned black again under software control.

At the moment I just adjust the width / height and horizontal position of the image on my CRT video monitor so the bright line is just off the LH edge of the screen. If you were using a typically auto-adjusting flatscreen TV, that would probably insist on including the bright line onscreen since it is part of the video image.

While I would eventually like to see the bright line suppressed, we have more fundamental problems to solve first.

Re: Ortonview PCB
 

As Sirius pointed out. Black Electrical Tape will cure the white bar for now :)

I've been distracted for the last couple of days by the arrival of a 3D printer.... Normal service will be resumed when I run out of filament, which will not be long.

I think that my next step might mean I'm going to hook up my logic analyser to the chip enables of the Fxx RAMs to see if the problem is there and what difference the running of the Ortonview makes to it. At the moment what I am seeing with my admittedly primative equipment does not make sense, and that's not good for reaching a diagnosis.

I'll try to document my experiments so that (a) I can remember exactly what I did and (b) I can share my ruminations with the rest of you.

Re: Ortonview PCB
 

Switched to #692, I think, using the hex file from Slothie’s dropbox to save time installing mplab and compiling.

I still see F09 and F11 rotating as expected with the mk14 monitor running, but for a minute or two after power on and reset The content of B20-B3F, B60-B7F, BA0-BBF and BE0-BFF are going wild. This then stops for a while and then returns again after another 5 minutes.

I just went back and tried again with reset pressed, now I only see the changes in Bxx when reset is pressed, and only in the last 4 characters of each range, so for some reason its no longer as bad as it was 30 minutes ago when its been powered off.

Tried triggering off NWDS with reset pressed, at 500MSa I see a few ripples but nothing less than 4v.

I think this is similar to what Sirius saw with extra extra ram.

I’ll take another look later, I need to work for a while.

Re: Ortonview PCB
 

When you come back could you just state whether you are running in 'vanilla' (original Ortonview circuit mode minus buffers) or buffered mode (buffers fitted).

If you have the buffers fitted do you also have your / Slothie's buffer enable RC delay fitted?

If you don't have the buffers fitted and you instead have them bypassed, do you have the 4x capacitors on A8-A11 to 0V?

Re: Ortonview PCB
 

Original ortonview mode, no buffers, and no capacitors yet, but the parts of Bxx changing do not correlate with writes to Fxx, so not just A8-A11 involved.

I need to make sure Bxx is being written with bad data and not just being read incorrectly by the pic.

Re: Ortonview PCB
 

Typical, I just tried again and now the display of Bxx is not changing anymore.

I took a look at NENIN and A11 or NWDS. I really need to find a third probe for trigger as I can’t tell if A11 is during read or write. What I can see is a wide variation between rise of NENIN and rise of A11 or NWDS, anything between about 150ns and 400ns, so suspect the effect of NENIN on A11 or NWDS is synchronous to the 8060 clock. They also seem to have a faster rise time if they rise earlier after NENIN rises, as if being driven high, compared to looking like they only float high if they rise later.

Re: Ortonview PCB
 

Adding a couple of scope plots.

Yellow is NENIN on both.

Purple is A11 on the first and NWDS on the second.

Using persistence to show a range of response with different timing.

Re: Ortonview PCB
 

A bit late to the party tonight so I didn't get as much time to experiment as I would have liked. I dropped a 4mm long black M2 screw on the carpet here and it took me most of the night to find it. But find it I did.

So: Today, I fitted 0.1uF caps across the supply to the video output stage and the 6116 RAM socket. My 'good' EL6116LP-10 still works solidly, no surprise, but now the other four EL6116LP-10s appear to work solidly as well - I can leave the machine running with OrVw displaying 0200-03FF with any of those ICs in and I don't seem to be seeing any pixels changing by themselves, which was the case before with four out of five of those ICs.

Against this, there is the fact that my two Hitachi HM6116LP-3s still cause heavy disturbance to the system but the disturbance, while it still makes the system go nuts, seems less aggressive.

So now I'll take it back to work again tomorrow and this time I will fit 0.47uFs or 1uFs in those positions. In fact I may populate all of the positions provided with 0.47s, if I can find any, rather than the 0.1uFs currently fitted.

Following this observation I would suggest that everyone else beefs up the decoupling for the 6116 and the video output circuit as well. If taking mine up to higher values still doesn't fix it for the worst case RAMs I am going to start thickening and rerouting the 5V and 0V rails.

Re: Ortonview PCB
 

I wonder if the reason Tim didn’t have a problem with the extra extra ram was because he did have the diode fitted in the supply and the combination of the diode and the decoupling cap gives a better supply to the ram.

Maybe this is linked to the problem I had with the display of Bxx.

Re: Ortonview PCB
 

Yes, I visualised it as the 'one way valve' action of Tim's diode helping to maintain a 'reservoir' of power to the RAM in the RAM's decoupling capacitor.

Re: Ortonview PCB
 

1.0 uF capacitors now fitted in all pre-existing decoupling capacitor positions, and also on the video-out supply rail and the 6116 supply pins. I'll try to give it a quick test drive with some 'bad' RAMs this evening.

Re: Ortonview PCB
 

Progress, but only in painfully small baby steps.

With the modification above (all decoupling capacitors including the additional ones on the video output stage and 6116 pins increased to 1.0 uF),

-All of the originally better behaved RAMS (EL6116LP-10) work as before and as expected.

-With the HM6116LP-3s fitted, the VDU still does not render correctly from that memory but the operation of the MK14 display / OS is now NORMAL with those Hitachi memories fitted. The only difference is the 10 x larger value of the decoupling caps, that is what is allowing the system to now run normally with one of these memories fitted.

I'm away for the weekend as usual but when I get back I will try editing and inspecting the screen RAM using the monitor, to see whether it is now only rendition of the memory content of that area from the Hitachi devices which is still faulty.

I suppose I could just keep going upwards on the decoupling cap values - go old-school with 10uF Tants, perhaps, to see what happens.

Re: Ortonview PCB
 

Maybe I should finally get scientific as well - have a look with a scope to see what problem it is on the supply rails that these decoupling capacitors are trying to fix.

Re: Ortonview PCB
 

I just gave it a quick try before putting everything away for now - I can't view / edit the content of 0200-03FF when there is a Hitachi device fitted. Nor can I view / edit any of the contents of the normal memory, although I can enter addresses and step through them - but I can't edit them, and what I'm seeing in them is not necessarily what is really there - so not as much improvement as I had initially thought.

Re: Ortonview PCB
 

Are you using a 4Mhz or the faster crystal?

Re: Ortonview PCB
 

4.00Mhz.

I must stress that with the additional decoupling my PCB build of OrtonView now works with more RAMs than it ever did before. What I'm really aiming for is a 'works with any 6116, any brand, that is sufficiently fast' solution.

As a cross check I could send you or Tim one of the misbehaving (but working, according to my device tester) Hitachi RAMs to see if they are equally badly behaved in yours.

I could also - although I would be reluctant to do it - chop off the EL6116LP-10 which has worked perfectly from the get-go on my original bridge board and fit a socket so that I can try different RAMs in the bridge board. Or a variation on that, I could tie CE of the soldered RAM high and tack solder a conventional socket to the shoulders of its pins, except CE, and take the output of the address decoder to CE of the socket.That would be less destructive and reversible but I then wouldn't know whether the parallel presence of the disabled IC was having an unknown beneficial or negative effect.

Re: Ortonview PCB
 

Happy to try one of your sub standard RAM's in my machine.

Re: Ortonview PCB
 

I have noticed a ringing on the 5v which also shows on NENIN. This can be up to +/- 0.5v which could be a problem. It shows as a pair, -0.5v followed by +0.5v, and then repeated at a slightly lower level about 250ns later.

It seems to be related to the pic switching the address lines to output, followed by setting the value of the address lines. I haven’t studied the code but would have thought it might be better to set the value before setting to output.

I tried adding 1uF across pin 11 and 12 of the pic, then also added 10nF in case the larger cap was too slow, but didn’t seem to make much difference.

I had 100pF on A8-11 which seems to make the problem worse, removing the caps doesn’t stop the ringing, but does reduce the amplitude.

So I was wondering if the 220pF used by Sirius is contributing to his memory problems. Maybe without the 220 pF there will be corrupting writes to Fxx that match intended writes to Bxx, but this might also prevent the issues seen with extra extra ram.

If I get some time over the weekend I might try fitting extra extra ram to see if I have similar problems.

Re: Ortonview PCB
 

I also would have expected that the output latches would be preset to the desired values before changing the port direction and I have not looked at the code to see whether that is or is not the case. As I've said before, Karen was the High Priestess of PIC, and usually had some reason for doing things the way she did.

To rewind a bit to when Tim and I both had working lash-ups on stripboard, the A8-A11 capacitors proved to be the final tweak which stopped the occasional problem where writes to an address in one memory page were causing writes to the same address in another memory oage.

The mystery is why what worked on stripboard for me and Tim, and also appears to work quite well for him on PCB, does not work well on PCB for you or me. Putting on my Sherlock Holmes hat, I'm going to have to say that this must be accounted for by whatever differences there are between our systems - we are all using the same PCB as the starting point, so what is it that we are doing which is different?

Tim's diode in Vcc to the 6116 is one obvious difference so I will try that, but like the caps on A8-A11, it is a slightly unconventional mod which is hiding the real reason for the problem.

I'll try disabling the PIC with VDU-off or just take the PIC out altogether to see if the board then works as a 1.5K 'RAM pack' with any sufficiently fast 6116 in it, including the Hitachis which are so troublesome for me. That will have to wait until I'm back at base unfortunately.

Tim, I have to send your RAMs back to you anyway so I will include one of my HM6116LP-3s for you to try.

Re: Ortonview PCB
 

I think part of the problem is that we are also looking at different things as well.

Tim doesn't really have a mission at the moment as his works quite well.

Mark is pursuing the original memory corruption problem which was 'fixable' by the addition of capacitors to A8-A11 and at the moment is not even trying to get any version of 6116 to work as extra-extra RAM.

My aim at the moment is to get to the point where the combination of the MK14, OrtonView, and any 6116 as extra-extra RAM all work together.

Right now, a working combo for me is:

4.00MHz clock.

OrtonView powered from MK14 +5V (no regulator).

Buffers not fitted (linked out).

100uF fitted in C8 position and 1.0uF fitted in all other provided decoupling capacitor positions, plus two more 1uFs, one close across the video output stage supply and one directly across the supply pins of the 6116.

200pF capacitors fitted between A8-A11 and 0V.

No diode fitted in the supply to the 6116.

The above configuration definitely works now with any of my EL6116LP-10 RAMS, and also with the M5M5117P loaned from Tim. Before I raised the decoupling capacitors from 0.1uF to 1.0uF, only one EL6116LP-10 worked reliably, along with the M5M5117P from Tim.

It does not currently work with my ST MK6116Ns or my Hitachi HM6116LP-3s or Tim's Hitachi HM6116P-4.

When I get back to base I will see if the non-working RAMs work fully normally when OrtonView is disabled.

Re: Ortonview PCB
 

Maybe we are missing something else very subtle in the build as that HM6116P-4 I sent you was the one I had in my board and it worked and is the same as the one I used in my Bridge board. Maybe I have made a mistake or difference in my build that somehow by accident allows it to work.

I will attach a zip with some photos to this but, I also have a 4.00MHz clock, 100uF in C8 and all decouplers fitted (104) the ones on A8-11 are (221K)

Or is it possible there is something different in the Issue VI build we each have a subtle component difference e.g. a one or the other not having what is actually marked on the TTL chip - I have certainly been sent some chips marked as LS that test as HC - luckily my tester can tell the difference but, something else may have slipped through.

Re: Ortonview PCB
 

Link to microchip design guide. This recommends a 4.7uF to 47uF supply decoupling if the power supply traces are more than six inches. Maybe C8 is a bit too far from the PIC. I haven’t fitted C8 yet as I wanted to avoid using an old tantalum cap across the power supply in case I leave it powered up while unattended. I’ve seen a few of those type go up in flames. I tried 1uF and 10nF across pin 11 and 12 but thats probably not enough.

https://www.microchipdeveloper.com/8bit:guide

I haven’t tried charset yet, so I don’t really know if I have the same problem of corruption in Fxx due to interrupted writes to Bxx. I don’t have an easy way to load code yet so its been putting me off. I got distracted by the noise on NENIN from the supply.

Another thought on the two pulses of noise separated by 250ns. The address output from the PIC is going to be two eight bit writes, so it probably is set to the correct address before enabling outputs, but there are two sets of outputs to enable.

I think Sirius 220pF caps on the address lines might make the PIC pull more current when the address lines are switched. Also the diode in the ram supply might be helping to protect it from a noisy supply on Tim’s.

Re: Ortonview PCB
 

OK, so when I'm back in front of the machine I will look at these avenues:-

(1) Fit a series diode - Schottky, I assume, Tim? in the supply to the 6116 just to see what effect, if any, that has on my problem with the system as configured above and with every type of RAM I have available.

(2) Try placing a bigger decoupling capacitor, up to 47uF, across the existing PIC decoupling capacitor.

(3) Disable or remove the VDU components so that the board is just a 1.5K 'RAM pack' and use Slothie's test program or some other means to verify the operation of all of the 6116 RAM ICs. When I first tested the board in RAM-only mode I happened to be using what turned out to be one of the 'best' RAM ICs. I'll try it again with the ones which are known to give trouble when the VDU is running, but this time without the VDU running.

(4) Remove the extra-extra RAM components, set the VDU to display 0fxx / 0bxx, remove the A8-A11 capacitors to see if that reproduces the original page to page corruption issue on this PCB and then refit A8-A11 capacitors, a low value initially, and raise them to the lowest value which fixes the problem.

I will also send Tim one of my HM6116LP-3s to see if that breaks the operation of his otherwise working Slothie-OrtonView.

Re: Ortonview PCB
 

Yes I used a BAT43 as it was what I had to hand. I now have loads of 1N5711 due to a supply messup... not tried one instead.

Great - lets hope it does break mine

Re: Ortonview PCB
 

I used BAT43 as well, since the current is low enough.

Re: Ortonview PCB
 

You thought about it - I just tried it, as an established student of the "Poke and Hope" electronics design school.

Re: Ortonview PCB
 

I fitted two off 10uF, smd 1206 capacitors directly on each pair of power pins on the PIC. This virtually kills the spikes seen on vcc and gnd at each pair of power pins. I still see the ringing on NENIN when the address lines are driven. First is when the A8-A11 are driven, second is when A0-A7 are driven. A8-A11 causes a bigger spike than A0-A7 when the capacitors on the bus are fitted.

I’m not sure we need to worry about this ringing on NENIN provided the power supply is clean. I don’t think there is much we could do about it, though we could put 75-100 ohm series resistors in place of the buffers. This would reduce the drive current from the PIC outputs, should make them more in line with LS ttl drive current and transition times. I’ve used similar to reduce ringing on clock lines driven by 74ACT.

Re: Ortonview PCB
 

As an aside to the issues part of the Slothie PCB included a hardware Random number generator which we have not tried yet. It may interest you to know there is canon for that (with code snippets) for the MK14 in November 1981 Computing Today Microlink... Pg. 25...

http://www.flaxcottage.com/ComputingToday/8111.pdf

I did try to add just the two pages of the article as PDF but, it was too big...

Re: Ortonview PCB
 

Thanks for that link. Looks like I'm going to have a load more magazines to read :) I still haven't found where I got the circuit for the RNG on my board from, I think it was Elektor, but I was browsing magazines on my phone while in hospital at the time so only saved an image of the circuit because my phone was full! Since then I've not found the article again.

The page of magazine covers brought back a memory rush! I bought Computing Today regularly from its beginning in ETI until about 1981 when I went off to Uni and my magazine money started being used for beer and pasties!

Re: Ortonview PCB
 

On systems with a Realtime clock or a counter-timer which can be set to free-run I usually just harvest some values from that and apply some kind of formula to get a pseudo random offset value into the ROM to pluck a value from there - the problem is that micro code is far from random so in SC/MP code you have a rather high incidence of values like 0xC4, for example.

On the MK14 I don't know if there is the possibility of using one of those those two locations which the OS constantly changes - I've never looked (on the VDU) to see what happens in those locations when you enter an execution address and press 'Go', whether they always end up holding the same values or not. But in any case, you'd only get that random seed when you first run the program, once the system is under the control of your own code the system no longer changes those locations.

The MK14 manual game 'Reaction Timer' obviously does derive a random delay time somehow.