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 22nd Oct 2020, 2:47 am   #481
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by Timbucus View Post
Indeed - it is an impressive achievement and is very usable and as can be seen runs everything we know to exist (other than the Pong game which I must nag for the source again).
Tim
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.
Mark1960 is offline  
Old 22nd Oct 2020, 7:04 am   #482
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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
Karen O is offline  
Old 22nd Oct 2020, 9:02 am   #483
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default 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.
SiriusHardware is online now  
Old 22nd Oct 2020, 10:39 am   #484
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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.
Karen O is offline  
Old 22nd Oct 2020, 10:55 am   #485
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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?
Karen O is offline  
Old 22nd Oct 2020, 11:01 am   #486
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
Source the VDU clock from an external 4MHz generator thus making it asynchronous to the Mk14.
Already in hand, see earlier posts.

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'.
SiriusHardware is online now  
Old 22nd Oct 2020, 11:11 am   #487
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
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
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!
Slothie is offline  
Old 22nd Oct 2020, 11:15 am   #488
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
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?
I think its highly likely that 6% is a "best case" figure for something with plenty of long delay loops... Like putting a car on a downhill slope and claiming fuel economy is "up to" 100mpg!
Slothie is offline  
Old 22nd Oct 2020, 11:35 am   #489
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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).
Karen O is offline  
Old 22nd Oct 2020, 11:50 am   #490
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
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).
Unless Sirius uncovers something with his test, I think its going to take connecting up a logic analyser and pouring over the waveforms. I'm sure its something simple, just a minor glitch in the timing somewhere. I have all the gear to do this, its just it 3 different places some of which I cant get to at the mo....
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......
Slothie is offline  
Old 22nd Oct 2020, 12:03 pm   #491
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
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.
If you remember a few pages back I tried a 'soft' frequency generation program with

- 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.
SiriusHardware is online now  
Old 22nd Oct 2020, 1:43 pm   #492
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default 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.
Attached Files
File Type: zip mk14vdu.zip (6.4 KB, 35 views)
Karen O is offline  
Old 22nd Oct 2020, 3:19 pm   #493
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default 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.
SiriusHardware is online now  
Old 22nd Oct 2020, 6:31 pm   #494
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default 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.
SiriusHardware is online now  
Old 22nd Oct 2020, 7:25 pm   #495
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default 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.
SiriusHardware is online now  
Old 22nd Oct 2020, 8:18 pm   #496
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
Quote:
Originally Posted by Karen O View Post
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
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!
I had a similar thought - I have actually learned more SC/MP code tricks from hand disassembly of HEX only programs in magazines than I have from listings.

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.
Timbucus is offline  
Old 22nd Oct 2020, 8:24 pm   #497
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Evening Tim - do you have the means of assembling Karen's latest code from #492?
SiriusHardware is online now  
Old 22nd Oct 2020, 8:25 pm   #498
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
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.
I have just uploaded a sequence I made for a longer video that shows the patterns I get when stepping through - do you get the same ones - as if so them we may have a deterministic pattern that we can use to try and work out what the effect is - it is obviously a beat between two things... the loops in the SCIOS and the Display generation.

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.
Timbucus is offline  
Old 22nd Oct 2020, 8:35 pm   #499
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default 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.
SiriusHardware is online now  
Old 22nd Oct 2020, 8:57 pm   #500
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Evening Tim - do you have the means of assembling Karen's latest code from #492?
Just done so and get the effect you indicate I think - the MK14 display is stable although the center of the zero bit seems to flicker at times...

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?

Click image for larger version

Name:	IMG_4127.jpg
Views:	49
Size:	34.7 KB
ID:	218641Click image for larger version

Name:	IMG_4123.jpg
Views:	45
Size:	43.4 KB
ID:	218638

The flickering on the graphics is hard to show with photos but as you say the first lines of sections seem stable.

Click image for larger version

Name:	IMG_4125.jpg
Views:	43
Size:	41.2 KB
ID:	218639Click image for larger version

Name:	IMG_4126.jpg
Views:	35
Size:	41.0 KB
ID:	218640

actually here is a video... easier

https://youtu.be/v3m1TOoGxzw

Last edited by Timbucus; 22nd Oct 2020 at 8:59 pm. Reason: Jumbled pictures
Timbucus is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 11:05 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.