Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

I've just done a 'lite' version of this test below,

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.

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.

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.

Re: Ortonview PCB
 

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

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?

Re: Ortonview PCB
 

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:
The address bus is incremented at the end of the
The code for each line looks like this:
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.

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. ;)

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

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!

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.

Re: Ortonview PCB
 

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....

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.

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.

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.

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?

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

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.

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

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.

Re: Ortonview PCB
 

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.

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.

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?

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

Re: Ortonview PCB
 

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

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.

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.

Re: Ortonview PCB
 

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.

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.

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

...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?

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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).

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

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.

Re: Ortonview PCB
 

That sounds correct - better memory than me...

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.

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.

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.