22nd Oct 2020, 2:47 am | #481 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
|
Re: Mk14 vdu
Just a thought, but if those programs are using the delay instruction for timing, I think during a delay instruction there is no bus access, so the timing would not be changed so much by driving NENIN high for longer periods.
|
22nd Oct 2020, 7:04 am | #482 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
That's a good point, Mark1960.
People are right to criticise my lack of comments but there is a reason for this. I generally only understand my realtime PIC creations for about two weeks. After that, no amount of comments can bring back that understanding |
22nd Oct 2020, 9:02 am | #483 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
There was the matter of the frequency generation code - normally 888Hz out, being slowed to just 75Hz when being interrupted by OrtonView. That uses two DLY instructions to time the high and low periods of the cycle.
I now have a BNC socket connected to my Bridge board (for injection of any old frequency into the SOC VDU). Obviously I can't vary it too much because the display frequencies are all derived from that clock but +/- 0.1 MHz should be enough to show whether the clocks need to be synchronous or not. Will try it out this evening. |
22nd Oct 2020, 10:39 am | #484 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
One interesting experiment that could be tried with an original SOC VDU and Mk14:
Source the VDU clock from an external 4MHz generator thus making it asynchronous to the Mk14. In all probability the VDU will run normally but if it shows similar behaviour to the PIC version then we have a very strong clue. I'm loathed to suggest experiments on vintage hardware, but in this case we only need to intercept one signal and little to no damage can result. |
22nd Oct 2020, 10:55 am | #485 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I struggle to work out where the 6% speed penalty figure comes from. I'm certain the SOC VDU must incur a much higher penalty. It's a figure quoted in the SOC VDU manual. My guess is, the write-up was produced before the hardware prototype was finished. Then, when they realised that, actually, the speed penalty is much higher, they decided it was too late to change the text and hoped that no one would notice the discrepancy.
Or am I reading too much into this? |
22nd Oct 2020, 11:01 am | #486 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Quote:
I plan to use a signal generator to vary the VDU clock up and down a little from 4.00MHz. Not too much, as all of the display frequencies are derived from that clock frequency, but enough to show for sure whether it does / does not matter whether the clocks are 'connected'. |
|
22nd Oct 2020, 11:11 am | #487 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
It wasn't a criticism, just a very picky observation I have been learning a lot from looking through the PIC14 code so maybe not making it too easy is an asset! I know what you mean, sometimes keeping the design in your head for something complex is like spinning plates on poles, you can keep them spinning in your head for a while but once you stop they all come crashing down and its a major job to get them back into place!
|
22nd Oct 2020, 11:15 am | #488 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
|
|
22nd Oct 2020, 11:35 am | #489 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Roughly speaking, how far short is the PIC VDU in terms of SC/MP speed penalty?
Not that I can do anything about the situation - attempts to claw back time for the SC/MP during the active display period were an abject failure (for reasons I still don't understand). |
22nd Oct 2020, 11:50 am | #490 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
Anyhoo the original software works well enough it seems for many applications, which gives many more opportunities for doing vdu stuff that were originally available - the total parts cost must be £5 or less, a considerable improvement on any existing clone! On a slightly cheeky note it also works better than the ZX80, which couldn't display any image while a program was running...... |
|
22nd Oct 2020, 12:03 pm | #491 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Quote:
- No VDU - SOC VDU - OrtonView The output frequency with the SOC VDU enabled was about 8% lower, so not very far off the fabled 6% at all. Unfortunately OrtonView with the most functional version of the firmware has a lot more impact on running speed, but as Tim has demonstrated it is still quite usable. |
|
22nd Oct 2020, 1:43 pm | #492 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
One last try at scavenging cycles for the SC/MP.
I've maximised the delay between NENIN assert high and bus acquisition (i.e. turning PortA0..4 and PortD into outputs). It means less time available to the SC/MP but I won't worry about that if it works. I must confess, I'm not at all optimistic about this but it's worth a try. |
22nd Oct 2020, 3:19 pm | #493 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Thank for taking the time to do that, Karen, I'll try that first, if it works then there will really be no need to do any of the other testing. Will report back this evening, or Tim may very well beat me to it.
|
22nd Oct 2020, 6:31 pm | #494 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Sorry to be the bearer of bad tidings but the result from the code posted in #492 is the same as with the first attempt at optimised code way back in #392
- MK14 display looks almost normal so the MK14 is clearly running faster. There are flickers and flashes in the two normally 'dark' display cells so there is obviously an ongoing clash between the MK14 and the OrtonView, but not enough to make the MK14 fall over. - First character line in each half of the screen is stable, lines 2-16 and 17-32, all characters are flickering between two different characters. If the first two characters of line 2 or line 18 are written to they become stable and show the correct character for the code written. -In graphics mode each group of 8 pixels is flickering except for the very top part of each half of the screen. Every alternate frame (graphics mode only) is rendered half a graphics pixel width to the right with the bright line at the left hand side having a half-pixel wide transparent section attached to its right hand side. Hopefully Tim will be able to confirm this as well. |
22nd Oct 2020, 7:25 pm | #495 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Onwards to the oscillator tests.
In the first instance I found a little rectangle of veroboard with a 4MHz crystal and a hex inverter and a trimmer capacitor on it - a buffered, slightly tuneable 4MHz oscillator. No idea why I made it or when, but just the thing to get me started. I broke into the CLK-OUT path between the MK14 and the SOC VDU and inserted the output from this oscillator so that it would supply an independent 4MHz clock to the VDU. Quite an interesting result, the display on the VDU output was rock steady and normal, but on the MK14 display which started off normal, after about 10 seconds one of the two normally dark display cells would light up '0', same brightness as the other 6. Sometimes the one next to the address field, sometimes the one next to the data field. Situation abnormal. I then tried using the output from a synthesised RF signal generator to generate first 4.00MHz and then 4.00 +/- a bit, but here I was thwarted because the output from the generator (which is meant for aligning receivers) does not go high enough to drive the transistor clock-input stage on the SOC VDU. I'll have to come up with some other way of generating near-4MHz signals at higher level. |
22nd Oct 2020, 8:18 pm | #496 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
Just to be clear for students of programming reading this; if it is for a living, your employer or a safety critical system then comments, re-usuble clear code, segmented into easily unit tested parts is a necessary evil that has sucked the joy out of hacking which is what most of us used to do before programming. |
|
22nd Oct 2020, 8:24 pm | #497 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Evening Tim - do you have the means of assembling Karen's latest code from #492?
|
22nd Oct 2020, 8:25 pm | #498 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
https://youtu.be/QBQY1RpBQfU I will burn a PIC to the same version and see if I get a similar effect to you as well. |
|
22nd Oct 2020, 8:35 pm | #499 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
I'll have a look but I think the effect we see on the MK14 display when V1.01 (the stable / working version) is running is:
- Overall scan rate is slower so the segments look dimmer on average - The VDU sometimes stops the scanning on the same one or two segments per scan and those segments look correspondingly brighter. At other times the 'stop rate' is not exactly in sync with the scan rate and at those times we see the 'bright' segments sweeping across the MK14 display. I am more keen to know what the problem is on the optimised (extra NENINs) versions of the code. I think the possible key would be understanding why, in graphics mode, every other frame is displayed half a graphics pixel width to the right. If the reason for that could be understood and fixed, the problem in character mode might very well be fixed as well. |
22nd Oct 2020, 8:57 pm | #500 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
This is the charset program as it should be on FW352 and then how it is with FW492 it seems the B00 memory is not displayed but, a copy of F00 offset there is an occasional flash of a character that would be where the rotating single letter is after CHAR = so it seems to only occasionally be showing a glimpse of B00 maybe? The flickering on the graphics is hard to show with photos but as you say the first lines of sections seem stable. actually here is a video... easier https://youtu.be/v3m1TOoGxzw Last edited by Timbucus; 22nd Oct 2020 at 8:59 pm. Reason: Jumbled pictures |
|