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)

Timbucus 11th Jul 2021 11:59 am

Re: Ortonview PCB
 
Indeed happy to help with that and another test build if it helps.

Slothie 11th Jul 2021 12:10 pm

Re: Ortonview PCB
 
When I get them I will see if i can arrange to send some out, its going to be a couple of weeks because I cheaped out on the postage :) By them I will have decided how audacious I can be with the cost! That might also depend on if it actually works...

SiriusHardware 11th Jul 2021 10:19 pm

Re: Ortonview PCB
 
There are some parts I'm not familiar with, like the RAM and the skeleton video-out socket, so if you can put together a short list of the more exotic parts and suggested suppliers ie, where you got yours from, and drop it off to interested parties via PM we can start to gather any Slothie-version parts needed in advance.

Tim and I already have working OrtonViews, mine is certainly in need of rebuilding properly so the majority of parts needed will come from that original rough prototype. It would be interesting to hear if anyone else that we don't already know of has also built an Ortonview.

Mark1960 11th Jul 2021 11:33 pm

Re: Ortonview PCB
 
The ram looks to be 6116 pin compatible, but try and use the LP version if you plan to use battery backup.

Battery socket looks a common type but might be good to confirm the part used.

Could someone add a link to the best firmware version as a starting point? It would probably be good to have a reference from this thread anyway.

I might wire up an orton view on protoboard just to join in. Its probably not worth postage charges to canada.

Slothie 13th Jul 2021 9:05 am

Re: Ortonview PCB
 
The battery socket is Multicomp CH29-2032LF but there are others that are pin compatible available from other manufacturers, but the Multicomp seemed to be the cheapest. I've seen the SMD version of this on eBay, which could probably be pressed into service since the through hole pads are on both sides....

The Phono socket is just something I found on eBay, but appears to be the same as Cliff FC68391 - I've checked the footprint and it should fit. The critical dimension between the front ground pin and the rear (signal) pin is 6.35mm so other types may well fit.

The write protect switch is a CK 1101 [specifically 1101M2S3AV2BE2] But the critical dimension is the 4.7mm pin pitch. In retrospect the CK switch is pricey, and I might have been better off using one with a 0.1" pitch which seem to be all over eBay.

All the above are available from Farnell/Newark and other suppliers. I was going to link but I know that is frowned on but they all turn up if you search on site or google.

The RAM is 6116LP compatible, I just used the M5M5117 because I have 8 or so of them....

Slothie 13th Jul 2021 12:40 pm

Re: Ortonview PCB
 
I've just noticed that the 4.7mm spacing on the switch is the same on PCB mount sub-min toggle switches, so that's an option too.

Mark1960 14th Jul 2021 12:00 am

Re: Ortonview PCB
 
I was just scanning through the mk14 vdu thread again to review the development of the OrtonView. Gave myself a bit of a panic when I saw Karen was planning to use the pic16f887 rather than the pic16f877 before I saw that she changed back to the pic16f877. Then another when I read that she swapped the B and D ports, before I realised that I searched the thread backwards when I was looking for the schematic, so was already looking at the schematic after the port swap.

What I couldn’t find was why the NENIN output of the pic has a diode in series. Does anyone know why the diode is needed?

SiriusHardware 14th Jul 2021 7:13 am

Re: Ortonview PCB
 
I can't remember which way the diode 'points' but it is to convert the totem-pole NENIN drive output from the VDU to one which pulls (up?) only. When not driven high via the diode NENIN is held low via a resistor, or so I seem to remember.

The original SOC VDU has the same arrangement on the output of the gate which drives NENIN on the MK14, so I think the NENIN drive arrangement was just copied verbatim.

If you sift carefully through the original thread there are a couple of posts where this is mentioned.

Mark1960 14th Jul 2021 9:56 pm

Re: Ortonview PCB
 
I found that part of the mk14 vdu thread, and I even replied to it with my concern about the active pull up if ever NBUSRQ was connected to NENIN, which is what was also bothering me this time round.

I’m still not sure why the original mk14 vdu used a 470 ohm pull down and npn transistor to pull up on the output of a cmos 4011. Maybe they wanted to protect the 4011 from an incorrectly modified mk14, or thought it couldn’t drive the 8060 NENIN, which doesn’t seem to have the input current in the 8060 spec.

Slothie 22nd Jul 2021 1:31 pm

