Mk14 vdu

[Timbucus]

I ran both programs unchanged - they may have been slower but I was tired anyway not so much they were unusable. I note one or both were in inverse as I set up the 8154 which pulls the outputs low I think and do not explicitly then set the bit as on my replica that is connected to the bit 7 character invert circuit so I would not have noticed... I have a patched version of Image that does as you say with just the last two bytes at the moment. I obviously still have the uploader problem to fix though.

More tonight

[SiriusHardware]

I will get onto fixing the Pi version of send14 this evening. For the most part you might be able to get away with pasting the fixed version of the 'SendFileToMK14' function into your original script, plus a couple of minor edits elsewhere which I will mention then.

[Timbucus]

That would be great - at the moment I have a stripped back one that does not do the reset at the start or FFF to 02 as I found on the Ortonview it could not type in the disable - it is marginal on the replica only working 50% of the time - I needed to put some time in with a second custom slow key press routine to use at the start so it can go full speed after the VDU is off rather than my hack of doubling the Inter key delay - I think it is more about how long they are pressed - I will work back up from the fixed one then to that.

[Mark1960]

Originally Posted by SiriusHardware

Secondly, the image also captures the rarer case where NENIN was asserted when NADS already happened to be asserted. In this case something odd happens, NADS looks as though it goes tristate for the duration of the NENIN pulse.

That is very odd behavior on NADS but not sure it looks tristate, the transition at the start seems to be too sharp, more like two outputs fighting each other, but I’m guessing you don’t have anything else on NADS.

You may have found a hardware bug in the INS8060, not sure if it would be noticed in an application as it seems to stay above ttl high level.

Is it possibly due to timing between NENIN and clock?

[SiriusHardware]

No, there's nothing but the scope on NADS actually.

I didn't look to see what sort of output NADS is, maybe it would benefit from a pullup but it seems to get up and down without any external help for most of the time.

The SOC VDU does run from the host system clock so the two boards are synchronised in that sense, although the VDU pays no heed to anything happening on the host system when it decides to jump on the buses.

[Mark1960]

NADS is a standard output, not tristate.

I thought you were using the PIC for those measurements, so would be completely asynchronous, while the mk14 vdu derives NENIN from the clock, so would probably always assert NENIN high at the same relative time.

[SiriusHardware]

Even so, those occurrences of the rising edge of NENIN landing bang on an active NADS pulse are relatively infrequent - it took me quite a while to manage to capture one.

If you are ever in any doubt as to what source the capture was taken from, look at the filenames of the attached images - I usually include that info in the name of the image.

[Timbucus]

Finally got around to playing with the working PICVDU - I will do a proper video but, here is some raw footage of the system in action - I am still trying to get the updated send14 integrated with my setup as of course before I was relying on the accidental enable on execute so have to modify all my programs...

https://youtu.be/kcIyj-8Lh3c

[Slothie]

Well we all got a shoutout there!

[SiriusHardware]

Good show Tim, I LIKEd it. I hope Karen has a chance to see it, as I gather she had to go back to hospital again.

The inverse screen was a little bit hard to read because the screen was so bright relative to everything else in the image, but it obviously does work.

I'm slowly trawling through V1.02 (optimised version) of the Ortonview firmware, commenting every line as I go in an effort to try to understand it but it is very slow going for me. Incredible that Karen managed to write it all in what, a week or two.

[Slothie]

I'm inclined to beleive that Karen will at least have a phone with her.
The VDU code is an incredible work. I wonder if she slept at all over those 2 weeks!

[Timbucus]

Originally Posted by Slothie

I'm inclined to beleive that Karen will at least have a phone with her.
The VDU code is an incredible work. I wonder if she slept at all over those 2 weeks!

Indeed - it is an impressive achievement and is very usable and as can be seen runs everything we know to exist (other than the Pong game which I must nag for the source again).

I hope she did remember hers and a charger - my phone was what kept me sane on my sojourn last year!

Tim

[Karen O]

Hi All,

I can't say I'm at all well but I'm still here and in possession of my mental faculties.

Sadly, I think a return to my bed-top workbench is no longer possible but I can still edit PIC code on my XP laptop. I can even do some limited testing (I routinely check the video loop total execution time in simulation for example). But the problems we've seen with NENIN frankly baffle me.

