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 13th Sep 2022 11:01 pm

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.

Timbucus 13th Sep 2022 11:13 pm

Re: Ortonview PCB
 
Glad to see progress for you Slothie (on both fronts)!

Slothie 13th Sep 2022 11:34 pm

Re: Ortonview PCB
 
Quote:

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

(snip...)

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.

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.

SiriusHardware 13th Sep 2022 11:44 pm

Re: Ortonview PCB
 
Quote:

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

Mark1960 14th Sep 2022 12:40 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1499370)
RC7=0 and RC5=0 gives you the bottom edge of the sync pulse.
RC7=1 and RC5=0 turns Q1 partly on, giving black video level at Q1 emitter
RC7=1 and RC5=1 turns Q1 on harder, giving peak white video level at Q1 emitter.

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.

Mark1960 14th Sep 2022 12:53 am

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.

SiriusHardware 14th Sep 2022 1:33 am

Re: Ortonview PCB
 
Quote:

RC5=1 and RC7=0 could also be decoded to generate either synch level or black level
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.

Mark1960 14th Sep 2022 3:31 am

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.

Slothie 14th Sep 2022 9:58 am

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

+--------------+--------------------+-----------------+------------+
|PARAMETER    |  RC5  RC7  BLANK |  IDEAL          | SIMULATED  |
|--------------+--------------------+-----------------+------------+
|SYNC          |  LOW  LOW  LOW  |  0.000V        |  5.100nV  |
|BLACK        |  LOW  HIGH  LOW  |  0.285v-0.339V  |  0.3328V  |
|100% WHITE    |  HIGH  HIGH  LOW  |  >1.000V        |  1.0670V  |
|BLANKED SYNC  |  LOW  LOW  HIGH  |  0.000V        |  5.100nV  |
|BLANKED BLACK |  LOW  HIGH  HIGH  |  0.285v-0.339V  |  0.3044V  |
|BLANKED WHITE |  HIGH  HIGH  HIGH  |  0.285v-0.339V  |  0.3060V  |
+--------------+--------------------+-----------------+------------+

Ideal values from https://en.wikipedia.org/wiki/Compos...site_Video.svg
Simulator at https://lushprojects.com/circuitjs/circuitjs.html
Simulator file at https://drive.google.com/file/d/13sA...ew?usp=sharing

Other states not valid.

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.

SiriusHardware 14th Sep 2022 10:23 am

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

Slothie 14th Sep 2022 11:01 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1499471)
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?

Its nano volts, not millivolts. i.e. 0.00051v
Quote:

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

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 :)
Quote:

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

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!

Slothie 14th Sep 2022 11:22 am

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.

SiriusHardware 14th Sep 2022 11:36 am

Re: Ortonview PCB
 
Quote:

Its nano volts, not millivolts. i.e. 0.00051v
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. ;)

Quote:

While the voltages are different, they are between the black and blank levels, so the TV should be black for all levels.
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.

Slothie 14th Sep 2022 11:41 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1499492)
Quote:

Its nano volts, not millivolts. i.e. 0.00051v
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. ;)

Quote:

While the voltages are different, they are between the black and blank levels, so the TV should be black for all levels.
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.

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.

Slothie 17th Sep 2022 9:41 pm

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!

SiriusHardware 17th Sep 2022 11:48 pm

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.

SiriusHardware 15th Oct 2022 10:48 am

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.

Slothie 15th Oct 2022 3:17 pm

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.

Mark1960 17th Nov 2022 9:22 pm

Re: Ortonview PCB
 
Quote:

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

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.

SiriusHardware 17th Nov 2022 9:32 pm

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.

Quote:

Originally Posted by Slothie
I think I may have thought of a way to generate the blanking signal without any software changes required.

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

Slothie 17th Nov 2022 10:41 pm

Re: Ortonview PCB
 
1 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1514413)
Quote:

Originally Posted by Slothie
I think I may have thought of a way to generate the blanking signal without any software changes required.

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

I was being a bit vague because I wasn't sure of all the details and wanted to try out a few ideas before I made a fool of myself, but I haven't had time to do this yet so here is the general idea...

Basically, my idea was based on the fact that while the pixels are being clocked out by the serial device the actual clock waveform is output on RC6 (Pin 25) which is the pin connected to the P4 input via the 10k resistor. During the sync intervals the serial device is disabled, so P4 can be read as an input so this is how the functions are shared on that pin.

My idea was to detect the 4MHz clock signal using a high pass filter and use this to detect when the serial device is active. There will be a lag between the clock starting and the 4MHz clock being dtetected, but that is actually good, because if we are using this signal to control the blanking signal we need a delay anyway so that the blanking is held while the white line is being output, and there are several "blank" characters being output between the end of horizontal sync and the beginning of actual output data.

