Re: Ortonview PCB
 

She did, and the SOC VDU must have had a similar post-nenin-edge delay in hardware to allow the SC/MP time to get off the bus before jumping onto the address bus itself. Just on a quick look around, the onset of the output of the signal to NENIN itself is actually delayed by an RC network on one of the inputs of IC5, namely R15 / C11. There's also the strange 74L86 which as Slothie once pointed out has a propagation delay far longer than standard TTL, so maybe that is intentionally brought into play for delay purposes.

Re: Ortonview PCB
 

Probably not a lot of arm twisting needed to get the VDU's out - probably no time until this weekend though due to work and other family commitments.

Re: Ortonview PCB
 

During the original troubleshooting phase we did a lot of scoping of NENIN vs. other signals including NENOUT which I seem to remember is the signal which shows when the SC/MP has relinquished the bus in response to a request on NENIN. From that, we were able to arrive at a likely maximum interval between NENIN rising and the buses being relinquished.

That's the delay we need to insert between the rising edge of NENIN and the buffers being enabled.

Re: Ortonview PCB
 

Ah, here we go. (Image 1). This shows the SOC VDU relationship between NENIN (top, active high) and the buffer enables (bottom, active low).

Bear in mind that on the SOC VDU NENIN and the buffer enables are enabled for a whole video line at a time, but this still shows a substantial delay between NENIN being taken high and the buffer enables being taken low.

The second image shows the delay between the rising edge of NENIN, output from the VDU, and the response from the SC/MP on NENOUT. In theory, you can not try to go onto the bus yourself until this delay has elapsed. It looks like around 160-170ns to me. Of course NENOUT is not available to the VDU so the rising edge of NENIN needs to be followed by a fixed delay slightly greater than the maximum time it takes the SC/MP to let go of the bus, after which delay the buffers can be enabled.

Re: Ortonview PCB
 

True, I just hoped we might get away with it as it will also take a certain amount of time for the SC/MP to come back onto the buses after NENIN is released low.

Unfortunately it's not two enable inputs acting in NAND fashion to enable or disable the whole buffer IC - instead, each active low enable independently controls three of the six buffers in the chip.

Re: Ortonview PCB
 

74ls365 has two inverted inputs to an AND gate to enable the six buffers.

74ls367 has separate enable for a group of 4 and a group of 2.

Slothie has connected both enables together so could use either of the above.

Re: Ortonview PCB
 

Scope plots in #104 for NENOUT is close to the datasheet, but should be a maximum of 150ns.

There would be a problem using NENOUT to gate the buffer as NENOUT is also high whenever the 8060 is using the bus.

Its not very clear in the 8060 spec that each memory access is 2 micro cycles. Its more obvious in the sc/mp technical manual that every instruction starts with a two microcycle instruction fetch. We might have just got away with a two micro second delay for the 8060 to finish using the bus and use NBUSRQ to stop bus access at the end of the current memory cycle. Unfortunately the ILD and DLD instructions would not release the bus until after 6 micro seconds as the bus is not released between the read and write cycles.

Re: Ortonview PCB
 

Yep, I must have been tired when looking at the pinouts last night. You could maybe also use a diode across the R of RC to make the delay asymmetrical, so that disabling is faster than enabling.

Using NENOUT directly has to be ruled out simply because it is not available on the edge connector of any MK14, not even the issue VI. It provides us with a good indicator of how long any NENIN->BufferEnable delay may need to be, but that's all.

Re: Ortonview PCB
 

At what CPU clock frequency? My Issue VI (from which those waveforms were taken) has a 4.00MHz crystal fitted so that it can be used with my SOC VDU.

This is another variable we need to be aware of: Many people may be running at 4.43MHz - The only reason anyone ever changed it to 4.00MHz was to make the system work with the SOC VDU.

Re: Ortonview PCB
 

It should be pointed out that in the "master plan" the r1.3 board was going to have NENOUT on pin a30 of the connector (next to NENIN), and that r1.2 boards can be modded thus..... :) However I don't see there being an r1.3 board any time soon unless a pressing need for some other change is found.

The instruction cycle of the PIC is 250nS with a 16MHz clock, so provided the software isn't putting NENIN high and enabling the buffers at the same time it will have at least that delay. I think the problem with the PCB is that I *don't* delay enabling the buffers. I'm going to be looking into this.

Re: Ortonview PCB
 

