Re: Ortonview PCB
 

Yes I had thought about exchanging boards as a solution but, I have a DIN on mine. Anyway I will put some RAM's in the post tomorrow that I know work my end.

Re: Ortonview PCB
 

Thanks Tim, happy to send them back once they have proved things one way or the other. I suppose the other thing I can try is to program one of my Spare 877s to see if that makes a difference.

Re: Ortonview PCB
 

It might be worth checking the continuity of the A10 line from the edge connector to the buffers. I was assuming I damaged mine removing the capacitor, but its possible theres a marginal connection due to some manufacturing/design defect. When A10 was broken it did some really wierd things....

Re: Ortonview PCB
 

Indeed as I said over on the Uploader thread one of the Vias was not fully connected.

Re: Ortonview PCB
 

Will do. It would be hilarious (not) if the A10 track turns out to have about 1K resistance between A and B. Were these made by JLCPCB? I know the uploader PCBs were made by a different outfit.

Re: Ortonview PCB
 

Nope. Nice low resistances from A0-A11 to the buffer pins and onwards to the PIC pins. Also good low resistances from A9-A11 to the address decoder IC (HCT02) pins.

One thing I did notice while I had the LS02 in, if I fitted my 'best' 6116 RAM and uploaded Clive and watched for a while the image slowly started to get little bits knocked out of it - in other words it continues to get slowly corrupted even when the monitor is not writing to or reading from that area - and the Ortonview is only reading that area.

With the HCT in I wasn't noticing that, but maybe it would have happened, just more slowly, had I let it run for long enough.

Throughout all of this the OS / MK14 continue to run normally as far as I can see as long as the 6116 in the Ortonview is one of the ELCAP ones.

Re: Ortonview PCB
 

The Ortonview PCB was made my JLCPCB and the uploader ones by AllPCB.

Re: Ortonview PCB
 

I wasn't sure about the OrtonView PCBs as the quality of the screen printing seems a bit more 'draft mode' than on the MK14 issue VIs where it was very clearly and densely printed.

When I was trying to buzz out the A0-A11 lines last night I did miss having the names of the signals printed on the underside of the PCB as well as the top side. ;)

Re: Ortonview PCB
 

The last couple of things I've had done by JLCPCB have had poor screen printing, maybe its just coincidence, it used to be really good (as on the MK14 PCBs that you had made). They do a good job otherwise. I was impressed with AllPCB but then they knew I was a new customer

Just after I had sent the files off I thought I should have labelled all the connections on the back, but there you are!! They've been useful on the MK14 several times for me.

Re: Ortonview PCB
 

I've removed everything from the PCB that is not vanilla, such as the RC timing mod on the output of the HCT02 buffer enable gate, in case that is somehow upsetting the operation of the other gates in the HCT02 (though I would expect not).

I've also removed the turned pin sockets meant for the capacitors and soldered 4 x SMD 220pF directly to the pads to remove any doubt about whether the capacitors are properly connected.

I'll have another tilt at it tonight. If there is no change I'll drop one of my spare 877s in, and if still no change I'll pause until Tim's RAM samples arrive.

Re: Ortonview PCB
 

The RAM's went in the first class post lunchtime so hopefully not too long.

Re: Ortonview PCB
 

Cheers Tim - in that case I might give myself a night off and do the next round of testing when those are to hand.

Re: Ortonview PCB
 

Against my better judgement I powered the system up again only to notice that the gradual corruption of screen memory 0200-03FF was suddenly a lot worse, with the Clive image slowly deteriorating over time even when the system was doing nothing but waiting at the 0000 00 prompt. This was much worse than when I was playing last night, so what had I done?

Then I remembered one significant difference - a while ago, fellow forum user kan_turk sent me another pair of 27S13 PROMs which I bought with a view to comparing their power consumption with that of the 82S131 / DM74S571, both of which run quite hot. As I had the device programmer down anyway to test all my 6116s, I took the opportunity to program the 27S13s with the 'new' OS, put them in, made sure the machine came up with the correct prompt, then put the machine away.

Just now, when the Clive image was looking very much like a breakout demo, I still had the 27S13s in. So I changed back to the usual DM74S571s and it was back to almost completely stable with my 'best' 6116 in.

From this, I conclude that among other things the fault is causing the system to try to write to addresses in the ROM area 0000-01FF - you'll remember that the address decoding is so primitive that it does allow an attempt to write to that area, and I also conclude that for some reason this causes more 'harm' when trying to write to 27S13s than it does when trying to write to 74S571s.

Re: Ortonview PCB
 

