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 13th Oct 2020, 8:11 pm   #381
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Oh - I like a mystery I need to build mine ASAP now... ordered the parts last night but, no sign of the ones I already had - maybe they were out of stock at the supplier . I had better order another one just in case from someone else...
Timbucus is offline  
Old 13th Oct 2020, 8:46 pm   #382
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

I am very aware that my design falls a long way short on the 6% processor slowing specification. Ideally, every bus read would have its own NENIN assert/ drive buses/ read data/ release buses/ de-assert NENIN. There just aren't the PIC cycles to do this.

But there is an opportunity I can explore and I'll give some time to this when I feel up to it. I can't promise 6% slowing but I think I can do better than the current processor loading.

I don't know if any interactive games were written for Mk14/VDU combination, but it would be a shame if these couldn't be adapted for my VDU due to the snails pace SC/MP.
Karen O is offline  
Old 13th Oct 2020, 8:49 pm   #383
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Hi Karen,

A little bit more info:-

Image 1 - one frame of NENIN activity (PIC VDU)
Image 2 - one frame of NENIN activity (SOC VDU)
Image 3 - zoomed detail of SOC VDU NENIN activity

The second image looked horrible at first sight but then I realised that if it looked like that it must be low (inactive) for at least as long as it is high, and so it proved when I zoomed in (image 3).

Given the way the 'soft' VDU works it is hardly surprising if it has to spend more time on the bus than the original hardware VDU does. It is fantastic that it works as well as it does.
Attached Thumbnails
Click image for larger version

Name:	Nenin_PIC_VDU_active_1frame .jpg
Views:	50
Size:	88.7 KB
ID:	217826   Click image for larger version

Name:	Nenin_SOC_VDU_active_1frame.jpg
Views:	50
Size:	75.3 KB
ID:	217827   Click image for larger version

Name:	Nenin_SOC_VDU_active_expanded.jpg
Views:	47
Size:	88.1 KB
ID:	217828  
SiriusHardware is offline  
Old 13th Oct 2020, 8:57 pm   #384
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

To answer your other question, Tim has acquired a collection of software to run on the VDU, including one or two items which could be considered 'Video Games'. When I get a chance I'll try the 'Falling Man' animated demo on your PIC-VDU, if Tim doesn't beat me to it.

The problem is that historically, not many MK14 owners had a VDU (did you?) and those who did mostly only had the memory expanded to the 'full' 640 bytes, myself included, so it wasn't a great system to try to write games on given that the VDU ate up 512 bytes of that RAM leaving just 128 bytes to write a video game in.

Several things which have come together now make it more likely that someone might write a new demo or game for the MK14.
-Ian's replica PCB is the easiest ever to connect a VDU to, and it has the 'memory hole' at 0200-07FF which MK14s before issue V historically did not, at least not without modification.
-Static RAM for making a memory expansion with is dirt cheap now, very expensive back in the day.
-We have better / easier tools for developing code to run on the MK14 now, including your brilliant PIC14.
-Anyone who doesn't have a SOC VDU can now build yours for a fraction of what it would cost to buy a genuine one or build a replica.

Last edited by SiriusHardware; 13th Oct 2020 at 9:10 pm.
SiriusHardware is offline  
Old 13th Oct 2020, 9:07 pm   #385
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 am very aware that my design falls a long way short on the 6% processor slowing specification. Ideally, every bus read would have its own NENIN assert/ drive buses/ read data/ release buses/ de-assert NENIN. There just aren't the PIC cycles to do this.

But there is an opportunity I can explore and I'll give some time to this when I feel up to it. I can't promise 6% slowing but I think I can do better than the current processor loading.
It looks to me like the SOC vdu pulls NENIN high just before the 'active' part of the display line (32uS of the 64uS) and releases it as the last pixel is sent out leaving 50% of the time available for the CPU. Perhaps you could do something similar in the front porch/back porch section? That would leave ~14us of CPU each display line and the complete vertical retrace time.
Slothie is offline  
Old 14th Oct 2020, 12:05 am   #386
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