Its not clear if the delay is clock related or just propagation delay, but 150nS should be safe for faster clocks I would imagine.

Re: Ortonview PCB
 

Those pads you originally provided for the ICs of the noise generator could come in pretty handy for any extra gates you might need...

Re: Ortonview PCB
 

Noooooo! Not my noise maker!!

Re: Ortonview PCB
 

I would honestly just try an RC or RC+diode in the line between the enabling gate and the enables of the buffers, the diode being a bypass for the R so that it slams the enables back off more quickly when NENIN goes back low.

I wonder whether Karen is looking down on us now, arms folded, fingers strumming on her elbows and a wry look on her face. We'll never know whether she would have been pragmatic enough to accept the four capacitor bodge as an acceptable solution, especially as it keeps the 'extra component' count, that is, major components in addition to the PIC, very low.

In the Mk1 version of her PIC14 she noticed a problem where the driver transistors for the display commons weren't switching fast enough and while she suggested an intermediate solution using a buffer IC, that had its own problems because the buffer outputs were totem-pole type and they were liable to clash when two keys on different columns were pressed at the same time. She then went back to V1 and put capacitors across the base resistors of the driver transistors - so fixing little problems with capacitors is an entirely authentic Karen method.

Re: Ortonview PCB
 

One possible solution that I'm thinking of is to cut the 3 tracks that link pins 1 & 15 on the buffers to separate the enable pins, and put a RC circuit between pin 15 and pin 1 so that on the falling edge of the inverted NENIN signal (from U1d Pin 13) pin 1 goes zero ~150nS after pin 15. On the rising edge when NENIN is removed the buffer will immediately disable because pin 15 goes high. A 1k resistor and 150-200pF capacitor should be about right.

But before I start hacking away at the PCB I think I will remove the loading capacitors and see if there are any tweaks I can make to the timings in the software. Given that it originally worked without problems but was slow because it took up too much bus time, then there should be some tweak to make, and I think if Karen had been given the time to look into it she would have solved it in the software, but she was up against an unmovable time limit...

This was my plan for making the board in the first place. But the good news is that it does work with the capacitors as you and Tim established, and some of the work of trying out the buffers has been done if we need to go in that direction. If we need more board space for extra logic then I'd just cut the track between U1 and the buffers and run wires to a daughter board.

Re: Ortonview PCB
 

In the software, timing is everything, every cycle counts. I think Karen must have written a little utility to count instruction cycles for her - or else it was all just in her head. Probably the latter.

That's what I would find daunting about modifying the software. Knowing what functional change you want to make is one thing, but making that change while still retaining the exact number of instruction cycles within the same time period is the real trick.

Re: Ortonview PCB
 

By the way, we don't definitely know that the 'slow' version worked without the corruption problems.

When it became apparent that it was causing too much system slowdown it was more or less abandoned when Karen fairly quickly came up with the 'fast' firmware which held NENIN high for much shorter periods of time, so I'm not sure that the slow version got stress tested as much as it should have been.

I might try your hardware suggestion (which I think was also suggested by Mark a few posts ago), ref. delaying the buffer enable but not the buffer disable. My main interest in getting the buffers working is to prove whether the problem is or is not due to the fact that the PIC pins used to drive the address lines do not completely disengage from the address lines the way the address drive pins on the SOC VDU do.

That would be a useful thing for you to know one way or the other even if you prefer to try to solve it ultimately by tinkering with the code.

Re: Ortonview PCB
 

i think its totally a good idea to find out, and if you get to it first then go for it. In fact, it will be easier to cut the tracks before you fit the DIL sockets - for me, its going to involve something akin to keyhole surgery because the tracks are on top of the pcb and the DIL sockets are kind of in the way!

Since I've not published the layout, I'll do a diagram of what I was thinking of doing to make it a bit clearer.

Re: Ortonview PCB
 

Yes, fortunately most instructions are 1 cycle, and if I remove any instruction I can replace it with a NOP, if I need to add instructions there are DELAY macros that can be ajusted to suit and only a few places where timing is super-tight. But you're right, the timing needs paying close attention to, any errors are likely to cause on-screen jitter or complete failure of the picture.

Re: Ortonview PCB
 

Here is the mod and a zip file of it in case forum compression kills it.

The white blobs are where the tracks would be cut, and the blue lines are links. The yellow components would probably go on the back (1k & 220p).