UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 22nd Jul 2021, 1:48 pm   #61
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

Good going. I don't know if you want to wait until you've been able to try one yourself, but if you could please let me know the outside dimensions of the largest of the two boards - presumably the Ortonview - I can start looking around for suitably sized padded bags.

The way I see it going, I send a suitably sized and stamped and addressed jiffy bag to Slothie inside a larger bag, Slothie uses the bag I've sent him to post some boards to me and then I send individual boards on to the interested parties, who as far as I know at the moment are Tim and Mark - I'm happy to bear the modest cost of all carriage, it can be my minor contribution to the project and it takes some of the leg work off Slothie.
SiriusHardware is offline   Reply With Quote
Old 22nd Jul 2021, 2:19 pm   #62
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Quote:
Originally Posted by SiriusHardware View Post
Good going. I don't know if you want to wait until you've been able to try one yourself, but if you could please let me know the outside dimensions of the largest of the two boards - presumably the Ortonview - I can start looking around for suitably sized padded bags.

The way I see it going, I send a suitably sized and stamped and addressed jiffy bag to Slothie inside a larger bag, Slothie uses the bag I've sent him to post some boards to me and then I send individual boards on to the interested parties, who as far as I know at the moment are Tim and Mark - I'm happy to bear the modest cost of all carriage, it can be my minor contribution to the project and it takes some of the leg work off Slothie.
The PCB is 100mm x 124mm so something like an Size 0 (CD sized) or larger padded bag would work for 3 Ortonviews and uploader boards. A 00 bag would fit a single pair of boards.
Slothie is offline   Reply With Quote
Old 22nd Jul 2021, 7:16 pm   #63
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

I've knocked up some notes on the Ortonview, Layout, Schematic and bill of materials.
Attached Files
File Type: pdf Ortonview_notes.pdf (304.6 KB, 23 views)
Slothie is offline   Reply With Quote
Old 22nd Jul 2021, 7:52 pm   #64
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

Nice manual!

I think that in the parts list the description labels for the 1N5711 and 1N4148 are swapped (5711 is Schottky, 4148 is small signal silicon).

It may be worth stating that it is necessary to use a 'plain' 877 and not an 877A, otherwise you get the 'double image' issue in graphics mode only. The reason for this was never resolved so the present solution is - don't use the 877A.

