UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (
-   Vintage Computers (
-   -   Ortonview PCB (

Slothie 5th Aug 2021 7:54 pm

Re: Ortonview PCB
Interesting, 300nS memory is too slow? I suppose if the pic is setting the address and then reading the data with the next instruction then thats 250nS. Still doesn't explain why it sent the MK14 mad given the delays before/after asserting NENIN.

SiriusHardware 5th Aug 2021 7:57 pm

Re: Ortonview PCB
The thing is, the 6116-3 is not 300nS (as you would reasonably expect)... it's 150nS. Like yours.

SiriusHardware 5th Aug 2021 8:12 pm

Re: Ortonview PCB
Incidentally I'm not getting any noise / unwanted flicker at all on the MK14 displays now that the RAM problem is sorted - but I do have R3 (NWDS pullup resistor)= 4K7, not 10K.

SiriusHardware 6th Aug 2021 4:02 pm

Re: Ortonview PCB
After last night's setback and then recovery from the Hitachi ram induced problems, the PCB is looking a little bit tidier now thanks to Tim's kind contribution of a Cliff-type RCA socket. I've also fitted turned pin socket strips which make it easy to fit and remove the A8-A11 capacitors.

Today's experiment was to revert the PCB back to buffered configuration and no capacitors on A8-A11, this time with the known good EL6116LP-10 RAM fitted and with 1K / 3.3nF in the buffer enable delay RC circuit.

Results are somewhat better than Slothie's original attempt with no buffer enable delay at all, which with hindsight wasn't likely to work well.

With the setup just described operation of the MK14 is normal with a rock steady 'ready prompt, and with the VDU pointed at 0x200-03FF I can edit addresses in that range and see the characters representing those addresses changing.

Unfortunately it's not quite there yet: Just sitting at the ready prompt I can see perhaps 5-6 of the characters in the 0300-> address range continually whizzing around, being changed at a high rate when they should be static. Also when I'm typing codes into successive addresses in the 0200-> range I see characters several bytes ahead of the ones I am typing into occasionally changing.

If I can find a pot or preset I may try winding the resistance of the R up and down to see what effect that has going higher and lower than 1K, the current fixed value.

Slothie 6th Aug 2021 4:10 pm

Re: Ortonview PCB
If anything is going to help I would imagine it will be increasing the value of R but this is encouraging news. I wish I understood precisely the mechanics of the problem...

SiriusHardware 6th Aug 2021 4:19 pm

Re: Ortonview PCB
I'll try to find a 2K2 or 4K7 pot or preset. Make the delay too long and the buffers still won't be enabled at the point where the PIC tries to place the address on the system address bus.

Are you going to have a go at this as well? It always helps to have a range of feedback on which values work and which values don't.

SiriusHardware 6th Aug 2021 4:37 pm

Re: Ortonview PCB
Just quickly tried it with a 10K preset initially set to 1K and then going up and down in value.

Going upwards, the effects on the screen don't alter until a certain threshold when the whole screen content starts to ripple / change and I would guess that is the point where the buffers no longer turn on in time for the VDU address to pass through to the system bus when needed.

Going downwards in R value from 1K nothing changes until the system suddenly crashes and won't run properly even after reset unless the resistance is increased a bit first. I would guess that this lower threshold is where the SC/MP still has not relinquished the buses and ends up clashing with the enabled buffer outputs which will be outputting a '1' if the PIC pins are still inputs at that point.

SiriusHardware 6th Aug 2021 4:49 pm

Re: Ortonview PCB
I should clarify that between the two thresholds described in #227, the unwanted behaviour, several characters in the 0300-> range and one in the 0200-> range rapidly changing, continues in the same way. The speed / frequency of change and number of characters affected does not change as I wind the resistance between the two thresholds.

Slothie 6th Aug 2021 5:07 pm

Re: Ortonview PCB

Originally Posted by SiriusHardware (Post 1396113)
I'll try to find a 2K2 or 4K7 pot or preset. Make the delay too long and the buffers still won't be enabled at the point where the PIC tries to place the address on the system address bus.

Are you going to have a go at this as well? It always helps to have a range of feedback on which values work and which values don't.

I will do, recently I have been spending time looking at the code to try and see how the various timings work (without much progress so far) and writing some SC/MP test programs too. I seem to have forgotten a load about writing assembler :)

I'm going to see about cutting the tracks to the buffer enables, since they are no use as they are anyway, and see what playing with the RC values does. I might also see if I can think up some scheme to delay NENIN if NWDS is active.

SiriusHardware 6th Aug 2021 5:10 pm

Re: Ortonview PCB
With the R and C back to 1K / 3.3nF which places the timing value between the thresholds mentioned above, I tried other things.

1) Swap the two buffers over. No change, the locations which are cycling are the same ones.

2) Swap the EL6116LP-10 for another one that I have here. I still have characters flickering but they are different characters (different locations).

