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 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 10:53 am.

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