Mk14 vdu

[Buzby123]

Yes, I am totally serious.

If Karen had the tools in her hands I'm sure she would come up with the solution in a few hours.

A webcam might be used to view the LEDs, and having remote desktop to MPLAB on a local PC would definately help. Then feed the OrtonView video output direct into a PC, then stream it, or whatever.

Also, but this is beyond my field, I believe there are scopes which can be remotley driven.

Obviously there would need to be a local operator to move test leads etc, but thats just organising some cooperation.

Please give it some thought.

Buzby

[Timbucus]

Interesting idea - Funny enough I have a video capture card but, it cannot lock onto the SOC VDU or the PIC copy I have been trying for some projects... The remote desktop to MPLAB would need the in-circuit program option which we currently do not have to be really useful onto the PICKIT3 - the chip is hard programmed using my TL866 at the moment.

I have been trying to work with the scope by USB but, it seems it has a custom protocol that is not well supported on Linux.

[SiriusHardware]

Assuming a need for test code to be loaded into the MK14, there would also need to be some version of the uploader involved as well. Unfortunately I don't have a logic analyser and I don't think Tim does either. I bet Karen does. In a different time it would have been good for us all to be able to get physically together and bring all of our toys to the same table to try to sort things out that way.

I'm still hoping that between us we can pin down the 'if...then' case which leads to this problem. It is possible that it simply can not be done, there may not be enough time for the VDU to nip in and out so frequently without upsetting the operation of the MK14.

If so, Karen has already achieved what she set out to do by producing the protoype OrtonView hardware and the 'stable' firmware version in record time, so quickly in fact that she took both me and Tim by surprise and sent us scrambling for parts in an effort to keep up with her.

Although that version has quite an impact on the running speed of the host MK14, it works impeccably even with the 'A' suffix devices and can be considered to be finished in its own right. Karen has also kindly, as she does with all of her projects, given us the source so anyone with enough time, skill and interest can bear down on the problem with the 'fast' version until it finally cracks, if such a thing is possible.

[Mark1960]

Originally Posted by Timbucus

Indeed it is effectively A10 I have the pullup on. I had to up it to 10K as the Mk14 in SCIOS was doing weird things ending up jumping into very high memory addresses when stepping with MEM.

I also notice that on the new FW chip the LISTER program which runs in F00 memory and displays in B00 is crashing when you use Go to get to the next page once or twice - with the pullup it displays corrupt characters and always dies on the first Go. Either way it dies - I put the old chip back in and it works fine except with the pullup on A10/_CE1 where it does eventually die.

Tim had some success with a pull up on A10, but writing to the wrong RAM chip would require both chip enables to be low during NWDS. Maybe further improvement is possible by also adding pull up to the A11, A9 and A8.

SCMP output low drive current is limited at 2mA, and some of those address lines are loaded by three 74ls inputs, so 10k pull up is probably the lowest that should be used.

Was anyone able to capture NWDS truncated pulses on a scope together with RAM chip enables?

[SiriusHardware]

Originally Posted by Mark1960

Was anyone able to capture NWDS truncated pulses on a scope together with RAM chip enables?

Truncated in what way Mark, by being interrupted by NENIN?

You have to realise that the interval between these 'ghost writes' is anything between seconds and minutes, (at least when charset is running) so it's a tall order to capture one.

[Timbucus]

Originally Posted by Mark1960

Tim had some success with a pull up on A10, but writing to the wrong RAM chip would require both chip enables to be low during NWDS. Maybe further improvement is possible by also adding pull up to the A11, A9 and A8.

SCMP output low drive current is limited at 2mA, and some of those address lines are loaded by three 74ls inputs, so 10k pull up is probably the lowest that should be used.

Was anyone able to capture NWDS truncated pulses on a scope together with RAM chip enables?

I will try a 10K on every Address Line but, as you comment in the last line I did observe the below while running CHARSET which runs in 0880 and after the initial load only writes to a place in B00. With a 10K pullup on NWDS instead of 4.7K (which makes my CHARSET fail reliably) - this was CHARSET running at full pelt no DLY

