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


All times are GMT. The time now is 4:43 pm.

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