Re: Ortonview PCB
 

Yes, I can see that working as well, assuming the schottky is fast enough (and they usually are high speed I think) and the resistance of R10 is adjusted to compensate for the volts drop across the diode.

You could add that transistor / diode hardware to your design and for the time being just set the spare PIC I/O pin which drives the video gating transistor = logic 0 so that it stays off and has no effect until we work out what to do with it. Maybe also put links on the PCB so that we can optionally have the page inputs read as they are now, or revert to the original design where the page inputs were going to be read by RE0-RE3. That would need us to work out how to reverse that pin-saving mod which Karen did when she realised that she could not program the 887.

Using a logic output to try to gate the video signal directly presents potential problems because it will exert a pull up when logic 1 and pull down when logic 0, when what you really want is 'no effect' and 'effect' respectively. As with the transistor solution you would probably have to involve a diode somewhere.

Re: Ortonview PCB
 

Glad to see progress for you Slothie (on both fronts)!

Re: Ortonview PCB
 

Fortunately there is a "long" time between the disappearance of the white line and the start of actual video data. the frequencies involved are much lower than the pixel rate. Schottky diodes have a recovery time in nanoseconds, so if the transistor can handle it I think the diode will.

I'd be able to do some decent testing, I've been "butchering" my prototype, breaking tracks, running mod wires, glueing down extra components.... So I won't have to wait for a new PCB to at least try things out in principle. Fortunately the sampling of the options is done once at the beginning of the frame, so that code (finding P1-4) is easy to change. And I could always start by "gating" alternate scan lines to make sure it works and doesn't disturb the sync.

However, Since the pixel data is being pumped out by the serial device, RA5 is always being driven high or low, so passing it through a logic gate will still have that effect. The diode in the transistor mod is just to allow me to use R10 as a current limit for the new transistor while stopping it pulling down the "black" level to the 0v "sync" level.

Re: Ortonview PCB
 

I was thinking more of the fact that your concept has the video signal passing THROUGH the diode, and whether that might have any detrimental effect on the sharpness of the image. The diode has to be able to pass signal level changes at whatever the video dot rate is.

As you say, probably easiest just to try it out by putting a schottky in series and reducing the value of R10 a bit to compensate for the diode's forward voltage drop. If the output image still looks Orton-sharp, then carry on.

Re: Ortonview PCB
 

Seeing the states represented like this I was wondering if the 4th possible state, RC5=1 and RC7=0 could also be decoded to generate either synch level or black level.

Simplest method might be that RC7=0 gives synch level and overrides RC5 selecting black or white. Then change the timing to initialise serial output during the end of the synch level before raising RC7.

Slightly more complicated hardware, but maybe simpler firmware, could be a cmos analog switch to select from four different voltage levels, maybe 74hct4051 or similar.

No additional control signal needed if one of these could be made to work.

Re: Ortonview PCB
 

Can RC7 be switched to input? Then RC5 could be a simple resistor network to generate white or black levels and RC7 is input during display frame and 0v for synch level.

Maybe need to check that RC7 input at black or white level is not going to risk damage due to floating/indeterminate input voltage.

Re: Ortonview PCB
 

I think that because RC5 is dedicated to the job of generating the video bit stream, most likely its only function is to shift the output between black level and white level, where the black level is preset by a logic '1' from RC7 partly turning on Q1.

It would make no sense to superimpose any video information on the sync level, so I think that when RC7 is low, RC5 will always be low as well.

The video device which will be receiving this signal will expect that the signal will be reasonably conformant, in particular I think it will expect the sync tip to be at or near 0V and the only way this circuit can achieve that is to turn Q1 completely off, ie, take both RC5 and RC7 to logic 0.

Re: Ortonview PCB
 

I think to turn Q1 off would only need the base pulled below 0.6v. RC7 could do this by direct connection to the base if it can be changed to an input or tristate during the display frame. Alternatively connect RC7 to the base with a schottky diode instead of a resistor.

The RC5 serial data out could then be initialized during the synch period as the uninitialized high level output would be overridden by RC7.

Re: Ortonview PCB
 

Well I didn't sleep to well last light, so I had a go at simulating my idea with the diodes etc and it didn't go well. I'd forgotten how awkward LTSpice is for static simulattion.... So I found an online simulator and tried a few ideas. The diode thing didn't really work so I played about a bit.

I came up with a different circuit, changing a lot of the resistor values experimentally and comparing the voltage level to the "standard". This seems to work well.
Attachment 264695

The results are:
The upside appears to be that the change is only a couple of extra resistors and a MOSFET. It does make some assumptions about the low impedance of the PIC outputs, but I've increased the resistances to make that less of a consideration. Hopefully soon I will find time to give this a try.

Re: Ortonview PCB
 

Points arising from this:

First line of the table shows ideal level for sync tip as 0.00V which is correct, but actual level 5.100mV. Is that a typo?

I am assuming that in your circuit the as yet unspecified 'BLANK' output from the PIC is active-high and so for Black level with blanking OFF you have 0.3328V and for Blanked White you have 0.3060V. Ideally there should be no difference at all between these values otherwise you still get a vertical line which is a different 'shade' of black.

While this would not be anything like as annoying as the current brilliant white vertical line, any applied fix should ideally blend seamlessly into the black background.

Many if not all Composite Video inputs are internally terminated with the standard video input resistance of 75R. You may wish to include a 75R resistor across the output of your circuit so that it has a realistic 'load'.

Re: Ortonview PCB
 