I am just writing one that will check the corrupted Fxx/Bxx memory location for a change from 0x20 and if so stop in a tight loop which should allow me to capture this event reliably - I will report back - sorry been doing other things all day.

The top trace is _CE1 for F00 ram which should NEVER be written to and bottom is NWDS - that looks like a write while F00 is enabled to me. Second trace is zoomed in on the event that concerns me.

[SiriusHardware]

Nice catch, you should be playing cricket for England I reckon.

The VDU doesn't have an NWDS output to the system (it is read only) so any NWDS pulses you see can only be generated by the SC/MP and, extrapolating from that, the SC/MP can not assert NWDS when NENIN is asserted.

It is however possible for NWDS to be -already- asserted at the moment when NENIN is asserted by the VDU. I showed a captured example earlier in the thread.

[SiriusHardware]

Actually the last NWDS pulse in your image #1 in post #726 also looks like it falls within a low period of _CE. Sorry to have to ask, but you're sure that was NWDS and not NRDS you were monitoring? You would obviously expect NRDS pulses partly from the program itself running in 0880-, partly from the VDU reading 0Fxx and partly from the VDU reading 0Bxx... so I would expect to see NRDS pulses both when 0Fxx _CE is high and when it is low.

[SiriusHardware]

The high four address bits account for these bits in the address xxxx1111xxxxxxxx, or xFxx in hex, so by pulling them all high you actually bias them towards the very address which selects the 0Fxx bank of RAM.

You could try pulling them gently towards 0V instead, but this presents its own hazard since x0xx is the memory block occupied by the first half of the OS. I seem to remember Slothie pointing out a very long time ago that there is nothing, electronically speaking, to prevent an attempt to write to the PROMs but that is something which should obviously be avoided if possible.

[Mark1960]

Originally Posted by SiriusHardware

Truncated in what way Mark, by being interrupted by NENIN?
.

Yes I meant interrupted by NENIN.

Tim was looking at only one of the chip enables, so this might still not be a write to the ram.

It’s going to be really difficult to check the state of two chip enables and the NWDS on a dual trace scope. It might just be possible using an external trigger input to sample one of the three signals, possibly rising edge of NWDS on external trigger with the chip enables on the two channels of the scope.

Pull down resistors is not really possible with 74ls ttl. It would require 470 ohm pull downs and the SC/MP would never be able to drive to high level.

[SiriusHardware]

Unfortunately even Tim's considerably faster version of my scope does not have an EXT-Trigger input. (cross posted with Mark below)

Tim was looking at only one of the chip enables, so this might still not be a write to the ram

Yes, we really need to be able to see both _CEs for the 0Fxx RAM, and the NWDS signal and ideally NENIN as well as the best way to tell if a NWDS pulse is originating from the system or the VDU. I suppose the output of a 3-input OR gate with its inputs coming from 0Fxx RAM _CE1, _CE2 and _NWDS will go low when that RAM is really being written to, with the other trace triggered from NENIN perhaps.

[Mark1960]

Looks like Hanmatek scope doesn’t have a seperate external trigger so I guess it rules out that possibility.

[Mark1960]

What would be the minimum, least invasive mod to an mk14 to try and see this issue without an mk14 vdu?

I’m thinking lift the NENIN pin on a spare SC/MP, 10k pullups on NRDS and NWDS, and drive NENIN from a 555 timer.

I probably need to add the extra RAM, which I didn’t really want to do without matching sockets to the rest of the MK14. But maybe I could just scope the Chip enable without fitting the RAM.

[Timbucus]

Originally Posted by SiriusHardware

Actually the last NWDS pulse in your image #1 in post #726 also looks like it falls within a low period of _CE. Sorry to have to ask, but you're sure that was NWDS and not NRDS you were monitoring? You would obviously expect NRDS pulses partly from the program itself running in 0880-, partly from the VDU reading 0Fxx and partly from the VDU reading 0Bxx... so I would expect to see NRDS pulses both when 0Fxx _CE is high and when it is low.

