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)

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"?

SiriusHardware 19th Jan 2022 10:09 pm

Re: Ortonview PCB
 
Indeed yes, we wave goodbye to the cap fix. I've had it running for something like five hours now without a single bit of corruption of any memory that is not being intentionally written to. I built mine on a stamp sized bit of stripboard placed copper up, but you could place the '74 in the position intended for U5 or U6, cut any unwanted PCB track connections to the pads and wire the mod up there.

On any subsequent revision of the PCB the buffers can be removed and the '74 placed where they were, leaving the U5 and U6 (noise generator) circuitry intact.

Mark1960 19th Jan 2022 10:56 pm

Re: Ortonview PCB
 
I am fairly certain that a 74ls74 would also work in the memory corruption fix, as its not dependent on RC delays.

The 74HCT74 fix for the white line seems to work, except for inverse graphics mode, but I don’t think thats a very usefull mode anyway. I think my wiring to a piece of proto board was too long which introduces noise in the video, but that would probably be ok if it was included in the layout.

I was wanting to try the 877A to see the issue, then maybe try adding a single NOP, but been too busy with work and travel over the holidays. Also spent too much time on an idea for a ttl processor, using 74AS870 for registers before realising that its not quite dual port registers and decided it wasn’t going to give a usefull ISA without serious workaround in the register addressing. I managed to find time to assemble one of Phil’s PICL boards, but still not programmed the 877 and tested it yet.

SiriusHardware 20th Jan 2022 12:06 am

Re: Ortonview PCB
 
I agree that inverse (black text on white or black pixels on overall white) is not especially attractive but Karen went to a lot of trouble, in her final days, to emulate that and the other features of the SOC VDU exactly so I think it really has to work as advertised.

If you can somehow make your 74 based white line remover 'case-sensitive' so that it only acts when there is black (not white) immediately following the sync pulse on any given line, that would be great.

It's interesting that all of the original 'classic' ZX computers actually favoured black text on white and I think that was because they were expected to be used on low resolution TV displays (rather than monitors) where spindly white text on a black background might have been a lot harder to read.

Mark1960 20th Jan 2022 7:27 am

Re: Ortonview PCB
 
It might be possible to drive the preset input of the 74HCT74 using a delayed PIC-24 input, inverted and combined with the PIC.26 using a nand gate. This would be relying on the race condition between preset and reset of the 74HCT74, really bad design practice but that makes it more fun.

It also adds more gates, which kind of spoils it.

I’ll keep thinking, probably won’t be able to stop thinking about this now until I think of a neat way to do it.

SiriusHardware 20th Jan 2022 9:45 am

Re: Ortonview PCB
 
I don't know if it helps to remember that inverse mode doesn't actually need fixing because when any given line is being rendered in inverse, the bright line just blends into the overall white background.

It's only when a line is being rendered in non-inverse / normal mode that it requires some kind of active solution.

Slothie 20th Jan 2022 1:37 pm

Re: Ortonview PCB
 
Quote:

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

Yes, sorry about that my cancer reared its head again and I've been busy having tests etc. Not serious, just time consuming. I have looked at it somewhat, I can get it to produce a stable screen, its just not reading the memory for some reason, and locking up the MK14, so I probably have some more config changes to make. I'll be starting treatment soon so will have plenty of time to get out my logic analyser!

SiriusHardware 20th Jan 2022 1:59 pm

Re: Ortonview PCB
 
Sorry to hear you are in the wars again. Obviously you should be looking after yourself first and worrying about this later.

I wonder if there would be some mileage in knocking up an 887-->877 pinout adaptor to reverse that port swap which Karen did ultra-last-minute when she realised that her programmer didn't 'do' the 887. She must have had a very good reason to feel she needed to do that.

Just to recap, although the 877 and the 887 ostensibly have the same pinout, Karen altered her design and code to swap two of the 8-bit ports over when she went from what was going to be the 887 originally, to the 877.

If we have ambitions to use the 887 instead, it may be necessary to swap those ports back over (and change the code accordingly).

Slothie 20th Jan 2022 2:21 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1442331)
Sorry to hear you are in the wars again. Obviously you should be looking after yourself first and worrying about this later.

I wonder if there would be some mileage in knocking up an 887-->877 pinout adaptor to reverse that port swap which Karen did ultra-last-minute when she realised that her programmer didn't 'do' the 887. She must have had a very good reason to feel she needed to do that.

Just to recap, although the 877 and the 887 ostensibly have the same pinout, Karen altered her design and code to swap two of the 8-bit ports over when she went from what was going to be the 887 originally, to the 877.

If we have ambitions to use the 887 instead, it may be necessary to swap those ports back over (and change the code accordingly).

Yes, I was wondering about that. If the 887 works then there'd really be no reason to use the 877/877A so a new PCB layout wouldn't be a problem. I'll look into it as see if I can work out what Karen's thinking was; unfortunately she was a lot more knowledgeable about PICs than me :)

SiriusHardware 20th Jan 2022 5:13 pm

Re: Ortonview PCB
 
Here's the turning point from the original VDU thread:

Quote:

Originally Posted by Karen_O
I will revert to using the PIC16F877 but I need to make two hardware changes: I must swap ports B and D so that the data bus uses the TTL compatible B port.

Really, the '887 only gives me one extra bit of I/O - the /MCLR pin is also port RE3 on the '887. On the '876 it is a straightforward master clear pin.

RE3 is used to sense PS4, so an input. Cunning plan: I use the serial port for video generation, but is only enabled on those scan lines that display text or graphics. During the frame blanking, when the PS4 state needs to be examined, the serial port is switched off. I can arrange that the clock output pin (RC6) is an input at this time and use this to sense PS4. I will couple through a resistor so that, when the serial port is enabled, the 2/4MHz coming out of RC6 doesn't try to drive PS4.

Now the question is, what architectural improvements or changes had been made by the time the 887 came along? Are all of the 887 ports TTL compatible? It would seem odd for Microchip to maintain the overall pinout and yet move the only TTL compatible port from port B on the 877 to port D on the 887 - port D being the 887 port which Karen had originally planned to use as the data bus. She may just have chosen 887 port D as 'D for Data', a handy mnemonic reminder of the port's purpose.

SiriusHardware 20th Jan 2022 5:44 pm

Re: Ortonview PCB
 
I've just had eyeballs on both datasheets and it looks as though the port D pins on the 877 are Schmitt Trigger in input mode, whereas the port D pins on the 887 are TTL in, as are the port B pins. So - it may not be necessary to swap the ports back, unless I've missed something (highly likely).


All times are GMT. The time now is 6:37 am.

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