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 5th Aug 2021 7:58 am

Re: Ortonview PCB
 
Brought the board into work with a view to converting it to 'classic' configuration, but before I did I scoped the enable 1 / enable 2 signals with the 1K / 2.2nF RC values in place on one of the enables.

Obviously one enable is sharp and one has very pronounced rising and falling slopes and it's quite difficult to know where the delayed enable will be crossing the threshold, but I would say that it is crossing the half supply mark at about 1.8uS after the vertical edge on the undelayed enable - so there may be some leeway to increase the capacitor value a little bit more.

I've hacked a couple of 16-pin sockets by soldering little wire hoops into their top contacts so I can bypass the buffers by plugging the wired sockets into the buffer sockets, making it easy to swap between one method and the other.

Slothie 5th Aug 2021 9:55 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395663)
Brought the board into work with a view to converting it to 'classic' configuration, but before I did I scoped the enable 1 / enable 2 signals with the 1K / 2.2nF RC values in place on one of the enables.

Obviously one enable is sharp and one has very pronounced rising and falling slopes and it's quite difficult to know where the delayed enable will be crossing the threshold, but I would say that it is crossing the half supply mark at about 1.8uS after the vertical edge on the undelayed enable - so there may be some leeway to increase the capacitor value a little bit more.

I've hacked a couple of 16-pin sockets by soldering little wire hoops into their top contacts so I can bypass the buffers by plugging the wired sockets into the buffer sockets, making it easy to swap between one method and the other.

I would have been happier if I'd been able to use a schmitt trigger type input where the input thresholds are better defined, but there you are. There is a danger of instability if the slope becomes too slow, but given that you see these RC delays in logic circuits fairly often it can't be too dodgy!
The sockets idea is good, I used 4 strips of turned pin header with the adjacent pins bridged with solder, which works but looks a bit clunky due to the solder blobs!
It seems to work well enough with the load capacitors, its just a little technically unsatisfying for me as at the moment I don't understand where the problem is, the intended approach of asserting NENIN and waiting should be working, but there is obviously some nuance we are missing. It should be possible to fix this in the firmware.

SiriusHardware 5th Aug 2021 10:12 am

Re: Ortonview PCB
 
One avenue to explore is the possibility of using the 887, which Karen originally meant to use. If you move the code over to the 887 that gets you at least one more I/O pin to play with (RE3, which on the 877 is MCLR). What we don't yet know is whether the graphics blur issue which only happens with the 877A will also be a problem on the 887. We'll just have to try it.

I had originally hoped to use that ruse to do the bright line blanking but it could be used instead to properly control the buffer enable / disable line - enable the buffers just after the PIC address drive lines have been swapped to output mode, disable the buffers just before the PIC address drive lines are swapped back to input mode.

Of course if you are definitely going to go with buffers then you no longer need to keep swappping the PIC pin directions, they can remain in output mode with the buffers gating their access to the system address bus on and off as per the SOC VDU. But leaving that bit in for now leaves us the option of going back to the original scheme whenever we want to try or check something.

Mark1960 5th Aug 2021 3:03 pm

Re: Ortonview PCB
 
I think the write to wrong address when a write cycle is interrupted is going to need a hardware fix, I don’t see how it can be fixed with the software timing. When NENIN is raised it resets the 8060 bus cycle, tristates the NWDS and Address lines, NWDS is then pulled up by pull up resistor and the address lines float. The high address lines don’t seem to hold their level long enough for NWDS to be pulled high, possibly due to 74ls ttl address decoding input bias currents pulling the logic level before NWDS is inactive. This doesn’t seem to be a problem on the original mk14 vdu so the possibility is that the input current of the PIC is pulling the address lines faster than just the address decoding logic.

There may be some timing difference internal to the 8060 between the NWDS floating and the address lines floating. Adding capacitors is just increasing the hold time on the address bus.

The buffers are an attempt to match the address interface of the original mk14 vdu, it will be interesting to see if that provides any further confirmation that the PIC inputs are contributing to the address bus hold problem, though adding two chips to the design.

As we have 3.75us delay from raising NENIN before the PIC reads data and the memory access cycle of the 8060 at 4MHz is less than 2us, we could possibly delay NENIN until the end of any active memory cycle. I’m not sure if we could do this in software on the PIC, but it could probably be done with external logic.

We could also try an active bus hold circuit instead of capacitors to “remember” the address driven by the 8060 until driven by the PIC.

SiriusHardware 5th Aug 2021 4:17 pm

