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)

Timbucus 23rd Aug 2021 7:22 pm

Re: Ortonview PCB
 
Excellent news Sirius - looks like progress has been made - I dread to think of some of the howlers I have made...

Indeed it will hang anywhere and I intend now I have the PCB one to turn my stripboard one into a display for the SCRUMPI 3 if I can modify the firmware as that has a different text layout.

I will be fascinated to see the Elektor unit - I have looked a few times as the Blue PCB is so iconic... I seem to have a plethora of PCB's for projects so need to knuckle down on builds.

Mark1960 23rd Aug 2021 7:38 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1400782)
So where is everybody else now? Tim has a more or less working vanilla Ortonview, as do I, finally.

Mine has now run for about an hour with no corruption to the image being rendered from 0200-03FF. Next up is to point OrtonView at 0Fxx / 0Bxx and run CHARSET to see if there is any remnant of the original corruption problem. If not, I may try gradually decreasing the A8-A11 capacitors to find a lower limit for the value of those capacitors on this PCB.

Slothie and Mark are obviously both trying to drill down to the actual cause of the corruption problem which the capacitors 'fix', although Mark is more likely to fix it with a hardware fix and Slothie is more focused on finding a firmware fix - is that a fair summary?

I might try adding the 6116 now that you know why it wasn’t working.

I still suspect its going to need a hardware fix. Either to prevent interrupted write cycles or to synch the NENIN from the PIC with the 8060 clock. The RC delay on NENIN in the original mk14 vdu makes me suspect that the NENIN needs to be timed to a specific part of the clock cycle. If only the original designer would stop by and tell us.

I was able to capture at least one time that NWDS was activated after NENIN was raised, so to prevent an interrupted write we would probably need to decode the RFLG during NADS.

Maybe its also worth trying the buffers again but I’m almost certain its not going to work. This is based on seeing the range of timing on NWDS and A11 relative to NENIN, where sometimes they show active pull up and sometimes they just float.

Easiest fix is probably to OR gate the NWDS output of the 8060 with NENIN, but that would need a mod to the MK14, and I think we already agree that is against the rules.

SiriusHardware 23rd Aug 2021 7:42 pm

Re: Ortonview PCB
 
I think I've mentioned before that the initial version of the Elektor computer - with binary switch inputs and binary LED outputs - was the first programmable device I ever programmed. Unfortunately my friend, whose system it was, never took it any further, not even to the point of a hex keypad and display.

Shortly after that, my MK14 finally arrived.

Edit, upon seeing Mark's Post - Yes, I'm afraid the 'rule', although I don't know who wrote it, is that the final version of Ortonview must not require any connectivity over and above that needed by the SOC VDU. I guess the idea / ideal is for OrtonView to be completely interchangeable with a SOC VDU and immediately usable with any original MK14 which was modified so that it could connect to a SOC VDU.

SiriusHardware 23rd Aug 2021 7:54 pm

Re: Ortonview PCB
 
I've seen circuits for frequency doublers somewhere, mmm...

https://www.maximintegrated.com/en/d...es/3/3327.html

Two of those, chained, to take the MK14 clock-out signal up to 16MHz for the PIC?

audiokit 23rd Aug 2021 8:09 pm

Re: Ortonview PCB
 
Hello Mark,
Yes it is made with digitasts and HP 7-segments like indicated in Elektor. but I don't want to clutter this thread and will make a new one when I got some more interesting to report. Posted some pictures in the German vintage computer board VzEkC : https://forum.classic-computing.de/f...666#post316739
Benny

Mark1960 23rd Aug 2021 10:18 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1400797)
I've seen circuits for frequency doublers somewhere, mmm...

https://www.maximintegrated.com/en/d...es/3/3327.html

Two of those, chained, to take the MK14 clock-out signal up to 16MHz for the PIC?

I think that still leaves four possible phase offsets between the PIC and the 8060 xout.

SiriusHardware 23rd Aug 2021 11:18 pm

Re: Ortonview PCB
 
I think we have discussed this before, but if you think about it there is no way to guarantee which phase of the SCMP's clock cycle the SOC VDU will first start clocking on.

With the SC/MP and the VDU both running, hold down reset for a moment (the SC/MP clock keeps running - I have just checked) - and therefore so does the SOC VDU (if it is hard-enabled, by a link, rather than controlled by flags or I/O pins).

When you release reset and the SC/MP begins running again, the VDU divider chain could be at any step-point in its overall cycle when the SC/MP resumes operation, yet this does not appear to harm the operation of the system or the SOC VDU.