You have made amazing progress in such a short time - the fact that it just worked is a real achievement and makes a great addon for people to develop on for the MK14. Fine tuning will be great whatever cycles can be gained when you feel another surge of energy.

If I use this as the basis for the SCRUMPI 2.5 VDU circuit as I plan then that has its own RAM and some buffers on the BUS so would have less impact.

Of course there isn't even the massive software base of; one animated demo (falling man), and three interactive games for that system like on the MK14 Did I even post Horse Race and Minefield yet here (which can both have their delay loop shortened!!!)? The other is not available publicly yet (pong https://www.youtube.com/watch?v=2hLAX2UUdpk watch this space when I get mine built they will be running ASAP.

Quote:
Originally Posted by Slothie View Post
Quote:
Originally Posted by Karen O View Post
I am very aware that my design falls a long way short on the 6% processor slowing specification. Ideally, every bus read would have its own NENIN assert/ drive buses/ read data/ release buses/ de-assert NENIN. There just aren't the PIC cycles to do this.

But there is an opportunity I can explore and I'll give some time to this when I feel up to it. I can't promise 6% slowing but I think I can do better than the current processor loading.
It looks to me like the SOC vdu pulls NENIN high just before the 'active' part of the display line (32uS of the 64uS) and releases it as the last pixel is sent out leaving 50% of the time available for the CPU. Perhaps you could do something similar in the front porch/back porch section? That would leave ~14us of CPU each display line and the complete vertical retrace time.
Timbucus is offline  
Old 14th Oct 2020, 12:37 am   #387
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

You did post Minefield, which I actually had running. Would it lend itself to a full screen version, I wonder? Can the three characters which form the tank be different? I was thinking that rather than XXX, something like [Q] might look a bit more like an overhead view of a tank, the 'Q' being the gun turret of course.

I think you also put Horse Race in a bundle but at the time I did not have a complete system to try it on - I should try it now that I have.
SiriusHardware is offline  
Old 14th Oct 2020, 2:05 am   #388
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
It looks to me like the SOC vdu pulls NENIN high just before the 'active' part of the display line (32uS of the 64uS) and releases it as the last pixel is sent out leaving 50% of the time available for the CPU. Perhaps you could do something similar in the front porch/back porch section? That would leave ~14us of CPU each display line and the complete vertical retrace time.
So where did the 6% figure come from?

I have observed that four inner-most subroutines feed the serial port with the background colour, both before and after the active text/graphics. There are some DELAY macro calls in these times, which could be pressed into service to turn on and off the bus. That would reclaim a decent amount of time for the processor.
Karen O is offline  
Old 14th Oct 2020, 8:48 am   #389
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Quote:
So where did the 6% figure come from?
I can't remember if that came from the manual or from an article somewhere. I always thought that was very optimistic myself.

I suppose if you look at that bit of test code, generated frequency drops from 450Hz (without VDU) to 415Hz (With SOC VDU) that is a better indication of the slowdown introduced by the original VDU.

Fun thought: I could try running 'Digital Clock' and seeing how much time it loses in ten minutes when each VDU is active. Does anyone have a version of that program re-timed for a 4.00MHz clock?
SiriusHardware is offline  
Old 14th Oct 2020, 8:57 am   #390
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I make 415Hz about 92% of 450, so 8% difference? Not too far off the anecdotal 6%, I suppose.
SiriusHardware is offline  
Old 14th Oct 2020, 9:23 am   #391
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
So where did the 6% figure come from?
I was wondering that myself. Sirius's observed 8% doesn't allow much time for fetching from memory... there are 32*8 = 512 visible lines of which 50% of the time the memory is being accessed and the remaining 113 lines of which 0% of the time memory is being accessed, so the percentage should be 256/625 or a 40% slowdown if the processor is halted while NENIN is being pulled up.... I'm missing something here.