Re: Ortonview PCB
 
Quote:

This doesn’t seem to be a problem on the original mk14 vdu so the possibility is that the input current of the PIC is pulling the address lines faster than just the address decoding logic.
This what I'm banking on, the fact that the main difference between SOC and Ortonview VDUs is that the SOC VDU completely disconnects its address drive lines from the system address lines, while OrtonView just turns them into inputs as the pins used don't have a high impedance / tristate state which they can be placed in.

You may already have suggested this but what if we generate the buffer enable signal from NENIN(active, high) and NRDS? It's Karen's code which 'flaps' NRDS up and down for each read from the RAM so there is probably a signifcant delay between the instruction which takes NRDS low and the instruction which reads the data from the databus.

As long as the address buffers can turn on in that interval, will the RAM (system RAM or extra RAM) be able to respond and supply the data from the address which has been supplied 'just in time' for the PIC to read it?

Even if the timing is OK there will be one drawback, if the NRDS signal edge occurs just before the address arrives on the databus it would probably break compatibility with the IM65x.. RAMs which are an option on the issue VI replica PCB... the very reason why Karen's code does 'flap' NRDS, unlike the SOC VDU which just holds it low all the way through one video line.

Slothie 5th Aug 2021 5:57 pm

Re: Ortonview PCB
 
TBH if we lose compatibility with the IM65X rams it wouldn't be a disaster. It seems to be easy enough to get the AMD 9111 RAMs these days.

SiriusHardware 5th Aug 2021 6:35 pm

Re: Ortonview PCB
 
I've just busy trying out Slothie-OV in the conventional mode and I seem to have a problem in so far as I initially got the same haywire behaviour as I did when the buffers were involved, Narrowing it down it seems the problem only really happens when I am trying to let OrtonView render from the 6116 RAM.

If I set P1-P4 (Page select inputs) to render from the MK14's onboard RAM (0F00-0FFF and 0B00-0BFF) or from the ROM 0000-1FFF it actually works fine, it only goes haywire when I 'point' OrtonView at RAM in the range 0200-0600.

Yet, if I remove the PIC and leave only the 6116 and the 7402 fitted the system is able to write to and read from memory in that range.

This invalidates all my observations to date since the problems I was having were obviously not specifically related to operations with the buffers in place, and Slothie may find that if he tries the buffers again but this time with the enable delay (I would suggest maybe 1K + 3.3nF) it may work.

I'll see if I can get to the bottom of this problem.

The 6116 isn't the same brand / type as the one I used on my original 'Bridge board', so I may try to find another one of those, an EL6116LP. The device currently fitted is a Hitachi 6116LP-3 which according to the datasheet (and in spite of what the -3 would suggest) is a 150nS part. This is a chip I've owned since the 1980s, so unlikely to be fake.

Mark1960 5th Aug 2021 6:38 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395816)
You may already have suggested this but what if we generate the buffer enable signal from NENIN(active, high) and NRDS? It's Karen's code which 'flaps' NRDS up and down for each read from the RAM so there is probably a signifcant delay between the instruction which takes NRDS low and the instruction which reads the data from the databus.

Yes, thats what I suggested in #195, but we need to isolate NRDS generated by the PIC from NRDS generated by the 8060 to avoid buffers turned on for every 8060 read. That means cutting track and inserting a schottky diode. There would be no set up time on the address lines for the RAM to latch the address but no problem for 2111 or 9111 ram.

Could also try #199, use UA11 to enable the buffer. Doesn’t need track cut, just a pullup resistor, but limits orton view to low 2k, so just the 6116 on the expansion, but we would need to check ram in high 2k is not corrupted by interrupted writes. Might be worth trying as it avoids hacking the pcb until we know if the buffer solves the problem.

SiriusHardware 5th Aug 2021 6:40 pm

Re: Ortonview PCB
 
EL6116 as originally fitted is 100nS, so I'm off in search of one of those...

SiriusHardware 5th Aug 2021 6:42 pm

Re: Ortonview PCB
 
Quote:

we need to isolate NRDS generated by the PIC from NRDS generated by the 8060 to avoid buffers turned on for every 8060 read
Are you sure? Remember I said to derive the buffer enable from NENIN(=High) and NRDS. NENIN is only ever high when the VDU is trying to read from RAM. The 8060 should be off-bus and never assert NRDS itself when NENIN=High, so NRDS pulses during NENIN = high can only be coming from the PIC.

