UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 15th Oct 2020, 11:12 am   #401
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
Why do I feel like I'm talking about a long dead Russian dictator?
In Soviet Russia, bus drives you!
Slothie is offline  
Old 15th Oct 2020, 11:38 am   #402
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
In Soviet Russia, bus drives you!


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?
Karen O is offline  
Old 15th Oct 2020, 11:57 am   #403
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default 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.
Slothie is offline  
Old 15th Oct 2020, 12:01 pm   #404
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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.
SiriusHardware is offline  
Old 15th Oct 2020, 12:02 pm   #405
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
Quote:
In Soviet Russia, bus drives you!


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?
Since the MK14 isnt crashing, that sounds entirely reasonable. I've tried to read the code to estimate timings but... well, my PIC skills are rusty so I need to go over it and annotate the code - you put in fewer comments than I like but admittedly that isn't your priority

I presume "when I assert NENIN low" is a typo and you mean "NENIN high"?
Slothie is offline  
Old 15th Oct 2020, 1:21 pm   #406
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
I presume "when I assert NENIN low" is a typo and you mean "NENIN high"?
You are correct, you assert NENIN high to boot the SC/MP off the bus.

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
Karen O is offline  
Old 15th Oct 2020, 1:26 pm   #407
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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.
SiriusHardware is offline  
Old 15th Oct 2020, 4:00 pm   #408
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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.
Karen O is offline  
Old 15th Oct 2020, 4:04 pm   #409
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

OK!
SiriusHardware is offline  
Old 15th Oct 2020, 7:30 pm   #410
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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:
Originally Posted by Karen O View Post
SH, did you notice any pattern to the display corruption? The first line of text in each half, i.e. lines 1 and 16, are fetched separately from the rest. Are they stable or addled?
....unsurprisingly, proved quite astute. I didn't notice it before but yes, those two lines are stable and furthermore I can edit the contents using the MK14 monitor and they display as edited. The same applies to the first TWO characters on lines 2 and 17, but not the rest of the characters on those lines or the remaining 14 lines per half screen.

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.
Attached Thumbnails
Click image for larger version

Name:	PICVDU_Graphics_V1.02fw.jpg
Views:	71
Size:	106.8 KB
ID:	217993  
SiriusHardware is offline  
Old 15th Oct 2020, 7:39 pm   #411
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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.
SiriusHardware is offline  
Old 15th Oct 2020, 8:45 pm   #412
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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.
Attached Files
File Type: zip mk14vdu.asm.zip (6.5 KB, 41 views)
Karen O is offline  
Old 15th Oct 2020, 8:48 pm   #413
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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.
SiriusHardware is offline  
Old 15th Oct 2020, 8:57 pm   #414
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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
Karen O is offline  
Old 15th Oct 2020, 9:15 pm   #415
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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.
SiriusHardware is offline  
Old 15th Oct 2020, 9:26 pm   #416
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default 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.
SiriusHardware is offline  
Old 15th Oct 2020, 10:49 pm   #417
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Its so frustrating having all my stuff in storage - I'd love to weigh in on this...
Slothie is offline  
Old 15th Oct 2020, 11:24 pm   #418
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

If they don't arrive tomorrow I will build it on my Breadboard in place of my Memory Expansion!
Timbucus is offline  
Old 16th Oct 2020, 6:23 am   #419
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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.
Karen O is offline  
Old 16th Oct 2020, 6:31 am   #420
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

I confess I'm baffled.

I recommend that we revert to the version of firmware released in post #352.
Karen O is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 7:02 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.