It was def NWDS - my rewritten CHARSET does not seem to work to halt on the written character not being the same so from that I assume it must be an extra write, the only problem is when I change the code the place the corruption it is written changes.

I think you are correct events like that must be rare - i have not been able to capture another.

The pulse you are concerned seems to be during a low is not they are all just about pulled up - the first image is a more detailed look when I have a 10K pullup like on the above. Then with the 4.6K - the 4.6K eliminates the writing to both Banks but, I still get the odd character changing in F00 - the problem really is when I change the code the effect changes or stops totally. So I am not sure if with 10K it is still low enough that the effect happens that both banks get written to, it does not seem so from the trace.



I may need to build your OR gate comparitor or try and rig the HAMEG which does have an external trigger.

[Timbucus]

Originally Posted by Mark1960

What would be the minimum, least invasive mod to an mk14 to try and see this issue without an mk14 vdu?

I’m thinking lift the NENIN pin on a spare SC/MP, 10k pullups on NRDS and NWDS, and drive NENIN from a 555 timer.

I probably need to add the extra RAM, which I didn’t really want to do without matching sockets to the rest of the MK14. But maybe I could just scope the Chip enable without fitting the RAM.

Mark - I don't think it ever happens on a plain MK14 - it does not happen with my JMP one and indeed does not happen with my MKVI with the SOC VDU on or the working #352 FW - it is a unique situation with the optimized PIC VDU so must be related the the flapping NENIN that is used to create the optimization.

[SiriusHardware]

Tim, look again at your first image in #726 - pulses 1,2,3,5 occur within logic 1 periods of the _CE1 signal, the fourth one very obviously occurs within a wide band of logic 0 on _CE1 (so chip is possibly enabled, depending on the unknown state of _CE2).

If you look carefully the 6th pulse in that capture also falls within a logic 0 period on _CE1.

As Mark has pointed out, there is no point in worrying about this unless we also know the state of _CE2.

It turns out that 3-input OR gates are a kind of a TTL missing link, but you can use a 74x27 (3 input NOR) for the same purpose, you would just be looking for a high (rather than a low) on the output to tell you when _CE1, _CE2 and _NWDS are all low together.

[Slothie]

Originally Posted by SiriusHardware

It turns out that 3-input OR gates are a kind of a TTL missing link, but you can use a 74x27 (3 input NOR) for the same purpose, you would just be looking for a high (rather than a low) on the output to tell you when _CE1, _CE2 and _NWDS are all low together.

Or you could use 3 signal diodes and a resistor... the frequencies here are not that high.

[Timbucus]

Well I have been playing all afternoon and although the 74LS27 works as we expect - it is a struggle to get the MK14 to work reliably for long enough to do anything - I have jury rigged a socket on the top of the RAM to pull off the signals but, it seems to make it unstable and the pulse is very messy (even with all unused inputs to ground and a 100nF decoupler on the LS27) - however, I do seem to have achieved some stability now and have captured a couple of scenarios we have been discussing.

Here is a reminder of the effect you expect to see (This is with my 4.7K pullup on NWDS) when CHARSET is running and the LS27 is on top of the B00 RAM - the only corruption is in the F00 area you can see the bit below the M of TIMBUCUS.



So I switched the LS27 to the top of the F00 chip and set a wide view:



Setting the trigger a lot lower that runt write is always in that position in the frame (of the picture this is likely a line of data?)...
as far as I can see and must be what is causing it although it does not seem very high (but over 2V) I suggest the speed and the NOR gate in the way is reducing that a bit as well.



Finally I set my NWDS pullup to 10K and sure enough the corruption on both the B00 and F00 appears in the lower middle as usual. I left the capture on F00 and you can now see a clear regular pulse in the wrong place... and the runt still there (both corruptions are happening on screen as well)

[Timbucus]

Just to clarify the last statement here is the screen corruption with the 10K pullup you can see the data in both banks (they are changing quite frequently) and the one below the M (the runt I believe) is also changing but, at a sightly lower pace.



and here is how I was capturing it... I wish I could find an economic source of some chip test clips.

[Timbucus]

That runt also shows just sitting in a tight loop displaying the SC/MP inside message as well.