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)

Slothie 14th Sep 2021 7:51 pm

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.

Mark1960 14th Sep 2021 8:52 pm

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.

Slothie 14th Sep 2021 9:44 pm

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?

Mark1960 14th Sep 2021 10:14 pm

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.

Slothie 14th Sep 2021 10:35 pm

Re: Ortonview PCB
 
Quote:

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

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

Mark1960 14th Sep 2021 11:34 pm

Re: Ortonview PCB
 
Maybe just try decoupling caps first.

Slothie 15th Sep 2021 8:53 am

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

SiriusHardware 15th Sep 2021 9:20 am

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.

Mark1960 15th Sep 2021 8:41 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1388429)
The white band is an unavoidable by-product from when the UART wakes up, it happens to produce white level at that point and it takes a finite amount of time to then turn the state of the output to the other (black) level under program control.

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?

Slothie 15th Sep 2021 8:52 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1406965)
Quote:

Originally Posted by SiriusHardware (Post 1388429)
The white band is an unavoidable by-product from when the UART wakes up, it happens to produce white level at that point and it takes a finite amount of time to then turn the state of the output to the other (black) level under program control.

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?

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

Mark1960 15th Sep 2021 10:27 pm

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.

Slothie 15th Sep 2021 10:40 pm

Re: Ortonview PCB
 
Quote:

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

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)

Mark1960 17th Sep 2021 10:30 pm

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.

Slothie 18th Sep 2021 8:05 pm

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.

SiriusHardware 19th Sep 2021 1:27 am

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

SiriusHardware 20th Sep 2021 5:50 pm

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.

SiriusHardware 20th Sep 2021 6:09 pm

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.

Code:

// For PIC16F887

#include <htc.h>

__CONFIG (INTIO & MCLRDIS & WDTDIS & UNPROTECT & PWRTDIS & BORDIS & DEBUGDIS & LVPDIS & FCMDIS & IESODIS);

// Define functions used in this program
void pinit (void);                //Initialise chip
void delay (void);                //Delay

void main (void)

{
unsigned int x;
unsigned char z = 0;

pinit();  // Call the chip setup function

while (1)
        {
        PORTD = 0x80;
        delay();
        PORTD = 0x40;
        delay();
        PORTD = 0x20;
        delay();
        PORTD = 0x10;
        delay();
        PORTD = 0x08;
        delay();
        PORTD = 0x04;
        delay();
        PORTD = 0x02;
        delay();
        PORTD = 0x01;
        delay();

        PORTD = 0x02;
        delay();
        PORTD = 0x04;
        delay();
        PORTD = 0x08;
        delay();
        PORTD = 0x10;
        delay();
        PORTD = 0x20;
        delay();
        PORTD = 0x40;
        delay();
        }
}

void pinit (void)
        {

//        Analogue functions off
        ADON = 0;
        ANSEL = 0b00000000;
        ANSELH = 0b00000000;

//        Comparator functions off
        C1ON = 0;
        C1OE = 0;
        C2ON = 0;
        C2OE = 0;
       
        ULPWUE = 0;       

        TRISA = 0b11111111;
        TRISB = 0b00000000;
        TRISC = 0b00000000;
        TRISD = 0b00000000;
        TRISE = 0b00000000;
 
        }

void delay (void)
        {
        unsigned int x;
        for (x=0; x < 7000 ; x++);
        }


Slothie 20th Sep 2021 8:02 pm

Re: Ortonview PCB
 
Quote:

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

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!

Mark1960 1st Oct 2021 12:48 am

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

SiriusHardware 1st Oct 2021 8:25 am

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.

Slothie 1st Oct 2021 5:54 pm

Re: Ortonview PCB
 
Quote:

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

In short, yes but no.