With either of the two EL6116LP-10s in, the start-up content of the RAM is specific to each of the chips, each bit in each chip appears to have a preferred start up value which it nearly always reverts to but this pattern is different in RAM (1) and RAM (2). The locations which flicker/change are also diffferent between chips but consistent on a per-chip basis. (Every time I start it up with a particular 6116 fitted, it's always the same locations which flicker in that chip).

SiriusHardware 6th Aug 2021 5:17 pm

Re: Ortonview PCB

delay NENIN if NWDS is active.
This all ties into the timing which generates video lines though doesn't it - the PIC has to have priority access to the RAM and it needs the screen data exactly when it needs it at precisely timed intervals. Holding off asserting NENIN will most likely cause tearing / jitter on the video lines.

SiriusHardware 6th Aug 2021 6:19 pm

Re: Ortonview PCB
Two further bits of info: - I thought the changing characters might be a side effect of the action of the OS code running where, if you have the VDU pointed at 0F00-> you can always see some characters constantly changing.


- Hold down the reset button to stop all SC/MP activity.


- Enter and run short loop program 90 FE, the purpose being to allow the SC/MP to run but at the same time stop it from running the OS maintenance routines.

In either case, the flickering / changing characters in the 0x200- 0x3FF area continue to flicker.

Timbucus 6th Aug 2021 6:48 pm

Re: Ortonview PCB
That sounds like it is just rendering different characters not that they are physically changing in memory like was happening with the memory corruption.

Slothie 6th Aug 2021 6:51 pm

Re: Ortonview PCB
Well I have some (slightly) different results.

I cut the tracks, joined the pins and put in a RC as described, using a 1K resistor and 2.2nF capacitor.

With the switches and jumpers set to display Fxx and Bxx I get all the characters changing rapidly on the screen, maybe a few stable but most changing. However, as far as the SC/MP is concerned the memory isn't changing - I can change the values in memory and they read back the same (I didn't test this exhaustively, but I tried several ranges of memory). You can see some effect on the display, but the characters flick from one to another.

Set the VDU to display the memory at 2xx and 3xx and its as stable as a rock... Changing values in the memory stick and change what is displayed on the screen.

All the time the MK14 has a stable LED display and doesn't appear to have hung yet.

So maybe there isn't enough time between putting the address on the bus and reading the data with the extra delay and the MK14 memory/signal path is too slow? I can't find a trimmer yet but I will try a variable RC delay when I do, although your results would seem to imply this isn't going to help.

I'm still using the 10k/10k NWDS pullups fyi but I am seeing this more as a PIC accessing the RAM problem that write corruption. When I can get display of 02xx etc stable then we'll go back to seeing if we have corruption problems (I expect we may).

I might see if I can film the results I'm getting and upload it (no promises!)

SiriusHardware 6th Aug 2021 6:54 pm

Re: Ortonview PCB