Except that the PROM enable on an Issue VI is gated on NRDS so writing to 000-1FF does not enable the PROM.

Re: Ortonview PCB
 

Oh the mystery deepens...

Re: Ortonview PCB
 

You had to go and spoil it. Now I'm really stumped.

Re: Ortonview PCB
 

Luckily I haven't really dismantled the original bridge / memory board and lashup Ortonview so as a fallback I will reassemble it over the next few days and see if it still works perfectly. The main problem there is that the 6116 RAM is soldered flat on to the underside of the bridge / memory board so I can't easily play with the RAM type.

Re: Ortonview PCB
 

I wonder if the problem you are having is also due to interrupted write cycles, not only affecting the high address lines but also the lower address lines. The 27S13 might have a slightly different effect on address line loading.

Re: Ortonview PCB
 

I can't remember how long your PROMs took to get there Mark, would expect possibly up to another week or so before the boards seem overdue. It'll be interesting to see if yours 'just works' in Vanilla mode.

One thing I have observed is that some of the bus lines on the board run parallel and very, very close to each other at times which could give rise to the possibility of crosstalk / mutual induction between one signal line and the others next to it, but if that was my problem, why only for me and nobody else?

Re: Ortonview PCB
 

Yes, the boards might not arrive for another week or two, but they could also turn up any day now.

I think its unlikely to be a problem with crosstalk at the kind of frequencies the mk14 and ortonview are running. Edge transition times from the PIC might be fast enough to cause ringing but should be settled before the control signals are active at these kind of access times. I was thinking about adding series resistors in place of the buffers but I’ll stick to the basic design until I confirm the memory corruption without the address bus capacitors, verify the capacitor fix and then try some experiments.

Re: Ortonview PCB
 

When I had my original SOC VDU connected to my original MK14 way back when, all the connections were done with tack-soldered flying insulated wires between the MK14 PCB and the two rows of holes on the SOC VDU. Not only did it look horrendous but it was quite unstable, I would often get various displayed characters flickering randomly until I teased the wires apart to try to keep them away from each other as much as possible, given so many wires heading in the same general direction from A to B.

When I built the 'bridge board' to connect the issue VI (with edge connector) and the SOC VDU (with DIN connector), operation of the SOC VDU and then OrtonView was completely stable, so layout and solidity do have some bearing on the outcome. As it happened, I made this 'bridge' board quite long so it also provided a handy place to put the 1.5K memory expansion.

I've found my spare 16MHz crystals, the only thing I really stole from the original OrtonView to get the PCB based one working, so I'll try a system restore and see if that gets me back to a fully reliable OrtonView. It will give me a way to test the PIC independently of the PCB-built version.

I'm back in the mode of being away for weekends so I may not be able to make any progress until Monday.

Re: Ortonview PCB
 

I'm beginning to think that there may be a problem with the Issue VI. I was writing a program to thrash the memory, in the hopes I could do a long logic analyser capture and catch it misbehaving. The program crashed despite being loaded into extended memory which I write protected, with a PC address of 083C or similar.
I then re-assembled it to run in standard memory, disconnected the Ortonview, and ran the program. It ran for a second or two the dropped back into the monitor at location 0FCB - miles from where it should have been.
If someone has more skill than me in SC/MP assembler, please look at my code.

Re: Ortonview PCB
 

I am joining DragonTalk live tonight on YouTube in a short while but, one thing I could do in the morning is punch that into my JMP MK14 and see if it does the same for you.

Re: Ortonview PCB
 

I think that should have been jmp start instead of jp start to stop it running off into the weeds.

Re: Ortonview PCB
 

Ah! You are right, JP is jump if positive, not plain jump. I should read more carefully!

:dunce:

Re: Ortonview PCB
 

I find that one confusing too, as jp is unconditional jump for z80, so very easy mistake.

Re: Ortonview PCB
 

Well after my slip up with assembler I corrected it and now with the Ortonview disconnected my memory test runs as expected. Connect the Ortonview with the VDU switch off and the program runs without crashing. Flick the VDU on, and you see errors on the screen and the program stops running in a manner of seconds. (The 'mfill' bit just fills the memory with zeroes so when Ortonview is mapped onto it is easier to spot the corrupted memory)

I've got my INS8154 fitted, so I'm going to have a go at relocating the code there and to the extension memory and see if there are any significant differences in behaviour. I'm a bit happier now because if I can reliably provoke the fault then its easier to tell if you've fixed it and theres more chance of catching the fault in action with the logic analyser.
Might have to invest in one with more than 8 channels.....

Re: Ortonview PCB
 

