UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   Ortonview PCB (https://www.vintage-radio.net/forum/showthread.php?t=181460)

SiriusHardware 20th Aug 2021 7:42 am

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.

SiriusHardware 20th Aug 2021 4:04 pm

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.

SiriusHardware 20th Aug 2021 4:09 pm

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.

SiriusHardware 20th Aug 2021 4:36 pm

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.

Slothie 20th Aug 2021 6:55 pm

Re: Ortonview PCB
 
Are you using a 4Mhz or the faster crystal?

SiriusHardware 20th Aug 2021 8:58 pm

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.

Timbucus 20th Aug 2021 9:19 pm

Re: Ortonview PCB
 
Happy to try one of your sub standard RAM's in my machine.

Mark1960 20th Aug 2021 11:45 pm

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.

SiriusHardware 21st Aug 2021 7:57 am

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.

SiriusHardware 21st Aug 2021 2:49 pm

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.

Timbucus 21st Aug 2021 4:23 pm

Re: Ortonview PCB
 
1 Attachment(s)
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.

Mark1960 21st Aug 2021 5:21 pm

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.

SiriusHardware 21st Aug 2021 6:55 pm

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.

Timbucus 21st Aug 2021 7:34 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1400174)
(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.

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

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

Slothie 21st Aug 2021 7:55 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Timbucus (Post 1400188)
Quote:

Originally Posted by SiriusHardware (Post 1400174)
(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.

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

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

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

Timbucus 21st Aug 2021 8:00 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1400195)
Quote:

Originally Posted by Timbucus (Post 1400188)
Quote:

Originally Posted by SiriusHardware (Post 1400174)
(1) Fit a series diode - Schottky, I assume, Tim?

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

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

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

Mark1960 21st Aug 2021 10:31 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1400174)
(2) Try placing a bigger decoupling capacitor, up to 47uF, across the existing PIC decoupling capacitor.

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.

Timbucus 22nd Aug 2021 12:27 am

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...

Slothie 22nd Aug 2021 7:51 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Timbucus (Post 1400261)
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...

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!

SiriusHardware 22nd Aug 2021 8:49 am

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.


All times are GMT. The time now is 3:04 pm.

Powered by vBulletin®
Copyright ©2000 - 2022, vBulletin Solutions, Inc.
Copyright ©2002 - 2021, Paul Stenning.