A general idea is in the attached diagram - the red line is the blanking signal.

Mark1960 17th Nov 2022 11:28 pm

Re: Ortonview PCB
 
Quote:

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

I thought just bumping this thread might be a more subtle prod for an update, but maybe you don’t do subtle :)

After further thought on using NENOUT to bump lower priority 8060s off the bus, instead of waiting for BUSRQ to ripple through NENIN/NENOUT chain, I guess there is still a risk that an 8060 gets bumped off the bus at a point that triggers a corrupted write. All the 8060s would be on the same clock, but TC and microcycles are not synchronized. We still don’t really know accurately what timing triggers the issue. We only know it seems OK if we use the 74ls74 circuit to block NENIN for a couple of clock cycles when NADS is asserted. I guess I just need to try it and see if it works.

SiriusHardware 17th Nov 2022 11:47 pm

Re: Ortonview PCB
 
I haven't thought it fully through but, consider the case of a fully inverted screen where all of the background outside of the active screen area is white - would your (Slothie's) circuit impose black level during the 'bright line' phase even then? Because if it did it would create an even more intrusive black vertical band to the left of the active area whenever Ortonview was operating in inverse video mode.

It also looks as though this requires two more different types of gates in addition to the '74 used for Mark's fix so that would take the chip count for Ortonview to four, not counting the two used for the RAM expansion.

If we are going to throw more chips at it I would honestly suggest just using a small 8-pin PIC for just this job. I envisage sampling the state of the video output after the rising edge of the sync pulse but before the bright line and if it is white (inverted screen), doing nothing (because the bright line will just blend in) and if it is black, generating a timed bright line suppression pulse to flatten the bright line.

As per this Pseudocode:

Code:

Begin:
-Wait for a rising edge on sync
-Time to a point just before the 'bright line' is due to fire up

-Sample the current state of the video output line:
    -If white, do nothing
    -Go to Begin:

    -Else (...If black...)
   
    -Commence bright line suppression output
    -Time until bright line time has passed
    -End bright line suppression output
    -Go to Begin:

Part of me doesn't really want either of these measures to actually work, because what we really want is for the main PIC to contextually generate the bright line suppression, it's part of why you did that good work to convert the code to run on an 887 as Karen had originally envisaged as it frees up an I/O pin, albeit one which can only be used in input mode. If we solve it some other way it removes the incentive to fix it 'properly'.

I once used a trick on a Micro:Bit to generate an output signal (a squarewave) on an I/O pin configured as an input . I did that by setting the pin as an input and then alternately switching the pin's input mode between pulled up and pulled down. In case you wonder why, I used it as a way of verifying that the settings for pull up / pull down were actually working because up until a certain point they didn't, as Micropython for Micro:Bit didn't initially support setting those pin modes. Then after a certain point, it did.

Unfortunately I don't think the PIC we are using here has pins which can be programmed as -either- pulled up or pulled down, possibly pull-up only - in which case maybe we could use a very weak external pulldown resistor to pull the pin down when it is not pulled up by the internal pull being enabled. You then change the logic state on the pin by switching the pin between pulled up input mode and not pulled up input mode. It wouldn't have very strong drive capability so the change of state would have to be detected / amplified / buffered by a FET or something.

Mark1960 17th Nov 2022 11:51 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1514421)
My idea was to detect the 4MHz clock signal using a high pass filter and use this to detect when the serial device is active. There will be a lag between the clock starting and the 4MHz clock being detected, but that is actually good, because if we are using this signal to control the blanking signal we need a delay anyway so that the blanking is held while the white line is being output, and there are several "blank" characters being output between the end of horizontal sync and the beginning of actual output data.

I wonder if a retriggerable monostable would do that better than a filter. Would a gate be needed to blank the video or would a diode from Q work.

SiriusHardware 17th Nov 2022 11:52 pm

Re: Ortonview PCB
 
Quote:

but maybe you don’t do subtle...
Ah, we have a saying here on Tyneside: "Shy Bairns Get Nowt". ;)

Mark1960 18th Nov 2022 12:14 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1514433)
Part of me doesn't really want either of these measures to actually work, because what we really want is for the main PIC to contextually generate the bright line suppression, it's part of why you did that good work to convert the code to run on an 887 as Karen had originally envisaged as it frees up an I/O pin, albeit one which can only be used in input mode. If we solve it some other way it removes the incentive to fix it 'properly'.

I thought it might be possible to replace the resistor on the sync output of the PIC with a diode, so it forces the sync level on the output regardless of the video output. Then start the serial initialization before the sync level is released. I think it would take me too long to learn the code and PIC assembler language to try this but the hardware would be a lot simpler.