I have made progress, in that I have determined that there are a couple of registers needing clearing before the Ortonview will do anything, but now it seems very unstable. It seems to run sometimes then not at others. If you tap the board, especially in the vicinity of the crystal, it works for a short while except the vertical sync seems to be all over the place. This is with the Ortonview not connected to the MK14.
I think there might be more work required to get the configuration fuses working properly, perhaps the oscillator is not starting properly. Its been a long while since I've played seriously with PICs and its taking time to get up to speed with all the intricacies of them.

I do recall that at one point Karen decided to move functions from one port to another, I don't recall why but that also might be an issue.

I have had a week or so off from the project due to other things but I'll get down to testing it again this weekend, I think I need to check the config settings bit by bit.

If anyone wants to look at where I am at the moment its at https://bitbucket.org/IanKRolfe/orto...src/PIC16F887/

(Note: The HEX file in the repository is not the HEX file generated from the latest source, MPLAB squirrels that away somewhere else. I believe the HEX file in the repository is the "vanilla" pic 877 #692 version, so ignore that.

Mark1960 1st Oct 2021 7:11 pm

Re: Ortonview PCB
 
I’ve been thinking about the issue with the 877A in graphics mode and re-reading the original thread. If I understand correctly the first working code did not have the issue, but then after Karen improved the time available to the 8060 the graphics mode showed the issue. I don’t have any 877A or 887 yet, they are still on my shopping list, but if I read the thread correctly the issue is the shifting of the display by one character pixel left and right in alternate frames. I’m thinking this might have been introduced by an optimisation of the timing of sync signals that Karen might have made, considering she was always quite particular to achieving perfection. Anyway I’m wondering if the graphics mode issue is caused by an odd number of cycles between frames causing an issue with sync of the tx clock in graphics mode with the 877A. I’m assuming here that the 877 resets the prescaler on init of the clocked serial and the 877A does not. I would suggest either adding or removing a single instruction cycle from the vertical synch to see what effect that has, it should still be acceptable synch timing for a tv.

Mark1960 1st Oct 2021 7:19 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1411008)
I do recall that at one point Karen decided to move functions from one port to another, I don't recall why but that also might be an issue.

This was when she made the change from using 887 to 877. Was it for ttl compatibility of the 877 inputs on the mk14 data bus?

SiriusHardware 1st Oct 2021 8:41 pm

Re: Ortonview PCB
 
Yes, I think there was a particular 877 port she wanted to use for the databus hence a very late change to the assignment of ports. It coincided with her decision to use the 877 instead of the 887, so, worst case scenario, there may be reason to change it back to the original wiring but still take into account that one of the page select pins also has to operate in a dual mode.

Another possibility is to (reluctantly) change to the PLCC packaged version of the 877 / 877A because that gets you a couple of extra port pins - but they can only realistically be used on a PCB, trying to hand-build without a PCB or at least a pin breakout board would be tedious in the extreme.

I do have some '44 pin PIC Demo' PCBs of the type which originally came with the Pickit 3 - we bought a number of those at work but we only really needed the programmers so the boards were up for grabs so I grabbed them. They typically came with PIC16F877 (QFP) versions fitted although they will accept QFP versions of the PIC16F877A, PIC16F887, PIC18F452 etc - but they are fine pitch devices which have to be soldered, of course.

SiriusHardware 1st Oct 2021 9:15 pm

Re: Ortonview PCB
 
Regarding the apparent sensitivity around the crystal area when using the 887, I'm sure the crystal 'type' in the configuration setup needs to be 'HS' rather than 'XT' and I recall when first messing about with the 887 that I had to disable the Low Voltage Programming option (LVPDIS in the 'C' source I posted earlier) because otherwise signals and states applied to the programming pins may try to put the chip into program mode. Of course disabling Low Voltage Programming is not helpful if you only have a low-voltage programmer rather than a PicKit2/3, ICD2 or ICD3 etc.