I thought you were thinking more of the fixed time commencing with an initial rising or falling SC/MP clock edge which eventually, and always after the exact same period of time - the time it takes to propagate through the VDU chain - becomes a NENIN pulse.

That time relationship between edges of the SC/MP clock and edges of NENIN can only be guaranteed when the VDU chain is being driven by the SC/MP clock.

SiriusHardware 23rd Aug 2021 11:32 pm

Re: Ortonview PCB
 
Sorry, I see that what you meant was that multiplying the clock x 4 creates 16MHz clock edges coinciding with the SC/MP clock edge, and at one-quarter past, and at half past, and at three quarters past and the PIC could start clocking on any of those four edges. Problems indeed.

Slothie 23rd Aug 2021 11:43 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1400834)
That time relationship between edges of the SC/MP clock and edges of NENIN can only be guaranteed when the VDU chain is being driven by the SC/MP clock.

I did think you might be able to synch the XCLOCK with the other signals by using a counter reset by NADS which always is asserted at the beginning of a memory cycle, but that might not work due to the rather random number of clock cycles each instruction takes, some of them not even using a memory cycle. I think it would probably break if you executed a DLY instruction.

I was going to see if gating the NENIN signal with the edge of XCLOCK using a latch might wotk, to prevent NENIN going high half way through a clock cycle, but I don't think that is a problem because in the intended multi-processor system as outlined in the National Semiconductor book they don't seem to share a clock oscillator, certainly I haven't seen any such requirement, so it must be possible for the processors to phase in and out of sync with eachother. What we are doing however is ignoring the NENOUT and NBREQ signals but I'm not sure if that is significant given the SoC VDU did as well, and it had no idea where the SC/MP was in its internal state either. I am inclined to believe that SoC used XCLOCK because it was a convenient source of 4MHz rather than because of any particular timing requirement.

Mark1960 24th Aug 2021 12:23 am

Re: Ortonview PCB
 
I think it depends on which of the 8060’s clocks we need to be in phase with. There is xout, running at 4MHz, and is clocking the 74ls74 at the start of the divider chain on the SoC vdu always on the rising edge.

Then the 8060 spec has a few references to Tc, with a period of twice the xout period, but also a few references to Tc/2 in the timing specs.

The microcycles for instruction execution are xout/4.

The 8060 spec is not clear if the synchronous logic that generates Control signals is clocked by xout, xout/2, or xout/4, and we don’t know if they are clocked by rising edges or falling edges but I think we can assume the SoC VDU generates ENIN in some specific time time window relative to xout that might always be safe to raise NENIN. This time window might be chosen to avoid a critical time in the memory cycle which might be anytime in the 2 microcycle memory cycle.

The PIC runs at xout*4, so even if we could get the PIC and 8060 clocks synchronised and the PIC instruction cycle is xout*4/4, the timing on NENIN set by the PIC relative to Xout rising edge could be + 0ns, +/- 62.5ns or +/- 125ns. It might still be possible even with this offset to avoid the critical time in the memory cycle, but it does seem like this would be more difficult.

Maybe if the PIC instruction cycle could also be synchronised to xout we would have a better chance, but I don’t know if there is a way to do that.

I’m still only guessing that there is a critical time relative to xout for NENIN that leaves NWDS floating instead of driven high, while the address lines are changing before NWDS is pulled high by the 4k7 pullup.

With an external trigger to the scope, I’m hoping to trigger on NENIN rising edge, display Xout on one trace and NWDS or Ax on the other and try and measure the time for NENIN relative to xout that causes NWDS or Ax to go floating instead of driven to 5v.

If I can find a time relative to xout where NWDS is driven high before Ax change, without the capacitors on the address bus, then we can add a 74ls74 clocked by xout, D from PIC NENIN, and an RC delay from Q to the 8060 NENIN, possibly using the other half of 74ls74 to buffer the output of the RC.

SiriusHardware 24th Aug 2021 12:32 am

Re: Ortonview PCB
 
It is undeniably the case that when the SOC VDU is driven from SC/MP clock-out there is a definite timing relationship between individual edges of the clock-out signal and all of the VDU events which are generated downstream.

I meant to, but never did, try running my SOC VDU from an independent signal generator running at some frequency slightly offset from 4MHz. I tried to do it, but discovered that the output from my RF sig-gen could not be wound up to the level that was needed by the clock-in buffer on the SOC VDU.