Slothie 18th Nov 2022 1:24 pm

Re: Ortonview PCB
 
Well my plan if the PIC was generating the blanking signal was to free up the RC5/RESET pin and use it as an input to free up one of the other pins used to read the options (say, RE2/PS3 then we would have an output to use for blanking. I'm still thinking this may have to be the way ahead because I was unsure as you are on the effect on the inverse video operation (one of the reasons I wanted to experiment a bit before revealing my genius idea !!). I have worked out the changes needed to do this but its untested as I need to make the mods to the PCB.

Using the PIC to generate the blanking does reduce the component count, and is more in line with the general philosophy, but it does involve extensive changes to the PIC code and that could be tricky to make changes to. Fortunately the handling of the signal is in a portion of the timing where the code is just marking time, its just something that needs changing in multiple places across the firmware, and the delays need adjusting in multiple places to compensate, so the opportunity to get it wrong is high..

Also changing RC5 to be an input rather than a reset could make programming the device harder, because the low voltage programming mode is no longer available. Not a huge problem, but could make debugging a bit harder.

SiriusHardware 18th Nov 2022 2:23 pm

Re: Ortonview PCB
 
Quote:

it does involve extensive changes to the PIC code and that could be tricky to make changes to.
I know, and I appreciate that just one small change can destroy the timing since the whole thing is software timed. I don't know if Karen just did all this stuff in her head or whether she had some sort of calculator for calculating the microcycles / therefore time taken by any block of code between instruction X and instruction Y. I seem to remember the old MPLAB simulator had a microcycle counter which you could reset at any point while you were single stepping through code and it would add the microcycles up for you as it went. I don't know if MPLAB X has anything similar.

However this isn't a building we are knocking down, so if anything goes badly wrong we can always reload to the last working version of the code and start again.

I wouldn't actually worry about the blanking output hardware for now beyond deciding which PIC pin to use to drive it, and then try to get that output to generate a context-sensitive blanking pulse which begins just before the bright line and ends just after the bright line, without breaking anything else - then try to work out how to use it to gate or clamp the video brightness signal.

SiriusHardware 18th Nov 2022 4:09 pm

Re: Ortonview PCB
 
Could you point us to the most recent version of the 887 chip source which successfully assembles and runs?

Slothie 18th Nov 2022 4:29 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1514556)
Could you point us to the most recent version of the 887 chip source which successfully assembles and runs?

Thats at https://bitbucket.org/IanKRolfe/orto...mmits/tag/r2.2 with download of hex at https://bitbucket.org/IanKRolfe/orto...ewHex_r2_2.zip

SiriusHardware 18th Nov 2022 5:52 pm

Re: Ortonview PCB
 
Thanks - as usual I am away for the weekend and the only machine I have MPLAB X on is my main desktop, I'm assuming the source has been edited in / saved from the MPLAB X editor and is best viewed in the same editor.

I may need you to (at some point) explain the MPLAB X steps to incorporate the source into a project and assemble it into working code because I failed miserably the last time I tried. I knew how to do all that in original MPLAB but as usual the user interface and way of doing things has evolved into something nearly unrecognisable for no good reason that I can see.

Regarding LV programming, are you sure you are using that?

I use a Pickit2 (original) for 877 / 887 programming and that definitely doesn't use the LVP process to program those devices, it does however require a little network including a Schottky blocking diode on the reset / programming pin to allow the high programming voltage to be applied to the pin without it running back into the application circuit through whatever the pin is connected to.

It's not much of a problem for me personally because I have my old 'Picduino' which is a homebrew 40 pin experimentation board for 40-pin PICs - in fact my first build of Ortonview was lashed up very quickly using that. It includes an ICSP header so I can always use that to program ICs for use in Ortonview even if Ortonview itself loses the programming connector.

Slothie 18th Nov 2022 8:56 pm

Re: Ortonview PCB
 
I have been using MPLAB X on a laptop running Linux Mint, so you may need to modify what I am about to say if you are running it on Windows.
First of all, I'm using MPLAB X IDE version 5.35 with MPASM support (I think this has to be selected on install). Ignore warnings about it not being supported on 64 bit platforms, it still seems to work on these versions.
The zip file of sources can be obtained from the repository by clicking on the "..." menu next to "invite" and "clone". Be sure you have the commit tagged "r2.2" because the "master" one contains changes I have been trying for the blanking signal etc.
The project files go in /home/user/MPLABXProjects/OrtonView.X/ and when unpacking the sources from the zip file you will need to rename the directory name to OrtonView.X because the one in the zip file will be "IanKRolfe-ortonview.x-3410de4eb944" or similar.
You should then be able to start MPLAB X and use File->Open Project to select the OrtonView.X folder and open it.


