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!