Its nano volts, not millivolts. i.e. 0.00051v
While the voltages are different, they are between the black and blank levels, so the TV should be black for all levels. However, that is what testing will be for :)
Yes, I noticed that the output levels for Karens original circuit where higher than I imagined, and thats probably why. I will probably need to tweak it. I just tried adding a 75 ohm load to Karens circuit, and it pulls the white up and black levels down to where they really should be (1.15v & 0.158v) - but I suspect most TV's tolerate that which is why we haven't had problems. Its a minor detail but something I will look into and report back on!

Re: Ortonview PCB
 

Just checked my circuit into 75 ohms, the voltages are too low. So I need to adjust the values, or find someone selling "ideal" transistors with no internal resistance.....But I think the principle will work with some adjustment. Thanks for pointing out the 75 ohm thing, For some reason I thought the input impedance was much higher.

Re: Ortonview PCB
 

Oh sorry, blinked and missed that. This may be the first time I have ever seen a voltage reading quoted in nanovolts on this forum. ;)

In the real world, especially with CRT monitors, people tend to adjust the brightness so that they can just see the raster background, ie, as very dark grey, so anything which is blacker than what the user has chosen as 'ideal' black will be noticeable as a darker line.

This may not be 'a thing' on LCD / Digital screens, probably anything which is numerically a bit blacker than black will just be represented by the same shade of black.

The 75R terminating resistance is common on video inputs and not uncommon on monitor sync inputs as well, which can cause problems when people try to drive such inputs using typical digital logic IC outputs - most such outputs will wilt if you put a 75R load on them.

Re: Ortonview PCB
 

The wonders of cut-and-paste. I considered reformatting it but in the end didn't.

I only have an LCD tv with a composite input (well, I have a 4" flatscreen CRT module from a door entry system that I got on AliExpress a while ago but have yet to get working, but thats another story) So I will have to rely on others to test on "proper" TVs.

Re: Ortonview PCB
 

Update:
I think I have got the software changes required to use the MCLR input for P3 so as to free up RE2 for the blanking output. I might have to lose the ICSP header, although I only used that a few times when converting the code for the '887 so it will only be a minor inconvenience.

I've spent a fair bit of time tidying up the code repository and looking through the code again to see if I can make sense of it I think I am going to have to annotate more of the code and make a "block diagram" since there are completely seperate bits of code for the various functions. I know some bits were effectively duplicated so make the code faster (e.g. inverse graphics/fonts) which will increase opportunity to miss things.

Now I need to look at the hardware mods to make the blanking work, modify my board to include those changes and see what I can do to prove the concept.

As Sirius pointed out, once that is done even if the firmware needs a considerable effort to modify it, the functionality can be disabled until the time affort and testing required can be done.

I just realized its probably a good 7-10 years since I did a significant amount of PIC programming in assembler. I'm really rusty!

Re: Ortonview PCB
 

The last reasonably complex bit of PIC programming I did was the original 2012 MK14 Hex-Uploader, and even then I wrote it in 'C' which hides all of that hideous register bank switching stuff you have to do in PIC assembly language.

As has been mentioned before, you currently seem to have the most advanced understanding of Karen's Ortonview code so that makes you the new High Priest Of PIC (Karen being the original High Priestess, of course).

I did make a start with trying to comment the original version of the Ortonview code line by line but then it when through several rapid revisions and I gave up and never really got going again.

Re: Ortonview PCB
 

A couple of nights ago I loaded a static image into the extra-extra RAM at 0200 hex on my Slothie-Ortonview, then got distracted and ended up leaving it running for well over two hours.

When I came back to it I noticed that one pixel in the image which should have been white was black. I honestly can't say whether it had in fact loaded incorrectly in the first place, or whether it had been corrupted in the same way as it was before we tried the cap fix and the 74LS74 fix (mine currently has the latter). After loading the image file into screen RAM I just left the MK14 at the OS prompt so it would have been continually modifying several of the RAM bytes in the low 0Fxx range.

I'll try to repeat the experiment again perhaps with the screen filled with alternate black and white pixels so that it will be more immediately obvious if the screen RAM does get corrupted.

Re: Ortonview PCB
 

Interesting. Maybe we haven't managed to "stab it with our steely knives" as the Eagles put it.

On other news, I was thinking of the white line elimination and I think I may have thought of a way to generate the blanking signal without any software changes required. or dodgy monostables on the sync pulses. I've just got to clear the decks here so I can get out my MK14/Ortonview stuff and find all the bits I need to do it.

Re: Ortonview PCB
 

Hi Sirius, did you get chance to try that memory corruption test again?

I just came back to look at this again to check the timing, to see if I could get the multiprocessor to work with ortonview.

Also want to investigate the latency on NADS from BUSRQ through the NENIN/NENOUT chain. I think instead of connecting first NENIN from BUSRQ it can be held at 0v or direct from the 74ls74 output from orton view. NENOUT to the next 8060 is about 500ns before NADS for lower priority 8060s. Maybe with a lookahead chain of 74ls32 for each NENIN will still work and avoid the latency.

Re: Ortonview PCB
 

I didn't do that yet, sorry. I'm not entirely convinced that the one-location 'corruption' I saw wasn't just a byte which didn't load properly in the first place as I always run the uploader just below the absolute maximum speed / shortest keypresses consistent with reliable loading. A reminder, mine does have your '74 fix fitted, the one which involves NADS in #488 of this thread, and the 'dirty fix' capacitors are no longer fitted on A8-A11.

I originally thought this might be a drum-roll leading on to Slothie expanding on how to do this, but no, it looks like we're going to be forced to ask...