Re: Ortonview PCB
 
3 Attachment(s)
Hurrah! The Ortonview PCBs have arrived. They look nice, the quality of the silkscreen on the board is not as good as it usually is but not too bad. The footprint I made for the CR2032 is fine, the phono connector is a bit snug and I had to straighten the pins to get them into the board as shown in the picture, and I had to file the pins on the switch to get it in but not much, and it might just be the cheapo switch I got off eBay :D
I'll be putting it together to see if it works, and if so how well it works. After Sirius and possibly Tim have theirs there may be 2 or 3 spare and If people want to wait for that before registering an interest I'll understand, and I've still got to decide and tell you how much I want for them! I need to discuss logistics with Sirius anyway as he has volunteered to oversee distribution etc.

Bear in mind this is board intended to test various things and firmware updates, and should not be considered a final product in any way! That said I'll put together some notes on anything that occurs to me as I'm assembling it this afternoon and put them up here. I do intend to produce a more "final" board in the future, these are intended for people who want to help me shake out the bugs.

SiriusHardware 22nd Jul 2021 1:48 pm

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.

Slothie 22nd Jul 2021 2:19 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1392036)
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 22nd Jul 2021 7:16 pm

Re: Ortonview PCB
 
1 Attachment(s)
I've knocked up some notes on the Ortonview, Layout, Schematic and bill of materials.

SiriusHardware 22nd Jul 2021 7:52 pm

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.

Slothie 24th Jul 2021 7:16 pm

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

SiriusHardware 24th Jul 2021 8:38 pm

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.

Slothie 24th Jul 2021 10:27 pm

Re: Ortonview PCB
 
Quote:

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

Mark1960 24th Jul 2021 10:47 pm

Re: Ortonview PCB
 
Quote:

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

SiriusHardware 25th Jul 2021 7:17 am

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.

Slothie 25th Jul 2021 10:34 am

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 25th Jul 2021 11:40 am

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

SiriusHardware 25th Jul 2021 2:51 pm

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 25th Jul 2021 2:54 pm

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.

Slothie 25th Jul 2021 3:09 pm

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 25th Jul 2021 3:18 pm

Re: Ortonview PCB
 
Quote:

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

Timbucus 25th Jul 2021 4:02 pm

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

Slothie 25th Jul 2021 4:06 pm

Re: Ortonview PCB
 
Quote:

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

SiriusHardware 25th Jul 2021 4:30 pm

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.

Slothie 25th Jul 2021 4:36 pm

Re: Ortonview PCB
 
Quote:

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

Mark1960 25th Jul 2021 6:11 pm

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.

Slothie 25th Jul 2021 6:22 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1392833)
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.

I did think that 470 ohms on the Ortonview was a bit low but it seemed to work for Tim and Sirius. My MK14 has a 4.7k resistor as advertised. I might remove the 470 ohm resistor on the Ortonview to see if it makes a difference.

Mark1960 25th Jul 2021 6:41 pm

Re: Ortonview PCB
 
I just took a quick look at the pic datasheet, it should be ok to drive 10ma and still provide 3.5v, so even after the voltage drop of the diode it should be reaching ttl logic high.

SiriusHardware 25th Jul 2021 10:48 pm

Re: Ortonview PCB
 
I seem to recall Karen mentioning that PIC pins have quite sturdy output drive, she quoted it somewhere as approx. 50R pulldown to 0V or 50R pullup to +5V when the PIC output was being driven low or high respectively.

SiriusHardware 25th Jul 2021 11:28 pm

Re: Ortonview PCB
 
Quote:

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.
Worth remembering that the original version of firmware which slowed the machine down a lot did not exhibit the blurred graphics mode problem when EITHER the 877 or 877A were used. The 877A / Graphics mode problem only appeared as a by-product of what Karen did to reduce the amount of time the system was held by NENIN.

Other pin compatible and largely code compatible 40-pin DIP PICs include the 16F887 and the 18F452. Karen actually meant to use the 887 originally because it has more pins which can be used as general I/O pins than the 877 does. Problem was, she found out at a late stage that the programmer she had available didn't support the 887 and with typical ingenuity, found a way to use the 877 with its lower I/O pin count.

We could just try making an MPLAB project set up for the 887 and bringing the code into that to see whether the 887 does or does not run the 'fast' version of the Ortonview code without any problems in graphics mode.