Mark1960 5th Aug 2021 6:45 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395862)
Yet, if I remove the PIC and leave only the 6116 and the 7402 fitted the system is able to write to and read from memory in that range.

What type of 7402? If its not hct then it might add more load to the address lines.

SiriusHardware 5th Aug 2021 6:48 pm

Re: Ortonview PCB
 
It is HCT (forgive my shorthand earlier). The chip I used for the address decoder on the bridge board I used with the prototype OrtonView was an LS, and continues to work OK.

Mark1960 5th Aug 2021 6:49 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395867)
Quote:

we need to isolate NRDS generated by the PIC from NRDS generated by the 8060 to avoid buffers turned on for every 8060 read
Are you sure? Remember I said to derive the buffer enable from NENIN(=High) and NRDS. NENIN is only ever high when the VDU is trying to read from RAM. The 8060 should be off-bus and never assert NRDS itself when NENIN=High, so NRDS pulses during NENIN = high can only be coming from the PIC.

I was thinking about the orton view interrupting an 8060 read cycle, might give a temporary bus conflict.

SiriusHardware 5th Aug 2021 7:07 pm

Re: Ortonview PCB
 
I keep forgetting that the VDU just barges in no matter what the SC/MP happens to be doing at the time.

I've just been up to my chip museum for some more RAM, found another Hitachi 6116LP-3 and a EL6116LP-10 which has obviously never been inserted in a socket before.

Fit Hitachi 6116: System goes nuts when VDU is set to render from the 6116.
Fit EL6116LP-10 - Works perfectly when the VDU is set to render from the 6116.

Slothie, what exactly do you have fitted in yours - in particular, what speed?

Slothie 5th Aug 2021 7:15 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395883)
Slothie, what exactly do you have fitted in yours - in particular, what speed?

I used an M5M5117P-15, 150nS memory.

Slothie 5th Aug 2021 7:17 pm

Re: Ortonview PCB
 
1 Attachment(s)
Here's the datasheet if you want to compare it to anything you might have.

SiriusHardware 5th Aug 2021 7:31 pm

Re: Ortonview PCB
 
I forgot you had specified something a little bit less mainstream. I've just checked a few sites and to be sure, got up off my launch pad and strolled as far as the bookshelf to get out my green and white 'Hitachi IC Memory Data Book' - all agree that

Hitachi 6116LP-4 = 200nS
Hitachi 6116LP-3 = 150nS
Hitachi 6116LP-2 = 120nS

So, I have no idea what's going on there. Ortonview obviously does rattle through the RAM quite quickly to try to keep the PIC fed with pixel data.

If I removed OrtonView, left the Hitachi IC fitted and wrote a bit of software to access the memory continually, maybe then it would fall over. Previously, I was checking the Hitachi RAM by just using the monitor to browse to various locations in the 6116's range to edit data and see if it would stick and could be read back (it did, it could).

SiriusHardware 5th Aug 2021 7:46 pm

Re: Ortonview PCB
 
Anyway, this means I'm right back at square one. To summarise, the sequence of events was:

1) Fit Hitachi 6116LP-3 RAM and address decoder only and check, using the crude process outlined above, that the RAM was working. It was.

2) Fit the VDU related components and modify the feed to the second enable on the buffers so that it was delayed by RC, initially 1K + 220pF then as high as 1K +2.2nF. In all cases the system went haywire when powered on.

3) Revert to original OrtonView design with address driving pins of PIC directly connected to system address bus, still pointed at memory at 0x200 onwards. Discover that the system still goes haywire when powered on.

4) Then tried pointing the VDU at areas of memory which were NOT in the 6116. Worked OK.

5) Replaced Hitachi 6116LP-3 with Elcap EL6116LP-10 - now working OK even when the VDU is pointed at any address within the 6116.

This should be a good starting point from which to attempt to get the buffers working again. I'm going to fit turned pin socket strips so that the address bus capacitors can be removed and fitted more easily.

Timbucus 5th Aug 2021 7:49 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395894)
I forgot you had specified something a little bit less mainstream. I've just checked a few sites and to be sure, got up off my launch pad and strolled as far as the bookshelf to get out my green and white 'Hitachi IC Memory Data Book' - all agree that

Hitachi 6116LP-4 = 200nS

Blast that is all I have - better hunt around for a different one then.

SiriusHardware 5th Aug 2021 7:53 pm

Re: Ortonview PCB
 
I can whizz you one of the Elcap 6116LP-10s if you have difficulty finding one (one good turn, etc)...


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

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