Mk14 vdu

[Karen O]

I think I've spotted it!

In order to get off the address bus, my code puts PortA0..3 and PortD0..7 in an input condition. This is okay normally because the output drive register for each port is preserved, and will re-assert on the port outputs, uncorrupted, as soon as the port is reconfigured as an output again.

The trouble is, I use the instruction:

BCF PORTA,NENIN

in order to flap NENIN, and I've configured portA0..3 as inputs to get them off the bus.

One has to carefully understand the precise meaning of the above instruction to see where things are going wrong. It means 'form a mask with all 1s except for the NENIN bit, which is 0. AND this with the SENSED STATE OF THE PORT A PINS, then write the result to the portA output drive register.

So the above instruction corrupts the output drive register for port A - the page part of the address.

A fix is already crystallizing in my head!

[SiriusHardware]

I should point out that it was actually Tim who won the race to test FW515 and seems to have given you a possible breakthough. Exciting stuff! I'll pause testing for now.

[Karen O]

Okay, let's try this one.

I've broken my own rule and did this fix rather quickly but fingers crossed!

[Timbucus]

That is much better on the stability front by the looks of it, the 7 segment is really stable, top and bottom pages are now selected, still some odd flickering effects here and there - I will capture and upload some video. I will need to do a bit more research but, it seems the horizontal data is not being fetched from the correct places with repeating patterns in both Text mode and Graphics - here is SC/MP and CHARSET. You seem to be on the right track though as my PI Uploader script now works to RESET and upload etc.

[Timbucus]

Maybe you have a similar error on the creation of the fetch address?

[SiriusHardware]

I hope this is not premature, but...

... this is a big step forward!

-MK14 display looks completely NORMAL now even with OrtonView Active

Initial test with meaningful data loaded into 0200-03FF, that area of RAM is rendered perfectly to the screen as characters, however the meaningful data happens to have the same letters all the way across one line so I'll have to check it with more complicated data.

If I switch to graphics mode the same data is now rendered to the screen as steady-state patterns, but I still have that one outstanding issue where every other graphics frame is offset to the right by one half of a graphics pixel, or one UART bit width. It is as though one extra white bit is transmitted at the very start of each line within the active area, but only on every alternate frame. I'll follow up with images to illustrate this.

That issue has been there since the first optimised version, but is not present in the original 'good but slow' firmware. In that version the graphics image is rock steady with no alternate-frame offset.

[Timbucus]

It is definitely repeating groups of four characters with some corruption happening. Sirius repeated characters would not show the effect.

Graphics mode seems to have a similar problem but, only getting data from the second half of the image.

Video to show the minor flickering on occasional characters and pixels.

https://youtu.be/JAh4NYKwkTg

[SiriusHardware]

Very quickly before Karen starts tearing the code apart again, I have 'inside' loaded at 0200-03FF and it is being rendered almost normally - ie, only one image, full width, but still with that one extra white UART bit offset on every alternate frame.

[Karen O]

Thanks for testing this last code for me.

I'm confident the problems you describe in graphics mode are down to some tiny timing error. A scan line is 256 processor cycles, but if I've not counted cycles correctly then there could be a 255 cycle line, which might not be too obvious but cause shifts on the picture detail.

I'm a little worried that it is a serial port baud rate issue. In graphics mode I use divide-by-2 baud rate. This leaves to question the phase at which the serial port starts.

There are tests I can do, but not on this laptop...

[Timbucus]

Originally Posted by SiriusHardware

Very quickly before Karen starts tearing the code apart again, I have 'inside' loaded at 0200-03FF and it is being rendered almost normally - ie, only one image, full width, but still with that one extra white UART bit offset on every alternate frame.

So a different effect to me - perhaps related to the high bit of the address being f00-bff for me or do we have another difference - Maybe I need to blow another PIC just in case.

[SiriusHardware]

Don't go too crazy Karen, this is what I get with 'inside' loaded at 0200-03FF - just the one image, not a double image like Tim has - but, as I said, with an extra white bit at the LHS every other frame so the graphics image is buzzing left-right-left-right by half a graphics pixel (one UART BIT duration) on each successive frame.

See the attached image - you can't see the horizontal shuddering in this image but note the thickening of the bright line at the left hand side, only in the vertical zone occupied by the active screen area.

[SiriusHardware]

Tim, try this (Hex file only) - maybe your code assembled differently to mine.

[SiriusHardware]

I must stress that the horizontal shifting issue in graphics mode was not present in your first two versions of firmware, graphics output was rock steady then.

Whatever causes this was introduced in the first optimised version and has been in every version since. I think this is a separate issue which was inadvertently introduced during the first attempt at optimisation.

[Timbucus]

Well looks like I can add another not fully working PIC to my pile. I took a chance and flashed the new FW over the working 352 one. Still testing I get an odd character appear on Charset that occasionally changes ? to / etc. The graphics renders looks perfect - no sign of the bit shift you mention.



I wonder if my issue is related to non A parts - I only have a few of those so may try one with this firmware.

[Timbucus]

Originally Posted by SiriusHardware

Tim, try this (Hex file only) - maybe your code assembled differently to mine.

Will give it a go - but, I think my problem was the PIC faulty or not being an A part maybe.

[Timbucus]

Originally Posted by Timbucus

Will give it a go - but, I think my problem was the PIC faulty or not being an A part maybe.

Hmm - your HEX in my other chip has worked perfectly other than the same Random character on CHARSET appearing in the same place as in the photo. Maybe the first Burn did not take properly - is that even possible? I have not posted any photos as they would be the same as I did above.

This is also a good test result as your code is the same as mine.

[Timbucus]

Originally Posted by SiriusHardware

Don't go too crazy Karen, this is what I get with 'inside' loaded at 0200-03FF - just the one image, not a double image like Tim has - but, as I said, with an extra white bit at the LHS every other frame so the graphics image is buzzing left-right-left-right by half a graphics pixel (one UART BIT duration) on each successive frame.

See the attached image - you can't see the horizontal shuddering in this image but note the thickening of the bright line at the left hand side, only in the vertical zone occupied by the active screen area.

I do not get this so I wonder if my TV is suppressing whatever is happening there in the signal. You used to have a solid white line before didn't you maybe this is missing on the interlace frames so is causing a sync error?

I will try an A part next to see if that may have an effect as well.

[SiriusHardware]

Your post regarding the dud chip was not yet up when I put the code up for you to try - obviously your chip was faulty. Edit: Oh, maybe it wasn't after all. Which programmer are you using Tim? We have to be careful, I think, that we don't send Karen off on wild goose chases.

Your apparent lack of any shifting problem with the graphics image is mystifying, it's all too clear on mine but then your display does not seem to show the bright line which is, as Karen explained, an unavoidable presence because the UART always generates one bit-time of white when it is enabled at the start of each line. So the white line IS there, but maybe shifted off screen to the left on your display. I do still have the white line, look again at image in #531.

As a matter of interest do you have another composite CRT display you can try yours with? SWMBO has one at her place that I could try mine with, but I can't currently go there.

This is where we need more beta testers so we can have a broader spectrum of feedback. Anyone else putting one of these together. I know Slothie would, if he could.

[Timbucus]

OK with an A part I get the shuddering you describe in Graphics ONLY (wow is that annoying) but, without the white line you seem to get at the left, text mode is still rock stable. I do however still get the random character although I seem to have to wait a lot longer for it to appear and it does not change as often - in fact it has been an underline since I started typing and has only just changed to a ?

[Timbucus]

Programmer wise I am using my TL866II+ but, I did use a clone PICKIT3 earlier today from the IDE directly - happy to try that as well.