Someone pointed out that the Mk14 and VDU run asynchronously. Maybe this is causing problems...? Maybe someone can lash in a divide-by-4 circuit (or a multiply-by-4 PLL) to eliminate any problems caused by asynchronicity (wasn't that a Police song?)

Anyway, nice to be back

[Timbucus]

Good to see you back and active - They have some pretty good IV only AB's available (as I found out luckily last year) so don't despair on that front yet...

Hopefully you can see from the video that the unit slowdown is less relevant IRL even with the animated software than might first appear and those were with the original slowdown loops

We also now have two working devices... I had wondered about how important the clock sync was and if a x4 PLL from the XOUT would be worth trying - we might need Slothie to advise on what would be needed to reverse the clock generation using a divider.

[SiriusHardware]

Nice to have you halfway back Karen, we knew from your other thread that you'd had a bit of a setback so we haven't been bombarding you with cries for (technical) help, nor should we, I think, at the moment. I hope you liked Tim's little show with OrtonView as the star.

If we divide the OrtonView clock by 4 to derive a synchronised clock for the SC/MP the problem I see there is that we we can't choose exactly which OrtonView clock pulse the divider will first start clocking on so although they will be synchronised in a sense, the output of the divider may toggle on the 1st, 4th, 8th, 12, 16th... Ortonview clock pulse or it may toggle on the 2nd, 5th, 9th, 13th OV clock pulse or on the 3rd, 6th, 10th, 14th OV clock pulse, if you see what I mean? We can't guarantee the relative phasing of the two (or can we?). Mind you, exactly the same can be said of the SOC VDU.

Maybe we need a common clock generator for both, with a 16MHz output and a 4MHz output both from the same divider chain so they are both always in lock-step.

Another thing that could be tried is to fit a 4.43MHz crystal in the MK14 and provide a 4.00MHz clock to the SOC VDU with a 4-pin oscillator module or a signal generator and see if that combination, which will obviously be completely asynchronous, works. If it does, it could be argued that OrtonView should be able to get away with being unsynchronised as well.

[Red to black]

Well done lady's and gents, I have nothing to contribute to this/these fascinating thread/s technically but long may it continue, I look in everyday to see how far each of you have got.
I hope you are ok too Karen wishing you the best after just having read about your latest set back.

[Slothie]

Originally Posted by Timbucus

We also now have two working devices... I had wondered about how important the clock sync was and if a x4 PLL from the XOUT would be worth trying - we might need Slothie to advise on what would be needed to reverse the clock generation using a divider.

Or you could use an ICS501 to multiply the XOUT clock to 16MHz and feed it to the PIC - you'd need to change the config bits in the PIC of course. And you'd need to have a 4MHz crystal in the MK14.

The only real snag is its a SOIC IC for vision-challenged persons like myself....

[SiriusHardware]

You still have the problem of not being able to control the relative phasing though...

Likely scenario:

-MK14 clock starts up when power is applied, the multiplier starts multiplying on the first MK14 clock pulse it sees and starts generating 16MHz but the SC/MP takes a while to come up out of reset before finally starting off on cycle zero and continuing from there.

-Assuming a common power supply, the PIC also takes time to come up out of power-on reset and only starts running from its cycle zero once it comes out of its own reset phase.

Result, we have no way to make the two units run in truly lock-step fashion. They'll be running at a synchronised speed, yes, but not necessarily in-phase.

Thinking about it, it could be sufficient just to break into the CLK_OUT signal as it goes across the bridge board and inject a not-quite 4.00MHz signal (a little bit plus or a little bit minus from 4.00MHz) to the SOC VDU to see if it still works when not synchronised. If it does, we should be able to get the OrtonView to work on the same unsynchronised basis.

[Slothie]

Originally Posted by SiriusHardware

Thinking about it, it could be sufficient just to break into the CLK_OUT signal as it goes across the bridge board and inject a not-quite 4.00MHz signal (a little bit plus or a little bit minus from 4.00MHz) to the SOC VDU to see if it still works when not synchronised. If it does, we should be able to get the OrtonView to work on the same unsynchronised basis.

That sounds like a good idea. I think (hope?) that looking at the data sheets this should work without being synchronous. I cant recall any mention on the sections about multiprocessor configurations that they should have synchronised clocks or even the same frequency.

[SiriusHardware]

I'll see if I can set that up tomorrow night, I have a synthesised RF signal generator to use as an alternative 'variable' clock for the SOC VDU. With regard to whether phasing is / is not important, I have already pointed out to myself that there is no fixed phase-relationship between the MK14's SC/MP and the SOC VDU - the VDU, which is essentially just a big multi-path divider chain, starts running as soon as it sees the first clock pulse from the MK14's clock but the SC/MP doesn't do anything until quite a while later until it comes up out of reset, that delay largely determined by the value of the reset capacitor, plus the ambient temperature and possibly the wind direction.

So phasing I don't think we need to worry about, but I will see how the MK14 / SOC VDU combination behaves when each unit is run from independent clocks with slightly different frequencies.