Slothie 26th Jul 2021 8:36 am

Re: Ortonview PCB
 
Oh, maybe I can try an 887 when I get everything working. They seem pretty cheap on eBay. I have an 877A too, so maybe I could investigate the graphics issue with that one, but that would be a "stretch goal" at the moment!

SiriusHardware 26th Jul 2021 9:00 am

Re: Ortonview PCB
 
Have jiffy bags, just need to get a couple of them addressed and appropriately stamped up, hopefully this lunchtime if real life doesn't get in the way.

Slothie 26th Jul 2021 10:06 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1392937)
Have jiffy bags, just need to get a couple of them addressed and appropriately stamped up, hopefully this lunchtime if real life doesn't get in the way.

Cool! I just need to get this to work lol

SiriusHardware 26th Jul 2021 11:07 am

Re: Ortonview PCB
 
And they're off!

Open carefully, the smaller return envelope is an exact internal fit inside the larger one I have sent it in, so if you take a pair of scissors to the end you will cut the end off the inner bag as well. I put one of our heaviest populated PCBs in the return bag while it was weighed so hopefully there is weight headroom for three small and three larger unpopulated - if not, it'll be me who gets the underpayment card through the door.

Slothie 26th Jul 2021 12:25 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1392978)
And they're off!

Open carefully, the smaller return envelope is an exact internal fit inside the larger one I have sent it in, so if you take a pair of scissors to the end you will cut the end off the inner bag as well. I put one of our heaviest populated PCBs in the return bag while it was weighed so hopefully there is weight headroom for three small and three larger unpopulated - if not, it'll be me who gets the underpayment card through the door.

Thanks, I'll be careful and cut the flap rather than across the top. I presume you intend me to send 3 of each?

SiriusHardware 26th Jul 2021 1:08 pm

Re: Ortonview PCB
 
Indeed, that's what I have estimated for weight wise, provided the PCBs are not like paving slabs. The populated PCB I used as a dummy load has several relays and an audio transformer on board, so it hopefully weighed more than the 3 + 3 bare boards will.

Slothie 28th Jul 2021 6:49 pm

Re: Ortonview PCB
 
1 Attachment(s)
**Update**

Well I tried connecting to my MK14 and it didn't go well, the MK14 crashed. Testing appears to show bus conflicts with the buffers in. I removed the buffers and bridged them using some turned pin headers plugged into the IC sockets, and tried again. This time the MK14 worked but had some corruption in the display, the reverse 'C' Sirius and Tim noted last year. I looked in my components and found some 220pF capacitors, the nearest I could find to the values Tim and Sirius used, fitted them to A11 to A8 on the board and everything seems to be working fine. I'm going to work on loading some of the programs from the other thread and seeing if it works, and then try fitting the INS8154 I have and trying out some of Tims test programs.

Overall, a good outcome (certainly no worse than anyone else). Going to need to experiment with the buffers a bit more. I wish I'd read the old thread a bit more carefully because Mark made a suggestion about enabling the buffers after NWDS goes high and I could have put in provision for that - but it shouldn't be too hard to hack the board about a bit to try something like that.

Timbucus 28th Jul 2021 7:22 pm

Re: Ortonview PCB
 
That is excellent news really as you can replicate the results exactly that we did - well done for prototype 1!

SiriusHardware 28th Jul 2021 7:27 pm

Re: Ortonview PCB
 
Re: The comet-tailing - sorry to suggest this but have you tried just turning down the contrast? - there is also often a 'sharpness' setting on both CRT and LCD displays, does adjusting either of those alter the degree of smear?

The video signal is only either deep black or brilliant white, so it's going from one extreme to the other the whole time. As far as the display hardware is concerned, it couldn't be harsher.

Slothie 28th Jul 2021 8:19 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1393637)
Re: The comet-tailing - sorry to suggest this but have you tried just turning down the contrast? - there is also often a 'sharpness' setting on both CRT and LCD displays, does adjusting either of those alter the degree of smear?

The video signal is only either deep black or brilliant white, so it's going from one extreme to the other the whole time. As far as the display hardware is concerned, it couldn't be harsher.