It might be that the software you are using supports more than one connected input device, if so maybe you can just add another of those low cost 8-channel ones for 16 parallel inputs. I suppose ideally you want a minimum of 32 inputs so you can monitor all of the address bus, all of the data lines, all of the control lines and maybe a chip select or two.

Re: Ortonview PCB
 

The original mode of the corruption which was occurring with the OrtonView as originally designed - direct address connection, no capacitors on A8-A11 - was quite specific, if a program continually wrote to address 0Fnn then occasionally, the same address offset of nn in other 256-byte address blocks would get changed as well. Not to the same character as the one which had been intentionally written, but instead to a value always with the second hex digit = F.

This was first noticed when running programs which were resident in 'standard' RAM 0Fxx and writing to 0Bxx, with the VDU pointed at 0Fxx (upper screen) and 0Bxx (lower screen) with the output of the program going to the area 0Bxx.

Because writing to 0Bxx sometimes also caused writes to 0Fxx, this was causing the program to slowly destroy itself.

The other 'reliable' indicator that the corruption was taking place was the appearance of the reverse 'C' character on the third from right display some time after the machine has been started and left running at the 0000 00 prompt.

This being the case, the best way to keep a program running so that the corruption could be observed continually was to place the test program itself in I/O RAM 0880-> but confine any test writes to other memory blocks to somewhere in the range 00-7F. so that the rogue writes would never corrupt the test program resident at xx80 upwards.

The above problem is the problem which fitting the four capacitors to A8-A11 eventually fixed, at least on both my and Tim's original builds of Ortonview.

Re: Ortonview PCB
 

I think the suspicion is that when a write cycle is interrupted the data and address lines are tristated before the NWDS, perhaps dependent on the timing of the interruption.

The second hex digit = F may be due to pull up resistors on only 4 of the data lines while NADS is still active.

Writing to Fxx instead of the intended Bxx is possibly due to the pull up effect of the 74ls ttl address decoding of the mk14 on the 4 highest address lines, again while NADS is still active.

What doesn’t seem to have a simple explanation it the reverse C on the mk14 display, though the C is possibly due to the data pullup resistors, but not sure why the address written would correspond to the address used by the mk14 for the third digit of the display.

Its possible that its not only the 4 high address lines that change while NWDS is still active.

Maybe this is similar to the problem Sirius was having with the extension memory.

It might be worth adding trying capacitors on all address lines, though according to the INS8060 spec the maximum capacitance on outputs is 75pF, so I hope we are not risking damage to the 8060 output drivers.

Re: Ortonview PCB
 

Possibly, although I didn't actually have that specific problem with the memory expansion on the original build. I'll fire that up again tonight to see if it is still solidly reliable in final vanilla mode (direct address connections, 4 x capacitors).

Re: Ortonview PCB
 

On the subject of possible differences between systems, hands up who did did fit the onboard regulator and electrolytic capacitor(s) on their Slothie-Ortonview PCB?

I didn't fit the regulator or the associated capacitors, apart from what would have been the output side disc ceramic capacitor. The +5V supply is jumped across to the empty output terminal pad for the regulator. I did however populate every position provided for 0.1uF supply decoupling capacitors.

I have yet to take a scope to this problem. No doubt when I do I'll find that there is about a volt of noise on the OrtonView 5V rail because I didn't fit the 5V rail electrolytic.

Re: Ortonview PCB
 

Last night I changed the program to run in E80+ memory with its variables there, writing to Bxx and the program memory doesn't seem to corrupt but random writes are made to memory in Fxx. This is pretty predictable too. I'm continuing to play with other configurations. If the random writes tend to go to Fxx then that would indicate the address high bits being pulled high too quickly?
I've thought of a few other avenues of investigation last night so I'll see if I can try a few of those too.

Re: Ortonview PCB
 

The theory was that, due to the presence of the PIC pins on the address lines, the address lines were swinging high while the NWDS pulse was still active, causing writes to two locations, although, as the same data does not get written to both the intended location and the other location, said address swing must be occurring while NWDS is still active but after the data has been removed from the bus so that the second write writes the undriven state of the databus. Or something else altogether.

The buffers were meant to show whether this theory was good or bad by disconnecting the PIC pins from the address lines whenever they did not need to be connected, but on the basis of what we have seen so far they don't seem to make a difference to the original problem which still requires the A8-A11 capacitors to fix it whether the buffers are used or not.

The capacitors appear to slow down the rate of change of state of the high address lines and that 'fixes' the fault.

