UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 2nd Sep 2021, 11:42 pm   #481
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

Quote:
Originally Posted by Mark1960 View Post
I wonder if this means there is a possible PIC firmware fix by shortening or lengthening the time that NENIN is active by one or two cycles. I think shortening NENIN by 250ns might be similar to the clock delay.

Is the length of NENIN a multiple of 1us, the same as the 8060 microcycle?
I spent a bit more time thinking about this, its likely not going to be a complete fix even if it does give an improvement, as the first NENIN of each frame is still going to arrive at a random point in the xout cycle.

If we try it then I think the length of NENIN and spaces between NENIN should be a multiple of 500ns, as we only want to avoid the one out of four clock cycles that cause the issue.

Another thought is if we can find some way to delay NENIN by one clock cycle, but only if NENIN is raised during the clock cycle that causes the problem. Maybe that could also work with 4.43316MHz.
Mark1960 is offline  
Old 3rd Sep 2021, 12:15 am   #482
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Ortonview PCB

I've been thinking about this, and it occurs to me that at 4.433619MHz the SC/MP is being effectively "overclocked", and maybe the timing of the bus arbitration logic just doesn't work much above the "official" max speed on 4MHz. This wouldn't have been noticed by or bothered SoC when originally designing the MK14 because NENIN wasn't used, and when developing the VDU they dropped the frequency to 4MHz anyway to simplify the timing for the video generation so attempting to get it to work above 4MHz might be a bit of a waste of time, or at very least require more complicated logic to compensate for shortcomings in the SC/MPs internal logic. It's possible the timing of switching off the address buffers and the other signals and the is controlled by "propagation delay" that runs out of room at higher frequencies. The data sheet gives a fairly narrow range of acceptable clock frequencies (2-4 Mhz) so maybe the internal logic isn't entirely synchronous as it tends to be in more modern CPUs.
Slothie is offline  
Old 3rd Sep 2021, 9:45 pm   #483
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

At 4 MHz there is a single point in the write cycle where raising NENIN will result in the NWDS floating high slowly while A10 rises earlier. This is around the rising edge of xout just prior to NWDS driving low. If we detect RFLG during at rising edge of NADS we might use this to block NENIN for one cycle of xout. The challenge would be to do this with a single chip, possibly a dual JK or JnotK could do this and would not need an RC delay.

At 4.433619MHz there are two points that are a problem, rising edge of xout just prior to NADS rising and also rising edge of xout just prior to NWDS driving low. Again this might be possible with a dual JK or JnotK.

Having two problem points is probably why the 80 ns delay is not working at 4.433619 MHz as it just shifts NENIN from one first problem point to the second.

Both of the above were seen using 40ns delay from rising edge of xout to rising edge of NENIN.

This would be a different method than that used by SoC, but might then support both 4.0 and 4.433619 MHz crystals.

I’ll post some scope plots later when I have time to get the laptop online as I don’t know how to get plots from the usb stick with the ipad.

Last edited by Mark1960; 3rd Sep 2021 at 9:49 pm. Reason: Added comment about two problem points and 80ns delay.
Mark1960 is offline  
Old 5th Sep 2021, 10:45 pm   #484
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

This is the plots showing the two sets of timing at 4.433 MHz for NENIN that causes NWDS to rise slowly and A10 changes while NWDS is low.

NWDS is yellow, A10 is purple, blue arrow shows NENIN rising edge trigger.

Also included with NWDS yellow and NADS purple for reference to these two timing positions.
Attached Thumbnails
Click image for larger version

Name:	SDS00004.png
Views:	36
Size:	22.1 KB
ID:	240745   Click image for larger version

Name:	SDS00006.png
Views:	33
Size:	22.4 KB
ID:	240746   Click image for larger version

Name:	SDS00005.png
Views:	40
Size:	21.7 KB
ID:	240747   Click image for larger version

Name:	SDS00007.png
Views:	30
Size:	23.0 KB
ID:	240748  

Last edited by Mark1960; 5th Sep 2021 at 10:47 pm. Reason: add 4.433 MHz
Mark1960 is offline  
Old 5th Sep 2021, 10:51 pm   #485
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

At 4.0 MHz there is only one timing that causes A10 to rise before NWDS.
Attached Thumbnails
Click image for larger version

Name:	SDS00014.png
Views:	26
Size:	22.0 KB
ID:	240749   Click image for larger version

Name:	SDS00017.png
Views:	25
Size:	21.3 KB
ID:	240750  
Mark1960 is offline  
Old 6th Sep 2021, 8:18 am   #486
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Ortonview PCB

I'm wondering if we should do more testing to see if the original A8-A11 capacitors work equally well when 4.00MHz / 4.43MHZ clocks are in use in the MK14. I'm not sure but I think Slothie has been using a 4.43MHz clock from the beginning.

If they do work equally well with either clock frequency then we may have to reluctantly accept that the capacitor fix is the more broadly effective and pragmatic one, no matter how technically offensive we may find it.
SiriusHardware is offline  
Old 6th Sep 2021, 11:25 am   #487
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Ortonview PCB