That sounds like it is just rendering different characters not that they are physically changing in memory
Actually if I browse to the exact locations in question with the monitor, the monitor display goes unstable, so I think the locations really are being changed.

I've gone back to direct address connection and A8-A11 capacitors for now. In static operation at least, the screen memory content is rock stable. I still need to stress test it using CHARSET or something similar.

I don't think I can do more on the buffer problem side until you and Slothie and eventually Mark either do or don't have the same problems when you try it. If I turn out to be the odd man out, I may have to try a third type of RAM just to see if that makes a difference.

There are a couple of other differences between Slothie's setup and mine - one is that his machine is 4.43MHz and the other is that I am, as far as I remember, running earlier OrtonView firmware - the earliest fast version which worked properly - the reason being that none of the subsequent alterations to the code had the hoped for beneficial effect, so they just make the code more complicated for no additional gain. However, I will try going to the version Slothie is using so we are both working from the same base.

Timbucus 6th Aug 2021 6:57 pm

Re: Ortonview PCB
Just finishing family things but, hoping to have an hour to solder it together as I have all the parts now.

Mark1960 6th Aug 2021 6:57 pm

Re: Ortonview PCB
Characters still changing when there are no writes to memory by the 8060 could indicate a different problem than the interrupted writes. Are you able to scope NENIN and NWDS?

According to earlier posts there is a 3.75 us delay from raising NENIN to the PIC driving the address. Write cycles are 2us max. If NENIN is raised by the PIC while a write cycle is in progress it should be ok to delay NENIN to the 8060 until the write cycle is complete.

Due to ILD and DLD instructions holding the NBUSRQ for 6us, we can’t just gate NENIN with NBUSRQ.

Simplest method might be to AND gate NENIN from PIC with NWDS, but its possible the fairly slow 150ns propagation of NENIN to NENOUT also applies to NENIN to NWDS and we might still have a short glitch on NWDS when we interrupt the write cycle just before NWDS is active.

We could latch the RFLG from the data bus at the rising edge of NADS, and clear at the rising edge of NWDS. This could then be gated with NENIN. Its more complicated, but I think could be done with a 74HCT74 and 74HCT08 in place of the two buffers so not increasing chip count.

Probably needs to be HCT to avoid any extra loading on NWDS which could impact timing of NWDS rise to Address lines floating.

Edit: cross posted with #233 onwards, I type too slow on the ipad.

Slothie 6th Aug 2021 7:26 pm

Re: Ortonview PCB
Interestingly if displaying from the extension memory (0200/0300) I can upload an image using the uploader and it displays perfectly.

I looked up my AMD AM9111 memory and I have AM9111C memory which is 300nS. Maybe that is why I am seeing a difference between the MK14 and extension memory...

It also shows that the VDU isn't interfering with the function of the monitor when operating in this mode.

I'm going to have another look at the firmware...

Slothie 6th Aug 2021 7:44 pm

Re: Ortonview PCB
The macro to read memory looks like this:

; Read data from memory macro
        BCF        PORTA,NRDS        ; RDMEM = 7~
        DELAY        3
        MOVF        DBUS,W
        BSF        PORTA,NRDS
        INCF        ADRSSL

This macro is used wherever memory is read, and is called at least 4uS after the NENIN has been set high.

Can someone confirm: With a 16Mhz clock, the machine cycle is 4MHz, ie 250nS.

So the code above is setting NRDS low, waiting 3 cycles (=750nS) then reading the databus port, so the access time is at least 750nS.

The last thing the read does is to increment the Address lower 8 bit port, PORTD. If there were problems incrementing the port, then the display wouldn't work when running from the extension memory; yet it would appear the code is allowing 750nS access time...


SiriusHardware 6th Aug 2021 8:15 pm

Re: Ortonview PCB
Slothie, remind me which #nnn firmware you are running?

All times are GMT. The time now is 8:31 pm.

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