Re: Ortonview PCB
 

I have changed my program to put in a long delay at the end of each loop to see if that breaks anything, but it does not, so thats the main worry off my tick-list. I guess we just need to try out as many things as we can to test it.
I'm getting a tiny bit of noise on the video, but I think that may just be the poor decoupling of the output stage that Mark noted before, or my long video cable. Not enough to worry too much about though but I might see what a little decoupling or improving the earth return might do.

Re: Ortonview PCB
 

Did you add any decoupling capacitors to the PIC pins. I fitted 10uF smd cap to each pair of power pins. Maybe you can put something similar using through hole caps, though 1uF might be the largest ceramic through hole cap available.

Could also try series resistors on the address output of the pic, maybe in the 50 to 150 range.

Maybe we can also try and fix the white band down the left edge.

Re: Ortonview PCB
 

No, decoupling is as it it by default. Some capacitance closer to the pic might improve things.

Not sure how the resistors on the address lines would help, unless that's to protect against conflicts?

Re: Ortonview PCB
 

After adding the decoupling capacitors the noise on the supply was almost gone, but it was still quite clearly visible on the NENIN output from the PIC. The noise coincided with the switching of the two groups of address pins and my guess is that the drive of the address lines is pulling the supply line inside the PIC, and we can’t get the decoupling any closer to that point. The PIC outputs are strong drivers with fast transition times, so when they drive the address lines to overcome bus capacitance they will pull quite a high current peak from the supply. Series resistors would slow down the transition times and reduce the peak current. This is all just guesswork of course, but was one of my concerns about adding capacitors on the address bus.

Re: Ortonview PCB
 

Ah, that makes some sense. I could try that fairly easily by using resistors in place of the links I have instead of buffers.

Re: Ortonview PCB
 

Maybe just try decoupling caps first.

Re: Ortonview PCB
 

I was thinking about this last night, then I thought to myself that I shouldn't worry too much. The prototype MK14 I built previously had the same decoupling as the original MK14 (i.e. virtually none) and there was so much noise on the signals that it was hard to see the signal, yet it still worked. When I made the r1.2 board I made sure there was plenty of places for decoupling caps and the amount of noise is much less. Its worth taking sensible steps to improve signal quality but we're not going to be putting this gear into any flight computers or medical equipment :) If I can reduce the noise I'm seeing that will be a good start.

As far as removing the white bar at the left of the screen, I cant see any simple way to do this without big changes to the OrtonView, or move to a different PIC. Personally I find the white bar is so far from the "active" content of the display in practice that I don't notice it, or at least it doesn't bother me. However I understand not everyone is so relaxed :)

If we can get it to work with the 16F877A or 16F887 that would be better as the 16F877 is getting rare and the whole point of the exercise was to make MK14 VDU software accessible. Sirius noted that we moved off the '887 because Karen found her programmer didn't support it for some reason, and the '877A caused glitches in the graphics mode for some reason. So it might just be a matter of moving to the '887 chip as they are essentially the same chip (I think the 887 has 1 more pin that can be used for I/o).

Re: Ortonview PCB
 

Indeed, and although we would originally have used this to reverse the need to multiplex one pin of the 877, we could instead use that extra pin as a video blanking output to hold the video line at black level during the 'bright line' period.

We would need to do this only when the relevant area of the screen (upper/lower) is in normal (not inverse) mode, because in inverse mode the 'inactive' area of the screen - the wide border surrounding the active area - is white anyway, so the bright line will blend into it.

The code should work as-is in an 887, although it may require some jiggling of the configuration bits to make sure any extra features of the 887 are turned off. A useful first check would be to see if using an 887 breaks the graphics mode in the same way as the 877A does.

Incidentally if we went to the PLCC version of the chips concerned, that would make extra I/O pins available on any of them. Although such packages are hopeless for hobbyist / stripboard use, it's not too difficult to solder a PLCC package directly to a PCB.

Re: Ortonview PCB
 

Might be a stupid question, but could we just initialise the UART earlier, so that it is reset before the visible area of the picture?

Edit: Or maybe initialise the UART only once after reset instead of on every line?

Re: Ortonview PCB
 

There are technical reasons the UART needs turning off - I can't quite remember what they were or if Karen fully explained it.

Re: Ortonview PCB
 

I was trying to figure out the basics of the video output, so there are three output levels controlled by two PIC outputs. Both outputs low for sync level, then the sync output is raised at the start of the line, then the second output switches between black and white levels. When the UART is initialised there is an unwanted burst at the white level.

If the synch output is changed to open collector/drain, connected to the base of the transistor, then the series resistor changed to pull up to 5v, and initialise the UART during the line synch. Then the synch output could override the high level during UART initialisation.

Re: Ortonview PCB
 

But, I remember something about that in order for the black to remain black it seems you have to keep feeding the serial port bytes every 8 instruction cycles. The software already has to output dummy "0" bytes after sync and turning on the serial port (or the white bar would go all the way up to the screen image) - it needs that time before starting the serial port to set up for the new scan line.The program needs the time at the end of each scan line to read in 2 more bytes so that after 8 scan lines it has the next 16 bytes to display. So it has to turn off the serial port so it can use the time to read those bytes in. That is why after vertical sync there are 2 bursts of 16 byte reads (to pre-fill the top and bottom buffers for the screen halves) and 2 reads on every scan line.
(The serial port also has to be off at the beginning of the page so that the P4 input can be read at the beginning of the page because the pin it is connected to is the clock output of the serial port - its synchronous)