Slothie 2nd Oct 2021 10:02 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1411053)
Regarding the apparent sensitivity around the crystal area when using the 887, I'm sure the crystal 'type' in the configuration setup needs to be 'HS' rather than 'XT' and I recall when first messing about with the 887 that I had to disable the Low Voltage Programming option (LVPDIS in the 'C' source I posted earlier) because otherwise signals and states applied to the programming pins may try to put the chip into program mode. Of course disabling Low Voltage Programming is not helpful if you only have a low-voltage programmer rather than a PicKit2/3, ICD2 or ICD3 etc.

That might have something to do with it, I set the LVP fuse because I had put a programming header on the board, although the reset pin is not being used in Karens design so LVP should still work. I could disable it because I "splashed out" on a cheap PICKIT 3 clone that nonetheless seems to work fine
.
I did set the crystal type to HS (or at least, I set them intending that to happen, its always possible I got it wrong, I used the configuration editor on MPLAB and set the config values in the source to match. I should probably use the defined symbols to build up the config values "properly".

Phil__G 23rd Oct 2021 10:11 am

Re: Ortonview PCB
 
1 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1411053)
Regarding the apparent sensitivity around the crystal area when using the 887, I'm sure the crystal 'type' in the configuration setup needs to be 'HS' rather than 'XT'

thats right, HS for a 16Mhz crystal. I always set the config word in the source rather than specifying it when programming, one less thing for me to forget...

Slothie 23rd Oct 2021 10:28 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Phil__G (Post 1416717)
Quote:

Originally Posted by SiriusHardware (Post 1411053)
Regarding the apparent sensitivity around the crystal area when using the 887, I'm sure the crystal 'type' in the configuration setup needs to be 'HS' rather than 'XT'

thats right, HS for a 16Mhz crystal. I always set the config word in the source rather than specifying it when programming, one less thing for me to forget...

Yes, I've been playing with it and managed to get it stable by configuring it thus:
Code:

CFG1        EQU _DEBUG_OFF & _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOREN_OFF & _CPD_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_OFF & _WDTE_OFF & _FOSC_HS
CFG2        EQU _BOR40V & _WRT_OFF

        __CONFIG _CONFIG1,        CFG1
        __CONFIG _CONFIG2,        CFG2

And initialise the peripherals:
Code:

        ORG        0
        ;+changes for '887
        CLRF        ADCON0                ;Not sure these    3 strictly necessary after reset...
        CLRF        CM1CON0
        CLRF        CM2CON0
        CLRF        ANSEL                ;Disable analogue ports
        CLRF        ANSELH
        ;-changes for '887
        MOVLW        B'00010000'        ; NRDS pullup others free

And when not connected to the MK14 this is stable, but does not appear to be accessing the "expansion" memory properly, and touching the data lines does not cause random characters as it does with the 877. I need to hook it up to my logic analyser and see if the various signals are OK, its possible there are other things that need initialising.
When I've checked this out and the signals seem plausible I will try connecting it up to the MK14 again.

SiriusHardware 29th Nov 2021 10:57 am

Re: Ortonview PCB
 
Running parallel to Slothie's (possibly) continuing efforts on the software side, I am finally getting my lardy **** into gear and making up Mark's little 74HCT74 patch for the 'occasional RAM corruption' problem. Should be 'installed' by the end of the week with any luck.

Slothie 29th Nov 2021 11:29 am

Re: Ortonview PCB
 
I've kind of dropped the ball on this one as well for the last few weeks, I've lost track of where I put my logic analyser module (its somewhere "safe") and I need to find the time to do a search......

SiriusHardware 29th Nov 2021 6:20 pm

Re: Ortonview PCB
 
A question for Mark or for Slothie who has already added this patch - can you confirm that the insertion point for the patch is between the 877 pin 7 and D4 anode, or to be precise

- Cut the connection between [877 pin 7] and [D4 anode / redundant U1D buffer enable gate]
- Connect from 877 pin 7 to 74HCT74 pin 12
- Connect from 74HCT74 pin 9 to D4 anode / redundant buffer enable gate.

The following connections obviously also have to be picked up