Unless the SC/MP is able to run in the background while NENIN is '1' only being held up when it needs memory access, but would that account for a factor of 5 if Sirius's program only accesses the memory for instruction fetches and the processor is able to limp on in the background, so to speak? If so Karen's proposal should provide an equivalent speed-up that might require Tim to keep his delay loops!
Slothie is offline  
Old 14th Oct 2020, 3:53 pm   #392
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

I've tried to minimise time spent with NENIN asserted in the hope that the SC/MP runs faster. I've checked the code carefully but I would appreciate someone testing it on real hardware.
Attached Files
File Type: zip PICMk14VDU.zip (96.9 KB, 47 views)
Karen O is offline  
Old 14th Oct 2020, 4:19 pm   #393
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Happy to give it a test drive as soon as I get home, thanks Karen.
SiriusHardware is offline  
Old 14th Oct 2020, 6:22 pm   #394
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I have what I am calling V1.02 firmware in the PIC VDU now - On the one hand the display on the MK14 looks much more normal, but unfortunately operation of the VDU side of things is now 'broken'. The overall display is still steady but all of the characters (when in character mode) are flickering / changing rapidly all the time. If I change to graphics mode I notice that there seems to be a steady state pattern of pixels and a rapidly changing one being shown on alternate frames, as though there are two frame buffers and only one of them is having its contents randomly changed.

I take it that when tested with an EPROM as data source it still works, so it must be about the timing of NENIN which I assume is not involved with the EPROM in any way?

Maybe if you connect NENIN to your test EPROM's _CE pin via an inverter (or just invert the polarity of NENIN in the firmware for the purposes of this test and connect it directly to EPROM _CE) you may be able to see the effect I am seeing, or something similar.

If I revert back to firmware V1.01 it goes back to the way it was working before - as intended, but making the MK14 run quite slowly.
SiriusHardware is offline  
Old 14th Oct 2020, 9:20 pm   #395
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

That's disappointing

I used a rather crude test method: I put the 'scope in x-y mode, fed in NENIN and NRDS, then checked that negative excursions of NRDS are confined to when NENIN is high.

Clearly, my margins are not wide enough somewhere...
Karen O is offline  
Old 14th Oct 2020, 9:36 pm   #396
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

That's a nice 'guerilla' method of looking at the coincidence of the two.

It's a shame we didn't get one of Slothie's replicas to you a while back when we were musing over that possibility, I just know that if you had all of the actual hardware in front of you you would have this sorted in five minutes flat.

It's going in the right direction, the fact that the 7-segment display on the MK14 reverted to more or less normal must mean that the MK14 got a considerable bite of the time cherry back after your mods to NENIN.

There are, though, a few faint flickers of interference on the 7-segment display perhaps suggesting that both the PIC VDU and the SC/MP are overlapping, even if only slightly, when accessing the memory.
SiriusHardware is offline  
Old 15th Oct 2020, 8:15 am   #397
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

One serious obstacle is the lack of definitive timing information on NENIN. I find the SC/MP datasheet somewhat scant in this area, the implication being 'here's a feature, but you'll have to work it out for yourself'.
Karen O is offline  
Old 15th Oct 2020, 8:18 am   #398
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

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?
Karen O is offline  
Old 15th Oct 2020, 9:00 am   #399
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I will run it up tonight and try to be more specific about the nature of the problem. This is what I mean when I say I wish you had a system to try yours on.

Given your inside knowledge of what the firmware does and when, You would instinctively understand what the problem is just from looking at it.
SiriusHardware is offline  
Old 15th Oct 2020, 11:10 am   #400
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Thanks SH, and thanks for your faith in my diagnostic abilities. Unfortunately I don't share that faith I will do a more quantitive analysis of the current situation specifically:

1. How long after PIC bus release to NENIN high.

2. How long after NENIN low before the PIC starts to drive the bus.

I will also look again at the SC/MP datasheet to see if any timing constraints surrounding NENIN can be established.

Why do I feel like I'm talking about a long dead Russian dictator?

Last edited by Karen O; 15th Oct 2020 at 11:12 am. Reason: Got sense of NENIN wrong
Karen O is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 11:55 pm.


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.