The only problem I have with the capacitor idea is the thought that it might load the bus with too much capacitance, the data sheet specifies a maximum of 75pF for outputs other than XOUT. Not sure if too much capacitance would harm the 8060 or if is a signal integrity issue.
Slothie is offline  
Old 6th Sep 2021, 5:02 pm   #488
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

Attached might work to synch NENIN to XOUT and also block NENIN at the end of NADS and beginning of NWDS.

It shouldn't matter that this also blocks NENIN during a read cycle at the same two points.
Attached Thumbnails
Click image for larger version

Name:	Capture2.jpg
Views:	72
Size:	22.0 KB
ID:	240780  
Mark1960 is offline  
Old 14th Sep 2021, 2:16 am   #489
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

I got round to testing the circuit in #488 and with the simple loop using ILD at B10 there is no sign of corruption at F10. This was at both 4MHz and 4.433619MHz.

Though this seems to work at both frequencies it does need NADS from the MK14 and I think Sirius or Slothie mentioned this might not be available on the earlier MK14 revisions.

The earlier circuit with an RC delay only works at 4MHz, but it does seem to work in a similar way as the original mk14 vdu with its RC delay in the NENIN circuit.

Does anyone have a more comprehensive test routine that I could key in?

I’ll post some scope shots later.
Mark1960 is offline  
Old 14th Sep 2021, 9:11 am   #490
Buzby123
Heptode
 
Buzby123's Avatar
 
Join Date: Oct 2011
Location: Culcheth, Cheshire, UK.
Posts: 637
Default Re: Ortonview PCB

Quote:
Originally Posted by Mark1960 View Post
... it does need NADS from the MK14 ...
My Issue II has a connection for NADS on the edge connector, but the documentation says it should not be available until Issue III.

https://www.vintage-radio.net/forum/...1&postcount=38
Buzby123 is online now  
Old 14th Sep 2021, 9:25 am   #491
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Ortonview PCB

Given that issue II, III did not even have contact fingers on the underside of the rear edge connector to route the address, data and control signals to, I suppose the presence or absence of NADS on the top side of the edge connector is the least thing that the owner of any early issue MK14 has to worry about when trying to connect a VDU, whether original or OrtonView.

For any original machine which does have contact fingers on the PCB underside at the rear edge connector (Issue IV, V?) the need to add just one more wire link to one more contact finger will not be too upsetting.
SiriusHardware is offline  
Old 14th Sep 2021, 9:39 am   #492
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Ortonview PCB

Quote:
Originally Posted by Mark1960 View Post
I got round to testing the circuit in #488 and with the simple loop using ILD at B10 there is no sign of corruption at F10. This was at both 4MHz and 4.433619MHz.

Though this seems to work at both frequencies it does need NADS from the MK14 and I think Sirius or Slothie mentioned this might not be available on the earlier MK14 revisions.

The earlier circuit with an RC delay only works at 4MHz, but it does seem to work in a similar way as the original mk14 vdu with its RC delay in the NENIN circuit.

Does anyone have a more comprehensive test routine that I could key in?

I’ll post some scope shots later.
Good work!

I'm thinking its not bad to have to use NADS, since none of the signals were available on the edge connector per se, so to have to wire one extra signal we are still in the spirit of the thng. If we were hoping to make it 100% functionally equivalent then we'd have to replicate the circuit in a CPLD or something.

This is the program I have been using - it is set here to reside in the ram/io and use variables in the ram/io but write to 0xB00-0xBff. by setting the Ortonview to display both pages you can see the obvious corruption in 0xF** which should not be written to at all. It should be simple to change to move or write to different locations:
Code:
Pass one
Loaded scmp overlay version 3.02.00

Pass two
0000-                  1                .CR scmp
0000-                  2                .TF testmem.hex, INT
0E80-                  3                .OR 0xe80
0E80-                  4
0B00-                  5        data    .EQ 0xb00
0EE0-                  6        var     .EQ 0xee0
0E80-                  7
0000-                  8        count   .EQ 0 ; Offsets into var
0001-                  9        char    .EQ 1
0E80-                 10
0E80-C4 0B            11 (  10) start   ldi /data       ; Point P1 to data area
0E82-35               12 (   8)         xpah    1
0E83-C4 00            13 (  10)         ldi #data
0E85-31               14 (   8)         xpal    1
0E86-C4 0E            15 (  10)         ldi /var        ; Point P2 to variable area
0E88-36               16 (   8)         xpah    2
0E89-C4 E0            17 (  10)         ldi #var
0E8B-32               18 (   8)         xpal    2
0E8C-C4 00            19 (  10)         ldi 0
0E8E-CA 00            20 (  18)         st count(2)
0E90-C2 01            21 (  18) loop    ld char(2)
0E92-CD 01            22 (  18)         st @1(1)
0E94-BA 00            23 (  22)         dld count(2)
0E96-9C F8            24 (9/11)         jnz loop
0E98-AA 01            25 (  22)         ild char(2)
0E9A-90 E4            26 (  11)         jmp start       ; always restart
0E9C-                 27
0E9C-                 28        ;       .OR 0xF12
0E9C-                 29        ;mfill
0E9C-                 30        ;       .BS 0xFFF-0xF11, 0
0E9C-                 31
0E9C-                 32        ; Bytes for loader
FFFE-                 33                .OR 0xFFFE
FFFE-0E               34                .DB start>>8
FFFF-80               35                .DB start

