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)

Mark1960 22nd Aug 2021 7:17 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Timbucus (Post 1400261)
As an aside to the issues part of the Slothie PCB included a hardware Random number generator which we have not tried yet. It may interest you to know there is canon for that (with code snippets) for the MK14 in November 1981 Computing Today Microlink... Pg. 25...

http://www.flaxcottage.com/ComputingToday/8111.pdf

I did try to add just the two pages of the article as PDF but, it was too big...

I thought Slothie based his circuit on the twonky, ETI February 1979, page 79.
https://worldradiohistory.com/UK/Ele...1979-02-79.pdf

They leave a lot of details missing from the schematic, but it should be possible to fill in the missing info. They also list the code.

Slothie 22nd Aug 2021 8:34 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1400478)
Quote:

Originally Posted by Timbucus (Post 1400261)
As an aside to the issues part of the Slothie PCB included a hardware Random number generator which we have not tried yet. It may interest you to know there is canon for that (with code snippets) for the MK14 in November 1981 Computing Today Microlink... Pg. 25...

http://www.flaxcottage.com/ComputingToday/8111.pdf

I did try to add just the two pages of the article as PDF but, it was too big...

I thought Slothie based his circuit on the twonky, ETI February 1979, page 79.
https://worldradiohistory.com/UK/Ele...1979-02-79.pdf

They leave a lot of details missing from the schematic, but it should be possible to fill in the missing info. They also list the code.

Yes, I got the idea from there and the details from an article in Elektor I think, which used a similar circuit for a synth.

SiriusHardware 22nd Aug 2021 11:30 pm

Re: Ortonview PCB
 
I've just done a 'lite' version of this test below,

Quote:

(3) Disable or remove the VDU components so that the board is just a 1.5K 'RAM pack' and use Slothie's test program or some other means to verify the operation of all of the 6116 RAM ICs.
I removed the PIC and fitted every type of RAM I have available in the 6116 position and they all pass a 'slow test', which is to say,

-They don't mess up the operation of the system.

-The normal / extra and I/O memory of the MK14 can be edited and inspected.

-The extra-extra RAM provided by the 6116 can be edited and inspected even when one of the Hitachi HM6116LP-3 or MK6116N-15 types are fitted.

Apart from the fact that the PIC is removed, all other system configuration is as described in post #390.

Slothie 23rd Aug 2021 10:17 am

Re: Ortonview PCB
 
It is rather looking like the PIC being on the buses is the problem.... so maybe we need to look at getting the buffers to work. I'm still trying and failing to catch a "rogue" write.

SiriusHardware 23rd Aug 2021 10:31 am

Re: Ortonview PCB
 
I think for a better RAM test I need to do some testing of all RAM areas at full machine speed, with one of the 'worst' 6116s fitted.

Somewhere back in the thread I think you thought your 6116 RAM was working 100% but then discovered it was not entirely stable? Not sure which exact circumstances that was happening under.

I've just fitted SMD 10uFs to the PIC power pin pairs as per Mark's mod but have left the associated 0.1uF in the position provided as well. Will do a bit more testing tonight.

Is there any thought as to how fast the 6116s need to be specifically with respect to Ortonview? OrVw rips through the RAM at quite a rate in order to keep the video bit stream topped up.

Slothie 23rd Aug 2021 10:46 am

Re: Ortonview PCB
 
1 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1400620)
Is there any thought as to how fast the 6116s need to be specifically with respect to Ortonview? OrVw rips through the RAM at quite a rate in order to keep the video bit stream topped up.

The ortonview accessed the memory slower (i.e. NRDS is low for longer) than the SC/MP but more frequently....

SiriusHardware 23rd Aug 2021 12:06 pm

Re: Ortonview PCB
 
Those NRDS pulse on the RHS, obviously generated by OrtonView since NENIN is high during that period, are quite close together although it's hard to tell how close together (timewise) on that scale.

I'm assuming there is also a required minimum interval between the application of the address to the address bus and the onset of NRDS - ie, the address bus needs to have time to settle and then wiggle its way through the internal address logic to select the correct internal element of the RAM, before NRDS is taken low. Could we be taking NRDS low too soon for some (not all) of the RAMS being tested? What is the interval between OrVw writing the address (which it does in two steps, so it's the second write which is the relevant one) and OrVw taking NRDS low?