I don't think it has been established, either, whether the rogue write to another page takes place as well as - or instead of - the intended write to the intended location. So maybe a bit of software resident at 0880-> which continually writes to the low half of 0Bxx - which in itself will cause occasional writes to the same offset addess in 0Fxx - but then also checks the content of 0Bnn after each time it has written to that address to see if the intended data does get written to the intended location every single time.

Re: Ortonview PCB
 

Well I've been playing with pulseview and my logic analyser and discovered how to get it to trigger on a number of conditions. If you set it to trigger when the top 4 address bits are 1 (i.e. Fxx) and the NWDS is 0 (I.E. write cycle in progress) then it never triggers. Change it to trigger on writes to Exx (The RAM where the counter variables are) it always triggers, Change it to trigger on writes to Bxx (The bottom of the screen) and it always triggers. Set it to trigger on writes to Fxx and it never triggers. Except that you can clearly see the bytes in the upper screen changing, and if you stop the program and look in the memory the bytes have changed in the memory. If you don't enable the VDU (so the PIC never interrupts the SC/MP) then the memory doesn't appear to change either.

Weird.

Re: Ortonview PCB
 

I won’t be fitting the regulator as I don’t have a regulator on the mk14, I just feed it 5v from an external power supply.

I’ll just link out the buffers. I was considering using resistors but that would introduce another difference that might change the problem.

I’m going to try to isolate NENIN at the connector, with a link to the PIC, as that would allow me to play with NENIN timing later.

Re: Ortonview PCB
 

This would be difficult to prove, as the 8060 will repeat the write cycle when the bus is returned to it after an interrupted write. We would have to detect the interrupted write and then reset the 8060 before it can repeat the write cycle.

Re: Ortonview PCB
 

This was also on my to-try list as it is another way of reducing the amount of influence the PIC pins (in input mode) have over the system address lines. In output mode the PIC pins have very strong drive capability both high and low so it would take quite a bit of resistance to weaken the address drive from the PIC to the address bus, although the greater the resistance the greater the significance of the total capacitance all connected devices present to the address lines.

Re: Ortonview PCB
 

Is it only triggering on a falling or rising edge of NWDS?

It might just be the sample rate of the analyzer is not fast enough to capture the event, or that the analyzer sees a different logic threshold to the sram.

Re: Ortonview PCB
 

I tried both rising and falling edge, and just a zero level. It triggers if I try matching something other than all top 4 address bits high.
I'm wondering if its glitches on the NWDS line now, but for a write to work I would have thought the 2111 memory would have to see the write pulse low for a reasonable length of time. I''d prefer it if I could use an oscilloscope to look at it, but I only have access to a BS05 Bitscope USB scope and I have a lot of problems sorting the triggering on that. Its a very weird device, probably reflecting its cheap price!

Re: Ortonview PCB
 

I've got my original build of Ortonview on my 'Picduino' veroboard with the original bridge / memory board sitting in between, Vanilla mode (direct address connection and 4 x 200pF caps on A8-A11) and the extra memory is rock steady and reliable, I can load into it over and over again and the only bytes which get changed are the ones which are being loaded into. I can leave it running for ages after that and the images is completely stable, never changes. With the equivalent setup on the PCB version I see random bits being knocked out of the image over time until it eventually becomes unrecognisable.

Having found that the original concept and the original PIC do still work as expected I'll pause for tonight and tomorrow I'll go back to the PCB version and try the RAMs Tim loaned me, I'll also try fitting an electrolytic across the 5V rail because that's one thing the 'Picduino' does have that my PCB currently does not.

Re: Ortonview PCB
 

Mine does have the Electrolytic fitted although I did bypass the regulator... you will find the problem I am sure.

Re: Ortonview PCB
 

Well, I fitted a 100uF capacitor to the 5V rails and I'm a small step further on, as my 'good' EL6116LP-10 now gives me completely stable results just with that one change.

Going through a selection of the RAMs I have available including Tim's samples, I get:

