UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   Mk14 vdu (https://www.vintage-radio.net/forum/showthread.php?t=162766)

SiriusHardware 7th Jan 2020 9:27 pm

Mk14 vdu
 
I know several people around here either have or may, at some point, be building a replica SOC VDU, as used with the MK14.

It took some finding, but here is what may currently be the only Youtube clip of an MK14 driving an MK14 VDU, unless of course anyone knows differently. (The MK14 is visible on the far right hand side of the video image).

https://www.youtube.com/watch?v=q8YG0hjRbZo

Karen O 8th Jan 2020 6:25 pm

Re: Mk14 vdu
 
Thanks for that link, SH.

A few comments:

I had always assumed the Mk14 VDU display was 16 lines of 32 characters but it looks like it's 32 lines of 16 characters.

Is it a camera artefact or are odd lines and even lines displayed in separate fields?

Am I right in thinking this VDU uses DMA?

SiriusHardware 8th Jan 2020 7:16 pm

Re: Mk14 vdu
 
2 Attachment(s)
I suppose you could call it DMA - it uses the SC/MP's ability to go hands-off on the bus to take over the memory, scans 512 bytes of the 640 bytes total memory and renders the contents as either characters or pixels. The character mode layout is 16 across by 32 down, the character lines are really too close together for comfort with a very small vertical interval between the lines.

As to the rendering mode, I can't honestly say as I have never looked into it in that kind of detail. I'll attach the manual, which includes the circuit diagram, below.

There were various problems with it:

-When the VDU was active it stopped the SC/MP whenever the scanning dot was within the 'drawable' area of the screen - in other words, instead of halting the SC/MP for just long enough to read each byte of screen data, it would keep the CPU in the halt state whenever the 'dot' was within the drawable area, which slowed the system down a lot.

-It ate up most of the available RAM, leaving only 128 bytes in which to write an actual program.

-The MK14 standard 4.43Mhz crystal had to be changed to 4.00Mhz for the VDU, so software timing-critical programs such as 'Music Box' and 'Digital Clock' didn't run quite as well as before.

-No version of the MK14 ever had proper connections provided for connection of the VDU - issue IV and V had extra 'finger' connections on the track side of the rear edge connector but they still weren't actually wired to the buses, you had to do that yourself.

For all of the above reasons mine didn't stay connected to the MK14 for long, but around 2013 I found it languishing unloved in a drawer and took pity on it, connected it to a PIC programmed to emulate 512 bytes of RAM and powered it up, essentially just so that I could show it / see it working. (see attached image). The lines of text on that demo image are written to every other character line to leave a reasonable space between lines.

You may recognise the PIC PCB as a '44 pin demo' PCB, as supplied with some versions of the PicKit2 / PicKit3 programmers. The PIC is an 18F452. The 'metal can' oscillator is providing the 4.00Mhz clock which would normally be borrowed from the MK14.

Practical Electronics magazine were enthusiastic supporters of the MK14 and produced a superior VDU project for it - unfortunately I never saw one or came across anyone who had one.

Karen O 8th Jan 2020 7:42 pm

Re: Mk14 vdu
 
Thanks, SH, I will have a look at that circuit.

I think it was inevitable that the SC/MP would be locked out for most of the while. I expect the worst case latency for bus acquisition corresponds to the longest instruction (ILD/DLD at 22 microsec). That's a third of a scan line, so the hardware didn't dare relinquish during rendering.

SiriusHardware 8th Jan 2020 9:23 pm

Re: Mk14 vdu
 
Actually, I hadn't thought that through, I'd always just assumed that the uP just went instantly off-bus with any ongoing action held in a static state. It never occurred to me that it might finish whatever it was doing before relinquishing the bus.

The VDU holds _RD low from the left edge of the 'drawable' area to the right edge of the 'drawable' area, which presents a problem for the PIC pretending to be RAM.

The very first "Read address from VDU / get data from that address in PIC RAM / Present data to VDU data bus" cycle is done on detection of the falling edge of _RD, but then the VDU just holds _RD low for the rest of the line, outputs the next address, reads, outputs the next address, reads, and so on until the end of the line where it releases _RD high.

With _RD staying low for the whole of the rest of the line, the PIC instead watches for changes of state of the VDU A0 line in order to know when to do the next read address / get data / offer data cycle.

Karen O 9th Jan 2020 9:37 am

Re: Mk14 vdu
 
Well, TBH I'm not sure what SC/MP behaviour is. I'm probably making assumptions - a multi-processor system needs semaphores, and you can't have those if instructions can be interrupted. But that's a guess. When I've gathered enough resolve I'll study the SC/MP data sheet to determine exactly how bus appropriation works!

SiriusHardware 9th Jan 2020 10:35 am

Re: Mk14 vdu
 
I'm certain you're right, otherwise if the uP was halted in mid-action it would probably have to rewind to the start of the action. It would be much more logical for the uP to notice the request for the buses, finish what it is doing, release the buses and then signal that they are available.

Timbucus 11th Jan 2020 4:07 pm

Re: Mk14 vdu
 
Nice find on the Video Sirius - I wonder what the code does as it is not either of the SCIOS image (V1 or V2) copies that would be at 0200 - it does seem to be a primitive disassembler code listing tool running - and I am sure I have seen one of those in a magazine somewhere but, can't find it again.

Karen O - There is a good description on the multiprocessor function in the May 1979 Elektor in the article before NIBL-E:

http://https://www.americanradiohist...or-1979-05.pdf

Sheet 38 of the PDF - Page 5-34

I have all the parts now to make a VDU but, I really need to build an issue V board as my JMP Issue 1 will be harder to use with it because of the memory decoding and lack of solder pads on the lower side. The V5.5 board design from Slothie is promising in that regard with the actual routing for all the pins.

SiriusHardware 11th Jan 2020 10:42 pm

Re: Mk14 vdu
 
Quote:

Originally Posted by Timbucus (Post 1206806)
I wonder what the code does as it is not either of the SCIOS image (V1 or V2) copies that would be at 0200...

I have a feeling both the VDU and the MK14 in this case are Czech (Martin L) replicas so the ROM images will be absent. Perhaps it's being used with one of ML's RAM expansion / PROM to EEPROM converter daughterboards, as in here:-

http://www.8bity.cz/2018/science-of-...ram-expansion/

The page is in Czech but any browser will offer to translate it, or there are various flags to click on at the top of the right hand column. I know this has been mentioned before in related threads, it is included here again for anyone who comes looking for info relating specifically to the MK14 VDU.

One of these expansions would be an essential companion for the VDU, I'm sure that will have been his main motive for producing that add on - but of course it can only work with an issue V - real or replica, or with earlier issue machines which have been modified to remove the PROM images from 0200-07FF.

SiriusHardware 25th Feb 2020 8:54 pm

Re: Mk14 vdu
 
Just checked back on the video I linked to in post #1: The originator (Milan) has stated that he has now made a game running on the VDU, which he hopes to post a video of soon.

Maybe a few more positive comments on the original video clip will give him a bit of incentive?

SiriusHardware 26th Feb 2020 6:39 pm

Re: Mk14 vdu
 
And here it is! Roughly analagous to the 'Squash' game in the old AY-3-8500 based video games, or Breakout without the Bricks...

https://www.youtube.com/watch?v=2hLAX2UUdpk

Timbucus 26th Feb 2020 7:17 pm

Re: Mk14 vdu
 
Looking good - using the whole screen as well - I wonder if it is extra RAM or just the expansion 128 bytes - impressive if so. Anyway gave it a tweet to see if we can get some thumbs up!

SiriusHardware 26th Feb 2020 8:55 pm

Re: Mk14 vdu
 
As you may remember from his first video his MK14 - which he says is a replica, probably one of Martin L's Czech issue V replicas - appeared to have RAM at 0200, therefore probably 1.5K of additional RAM at 0200-07FF as well as the usual 640 byte RAM of a fully expanded MK14.

I guess he'll be using one of Martin L's extra-memory daughterboards, as mentioned in post #9.

Timbucus 26th Feb 2020 11:58 pm

Re: Mk14 vdu
 
Indeed you are correct it is hard to remember al the threads now!

Slothie 3rd Mar 2020 2:28 pm

Re: Mk14 vdu
 
1 Attachment(s)
Hi folks!
If anyone is interested in trying my new rel 5.5 PCB which was specifically designed to connect to the VDU board by the edge connector they are at https://bitbucket.org/IanKRolfe/mk14/src/master/ and https://bitbucket.org/IanKRolfe/kica...ib/src/master/ which are bitbucket git repositories for tje boatd and the libraries i have created for components not in the default libraries. They are for an older version of Kicad so if you have a more recent one you may need to fiddle with the library settings and/or ignore warnings about them.

I cant really help at this time because i am still languishing in hospital (although things are going well) and have no access to my laptop or the boards i had made. I did manage to retrieve the zipfile i uploaded to JLCPCB but my phone doesnt seem to like the attach file dialog here so i have put it as a download on the bitbucket mk14 repository. If you have any luck with it please tell me!

SiriusHardware 3rd Mar 2020 6:16 pm

Re: Mk14 vdu
 
Hello Ian (Slothie), very nice to hear from you and thanks for thinking about us in your current situation. Glad to hear the sand is still flowing in the right direction.

I'll gladly take a look at the contents of the archive but I have never used Kicad or gone on to order PCBs made with it, so it may be a steep learning curve. No doubt Tim will be along presently, maybe the two of us can huddle together and sort out an order for some PCBs between us - you must have been reasonably confident that the design was good when you ordered your own PCBs.

I think we'll continue any further discussion about this in what was, after all, your thread concerning this very project, the 'MK14 Schematic Revisions' thread.

You were right to point out that your MK14 PCB design is unique in the way that it has all the signals required by the VDU routed to the rear edge connector.

Timbucus 3rd Mar 2020 10:42 pm

Re: Mk14 vdu
 
Indeed good to hear you are going the right way - as you know I had a long stint in hospital as well so appreciate you taking the time to do this and understand your frustration with lack of access to your hobby! As Sirius says we will continue the thread on the PCB with progress so you enjoy it vicariously. As my main interest was to get my VDU board working this will be a great chance to push forward on that without hacking my JS one to bits!

Slothie 7th Mar 2020 9:36 pm

Re: Mk14 vdu
 
Dont forget the XOUT signal got moved from 1 side of the board to the other so you will need to make a mod to the VDU card.

Timbucus 8th Mar 2020 8:20 pm

Re: Mk14 vdu
 
Thanks will do! I had forgotten

Slothie 24th May 2020 11:20 am

Re: Mk14 vdu
 
2 Attachment(s)
DM8678 emulator from 1978 National Semiconductor book that might be useful for people having yrpuble getting the character generator chip. The proms could be replaced by any EPROM 1024x8 or larger.


All times are GMT. The time now is 7:49 am.

Powered by vBulletin®
Copyright ©2000 - 2021, vBulletin Solutions, Inc.
Copyright ©2002 - 2020, Paul Stenning.