+5V power and 0V

CLK OUT (actually clock in, from the MK14)

NADS

Slothie 29th Nov 2021 9:44 pm

Re: Ortonview PCB
 
1 Attachment(s)
I found this in my notebook, if its any help, it shows the 74HCT74 from underneath.

Mark1960 29th Nov 2021 9:45 pm

Re: Ortonview PCB
 
3 Attachment(s)
Hi Sirius

Attached pictures of my mod, hope I didn't reduce the resolution too far, pin 7 cut before it reaches the via, I used this location so I was clear of other traces in case I slipped, also seemed like a good place to repair the cut if I needed to later.

Pin numbers on the 74HCT74 might be different.

Try not to be confused by the additional circuit, this was to remove the white bar down the let edge, but the wire lengths introduce noise in the video output.

Are you trying the first or second version of the mod? I think the second one is better as it should also work with the standard crystal.

Mark

Mark1960 29th Nov 2021 9:55 pm

Re: Ortonview PCB
 
1 Attachment(s)
Just realised I cropped the view of the back of the mod to miss the 74hct74 for delay in NADS.

SiriusHardware 29th Nov 2021 10:36 pm

Re: Ortonview PCB
 
Quote:

Are you trying the first or second version of the mod?
The second, in which you involved NADS. It made better sense to evaluate that version of the mod, bearing in mind that we are trying to advance this to the point where it always works for everyone, every time, so it needs to be MK14 clock-frequency agnostic.

I had considered cutting / drilling the tracks going to one of the noise generator IC pad positions and placing the IC there but I suspected Slothie might be inconsolable if I did that, so I've built mine on the shiny side of a small square piece of stripboard which I can stick down on any conveniently bare part of the PCB. I've used the circuit and IC pin numbers as drawn in your drawing of #488.

SiriusHardware 29th Nov 2021 10:43 pm

Re: Ortonview PCB
 
I'm not aiming to include the white line blanking mod at the moment - one baby step at a time.

Mark1960 30th Nov 2021 12:35 am

Re: Ortonview PCB
 
You are trying the circuit from #488 and not the earlier #466?

Just want to make sure we are talking about the same circuit.

Mark1960 30th Nov 2021 1:10 am

Re: Ortonview PCB
 
If I want to try the PIC16F877A instead of PIC16F877, do I need a different build of firmware or can I use the same firmware as the PIC16F877?

I have a couple of 877A and 887 now, so interested in duplicating the graphics mode issue with the 877A. I’ll wait for Slothie before I try the 887.

SiriusHardware 30th Nov 2021 8:03 am

Re: Ortonview PCB
 
Quote:

You are trying the circuit from #488 and not the earlier #466?
Indeed yes. Unfortunately I manage to leave my OV and the little '74 board on the hall shelf as I left home this morning.

There is no specific 'fork' of the firmware for 877A, we made a decision along with Karen just to declare that the project only worked with the 877 and not the 877A. Trying to fix that problem was taking up far too much of the little time and energy she had left.

If you put the same firmware in an 877A it will work almost normally but in graphics mode the whole image appears to jump from side to side by about a pixel width on every successive frame. One reason for trying to get the code to run in an 887 is to see whether this problem is also present when that chip is used.

Slothie 30th Nov 2021 10:50 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1428587)
I had considered cutting / drilling the tracks going to one of the noise generator IC pad positions and placing the IC there but I suspected Slothie might be inconsolable if I did that, so I've built mine on the shiny side of a small square piece of stripboard which I can stick down on any conveniently bare part of the PCB. I've used the circuit and IC pin numbers as drawn in your drawing of #488.

It occurred to me just the other day I haven't even tried the noise generator, or fixed the battery backup.... I really have the attention span of a goldfish. However I did want to be able to try it out so I decided to glue the 7474 upside down to the PCB and "dead bug" wire it. I didn't do the white line version of the mod because I wanted to try the simplest one first, and the white line actually doesn't bother me too much and I think Mark implied it was a work in progress at the time.