To be honest I haven't fiddled with it, I replaced the cable with a better one and it improved but that cable was still 5m long. I've ordered a 2m cable that should come in a few days.
Also I didn't have the resistor values for the output stage so I did a LTspice simulation and changed the values to ones I did have, to get the same waveforms, but maybe I've not taken something into account. I've got some resistors on the way to fit and maybe that will improve things, but I will adjust the TV a bit - when watching normal TV its very saturated and so maybe contrast needs adjusting. But I'm mostly happy that functionally things are going well, and I do at least have something I can take measurements from without worrying about wires falling out! The digital signals (luminance, sync) are good, I've just got an analogue problem.

Edit: Its also true to say it looks a bit worse in the photo than in real life.

Mark1960 28th Jul 2021 8:35 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1393625)
..... Mark made a suggestion about enabling the buffers after NWDS goes high and I could have put in provision for that - but it shouldn't be too hard to hack the board about a bit to try something like that.

I think that might have been my suggestion that we stop the ortonview from interrupting a write cycle by using an AND gate between NWDS and NENIN from ortonview. Looking more closely at the timing it might still be possible for a write cycle to start and then be terminated due to a delay between NENIN and NWDS. I was planning to try and measure the timing in more detail and try and determine what clock edges to reference for each signal.

Controlling the buffers might need a delay between asserting NENIN and enabling the buffers, I think Karen had a delay before setting the address outputs active, but I don’t think the original mk14 display had that.

SiriusHardware 28th Jul 2021 8:54 pm

Re: Ortonview PCB
 
Is the PCB generated directly from the circuit diagram? (I would expect so). I've just been going over the diagram again and I can see nothing obviously wrong there, checked the pinouts of the buffers and so on and so forth.

Regarding enabling of the buffer signals via NENIN alone, obviously the edge of the NENIN signal is what tells the SC/MP to relinquish the bus and as we remember it takes a significant amount of time to do that, so maybe the buffers are passing what they are seeing on the PIC pins - even though the PIC pins are in input mode - as soon as NENIN changes state, and therefore before the SC/MP has had time to finish what it is doing and get off the bus.

Karen's code no doubt waits for a period of time after it sets NENIN high before swapping the port directions to apply the address output drive to the system address bus, but here the buffers, when fitted, will immediately output whatever state they see coming onto their inputs from the PIC pins (high, when the PIC ports are still in input mode?) as soon as they are enabled by the rising edge of NENIN.

We could trying delaying the enable signal to the buffers with a simple RC circuit in the output from U1D to the enable inputs of U7 / U8 (series resistor, capacitor up to +5V).

Edit: Crossed with Mark.

Slothie 28th Jul 2021 9:28 pm

Re: Ortonview PCB
 
1 Attachment(s)
Yes, the PCB is generated from the schematic. The correct schematic is in the notes but isn't very clear, so here it is as its own PDF.

I was looking at the code the other day, and it is a little complicated because the code for controlling the address bus and NENIN is duplicated in four or five places (one is slightly different due to timing) so I will have to look at it a bit closer.

Looking at the MK14 schematic diagram, it looks like the buffer enable and NENIN are not timed together, except that NENIN is always high when the bus is being driven, but its hard for me to tell exactly how it is timed. I really need to find a logic simulator that can cope with RC delays to see how it works, or get my hands on a replica of the original to take measurements from. But that would be another project.

Slothie 28th Jul 2021 9:29 pm

Re: Ortonview PCB
 
1 Attachment(s)
Oops forgot to attach the schematic!

Mark1960 28th Jul 2021 9:29 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1393662)
We could trying delaying the enable signal to the buffers with a simple RC circuit in the output from U1D to the enable inputs of U7 / U8 (series resistor, capacitor up to +5V).

An RC would delay both turn on and turn off of the buffers, so the buffers would remain on after NENIN is switched back to low. Unless only one of the buffer gate inputs is delayed by the RC, then it would delay buffer turn on but not the buffer turn off time.

Mark1960 28th Jul 2021 9:44 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1393672)
Looking at the MK14 schematic diagram, it looks like the buffer enable and NENIN are not timed together, except that NENIN is always high when the bus is being driven, but its hard for me to tell exactly how it is timed. I really need to find a logic simulator that can cope with RC delays to see how it works, or get my hands on a replica of the original to take measurements from. But that would be another project.

Maybe we could twist Timís arm to scope that. Unless he already did when Karen was working on the timing?


All times are GMT. The time now is 2:36 am.

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