15th Oct 2020, 11:12 am | #401 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
|
15th Oct 2020, 11:38 am | #402 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
It is interesting that the latest VDU code doesn't crash the Mk14 (as it could so easily do). But it does seem that the Mk14 is crashing the VDU! This suggests that I'm not giving the SC/MP long enough to get off the bus when I assert NENIN low. As a consequence, VDU read cycles are corrupted. Does this sound plausible? |
|
15th Oct 2020, 11:57 am | #403 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
I've been looking at the data sheet and as you say it is vague, to say the least.
About the best clue I can see for the bus access timing is TD(NENOUT) = 150nS which the time between NENIN going high and the SC/MP Indicating its not enabled on NENOUT. This does not seem to be clock frequency related. |
15th Oct 2020, 12:01 pm | #404 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Whatever else fails, I am glad to see that Karen's sense of humour never does.
The plan is to -Load meaningful / recognisable data into the screen ram with the VDU disabled. -Enable the VDU and see if the loaded content survives and is displayed in some form or is erased / scrambled. -Take a bit of off-screen video of what's happening -View it in VLC and run it in 'slow motion' to see if that makes anything more obvious. |
15th Oct 2020, 12:02 pm | #405 | ||
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
I presume "when I assert NENIN low" is a typo and you mean "NENIN high"? |
||
15th Oct 2020, 1:21 pm | #406 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
Before we go any further: can we try slugging NRDS and NENIN using small capacitors e.g. 470pF just to be certain that fast edges on the PIC outputs is not causing all the trouble we're seeing? It is shocking how much trouble fast edges can cause. I've done a careful study of the timings of my code relating to NENIN transitions. They look okay to me in terms of giving the SC/MP adequate time to get off the bus. There is opportunity to increase this margin a little, but that will lead to a slowing of the Mk14. ANALYSIS ====== t1 = NENIN high to address bus drivers low impedance t2 = NENIN high to first read cycle NRDS low t3 = Address bus high impedance to NENIN low Note: 1~ = 250nsec = 0.25usec 1 (Bus acquisition in preparation for buffer pre-charge) t1 = 15~ = 3.75usec t2 = 25~ = 6.25usec 2 (Bus release after buffer pre-charge) t3 = 21~ = 5.25usec 3 (Bus acquisition in prep. for main display region) t1 = 21~ =5.25usec t2 = 100+~ 4 (Bus release after main display region) t3 = 13~ = 3.25usec The following occur during text generation 5 (Bus release prior to text rendering) t3 = 9~ = 2.25usec 6 (Bus re-acquisition following text rendering) t1 = 14~ = 3.5usec t2 = 34~ = 8.5usec The following occur during graphics generation 7 (Bus release prior to graphics rendering) t3 = 13~ = 3.25usec 8 (Bus re-acquisition following graphics rendering) t1 = 18~ = 4.5usec t2 = 38~ = 9.5usec Last edited by Karen O; 15th Oct 2020 at 1:27 pm. Reason: Factual error and typo |
|
15th Oct 2020, 1:26 pm | #407 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Suggestion re: Capacitors duly noted. I will try that and see if it 'just works' before I try any of the other stuff.
|
15th Oct 2020, 4:00 pm | #408 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Attach the capacitors as close to the PIC pins (one being GND) as possible, otherwise a radiating loop will be created, which can be just as bad as a wire antenna.
|
15th Oct 2020, 4:04 pm | #409 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
OK!
|
15th Oct 2020, 7:30 pm | #410 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Just started the latest round of testing with V1.02 firmware (with the NENIN mods) back in. First the bad news, no combination of 470pF capacitors from NRDS to GND, NENIN to GND or both has any affect on the symptoms. It was worth a try though.
Now then, this question... Quote:
I've also noticed that all of the other characters are not completely chaotic, each character is in fact alternating between just two characters although they are doing it in a kind of 'Mexican wave' ripple pattern sweeping continually down across the screen. Changing to graphics mode, it looks as though I can edit the very first part of each half of the screen which is static, with the rest of the pixels constantly flipping states just as in character mode, but there is one extra anomaly in graphics mode - every other screen seems to be getting rendered half a graphics pixel width offset to the right so the overall image is constantly jumping slightly left/right by half a graphics pixel width. Still in graphics mode, Looking at the bright vertical line over on the left hand side that too seems to have a transparent extra half pixel width being added onto the right hand side of it, but only in the vertical interval occupied by the 'active portion' of the screen. The attached photo will hopefully illustrate it better, look carefully at the bright line on the left hand side and you can see it looks thicker inside the vertical range occupied by the 'active' area of the screen, although the extra bit on the right hand edge is transparent as though it is only there every other frame. You probably won't be able to see that the left and right edges of the main graphics block are also transparent to a depth of half a graphics pixel width because the whole screen is zipping back and forth half a graphics pixel width. If you can work out what is causing this half pixel offset on every other graphics frame, fixing that might well fix the problem in character mode as well. In character mode, the LHS bright line is 'normal' thickness all the way down, that is, about one graphics pixel width wide. Hope this gives you some ideas. You will have noticed from all of the foregoing that the MK14 itself is working virtually normally, except that the two normally empty characters between the address and data fields on the display have a significant about of 'noise' on them so the VDU is upsetting / clashing with the MK14 a little bit, but not enough to make the MK14 fall over. |
|
15th Oct 2020, 7:39 pm | #411 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
One other thing I forgot to mention, I can also edit those areas of the screen memory which appear to be constantly changing, using the monitor. The edited values 'stick' and I can revisit the edited memory locations and the values remain as they were edited, but the VDU only correctly renders the first 18 characters in each screen memory half onto the screen.
|
15th Oct 2020, 8:45 pm | #412 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
The attached file has the scavenging code ripped out and will (hopefully) run with much less flak. Sorry, no hex - don't have access to my main laptop.
|
15th Oct 2020, 8:48 pm | #413 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
One further, potentially significant bit of info:
As stated, characters 1-16 on each screen half are always steady state and accurately rendered from the values in the first 16 bytes of each 256-byte block of screen memory When the system is first powered up, characters 17 and 18 of each 256-byte block are not steady, they alternate continually between two different characters just like the remainder of the 256 characters in the block do. However when they are written to, they BECOME steady-state and they display as the characters corresponding to the values written to those locations. Edit: Crossed with your latest post Karen, will try it now. |
15th Oct 2020, 8:57 pm | #414 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Hi SH,
The first 16 characters of each half-screen are read from memory separately, actually, during the blank lines above the display area. I would expect them to be good because the margins there are quite wide. Characters 17 and 18 are unique insofar as they are read from memory before the very first attempt to claw back time for the processor, i.e. NENIN is asserted 0 just after these bytes are read. I'm rapidly coming to the conclusion that these issues won't be fixed without a logic analyser |
15th Oct 2020, 9:15 pm | #415 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Righto, chip programmed with V1.03 (scavenging bits removed).
- MK14 display is being noticeably impacted again (slow scanning with some bright cells, some dim cells, suggesting quite a bit of slowdown, but maybe not as much as with V1.00/V1.01). - PIC_VDU Character mode is back to normal, constant steady display with all 512 characters correctly rendered from screen RAM. - PIC_VDU Graphics mode still has that odd half-a-pixel-offset on every alternate frame as described in #410, first introduced in V1.02. Last edited by SiriusHardware; 15th Oct 2020 at 9:29 pm. |
15th Oct 2020, 9:26 pm | #416 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
I've just been told my presence is required elsewhere for a while so I probably won't be able to do any more test driving tonight, unfortunately. Hopefully Tim's parts aren't too far down the road now and we will be able to combine / compare testing efforts once he gets his PIC-VDU together.
|
15th Oct 2020, 10:49 pm | #417 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Its so frustrating having all my stuff in storage - I'd love to weigh in on this...
|
15th Oct 2020, 11:24 pm | #418 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
If they don't arrive tomorrow I will build it on my Breadboard in place of my Memory Expansion!
|
16th Oct 2020, 6:23 am | #419 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I think it's about time someone lashed a signal generator to NENIN and measured how quickly the SC/MP got onto and got off the bus in response to NENIN edges. I don't think this would be a difficult undertaking.
|
16th Oct 2020, 6:31 am | #420 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I confess I'm baffled.
I recommend that we revert to the version of firmware released in post #352. |