On the prototypes (Mine, Tim's) the capacitors from A0-A7 to 0V were never fitted and fitting them could have unintended consequences. The ones from A8-A11 to 0V were necessary - 180pf-200pf in my case, to resolve the problem where software attempting to write to a location in any given memory page would sometimes write to the same location in a different memory page as well.

The hope is that the buffers will remove the need for any capacitor bodge on the address lines, so initially either the buffers should be fitted and no capacitors fitted, or capacitors, suggested value 180pF, should be fitted from A8-A11 to 0V only and the buffers should be linked across.

I'll start looking around for the ICs at work tomorrow. I think I might have the 365 buffers, the '02 and the RAM already. I'll also have a hunt around the shops for some suitable jiffy bags.

Once you've assembled your own board you should be able to get it to output a signal initially by setting it to display the contents of the onboard RAM at 0200-02FF and 0300-03FF and applying 5V power. It should render the random content of the RAM either as graphics or characters, according to the state of the graph / char input.
SiriusHardware is offline   Reply With Quote
Old 24th Jul 2021, 7:16 pm   #65
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Well, some initial results. I programmed a chip with firmware #692, fitted the address buffers and jumpered the lower 8 address lines to the data lines. The results are a bit smeary, I'm convinced this is the phono cable I am using - I didn't bother to buy one because I knew I had one in a box of miscellanea that I had, and when I got it out I discovered it was a M-F stereo cable rather than the needed mono M-M. I chopped off the female connectors and joined the 2 stereo leads to make a mono and in the process discovered it was unscreened and made of tiny unsolderable aluminium wires so popular in the far east. Its also way too long, so I am 90% certain that is where the problem is. Another possibility is I fried the transistor a little too much as I was having trouble soldering it without shorting it due to the microscopic footprint I seem to have chosen for it.
However, the display is rock solid aside from the smearing and the buffers are apparently working enough to switch on at the right time, so tomorrow is testing the on-board memory and connecting it to the MK14 and running some of the test programs I think Tim posted to the original thread.

I've definitely overdone the regulator, the board pulls hardly any current and would probably have been OK to use a little TO92 regulator, or even pull from the MK14 (which is an option!).
Attached Thumbnails
Click image for larger version

Name:	IMG_20210724_195450.jpg
Views:	33
Size:	121.2 KB
ID:	238173   Click image for larger version

Name:	IMG_20210724_195758.jpg
Views:	30
Size:	120.6 KB
ID:	238174  
Slothie is offline   Reply With Quote
Old 24th Jul 2021, 8:38 pm   #66
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

Looking good - if you are unlucky you may have part damaged the video buffer transistor but visually speaking it just looks like the cable has far too much capacitance because of the way the characters are comet-tailing like that.

I did wonder about the need for the regulator but with the MK14 running right on the limit on boards which typically have a tiny heatsink on the main regulator, anything which keeps any additional load away from it can only be a good thing.

We are heading out shopping tomorrow so I will make sure I come back with a handful of jiffy bags to get the supply train rolling on Monday.
SiriusHardware is offline   Reply With Quote
Old 24th Jul 2021, 10:27 pm   #67
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Quote:
Originally Posted by SiriusHardware View Post
Looking good - if you are unlucky you may have part damaged the video buffer transistor but visually speaking it just looks like the cable has far too much capacitance because of the way the characters are comet-tailing like that.

I did wonder about the need for the regulator but with the MK14 running right on the limit on boards which typically have a tiny heatsink on the main regulator, anything which keeps any additional load away from it can only be a good thing.

We are heading out shopping tomorrow so I will make sure I come back with a handful of jiffy bags to get the supply train rolling on Monday.
Well I've ordered a new cable that's designed for AV and not 10 metres long! I can still carry on with my testing without it for now,

Anybody building the board should really just lay the regulator down on the board and not bother with a heatsink, unless they are powering their MK14 from a higher than normal voltage (I use a 7.5v 1,6A supply, sold for use with a Roberts radio I think!). If they have enough headroom with current and temperature then there's always the no-regulator option on the board. When I have all the chips fitted I will try to take some accurate power consumption readings with a multimeter (the ammeter on my cheapo "bench" power supply seems to be accurate to +-100mA despite having 3 decimals, so I generally ignore it!)

The rest of the uploader PCBs have arrived now, so I have 10 spare and I could send some with the Ortonview PCBs once we know who wants them.
Slothie is offline   Reply With Quote
Old 24th Jul 2021, 10:47 pm   #68
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 640
Default Re: Ortonview PCB

Quote:
Originally Posted by SiriusHardware View Post
On the prototypes (Mine, Tim's) the capacitors from A0-A7 to 0V were never fitted and fitting them could have unintended consequences. The ones from A8-A11 to 0V were necessary - 180pf-200pf in my case, to resolve the problem where software attempting to write to a location in any given memory page would sometimes write to the same location in a different memory page as well.
My suspicion is that the capacitors on A8 to A11 were required due to the combined load effect of the inputs of the pic and the 74ls ttl address decoding on the mk14. An alternate to the buffers or capacitors might be to swap the 74ls address decoding for 74hct.

Then we might start getting into an argument about where to draw the line for retro hardware, though I think the pic already sets an era that would allow 74hct, but that is on a separate board rather than a mod to the mk14.

If Ianís board doesnít show memory corruption with the buffers we probably need to experiment with taking them out to confirm they are the fix and not just some other effect due to the board layout etc.
Mark1960 is online now   Reply With Quote
Old 25th Jul 2021, 7:17 am   #69
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

Quote:
An alternate to the buffers or capacitors might be to swap the 74ls address decoding for 74hct.
Karen didn't specifically make OrtonView for issue VI or other replica boards, she was aiming to make a direct functional replica of the original VDU which could be used with any MK14 including any original machine as long as that machine already had the historically necessary modifications required for the fitting of a VDU.

Owners of original MK14s may very well have some of the ICs directly fitted in the PCB, or may just not want to replace any of the historically authentic components so I think any modifications to solve any problems have to be on the OrtonView, and not on the MK14 - especially when these problems are specific to OrtonView, and do not occur when a real SOC VDU is connected.
SiriusHardware is offline   Reply With Quote
Old 25th Jul 2021, 10:34 am   #70
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Well I plugged in the memory chip and when I got the P1-P4 set properly I see a stable alternating pattern of 00 and FF characters, which is plausible for the initial pattern for the memory chip. One odd thing I was getting instability - the display going blank at random - and when I touched the A1 wire, or touched the A1 pin on the test points it would also blank. Touching it continuously with an insulated screwdriver caused a lot of onscreen noise, and sometimes blanking of the display (whether its the signal failing or the TV losing sync I'm not sure, LCD TVs tend to blank the screen when they get confused). I removed the buffers and the memory chip and touching pin 20 of the PIC (the UA1 output) causes the same problem, and the only thing connected to the UA1 is the buffer. This doesn't seem to happen with the other address lines, which is the weird part. I am aware that the address lines float when NENIN is not high, so maybe the PIC programming needs changing so the address lines no longer float (since this function is now being done by the buffer) but its strange its only UA1 and not the others. I'm going to put a pin in that for now and continue testing and just avoid the issue and till I get chance to get my USB scope out (which is a pain to use). I want to connect up to the MK14 now and check that changing memory affects the display, and the memory works OK etc. Then its loading some software and checking for problems there. Is there any program that reliably shows the issues with memory corruption?
Slothie is offline   Reply With Quote
Old 25th Jul 2021, 11:40 am   #71
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

I've created a Bitbucket repository for all the versions of the firmware called "Ortonview.X" which is an MPLAB X project which includes all of the versions released on the old thread, tagged 'fw###' where ### is the post number (e.g. the latest is fw692). The "master" version is based on fw692 and is the one I am tinkering with (nothing significant yet, but there you are).

https://bitbucket.org/IanKRolfe/ortonview.x/src/master/

Perhaps someone could try accessing it and verify they can. I tried logging out of bitbucket to see but it just automagically logs me back in...
Slothie is offline   Reply With Quote
Old 25th Jul 2021, 2:51 pm   #72
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

Set the VDU to display memory blocks 0Fxx and 0Bxx and then write a program, resident in I/O RAM at 088x->, which continually writes successive characters to address 0Bnn, where nn is randomly chosen by you from the range 00-FF.

When the program is running you will see the single character in 0Bnn continually changing, and if the corruption problem is present you will see that the contents of 0Fnn also change from time to time, to typically one of four characters all of whose character codes end in 'F', or so I seem to remember.
SiriusHardware is offline   Reply With Quote
Old 25th Jul 2021, 2:54 pm   #73
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

I've looked at the archive and I can view what is in it, I have not downloaded anything as I am not on my main computer at present.
SiriusHardware is offline   Reply With Quote
Old 25th Jul 2021, 3:09 pm   #74
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

I've connected up to the MK14, and nothing worked, the display just flickered even with the VDU disabled. I removed the buffer ICs and the PIC and the MK14 is working again and the 1.5k memory is there and working fine (I did wonder if I'd made an error with the memory mapping), so that is OK and the memory mapping of that is correct and the problem is with the PIC and/or buffers (since thats the only untested part of the design that is also the part I am most suspicious of).
I did think at first maybe the NENIN output from the PIC might be floating causing the buffers to switch spuriously but I've looked at the code and the pin is always an output - which is why of course Karen put the diode there in the first place.
I'm going to jumper the buffers and see if it all works as it should (maybe using Karen's original "slow mode" firmware if necessary, so I can get a baseline and see where things go from there. Its slightly possible that there is a problem with the PIC chip as it wasn't new, if so I think I have another 877 somewhere. If not I can always take the one from my PIC14 and reprogram that.
Slothie is offline   Reply With Quote
Old 25th Jul 2021, 3:18 pm   #75
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Quote:
Originally Posted by SiriusHardware View Post
It may be worth stating that it is necessary to use a 'plain' 877 and not an 877A, otherwise you get the 'double image' issue in graphics mode only. The reason for this was never resolved so the present solution is - don't use the 877A.
Its a shame because the 877 is getting harder to get already, and the 877A is really cheap!
Maybe something to look into later. Of if there is another chip that works as a plug in replacement.
Slothie is offline   Reply With Quote
Old 25th Jul 2021, 4:02 pm   #76
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,073
Default Re: Ortonview PCB

I am following along guys - here is the archive I have from testing including the source to CHARSET which was the one that shows the error easily.
Attached Files
File Type: zip VDUTESTS.zip (2.2 KB, 6 views)
File Type: zip CHARSET.ASM.zip (1.5 KB, 10 views)
Timbucus is offline   Reply With Quote
Old 25th Jul 2021, 4:06 pm   #77
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Quote:
Originally Posted by Timbucus View Post
I am following along guys - here is the archive I have from testing including the source to CHARSET which was the one that shows the error easily.
Oh cool, I had the TESTS zipfile but not the charset program.
Slothie is offline   Reply With Quote
Old 25th Jul 2021, 4:30 pm   #78
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,080
Default Re: Ortonview PCB

As written, CHARSET cycles through the character set quite slowly so it takes a correspondingly longer time for one of the writes to also cause a rogue write to another page as well.

You should therefore reduce the 'time between successive character writes' delay to the minimum so that the software is doing the maximum possible number of writes to the intended location within the intended page per second.

If you do that, then the same character in the other screen memory page - which should not change at all - will change every second or every few seconds when the corruption problem is present.

The version Tim bundled a couple of posts ago may already have been accelerated in this way.

You can see why there would be a problem when there is software in 0Fxx which is trying to write to screen memory at 0Bxx - the software ends up knocking bits out of itself when intentional writes to 0Bnn also occasionally cause changes to 0Fnn.

For that reason, if your test program is in I/O RAM at 088x, it's best to have it write to 0F7F or less, or 0B7F or less so that there will be no random writes to 088x, which would take down the test program.

When running test like this you'll find the uploader a godsend because if the test program self destructs, runs wild and wipes itself out, it only takes a matter of seconds to reload it.
SiriusHardware is offline   Reply With Quote
Old 25th Jul 2021, 4:36 pm   #79
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,044
Default Re: Ortonview PCB

Quote:
Originally Posted by SiriusHardware View Post
When running test like this you'll find the uploader a godsend because if the test program self destructs, runs wild and wipes itself out, it only takes a matter of seconds to reload it.
One of the reasons I pressed fast-forward on getting my uploader made...
Slothie is offline   Reply With Quote
Old 25th Jul 2021, 6:11 pm   #80
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 640
Default Re: Ortonview PCB

I think I just about make out the T for 74hct02 in the photo posted earlier but maybe you could confirm thats what you used.

For the NENIN pull down on your MK14, is that 4.7 k. I think thats what you had on your schematic for the issue VI. Just wondering if you instead used 1k or lower, which combined with the 470 on the ortonview might stop the pic output from pulling up high enough.
Mark1960 is online now   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 3:53 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


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