Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

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:

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

Ah, we have a saying here on Tyneside: "Shy Bairns Get Nowt". ;)

Re: Ortonview PCB
 

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.

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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

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.

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.