0 Errors found during assembly.
0 Warnings found during assembly.
Slothie is offline  
Old 14th Sep 2021, 9:46 am   #493
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Ortonview PCB

Oh, the original files:
Attached Files
File Type: zip testmem.zip (674 Bytes, 33 views)
Slothie is offline  
Old 14th Sep 2021, 7:29 pm   #494
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Ortonview PCB

YAY

Well I wired up Marks circuit from #488 and have run the test under various scenarios and it all seems to be working fine, the code will now run in F20 with its variables, writing to B00-BFF with no visible corruption, and also the other way round, or from e80 etc.

I'm running firmware #692 at 4.433619MHz. Looks like I might not need those 4MHz crystals I bought after all...

Given the elegance of the design it seems that it will provide the necessary synchronisation. I suppose we need to test that things like running a DLY instruction won't break it due to the lack of NADS pulses. I must confess I haven't got my head round how the dual latch works, but it seems it does.

Its especially nice that its a one-chip solution to the problem, and a chip that is still readily available!
Slothie is offline  
Old 14th Sep 2021, 7:35 pm   #495
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Ortonview PCB

I'm away from Moon Base Alpha just now so I won't be able to throw Mark's patch together until next week, but it all sounds very hopeful.

Oh, but... were you both testing with no fudge capacitors on A8-A11? I know Mark won't have had capacitors fitted, but Slothie?
SiriusHardware is offline  
Old 14th Sep 2021, 7:42 pm   #496
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Ortonview PCB

Quote:
Originally Posted by SiriusHardware View Post
I'm away from Moon Base Alpha just now so I won't be able to throw Mark's patch together until next week, but it all sounds very hopeful.

Oh, but... were you both testing with no fudge capacitors on A8-A11? I know Mark won't have had capacitors fitted, but Slothie?
No capacitors! No buffers, I took your suggestion and made them "pluggable".
Slothie is offline  
Old 14th Sep 2021, 8:04 pm   #497
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

I don’t have capacitors fitted, but I did have a scope probe on A10. I’ll try again with the scope probes removed.

Also need to fit the 8154 and key in Slothie’s test code, and maybe also try with the extra extra 1.5k ram.

Operation of the circuit is as follows, hopefully this doesn’t cause more confusion.

NADS low presets the first flip flop, which holds clear low on the second flip flop, holding 8060 NENIN low.

NADS stays low until after the XOUT rising edge keeping the first flip flop set.

After NADS returns high, the first flip flop remains set, keeping clear low on the second flip flop and 8060 NENIN remains low.

On the next XOUT rising edge the first flip flop is cleared, this releases clear on the second flip flop, but too late for XOUT to clock in NENIN from the PIC, so again NENIN to the 8060 remains low.

Then on the next rising edge of XOUT, NENIN from the PIC can be clocked through to the 8060.

The extra connection from /Q of the second flip flop to clear of the first flip flop ensures that after NENIN to the 8060 has been raised, NADS can not set the first flip flop. This relies on the “feature” of the 74x74 where both clear and preset low will hold both the Q and /Q outputs high.
Mark1960 is offline  
Old 14th Sep 2021, 8:23 pm   #498
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

Adding scope plots for 4MHz

Blue arrow marks NENIN to 8060 rising edge on the trigger input.
Yellow is NWDS
Purple is A10
Attached Thumbnails
Click image for larger version

Name:	SDS00001.png
Views:	31
Size:	59.5 KB
ID:	241310   Click image for larger version

Name:	SDS00002.png
Views:	27
Size:	19.7 KB
ID:	241311   Click image for larger version

Name:	SDS00003.png
Views:	25
Size:	20.3 KB
ID:	241312   Click image for larger version

Name:	SDS00004.png
Views:	26
Size:	20.5 KB
ID:	241313  
Mark1960 is offline  
Old 14th Sep 2021, 8:24 pm   #499
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Ortonview PCB

And the same at 4.433MHz
Attached Thumbnails
Click image for larger version

Name:	SDS00005.png
Views:	32
Size:	52.2 KB
ID:	241314   Click image for larger version

Name:	SDS00006.png
Views:	27
Size:	20.9 KB
ID:	241315   Click image for larger version

Name:	SDS00007.png
Views:	28
Size:	20.3 KB
ID:	241316   Click image for larger version

Name:	SDS00008.png
Views:	22
Size:	20.1 KB
ID:	241317  
Mark1960 is offline  
Old 14th Sep 2021, 8:30 pm   #500
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Ortonview PCB

I will have to dig my items out on the weekend, desolder the caps and try the patch - well done Mark.
Timbucus is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 11:00 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


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