Bear in mind that application of the address to the address bus is done by changing the port from input mode to output mode in two stages - How long does that overall port direction change actually take to happen? And then afterwards, how long does it take to change back from output to input mode?

Slothie 23rd Aug 2021 1:16 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1400650)
Those NRDS pulse on the RHS, obviously generated by OrtonView since NENIN is high during that period, are quite close together although it's hard to tell how close together (timewise) on that scale.

I'm assuming there is also a required minimum interval between the application of the address to the address bus and the onset of NRDS - ie, the address bus needs to have time to settle and then wiggle its way through the internal address logic to select the correct internal element of the RAM, before NRDS is taken low. Could we be taking NRDS low too soon for some (not all) of the RAMS being tested? What is the interval between OrVw writing the address (which it does in two steps, so it's the second write which is the relevant one) and OrVw taking NRDS low?

Bear in mind that application of the address to the address bus is done by changing the port from input mode to output mode in two stages - How long does that overall port direction change actually take to happen? And then afterwards, how long does it take to change back from output to input mode?

The MK14 NRDS pulses are 3.5-4.5 uS apart, with a duration of ~500ns or less.
The Ortonview NRDS pulses (at fastest) are 2.5uS apart with a duration of 1.5uS (hence the NRDS is high for 1uS between read cycles).

As for the address bus writes, the upper 4 bits are only set at the beginning of each half of the screen. the lower 8 bits are incremented in this macro:
Code:

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

The address bus is incremented at the end of the
The code for each line looks like this:
Code:

        RDMEM
        ANDLW        B'00111111'
        IORWF        TINV,W
        MOVWF        BUFA+0
        RDMEM
        ANDLW        B'00111111'
        IORWF        TINV,W
        MOVWF        BUFA+1
        RDMEM
        ANDLW        B'00111111'
        IORWF        TINV,W
        MOVWF        BUFA+2

The RDMEM macro takes 7 cycles, then there are a further 3 instructions, so the address bus lower 8 bits get incremented every 10 cycles = 2.5uS as observed. The NRDS bit gets set low by the BCF instruction at 4 instructions after the increment which is ~1uS after the address bus is changed. There are at least 3 cycles (750nS) between NRDS being set low and the data being read from the address bus.

SiriusHardware 23rd Aug 2021 4:07 pm

Re: Ortonview PCB
 
Oh... Dear.

I think I've just found out why my PCB-based OrVw is the worst performing of all those built so far, at least with respect to the operation of the 6116 memory expansion. While fitting a diode in place of the direct link between +5V and the 6116 supply pin, I realised I had the link fitted in the D1 position, not the D2 position - in other words, I had the link in the position of the diode which is meant to carry the alternative supply from the backup battery (not fitted).

This means, of course, that I have been trying to run the 6116s without any serious kind of +5V supply, except what they may have been getting through the clamp diodes on their various other pins, or through resistors R1 / R2 / R3, one of whose associated lines are high most of the time.

This being the case, it is pretty miraculous that any of the RAMs have been working at all, and no surprise that some tolerated the situation better than others. A simple check on the 6116 supply pins with a meter and scope would have given the game away two weeks ago. Not my finest hour.

I've now linked out the D2 position instead, so we'll see what happens when I give it another go tonight. ;)

Mark1960 23rd Aug 2021 4:25 pm

Re: Ortonview PCB
 
I actually read a suggestion to check for that kind of issue in a recent thread on 6502.org but thought that was too unlikely to pass it on. The thinking was that the parasitic diodes in the inputs and outputs charge the decoupling cap but then that is discharged when the inputs are low.
http://forum.6502.org/viewtopic.php?...tart=45#p85984

Slothie 23rd Aug 2021 5:12 pm

Re: Ortonview PCB
 
Well its not like any of the rest of us have done something like that! (Speaking as the guy who fiddled with bad video for a fortnight before finding he had a transistor in backwards!).

I'm glad you've found the problem, I should have documented it better, rather than just posted a PCB to folks and leaving them to work it our!

SiriusHardware 23rd Aug 2021 5:17 pm

Re: Ortonview PCB
 
I think this is why it took me so long to consider / notice the real problem, because at least some of the RAMs were working quite well and in fact all of them were working nicely in plain 'Memory expansion' mode - all without anything close to an acceptable +5V supply. It's hard to believe that any of them could have managed to work so well.