When the time comes of course it will be on the PCB, as there will be plenty of room without the buffers which have proved unnecessary. I'd like to see if there are any changes required to get the 887 working first even though that is unlikely.

I really must get my mojo going on this one!

SiriusHardware 30th Nov 2021 11:47 am

Re: Ortonview PCB
 
The battery backup and the noise generator are not original core features of the VDU so I would not consider those to be a priority - neither is the extra-extra RAM an original VDU feature of course but I think we can all agree that it should have been, and that it is needed for the VDU to be able to be used in any serious way.

The RAM has been shown to work well by Timbucus and, eventually, myself, in spite of my initially trying to get it to work without any +5V supply worth speaking of.

The main thing to get out of the way was this occasional tendency by OrtonView to corrupt memory and I hope to confirm that Mark's '74 mod is completely effective in this respect.

The vertical white line is undesirable and not easy for people using flat panel displays to eliminate, so I would like to see that go but I think the best way to do that is have the firmware generate a hardware blanking signal to 'smother' the bright line only when the screen half being rendered is in 'normal' (not inverse) mode. To do that, we really need to find another I/O pin from somewhere, either by using a 40-pin device where more pins can be defined as I/O pins (=887) or by using a 44-pin (PLCC or QFP) version of any of that family, all of which which have two or three more port pins available in those packages.

Slothie 30th Nov 2021 12:22 pm

Re: Ortonview PCB
 
I did some extensive testing with Marks mod #488 and failed to uncover any memory corruption, although any confirmation is naturally a good thing as different people have different approaches. It occured to me that getting rid of the white line could be as easy as using a monostable to gate the video signal, triggered by the sync pulse. I think Marks approach uses a latch to do much the same, but tbh I didn't spend much time looking at it. I agree however for any "final" design something needs to be done about it other than my "somebody else's problem" approach!
I think the 887 can have the MCLR pin redefined as an input pin, so we could use that instead of one of the other inputs and repurpose the other input as the blanking output. I'd prefer to avoid using a PLCC/QFP package, if only because it looks wrong for a computer of this vintage and there's also the soldering problem for people like myself with poor eyesight!

SiriusHardware 30th Nov 2021 12:52 pm

Re: Ortonview PCB
 
The simplest 'monostable triggered by sync' approach falls down when the screen is inverted (black on white) either for the whole screen or for only the upper half or only the lower half, as it then becomes necessary for the bright line blanking circuit (BLBC) to 'know' whether the video signal state between sync and 'bright line' was white or black, and to take that into account when deciding whether to clamp the video level to black during the 'bright line' period.

To be honest a small 8-pin PIC like a 12F508 or a 12F629/12F675 would be as good as anything for this purpose, but the more programmed devices there are on a project the less appealing it becomes to any prospective builder - although in this case both PICs could most likely be programmed by the same PIC programmer.

SiriusHardware 30th Nov 2021 2:21 pm

Re: Ortonview PCB
 
Quote:

I'd prefer to avoid using a PLCC/QFP package
I am still just about dexterous enough and my eyesight OK enough to be able to solder QFP ICs although some of the modern ones we use have even finer pin pitch than the PICs and they are right on the limit of what I can now see and handle so I have some sympathy with your view.

44-pin PLCC sockets are still available in through-hole pin variants as well as SMD, these ones have the pins broken out into an inner and outer row spaced at 0.1" apart so you could almost use one in stripboard if you are a dab hand at track cutting.

https://uk.farnell.com/multicomp/mc-...ole/dp/2097214

If you can solder conventional IC pins 0.1" apart, you can solder these sockets into a PCB.

SiriusHardware 30th Nov 2021 2:30 pm

Re: Ortonview PCB
 
Quote:

