23rd Oct 2020, 9:57 pm | #541 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Just in case there is a difference in memory use as well here are my test programs - obviously set for use at F00 on top and B00 on bottom.
|
23rd Oct 2020, 10:11 pm | #542 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
I think the shuddering may be a tiny error in the sync timing. The 877 and 877A do have differences in their internal circuitry (for instance, the data sheet says they are slightly faster to program) so its entirely possible there are tiny differences in propagation delays between instruction execution and when the port actually changes, or something like that. This may be subtly exascerbating a small timing error? Pure conjecture I know but I do think there is a small snafu in the timing of the video given the original software is rock solid, as is the character mode.
Tim, not seeing the white line may just mean your TV has more "oveerscan" than Sirius's. You're right Sirius, its really annoying not being able to help out!!! |
23rd Oct 2020, 10:21 pm | #543 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I've a feeling that the PIC baud rate generator (which has settings like divide-by-1, divide-by-2 etc.) does not have its phase automatically reset when the serial port is enabled.
This is not a problem - it might mean some ambiguity about exactly when a line of graphics pixels will begin, but at least it will be consistent and won't shudder... IF the total frame duration is an even number of processor cycles. If my frame duration is out by just one processor cycle, then we'll get the effects people have witnessed. So don't despair! I have an awful lot of counting to do! I'm encouraged to see, in the image of #531 that the left edge of the bright line is continuous. |
23rd Oct 2020, 10:25 pm | #544 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
I bet it is annoying but, also helpful to have a dispassionate third eye... I will certainly try double programming and two PICS for all future tests before reporting. |
|
23rd Oct 2020, 10:34 pm | #545 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
I also think the Random character in character mode may have a wider impact and be worth looking into as after some time playing, MINEFIELD started doing funny things, which it did not on FW352 nor on the Replica SOC VDU so in this instance (unlike HORSERACE) I do not suspect a bug in my code. This game uses the screen memory for sensing what is happening by looking at the characters as it goes along which may explain why it suffers. Sirius if you can confirm with my CHARSET running that you see the same character appear then that will help a lot I assume. So all in all this is almost a perfect build especially on a non A part from my perspective as the graphics can be looked at and admired. As I said the Random character appears and then changes slightly slower on the A version. Again this may or may not help. |
|
23rd Oct 2020, 10:41 pm | #546 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
I only asked about programmers (Tim) because it seemed possible that your preferred programmer does not always work perfectly which is a bit dangerous - we could end up making Karen waste time looking for a non-existent problem (which is why it's great that there are two of us independently testing, otherwise we might be none the wiser).
On the matter of the horizontal shifting in graphics mode only, brilliant observation thanks Tim - so ultimately if I want to fix that the workaround is just to use a non-A part, but then that offers another mystery - why does the 'A' part not do this when programmed with the original code? Why only in more recent versions? I went looking for empirical proof of the graphics shifting problem, and here it is: Image #1 a capture of a single line of the 'inside' image video. The first bright spike after the sync pulse and a bit of black-level is the unavoidable 'white bit' generated when the UART switches on. As this is a frozen image it only shows the line at one of two possible degrees of shift. Image #2: This is is a close up on the sync pulse and the 'bright line' only, but this time I left the scope running 'live' while I took the shot, and you can now see that the 'bright line' is alternating between two different durations, so we can say for sure that this is the point at which the timing of unshifted graphics frames and shifted graphics diverges, the timing on all frames is identical up to the rising edge of the 'bright line' but on every other frame, for some reason, there is an extra white bit being added on to the right hand side of the bright line. When this happens, the whole line following is shifted to the right by one UART bit duration / half a graphics pixel width. |
23rd Oct 2020, 10:45 pm | #547 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
We are doing a lot of crossposting at the moment - aren't we all excited? This has been a major breakthrough by Karen today.
I'll dig up a copy of CHARSET and see if I have similar problems. |
23rd Oct 2020, 10:54 pm | #548 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
Going to have to call it a night as have an appointment for my Flu Jab first thing in the morning! |
|
23rd Oct 2020, 11:34 pm | #549 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
and with an A part it is noisy and the timing of its pulse is variable whereas on the NON A it was a nice steady signal lock. This is zoomed in like you on the pulse which is flickering in duration on the A part. OK I really am going now curiosity satisfied. |
|
23rd Oct 2020, 11:45 pm | #550 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
If the shift is half a graphics pixel width, then this is actually a shift of a single processor cycle. This is what lead me to consider that it might be a baud rate generator phasing issue. |
|
23rd Oct 2020, 11:59 pm | #551 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
OK Karen, I wasn't sure, at one point you were trying to decide whether to stay at the same baud rate and double up all the transmitted pixels, or drop the baud rate in graphics mode and transmit one bit per pixel. I didn't know which way you went in the end. You should be able to get an idea of the actual difference in duration / width of the bright line from image #2 of #546.
To Tim: I actually much prefer analogue scopes, ideally ones which have a digital frame store built in as an afterthought so my weapon of choice at work is still a Hameg hybrid (analogue-with a digital- bit clagged on) CRT scope. Also has that very handy V/I component analyser built in, very much a Hameg feature. The one I've been using here at home for the off-system grabs is a modern but basic 'Multicomp' model identical to some we have at work - I test drove those for a while and decided to get one myself. I could wish that the pixel resolution of its screen was at least twice as high but it is not bad for what I have been using it for here. Last edited by SiriusHardware; 24th Oct 2020 at 12:15 am. |
24th Oct 2020, 12:04 am | #552 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
SH, you're illustrations in #546 really reveal the problem.
I found it difficult to read off the exact duration of the shudder shift. What was the actual shift duration in microseconds? |
24th Oct 2020, 12:20 am | #553 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
The horizontal scale in the second shot is 1.0uS per division, so the difference between the two possible widths of the bright line is roughly 1/5th to 1/4 of a microsecond / 200-250ns. As you say hard to read. Hope this helps.
I can try to get a better measurement of the time difference if you need it but it will have to be tomorrow evening now, sorry. Last edited by SiriusHardware; 24th Oct 2020 at 12:30 am. |
24th Oct 2020, 12:43 am | #554 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Here's the 'bright line' detail from that shot magnified up: 1.0uS per blue square.
|
24th Oct 2020, 8:40 am | #555 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
By the way Karen, I hope you don't mind that we keep coming up with little (and sometimes big) issues which need tweaking, but you seem to be most in your element when:-
- There is a problem to solve. - You are the only person who can realistically solve it. This has been an unusual project for you for various reasons but especially given the 'real time' and 'remote' nature of it. Normally you would have the target hardware in front of you and would quietly labour away in the lab until you had the chrome-plated final product ready to be unleashed upon the world, whereas in this case it's a work in progress and you don't even have the target hardware in front of you, and you have done a lot of your thinking on this 'out loud'. It has been a real pleasure to be involved with this project (if only as a passive spectator) and to watch that formidable mind of yours working. |
24th Oct 2020, 11:06 am | #556 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
The ability to follow the development rather than a fait-accompli has been a great learning experience for me, your BCF instruction explanation was really helpful and understanding what you meant about the clever dual use of RC6 for PS4 in, and TX out, when I saw the bits on the scope while looking for my oscillator track errors. Going to tackle trying to understand the ASM next so thanks for sharing the journey with us this time.
Working remotely has become the norm for so many at the moment it is nice to do so in a creative way where (hopefully) the problems are like enjoyable puzzle book problems rather than drudge work. |
24th Oct 2020, 11:19 am | #557 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
This VDU project has been one of the most difficult but simultaneously one of the most pleasurable that I have ever taken on. Normally, I set the spec.s of the things I build, but in this case the spec. is already defined and that makes for a much more difficult task. I couldn't do this without the help and feedback of my friends on this forum.
I lay awake last night, and I think I've found a way to implement graphics without changing baud rates. I'm finally embracing something that was hinted at earlier (probably by someone else): implement graphics as a special kind of character font. When I did finally fall asleep, the project acquired a bank of 8 cathode followers. Don't ask me what that's all about... |
24th Oct 2020, 5:26 pm | #558 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Hmm, and we imposed at least one major spec change pretty late on, namely the ability for any control input to respond to a change in state of TOP PAGE half way down the screen.
The changes you are considering making to de-shudder the graphics mode I think I understand in principle - leave it at the higher baud rate and use two serial bits to represent each pixel although presumably that means you would have to pre-store a further 256 +256 'characters' (the high and low nibbles of each possible bit pattern, with each pixel represented by 2 bits?). If you wanted to say 'Look, just use the 877 and forget about the 877A' I don't think we would quibble too much about that as long as that requirement, and the unsuitability of the 877A, was made clear in the project documentation. Can I ask, though, if you have a theory as to why this was not a problem even on the 877A in your first two released firmware versions? No shudder in those versions, and I have only used the 877A throughout. Last edited by SiriusHardware; 24th Oct 2020 at 5:37 pm. |
24th Oct 2020, 6:15 pm | #559 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Tim, as a matter of interest what is the EXACT numbering on your non-A 877s?
Just been looking around with a view to ordering a couple of non-A variants through work and I'm surprised to see the non-A version seems to be available in 4MHz DIP (PIC16F877-04/P) and 20MHz DIP (PIC16F877-20/P). I was never aware before that they were available in 'two speeds'. This one instance that you have found where the project code works OK in non-A but not quite OK in 'A' variants probably means that we have to test any future code revisions in both types from now on, unless Karen decides that the project has to use a non-A variant. |
24th Oct 2020, 6:39 pm | #560 | |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,087
|
Re: Mk14 vdu
When I bought my 877s for the PIC14 & PICL from RS, I noticed they list 04's and 20's
04 = 379-3143 20 = 467-1640 Heres something: Quote:
Last edited by Phil__G; 24th Oct 2020 at 6:53 pm. |
|