All I can say is, I'm glad Tim opted to leave the diode (D2) in because that was what finally drew my attention back to that area. If his had been linked out from the start, that wouldn't have been an issue which needed to be considered and I wouldn't gone there.

Just off to give it a shot now.

SiriusHardware 23rd Aug 2021 5:22 pm

Re: Ortonview PCB
 
Quote:

I should have documented it better
Don't kid yourself, the documentation, which included the circuit diagram, was fine and contained enough info for any half-wit (...almost any half-wit) to pick the right diode to bypass to put a direct supply on the 6116.

Back in a bit....

SiriusHardware 23rd Aug 2021 5:48 pm

Re: Ortonview PCB
 
Straight in with the three worst RAMs, the Hitachi HM6116LP-3s, and all give a rock steady picture when OrtonView is rendering from 0200-03FF. I've left the third one in and I will run it for an hour or so to make sure no pixels get knocked about during that time.

I haven't (yet) regressed the decoupling capacitors to the original fitted values, I think that following Mark's observations I will keep the 10uF SMDs on the PIC pins but will otherwise take most of them back down to 0.1uF, and I will keep the additional two 0.1uF across the video output supply rails and the 6116 pins. Of course the 220pFs on A8-A11 are still there as well.

I'll be happy with this for a while, but then I may go back to trying to get the buffers working again now that I have a sensible supply arrangement for the 6116. Still determined to get rid of those capacitors eventually, if at all possible.

Mark1960 23rd Aug 2021 6:23 pm

Re: Ortonview PCB
 
The documentation was almost not needed. The silkscreen of the component values made it much quicker to assemble, just needed to make sure I fitted 4k7 for NWDS. One thing that would be nicer would be to move the reference designators on the silk screen so we can still read then after the components are fitted. I don’t know how easy that is with kicad.

I’ve searched again for my spare scope probes and still not found them, so ordered a cheap set from Amazon to use on external trigger so I can look at both NWDS and an address line at the rising edge of NENIN. I’ll probably find them tomorrow when its too late to cancel the order. The search wasn’t a complete waste of time, I found my original MK14 manual and SC/MP technical manual, both a little worse around the edges for having been in a damp garage for a few years but still readable.

SiriusHardware 23rd Aug 2021 6:36 pm

Re: Ortonview PCB
 
You would be surprised how much an original MK14 manual can be worth. The last one that caught my attention ended up going for more than 40 GBP. Just the manual.

Not that I imagine you would want to sell yours.

I have two, my original one which is covered in horrible teenage biro scrawl and another very clean one which I bought for less than a tenner, although that would have been about 10 years ago now. Both are V1, they describe the operation of the system with the original OS, not the revised OS.

SiriusHardware 23rd Aug 2021 6:57 pm

Re: Ortonview PCB
 
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?

audiokit 23rd Aug 2021 6:57 pm

Re: Ortonview PCB
 
Glad any of us makes an (afterwards obvious) mistake every now and then. Just think about it as making a journey, all the fun is the journey itself. Of course your goal is to get it working but you will find out that most of the fun has gone. I just try to follow the discussion, a bit difficult when you don't have your hands on the same PCB but still interesting. I am currently in the end process of making a complete Elektor SC/MP computer with 3 wirewound PCB's and a separate keyboard + display. Still enjoying the yourney meaning it doesn't work (yet) ;)
Benny

SiriusHardware 23rd Aug 2021 7:07 pm

Re: Ortonview PCB
 
I think Slothie is holding one OrtonView PCB in reserve in case his first prototype catches fire (more likely, in case it starts falling apart due to constant modification) - who knows, that spare PCB may become available.

If not, the project is simple enough in hardware terms to build on stripboard, especially if you build the original version (without 74LS365 buffers, but with some kludge capacitors on A8-A11). It should hang onto any SC/MP system quite easily, the design allows for any two 256-byte blocks of RAM in the address range 0x000 to 0xF00 to be mapped as the screen RAM.

Mark1960 23rd Aug 2021 7:13 pm

Re: Ortonview PCB
 
Hi Benny

We’ll look forward to seeing your Elektor SC/MP computer whenever you feel ready to show it working or share some of the fun, finding out why it doesn’t.

Is it old style keyboard and display?

Mark

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.

Slothie 25th Aug 2021 6:16 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1401276)
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.