any confirmation is naturally a good thing as different people have different approaches
This has worked for us over and over again, for example it was me that initially reported the 877A graphics problem - I only had an 877A at the time, Tim couldn't see it as he happened to be using an 877 - luckily Tim had both types and it was Tim who discovered that it was an 877A-only problem, whereas to me it looked like an overall problem which had been introduced with a firmware change.

The more people we have testing in parallel using slightly diverse systems and resources, the better.

Mark1960 30th Nov 2021 5:33 pm

Re: Ortonview PCB
 
Did the first version that hogged too much time from the 8060 have the graphics problem with the 877A? I was wondering if adding a single extra NOP to the PIC code during frame blanking would help. Just thinking the prescaler for the serial output might be cleared on the 877 each time the serial output is initialised, while the 877A might not clear the prescaler. This would possibly give a half bit offset on the video out if there are an odd number of cycles between start of horizontal data between frames. Hopefully a single extra NOP would not stop the tv from synching to the video correctly.

SiriusHardware 30th Nov 2021 5:49 pm

Re: Ortonview PCB
 
No, the initial version worked fine on the 877A in both graphics mode and character mode but it stole so much time from the SC/MP by keeping NENIN constantly asserted that the system ran at the speed of mud, to the point where the scanning of the 7-segment displays was very uneven and lopsided.

The current version which asserts NENIN for far less time overall actually spends slightly less time stopping the system than a real SOC VDU does, so the speed improvement is huge, but it does have that unfortunate side effect of breaking the operation of graphics mode on the 877A only.

SiriusHardware 1st Dec 2021 11:04 am

Re: Ortonview PCB
 
1 Attachment(s)
Almost ready for takeoff : Mark's patch of #488 now in place. Looking at this photo made me realise I still hadn't removed the 'dirty fix' capacitors on A8-A11, but I have since removed them.

SiriusHardware 19th Jan 2022 8:34 pm

Re: Ortonview PCB
 
Well, that was a long 24 hours. Right after the last post I fell rather ill for a few days (nothing life altering, but very unpleasant at the time) and then all of a sudden Christmas was looming and I had very little time to do anything else.

A month and a half on...(!) I have now been able to fire up my Ortonview with Mark's 74HCT74 fix for the occasional memory corruption problem, as per post #488 of this thread, fitted. So far, so good.

I've had modified versions of CHARSET writing continually to locations within standard RAM (0F00-0FFF), optional RAM (0B00-0BFF) and various pages in the extra-extra RAM (0200-07FF) while 'watching' the standard RAM and the optional RAM on the Ortonview display. I am pleased to say that I have not been able to cause any unwanted memory writes throughout any of the testing. So well done Mark, excellent job.

That's two of us, me and Slothie, who have 'proven' this mod, I don't know where Tim and Mark are with this but maybe they could also repeat this exercise and if it works equally well for them as well maybe we can then say for sure that this is a reliable, official mod which can be committed to PCB.

After that, there is the question of solving the bright line problem.

Last we heard Slothie was trying to squeeze an 887 under the bonnet of Ortonview, I'm assuming that process is currently either parked or moving slowly. Apart from the wider availability of that IC and the hope that it might accidentally fix the graphics blur problem found only on the 877A, that IC also presents the possibility of one more I/O pin which could be used to blank out the bright line in a controlled fashion.

I might try rigging up a small (8 pin?) PIC to detect the rising edge of sync, then detect the state of the video signal (black, or white) shortly after that, and if (and only if) the sampled video line state was black, clamp the video line state at black until after the falling edge of the 'bright line' has passed.

Timbucus 19th Jan 2022 9:27 pm

Re: Ortonview PCB
 
That is good news - like you I was busy with family issues, fell ill, had Christmas and then its now and I am rebuilding my PC with a growing project backlog brought on by e-bay browsing while under the weather :)

I will go and order a 74HCT74 as I do not have one (many others of course...) so I can add weight to the evidence. I assume we remove the capacitor "fix"?


All times are GMT. The time now is 4:14 am.

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