M5M5117P-15 - completely stable.
EL6116LP-10 (#1) - now completely stable.
EL6116LP-10 (#2 - #5) - slow corruption of the 0200-03FF screen RAM area with the machine just sitting at the 0000 00 prompt.
Hitachi HM6116LP-3 (#1-#2) - system goes haywire.
Hitachi HM6116P-4 - system goes haywire.
MK6116N-15 (#1, #2) - system goes haywire.

So at the moment the one benefit of fitting the electroytic is that it has made a single EL6116LP-10 RAM which was already almost reliable, completely reliable. At the moment I'm obviously a long way away from being able to just drop any old 6116 into the board. One good result is that Slothie's chosen M5M5117P-15 happens to be one of only two ICs which works really reliably.

I'm now going to take all the removable parts off the PCB and just do some basic measuring of, and between, tracks.

Re: Ortonview PCB
 

M5m5117p-15 spec shows th data hold time 0ns, trec of 10ns looks to be address hold time in the timing diagrams.

Mk6116N-15 spec shows tdh data hold time 0ns, tah address hold time of 10ns.

Hm6116lp-3 and P-4 spec shows tdh data hold time 10ns, twr of 10ns looks to be address hold time in the timing diagrams.

Not much difference between them as far as spec is concerned but its possible the 5117 has more margin to spec.

Re: Ortonview PCB
 

Well I can assure everyone that I didn't design in a "trap" to make only M5M5117P RAMS work on the board! I'm a little surprised its making a difference. Perhaps I should take a closer look at the 6116 data sheets to see if there are any significant differences.

Measurements show that the access time from setting the address to the end of the read/write cycle is 500nS minimum, and the time the read and write pulses are low is still ~250nS of that, so it shouldn't be sensitive. The read cycles from the PIC are even more relaxed than the SC/MP timing, so I really don't think that memory speed is a factor. Perhaps the data bus isn't stable for that entire time, which is why things are not great.
I am beginning to think it might be noise on the NWDS pin, I have been occasionally catching very brief pulses when I wouldn't expect them (for instance, with no NADS pulse before them, or a long time after NENIN has gone high) but they are very brief. Maybe thats enough to corrupt the memory? Also I only seem to be experiencing corruption in the Fxx memory segment when continuously writing to Bxx. I've been trying various scenarios but not really coming to any conclusions, but by putting the program in the RAM/IO, writing to Bxx it will run almost indefinitely with random corruption in the Fxx memory block. After a while running like that looking in the memory at 200-> shows it is completely unchanged.
I currently only have the 2 10k pullups on NWDS but I am going to change one of them to 4.7k since I recall Sirius saying that improved things, but before I do that I will need to find my Bitscope and have a look at the signal so I can get "before" and "after" shots!

Re: Ortonview PCB
 

Thanks for the research, Mark.

I might try your series decoupling resistor idea as that would be easy - just replace the wire hoops I currently have plugged into the buffer sockets with vertically mounted resistors. I wonder if you had a value in mind?

I don't see any DC problems on the tracks on the PCB. Somewhere around here I have one of those cheap microprocessor based capacitance meters - not sure how low in pF value it goes but I'm now wondering if some of the long parallel runs of tracks with very small gaps between are forming low value capacitors (ie, two long parallel conductors separated by a very narrow band of insulator).

I may ultimately sever the address, then data tracks at each end and remake / reroute them with kynar wire to spread them further apart. That's how all the buses are wired on the original build.

Just caught Slothie's post: I assume, Slothie, that you are working with a vanilla install in which you intentionally have not added the A8-A11 capacitors in order to produce the corruption so you can observe it. Unfortunately it would seem that you are accidentally using a best case scenario RAM so you aren't getting the problems I am getting with so many other examples of 6116 types including one (HM6116P-4) which appears to work OK for Tim. Maybe I can send you one of my HM6116P-3s down - one of the ones which stop the system working, to see if it works equally badly in yours? It will give me a better idea of whether I am trying to solve a problem unique to my particular PCB.

Re: Ortonview PCB
 

I was thinking 100 ohm, but that was just to try and put some current limit between the pic and 8060 to try and protect from bus contention if we are making changes to the pic code.

I don’t think it would help with corrupted ram, maybe caps on A0 to A7 in addition to A8 to A11 is worth a try.

Re: Ortonview PCB
 

Produced by what, the NWDS pin on OrtonView?

One stunt I have sometimes used when trying to debug or hack i.e., i2c comms, is to put a resistor in series with the data drive pin on the master or slave so that the two devices pull the data line to different low levels - that way I can see which device is 'talking' at any given time, the master or the slave.

You could do something similar here, put a Schottky or ordinary diode in series with the OrtonView NWDS output so that NWDS pulls the write line to a different logic low level than the SC/MP does. If your 'random' NWDS pulses have the same low level as the ones known to be coming from the OrtonView's NWDS output, you know they are coming from OrtonView.

Re: Ortonview PCB
 

If these 'unwanted' NWDS pulses you might be observing are much briefer than 'proper' NWDS pulses of regulation length, then maybe play with a capacitor from NWDS to 0V - value weighted to take out needle-thin pulses, but not 'regular' NWDS pulses?

Re: Ortonview PCB
 

That might delay the rising edge of NWDS and make the problem fixed by capacitors on A8 to A11 worse, though that would be another useful piece of information.