I could revive that idea - make a crystal oscillator which runs slightly above or below 4MHz and run the SOC VDU on that - if it still works then we can say that there is no reason for the two units to be in lock-step or to have a particular phase relationship.

Mark1960 24th Aug 2021 12:33 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1400838)
I am inclined to believe that SoC used XCLOCK because it was a convenient source of 4MHz rather than because of any particular timing requirement.

Its that RC circuit on the NAND gate in the SoC VDU NENIN circuit that makes me suspicious that they are tuning the delay.

In the multiprocessor circuit there are no aborted memory cycles. When NBUSRQ is pulled low, no other 8060 can pull NBUSRQ low. If two 8060s pull NBUSRQ low at the same time, they wait for NENIN to ripple through the higher priority 8060s before they access the bus.

Mark1960 25th Aug 2021 1:58 am

Re: Ortonview PCB
 
1 Attachment(s)
Extra probes arrived so I now have external rigger on NENIN, trigger time shown by the blue arrow at the top. NWDS in yellow and A10 in purple.

Running 8060 at 4MHz as it makes it easier to count cycles.

No capacitors on address lines.

I have a tight loop writing to B10 and I see characters also changing at B20 and F10.

Unfortunately when I put a scope on A10 it stops F10 character from changing, but timing still looks marginal as in attached.

Mark1960 25th Aug 2021 2:09 am

Re: Ortonview PCB
 
1 Attachment(s)
I also noticed that NWDS pulse width is never shortened even when NENIN is raised.

Looking at NWDS and XOUT it seems that NWDS is clocked on the rising edge of XOUT for both the beginning and the end of NWDS.

Here with NWDS in yellow and XOUT in purple.

Note here that NENIN raised at the blue arrow, before rising edge of XOUT, but there is still a complete NWDS cycle.

Mark1960 25th Aug 2021 2:22 am

Re: Ortonview PCB
 
3 Attachment(s)
This time with A5 in yellow, XOUT in purple. Blue arrow is still NENIN rise.

Address line can start to rise anywhere from first rising edge of XOUT to the third rising edge of XOUT.

This seems to show address lines may be synched with microcycles, XOUT / 4.

Slothie 25th Aug 2021 11:30 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1401075)
I also noticed that NWDS pulse width is never shortened even when NENIN is raised.

Looking at NWDS and XOUT it seems that NWDS is clocked on the rising edge of XOUT for both the beginning and the end of NWDS.

Here with NWDS in yellow and XOUT in purple.

Note here that NENIN raised at the blue arrow, before rising edge of XOUT, but there is still a complete NWDS cycle.

I noticed that with my logic analyser. Up to 1uS (4 clock cycles) after NENIN is raised its possible for a write cycle to be in progress. I never saw one start sooner than 500nS after NENIN is raised, but that may just have been chance.
The address decode logic on the MK14 only pulls the 'E' enable pin low when one of NRDS or NWDS is low, through an AND gate, so when a write cycle begins the R/~W pin of the RAM should go low one propagation delay before the enable signal, and presuming the two chip selects are low (which they should be because the address bus should be being driven from when NADS was low) the write should occur. Unless the address bus is being released before NWDS goes high in the case of NENIN being asserted, I can't see how bad memory addresses could be being formed.
'Tis puzzling.

Mark1960 25th Aug 2021 5:21 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1401162)
I can't see how bad memory addresses could be being formed.

I think #433 shows that the address line is changing while NWDS is still low. Its not quite reaching logic high but maybe enough to change the address written.

SiriusHardware 25th Aug 2021 5:25 pm

Re: Ortonview PCB
 
Quote:

I think #433 shows that the address line is changing while NWDS is still low
...and that's why the capacitors work, albeit in crude fashion? They hold the address lines to their original state for just long enough for the NWDS pulse to end?

SiriusHardware 25th Aug 2021 5:47 pm

Re: Ortonview PCB
 
It might be rising a little faster were it not for the capacitance added by the scope probe / scope input - that's possibly part of the problem, we are in that realm where the mere act of observation can alter the very thing we are trying to observe.

Timbucus 25th Aug 2021 6:13 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1401281)
It might be rising a little faster were it not for the capacitance added by the scope probe / scope input - that's possibly part of the problem, we are in that realm where the mere act of observation can alter the very thing we are trying to observe.

I am sure I remember we had that issue when I was trying to scope the problem before and was why we tried the capacitors - although my memory may be failing.


All times are GMT +1. The time now is 8:39 pm.

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