Ah! I didn't catch that. Maybe NENIN and XCLOCK do need syncing somehow.

SiriusHardware 25th Aug 2021 6:23 pm

Re: Ortonview PCB
 
Quote:

we had that issue when I was trying to scope the problem before and was why we tried the capacitors
You had it in a different sense as well, when you were hanging one of those parallel logic sniffers on the high address lines - doing that made the fault clear. In that specific instance I think you narrowed it down to the A10 line being the one which was making the difference.

The capacitors were ultimately Mark's suggestion but the idea may have come from your original observation that hanging something on those lines made the fault go away, plus my own (much earlier) experience of having 'fixed' a computer fault which went away when a scope probe was put on a particular pin, by soldering a 1M resistor and 50pF capacitor from the pin to 0V (To make the pin 'think' it had a scope connected to it).

Slothie 25th Aug 2021 6:24 pm

Re: Ortonview PCB
 
Well I've just received some 74LS74's and found a few other spare gates so I might be able to do some experiments tomorrow. looks like its proto-board time!

Now I am wishing I'd made the top corner of the board a prototyping area after all :D

SiriusHardware 25th Aug 2021 6:26 pm

Re: Ortonview PCB
 
It kind of already is, just lop a few of the existing interconnecting tracks... power pins will still be in the right place.

Timbucus 25th Aug 2021 6:34 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1401292)
Quote:

we had that issue when I was trying to scope the problem before and was why we tried the capacitors
You had it in a different sense as well, when you were hanging one of those parallel logic sniffers on the high address lines - doing that made the fault clear. In that specific instance I think you narrowed it down to the A10 line being the one which was making the difference.

The capacitors were ultimately Mark's suggestion but the idea may have come from your original observation that hanging something on those lines made the fault go away, plus my own (much earlier) experience of having 'fixed' a computer fault which went away when a scope probe was put on a particular pin, by soldering a 1M resistor and 50pF capacitor from the pin to 0V (To make the pin 'think' it had a scope connected to it).

That sounds correct - better memory than me...

Mark1960 25th Aug 2021 7:09 pm

Re: Ortonview PCB
 
I think adding the 74ls74 as described in #275, possibly also connect NENIN from PIC to clear on the 74ls74 so that when NENIN goes low there is not so much of a delay in NENIN going low to the 8060. This would also add a little setup time from NENIN going high prior to rising edge of the clock.

I’m hoping there is no need to fine tune the delay of NENIN to the 8060 with any RC delay.

Pure guesswork but suspect there is a setup time inside the 8060 for NENIN high to the rising edge of xout, or its internal equivalent, and the setup time might be different for the address and NWDS control. Registering NENIN to xout should give maximum set up time to the next rising edge so that both the address control and the NWDS control are triggered on the same clock cycle.

Suspect Slothie might beat me to it, but I’ll also try adding a 74ls74 on protoboard.

Mark1960 25th Aug 2021 7:21 pm

Re: Ortonview PCB
 
The other thing I noticed yesterday is that the address lines are not pulled high to give good high logic level. It might be good to add pull up resistors, though that would make the corrupted write issue worse. Maybe if adding the 74ls74 works we can see if it still works with pull up resistors, that should make it worst case for the corrupted write issue.

Slothie 25th Aug 2021 7:22 pm

Re: Ortonview PCB
 
Well if it does work then it would explain why its so random and it varies over time.

SiriusHardware 25th Aug 2021 7:29 pm

Re: Ortonview PCB
 
Quote:

The other thing I noticed yesterday is that the address lines are not pulled high to give good high logic level
Do you mean when OrtonView is actively trying to drive the address lines? I would be surprised if so, as the PIC has very strong output drive. I thought I remembered the address lines being driven from rail to rail when it is the PIC which is driving them.

Mark1960 25th Aug 2021 8:23 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1401317)
Quote:

The other thing I noticed yesterday is that the address lines are not pulled high to give good high logic level
Do you mean when OrtonView is actively trying to drive the address lines? I would be surprised if so, as the PIC has very strong output drive. I thought I remembered the address lines being driven from rail to rail when it is the PIC which is driving them.

No the PIC drives them rail to rail, probably too strong, I might still put in series resistors later.

8060 doesn’t drive the outputs very high, I guess that should be expected for nmos.


All times are GMT +1. The time now is 2:17 am.

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