I'm not sure if I was or was not using LV programming, I was probably using HV programming the few times I used the ICSP header on my Ortonview because I think that is the default. The PCB has the diode required that you describe (D3 on the board) but if the pin is being used as an input this may not work - although it may just be a matter of setting the dip switch correctly and removing any connection to the P3 pin on the board, I haven't looked directly into it at this point as I haven't made any mods to the PCB yet to support the change. Its not a big problem as I have an adapter board the Pickit 3 plugs into that has a 40 pin ZIF socket which I've used to program PICs in the past. I have used the ICSP connector on the Ortonview to program in the old firmwares so I know it works in its unmodified form.

Slothie 13th Apr 2023 12:52 pm

Re: Ortonview PCB
 
Since I intend to restart my efforts on the white line removal before settling on a new PCB design, I discovered in a recent upgrade to the OS on my PC that MPLAB X, KiCAD and the KiCAD 3d models all need reinstalling. The last version that supported MPASM was 5.35 and is available here:
https://www.microchip.com/en-us/tool...plab-ecosystem

For those that prefer, the last version of MPLAB 8.92 supports MPASM and is available at the same place, just select "MPLAB Archive" from the top menu bar.

Now I just have to get KiCAD reinstalled and hope that I don't have the palaver I had last time getting the libraries and 3D models to hook up.

SiriusHardware 17th Apr 2023 5:07 pm

Re: Ortonview PCB
 
1 Attachment(s)
Thanks for continuing to keep this ticking over, as I feel we owe it to Karen to see this through to the end. In fact Karen's reaction to the bright line was 'Yeah, sorry about that, it's just a fact that the serial output initially outputs a logic 1 when first initialised' or words to that effect but I think she would have been quite pleased if we found a way to solve it, especially if we did it using little more than the PIC itself as she undoubtedly would have done herself.

For anyone late to the party and wondering what we are talking about, there is an inherent artefact in the otherwise pristine video output generated by Ortonview, a narrow bright white line near the left hand side of the image. This occurs when the serial output is switched on immediately before it starts to generate video output at which point it generates a logic 1, equivalent to peak-white, before the serial output begins generating video output under software control, see the attached image.

If you have a CRT monitor you can quietly eliminate the bright line by increasing the horizontal and vertical scan widths to the extent that the bright line falls beyond the left screen edge, but if using an LCD screen it will be more difficult to get rid of because an LCD screen will try very hard to fit every part of the image onto the screen including the unwanted bright line - so the main outstanding problem now on Ortonview is how to use the main PIC to generate a context sensitive bright line blanking pulse, and then how to utilise that so that it dims the bright line to the same 'shade' of black as the video black level.

Slothie 17th Apr 2023 10:50 pm

Re: Ortonview PCB
 
I have tinkered with various approaches, hardware and software but I agree the best idea and most in line with the original idea is to do as much as possible in software... one issue is I really haven't done any programming for a year or so now so I need to re-familiarise myself with the code and its not as simple as I thought. How Karen kept all this stuff in her head with what she was going through I cannot imagine.
I recall that I worked out how I could free up a pin to make a blanking output by re-arranging the P1-P4 pins and started working on the code to do that. Then I need to work out how to make the blanking work so that it eliminated the bar without replacing it with a different shade of grey or similar! If you recall I made some simulations, but there is no substitute for actually building the circuit and trying it.
Progress is probably going to be a bit erratic, sometimes my treatment hardly effects me and other times it knocks me out, but the good news is it does seem to be keeping things at bay.

Mark1960 18th Apr 2023 2:36 am

Re: Ortonview PCB
 
I still think there might be a possibility to use only two outputs from the pic. Use a diode instead of resistor to pull the video output to the sync level and resistor network to select the black and white level from the other pin. The diode would allow the sync output to override the white line. The data output would need to be initialised before the sync is released.

I’ve never programmed the pic in assembler or tried to study Karen’s code, and too busy with work to try this myself.

Slothie 18th Apr 2023 8:04 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1552445)
I still think there might be a possibility to use only two outputs from the pic. Use a diode instead of resistor to pull the video output to the sync level and resistor network to select the black and white level from the other pin. The diode would allow the sync output to override the white line. The data output would need to be initialised before the sync is released.

I’ve never programmed the pic in assembler or tried to study Karen’s code, and too busy with work to try this myself.

The problem is that the white line appears AFTER the horizontal sync has finished.

Mark1960 19th Apr 2023 12:21 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1552452)
The problem is that the white line appears AFTER the horizontal sync has finished.

Yes, but could the serial output not be initialised before the horizontal sync has finished.


All times are GMT +1. The time now is 6:04 am.

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