Re: Ortonview PCB
 

I’ve been looking at the output of the clocked serial and the clock output. At the start of each line, when the synchronous tx is initialised, the clock output is driven low and the tx output is driven high. There is then a short delay where tx is high and clock stays low, which causes the white band down the left edge of the screen. The clock then starts clocking out the data on the rising edge of each clock cycle.

It might be possible to register the tx output to eliminate the white band. We would want to register the tx output on the falling edge of each clock cycle.

Looking at the spec for the PIC it doesn’t seem to be possible to change the clock polarity or phase in the synchronous Tx mode that is used by ortonview.

Unfortunately the common 74x74 D type flip flop registers data on the rising edge of each clock. We can invert the clock, and this can be done with one half of the 74x74, but this then delays the rising edge at the input of the D type and would capture the unwanted high tx level at the start of the line and we would still see the white band.

We can avoid registering the unwanted tx high level by adding an RC delay. This would need to be longer than the propagation delay of the inverter but less than the width of the clock pulses. I think this is just about possible.

This is going to shift the display image half a pixel to the right, but it should be a fixed offset and would probably not be noticed.

One thing I’m not sure about is what happens when the tx clock output pin is used to read the state of P4. If it clocks the flip flop it could leave a horizontal bar on the display until the next tx clock. I tried linking P4 to ground but didn’t see any difference on the tx clock output.

I may just give it a try and see if it works.

Re: Ortonview PCB
 

Update: I received a PIC16F887 today, and I made changes to the firmware #692 to support the new config bits on the new chip (it has 2 config registers rather than 1). after generating a Hex file I programmed it onto the chip and plugged it into my Ortonview, but it did not work. The display on the MK14s LED was all over the place so I swiftly switched it off, but I don't think anything came out on the TV either. Clearly there need to be some changes made to the initialisation to make it work. I didn't proceed because its getting late and I'm tired, but will give it another look tomorrow. I may need to look through the documentation, possibly look for a porting guide from the '877 to 887.

Re: Ortonview PCB
 

I'm still not back at base but I will have a look at this as well some time next week.

Re: Ortonview PCB
 

Just had a very short look - one thing I notice is that bits 0-7 of Port A and bits 0-5 of Port B are analogue inputs by default. This is not a function of the configuration bits but is controlled / set by two of the special function registers, ANSEL and ANSELH.

These registers have their Analogue input enable bits set to '1' - 'enabled' - at reset.

For any other use of the pin, ie, digital I/O, the corresponding ANSEL and ANSELH bits need to be set to '0' very early on during initialisation.

This is contrary to the behaviour we would usually expect, where special pin functions are normally turned off until you explicitly turn them on.

The PIC16F690 also has this quirk - I used those quite a lot at one point because that was the device which came in the demo PCB which came with the PICKIT2 so I made a whole string of projects using that chip.

Note I have not yet tried this, nor do I know whether Slothie already realised this as I have not yet seen his version of the code converted for 16F887.

Re: Ortonview PCB
 

I've just dug out what may have been the first ever bit of code I wrote to run on the 16F887 - it's a simple running light display - in this case a knight-rider style swept light display. It's 'C' code but you can see that one of the few things I did in the pinit() chip setup function was to turn off the analogue inputs by writing to ANSEL and ANSELH. I also turned off the comparators but I don't think that was necessary. I think the configuration bits in this code also set the clock pins on the chip to be general I/O and to use the chip's internal 4MHz clock, which of course we do not do on OrtonView because we need a 16MHz clock.

Re: Ortonview PCB
 

Thanks for that, it might save me some time. I seem to recall having to do something similar when migrating from an old pic to a new one that had added some analog functionality and was enabled by default. I'm going to be giving this another look in the next couple of days!

Re: Ortonview PCB
 

Attached is sketch of a circuit to remove the white bar down the left side of the display. Limited testing so far but it seems to be working.

There are a couple of minor issues.

1). when inverse mode is set there is a black bar down the left side, though this is less noticable than a white bar in normal mode.

2). when inverse mode and graphics set together the left edge is not a straight edge, there is an extra block of white half character high by half character wide at the left edge of the display at the top and bottom of the screen. This is due to the first and last lines using twice the clock rate of graphics mode.

I haven't tried mixed character and graphics modes yet.

Re: Ortonview PCB
 

I'm wondering if Slothie has been able to make progress with getting the code to run in an 887, the device the code was originally meant to run in. If so we could use the extra pin freed up to provide a blanking control signal spanning the UART initialisation phase only when the screen half being rendered is in normal (not inverse) mode.

I still haven't built your NENIN timing fix - the parts are in front of me here but it has been difficult to find time to build it here.

Incidentally we are rapidly approaching OrtonView's first birthday, much credit to Mark for having come up with both the initial 'dirty' capacitor fix and recently the more elegant circuit fix, and to Slothie for having produced a nice PCB, both within that first year. I think for Karen the worst that could have happened is that we would all have lost interest in it by now. That certainly isn't happening.